why

https://gyazo.com/80aa6d5ea70ace69d5b50a543d893ecc

プロダクトバックログなどの要求文書には必ずWHY（なぜ）をつけましょうというのは口を酸っぱくして言われます。でもそれは「なぜ」なのでしょ

あくまでコミュニケーションをする上での補間的な役割として「WHY」をつけた方が良いということなのだと考えられて

ところが、メリットはそれだけではありません

「意図」の記述が、直接ソースコードや設計に影響を与える

全く意図を喪失した要求には、コードに落とすべき「抽象」が見当たりません

対象とする問題を解決するための抽象構造のことをドメインモデル

このような「意図」に基づいた新たな要求に対するレジリエンス（耐久性）が上がります。

意図の明確化は、「将来の不確実性」に対応する手段

意図は発見的に見出されることが多い

ソフトウェアアプリケーションを作っていく場面で重要なのは、存在論的抽象というよりもむしろ、目的論的な抽象

ある場面での目的に合わせて、事後的に発見される抽象構造をテレオロジー的な抽象、あるいは目的論的な抽象

直交性の定義は、ある種のジャーゴン

完全に2つの機能が直交であれば、機能同士は無関係

例: 意図を発掘して、50パターンという複雑性をどれだけ減らしてシンプルな要求にリバースエンジニアリングできるか

10個の顧客区分割引と2個の時間帯割引、そして1つのイレギュラールールという合計13パターンのチェックで

設計意図は隠れやすいし、提案者本人でさえ気が付いていないこともままあ