ミスの少ない「筋の良い」設計書の書き方とは?

 2020.11.18  株式会社システムインテグレータ

どんなに完璧な人でもミス(失敗)しますよね?つまり、完璧な設計書を作るのはとても難しいのです。では、我々システム開発に携わる企業はどうすれば良いでしょうか。それは、ミスを減らす取り組みを行うことです。ある程度のミスは受け入れましょう。その中で、どれだけミスを減らせるかに焦点を当てることで、成功プロジェクトへ導けると考えています。本稿では「設計書のミスを減らすためには、どういったポイントに留意すればよいのか」について執筆させて頂きます。

※本稿では機械や建築の設計ではなく、システム(ソフトウェア)開発の設計書について記述しています。

設計工程のミスの種類とは

そもそも設計工程でなぜミスは起こるのでしょうか。私もたくさんのIT企業を見てきましたが、下記のような声をたくさん聞きます。

・設計書はシステムの完成後に作成する
・システムを引き継いだが設計書がなかった
・システムを引き継いだが設計書が古すぎて信用がない
・仕様変更時の影響範囲が設計書から判断がつかない
・設計書の修正漏れが多い
・設計書を、いつ/誰が/どこを修正したのかわからない
・設計者によってバラツキがある
・そもそもテンプレートが用意できていない

どうでしょうか。当てはまる項目はありましたか?一つずつ見ていきましょう。

設計書はシステムの完成後に作成する

「設計書はプログラマに見せるため」と定義した時に、システムの完成後に作成するのは矛盾していますよね?「エンドユーザへ見せるため」の位置付けだけであれば、後から作成したほうが、効率は良いですが、後から設計する人はプログラマでしょうか?また、プログラマの効率はどうでしょうか?テスト工程には影響はありませんか?デメリットの方が多いように感じます。そもそもしっかりとした設計書を作成できないことから「設計書はシステムの完成後に作成する」という思想になったのだと思います。

システムを引き継いだが設計書がなかった

こればかりは、最初にシステム開発に携わった人たちに依存しますが、最初から設計書を作成すれば誰も困りません。目先の成功だけではなく、運用・保守などの側面も考えると設計書が無いと後々の工数が大きくなってしまいます。なので、引き継いだ時点で設計書がなくても気づいたタイミングで既存の仕様を確認する目的も含めて設計書を作成しましょう。

システムを引き継いだが設計書が古すぎて信用がない

これも上記と同様ですが、ソースコードだけ最新になりがちです。人が書いたソースコードを追いかけるのは時間がかかります。ソースコードを修正した場合、必ず設計書にも反映させましょう。

仕様変更時の影響範囲が設計書から判断がつかない

ソースコードから仕様変更時の影響確認をする人は多いのではないでしょうか。もちろん動いているものが正なので、そうなると思いますが、これも設計情報の信頼性が下がっている事が原因だと考えます。プログラマが運用・保守フェーズも対応するのはあまり無いので、設計情報から判断ができると運用・保守面では圧倒的に工数が削減できます。

設計書の修正漏れが多い

一度、修正漏れが起きてしまうとその設計情報は信頼性を失ってしまします。一人で、設計・開発・テスト・運用・保守と行うのであれば、問題ないですが、システムが大きくなればなるほど、現実味がありません。あとで楽するためにも仕様変更時には、必ず設計書の修正から行いましょう。

設計書を、いつ・誰が・どこを修正したのかわからない

「いつ、だれが」といったところは昨今解決できてるかもしれませんが、従来通りExcelで設計を行っていると、どこに修正が入ったのか追えなくなっていませんか?バイナリファイルでの比較は難しいので、「どこを修正したか」に関しては修正者がしっかりと変更履歴などで記載しないと分からなくなってしまします。変更内容は細かく記載しましょう。

設計者によってバラツキがある

Excelなどで言うと、マクロなどを用いて、フォーマットを合わせようとしますが、ファイルが破損してしまうケースが多々あります。また、Excelに関しては使い慣れている人が多いので、徐々に自分流にカスタマイズしてしまうケースもあるのではないでしょうか。Aさんの設計書はしっかり作られているが、Bさんの設計書は情報が足りず、プログラミングできない。などが無いように統一感のある設計書を作成しましょう。

そもそもテンプレートが用意できていない

いわゆるフォーマットを定めるという事です。どこの企業もフォーマットは既にあるのではないでしょうか?でもそのフォーマット自体を見直したことはありますか?先駆者が作成したフォーマットはこれから作成する設計書にも利用できるのでしょうか?書かなくてもよい設計書はありませんか?情報が多ければ正というわけではありません。これが一番最初に取り組むべきことで、まずはテンプレートを用意しましょう。既にある場合は見直しましょう。テンプレートを用意しないで、取り掛かると必ず後戻りが発生します。軽視されがちですが、時間をかけてフォーマットを定める事がミス削減の近道といえるでしょう。

 

いかがでしたでしょうか。少しでも御社の設計書作成のミス削減に活用できそうな気付きはございましたか。近年デジタルトランスフォーメーションの文脈で、多くの企業のIT投資は増加傾向にあります。プロジェクトの規模も大きくなり案件数も増える中で、安定的にプロジェクトを成功させるためには、開発効率を高めるだけでなく、ミスを減らす仕組みづくりが欠かせません。しかしながら開発ドキュメントを標準化し、設計段階のミスを減らすことは多くの企業が必要性を感じているものの、なかなか実現できていません。なぜなら、開発言語や開発手法が多様化し次々と新しい技術が出現し、またエンジニアの需要が多く人材の流動性が高い環境では、仕組みを持たない中で全社的な標準を作成し、それをメンテナンスしていくことはとても困難だからです。だからといって何もしないままでは、いつまでもミスを減らすことはできません。いきなり完全を目指すのではなく、段階的に進めることが現実的な標準化のプロセスと考えます。

Object Browser 事業部

新規CTA

新規CTA
新規CTA

RELATED POST関連記事


RECENT POST「設計書の書き方講座」の最新記事


この記事が気に入ったらいいねしよう!
新規CTA
ブログ購読のお申込み

RANKING人気資料ランキング

RANKING人気記事ランキング

RECENT POST 最新記事

ITだけCAD使ってない不思議