「システム設計の謎を解く」の感想

書籍モニターキャンペーンに当選してプレゼントいただいた書籍「システム設計の謎を解く強いSEになるための機能設計と入出力設計の極意」を読了したのでその感想など。自分にとっては恐ろしいほどに有用な本だった。ただひたすらにソフトウェア開発の基本設計について考える本。

以前に書いた記事はこちら

「システム設計の謎を解く」を読みながら設計について考える - 勘と経験と読経

アジャイルフリーでテクノロ ジーフリーな基本設計の本

本書は一言で言うとそんな感じ。

要件定義の領域は扱っていない（ただし、基本設計の前にやるべき事は整理されている）
アプリの基本設計が中心でアーキテクチャ設計は軽く触れる程度
詳細設計についても範囲外
オブジェクト指向設計については軽く触れる程度
アジャイル開発も触れる程度

この割切り（？）は顧客の立場に立って考えるととても実践的だと思う。

顧客の立場からすると

アーキテクチャの設計は興味の範疇外
- 非機能要件として気になる部分はあるけど、よろしくやってよね
詳細設計も同様。
オブジェクト指向かどうかなんてどうでもいい。
アジャイルかどうかも同様。
漏れなく誤り少なく仕様化するのが一番重要だよね

というところだろう。

「顧客と具体的な仕様を詰めること」に特化して書かれた本だと感じている。

成果物のガイドラインではなく検討のガイドライン

以前の記事でも書いたのだけど、本書は「考え方」を中心に書かれているのがポイントだと思う。

筆者は「設計とは"考えること"であり、アウトプットはその一側面である」と考えているからです。設計は単純に右から左に書き写せばよいものでもありませんし、機械的にできるものでもありません。設計には他にも重要な要素がありますうが、最も重要なのは「考えること」です。
システム設計の謎を解く強いSEになるための機能設計と入出力設計の極意（はじめに、より）

本書でも冒頭に紹介されているIPAの「IPA/SEC 機能要件の合意形成ガイド」や他で目にする似たような標準化ガイドは、成果物の説明とTIPS/チェックリストという構成が多い。これをあまり考えずにプロジェクトに適用するとうまくいかないことが多い。

成果物（アウトプット）のイメージを先に考えてしまうと、ついアウトプット優先で作業を考えてしまい、肝心の設計に関する思考が後回しになりがち
パーキンソンの法則 - Wikipedia
割りと考えずに成果物を展開したあとに、横串での整備に泣かされるというよくある展開に

進捗管理の上では成果物（アウトプット）中心で考える必要があるが、工程推進の観点では「どう考えていくか」「どう攻めるか」を中心に考えるべきだ。

副読本をあげるとしたら

本書は自分の考え方と近いところが多いので、プロジェクトのメンバーに是非読んでもらいたい本だと思っている。加えて、設計を担当するメンバーに副読本も紹介するとしたら次の本を挙げたい（本書の中でも参考図書として紹介されている）。

ユースケース実践ガイド―効果的なユースケースの書き方 (OOP Foundations)

Amazon

って絶版？！
別にユースケースにこだわりはないのだけれども、顧客とどのように仕様決定をしていくのかについて大変勉強になる本だと思っている。

自分への宿題

冒頭でも書いたけれども、本書の好感度が高い点の一つが、オブジェクト指向設計を前提として書かれていないことだったりする。

本来的にはこの考え方（引用注：オブジェクト指向）に基づいて、要件定義、基本設計、詳細設計、開発までが行われるべきなのでしょうが、現実としてはなかなかうまくいっていないようです。本書はオブジェクト指向設計の考え方に触れずに、アプリケーションの入出力や処理に注目して説明してきました。
システム設計の謎を解く強いSEになるための機能設計と入出力設計の極意（コラム：オブジェクト指向の発想、より）

とはいえドメインモデルは（学習の観点では）避けて通れないものでもある。というわけで購入したけど長らく積読の本を次に読みこなしたいと思っている。