第9章 要件からドメインを整理する

Slide 01. 要件からドメインを整理する

ここからPart 3に入り、Webアプリケーションを設計して作る準備を始めます。今回の入口は、「メンターが担当受講者に支援ステータスを付けられるようにしたい」という小さな要求です。ここでいうドメインは、その仕事で使う言葉やルールのことです。すぐ実装に変える前に、誰のための機能か、どんな決まりがあるかに分けて見ていきます。

Slide 02. この章で持ち帰ること

この章で持ち帰ってほしいのは、作る前に要求文をいくつかの箱に分ける型です。全部の名前を今すぐ覚える必要はありません。利用者と目的、使う言葉、状態、出来事、ルール、作る範囲を順番に分け、最後に、実装後に確認する受け入れ条件へつなげます。

Slide 03. Part 3の入口

前の章までは、手元で動かし、HTTPを観察し、既存コードを読んで小さく直す流れを扱いました。調査内容や判断は、Pull Requestで説明しました。ここからは、コードを書く前に何を作るべきかを整理します。この整理は、第10章以降のデータ設計、API設計、画面設計、テスト設計の土台になります。

Slide 04. 第2章からつなげる

第2章では、機能要求をユーザー価値、事業価値、制約に分けました。第9章では、その材料を、アプリの中で使う言葉とルールに整理します。価値として何を良くしたいのかを見たあとで、誰が、何を、どの状態に変えたいのかを見ます。ここが見えると、後続の設計で迷いにくくなります。

Slide 05. 要求文を観察する

今回の要求文は、「メンターが、担当受講者に支援ステータスを付けられるようにしたい」です。この一文には、利用者、対象、操作、管理したい情報が含まれています。まずはDBカラムや画面部品に急がず、メンターが仕事として何を見て、何を判断したいのかを抜き出します。

Slide 06. ユースケースを書く

ユースケースは、ユーザーが達成したいことを書くためのメモです。たとえば、メンターが担当受講者の支援状況を一覧で確認し、必要ならステータスを変える、という形です。利用者、目的、事前条件、基本の流れ、成功したと言える状態を並べ、機能名だけでなく利用者の動きが見えるようにします。

Slide 07. 整理の粒度を変える

ここでは、整理する細かさ、つまり粒度を変えてみます。たとえば「支援ステータスを追加する。DBにstatusカラムを足す」とだけ書くと、実装作業は見えますが、何のための機能かはまだ見えにくいままです。「メンターが担当受講者の支援状況を一覧で管理したい」と書くと、何を支える機能なのかが見えやすくなります。

Slide 08. 用語を揃える

用語を揃えることは、設計のズレを減らすための基本です。受講者、メンター、担当受講者、学習ログ、提出、支援ステータスといった言葉を、チームで同じ意味で使えるようにします。コード名、API名、画面文言、テスト名にもこの言葉が出てくるからです。

Slide 09. 似た言葉を分ける

似た言葉は、早めに分けておきます。未提出、未対応、要支援、困っている、アラート対象は、似て見えても同じ意味とは限りません。意味を混ぜたまま進むと、画面では要支援、APIではalert、テストでは未対応と呼ばれ、後から読む人が迷います。

Slide 10. 状態を取り出す

状態は、ある対象の今の様子を表します。支援ステータスなら、支援不要、要支援、支援中、解決済みのような値が考えられます。ここで大事なのは、学習ログの提出状態と支援ステータスを同じものとして扱うか、別のものとして扱うかを確認することです。

Slide 11. イベントを取り出す

イベントは、状態を変えるきっかけになる出来事です。メンターが支援ステータスを変更する、受講者が学習ログを提出する、といった動きがイベントです。ただし、学習ログを提出したら支援ステータスが自動で解決済みになるのかは、ルールとして別に確認します。

Slide 12. ルールを取り出す

ルールは、いつ、誰が、何を変えてよいかという決まりです。たとえば、メンターは担当受講者の支援ステータスだけ変更できる、受講者本人は支援ステータスを変更しない、初回リリースでは自動アラートを作らない、といった判断です。ルールを分けると、どこに書くか、何を確認するかが見えやすくなります。

Slide 13. 境界を決める

