この記事には、ソフトウェア開発を経験した中で得たこと・感じたことを備忘録として残す。
読みやすい文書でもないし、正解が書いているわけではない。
##ソフトウェア設計とは何か
###アーキテクチャ設計
要件定義フェーズで決定された機能仕様/非機能仕様を実現するために、ソースコードを記述する必要がある。
この時、無秩序にソースコードを記述してしまうと、複雑度・凝集度・結合度が悪化して品質悪化し、保守性も低下する。
これを避けるためにはアーキテクチャ設計を行い、ソースコードの世界に秩序をもたらす必要がある。
###詳細設計
こと日本においては、詳細設計の実施が重要視されている。
以前は、フローチャートやPADを丁寧に記述し、その内容を徹底的に机上レビューし、不具合が作りこまれていないことを確認してから、コーディングを行っていた。
なぜか？
数台しかない端末、取り合いになるコンパイル用中央コンピュータといった限られたリソース下であるが故に、コーディング作業は最低限の時間内で終わらせる必要があった。
その名残ではないかと思っている。
現在も、詳細設計をきっちり終わらせてからコーディングに移ることが美徳であるとする傾向にないか？（特に大きな企業）
現代においてこの考えは捨てるべきである。
リーンのプラクティスである「決定をできるかぎり遅らせる」の考えに則り、設計の確定はできる限り遅らせるべきである。
これはなにも、「実装してから詳細設計書けばいいじゃん」と言っている訳ではない。
そんなものは無意味である。
必要なタイミングで、必要なレベルの設計を確定し、その設計とソースコードは矛盾ないか確認しながら進めるべきである。
##設計とは何か
ここではソフトウェアという狭い世界から一歩引いて、設計（Design）とは何かということを考えてみたい。
その知見から、改めてソフトウェア設計では何をすべきなのかを考えたいのである。
###Design
設計は英訳すればDesignである。
Designと言ってぱっと連想したのは「グラフィックデザイン」であったので、これを考えてみる。
以下は、学生時代に書いていた小説(いまで言うラノベ)のタイトルロゴを友人に作ってもらったものである。
要求としては「どのような作品であるか」を伝えた程度だったと思う。
これを受けた友人がデザインを考案するにあたり、事前に色々なことを考えたのではないかと推測する。
「この小説は剣と魔法の世界だから、鋭利なイメージが良いのでは」
「Genesis＝創世記ということは、古代的なイメージが良いのでは」
・・・
具体的な要求もなしに、よくここまで良いデザインを作ってくれたものだと感心しきりである。
さて、ここで友人は「Design」を決定するための事前準備として「Image」を描いている。
- 鋭利なイメージ
- 古代的なイメージ
とてもコンセプチュアルである。
これを私が事前に聞いていたかどうかは最早記憶に残っていないが、レビューしていたとしたらOKと返事していたことだろう。
一方で、「Detail」として
- フォントの種類は？
- 文字サイズは？
- Gの文字角度は何度？
なんてことは決めていないはずである。
これを私が事前に聞いたとしても、良し悪しは答えられない。
実際にPhotoshopを使って絵を描いているときには、フォント・サイズ・角度、長さ、、、などなどを試行錯誤したことだろう。
しかし手を動かす前にやったことは、おそらくコンセプチュアルなところを決めたに過ぎないはずである。
（私も絵描きの端くれだが、自分ならそうやって進めると思う）
Software Detail Design
ソフトウェアの世界に戻ろう。
詳細設計を描くときに、フローチャートを正確に書くことは重要だろうか？
どこで変数を宣言して、どこで何を代入するのかを正確に書くことは重要だろうか？
私はそうは思わない。
それは最早、コーディングと何も変わらないのである。
コーディングの前にやるべきことは、コンセプトの確立と適切なレビューである。
要件に対して設計コンセプトが適切であることを、レビューアが評価できるために、必要な設計をすべきである。
クラス設計かもしれないし、DFDかもしれないし、タイミングチャートかもしれない。
色々なことをしないといけないビジネスロジックの上位メソッドは、アクティビティ図でシンプル化を図るべきかもしれない。
だがそれら「詳細設計を終えないとコーディングしてはいけない」ということではないと思う。
アーキテクチャ設計はソフトウェアの秩序なので、安易に変更してはならない。
しかし詳細設計は試行錯誤なのである。
コンセプトはしっかり固めておきたいが、ロジックはソースコードで書けばよいのである。
ロジックに不安があるなら、それを分かりやすい形に可視化して、だれかにレビューしてもらえばよいのである。
何のために設計をするか
構築から保守にいたる全ライフサイクルにおいて、不具合を埋め込まないためである。
アーキテクチャ設計はソフトウェアの秩序を明確にするために行う。
開発者は、定められたアーキテクチャに従う義務がある。
詳細設計は難しい。
私はソースコードの妥当性を「自分が確信し」「他人が賛同できる」ために行うのだと思っている。
眠くなったので本日はここまで