本記事は、株式会社ギックスの運営していた分析情報サイト graffe/グラーフ より移設されました（2019/7/1）
目次
設計書なんて必要ないでしょ？ 見れば分かるだろ？ こんなの常識だろ？ 未来の自分にそんなこと言えますか？
データ分析業務に限らず、開発や製造、建築などの”モノ作り”の仕事において、設計書は必ずと言っていいほどあります。しかし、一人、または小規模プロジェクトでは、これらの設計書作成を省いて、口頭やメールベースで作業を進めてしまう場合があります。このやり方は正当な方法とは言えませんが、ある程度のスキルを持ったメンバー同士の”モノ作り”の中では、設計書作成の工程はない方が効率的な場合もあります。
今回は、”モノ作り”の仕事の中からシステム開発やデータ分析業務に的を絞って、設計書の”あり方”について考えを書きたいと思います。
本来の設計書の役割は”モノ作り”のチェックリストである
システム開発やデータ分析業務の設計書は、次の担当者への作業指示書であるのと同時に、作業がちゃんと行われるかのチェックするためのチェックリストとして使われることが多いです。
開発工程は、要件設計、基本設計、詳細設計、開発のように工程が分かれ、各設計工程ではそれぞれ設計書を作り、その工程での担当者と設計書ベースで内容をコミットしていきます。そして、開発終了後、単体試験、総合試験、ユーザー試験の順で試験を行いますが、その時、試験項目のベースとなるのが詳細設計書、基本設計書、要件設計書になります。この様にすることで各設計工程で決めた内容がきちんと出来ているかをチェックすることができます。
小規模な”モノ作り”の現場では、設計書の役割はうやむやになっている
大規模な開発なら開発期間も長くなりますし、多くの関係者の認識を合わせるためにも設計書は必要になります。しかし、数人程度の開発の場合、設計書を作ること自体が非効率となり、その場でモノだけクイックに作ってしまうことは少なくありません。また、開発期間を短縮するために、細かいレベルの設計書の納品を行う必要もない場合もあります。
設計書やメモを残さないことは、命綱なしで綱渡りしているのと同じこと
設計書は必要がなければ作らなくても良いのでしょうか？
開発をしている当時は、プロジェクトに集中しているため、簡単にモノを作れたかもしれませんが、時が立ってしまうと当時の記憶を掘り出すまでに時間が掛かる場合があります。また、担当者が突然の病気や異動でプロジェクトを離れる時、モノしかない状態ですと作業の引き継ぎがスムーズに行うことはできません。
そのため、設計書のようなしっかりしたものでなくても「メモ書き」程度は残しておくべきです。メモ書きは別ファイルでも良いですし、プログラムソースなどではコメントを残しておけばいいと思います。メモ書きは完璧な必要はありません。作ったモノを作った経緯や内容、注意すべきことが分かるきっかけになる情報だけ残して置けばいいのです。多少手間ですが、いずれ自分、またはプロジェクトメンバーに返ってくるものですのでメモ書き程度は残しましょう。
