たびたび紹介しているけど、Chad Fowler著の『情熱プログラマー』（オーム社刊。kmutoは日本語版の編集と監修を担当）は色あせぬ金言に満ちていて、自分の意識や行動にも大きく影響を与えている（最近もまた重版のお知らせがあり、ありがたいことです）。
Mackerel CREにキャリアチェンジしてから3年を過ぎ、働き方も変化しているので、再び読み返していた。
一番の下手くそなエンジニア
「4. 一番の下手くそでいよう」は挑戦を後押しする力強い言葉で、「エンジニアリングをかじった書籍制作者」から「ITエンジニア」への転身を決意し、新たなキャリアを始めるにあたっても心に刻んでいた。
kmuto.hatenablog.com kmuto.hatenablog.com
「Mackerel CREのカスタマーサクセスユニットエンジニア」という職がアプリケーションエンジニアではなくセールス寄りのポジションというのは差し引いても、周囲の優れたITエンジニアを尊敬し学んできたことで、良いITエンジニアとして成長できているのではないかと思っている。先日はエンジニアリングの発揮を含めたCREの仕事について社内表彰いただいた。
半期の社内表彰でCTO賞と敢闘賞をいただきました。CREという職種で受賞するのは予想してなかったので驚きとともに嬉しく、チームを勇気づけることにもなって良かったなと思います☺️
— kmuto (@kmuto) 2026年1月30日
「一番の下手くそ」からのつながりとして「39. 業界で名前を売ろう」「40. 自分のブランドを築こう」「43. コネを作る」がある。
人によっては抵抗を感じるかもしれないが、これらはどれも悪いことではない。もちろん嘘で飾るのは絶対にダメだけど（いずれバレて最悪なデジタルタトゥーになるだけだ）。
過去の自分の体験としても、一番の下手くそとしてまずは入門し、先達に学びながら、自分なりの強みを持ってつながりを構築していくことを繰り返してきたと思う。
広くてちょっと深い
「7. 万能選手になろう」「8. スペシャリストになろう」。これらは矛盾しない。
現代のほうがITサービスの複雑性は増していて広範な知識が求められるし、CREはIT技術だけでなくビジネスにも直接の関心を持たないといけない。
何かのスペシャリストであるということを、単にほかのことを知らないという意味で使っている人が多すぎる。
辛辣な文だが、万能選手になった上で、さらに特定分野に深み凄みを持ってこそはじめてスペシャリストと名乗れるのだろう。
どちらも終わりはないことだけれども、昔から「広くてちょっと深いジェネラリスト」をロール目標としている自分にとって、2軸どちらも欲張って追求していくのは性に合っている。
ビジネスと価値
「12. ビジネスの仕組みを学ぶ」はCREとしてのキャリアを始めてから痛感している。
もちろん書籍制作業でも上長やお客さまとお金の話をしていたし、「私たちはどうして会社からお金をもらえて、ご飯を食べられているのか」と偉そうに言うこともあったけれども、SaaS事業でカスタマーサクセスという仕事を始めてみて、自分の解像度の低さを思い知らされた。
僕らはビジネスのために働いているのであり、僕らの仕事は利益を上げるか費用を削減することによってビジネスに貢献することだ
ビジネスの仕組みを知らなきゃ想像力を発揮したって役に立たない
「25. 自分にどれだけの価値があるか？」はちょっと憂鬱になるのだが、査定のたびに頭に浮かべている。
君は有利な投資対象になっているか？
ヒェー……
巨人の肩とAI
「17. 巨人の肩の上で」では、先人から学ぶ方法として、OSSのコードリーディングや、人を集めての読書会が挙げられている。
この点で、今はとても便利な時代になったと思う。基盤ソフトウェアから高度なアプリケーションまでさまざまなプロダクションレベルのコードがGitHubなどで公開されており、CopilotなどのAIを使って好きなだけ解析できる。
「AI時代では設計が重要」と言っても、実装の理解なくして設計することなんて無理だろう。疲れないAIを壁打ち相手に「15. 一に練習、二に練習」して筋トレしよう。
「社員は設計だけやって実装は外注」スタイルは、最初はいいけど数年単位でみるとうまくいかないのが体感としてあって、いま著名な人でもAIの登場によって人間が設計だけになると言ってるのを見ると、なにが違うんだろうと思う(生成されるコードの品質？速度？)
— kadota (@plan9user) 2026年1月23日
有言実行と他者への影響の難しさ
自分の業務の進め方のスタイルとしては「19. 今すぐに」と「32. 言って、成して、示す」が相当する。
“いつかやる”のレーンに入れたタスクは、二度と顧みられることはない（あるいはいよいよ火が付いたときに慌てて対処し、同じことを繰り返すだろう）。CREの業務範囲だと、たいていはしがらみよりは気合いの問題なので、新しいことはエイッとまず進めたりしていた。
とはいえ、ゴール設計・計画・実行を考えて必要なタスクを分解するようにはしていて、バックログにチケットをガンガン立ててバンバン消化している（今は積み残しができつつあるので棚卸しして捨てよう……）。
ソロ冒険者に近かった前職と大きく違うのは、チーム行動や評価制度として「有言」（宣言）が重要なことだろうか。無言実行は感謝されることもあるが、「優先すべきアレを放ってソレをやっていたの？」と思われてしまうリスクもはらむ。
難しいなぁと思うのは、「言って、成して、示す」だけでなく、他者の行動を直接変えることを期待されたときだ。
本書において自分を変えるための話題はたくさんあるが、他者を直接変化させる言及はない。「14. 師匠になる」も、教えて理解を深めることと、助けて関係を築くことが主眼だ。
自分は仕事を「それぞれがプロとして自身に責任を持ち、職務やタスクを実行してゴールを達成する」ものと捉えていて、他者の行動に踏み込んでいくのは食い合わせが悪い気がしている（『Team Geek』も読み返しているが、これはあまりしっくりこなかった）。
ロードマップと次のアチーブメント
「47. 自分のロードマップを作る」では、自身を製品に見立て、機能目標とロードマップを考えてみて、適宜更新することが提案されている。
ロードマップという地図がなければ、文字どおり路頭に迷いかねないんだ。
「今たずさわっている業務スコープだけでキャリアプランを考える」ことのリスクは、書籍内でもたびたび触れられている（「9. 自分の人生を他人任せにするな」「44. 既に時代遅れである」「45. 君は既に職を失っている」）。
最近「この会社でITエンジニアとしてやっていけているという証明として達成してみたい」と思っていた中目標イベントをアチーブメントしたので、ロードマップの更新タイミングだ1。
おわりに
読み返してつくづく良い本だった（小並感）。今のCRE業務にもやはり応用しやすい。
ITエンジニアという世界で生きていく上での本質的なテーマで古びておらず、良いITエンジニアを目指すならぜひ読んでほしいな、と改めて思う。
- Mackerel CREは続けるヨ！↩
