日本版SOX法・徹底解析

もしその技術が伝わっていたら，こんな事態にはならなかった…。プロジェクト遅延やコスト超過，システム障害の発生など重大なトラブルの裏に，技術伝承の失敗が隠れていることが少なくない。伝えるための地道な努力を惜しんではならない。

http://itpro.nikkeibp.co.jp/article/COLUMN/20090128/323699/?ST=system

　技術の断絶が現場力の低下を招いているのではないか――。この思いから本特集を企画した。背景には，ある若手技術者の言葉がある。

　「IT業界は技術の変化が早いでしょう。伝承しようと思ったときに，その技術は陳腐化している。だから，ベテラン技術者が自信をなくしてしまった。おかげで，彼らから僕らは何も伝えられていないんです」。

　ものづくりの現場や伝統芸能の世界では，昔から技術伝承が大きなテーマだった。だが，歴史の浅いIT業界では「どんな技術を伝承すべきなのか」「どうやれば伝承できるのか」「そもそも技術は伝承できるのか」といったことが，議論されたことも検証されたこともほとんどない。あなたの周りではどうだろう。

　折しも団塊の世代の引退が始まる“2007年問題”を契機に，ITの現場でも「ベテランが持つ技術をいかに残すか」が語られ始めている。団塊の世代に限らず，先輩から後輩へ，前任者から後任へ，伝承の場はいくらでもある。そこでは，何がどうやって伝承されているのだろう。あるいは何も伝承されていないのか。それで支障はないのだろうか。

　そんな問題意識から，取材をスタートした。取材してみると，技術の断絶に起因すると思われる身近なトラブル事例がいくつも出てきた。技術をうまく伝えていれば回避できたものばかりだ。トラブルに遭った当事者たちは「そんなことは教えられていませんでしたよ」と口をそろえる。ITの現場にも，伝承すべき技術は確かにありそうだ。

CASE1：なぜ教えた通りにやらない

ヒアリングに漏れ。採算割れに

　「教えたはずなんだがなぁ…」。

　ソフトウエア・ベンダーに所属する二谷幸彦氏（仮名）は，業務パッケージ導入プロジェクトでの部下の失敗を悔やんでいる。

　二谷氏は，フィールドSEのリーダー。顧客の要望を把握し，それを自社製ERPパッケージを用いて実現する。

　問題の案件は，そのERPパッケージを使用するユーザーのシステムを，金融商品取引法（日本版SOX法）に対応させるため，機能改変するものだった。仕様書などのドキュメントは作られていなかった。初期導入した際のプロジェクトは時間に追われドキュメントの作成が後回しになった上に，その役割を担っていたスタッフが次々に異動・転職したためである。

　多忙な現場ゆえ，人手が足りない。ある部下にヒアリングを任せたのが失敗だった。その部下は入社8年目。そろそろ独り立ちして，小さなグループを率いてもおかしくない時期だ。だが，彼の要件定義には重大な漏れがあった。その結果，プロジェクトが迷走し，採算割れを起こしてしまった。

ユーザーを洗い出す技術が伝わらず

　二谷氏の部下は，ユーザーにヒアリングして，導入時にERPパッケージに施したカスタマイズ内容と，今回改変する機能の要望を仕様書としてまとめた。それに基づいて，開発スタッフが実装作業を進めた。実装が終わった段階で，ユーザーに検収を求めた。

　結果は「NO」だった。改変後のシステムは，仕様書の内容を満たしてはいたものの，必要な例外処理が抜け落ちていた。

　「どういうことなんだ！？」。順調だと思っていた二谷氏にとって検収段階でのダメ出しは予想外。明らかになった原因は，部下が実施したヒアリング方法だ。ヒアリングの対象者に漏れがあった。一度も打ち合わせに来ていない部署にもユーザーがいたのである。これでは，そのユーザーの要望を取り込みようがない。

　二谷氏の部署では，潜在ユーザーを洗い出すため，ユーザー企業のオフィス・レイアウト図をマーキングするなどの手法を用いている。「半年前に実施した部の勉強会で，潜在ユーザーを探すことの重要性を説いていた。そのやり方も一通り説明していた」（二谷氏）。しかし，二谷氏の部下は徹夜明けでその勉強会に参加したことから身が入らず，勉強会の内容が記憶に残っていなかったという。

　最終的に，2人月と見積もっていた開発工数が，手戻りにより3.5人月に膨らむ。赤字プロジェクトに陥ってしまった。

CASE2：技術とともに去りぬ

練習積み挑んだデモ。途中で止まる

　上田明氏（仮名）は小さなソフトウエア・ベンダーに勤務している。鉄道会社を顧客に持つ大手ソフトウエア・ベンダーからの各種サブ・システム開発請け負いが主な仕事。

　あるとき，列車運行管理システムに接続する各種設備をシミュレートするツールの開発を任された。難しい案件であったから，若くて元気のよい上田氏に白羽の矢が立ったのだ。

　ロジックに複雑な部分があったことに加え，バグの修正に手間取った。ツールが完成したのは，システム納品前に顧客が立ち会って行う監査直前のことである。元請け会社の担当者は，上田氏から受け取ったツールを試験用システムに組み込み，正しく動作することを確認した。

通信を制御する技術が伝わらず

　翌日，上田氏と元請け会社の担当者は鉄道会社に出向く。持参したシステムを運用機となるサーバーにインストールして，デモンストレーションを始めた。事前に予行演習をしていたこともあって，デモはよどみなく進んだ。ところが，あるボタンをクリックしたところで，システムがフリーズしてしまった。

