設計書の意味
ソフトウェア開発における「欠陥」…すなわちバグの定義というものをご存じでしょうか。
JSTQBなどを認知しているとひょっとしたら知っている人もいるかも知れません。JSTQBでは
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備
と定義づけられています。
…まぁ難しいことを考えている人が、あえて難しく表現したらコーなっちゃうかーって感じの表現ですね。正直、わかりにくい。
要するに
「期待通りじゃない現象とそれを引き起こしているモノ」
のことです。これを欠陥あるいはバグと言います。
はい、ここまでは良いんです。ちょっと難しい言葉を翻訳すれば、おそらくほとんどの人がまぁ似たような解釈に辿り着いていることでしょう。でも、ここまでは序の口。問題でもなんでもありません。
問題は「期待通り」というフレーズ。
これを多くの人が「（誰かが）期待した結果に対して」と読み解きます。ちょっと理解を先に延ばした人なら「（お客さま、あるいはお客さまの要求事項が）期待した結果に対して」と考えているかもしれません。
それはある意味で間違いではないのですが、『ソフトウェア開発』というプロセスにおいては50点も取れません。
そもそも、「お客さまの期待」というものをそのまま用いて作成されたプロダクトやサービスと突き合わせて評価することは可能か？というとどうでしょう。
「お客さまの期待」と一致しない
とどうやって評価するのでしょう。お客さま自身にテストさせる…それは一手段として正しいでしょうけど、お客さま自身がソフトウェアやシステムに対してよほど優れたリテラシーを持っていない限り、完璧に評価することは難しいでしょう。
ましてや、細かいバグを一つひとつ見つけ出すことは可能でしょうか。
それができないからこそ、ソフトウェア開発の中に「開発者が責任を持って行うテスト工程」というものが存在しているのです。
ゆえに「すべてお客さまに評価させる」というのは絵に描いた餅であり、だからこそ「お客さまの期待」というあやふやなもので欠陥やバグをすべて洗い出すことは不可能という理屈になるわけです。
では、その「お客さまが期待」しているものが何なのか、それを言語化したものは何か、というとそれがタイトルにもあるように
設計書
となります。もう少しカチっとしないあやふやなものを残すのであれば「仕様書」でもいいでしょう。どちらにしても、テストにはそのテストで評価する元となる基準…答えが必要であり、その答えと比較して
「差分がないか」
というただその１点において、欠陥であるかどうかを見極めることが可能になるわけです。言い換えるなら、基準を明確に言語化していない状態で、「期待通りか否か」を比較評価することは決してできないということになります。
ほんの少しソフトウェア品質をかじれば、この点だけでも「設計書」がどれほど重要なポジションを占めているかがわかります。
設計書を、ただモノづくりのための面倒な翻訳作業か何かだと勘違いしているエンジニアにはこの重要性がどうしても理解できません。結果、そういったエンジニアによって「設計不備」による欠陥（バグ）が多発するわけです。
設計書は必ずなければならないものではありませんが、
「無くても製品の品質を保証できる」
と言うことは絶対にありません。そもそも設計書を用意しないと言うことは、作り上げた製品（ソフトウェア）が何を以って正しいか、欠陥がないかということを証明するための基準を明確化しないということですから、自らの責任で証明することを放棄するようなものです。
仮に問題なくお客さまに納めることができたとしてもそれは限りなく個人に依存した手法によるものであり、チームが、組織が、企業が、社会的に信頼されるに値する手法ではありません。
「当社の〇〇さんが大丈夫と言ったから、絶対にバグは起きません。
信用してください」
と言われてシステム代金１億の請求をされたとして、みなさんが客の立場だったら納得して検収をあげることができますか？
設計書とは、最終的に作り上げられたプロダクト（プログラムやシステム）に対して、その内容が正しいことを保証するための回答用紙です。
回答用紙がないのに、問題だけ解いて答え合わせをしようと思っても、それが正しいかどうかを証明する手立てがありません。もしも「バグが起きなかった」と認識したとしても、その認識自体が正しいことを裏付けるものが何もないのです。
JSTQBの提唱しているソフトウェアテストの７原則にもあります。
1. テストは「欠陥があること」しか示せない
2. 全数テストは不可能
明確に期待通りではない結果となった時だけは「この動きは欠陥である」と言えますが、そもそもテストは欠陥が無いように見えても、裏で起こっていることの全てを見通すわけではないので、本当に欠陥がないかどうかは証明できません。ただ設計通りの結果を示すことで「期待通りの動作をしている（はず）」と言っているにすぎません。
しかも、すべてのケースに対して一つひとつテスト網羅することはまず不可能である以上、確認していないケースの中に欠陥が潜んでいる可能性だってゼロにはなりません。「これで大丈夫なはず」と思って選別したテストケースの中に欠陥が無かったとしても、それはあくまで実施したテストケースの中に限って欠陥が無かったというだけでしかありません。
何が言いたいかというと、
その選別されたテストケースは、「本当に期待した通りの要求をすべて満たすことが保証されるテストケースになっているのか？」が論理的に証明されない限り、『テスト』だけで品質を保証することは不可能だということです。
むしろソフトウェアテストの品質は「如何にしてMECEなテストケースを抽出できるか」にかかっていると言ってもいいでしょう。
では、そのテストケースを作成するうえで重要なinputは何になるでしょうか。
…そう、設計書（あるいは仕様書）です。
ですから設計書を作らないと言うことは、お客さまがOKを出してくれない限り、延々と改修は続きます。それはすなわち、テスト作業に対する作業見積りの根拠が明確にできず、どんなに見積りを行ったところで後で狂うことになる可能性があるということでもあります。
そうならないのは、定常顧客とよほど信頼関係が構築されて密な連携が取れているケースだけです。
また、設計書を作ってさえいればトラブルや計画外作業が発生しないかと言うとそんなことはありません。
顧客指定の定型フォーマットであれ、自身が構築したものであれ、重要なのは
設計書に求める意味（目的）は何か
設計書に求める効果は何か
と言うことを定義できるかどうかにあります。
この回答を用意できないプロジェクトは、結果的に
・プログラミング時には設計書を見ない
・チェックリスト作成時には設計書を参考にしない
と言ったことをエンジニアが平気でしてしまっていて、しかもマネージャーがその点を管理しない、気にしない、是正しないといった状況に陥っていることが殆どではないでしょうか。
挙句
「必要な機能（処理）が不足する」
「品質の根拠が説明できない」
という状況を引き起こします。
多くのトラブルプロジェクトに見かけられるエンジニアリング起点のトラブルは、大抵の場合が「各工程や各工程成果物の意味および目的を理解しないままに進める」ことにあります。
こうした意味や目的は、本来マネージャーやリーダーが定義するものですが、マネージャーやリーダーだけの責任とも言えません。仮にマネージャーやリーダーが未熟でそういった観点にまで頭が回らなかったとしても、自らのプロ意識に照らし合わせて考えればエンジニアの目線から言っても喚起することは可能なはずです。
「設計でこういう定義を明確にしておかなくてもいいんですか？」
と。
確かに問題要因の根幹としては「マネジメント不良」によるところが大きいと言えるのですが、私に言わせれば
「マネジメントとは、マネージャー１人で行うものではなく
マネジメントチーム全員で推進するものだ」
という考えがベースとなっていますので、そこで改善するための努力をしなかった一人ひとりに平等に責任を問うような問題だと思っています。
そう言う意味では、マネジメントそのものではなく『ソフトウェア開発』そのもののプロセスを正しく理解しているかどうかが多くの割合を占めると言えるでしょう。
こればかりは、目先のテクノロジーやプログラミング能力だけを延々と高めても絶対に向上しませんし、これらが向上しない限り集団におけるプロジェクト活動では苦労することが多いでしょう。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。