最近ユースケース駆動開発実践ガイドを購入して読みました。その感想
何故読んだか
最近、DDDに関する書籍が発売されて周りのエンジニアがほとんどみなさん購入していそうなのですが、あまのじゃくなのでDDDを避けて何か別のものを勉強しようと思ったのがきっかけですね
あまのじゃくなのでみんなドメイン駆動設計やってる中でICONIXプロセスを勉強します
— morimorikochan (@marooon88) February 17, 2020
（このツイートが DDD界隈のとてもエライ人にいいねをされてビビった。disツイートとして拡散されてないか怖い）
そんな中で、 今まで自分はアンチウォーターフォールのスタンスを取ってきて設計をおざなりにしていたが、実際のところ深く設計することをめんどくさがって避けてるだけじゃないのか？ と感じた（実際はアジャイルでも設計はするとは思うが私は軽視してきたと思う）ので設計関連の本をamazonでググってみたら 下記の本が出てきました。
システム開発の設計手法にの書籍でよく拝見する増田さん（と思わしき方）がベタ褒めしていたのをきっかけにして読み始めましたw
どんな本か
本書では、ユースケース駆動開発の一つとして ICONIXプロセスというものを採用しており、そのICONIXプロセスについて実践的に事細かく手法が書かれています
実践的
よくあるDDDの本やその他設計には、厳密に設計を求めたりまたは作業にかける時間（コストパフォーマンス）に対する配慮が全く書かれていないことが多いと感じています。ですがこの本では、作業にかける時間（コストパフォーマンス）に対する配慮が至る所にあります。
例えば本書のイントロダクション（第１章の前）の部分にて、分析麻痺についてコラムが書かれています。分析麻痺というとなじみがないですが、要するに 設計作業の中で、分析に対してパフォーマンスが上がらない細かい設計を厳密にやろうとしてしまうことです。 若干私にも思い当たりがあって心が痛いです。
本書では何段階かのプロセスを踏みますが、一つ一つのプロセスで完全性を求めておらず、その先のプロセスで新しい発見があることが前提で書かれています。そのため新しい発見があった場合は前のプロセスのものに修正を加えていき、プロセス全体を通して設計を強固にしていきます。また、時間に対する言及（「この作業は2時間ほど行えば今の段階では十分！」みたいな）もあります。このように厳密さを求めていない設計手法になっている点がとても面白いと感じました。
こういう点から本書は理論的ではなく、圧倒的に実践的だなぁと感じました（本書内でもクックブックと表現しています）。
軽量・フレキシブル
また、設計の途中でUML図を使うことがたびたびあります。ですが本書全体ではたった4種類のUMLしか使用していません。（UML自体は13か14種類ほどあったはず）
また、本書で紹介されているICONIXプロセスは、ある程度の設計フェーズまで完了すると、個々のユースケースごとに設計と実装を行うことも可能ですし、全ユースケースで設計→全ユースケースで実装というふうに作業を行うことも可能です。とてもフレキシブルなので、細かくイテレーションを回すアジャイル開発・工程を分けるウォーターフォール開発どちらでも通用することなのではと思っています
ドメインモデリング
どのような設計方法でも、顧客の頭の中にある世界をモデリングするフェーズは必ずあると思います（そうでないと認識の齟齬が出ると思うので）
DDDだと ユビキタス言語 っていう名前でチーム全体の共通言語を作成していきますが、ICONIXプロセスではそれをドメインと読んでいて、ドメインを顧客から引き出すことをドメインモデリングと呼んでいます
このときの引き出し方（HowToの部分）がとても詳細に書かれていてすぐに実践が可能です。また、本書内でも架空の顧客用件をもとに実際にドメインモデリングを進め、読者の間違いやすい点をカバーしてくれています。これはドメインモデリングの部分だけでなく、各章ごとに理論だけでなく実際に適用した時の考え方・成果物が記載されています。最後らへんの章では少しボリュームが多くて鬱陶しく感じますが、ドメインモデリングおよびその後のフェーズでは大いに役立ちました。
まとめ
- 軽量なツールなので、せっかちな自分にはあっているように思ったので、仕事に活かしたいと思いました
- ICONIXに関するネットの資料が少なすぎるが何か理由があるように思いました