「技術的には可能です」に対抗する、すれ違いでがっかりさせないための要求整理と設計

この記事は

対顧客関係者からの質問に「技術的には可能です」とかそれに類する回答をしてしまうよわよわ開発者に、どういった手順で要望、要求から要件に落とし込んでいくべきかをまとめたもの。

「技術的には可能です」とは

Python: 無限の猿定理を参考に「技術的には可能です」がどのくらい「現実的には不可能」なのかを見える化する というしょうもないことを考えたことがあるのですが、この「技術的には可能です」という有名なフレーズ、言いたいことはつまり「現実的には(結構)不可能です」である場合が多いと思っている。

依頼者 (営業や業務コンサルタント): 「これ実装できますか？」
開発者: 「技術的には可能です」

は、イコール

• お値段はかかる
• 納期はうーん、○ヶ月で大丈夫かな...
• 使い勝手はこんな程度でも許されるよね...？

を暗に含んだ回答であることもあるという理解。この相互理解のあやふやなままプロジェクトが始まってしまうとその○ヶ月後、

依頼者 (営業や業務コンサルタント): 「これ実装できますか？って聞いたじゃない？(想像していたものと合ってない！)」
開発者: 「技術的には可能ですって答えたじゃない？(だから色々制約はあるに決まってるじゃない！)」

のような、かなしいことになる。話は極端だとしても

「顧客が本当に必要だったもの」にならないよう要求を整理する。その「整理」手順を明らかにしたい。

要望、要求確認、要件定義

端的に、設計の方法論。

要望：「こんなシステムがあったら良いな」といったアイディア
↓
要求：システムに実装して欲しい大まかな機能一覧
↓
要件：双方が合意した具体的な機能一覧と実装方法

「要望・要求・要件」の図がわかりやすい。「要求の意図を明確にする重要性と、それを対話によって発見していくプロセスがソフトウェアの複雑性を下げる」ということは、スケールする要求を支える仕様の「意図」と「直交性」 - Qiita でも述べられている。

具体的なチェックリストとしては以下。

鑑みると以下のようになりそう。

1. 要望：解決すべき課題

依頼者に聞いて明らかにすべき回答

現状の課題
ゴール（本来あるべき状態）
現状とゴールのギャップ（解決すべき課題）

2. 要求：システムに実装したい機能

「要望」をもう少しサマリした「やりたいこと」

企画の背景（解決すべき課題）
課題解決に必要なシステムの概要
具体的に実装したい機能一覧

チェックすべきは

• 要求になっているか？
• 顧客の気持ちや背景を記載できているか？
  • 「〜したい」と表現できているか？
  • 顧客が実際に言っていることなどの事実が記載されているか？
  • 「なぜそういう意見がでたのか？」を理解できるように記載できているか？
• 「要件」になっていないか？
  • 具体的な解決方法を勝手にこの段階で記載してしまっていないか？
    • 「(具体的手段、メール送信 等) をできるようにする」と記載していないか？
    • 「(具体的手段、Email 等) の項目を追加する」と記載していないか？
      • それらは、要件としてまとめていくべきもの。

3. 要件：双方が合意した決定事項

依頼者・開発者が協議して完成させる

システムに実装する機能一覧
納期、請求額の目安が記載されるケースも

チェックすべきは

• 要求との接続
  • 要求に基づいて、それを実現するために要件が作られているか？
  • 「〜できること」と表現できているか？
  • 要求との対応関係が明確か？
• スコープ
  • 開発のスコープ（=変更すべき点）が明確であるか？
    　 - 影響範囲は確認できているか？
  • 関係しそうだが、変更してはいけない点に関して記載できてるか？
    　 - 非機能要件は定義されているか？
  • 異常系・準異常系の挙動は定義できているか？
  • 要求を実現できたかどうかを計測できるか？

さらに要件定義の中にも3階層

要件定義の「３階層」

1. ビジネス要件 ... WHAT、企業としての，市場に対する目標や経営上・事業上の解決すべき点。
2. 業務要件 ... WHAT。業務担当者としての，部門の業務を果たす上での課題・目標。
3. システム要件 ... HOW。システムとして，業務要件を満たすために業務モデル内で果たす役割。

要望、要求、要件。例えば

要望: 「イベントを企画する」ことを助けるアプリ

「イベントを企画する」のを助けるアプリ、というようなざっくりとした「依頼者の要望」に対し、
「イベントを企画する」とはどういった作業なのか、をヒアリングする。
すると、日時、場所、会費、等が決まらなければならない作業だ、などということが分かってくる。
それを仮に「TODO」と呼んでいくことにする。

要求: 「イベントを企画するTODOアプリ」を作る

ヒアリングをすすめると、「イベントを企画するTODO」の中の、項目が決まってくる。

例

- 日時を決めたい
- 場所を決めたい
- 会費を決めたい
- 参加人数を決めたい
- リマインドをしたい ... etc

要件: 「イベントを企画するTODOアプリ」要件

要求が決まると、それに対応する形で具体的な方法が決まる。

例

- 日時を決めたい
    - Google Calendarに登録できること
- 場所を決めたい
    - 日時と合わせてGoogle Calendarに登録できること
- 会費を決めたい
    - 日時、場所と合わせてGoogle Calendarに登録できること
    - 期日までに支払い確認ができること
- 参加人数を決めたい
    - 定員を超えたらイベント申し込みを締め切る通知を送れること
    - キャンセルが出たら通知を送れること
- リマインドをしたい
    - メールでリマインドできること

まとめ

言葉は悪いがこんな話

口だけにはなりたくないと格好いいことを言っても、言語化できないものはやはりわかり合えない。「技術的には可能です」は、開発者の側から言語化を放棄していないか反省しないといけない、ということかもとおもう。

「ユビキタス言語」を作るという作業、とても学び足りないなと思う。
以上参考になればさいわいです。