　上田氏と元請け会社の担当者は，鉄道会社に平謝りし，カットオーバーに支障が出ないよう早急に対処することを約束した。上田氏と元請け会社の担当者は運用機となるサーバーを持ち帰って，原因を調べた。結局，上田氏が開発したシミュレーション・ツールと，サーバーにインストールされていたイーサネットの通信ミドルウエアとの間で，UDPポートが競合し，通信できなくなっていたことが分かった。

　なぜ，こんなことになったのか。

　実は，その分野に経験豊富な先輩の技術者が前月末に退職してしまっていた。「UDPポートなどリソースの競合をどうすれば回避できるのかが，よく分からなかった。でも社内の誰にもその先輩の技術が引き継がれていなかった。詳しい人が誰もいない。独力でなんとかしようと頑張ったが，こんなことになってしまった」（上田氏）。

CASE3：バトンはどこに行った

暴走を止められず。テストで噴火

　SIベンダーに勤める山田洋一氏（仮名）は，全プロジェクトを横断する形で運営を側面から支援する，プロジェクト・マネジメント・オフィス（PMO）のリーダーである。ある基幹システム構築プロジェクトが，テスト段階で火を噴いた。テストが遅々として進まず，結果的にそのシステムのリリースが半年程度遅れるという事態が生じた。そのプロジェクトを率いていたのは，経験の浅い若手プロジェクト・マネージャ（PM）である。

　山田氏は「PMOにはPMを育成する役割もあるのだが，プロマネの技術は人を扱うスキルなだけに伝承するのが難しい」と振り返る。

　そのプロジェクトは，上流工程でちょっとした遅延があった。PMはそれを取り戻そうとメンバーに声を掛けたが，思うように動いてくれない。思惑通りに遅れを取り戻すことができなかったPMは，結局，単体テストおよび結合テストの大部分を割愛することにした。ただし，その後に実施するシステムテストは簡略化せず，当初の計画通りに一連のテストを数回実施する。システムテストさえ綿密に実施すれば，成果物の品質を確保できると踏んだのである。

現場を調整する技術が伝わらず

　システムテストを始めた段階で，一連のテストを続けて実施しようにも，それができないほど致命的な問題が個々のテストで見つかった。原因が単体テストや結合テストなど先行テストがきちんと実施されなかったことにあるのは明白だった。

　結局，単体テストや結合テストに準じたテストの実施を余儀なくされた。事前準備をしていなかったために時間を要し，テストが終了した段階で，カットオーバーが遅れることが確実になった。

　「後工程になるほどバグの修正工数が増大する」「単体テストや結合テストの省略は開発工数の削減にはつながらない」。ソフトウエア技術者にとっては常識とも言えるセオリーだが，PMはこのセオリーを使いこなせなかった。

　PMはテスト担当者のミスをリカバリーすることにも失敗した。システムテストを再開した直後，さらに大幅な工数の超過が明らかになった。テスト担当者が「データ日次入力→週次集計→閲覧→月次集計→変更→年次集計」といったシナリオに沿ってテストを設計したときに，各テスト・ケースの間に強い依存性を持たせてしまったことが原因だった。これにより，一連のテストを途中から実施することができなくなってしまったのである。

　例えば，テストの途中でデータベースが壊れるなどの問題が発生したとき，テストを途中から再実行できず，最初からやり直すことになる。途中から再実行可能なテストを設計する必要があったのだが，テスト担当者はそうした認識を持っていなかった。結局，山田氏が指示を出してテストのベテラン・エンジニアをプロジェクトに暫定派遣し，テスト設計をやり直させた。

　ようやくシステムテストが軌道に乗ったものの，今度はテスト担当者がテスト・サイクルの途中で無計画にテストを追加してしまった。良かれと思って追加したものだが，新たなテスト・サイクルに入るたびに新規のバグが見つかる。いつまでたってもバグ収束曲線に収束の兆しが表れない事態に陥った。テスト担当者がテスト・サイクルを繰り返すことの意義を理解せぬままテストを実施したことによって，戦略的な品質向上が一切期待できなくなったのである。

　上流工程でメンバーをうまくコントロールできなかったPMは，事の成り行きを見守るしかなかった。本来はテスト担当者が暴走しそうになったとき，PMはそれに気づき，対処すべきであった。「現場を調整するのもPMの技術の一つ。この反省を基に，しっかり指導していきたい」（山田氏）。

　三つの事例では，当事者たちの技術力不足がトラブルを招いている。酷な言い方になるが，ほとんどが技術を持った人なら防げたものばかりである。

　では，その技術とは何か。三つの事例から拾うなら「ユーザーを洗い出す技術」「通信を制御する技術」「現場を調整する技術」――。多くが，案件をこなす中で蓄えられてきた「勘」や「経験」に基づくものだと気づくだろう。IT業界は技術の変化が早い。だが，現場で鍛えられた勘や経験はいずれもそう簡単に陳腐化するものではない。

　取材ノートをひっくり返してみれば，同じように技術が伝達されてさえいれば防げたであろうトラブルがいくつも見つかる。本特集では伝承すべき技術を「上流工程」「実装/運用」「プロマネ」という三つの分野に整理し，勘と経験の残し方を探った（図1）。

図1●伝承すべき技術の例

「上流工程」「実装/運用」「プロマネ」――業務遂行に必要な技術が伝承されなければ，障害や事故が発生する危険性が高まる

[画像のクリックで拡大表示]

　取材を終えた今，IT業界で伝えるべき技術はあるかという疑問に答えるなら，次のようになる。「伝えるべき技術はあるし，その技術は伝えられる」。