あなたの周りに，この人はすごいというエンジニアはいないだろうか。「バグのありかをピタリと言い当てる」「製品や技術の選択を誤らない」「あざやかな手並みでプロジェクトを立て直す」---システム構築はその人を中心に回っている，誰もがそう認めるような人物だ。しかし，そんなデキル人ほど引く手あまた。その人が現場を離れるとき，持っている技術を誰かに残していくことができるのだろうか。
システムの構築，運用に求められる技術は幅広い。いわゆる上流工程においては，要件定義や見積もりにはじまり，製品・技術の選定，アプリケーション設計などの技術が求められる。プログラミングやデバックの巧拙はシステムの品質に直結するだろう。カットオーバー後の運用保守も，欠かせない技術だ。
技術は通常，個々の現場で先輩から後輩へと伝えられる。後輩は，先輩の後について技術力を磨く，現場で自分の力を試す，先輩にアドバイスをもらう---このようなサイクルのなかで技術は受け継がれていく。うまく伝えなければ失われてしまう。
そうした危機感から，企業が技術伝承に本腰を入れ始めた。プロジェクトの「完了報告書」をきちんと作り，次のプロジェクトに生かそうという事例が増えていることはその一端。製品・技術や開発プロセスなどを標準化する動きは，伝承の難しさの裏返しとも言える。
筆者は，すべての技術を伝承できるとは考えていない。現場では，ときに「直感」や「ひらめき」としか言いようがない能力が示されることがある。もちろん，この直感は，技術を積み重ねたところに現れる。例えばトラブル・シューティング。システムの隅々に理解が行き届き，日々の運用状況に目配りしているからこそ，トラブルが生じたときに誰よりも早くその原因にたどり着けるのだ。この技術は伝えることが難しい。
では，伝えられる技術とは何なのだろう。そして，どう伝えればよいのだろう。「日経SYSTEMS」では「技術伝承」のノウハウを掘り下げる特集記事を掲載する予定だ。記事を書くに当たり，ITpro読者の皆様の力をお借りできないかと考えている。アンケート回答サイトで，技術伝承の実態についてアンケートを実施している。ぜひ読者の体験を教えていただければ幸いである。
