基本設計を何と心得る？

いまだ多くのソフトウェア開発において、やはり「ウォーターフォール」型の開発モデルが選択されることは珍しくありません。

これを

　「ウォータオーフォールはもう古い！」

という人がいたらちょっと距離を置いた方がいいでしょう。

もちろんアジャイルがどんどん浸透してきてスクラムにせよ、ＦＤＤにせよ、広がりを見せるのは良いことだと思います。ですが、アジャイルは往々にしてＢ２Ｂ…特にお客さま企業の経営体質に向かない性質があるのも確かです。

　「エンジニアにとって」都合がいい

という理由だけで選択するわけにはいきません。そもそも企業間では「契約」が先に取り交わされ、その中で期間や予算などもあらかじめ決められるものです。期間や予算が最終成果にとって妥当であるためには、最初にスコープや作業量（工数）が算出されている必要があります。

…というと、「ベースラインを決めて変更分を追加請求すればいいじゃん」という人が出てくるかもしれませんが、それすらもエンジニア目線でしかなく、お客さま目線となっているかどうかは疑わしいと言わざるをえません。

お客さまにも年間の予算計画というものがあります。

それはほんの少し経営というものに目を向ければわかることです。ＩＴ投資できる予算にも限度というものがありますが、お客さま側の担当者がそんなことまで考えているとは限りません。進行すればした分だけ湯水のようにニーズがあふれてきて、それらを一つひとつ吞んでいたらあっという間に予算も期間もオーバーです。自社の都合だけ考えてとにかく請求しようとしか考えてなければ、待っているのは泥沼論争だけです。

ウォーターフォールはそう言った意味で、

　「仕様スコープが明確に定められる」

ケースにおいてはとても有効な開発モデルと言えるでしょう。まぁなかなか仕様が定まらないお客さまの方が多いので、ウォーターフォール以外の選択肢がどんどん増えてきているのも確かですが、ここで言いたいのは

　"特定条件を満たすか否か"によって
　それぞれのメリデメと特性を最大限活かし、最適な選択をすればいい

のであって「古いかどうか」で浅はかにジャッジするようなものではない…ということです。

さてしょっぱなから脱線してしまいましたが、そのウォーターフォールにおける

　・「基本設計」とはなんぞや？
　・「基本設計」と「詳細設計」はなぜわかれるのか？

を正しく理解しているエンジニアって本当にそんなにいるのでしょうか（いやまぁ基本設計という呼び方が妥当なのかどうかはともかく、当該工程のことです）。前職、いやさらにその前からなので最低でも10年以上前からそうですが、基本設計の中に

『お客さまにレビューしていただけない内部設計相当の記述がある』
『対となるテストでは"ホワイトボックス"でなければ検証できない』
『論理飛び越して、物理設計が行われている』

というケースがとても多く散見されるのです。

もし。

もしですよ？
基本設計の対となるテスト工程で、これらを検証するのであれば文句はありません。ですが、一般的にＶ字モデルを継承したウォーターフォールであれば基本設計の対となるテスト工程は

　『結合テスト』

です。いわゆるモジュール等を結合させて、処理ではなく「機能」を検証しようという工程です。処理単体の確認が単体テストで済み、それらパーツを結合させることで１つの『機能』として適切かどうかを検証します。

ここでは一般的に「ブラックボックステスト」が採用されている企業やプロジェクトが一般的でしょう。WEB系の開発などIDE（統合開発環境）を用いて開発するタイプのプロジェクトであれば、単体テストですらブラックボックスを採用しているチームも少なくありません（ホワイトボックスを実施しなくて、カバレッジ100%の保証も無くていいのか？という疑問は残りますが（1回も実行しないままリリースしてしまうプログラムが存在する可能性を否定できないから））。

にもかかわらず、なぜか基本設計において「ホワイトボックステスト」でなければ決して検証できないような設計を行っているのです。

　検証しないのに

です。実装工程（プログラミング工程）に対しては、そういった「処理」の内容を記述する設計というのもあってもいいかもしれません。ですがそれを検証する工程が無いのです。検証しないのに設計してどうするんでしょう。「実装のために…」というなら、別に基本設計工程で実施しなくても、そのぶん実装工程を長めにとって実装工程の中で検討してもいいはずです。

しかも日本の場合、設計→実装→テストを縦割りで同じ担当者に実施させる企業やチームも多いと思います。詳細設計を嫌い、「わざわざプログラムを日本語で書かなくても、さっさと実装した方がマシ」と言い張るエンジニアさえいるくらい形骸化していると思われがちなこの国において、基本設計時に詳細設計相当の記述をしたがる癖が残っているのは何故でしょう。

当然、要件定義（あるいは要件定義相当）と呼ばれる工程のいかなる成果物ともトレーサビリティが紐づきません。各工程、各作業、各成果物の一つひとつが deliverable な要素構成になっていないということです。

　「どこからこの設計が捻りだされてきたの？」

と聞かれてもおそらく答えることはできないでしょう。

答えられないと言うことは、その設計内容、設計思想自体に対して「正しい」と証明することもできないということです。結果的に正しかった…ということはあっても、まだ設計時点では

　「うるさい！いいから黙って食え！」

といって客の不安を無視する横柄な料理店さながらです。

今のご時世、なんとなくプログラミングだけ教わって、なんとなく各工程ですることを教わったら、そこに「なぜ」という疑問も持たずにただただ作るだけでエンジニアと呼ばれるようになってしまいました。

もちろん、一部の優秀な方たちはそうでないかもしれませんが、私の知る限りそんな優秀な人達なんて100人に1人、いや200人に1人いるかどうか…。

そういう設計をみるたびに

　「あー…また自己満足で進行するプロジェクトかぁ」

と少しガッカリしてしまいます。
中でも炎上プロジェクトへの支援として入る時は、そのガッカリ感も相当なものです。仮に説明して真摯に聞き入れて次に活かしてくれるならまだしも

　「うるさいな…」
　「そんなこといいからなんとかしてくれ」

みたいなマネージャーやエンジニアが多いんです。炎上させておいて、あるいは鎮火もできないくせにプライドだけは高いのかもしれません。

私は「余計な仕事を増やせ」と言っているわけではなく、「品質に直結しない無駄な作業は減らせば？」と言っているだけで、むしろ業務負担が減る提案をしているだけなんですけどね（まぁ逆にトレーサビリティを確保する上で不足しているものがあれば「追加しろ」と言いますけど。本来やるべきことが不足してるんだから）。

いい加減、各工程、各作業、各成果物にどのような意味があって、どのようなインプットが必要で、次のプロセスのインプットとするためにどのようなアウトプットにするべきなのか、きちんと考えられる人たちと仕事がしたいですね。

今後、そういう人たちと出会うことはあるのかなー。