どんなに完璧な人でもミス（失敗）しますよね？つまり、完璧な設計書を作るのはとても難しいのです。では、我々システム開発に携わる企業はどうすれば良いでしょうか。それは、ミスを減らす取り組みを行うことです。ある程度のミスは受け入れましょう。その中で、どれだけミスを減らせるかに焦点を当てることで、成功プロジェクトへ導けると考えています。本稿では「設計書のミスを減らすためには、どういったポイントに留意すればよいのか」について執筆させて頂きます。
※本稿では機械や建築の設計ではなく、システム（ソフトウェア）開発の設計書について記述しています。
設計工程のミスの種類とは
そもそも設計工程でなぜミスは起こるのでしょうか。私もたくさんのIT企業を見てきましたが、下記のような声をたくさん聞きます。
・設計書はシステムの完成後に作成する
・システムを引き継いだが設計書がなかった
・システムを引き継いだが設計書が古すぎて信用がない
・仕様変更時の影響範囲が設計書から判断がつかない
・設計書の修正漏れが多い
・設計書を、いつ/誰が/どこを修正したのかわからない
・設計者によってバラツキがある
・そもそもテンプレートが用意できていない
どうでしょうか。当てはまる項目はありましたか？一つずつ見ていきましょう。
設計書はシステムの完成後に作成する
「設計書はプログラマに見せるため」と定義した時に、システムの完成後に作成するのは矛盾していますよね？「エンドユーザへ見せるため」の位置付けだけであれば、後から作成したほうが、効率は良いですが、後から設計する人はプログラマでしょうか？また、プログラマの効率はどうでしょうか？テスト工程には影響はありませんか？デメリットの方が多いように感じます。そもそもしっかりとした設計書を作成できないことから「設計書はシステムの完成後に作成する」という思想になったのだと思います。
システムを引き継いだが設計書がなかった
こればかりは、最初にシステム開発に携わった人たちに依存しますが、最初から設計書を作成すれば誰も困りません。目先の成功だけではなく、運用・保守などの側面も考えると設計書が無いと後々の工数が大きくなってしまいます。なので、引き継いだ時点で設計書がなくても気づいたタイミングで既存の仕様を確認する目的も含めて設計書を作成しましょう。
システムを引き継いだが設計書が古すぎて信用がない
これも上記と同様ですが、ソースコードだけ最新になりがちです。人が書いたソースコードを追いかけるのは時間がかかります。ソースコードを修正した場合、必ず設計書にも反映させましょう。
仕様変更時の影響範囲が設計書から判断がつかない
ソースコードから仕様変更時の影響確認をする人は多いのではないでしょうか。もちろん動いているものが正なので、そうなると思いますが、これも設計情報の信頼性が下がっている事が原因だと考えます。プログラマが運用・保守フェーズも対応するのはあまり無いので、設計情報から判断ができると運用・保守面では圧倒的に工数が削減できます。
設計書の修正漏れが多い
一度、修正漏れが起きてしまうとその設計情報は信頼性を失ってしまします。一人で、設計・開発・テスト・運用・保守と行うのであれば、問題ないですが、システムが大きくなればなるほど、現実味がありません。あとで楽するためにも仕様変更時には、必ず設計書の修正から行いましょう。
設計書を、いつ・誰が・どこを修正したのかわからない
「いつ、だれが」といったところは昨今解決できてるかもしれませんが、従来通りExcelで設計を行っていると、どこに修正が入ったのか追えなくなっていませんか？バイナリファイルでの比較は難しいので、「どこを修正したか」に関しては修正者がしっかりと変更履歴などで記載しないと分からなくなってしまします。変更内容は細かく記載しましょう。
設計者によってバラツキがある
Excelなどで言うと、マクロなどを用いて、フォーマットを合わせようとしますが、ファイルが破損してしまうケースが多々あります。また、Excelに関しては使い慣れている人が多いので、徐々に自分流にカスタマイズしてしまうケースもあるのではないでしょうか。Aさんの設計書はしっかり作られているが、Bさんの設計書は情報が足りず、プログラミングできない。などが無いように統一感のある設計書を作成しましょう。
そもそもテンプレートが用意できていない
いわゆるフォーマットを定めるという事です。どこの企業もフォーマットは既にあるのではないでしょうか？でもそのフォーマット自体を見直したことはありますか？先駆者が作成したフォーマットはこれから作成する設計書にも利用できるのでしょうか？書かなくてもよい設計書はありませんか？情報が多ければ正というわけではありません。これが一番最初に取り組むべきことで、まずはテンプレートを用意しましょう。既にある場合は見直しましょう。テンプレートを用意しないで、取り掛かると必ず後戻りが発生します。軽視されがちですが、時間をかけてフォーマットを定める事がミス削減の近道といえるでしょう。
おわりに
少しでも御社の設計書作成のミス削減に活用できそうな気付きはございましたでしょうか。近年デジタルトランスフォーメーションの文脈で、多くの企業のIT投資は増加傾向にあります。プロジェクトの規模も大きくなり案件数も増える中で、安定的にプロジェクトを成功させるためには、開発効率を高めるだけでなく、ミスを減らす仕組みづくりが欠かせません。
今回は設計工程の記事を記載しましたが、設計工程と聞くと「開発するための前工程」と思いますよね？もちろん間違いではないのですが、運用・保守工程にも深く関係のある工程なのです。保守コストは今後より増大すると言われています。2018年に経済産業省が発表したDXレポートでは、このままシステムのブラックボックスが解消できない状態が続くと、2025年には保守コストは9割となり運用保守の人材不足問題や、開発言語や開発手法が多様化し次々と新しい技術が出現し、DXが推進できないことから国際競争力を失う問題が提起されています。いわゆる「2025年の崖」問題です。
また、エンジニアの需要が多く人材の流動性が高い環境では、仕組みを持たない中で全社的な標準を作成し、それをメンテナンスしていくことはとても困難だからです。だからといって何もしないままでは、いつまでもミスを減らすことはできません。いきなり完全を目指すのではなく、段階的に進めることが現実的な標準化のプロセスと考えます。
ソフトウェア開発は品質からスピードが求められる時代になったのは事実です。しかし、アジャイル手法だからと言って設計ドキュメントを作らなくて良いというわけではありません。「2025年の崖」の通り、システムのブラックボックス状態はユーザのデジタル変⾰の⼤きな⾜かせとなります。実際に膨大な保守コストが原因で、DXの実現が進まず国際的な競争力が失われているという実態があります。ユーザはこの失敗を忘れ、また同じことを繰り返すのでしょうか。そんなことはありません。⽬先のスピードを重視しつつも、長期的な成長を支えるための合理的な提案と組織をユーザは期待しています。このユーザの期待に応えられないベンダーは生き残れるのでしょうか。
これからもみなさまがユーザのみなさまに選ばれ続けるために、今こそ設計プロセスを見直していただきたいと切に願っております。
Object Browser 事業部
