システム開発の設計書で重要なことは？
- フォーマット？
- レイアウト？
- フォント？
- 内容？
設計書のフォーマット・フォント・レイアウトは各会社では統一されている場合が多い
又、客先に指定されたフォーマット等を使用する場合もある
しかし、自社で使用するシステムを作る際の設計書は
フォーマットが決まっていない場合がある
先輩や同僚が以前に作成した物を利用したり、パクったりして作成する場合もある
オリジナルが良いという訳ではないし、パクることが悪いことではない（社内利用の場合に限る）
Web系のエンジニアだったり、デザインを重視するエンジニアに多い気がするが
レイアウトやフォントや配色に気を遣っている場合も多い
Excelを使用して、
シート名をお洒落な英語にしたり、内容の見出しにも英語を多用したりしている
しかし、最も重要な内容は、スカスカだったりする
システムの概要に図を用いていて、全体像を何となく把握することができるが
詳細部分に目を通すと、様々な箇所で疑問点・不足・漏れがある
設計書の目的は？
設計書を何の目的で書くのか？
設計書を誰に見せるのか？
設計書とは別に
課題票
や
Q&A表
と言ったファイルを作成し、質問事項を記載する
設計書より大事なことや重要なことがこのファイルに記述される
このような設計書では実際に物は作れない
設計書を見る
↓
物を作り始める
↓
疑問が出る
↓
質問・確認事項を記載
↓
打合せ
↓
解決
これを繰り返すのは仕方がないが、
繰り返す回数、そして頻度、内容が酷いと無駄な時間が発生し
不毛な打合せが繰り返される
結論の出ない、問題が解決しない打合せ
直接関係のない上司、部下が勢揃いで、1つ1つの質問・課題を解決していく
システム開発が終了し、テストの段階で不具合やトラブルが発生したのならともかく
製造の最初の段階からこのような事が繰り返されるとスケジュールも思うように進まない
自社で使うシステム開発に限らず
大手企業の設計者にも多く見られる
特に…
上流工程にしか携わらない
下流工程は外注するような企業に多く見られる
大雑把で適当な設計書を作り
どんぶり勘定の見積り、大雑把なスケジュールで外注にお願いする
請負で契約していればまだ良いが、
派遣契約で大手企業に常駐していたら最悪
言いたいことも言えず、
穴だらけの設計書に文句も言えず
課題表やQ&A票に記載し回答をもらう
なんのための設計書だろうか？
最後に
設計書はどうあるべきか？
どう書くべきか？
答えは1つとは限らないが…
実際に自分が物を作る立場になって、設計書を書くことに注意すべき
この設計書を見て、実際に物が作れるのか？
理想はプラモデルの説明書
多少の漏れ・不足は止む終えない
しかし、大幅な漏れがあったり
疑問ばかりで物が作れないことは絶対に避けるべき！
フォーマットや体裁は気にするな！
この記事へのコメントはありません。