書籍モニターキャンペーンに当選したので、今月末に発売予定の書籍「システム設計の謎を解く」を読み始めた。まだ全部は読み終わっていないのだけれども、設計に関して考えた事について。
ソフトウェアの設計を「考える」
最近の風潮では（あくまで個人的感覚だが）なんというか「設計」は軽視されがちだ。
- アジャイル開発のメジャー化に伴って、プログラミングを中心とした方法論やプラクティスは割りと注目されている。
- SIerを中心に以前としてあるプロジェクトマネジメントや、要求管理は引き続き注目されている(ような気がする)。
- 他に、運用関連やテスト(プロセス)関連も割りと話を聞くような。
本来はソフトウェア開発のど真ん中にあるべき「設計」に関する話題で盛り上がることはあまり無い気がしている。ドメイン駆動設計は少し話題になったけれども・・・
また、「アジャイル vs ウォーターフォール」の議論の中で「プログラミングも出来ないSEが設計することはおかしい」というような文脈も割りと目にするけれど、肝心の「設計」そのものについての議論はあまり記憶にない。
もしかすると、ソフトウェアの「設計」は皆あまり意識することなく実施しているかもしれない。本書はこの「設計」についてひたすら書かれている本である。
しかし、いかに現場の経験が重要といっても、プログラマの延長上で、泥縄式に設計ができるようになるわけではない。
システム設計の謎を解く 強いSEになるための機能設計と入出力設計の極意（巻頭の推薦文より。株式会社メソドロジック代表取締役社長 山岸さんの言葉）
筆者は「設計とは"考えること"であり、アウトプットはその一側面である」と考えているからです。設計は単純に右から左に書き写せばよいものでもありませんし、機械的にできるものでもありません。設計には他にも重要な要素がありますうが、最も重要なのは「考えること」です。
システム設計の謎を解く 強いSEになるための機能設計と入出力設計の極意（はじめに、より）
Code Completeにこんなことが書いてあったことも思い出される。
ソフトウェアの設計の歴史は、激しく対立する設計手法の熱狂的な支持者たちによって彩られている。1990年台の初めに本書の初版を出版した当時、狂信的な設計者たちは、コーディングの前に済ませなければならない設計作業を事細かに主張していた。しかし、その内容はまったく意味を成していなかった。
2000年台に入って、筆者が第2版を執筆しているころ、ソフトウェアの権威者の一部は、設計を一切行わないことを主張していた。彼らはBig Design Up Front(設計の大部分は前もって)をBDUFと呼び、「BDUFはよくない。コーディングの前に設計は一切行わない方がよい」と主張した。
(中略)
では、どれだけやれば十分だと言えるのか。それは個人的な見解であり、これで十分だと断言できる人はいない。設計の正しい量がこれだと言い切ることはできないが、常に誤りであると保証できることが2つある。それは、すべての詳細を残らず設計すること、そしてまったく何も設計しないことである。常に誤りであることがわかっているのは、対極にある過激派が提唱するこの2つの姿勢だけだ。
CODE COMPLETE 第2版 上 完全なプログラミングを目指して 5.5 一般的な手法へのコメント
ガイドラインとチェックリストでは足りない
自分の過去の経験と照らし合わせると、「設計」については様々な現場に転がっている標準化ガイドライン、テンプレートとかチェックリストから学び取ってきた気がする。既存のガイドラインの類は腐っていることが多いので、これをブラッシュアップしながら、プロジェクトの特性に応じて「考えていく」スタイルである。
- 前工程のインプットをどうやってアウトプットに繋げるのか
- プロジェクトを達成させるために、どういった観点で前工程に品質を仕込むのか
といった観点でプロセスを組みながら「考える」。そしてプロジェクトが終わるたびに至らなかった点などを反省しつつ、次に活かしてきたように思う。
とはいえ周りを見渡すといつまでたっても設計力が残念な人も居て、育成をどうするのかは大きな悩みのひとつである。どうして設計力がつかないのか、本書を読んで少しわかった気がする。
要は、ガイド類が充実した結果「考えない」でやってしまうから設計力がつかないのだ。
- ガイドラインや成果物テンプレートに頼ると「ルールに則って落としこむ」ということに注目してしまう。
- チェックリストがあると、いかにしてチェックリストを網羅するかだけに注力してしまう。
- 生産性を上げる＝いかに要領良く成果物を仕上げること、になってしまい、考える事が少なくなってくる
・・・というような事を考えながら、本書を読んでいる。もうすこし設計について「考えて」みようと思う。
参考
- IPA/SEC 機能要件の合意形成ガイド
- 好みの問題はあるけれども、ここまで壮大なガイドも世の中にはすでにある。
- しかし、世の中のアプリケーションエンジニアの設計レベルが上がっているわけではない気がする。
