技術は何を引き継ぐのか ── 技術継承（後編）：AI時代に見えてきた「観点」の価値 ──
※前編はこちら
「技術が伝わらないのはなぜか ── 技術継承（前編）：なぜ技術が現場に残らないのか ──」
前回のコラムでは、成果物だけでは技術は継承されず、判断の理由や背景を残すことが重要であると述べました。
では、その判断の理由や背景とは何なのでしょうか。
最近、様々な場面で生成AIを使うようになって、私はその答えが少し見えてきたように感じています。
AIは知識や答えを提示してくれます。しかし、その答えを評価するために何を見るべきか、どこを疑うべきかまでは教えてくれません。
だからこそ私は、技術継承で本当に引き継ぐべきものは、知識そのものではなく「判断軸」なのではないかと考えるようになりました。
今回は、AIとの関わりを通して見えてきた技術継承の本質について考えてみたいと思います。
AIが見せてくれたもの
生成AIに対しては、
- なぜその答えになったのか分からない
- 結果が変わることがある
- 品質を保証しにくい
といった声を耳にします。
確かにその通りです。
しかし考えてみると、私たちは人間の判断についても似たような状況を経験してきました。
レビューの場で、ベテラン技術者から
「その設計は危ない」
と指摘されることがあります。
その指摘は正しい場合が多いのですが、理由を聞くと、
「以前、似たような案件で問題になった」
「経験上、そのやり方はうまくいかないことが多い」
といった説明になることも少なくありません。
人間の判断もまた、完全に説明可能なものではありません。
AIによって新しい問題が現れたというより、これまでも存在していた「判断の根拠」という課題が見えやすくなったのかもしれません。
AIとの壁打ちで気付いたこと
私の周囲でも、生成AIを使う際に「壁打ち」という言葉をよく耳にします。
AIへ質問を投げ、自分の考えを整理しながら回答を改善していく使い方です。
実際、この方法は非常に有効です。
最初は曖昧だった考えが徐々に整理され、自分でも気付いていなかった論点が言語化されていきます。
しかし一方で、AIとの壁打ちを重ねて自信を持って提出した成果物が、レビューであっさり否定されることもあります。
むしろ、そのような経験の方が多いかもしれません。
なぜでしょうか。
それは壁打ちの出発点が常に自分だからです。
AIとの対話は、自分の考えを深めることには適しています。
しかし、自分が持っていない見方を発見することには限界があります。
壁打ちは思考を深くしますが、必ずしも広くしてくれるわけではないのです。
AIを使う中で私が強く感じたのは、良い答えを得るためには、良い知識以上に良い判断軸が必要だということでした。
技術継承におけるレビューの本当の価値
ここで改めてレビューの役割を考えてみます。
前回、レビューは本来技術継承の場であったと述べました。
現在のレビューは、記載漏れや規約違反の確認に重点が置かれることも少なくありません。
しかし本来の価値はそこだけではありません。
レビューの本質は、自分が持っていない見方と出会うことにあります。
例えば、
- 開発者は性能を見る。
- 運用担当者は障害対応を見る。
- 保守担当者は将来の変更容易性を見る。
- 利用者は使いやすさを見る。
それぞれ違う経験を持ち、違う切り口で成果物を見ています。
だからこそ、一人では気付けない問題が見つかります。
レビューについて議論する中で、
「開発メンバだけによるレビューには限界がある。運用担当者や品質保証担当者、利用者など、異なる立場の人が参加することで初めて見えてくる課題もある」
という考え方を耳にしたことがあります。
当時はその重要性を十分理解できていませんでした。
しかし今振り返ると、その本質は品質確認そのものではなく、多様な立場からの見方にあったように思います。
レビューとは誤りを探す活動だけではありません。
それぞれが持つ経験や着眼点を持ち寄り、自分一人では見えていなかった問題や課題に気付く活動でもあるのです。
技術継承のために判断の背景を残す
では、そうした見方や考え方をどのように残していけばよいのでしょうか。
必ずしも新しいツールや大掛かりな仕組みが必要なわけではありません。
例えば設計書やレビュー記録に、「理由・根拠」欄を設けるだけでも状況は大きく変わります。
多くのレビュー記録には、
- 指摘事項
- 対応内容
- 承認結果
は残っています。
しかし、
- なぜその方式を選んだのか
- どのような代替案を検討したのか
- 何を重視して判断したのか
といった情報は残らないことが少なくありません。
例えば、以下の記載例のように、理由・根拠を一言記録するだけでも、その価値は大きく変わります。
【記載例】
決定事項
Redisによるキャッシュ方式を採用
理由・根拠
非同期処理も検討したが、即時応答を優先するためキャッシュ方式を採用した。更新頻度が比較的低いことも判断材料とした。
後から参画した開発者は、採用された答えだけではなく、その背景にある考え方も理解できるからです。
もちろん、これだけで十分というわけではありません。
レビュー観点表やチェックシートを整備している現場は少なくありませんが、運用次第では単なる確認作業になってしまうこともあります。
確認項目を一覧化することと、その背景にある考え方を理解することは同じではないからです。
なぜその確認が必要なのか。
どのような失敗や経験から生まれたものなのか。
その背景まで共有されて初めて、本当の意味で技術継承につながります。
しかし、その第一歩は判断や考え方を言語化し、残していくことだと思います。
技術継承とは何を継承することなのか
前回のコラムでは、
「技術は成果物だけでは継承されない」
という話をしました。
今回さらに考えてみると、継承すべきものは知識やノウハウだけではないように思えてきます。
近年では、ソフトウェア開発に限らず、様々な分野でベテラン技術者や熟練工のノウハウをAIへ残そうという取り組みも進んでいます。
例えば設備保全の現場で、
「この音がしたらベアリング交換だ」
という熟練者の経験をAIへ学習させることは可能かもしれません。
しかし本当に価値があるのは、その結論だけではありません。
- なぜ異常だと判断したのか。
- 何を聞き分けていたのか。
- 他にどのような兆候を確認していたのか。
そうした判断の背景や着眼点まで残せて初めて、技術継承として意味を持ちます。
これはソフトウェア開発における設計判断とも本質的には同じです。
もちろん知識は重要です。
しかし知識だけでは、新しい問題には対応できません。
本当に価値があるのは、
- どのような前提を確認するのか
- 何を疑うのか
- どのような見方で捉えるのか
- どのように判断するのか
という考え方です。
つまり継承すべきものは、答えそのものではなく、それを導き出した判断の背景や見方なのではないでしょうか。
技術継承とは、次の世代が自ら判断できる状態を作ることです。
そのためには、結論だけではなく、
- なぜそう考えたのか
- どのような選択肢を比較したのか
- 何を重視したのか
を残していく必要があります。
まとめ
前回のコラムでは、技術継承が進まない原因を開発の構造という観点から整理しました。
今回のコラムでは、技術継承とは何を引き継ぐことなのかを改めて考えてみました。
AIとの対話や人とのレビューを通じて見えてきたのは、技術継承の本質は知識や答えを残すことではなく、判断軸を残すことだということです。
本当に重要なのは、何を見て、何を疑い、どのように判断するのかという考え方や観点を受け継ぐことです。
技術を残すとは何を残すことなのか。
もちろん、知識や答えを残すことは重要です。
しかし、本当に継承したいのは、それらを生み出した人たちの考え方や観点なのではないでしょうか。
次の世代が自ら考え、判断できるようになる。
技術継承の本質は、そのための土台を残すことにあるように思います。
おわりに
今回のコラムでは、技術継承の本質は知識や答えを引き継ぐことではなく、それらを生み出した判断の背景や観点を引き継ぐことにあるのではないか、という考えをお伝えしました。
しかし、判断の背景や観点は、単に「残そう」と呼びかけるだけではなかなか組織に定着しません。
実際には、
- レビューの場が形骸化している
- 判断理由が成果物に残っていない
- ベテランの知見が属人化している
- 技術継承を進めたいが、何から着手すればよいか分からない
といった課題を抱える組織も少なくありません。
当社では、開発プロセスやレビューの進め方、ナレッジ共有の仕組みづくりなど、技術継承を支えるプロセス改善をご支援しています。
「技術継承が人に依存している」
「ベテランの退職が近づき不安を感じている」
「AIを活用しながら知見を組織に残したい」
そのような課題をお持ちでしたら、ぜひご相談ください。
当社はプロセス改善の専門家として、技術継承が自然に行われる仕組みづくりをご支援します。
知識や成果物だけでなく、判断の背景や観点まで組織の資産として残せるプロセスを共に考えていきます。
（安部 宏典）