現在の仕事
担当者は講座のスプレッドシートを確認し、メールで返信し、承諾された予約をカレンダーに入力します。この例では、先の顧客からの返事を待つ間に、同じ席を別の顧客にも案内しています。
変えたいこと
担当者が未回答の問い合わせを確認し、席を提示するか判断できるようにしたいと考えています。いつ席が埋まったとみなすかは、まだ決める必要があります。
まず、スタッフが終わらせる必要のある仕事を一つ選びます。何をきっかけに始まり、誰が担当し、どうなれば完了で、どこで困るのかを書きましょう。作るものがまだ決まっていなくても、開発者と話を始める材料になります。

「もっと良い予約システムが必要」という言葉から始めて構いません。次に考えたいのは、誰かが予約しようとしたとき、実際に何が起きるかです。
開発者との最初の話し合いの前に、依頼を受けてから完了するまでの仕事を一つ説明してみてください。困る場面も含めます。ソフトウェアの作り方が分からなくても、普段の言葉で説明できます。
架空の研修会社を考えてみましょう。顧客がメールで、ある講座に二人分の空席があるか問い合わせます。担当者は空席を確認し、顧客に返事をして、予約を記録します。満席なら、代わりに何を提案するかを誰かが決めなければなりません。
これだけでも、役に立つ依頼書の出発点になります。「ダッシュボード付きのポータルを作る」だけでは、誰が使い、何を終わらせたいのか、何をもって予約成立とするのかを開発者が推測することになります。
英国政府のサービス構築前に問題を理解するためのガイドでは、利用者、利用者がたどる一連の流れ、制約を調べることを勧めています。そこで説明される政府向けの進め方は、その現場に固有のものです。この研修会社で最初に考えたいのは、どうすれば顧客が講座を受講できるか、ということです。
実際に担当している人に、最近の事例を最初から説明してもらいましょう。まず見聞きしたことを書き、その後で変えたいことを記します。架空の会社なら、次のようなメモになります。
担当者は講座のスプレッドシートを確認し、メールで返信し、承諾された予約をカレンダーに入力します。この例では、先の顧客からの返事を待つ間に、同じ席を別の顧客にも案内しています。
担当者が未回答の問い合わせを確認し、席を提示するか判断できるようにしたいと考えています。いつ席が埋まったとみなすかは、まだ決める必要があります。
左側は現在の仕事、右側は変更案です。まだ決めていないことも見えるようにしています。スタッフによってやり方が違う場合には、この区別が大切です。返事を待つ間に席を仮押さえする人もいれば、席を空いたままにする人もいます。開発者にルール化を頼む前に、両方を記録してください。
講座への問い合わせなら、次のような項目をまとめられます。
これらは架空の例に対するメモ案であり、どの研修会社にも当てはまる確定ルールではありません。自社で「合意した予約」が何を意味するか確認しましょう。席は提案したとき、顧客が承諾したとき、支払いを終えたときのどれで埋まるのでしょうか。問いとして書けば、一緒に決められます。
架空の記録を使った小さな例も加えます。5月12日の講座Aには空席が一つあり、問い合わせBでは二人分を希望しています。期待する対応と、誰が判断するかを書いてください。開発者は具体的な状況について質問できます。
仕事の説明には架空の名前と記録を使えます。実際のサンプルを共有する場合は、共有を許可されたものだけにし、不要な個人情報や機密情報を除き、適切な渡し方を合意してください。
必須条件: 担当者が未回答の問い合わせを確認できること。そうでなければ、共有の受信箱を探して未完了の仕事を見つける必要がある、と理由も書きます。
話し合うアイデア: 顧客が別の日付を自分で選べるようにする案もあります。どんな仕事が発生し、誰の役に立つかを考えるまでは、可能性として扱います。
未決定の問い: いつ席を確保し、誰が確保を解除できるのか。業務上のルールを開発者に暗黙のうちに決めさせず、判断する人として研修責任者を明記します。
実際にある制約も含めます。既存のカレンダーを残す必要があるかもしれません。顧客情報を見られるスタッフを限る必要や、決まった日までに特定の講座に対応する必要もあり得ます。確定した制約とその理由を書き、日付や予算がまだ希望ならそう示します。
「使いやすくする」には具体例が必要です。この会社なら、担当者が問い合わせから返答まで追え、まだ回答していない問い合わせをすべて見つけられる状態です。通常の予約と残席一つのケースを使い、完成したものが何を示せばよいか話し合いましょう。
測りたい今の問題も記録できます。たとえば、未回答の問い合わせを探すために複数の道具を調べる頻度です。何を観察済みで、何をまだ確認する必要があるかを分けて書きます。比較の基準を確かめてから、目標を決めてください。
開発者に送る前に、実際に仕事をしている人に依頼書を見せましょう。抜けた手順を指摘したり、一見簡単な近道がなぜ困るかを説明したりできます。未解決の点は、それぞれ回答する担当者を付けて文書に残します。
私たちは業務向けのカスタムソフトウェアを開発しています。プロジェクトについて相談するなら、今の仕事、変えたいこと、具体例、残っている問いを持ってきてください。仕事内容に沿って範囲や取引条件を話し合えます。依頼書はその話し合いの出発点であり、技術的な調査と設計はその後も必要です。
まずは仕事の内容、担当する人、使っている道具、必要な結果を説明できます。技術設計は調査の後に進められます。分かっている技術上の制約があれば、なぜ重要かとともに記してください。
実際に見たやり方をそれぞれ書き、関係者に違いの理由を聞いてください。必要な違いと、まだ判断が必要な違いを区別し、決められる人を明記します。
問い、今分かっていること、答えを出せる人を書きます。たとえば「席は提示時、承諾時、支払い時のいつ埋まったとみなすか」です。合意済みの必須条件とは分けてください。
前回のニュースレター:すでにお持ちのサブスク型サイトやアプリで、もっと収益を上げる方法。
その前の回:本物の成功事例から AI のたわ言を見抜く方法。
気になりますか?
毎週 もしくはお知らせいただければ、ご希望に合わせて調整します。いかがですか?