ドキュメントゼロのシステムを引き継いだとき

重要ポイント

• 状況: 資料なし・コメントなしのシステムを引き継ぎ
• 対応: コードを読み解くところから開始
• その後の変化: 「現状の可視化」を目的にした調査工程を必須化

Q. 実際に引き継いだとき、どうしたのですか？

A. 誰が、いつ、どんな意図でその部分を作ったのかを説明してくれる人はもういません。頼れるのはソースコードそのものだけで、まずコードを一行一行読み解いていくところから始めるしかありませんでした。想像以上に時間がかかる作業でしたし、途中で「これはなぜこうなっているのか」が分からず手が止まる場面も何度もありました。

Q. どういう部分で特に苦労しましたか？

A. 一見不要に見える処理が、実は特定のケースだけを想定した重要な分岐だった、ということが何度もありました。安易に消してしまうと別の場所で不具合が出るので、まず「動きを変えずに理解する」ことを徹底しました。

Q. そこから何を学びましたか？

A. 引き継ぎ案件では、いきなり修正や機能追加に着手してはいけないということです。それ以来、引き継ぎの依頼を受けたときは、最初に「現状を見えるようにする」ことだけを目的にした調査の工程を必ず設けるようにしています。何がどう動いているのか、どこにリスクが潜んでいるのかを地図として描き出してから、初めて次の判断に進みます。

Q. これは、どんな会社で起きやすい問題ですか？

A. 社内にシステムが分かる人が一人しかいない会社では、この「ドキュメントが無いまま引き継ぐ」事態がいつ起きてもおかしくありません。担当者が急に辞める、体調を崩す、といった予期しない出来事は、どの会社にも起こり得ます。

Q. 引き継ぎの調査工程には、だいたいどれくらいの時間をかけるのですか？

A. システムの規模によりますが、本格的な修正に入る前に、まとまった時間を調査だけに充てるようにしています。急いで飛ばしたくなる工程ですが、ここを省略すると、あとで何倍もの手戻りとして返ってくるというのが経験則です。