曖昧な要求から設計を考える勉強会

はじめに

「こんな機能が欲しい！」と言われたとき、何から考えますか？

普段の仕事で私がどう要求を整理し、設計につなげているかを紹介する勉強会を開催しました。
題材は、架空の不動産会社の備品予約システムです。

今回伝えたかったのは、予約システムの正しい作り方ではありません。曖昧な要求から、設計に必要な情報や論点をどう見つけるかという思考の過程です。

「予約管理したい」だけでは、まだ分からない

最初の要求は、「会社のカメラやタブレット、ETCカードの予約を管理したい」というもの。Googleカレンダーで管理しているけれど、予約が重複して、当日使えないことがあるという設定です。

ここから、実際に使う場面を想像してみます。

• カメラは「3台ある」と数量で管理する？ それとも「カメラA」「カメラB」を指定する？

• 予約時間が終わっていても、実物が返ってきていないことはない？

• 備品を廃棄したら、すでに入っている予約や過去の履歴はどうする？

これらは、ただ詳しく聞くための質問ではありません。回答によって、何を一件のデータとして持つか、どんな関連や制約が必要か、そもそも今回どこまで作るかが変わります。

例えば、予約とは別に持ち出し・返却も管理したいなら、必要なデータや画面、開発タスクが増えます。「予約機能」の一言に、どこまで含まれているのかを確認したいです。

そもそも、同じ前提で話している？

質問を考えるときは、足りない情報を探すだけでなく、そもそも前提の認識が合っているか、説明された条件同士に矛盾がないかも意識しています。

例えば、同じ「予約」という言葉でも、個々の備品を指定する予約なのか、必要な台数を確保する予約なのかで、データの持ち方が変わります。

また、一つひとつの説明には納得できても、条件を組み合わせると疑問が出てくることがあります。

例えば、こんな条件があったとします。

• 同じ備品を同じ時間帯に重複予約することはできない

• 予約時間が終了すれば、次の人が予約できる

• 備品が返却されるまでは、次の人は利用できない

では、予約時間が終了しても備品が返却されていなかったら、次の予約はどうなるのでしょうか？

次の人は予約できても、実際には利用できないかもしれません。

もちろん、これらの条件が必ずしも矛盾しているとは限りません。予約できることと、実際に利用できることを別々に扱う業務なのかもしれません。

ただ、この条件を組み合わせたときに、想定している業務が本当に成立するのかは確認したいところです。

前提が曖昧なまま設計を進めると、後から「そういう意味ではなかった」となることもあります。

だから、理解したつもりで進めず、具体的な場面に置き換えて認識を確かめるようにしています。

具体例から条件を取り出し、設計案にする

ヒアリングでは、主にこんなところを考えています。

• 前提認識：同じ言葉を同じ意味で使っている？

• 作る範囲：本当に予約だけで足りる？

• 業務の条件：誰が、いつ、何をする？

• 整合性：説明された条件同士に矛盾はない？

• 前提・例外：予定どおりに進まなかったら？

聞いた条件は、設計の判断につながります。

どんな状態のデータが存在してはいけないのか

設計するときに必要なので薄っすら想像しながら確認していきます。

例えば、備品の管理番号が重複してはいけないなら、一意制約を設けることが考えられます。でも、管理番号は全社で一意なのか、拠点ごとに一意なのかによって、必要な制約は変わります。

同じ備品に予約時間が重複している場合も、キャンセル済みの予約なら問題ないかもしれません。

こうした「何を不整合とするのか」も、業務上のルールとして確認したいところです。

できるだけ不整合なデータを作りたくないので、DBで保証できる整合性はDBの制約で守りたいと考えています。
ただし、すべてをDBの制約だけで保証できるわけではありません。操作に応じて確認する条件や、複数のデータにまたがるルールもあります。

そのため、何を保証する必要があるのかを明確にしたうえで、DBの制約、モデルの責務、アプリケーションの処理など、どこで扱うべきかを考えます。(できる限り多層防御する)

勉強会では、管理番号と備品名を組み合わせる display_name を例に、同じ知識をあちこちに書かず、モデルにまとめる考え方も紹介しました。

こうして要求を整理していくと、必要なデータだけでなく、それぞれの責務や実装する機能も少しずつ見えてきます。

一度まとめたら終わり、ではない

私が特に伝えたかったのは、具体と抽象を往復することです。

具体的な使い方を聞いて、そこから共通する情報やルールを取り出す。いったん設計案にしたら、また別の具体的なケースで考えてみます。

「このルールが正しいなら、この場合はこうなるはず。それで合っていますか？」

すると、「いや、その場合はこうする」と、まだ聞いていなかった前提が出てくることがよくあります。

そうなると、さっきの整理では足りなかったな、と考え直すことになる。実務でも本当によくあります。また、設計案を考えている途中で、説明された条件同士がうまく両立しないことに気づく場合もあります。

そのときは、どちらかの条件を勝手に優先するのではなく、具体的にどんな場面で問題になるのかを整理して確認します。

予定どおりのケースだけでなく、ルールが成り立たないケースも探してみる。こうした反例分析も、質問を生むきっかけになります。

質問してから設計するだけでなく、設計を考えたからこそ、次に聞くべきことが出てくる。

質問は、情報を集めるためだけのものではありません。自分が理解した前提や、考えた設計案が本当に成立するのかを確かめるためのものでもあります。

この行き来が大事だと思っています。

完璧な仕様より、早い段階で論点を見えるようにする

すべてのケースを最初から洗い出すのは難しいです。

それでも、実装してから必要な機能や条件が見つかると、追加実装だけでなく、データの持ち方から見直すこともあります。工数や納期にも影響します。

だから、分かる範囲で早めに論点と開発範囲を整理したい。

特に、前提の認識違いや条件の矛盾は、実装が進んでから発覚すると影響が大きくなることがあります。

また、必要な機能が見つかっても、全部を今回作るとは限りません。追加する・対象外にする・後で対応する、という判断は関係者と合わせます。

何が決まっていて、何が決まっていないのか。どこに認識のずれや確認が必要な論点があるのか。

それらを早い段階で見えるようにすることも、設計に入る前の大切な仕事だと思います。

AIにも考えてもらう。でも、業務の決定とは区別する

考慮漏れや設計案をAIに挙げてもらうのは便利です。今回の架空の題材も、AIとやり取りしながら質問や設計案を整理しました。

ただ、AIが推測した仕様を、確認済みの要求として扱わないことは意識しています。

AIが出した案も、具体的な業務の場面に戻して確かめる。分からない前提は業務担当者に確認する。そのうえで、出力が仕様や設計意図に合っているかをレビューする必要があります。

AIがもっともらしい設計案を出してくれても、その前提が実際の業務と違えば、正しい設計にはなりません。

おわりに

今回、自分が普段かなり無意識にやっていることを、改めて言葉にしてみました。

要求を聞いて、そのまま設計に進むのではなく、言葉の意味や前提を確かめる。条件を組み合わせて矛盾がないか考える。設計案を立てて、別の具体例や反例で確かめてみる。

そうしているうちに、次に聞くべきことや、まだ決まっていないことが見えてきます。

質問項目を覚えるというより、「何を確かめたくて、どう考えるとその質問が出てくるのか」 が少しでも伝わっていたら嬉しいです。

参加してくださった皆さん、ありがとうございました！