もしその技術が伝わっていたら，こんな事態にはならなかった…。プロジェクト遅延やコスト超過，システム障害の発生など重大なトラブルの裏に，技術伝承の失敗が隠れていることが少なくない。伝えるための地道な努力を惜しんではならない。
技術の断絶が現場力の低下を招いているのではないか――。この思いから本特集を企画した。背景には，ある若手技術者の言葉がある。
「IT業界は技術の変化が早いでしょう。伝承しようと思ったときに，その技術は陳腐化している。だから，ベテラン技術者が自信をなくしてしまった。おかげで，彼らから僕らは何も伝えられていないんです」。
ものづくりの現場や伝統芸能の世界では，昔から技術伝承が大きなテーマだった。だが，歴史の浅いIT業界では「どんな技術を伝承すべきなのか」「どうやれば伝承できるのか」「そもそも技術は伝承できるのか」といったことが，議論されたことも検証されたこともほとんどない。あなたの周りではどうだろう。
折しも団塊の世代の引退が始まる“2007年問題”を契機に，ITの現場でも「ベテランが持つ技術をいかに残すか」が語られ始めている。団塊の世代に限らず，先輩から後輩へ，前任者から後任へ，伝承の場はいくらでもある。そこでは，何がどうやって伝承されているのだろう。あるいは何も伝承されていないのか。それで支障はないのだろうか。
そんな問題意識から，取材をスタートした。取材してみると，技術の断絶に起因すると思われる身近なトラブル事例がいくつも出てきた。技術をうまく伝えていれば回避できたものばかりだ。トラブルに遭った当事者たちは「そんなことは教えられていませんでしたよ」と口をそろえる。ITの現場にも，伝承すべき技術は確かにありそうだ。
CASE1：なぜ教えた通りにやらない
ヒアリングに漏れ。採算割れに
「教えたはずなんだがなぁ…」。
ソフトウエア・ベンダーに所属する二谷幸彦氏（仮名）は，業務パッケージ導入プロジェクトでの部下の失敗を悔やんでいる。
二谷氏は，フィールドSEのリーダー。顧客の要望を把握し，それを自社製ERPパッケージを用いて実現する。
問題の案件は，そのERPパッケージを使用するユーザーのシステムを，金融商品取引法（日本版SOX法）に対応させるため，機能改変するものだった。仕様書などのドキュメントは作られていなかった。初期導入した際のプロジェクトは時間に追われドキュメントの作成が後回しになった上に，その役割を担っていたスタッフが次々に異動・転職したためである。
多忙な現場ゆえ，人手が足りない。ある部下にヒアリングを任せたのが失敗だった。その部下は入社8年目。そろそろ独り立ちして，小さなグループを率いてもおかしくない時期だ。だが，彼の要件定義には重大な漏れがあった。その結果，プロジェクトが迷走し，採算割れを起こしてしまった。
ユーザーを洗い出す技術が伝わらず
二谷氏の部下は，ユーザーにヒアリングして，導入時にERPパッケージに施したカスタマイズ内容と，今回改変する機能の要望を仕様書としてまとめた。それに基づいて，開発スタッフが実装作業を進めた。実装が終わった段階で，ユーザーに検収を求めた。
結果は「NO」だった。改変後のシステムは，仕様書の内容を満たしてはいたものの，必要な例外処理が抜け落ちていた。
「どういうことなんだ！？」。順調だと思っていた二谷氏にとって検収段階でのダメ出しは予想外。明らかになった原因は，部下が実施したヒアリング方法だ。ヒアリングの対象者に漏れがあった。一度も打ち合わせに来ていない部署にもユーザーがいたのである。これでは，そのユーザーの要望を取り込みようがない。
二谷氏の部署では，潜在ユーザーを洗い出すため，ユーザー企業のオフィス・レイアウト図をマーキングするなどの手法を用いている。「半年前に実施した部の勉強会で，潜在ユーザーを探すことの重要性を説いていた。そのやり方も一通り説明していた」（二谷氏）。しかし，二谷氏の部下は徹夜明けでその勉強会に参加したことから身が入らず，勉強会の内容が記憶に残っていなかったという。
最終的に，2人月と見積もっていた開発工数が，手戻りにより3.5人月に膨らむ。赤字プロジェクトに陥ってしまった。
