設計以外に書いておいた方がいいことってあるのかな？
こんにちは、古賀です！
本記事では、
上流工程を担当しているエンジニアの方向けに、
はてな
「基本設計書に書いておくと後々助かること」
について、お話します！
基本設計書は今からプログラムで作成するシステムやサービスを、
「どのような作りにするか？」
を書くことがメインです。
それにあることを書き足して、さらに良い基本設計書にしていきましょう！
そのあることとは、
ポイント
- 理由
- 使い方
- 変更点
この３つです！
この３つを書いておくことで、後々の工程で自分たちを助けてくれるはずです！
自己紹介が遅れましたが、
わたしは大学卒業後、上場IT企業に就職し、プログラマー、システムエンジニアとして
約１０年間働きまして、現在フリーランスをしております。
プロフィールの詳細はこちらです。
-
-
プロフィール
こんにちは、古賀正雄です。現在３６歳です。 簡単ではありますが、こちらのページで自己紹介とこのブログについてお話します。 高校時代 学生時代は主に野球をしていました。 進学先の高校も野球で選びました。 ...
続きを見る
基本設計がどのような工程なのかは、こちらの記事でお話しています。
-
-
システム開発における基本設計とは？基本設計書の成果物や進め方について
こんにちは、古賀です！ 今回は「基本設計」についてお話します！ システム開発プロジェクトは要件定義を終えると、 「基本設計」工程に移っていきます。 基本設計工 ...
続きを見る
※YouTubeに同内容を公開しております。
基本設計書に書いておいた方が良いこと①「理由」
基本設計書に書いておいた方が良いこと１つ目は、
「その設計にした理由」
です！
設計書は「決め事」だけを書きがちですが、その設計にした「理由」も書き加えておきましょう！
単純な例ですが、
「操作ミスを防ぐため、エラーチェックを追加する」
「作業を効率化するため、本処理で自動で処理されるようにする」
「○○さんから要望があったため、本処理を追加する」
このように理由を付け加えておきましょう。
「要件定義書」や「打合せ議事録」に既に書いてあるかもしれないですが、
それを毎回掘り返すのも手間ですし、大変です。
（わたしは何度かこの掘り返し作業をして、時間を無駄にしてしまいました。。）
基本設計書に書いておくことで、「設計」と「理由」が紐づくので確認作業が楽になります。
「理由」を書いておくメリットですが、
「詳細設計や開発時のミスを防ぐため」
です。
基本設計書を作成している時は、その設計にした理由はもちろん頭に入っているのですが、
プロジェクトを進めていくと、
「あれ？なんでこうしたんだっけ？」
と思うことが良くあります。
その理由を思い出せずに、詳細設計や開発作業をしてしまうと、
間違った設計にしてしまったり、バグを引き起こしてしまったり、
色々と考慮漏れが発生してしまいます。
また、後々機能の追加を行う場合も「理由」を書いておくことで、
「何ができなくなるのか？」
「どこに影響が出るのか？」
「この変更の仕方で良いのか？」
判断が付きやすくなります。
プロジェクトを進めていけば、ミスはつきものです。
ミスが起きても
「カバーできる状態にしておく」
ことが大事です。
そのために基本設計書に「理由」も書いておきましょう！
基本設計書に書いておいた方が良いこと②「使い方」
基本設計書に書いておいた方が良いこと２つ目は、
「画面や機能の使い方」
です！
基本設計には「作る内容」だけ書くのではなく、実際の「使い方」についても書いておきましょう！
「前後で使用する画面」
「実際に使う場面、タイミング」
「画面の操作の仕方、設定の仕方」
これらを書いておきましょう！
ただ別で後々「操作マニュアル」を作成する場合もあると思うので、
細かく書く必要はありません。
イメージを持たせる程度で良いかなと思います！
「使い方」を書いておくことで、
お客さんが実際に使う時をイメージして、確認することができます。
プログラムが実際にできあがった時に、
完成イメージとまったく違うものが出来上がってしまう可能性もかなり低くなります。
また、
「こういう風にした方がもっと良くなるのでは？」
という改善意見も出るようになりますし、
「この使い方でなるのであれば、あの画面でも対応が必要では？」
というように、先程の「理由」と同じように、ミスを防ぐことにも繋がります。
後で「操作マニュアル」を作る時の元資料にもなりますし、
「改善」、「ミス防止」のために「使い方」も書いておきましょう！
基本設計書に書いておいた方が良いこと③「変更点」
基本設計書に書いておいた方が良いこと最後３つ目は、
「現行システム、サービスとの変更点」
です！
「理由」、「使い方」を補足する内容になりますが、
今現在使っているシステムやサービスの作り直し、リプレースであれば、
「現行システム、サービスとの変更点」も書いておきましょう！
「これから作るシステムやサービスと関係ないから」
と言って、旧仕様のことは書きたがらない人もいますが、
お客さんによりイメージを持ってもらったり、
後工程で役立つ情報であれば書いておくことをオススメします！
お客さんからテスト工程や操作説明の段階で、
「今は出来ているのに、ここができていないよ」
という指摘をされたりすることがありますが、
変更点が設計段階で明記されていれば、その指摘も少なくすることができます。
お客さんの中には、「変わる」ことに対する「抵抗感」を持たれている方も少なくないので、
変更点を書いておくことで、その抵抗感を和らげる働きもあります。
また、開発作業をする時でも、
現行システムを参考にしながらプログラムを作成することがありますが、
「ここが変わる！」
とわかっていれば、現行システムの仕様のまま作ってしまうことも防げます。
基本設計後にプロジェクトに参加する人も多いです。その時に、
「どこが変わったのか？」
が分かると、非常にやりやすいですし、質問される数も少なくでき時間の節約にも繋がります！
「お客さん側」にも「自分たち」にもメリットがあるので、
今から作るシステムやサービスに関係なくても「変更点」を書いておきましょう！
まとめ：基本設計書に書いておいた方が良いこと
ここまでの話をまとめます。
まとめ
基本設計に、
- 「理由」
- 「使い方」
- 「変更点」
を書いておくと後々助かる！
「その設計にする理由」を書いておくことで、
「詳細設計や開発時のミスを防ぐ」ことでできる！
「画面や機能の使い方」を書いておくことで、
「完成イメージとかけ離れたモノができにくくなる」
「改善案や考慮漏れを防ぐ」
ことができる！
「現行との変更点」を書いておくことで、
「お客さんからの指摘を少なくし、抵抗感を和らげる」
「開発作業のミスを少なくし、プロジェクト途中参加者の負担を少なくする」
ことができる！
「基本設計書」という成果物に執着してしまうと、
「作る内容」だけ書かれた状態になってしまいがちです。
目的は基本設計書を作ることではありません。
その先の目的のために「作る内容」だけでなく、
「理由」、「使い方」、「変更点」を書いておきましょう！
お客さんが基本設計書を確認する時も、理解がしやすくなります。
自分たちが詳細設計、開発作業を行う時も役立ちます。
ミスが防げます！
改善案が出てきます！
後々の時間節約にも繋がります！
プロジェクトを進めていけば、途中で人が入れ替わることもあります。
自分が途中で抜けるかもしれません。
その時のために、
成果物の体裁に拘らずに、他にも役立ちそうなことがあれば書いておきましょう！
その１つ１つが後々自分たちを助けてくれるはずです！
