設計書作成について書きたいと思う｜現場で気づいた本当に大切なこと|システムエンジニア
とてぃです。
なぜこのようなタイトルで記事を書こうと思ったのか――それは、新人時代の自分の考え方に大きな間違いがあったことに気づいたからです。
新人時代の「間違い」
具体的にどこが間違っていたのか？
それは「設計書はプログラム実装と同時進行で、後から付け足せばいい」という考え方でした。
理由は、工数や納期の都合で設計書作成に十分な時間を割けず、「後で処理を書き足せばいい」と思い込んでいたからです。
某SIer社でよくある現場の“あるある”かもしれません。
このやり方にも一理はありました。実際に手を動かしてプログラムを書くことで、業務ロジックが自然と頭に入ってくるというメリットもあったのです。
でも現状、何が問題なのか？
設計フェーズで、必要なフラグや既存の動きを、プログラム言語やシステム仕様に合わせてしっかり設計できていたか？――答えは「できていなかった」のです。
設計書が不十分だと、後工程（実装・テスト・保守）で手戻りやトラブルが発生しやすくなります。
また、他のメンバーや後任が内容を理解しづらくなり、チーム全体の生産性や品質にも影響します。
解決策は？
答えはシンプルです。
設計書を書くなら、実際に実現できるかプロトタイプやサンプルを作ってから書くこと。
- 設計書を作成する際は、実際にロジックや画面を試作し、足りない処理や改善点を洗い出す
- プロトタイプで動作確認しながら、設計書をブラッシュアップする
- 「実装できる設計書」＝「誰が読んでも分かりやすく、実際に動くもの」を意識する
とある先輩に「設計書は実現できるかを試してから書くべき」と言われ、まさにその通りだと実感しました。今まで「実装できるか」を十分に検討せずに設計書を書いていたことを反省しています。
設計書作成のコツ・ベストプラクティス
- 要件・仕様を正確に整理：曖昧な部分は早めに関係者に確認
- プロトタイプやサンプルで動作検証：設計と実装のギャップを減らす
- 設計書は「誰が読んでも分かる」レベルで書く
- 設計書と実装をセットで見直す：手戻りやバグを減らす
- レビューやフィードバックを積極的に活用
まとめ
- 設計書は「実装できるか」を意識して作成することが大切
- プロトタイプやサンプルを活用し、設計と実装のギャップを減らそう
- 設計書作成は、後工程の品質やチームの生産性にも直結する
以上のことを踏まえて、改めて設計書作成の大切さを考える時間になりました。
最後まで読んでいただきありがとうございました。