境界は、今回作る範囲と、今は作らない範囲を分ける線です。今回やることは、メンターが担当受講者の支援ステータスを手動で更新できること。今回やらないことは、自動アラート、CSV出力、詳細分析ダッシュボード。後で検討することは、支援履歴の集計や引き継ぎです。

Slide 14. ドメインモデルを描く

ドメインモデルは、業務で出てくる主な言葉と、その関係を表すたたき台です。ここでは厳密な図を作る必要はありません。主要な言葉と関係のメモで十分です。メンターは受講者を担当する、受講者は学習ログを提出する、受講者は支援ステータスを持つ、という関係を見えるようにします。

Slide 15. DB設計へ急がない

ドメインモデルは、業務で使う概念を揃えてからDB設計へ進むための考える道具です。テーブル名やカラム名の前に、概念、関係、状態、ルールを整理しておくと、第10章でテーブル、カラム、制約へ落とし込みやすくなります。

Slide 16. 受け入れ条件を書く

受け入れ条件は、実装が完了したと言える条件です。言い換えると、作ったあとに何を見れば終わったと言えるかです。ユースケース、用語、ルール、例外をもとに、あとで確認できる形で書きます。これは第13章のテストだけでなく、第6章で扱ったPull Requestの確認方法にもつながります。

Slide 17. Given When Then

受け入れ条件を書くときは、前提、操作、結果の三つに分けると書きやすくなります。この形をGiven、When、Thenと呼ぶことがあります。たとえば、前提はメンターが担当受講者の進捗一覧を開いている。操作は支援ステータスを要支援に変更する。結果は、その受講者の支援ステータスが要支援として保存される、です。

Slide 18. AIに整理を手伝わせる

AIは、ユースケース案、用語候補、状態やルールの抜け漏れ、受け入れ条件の初稿づくりに使えます。依頼する前に、個人情報や秘密情報、社内だけの情報を入れないか伏せます。依頼するときは、DB設計やAPI設計にはまだ入らない、自動アラートは対象外、不明点は分ける、という制約も一緒に渡します。

Slide 19. 確認責任は人が持つ

AIが出した案は、自然に見えても、その組織の業務ルールとずれることがあります。支援ステータスの値、担当メンターの権限、対象外にする範囲は、メンターや仕様を知っている人に確認して決めます。AIの案は、整理と抜け漏れ確認の相手として使い、採用前に自分たちの材料と照らします。

Slide 20. 演習1 ユースケース

演習1では、要求文をユースケースに分解します。まずは、「メンターが担当受講者の支援状況を確認し、必要ならステータスを変更する」のような一文から始めます。利用者、目的、事前条件、基本の流れ、例外、成功条件、対象外、不明点を書きます。最初からきれいに書く必要はありません。

Slide 21. 演習2 用語集

演習2では、用語集を書きます。受講者、メンター、担当受講者、学習ログ、支援ステータスなどを表にして、意味、似た言葉との違い、コード上の名前候補を整理します。たとえば支援ステータスは、メンターが支援の必要度を見るための値、くらいで十分です。迷っている用語は、無理に確定せず、そのまま残します。

Slide 22. 演習3と4 ルールとモデル

演習3では、状態、イベント、ルールを表に分けて書きます。たとえば、要支援は状態、メンターがステータスを変更することはイベント、担当受講者だけ変更できることはルールです。演習4では、主要な言葉と関係をドメインモデルのたたき台にします。ここでもDBテーブルには急ぎません。

Slide 23. 演習5 受け入れ条件

演習5では、受け入れ条件を書きます。まず、実装後に何を見れば完了と言えるかを、正常系、権限、例外に分けます。たとえば、担当メンターが要支援に変更すると保存される、担当外の受講者は変更できない、という形です。そのあと、PRで説明する確認方法や今回対象外も分けて残します。

Slide 24. 次はデータ設計へ

この章で作ったユースケース、用語集、ルール、ドメインモデル、受け入れ条件は、Part 3の次の章で使う材料になります。次の第10章では、ここで整理した概念、関係、状態を、データベースのテーブル、カラム、制約に落とし込みます。受け入れ条件は、SQL確認や後のテストで、できたと言えるかを見る材料になります。