このレッスンでは、前の3モジュールで学んだ考え方を1つの業務に集約し、要件シートという1枚にまとめます。
前の3モジュールでは、会話で答える型・手順で処理する型・外部連携を、それぞれ単独に学びました。 本モジュールは、その3つを実際の1件の業務に当てはめて、同僚が使う状態まで仕上げます。
このモジュールの終着点を確認する
このモジュールのゴールは「動くものを作る」ではなく「実際に使われる」ことです。 前の3モジュールは、それぞれの型を1つずつ動かすところまでが範囲でした。ここからは、企画・設計・実装・配布・効果測定・運用移管までの一連を通します。
| # | レッスン | やること |
|---|---|---|
| 1 | 業務を選ぶ | 要件シートを作る(このレッスン) |
| 2 | 設計に落とす | 実装パターンとノード構成を決める |
| 3 | 組み立てる | 設計どおりにMVPを実装する |
| 4〜6 | 配布・効果測定・運用移管 | 同僚に使ってもらい、数字で効果を確かめ、保守体制を決める |
自分が今どこにいるか見失ったときは、この表に戻ってください。
選定基準で候補を絞る
業務を選ぶ基準は3つです。 基準を決めずに選ぶと、思いつきで作り始めて、途中で対象を変えることになります。
| 基準 | 確認すること |
|---|---|
| 頻度 | 週に1回以上など、一定の頻度で発生しているか |
| ルール化できるか | 担当者の勘ではなく、手順や条件として言葉にできるか |
| 影響範囲 | 間違えたときに、どこまで影響するかを言えるか |

3つとも満たす候補を選んでください。「頻度は高いが、判断の基準を言葉にできない」業務は、いまは対象から外してください。 言葉にできない判断を仕組みに任せると、誤った結果を機械的に量産します。
要件シートで作る前に決める
要件シートは、実装を始める前にまとめる1枚です。 何を作るかを先に言葉にしておくと、後で「思っていたものと違う」が起きにくくなります。
| 項目 | 書く内容 |
|---|---|
| 対象業務 | 選んだ業務の名前 |
| 使う人 | 誰が使うか(自分だけか、部内の同僚か) |
| 入力 | 何を渡すか |
| 出力 | 何が返るか |
| 成功の基準 | 何をもって「うまくいった」とするか |
成功の基準を先に決めることが最も重要です。 基準が無いと、効果測定のレッスンで比較する相手がありません。「時間が減った気がする」ではなく、「対応時間が1件あたり5分減る」のように、数えられる形で書いてください。
最初の一歩をMVPに絞る
思いついた機能を全部、最初から作らないでください。 一度に作ろうとすると、どこか1つでも詰まった時点で、全体が止まります。
MVP(必要最小限の機能)とは、成功の基準を確かめるために欠かせない機能だけに絞った最初の版のことです。 あると便利な機能は、MVPが動いてから足します。
| 含める例 | 見送る例 |
|---|---|
| 資料に基づいて答える | 複数の言語に対応する |
| 対応した件数を記録する | 過去の対応履歴を検索できるようにする |
自分の候補について、成功の基準を確かめるために必須な機能だけを挙げてください。それ以外は、いったん見送りリストに移しておきます。
通し事例を確認する
本モジュールでは、**「経費精算に関する問い合わせへの一次回答と、対応件数の記録」**を通し事例として使います。経理部が、同じ質問に繰り返し答えている状況を想定した例です。
| 項目 | 内容 |
|---|---|
| 対象業務 | 経費精算に関する問い合わせ対応 |
| 使う人 | 経理部の同僚 |
| 入力 | 同僚からの質問 |
| 出力 | 資料に基づいた回答、および対応件数の記録 |
| 成功の基準 | 経理部への同種の問い合わせが1週間あたり5件以上減る |
この事例は、資料に基づいて答える機能と、対応件数を記録する機能の両方を、成功の基準を確かめるために必要としています。だからこの2つが、この事例のMVPです。 次のレッスンから、この事例を使って設計を説明します。実際に進めるときは、自分が選んだ候補に置き換えてください。