(1)大事なものが引き継がれない

  システムのバージョンアップと引継ぎが重なってしまった。新システム側は自分も設計に参加しているので経緯が分かるが,旧システム側の設定値の経緯が分からない。どういう経緯でそのパラメータが設定されたのかが分からずに,困ることがたびたび。テストで障害があって初めてパラメータが追加されていたことに気づくこともあった。
 幸いチームで動いているので,チームの他のメンバーに話を聞くと経緯が見えてくることがあった。それでも分からない時には,社内の技術部門に問い合わせて解決した。
 その後は,ドキュメントにできる限り背景や経緯をメモ書きしておくようにした。作った資料は社内で公開の場に置いて,自由に参照できるようにし,活用されるようにしている。
 このケースでは,“引き継がれなかったもの”に注目したい。ここで引き継がれなかったのは「パラメータの設定理由」である。どういう経緯でそのパラメータが設定されたのかが分からない状態で不用意に変えてしまうとデグレード(機能の後退や品質の低下)の恐れもある。調査に時間を取られ,パラメータを変更するだけでも,とんでもなく時間を食うことになる。


(2)必要な情報にたどり着くのが大変

 引き継ぎの書類が多い。全体像を把握するためにかなりの量を読まなければならなかったし,探すのが大変だった。その上,ベンダーが不誠実。こちらが知らないのをいいことに,都合の悪いことは隠し,問題が起きたときもこちらのせいにされそうになった。
 そこで,過去の書類のすべてに目を通した。議事録からマニュアルまで全部読んだ。こちらに原因があったケースもあることが分かり,ショックを受けたこともあった。結局,そのシステムの検討から開発の時間を経験しないと全体は把握できない。短期間で経験するには書類に埋もれるのも仕方がない。
 その後は,ものごとを決めるまでの経過,理由をできるだけ残すようにしている。「検討して決定した」とだけは書かない。
 この話からは「情報が残ってさえいればよいわけではない」ということが分かる。仮に必要な書類が残っていたとしても,量が膨大だったり検索性が悪かったりすれば,必要な情報にたどり着くことが困難になることを示唆している。


(3)問題は表面化していないだけ

 メインフレームで運用されていたシステムを引き継いだときに,ジョブネットもよく分からない状態だった。分かっているのは明らかに冗長なマスター情報。そのシステムの一部をリプレースすることになったが,どこをいじればいいか分からない。現行システムの解析にかなりの時間を取られた。
 そこで,メインフレームのJCLを解読して,ジョブネットを解析。フラグの更新など,どのようにすれば良いかプログラムを見ていくことで対応した。
 その後は,プログラム仕様書はもちろん,全体設計のポイントを分かりやすくドキュメントに残すよう心がけた。
 この話から読み取っていただきたいのは,問題が表面化する時期である。担当者は分からないなりにシステムを運用はできていたが,リプレースするときになって,どこをいじればいいか分からず,本来なら不要な時間を食ってしまった。何の支障もなくシステムを運用できていても,引き継ぎ問題は既に埋め込まれており,リプレースや保守開発のタイミングで噴出するのである。


(4)開発当時のドキュメントだけでは不十分

 ドキュメントがそろっていなかったり,修正が反映されていなかったりして,引き継いだシステムの内容と乖離している。そのため,改修に苦労した。システムの現状を示すドキュメントはあるが,どうしてそうしたかなど設計思想や設計方針がドキュメントに残っていないので,改修時に方針が決められず手間取った。
 そこで,前任者から思想などを聞き出し,文書化した。その後は,設計理由などもドキュメントに記述するようにしている。
 これは前述した「B.業務や技術が変質した量」の問題である。稼働後の修正がドキュメントに確実に残されているシステムはどれだけあるだろうか。さらに,設計思想や設計方針まですべてドキュメントに残している現場はまれだと思う。


(5)ベンダーからの納品物も一種の引き継ぎ

 インテグレータが開発したシステムを導入した。簡単なマニュアル(仕様)があっただけなので,日常的な使い方以外のトラブル・シューティングや改変の方法などが分からない。ただ,もし仮に詳しいドキュメントがあったとしても,OSなど基本知識・経験が自分には乏しいのでどうしょうもない。結局,何かあったときにはそのインテグレータにまた依頼するしかない。
 開発を外注した場合,納品されたシステムの中身を逐一理解するのは難しい。何かあればベンダーに頼らざるを得ない。さらに,ベンダー側にも当時の開発担当者がいなくなったり,ベンダーそのものが消えてしまったりして,どうにもならなくなったシステムも取材では見聞きしている。これも開発から保守/運用への引き継ぎがうまくいっていない一例と言えよう。


 情報システム部門に配属された新人は,基礎教育を受けた後,まずは既存システムの運用や保守を任されることになるだろう。ベンダーで働く技術者も,ユーザー企業が運用している既存システムとの連携を前提としない案件などほとんどない,ということを知っているだろう。既存システムからのマイグレーション案件も増えていると聞く。

 引き継ぎ問題は,こうした日常的なあらゆるシチュエーションで発生する。システムの引き継ぎに起因するシステム障害や失敗プロジェクトは少なくない。地味だがもっと注目されてよい問題と考える。