階段を登るのではなく、円を広げる。「ホロン構造」で捉える開発者の成長

前稿では、ソフトウェア開発者の成長を測る第一の尺度として、「練度（密度の高い、美しい仕事）」について書きました。「品質こそが速度の源泉である」という事実は、プロフェッショナルが身につけるべき揺るぎない土台です。

しかし、品質を磨き上げるだけでは、真の自立には到達できません。熟達にはもう一つの不可欠な軸、すなわち「広さ（仕事の領域）」が必要です。

多くの組織では、成長を「現場を離れて管理職へ昇る階段」と捉えがちですが、技芸の本質は、現場の技術を捨て去ることではなく、それを包含したまま責任の円を広げていく「ホロン構造」にあります。

第2回となる本稿では、「プログラミング」という言葉をコードの記述から「問題解決の意志」へと再定義し、AI時代にこそ際立つ、エンジニアの「意思決定」と「最終責任」のあり方について探っていきます。

プログラミングを再定義する：コーディングは「出口」

まず、私たちの仕事の土台となる「プログラミング」という言葉を再定義するところから始めます。

世間一般において、「プログラミング」という言葉は、ソースコードを記述する作業（コーディング）と同義であると捉えられています。しかし、仕事を技芸として捉えるソフトウェア開発者にとって、その定義はもっと広く、深いものです。

私にとっての「プログラミング」とは、単にコードを書く行為だけではなく、ソフトウェアをつくること、ひいてはソフトウェアを用いて価値を提供し、現実の問題を解決する行為を指します。価値あるソフトウェアを生み出すために必要なあらゆるプロセスこそが、本来の意味でのプログラミングだと考えています。

いわば、コーディングは、プログラミングという広大な営みの『出口』に過ぎません。

巷では生成AIによってコードを書く行為がなくなり、プログラミングがなくなるような言説がありますが、そうではなく、生成AIをプログラミングの道具として使い、ソフトウェアを作り出すのです。そう考えるならば、プログラミングはなくなりません。

そして、どういった道具や手段を採ったとしても、最終的には動くコードができあがります。コードこそが動くソフトウェアのコアであることには違いありません。そして、そのコアを生み出すためには、必ずその手前の「思索」が必要になるのです。

ソフトウェア開発の真髄は「手を動かす前」にある

コードを生み出すには、様々な工程が必要です。たとえば、どういった画面やデータ構造にするのか、どんな機能が必要なのか、その機能はどんな問題を解決するのか、一体なにに困ってソフトウェアを必要としているのか。そうした検討をする前工程があって、はじめてコードは生み出されます。

料理の世界に例えるなら、シェフの仕事は「火を使うこと」だけではありません。どのような客が来るのかを知り、献立を考え、最高の食材を厳選し、丁寧な下ごしらえに時間をかける。それらすべての工程を経て、最後に包丁を握り、フライパンを振る。ソフトウェア開発も全く同じです。

• 問題の本質を把握すること： 何を解決すべきか、問題や背景を理解する。
• 要件をまとめること： 解決のために何が必要で、何が不要かを峻別する。
• 設計をすること： 論理的な破綻がなく、持続可能な構造を規定する。

これらすべての工程を貫く「意志」こそがプログラミングの真髄であり、コードを書くことはその意志を現実化するための最終的な表現手段に過ぎません。この全行程を自分の領分として捉えられるかどうかが、熟達を目指す重要な分水嶺となります。

分業という「効率化」が、開発の本質を損なう理由

現在の多くのシステム開発の現場では、効率化や大規模化の名の下に「工程ごとの分業」が当たり前のように行われています。しかし、ソフトウェア開発を技芸と捉えるならば、この分業こそが本質を損なう最大の要因であると言わざるを得ません。

本来、ソフトウェア開発の本質とは、目の前にある「問題解決」を「ソフトウェア」という形に結実させる一連のプロセスです。問題をどう解くかという「思索」と、それをどう実現するかという「実行」は、本来切り離すことができない不即不離の関係にあります。例えるなら、曲を作ることと楽譜を書くことが分業されないことや、絵を描くことと筆を振るうことが分業されないのと同じことです。

もし、問題を理解する人とコードを書く人が別々であれば、どれほど緻密な仕様書を作ったとしても、文脈の欠落や誤解が生じるのは避けられません。それは、診察する医師と執刀する医師が別人で、一度も対話がないまま手術を行うようなものです。現場の微細な違和感や、実装中に見つかるより良い解決策が、分業の壁によって捨てられてしまうのです。

コードを知らぬ者が描く「空飛ぶ絨毯」の危うさ

さらに言えば、多くのプロジェクトが失敗する原因は、コードを知らない人が計画を立てることにあります。

コードを知らなければ、どれほど華やかな理想を語っても、それを現実のソフトウェアとして着地させるまでの見通しを立てることができません。その結果、実現不可能なスケジュールや、現場の論理を無視した機能要件という「空飛ぶ絨毯」を設計することになってしまうのです。

また、動くソフトウェアという「具体」があるからこそ、初めて学び取れることがあります。頭の中にある想像のソフトウェアだけでは想定しきれなかったことが、ソフトウェアを動かしてみることで、本当に欲しかったものや解決したかったことが見えてくることなど、ざらにあります。

つまり、いかに早く動く状態にすることが大事で、そうして動くソフトウェアから学べたことを、またソフトウェアに反映させていくことで、事業や業務は少しずつうまくいくようになります。

分業をなくし、一貫して引き受けることで「伝言ゲーム」がなくなり、小さくても動くソフトウェアを早く手に入れることができます。この学習サイクルを、いかに高速に回すのかを考えたら、分業をしない方がよいのです。ソフトウェア開発者という職人は、問題の本質を掴むところからコードの一行までを一貫して引き受けるべきなのです。

