Career & Craft
達人プログラマーと歩んだキャリアの転換
インフラ→Web→PLへ。13年の試行錯誤で見えたもの。
達人プログラマーの言葉を、自分のキャリアに重ねて振り返る。
この記事のポイント
Chapter 01
20代半ば、インフラエンジニアとして7年目を迎えたあたりで、漠然とした違和感を覚えた。
Linux、Windows Server、VMware、ファイアウォール。手を動かすほど現場で頼りにされたし、資格も取った。VCP、LPIC、CCENT、応用情報、ITIL。できることは着実に増えていた。
ただ、ふと思った。自分は「何かを作る人」ではなく、「何かを維持する人」になっているな、と。
サーバーの監視、障害対応、パッチ適用。重要な仕事ではある。けれど、「自分で設計して、形にする」経験がほとんどなかった。このままでいいのか——そう思ったのが、2019年ごろ。高卒でこの業界に入ったので、26歳にしてすでにインフラ7年目だった。
結局、転職を選んだ。受託開発の世界に飛び込んだ。PHPもJavaScriptもほぼ未経験。インフラ畑から見ると、全く違う景色だった。
あれから7年が経ち、30代になった今、当時の判断を振り返って思うことがある。自分のキャリア観に大きな影響を与えた本がある。「達人プログラマー」だ。
「あなたのキャリアはあなたのものだ。自分自身の手でデザインせよ。」
——『達人プログラマー』の教えより（要旨・筆者による意訳）
この言葉が、まさに自分の状況に刺さった。誰かに用意されたキャリアパスを歩くのではなく、自分で選び、自分で舵を切る。そういう覚悟を持てたのは、この本がきっかけだった。
Chapter 02
達人プログラマーが繰り返し説くのが「主体性」だ。問題を見つけたら他人のせいにしない。環境を嘆くのではなく、自分にできることを探して動く。
「割れた窓を放置するな。」
——『達人プログラマー』の教えより（要旨・筆者による意訳）
インフラ時代の自分は、正直なところ「指示待ち」に近かった。運用手順書があり、それに沿って作業をする。障害が起きたら対応する。上流から降りてくるタスクを正確にこなすことが評価される世界だった。
Web開発に転身してから、求められるものが変わった。顧客の曖昧な要望を聞き取り、仕様に落とし込み、設計し、実装する。誰も正解を用意してくれない。「何を作るか」を自分で考え、提案する力が必要になった。
最初は苦しかった。「これで合っているのか？」と常に不安だった。けれど、顧客と直接対話し、要件を整理し、仕様書を書くプロセスを重ねるうちに、少しずつ変わっていった。「言われたことをやる人」から「本当に必要なことを提案する人」へ。
振り返って思うこと
「オペレーター」から「デザイナー」への転換は、技術の問題ではなかった。マインドセットの問題だった。手を動かす前に「なぜこれを作るのか」を考える習慣。それが主体性の正体だと、今なら言える。
プロジェクトリーダーになった今、この姿勢はさらに重要になっている。チームメンバーに作業を振るだけではなく、プロジェクトの方向性そのものを提案できるかどうか。それは、かつて「指示待ち」だった自分が、もっとも大きく変わった部分だと思う。
Chapter 03
達人プログラマーは「知識のポートフォリオ」という考え方を提唱する。金融のポートフォリオと同じように、知識にも分散投資が必要だという話だ。
「知識のポートフォリオに定期的に投資せよ。」
——『達人プログラマー』の教えより（要旨・筆者による意訳）
これは、自分にとって比較的自然に実践できたことかもしれない。StrengthsFinderでいう「学習欲」と「収集心」が上位にある自分にとって、新しい知識を仕入れ続けることは苦にならない。
13年のキャリアで取得した資格は13。クラウド、インフラ、設計、品質、データベース、マネジメント、国家資格と、意図的に分野を散らしてきた。AWS Solutions Architect、UMTP L2、JSTQB、OSS-DB Silver。一見バラバラに見えるかもしれないけれど、全部が「システムを多角的に見る目」に繋がっている。
読書は累計900冊を超えた。技術書だけじゃない。ビジネス書、心理学、投資、ときにはマンガまで。一冊一冊が、別の知識と結びついて新しいアイデアを生む。StrengthsFinderの「着想」とはまさにこの感覚だ。
自分のサイクル：読む→試す→仕組み化
本で知識を仕入れ、小さく試し、うまくいったら仕組みに落とす。このサイクルが自分の学び方の基本形だ。デザインパターンもDockerの環境構築も、すべてこのプロセスから生まれた。
業務ドメインの幅も広がった。福祉・介護の業務システム、医療機関の在庫管理、ECサイトの決済フロー。それぞれの現場で求められる知識は全く違う。介護保険の仕組み、医療品の発注ロジック、3Dセキュア認証の規格。
達人プログラマーが言う「知識のポートフォリオ」は、資格や書籍の数のことではない。異なる領域の知識が交差するポイントにこそ、本当の価値がある。インフラの知識があるからこそサーバー設計ができ、品質の知識があるからこそテスト戦略が立てられる。分散投資が効いてくるのは、予想外の場面だ。この「知識のポートフォリオ」がどう資産形成にまで波及するかは、13年分のデータで統合分析したレポートにまとめた。
Chapter 04
達人プログラマーの有名な概念に「Pragmatic Paranoia（実用的な妄想）」がある。最悪のケースを常に想定し、防御的にコードを書くという考え方だ。
「自分自身のコードすら信用するな。」
——『達人プログラマー』の教えより（要旨・筆者による意訳）
これを読んだとき、笑ってしまった。まさに自分だ、と思ったからだ。
StrengthsFinderの2位が「慎重さ（Deliberative）」。何かを始める前にリスクを洗い出し、問題が起きた場合の対処を先に考える。周囲からは「心配しすぎ」と言われることもあるが、設計の世界では、この性質が武器になる。
具体的な例を挙げると、外部API統合の設計で活きた。ある案件で外部APIの個別実装が3社分並存していて、そこに4社目の連携追加が持ち上がった。APIごとにデータ形式もエラーハンドリングも違う。目先だけ見れば、個別実装をもう1本継ぎ足すのが最小工数だ。しかし「5社目、6社目が追加されたらどうなる？」——そういう妄想から、これを機にAdapterパターンで統一基盤へ再設計する道を選んだ。
Adapterパターンの設計判断
各社のAPIをそれぞれ個別のAdapterクラスでラップし、統一インターフェースを定義。ビジネスロジック層はAPIの違いを意識せずにデータを扱える構造にした。結果として、以後のAPI追加がAdapterクラス1本の追加で済むようになった。
マルチテナントアーキテクチャの設計でも同じだ。「テナントAのデータがテナントBから見えてしまったら？」という最悪のシナリオを想定し、データの分離戦略を最初に決めた。パフォーマンスとのトレードオフはあるが、セキュリティ事故が起きてからでは遅い。
達人プログラマーの「妄想」は、単なる心配性とは違う。「起きうる問題を先に潰す」のではなく、「問題が起きても対処できる構造を先に作る」という姿勢だ。StrengthsFinderの「慎重さ」が、設計における強みに変換されるポイントは、まさにここにある。
Chapter 05
達人プログラマーが重視するもうひとつの軸が「アジリティ（俊敏性）」だ。完璧なものを一度に作るのではなく、小さく動くものを素早く作り、フィードバックを得ながら改善する。
「曳光弾を使え。暗闇の中でターゲットを探すのではなく、光の軌跡で方向を確認しろ。」
——『達人プログラマー』の教えより（要旨・筆者による意訳）
自分の場合、このアジリティが一番発揮されたのはDocker環境の標準化だった。
チームの開発環境がバラバラだった時期がある。OSの違い、ミドルウェアのバージョン違い、「自分の環境では動くんですけど」問題。完璧なCI/CDパイプラインを構築する前に、まずdocker-composeで開発環境を揃えるところから始めた。
最初は最小構成。PHP + PostgreSQL + Nginxだけのシンプルなcomposeファイル。これをチームに展開し、フィードバックをもらいながら少しずつ必要な機能を足していった。最終的にはプロジェクトごとのテンプレートとして定着した。
「動くコード」ではなく「保守しやすいコード」
EC-CUBE4のプラグインを20本以上開発してきた中で感じたのは、「動くこと」はスタートラインでしかないということ。プラグインは本体のバージョンアップに追従する必要がある。保守しやすい構造でなければ、技術的負債がすぐに溜まる。
「読む→試す→仕組み化」という自分のサイクルも、アジリティそのものだ。本で得た知識を、いきなり大規模に適用するのではなく、まず小さなプロトタイプで試す。うまくいったら、チームで使える仕組みに落とし込む。完璧を目指して動かないより、不完全でも回り続ける仕組みのほうが、結局うまくいく。
Chapter 06
達人プログラマーには「Good Enough Software（十分なソフトウェア）」という考え方がある。完璧主義はむしろ有害で、「十分によい」を見極めるスキルが必要だという話だ。
「完璧なソフトウェアは存在しない。十分によいソフトウェアを目指せ。」
——『達人プログラマー』の教えより（要旨・筆者による意訳）
これはプロジェクトリーダーになって、よく考えるようになった概念だ。
エンジニアとしての自分は、コードの品質を徹底的に追求したい。設計は美しくしたいし、テストカバレッジも上げたい。でもPLとしての自分は、納期を守らなければならないし、チームメンバーの稼働も考えなければならない。
この二つの自分が毎日ぶつかる。
PLが日々向き合うトレードオフ
グッドイナフとは「妥協」ではない。「今この瞬間の最適解」を意識的に選ぶということだ。
たとえば、ある機能の実装で「理想はRepository + Service層で分離したい」が「スケジュール的に直書きの方が現実的」という場面。ここで大事なのは、「今は直書きにするが、将来のリファクタリングポイントとしてコメントを残す」という判断だ。品質を諦めるのではなく、品質の上げ方にタイミングの概念を持ち込む。
StrengthsFinderの「個別化」が、ここで効いてくる。チームメンバー一人ひとりの強み・弱みを見て、タスクの割り振りを調整する。全員に同じ品質基準を押しつけるのではなく、その人の成長段階に合わせた「ちょうどいい」を設定する。グッドイナフの哲学は、コードだけでなく、チームマネジメントにも当てはまる。
Chapter 07
今、育休中だ。4人の子どもとの時間を過ごしながら、キャリアを見つめ直している。
13年を振り返ると、「T字型スキル」の横棒が思った以上に広くなっていた。インフラ、バックエンド、フロントエンド、DB、設計、品質管理、そしてプロジェクトマネジメント。どれも専門家レベルとは言えないかもしれないが、全レイヤーから問題を切り分けられる視点は、自分の強みになっている。
ただ、技術力だけでは足りないことも分かってきた。
PLとして感じるのは、「伝える力」の重要性だ。どれだけ良い設計ができても、顧客に価値を伝えられなければ意味がない。チームメンバーに設計の意図を共有できなければ、保守性は担保できない。技術の深さと、人に伝える力。この両方を磨き続けることが、次の10年のテーマだと思っている。
育休中に考えていること
達人プログラマーの最も大切なメッセージは、テクニックではなく姿勢にある。
主体性を持つこと。知識に投資し続けること。慎重さを設計に活かすこと。完璧よりも回り続ける仕組みを選ぶこと。そして、「十分によい」を見極める目を持つこと。
これらは全部、13年のキャリアで自分が実感してきたことだ。達人プログラマーはそれを言語化してくれた。
おわりに
30代で「分岐点」を経験し、インフラエンジニアからWeb開発者になり、今はプロジェクトリーダーとして設計とマネジメントの間に立っている。
達人プログラマーは、完成形としての「達人」を描いた本ではない。学び続ける旅人の姿勢そのものを描いた本だ。
10年後の自分がこの記事を読み返したとき、「あの頃はまだこんなことで悩んでいたのか」と笑えるくらい成長していたい。そのために、これからも「読む→試す→仕組み化」のサイクルを回し続ける。
達人とは完成形ではなく、
学び続ける旅人の姿勢そのもの。
著者: しきぴょんた / 初出: 2025年 note（3部構成） / 本サイト用に再編集