設計書をなぜ作るのか ~エンジニアが初心に帰り自戒する~

初めまして。株式会社シー・エス・エス、ファイナンシャル・ソリューション開発部のこじこじです。
普段は証券系のシステム開発のプロジェクトに携わっております。

唐突ですが昨年11月に発生したボイジャー1号の通信トラブルのニュースはご存じでしょうか?同機から送られてくるバイナリコードが意味をなさない状態で送られてくるようになったというトラブルです。この問題に対処するためボイジャー1号に対してコマンド入力が必要になったのですが、そのコマンド自体がどの様な影響を与えるのか調べるために打ち上げ当時のエンジニアが書いた資料を参照して対応を模索しているという内容でした。

そんな宇宙規模の話とはスケールが小さくて恐縮ですが、私は昨年は新NISA、今年は東証のarrowhead更改の対応を担当しています。その調査にあたり10年以上前に自分達で作成した設計書を目にしたのですが、説明が足りない、ソースコードと記載内容が一致しないなど、当時の設計書の内容に頭を抱えることがしばしばありました。作成者やレビュー者の名前を見ると自分の名前が記されています。「過去の自分は赤の他人」と痛感した瞬間でした。という事で今回は初心に戻りかつ自戒の意味も込めての設計書のお話です。


1.設計書を作る目的とは

(1)完成イメージの共有

どの様な機能を有しているのか可視化し、要件定義に基づき機能の抜け漏れが無いか、また妥当性を有しているかの確認をするのに用います。要件定義者やユーザなどと認識共有を図るためのものでもあり、また時としてテストケース作成の土台にもなります。

(2)プログラマーに対しての指示書

イメージした処理や機能を実現するためのプログラムを効率よくプログラマーに作成してもらうための指示書にもなります。認識違いによる齟齬や手戻りが発生しないよう、なるべくプログラマーに分かりやすく作成する必要があります。

(3)将来の保守、運用のための引継ぎ資料

システムは作って終わりではなく、リリース後も保守・運用が続いていきます。システム開発当事者がその後も保守・運用するとは限らず、別の人が担当することの方が大半です。問い合わせや障害対応、システムの刷新等で影響調査する際に、一からソースコードの解析を行うのは効率が悪すぎます。その際に整備された設計書があれば、アタリをつけたり調査を効率的に進めることができます。またメンテナンスの履歴に不具合の情報が記載されていれば、同様の問題を回避するためのヒントにもなります。


2.現場で感じている課題・問題点

設計・調査フェーズで既存処理に意図不明の処理Aがあったとします。その際に過去に作った設計書を辿ることになりますが、残念ながら以下のようなケースが割と発生します。

 ・処理Aの記載が何処にもない
 ・処理Bから処理Aに変更した事は記載されているのに背景・理由は一切書かれていない
 ・処理Aの内容についてソースコードと設計書の内容が一致しない

こうなるとソースコード解析や他の処理に範囲を広げての調査が必要になり工数もどんどん嵩んでいきます。こういった問題が発生する原因の一つに、前述した1-(3)の目的を意図しての要件の記載不足や仕様変更時の修正漏れが挙げられます。実際プロジェクトが佳境に入りスケジュール優先になると、作成済みの設計書の修正・管理が疎かになりがちです。特に大きなプロジェクトだと設計書の数も膨大になり、要件や仕様変更等で発生した事象を上流~下流工程までの設計書に一貫性を持たせて加筆修正していくのが難しいのは事実です。それが複数部署に跨る案件だと猶更です。しかし構築したシステムを長く維持し効率的な運用を図ろうとするのであれば、プロジェクトの締めとして設計書を全て最新の状態に整えるタスクは最低限必要であるし、設計書作成時に将来の保守を見据えた書き方をすべきであると考えます。

関連記事

blog.css-net.co.jp
blog.css-net.co.jp

3.最後に...ボイジャー1号のその後

さて、話題を振って放り投げたままのボイジャー1号のその後のお話です。NASAの研究チームで対応を進めた結果、今年3月にとあるコマンドを入力したところ、それまでとは違った信号が返されたそうです。そこから更に解析を進め、4月にデータの一部を正常に送信することが可能になり、6月時点で完全復旧したとの事。復活の背景には担当エンジニアの並々ならぬ労力があったのは勿論ですが、1970年代に作られた当時の資料を残し整備していた事も無視できないと思います。
このニュースを知った時、過去の成果物で50年先のシステムを救うんだなとちょっと感動したものです。少々オーバーですが、後で直そうとして修正漏れした記載や、この説明は不要かな…と省略した部分が数年後の誰かを救うのかもしれません。開発・テストに比べて疎かになりがちな設計書の作成・整備ですが心を入れ替えて作成・レビューしていかなくては、と考えたのでした。


\システム開発なら、株式会社シー・エス・エスへ/

4.この記事を書いた人


【ニックネーム】:こじこじ
【経歴】:入社二十云年目。証券系システム一筋です。
【一言】:先日、東博で開催されたはにわ展行ってきました!ずっと楽しみにしていたはにわ展でしたので、振休を使って初日朝から行くことができ嬉しかったです。開館前から結構人が並んでいてびっくりしました。