設計を軽視しない

TL;DR

• 設計は不確実性に対処するためのプロセス。
• 影響範囲は多岐にわたる。
• 設計を実施することで、コード上では気が付かない問題に対処できる。

極端な例を取り上げています。
通常は良識あるPMやリーダーによって正しいプロセスに沿ったプロジェクト運用が行われます。
ジュニアエンジニアはどうして設計を大切にするべきなのかを学ぶことが大切です。

忙しいので設計は後回しにします？

「忙しいので設計は後回しにします。」

現場では非常によく聞く台詞です。
設計工程を飛ばしてもコードを記述すれば、プログラムは動く。という理屈がこの言葉には含まれています。
では、その結果どうなっていくでしょうか。

あるプロジェクトの振り返りを見てみましょう。

「プログラム改修を最優先し、設計書修正を後回しにしたため、修正誤り、漏れ、仕様把握者の俗人化、保守性の悪化といった品質不良を拡大した」

この振り返りを例に問題毎の原因を考えていきましょう。

品質悪化拡大までの道のり

「品質悪化が拡大」するまでの道のりを想像してみましょう。

修正誤り・修正漏れ

設計書を修正しないとなぜ「修正誤り」が起こるのでしょうか。

原因はいくつか推測できます。

• 要件（コーディングの根拠）を理解せずに修正した
  ソフトウェア開発において、最上流にあるのはユーザー要件です。
  たとえば、次のような関数があったとします。

  X + Y / Z = Aという実装の結果Aの値が誤っているというバグが報告された。
  X、Y、Zそれぞれの値は各別々のモジュールから取得されている。
  そして、X、Y、Zは他のさまざまな実装で利用されている。

  要件を正しく理解して仕様化していないと、デグレードを起こしてしまうでしょう。
  場合によってはユーザーと要件調整も必要かもしれません。

• テスト実施が不十分だった
  テストにはブラックボックステスト、ホワイトボックステストがあります。（詳細は他所に譲ります）
  設計を正しく実施していなかったために、仕様に適合できているのかを確認するブラックボックステストが不足したと推測されます。
  設計書修正を行わないということは既存のテスト仕様書も正しく修正されていなかったことも推測されます。

• レビューが正しく実施できなかった

  設計書が修正されていない場合にレビュアーは何を根拠にレビューを実施すればよいでしょうか。
  おそらくバグ報告とコードをベースにしていたと推測されますが、ここでも要件の理解不足と同様の問題が発生します。

仕様把握者の俗人化

設計を確認し、修正する行為は前述の通り、要件を把握し、仕様化するプロセスでもあります。
この行為をプロジェクトに所属する各位が実施をしないと上流設計者以外は仕様を把握する機会を失ってしまいます。

保守性の悪化

修正誤り・修正漏れに記載しましたが、設計工程をないがしろにしたことで、さまざまな工程に悪影響をもたらします。
そしてそれらの影響は積み重なり、日々大きくなっていきます。

その他の影響

このプロジェクトでは設計書工程を後回しにした影響が他にもありました。

「正規の設計書がないことで、仕様変更分の費用交渉が難航した」

設計書としてユーザーと仕様を同意した文書がないため、あとから発生したユーザーの指摘が仕様変更（設計時になかった新たな要求）になるのか、不具合（要求を取り込んでいない）になるのかがわからなくなり、仕様変更に対する費用交渉が難航したと思われます。
こちらとしては仕様変更であっても、それを証明できなかったということです。

---

設計の必要性はこの例で明らかだと思います。
また、実際の必要性以外にも通常は設計書の修正プロセスは事前にユーザーと約束しています。
ユーザーとの同意なしにプロセスを省略してはいけません。

まとめ

• 設計は不確実性に対処するためのプロセスの一環
  時間的制約ではなくさまざまな理由から設計を省略したいと考えることがあるでしょう。
  ただ前述のように後に残る不確実性は測ることができません。
  また、悪い影響の対となる恩恵もたくさんあります。
  最終的な目的はユーザーに成果物を届けることです。
  時間に追われて、目的を忘れないことが大切です。