技術が伝わらないのはなぜか ── 技術継承（前編）：なぜ技術が現場に残らないのか ──
ソフトウェア開発の現場で、近年よく聞かれるようになった言葉があります。
「若手が育たない」
「技術継承が進まない」
「同じ問題が、何度も繰り返される」
人材不足、教育不足、外注依存、技術の高度化など、
様々な要因が指摘されています。
しかし、それだけではこの問題の本質を説明することはできません。
その背景として、現場によっては、要求仕様書や設計書といったドキュメントが十分に整備・活用されていないケースが少なくありません。
形式上は存在していても、実際の開発では参照されず、「あるだけのドキュメント」になっている場合も見られます。
このような状況では、技術が継承されないのは当然とも言えます。
一方で、開発環境や開発プロセスが整備され、ドキュメントも一定程度整っているように見えても、
それが必ずしも「技術の理解」や「継承」につながっているとは限らないケースもあります。
では、なぜこのような状況が生まれているのでしょうか。
本コラムは前後編で構成しています。
前編では、技術継承が進まない要因を整理し、
後編では、AI時代も見据えた上で、どのようにこの課題に向き合うべきかを考えます。
本編ではまず、この問題を人材や教育の観点ではなく、開発の進め方やプロセスの運用という観点から整理します。
かつて、技術は「自然に」継承されていた
筆者がソフトウェア開発に携わり始めたのは、今から40年ほど前になります。
当時のソフトウェア開発現場では、一人の開発者がシステム全体に関わることは珍しくありませんでした。
要求分析から設計、実装、テストまでを一貫して担当することも多く、
自分が設計した内容がどのように振る舞い、どのような問題につながるのかを、
実感として理解することができました。
ここで重要なのは、当時の開発者が特別に優れていたということではありません。
システム全体の構造と因果関係が、個人の認知の中で把握できる範囲に収まっていた、という点です。
設計の意図や判断は、日常的な会話やレビューの中で説明され、暗黙のうちに共有されていきました。
結果として、技術は「教えるもの」であると同時に、「関わることで自然に身につくもの」として継承されていたと考えられます。
なぜ今は同じことができないのか
現在の開発現場では、この前提が大きく変わっています。
システムの大規模化・複雑化、機能単位への細分化、分業化の進展、派生開発の常態化――
こうした変化により、個々の開発者が関わる範囲は限定され、システム全体を見渡す機会は大幅に減少しました。
さらに近年では、実装の多くをサプライヤに委託し、自社は管理や調整を中心とするケースも増えています。
このような開発体制では、プロジェクトに関わっていても、技術的な判断そのものに直接関与する機会が限られます。
その結果、
自分の作業が全体のどこに位置付くのか分からない、
前提条件が共有されないまま作業が進む、
なぜその設計になっているのか説明できない、
といった状況が生まれています。
これは個人の能力に帰属させるべき問題ではなく、技術的な判断に関与しづらい開発の進め方やプロセスの運用のあり方によるものです。
文書はあるのに、技術継承が進まない理由
ドキュメントが十分に整備されていないこと自体が課題となるケースもありますが、それだけではこの問題は説明しきれません。
「昔と違って、今はドキュメントがあるはずだ」という指摘もあります。
確かに、要求仕様書や設計書、テスト仕様書といったドキュメントが整備され、形式上は揃っている現場もあります。
しかし、実際には十分に活用されていなかったり、
派生開発の積み重ねによって、全体像が見えにくくなっているケースも少なくありません。
ただし、こうした問題だけで、技術が継承されない理由をすべて説明できるとは言えません。
では、技術が継承されない本質的な理由はどこにあるのでしょうか。
その理由は次の点にあります。
文書には「何を作るか」は書かれている一方で、「なぜそうしたか」が十分に残されていないためです。
例えば、同じ性能問題に対して、
・キャッシュを入れる
・非同期処理にする
といった複数の解決策が考えられる場面で、
ここではキャッシュを採用したとします。
しかし、
・なぜそれを選んだのか
・なぜ他の選択肢は採用しなかったのか
といった前提が残っていなければ、後続の開発者はその判断を再度検討することになります。
その結果、同じ検討が繰り返され、知見は蓄積されません。
例えば設計書には、処理の流れやインタフェース仕様、状態遷移といった内容は記載されています。
しかし、
・なぜこの構成を選んだのか
・他の選択肢はなぜ採用されなかったのか
・どのような前提条件で判断したのか
といった設計判断の背景は、記録されないままになりがちです。
技術は成果物だけでは継承されません。
継承されるのは、設計判断の理由や前提が残っていてこそです。
どれだけ文書が整っていても、判断の理由や前提が残っていなければ、それは再利用も学習も難しくなります。
プロセスの中で、判断が十分に活かされていない
レビューはなぜ機能しなくなったのか
本来、レビューは技術継承において重要な役割を持っていました。
過去のレビューでは、
なぜこの設計にしたのか、前提条件は妥当か、他に選択肢はなかったのか、
といった判断そのものを問い直すことが重視されていました。
しかし現在では、記述の抜けや規約への適合、形式の確認といった観点に重きが置かれることが多く、
レビューは「品質確認の場」としては機能していても、
判断を共有・継承する場としては十分に機能していないケースが増えています。
つまり、決定結果は確認されていても、「なぜその判断に至ったのか」が共有されないまま進んでいると言えます。
その結果、判断は行われていても、それが技術として蓄積されにくくなっています。
まとめ
技術が継承されなくなった原因は、個々の努力や教育だけで解決できる問題ではありません。
現場によっては、そもそもドキュメントが十分に整備・活用されていないという課題を抱えているケースもあります。
そのような状況では、技術が継承されないのも当然です。
しかし、本質的な問題はそれだけではありません。
設計判断が十分に言語化・共有されず、それを残すことを前提として開発プロセスの中で扱われていないことにあります。
技術継承とは、単に知識を伝えることではなく、
設計判断を「どう残し、再利用できる形にするか」という問題です。
現在の開発は、「技術を蓄積する構造」というよりも、
「判断が残らないまま進む構造」になっている点に課題があります。
もし、
同じ議論が何度も繰り返される、
設計の意図が分からない、
全体像を掴みにくい、
といった状況がある場合、
それは、開発の進め方やプロセスの運用に起因している可能性があります。
この問題は、個々の工夫だけでは解決しにくく、開発の進め方そのものを見直す必要があります。
次回は、これからの開発において技術継承をどのように実現していくのか、
AIの活用も含めて、「判断をどのように扱い、残していくか」という観点から整理します。
（安部 宏典）