視界を内包しながら広げる「ホロン構造」

では、ソフトウェア開発者の「成長」はどのように描かれるべきでしょうか。 多くの組織では、成長を「キャリアの階段」として描きます。プログラマからSEになり、やがて現場を離れてマネージャーになる。しかし、この階段モデルでは、上の階に登るたびに動くソフトウェアを作ること、今で言えば「コードを書く」という手段を捨てていくことになります。これは技芸の世界では「技の放棄」に他なりません。

技芸と捉えるソフトウェア開発者としての成長は、階段ではなく「ホロン構造」で描くべきだと考えています。ホロンとは、それ自体が全体でありながら、より大きな全体の一部でもあるという入れ子構造のことです。開発者の領域は、以下のように同心円状に広がっていきます。

成長とは、中心にあるコードを書く技術を捨てて外側へ移動することではありません。コードを書く技術をしっかりと保持したまま、その外側にある設計、要件、そして問題の本質へと、自分が責任を持てる「円」を大きく広げていくプロセスを指します。

最初のうちはコードを書くところから始まり、少しずつ責任を担う円を広げながらも、中心にあるコードへの手応えを失わない。この「包含しながらの拡大」も、熟達を測る尺度の一つなのです。

コードを手放してはならない4つの理由

では、なぜ上流工程に関わるようになっても、武器としての「コード」を手放してはならないのでしょうか。その理由は、以下の4つの論点に集約されます。

1. コードは動くソフトウェアの「唯一の真実」である

要件定義書や設計図は、あくまで人間の「願望」を記したものに過ぎません。ソフトウェアの世界において、厳密な論理として成立し、実際に動作するのはコードだけです。どのような工程も、コードを生み出すためにあるのです。

2. 「物理法則」を知らない設計は実現できない

建築家が素材の強度を知らなければならないように、ソフトウェアを作るにはコードという素材の特性（計算量、副作用、保守性、負債化のリスク）を知る必要があります。実装のリアリティを無視した上流工程は、非現実的な空論に陥ります。

3. 抽象化の深さは、具体の解像度に比例する

優れた抽象化は、複雑な現実をシンプルに整理することです。しかし、具体的なコードを知らない人間の抽象化は、単なる「中身のない言葉遊び」になりがちです。「具体」の圧倒的な蓄積があるからこそ、真に機能する「抽象」が生まれるのです。

4. 「AIの検収責任」はコードが書ける者にしか取れない

生成AIは、時として「もっともらしい嘘」をつきます。AIが生成したコードの脆弱性、データ保全性の欠陥、将来的な拡張性の有無を瞬時に見抜けるのは、コードの「手触り」を知る人間だけです。実装能力を捨てることは、AIが出した結果の品質保証を放棄することと同義です。

AI時代の職人に求められる「意思決定」と「最終責任」

プログラミングの領域が問題の本質にまで広がると考えるなら、「生成AIがコードを自動生成し、プログラミングの一部が代替される今、人間がコードを学び、書き続けることに意味はあるのか？」という問いが生まれます。

答えは、むしろ逆です。AIが台頭した今こそ、ホロン構造のすべてを理解した職人の価値は際立つことになります。AIにコードを書かせることは容易になりましたが、人間にしかできない決定的な役割が残されているからです。

円の中心にある「コーディング」という作業が代替されていく中で、人間の開発者の役割はより外側の円、つまり「意思決定」と「最終責任」に集約されていきます。

まず重要なのが、「意思決定」です。 開発の現場は常にトレードオフの連続です。「スケーラビリティを優先してユーザー体験を少し落とすか」「開発速度のためにセキュリティの構成をシンプルにするか」。AIは論理的な案を提示してくれますが、どちらを選ぶべきかという「意志」を持った判断はできません。

何を落として何を得るのか。その決断には、ビジネスの背景、ユーザーの感情、そして自分たちの美学を含めた、極めて人間的な判断が必要です。トレードオフを判断し、決断を下すことは、技術的な目利きにしかできない聖域です。

そしてもう一つが、「最終責任」を負うことです。 AIを使ってコードを生成しても、そのコードがトラブルを引き起こしたとき、AIが責任をもって問題を収束させることはありません。予期せぬ事故や障害が起きたとき、最後になんとかするのは人間でしかあり得ません。

「最後はどうにかなるようにする」という覚悟と、実際にそれを修復できる能力。AIを道具として使いながらも、その中身を深く理解し、万が一の事態を自分の腕一本で解決できることが求められます。

AI時代は、コードを深く理解した上で、設計やビジネスまで統合できるホロン構造の開発者の価値をより一層際立たせます。技術的な軸足を保ち、道具を使いこなす「職人」こそが、AI時代を生き抜く最強のプロフェッショナルなのです。

階段を登るのではなく、円を広げ続けるという生き方

ソフトウェア開発者の成長とは、役職が変わることでも、最新のフレームワークを網羅することでもありません。

• 練度（第1回の軸）： いかに精度が高く、美しい仕事ができるかという「密度」。
• 広さ（第2回の軸）： どの大きさの円まで責任を持って問題を捉えているかという「領域」。

できることの品質を高めること、できることの幅を広げること。この二つの軸を伸ばし続けることが、技芸としての成長です。

階段を登るのではなく、円を広げる。足元のコードを大切にしながら、視線を遠くの課題へと向ける。その姿勢そのものが、プロフェッショナルとしての誇りとなり、AI時代における唯一無二の価値となるのです。