今回は実際にクライアントから受けた相談（詳細を伏せつつ、フィクションも含まれています）をベースに、どういう風に解決策を考えていったかという内容です。

相談を受けた際に、黄信号が点灯するケースにはある特徴があります。

それは、相談の段階で「手法を固定」している場合です。

何かの結果を得るために必要な条件について「要件」という言い方をします。要望が実現されるのであれば手法をひとつに限定する必要はありません。

先に手法が指定されてくる場合は、依頼者側になんらかの事情があると考えていいでしょう。

その事情を紐解いていく時に効果的なのが「やらなくて良い方法から考える」です。

相談ケース

来店の予約受付システムを構築したいという依頼。

前日までに、空き状況を確認して予約。仮予約を受けた後に、店舗側から顧客に最終確認をして予約確定。

店舗側で、受付できる日時や提供可能なサービスの選択は制限できるようにしたい。

サービスを提供している店舗は複数ある。

カウンセリングが必要と考えたポイント

• 初回の打ち合わせで非常に作り込まれた仕様書を持参してきた

• ウェブフォームを想定しており、項目のレイアウトや選択肢、自動返信の文面まで定義済み

• 打ち合わせの最初が「こういうものが欲しい、いくらかかるか？」から始まった

すばらしい仕様書･･･だけど

予約受付は、有人であれば電話や来店などで対応可能でIT化しなくても実現できることです。

ウェブフォームで事前予約という手法は、無人化という意味を含みます。

友人であれば、現場の判断でルール外のことも対応できるかもしれません。対して、無人化するには、細かく条件や状態を定義しておく必要があります。

それを踏まえると、仕様書として作り込めている点はすばらしいですし、業務の流れを把握している人が携わっていると分かります。

ざっくりと仕様を確認してみました。

• 事前予約のウェブフォーム（項目など定義済み）

• 顧客が空き状況を確認できる

• 空き状況や利用可能なサービスは店舗でコントロールする

• フォームの入力完了後は自動返信（仮予約）

• 店舗から顧客に最終確認して予約確定とする

受付の仕組みを用意するには、事前に店舗側の情報を設定しておく仕組みが必要なので、思ったよりも規模が大きくなりそうです。

• 店舗が空き状況を管理、公開できる仕組み

• 店舗が提供サービスを管理、公開できる仕組み

• 店舗が予約状況を管理できる仕組み

• システム利用者を管理できる仕組み

店舗カレンダーとタイムテーブルのようなものが必要で、サービスはいわゆる商品管理。予約状況を管理ということは顧客管理も検討が必要そうです。

店舗スタッフの権限によって、できる・できないが必要ならユーザー管理も出てきます。

仕様書をざっと拝見した段階でも、キャンセルはどうするんだろう？決済は？と、イレギュラーを含めて全体の流れについての質問事項が頭の中を駆け巡ります。

おそらくプログラマーだと職業病と言いますか、こういった資料を眺めた段階でどういう機能と運用体制が必要で、期間と費用はこのぐらいと金額の目処も大まかにつきます。

既成パッケージがあるならともかく、ゼロから作るのであれば数万・数十万に収まりそうには見えません。

いきなり期間と費用や、仕様への質問を始めるのは危険です。

なぜなら、この仕様書の前に必要なものが提示されていないからです。

仕様より何より大事なもの「要件」

発注側の落とし穴としてよくありますが、なぜこの話が持ち上がったか経緯や理由を文書化していません。

日々の業務を担当している側には「当たり前」となっている暗黙知が積み重なっているから、わざわざ書き出していないのも分かります。

ですが、外の人間と協業するのであれば、当たり前になっていることを共有しておかないと、適切な解決策を提示してもらえない可能性が出てきます。

暗黙知も含め業務知識を持っている依頼者に対して、私の業務に対する理解度は圧倒的に低いのです。

何がまずいかというと、相手が提示した条件を正解だと思い込んだ状態で聞くことになります。

確かに業務知識は依頼者の分野です。ですが、ウェブフォームなどITを前提としたシステムはこちらの分野です。

お互いに情報の不足がある状態で手法の話を進めると、不適切な解決策を実装してしまう可能性が高くなりがちです。

依頼の発端となった原因について、誰もまだ正解は分かっていません。しかも、作る側には原因の共有すらされていません。

仕様は後々に必要となります。ですが、依頼の発端となった原因が織り込まれた要件が先です。

IT化とは再現ではなく見直し

今回の仕様書のように作り込まれた資料を目の当たりにすると、議論のスタートが資料ありきになってしまいます。

IT化というと、現状をコンピューター上で再現すると考えがちかもしれませんが、まったく違います。

今まで人海・アナログで取り組んできたものをIT化、つまりデジタルの世界に持ち込むことになります。

これによって、今まで省略したり考えずに済ませてきたことまで網羅する必要も出てきます。いわゆる現場の判断というものも明文化しなくてはなりません。

大変に感じるかもしれませんが、業務自体を根底から見直すタイミングでもあるのです。

さすれば自ずと質問は決まってきます。「こちらの仕様、どういった経緯で作られたのでしょうか？」と。

すると、大概は「現場からの要望を受けて、こういうものを作れば良いのではと社内で検討しました。」といった旨の回答が来ます。

確かにその通りですが、現場についてこちらは知らないことだらけです。

スタートラインを揃えるためには、どういう内容についてヒアリングしていけばいいのでしょうか？

ヒアリングすべきは経緯

ここから踏み込むべきは、検討の経緯ではなく現場の経緯です。どういった状況だったのかを知ることで要件の輪郭が見えてきます。

さらに私は質問を続けます。「現場からの要望というのは、どういった内容だったのでしょうか？」

いわく「当日、予約なしで来店されたお客様に、ちょうど空きがなく断ってしまうことが多いので、事前予約できるようにして欲しい」と。

結構な件数を断っていて、機会損失と経営側は捉え予約受付システム構築という発想になったそうです。

ヒアリングを続けるには、いくつか分割したいポイントが出てきました。

• 当日、ということは事前に把握しづらい要因がある？

• 予約なしで来店、というのは1日あたりどのぐらいの割合か？

• ちょうど空きがなく、ということは何かにタイミングを左右される？

• 断ってしまった場合、再訪はある？

その場でこんな分割できるものだろうか？と思われるかもしれません、ある思考法に沿ってヒアリングしていますので、身につけば形式的に抽出できます。

まとめて質問するより、細かく分けて順を追って質問すると、回答する側も一緒に整理できます。

• 当日というのは、「今日は天気がいいから」と天候に影響されるサービスのため

• 予約なしで来店は、およそ3割ぐらい。週末に集中しやすい。

• ちょうど空きがないタイミングは、提供サービスによって時間のかかり方がまちまち（最短10分、最長で2時間）なのと、スタッフがシフト制のため当日の状況とかみ合わない時に起きる。当日まで混雑状況は分からない。

• 断った場合、その日は他店にいくかもしれないが、近いところへいく性質なので次の機会も近場の人はまずここに来る

なるほど、情報が大分そろってきました。

答えは誰が持っている？

回答も分かりやすく、現場を理解しているからこその内容でした。

どんなテクノロジーを盛り込んだとして、使うのは結局のところ人です。

では、それぞれに「どういう状況だったらOKか？」を一緒に考えてみれば答えが出そうです。

登場人物はざっくりと顧客、店舗スタッフの2人です。

現場のことを理解している人は、顧客の心理や行動パターンもよく理解しています。ここはもうダイレクトに聞いてしまいます。

「顧客はどういう状況が良いのでしょう？」

• 今から店に行こうと思ったときに空いてると分かる

• 待ち時間がどのぐらいか分かる

「顧客はどういう状況が困るのでしょう？」

• 行ってみたら空きがなかった

• 待ち時間が思ったよりも長かった

顧客はやはり「当日、今」という時間軸で考えるようです。当日の天気に影響されるという性質もありますし。

となれば事前予約という発想は顧客のリクエストと相性が悪そうです。

天気予報をチェックして、空き状況を見て…と念入りに行うよりも気軽に受けたい性質のサービスなら尚更でしょう。

そうなると、1週間とか1ヶ月先まで予定を公開しても使ってもらえなさそうです。

では次、店舗スタッフはどういう風に考えるのでしょうか？

欲しいものが必要なものとは限らない

ここも同じようにダイレクトに聞いてしまいます。

「店舗スタッフはどういう状況が良いのでしょう？」

• 顧客が当日に受けられるサービスを分かった上で来てくれる

• 顧客がおよその待ち時間を分かった上で来てくれる

• 混んでたなら顧客が日程を改めてくれる

「店舗スタッフはどういう状況が困るのでしょう？」

• 顧客がリクエストするサービスに対応できる店舗スタッフが当日いない

• 当日できるサービスと待ち時間の説明で店舗スタッフが顧客に対応する時間が長くなってしまう

シフト制なので店舗スタッフが当日できることに限界があります。

また、営業時間が決まっているので、顧客1人あたりにかけられる時間も限度があります。いわゆる回転率を考えなくてはなりませんん。

ますます事前予約という方法は合っていないことが分かりますし、スピードや一覧性が重要と思われます。

ここまで話したところで、お互い整理がついてきました。

最初に欲しいと言われたものは事前予約のウェブフォームでしたが、重要人物である顧客と店舗スタッフにとって必要なものはどうやら違うようです。

ここまで洗い出して、初めて「要件が分かった」と言えるでしょう。

機会損失を減らしつつも、店舗側の事情も汲むためには別なアプローチが必要ということで互いにアイディアを出し合うこととしました。

そのIT化は本当に必要ですか？

要件を洗い出してからアイディアを出し合うと、解決策はスムーズに出てくるようになります。

必要なものはシンプルでした。

• 顧客に必要なのは、店舗で受けられるサービスと混雑状況が当日に分かること

• 店舗スタッフに必要なのは、顧客への説明時間を短縮できること

最初、業務用タブレットやセンサー感知のIoTといったテクノロジーありきのアイディアも出ましたが、即効性が高く、IT化が本当に必要か検証するためとして落ちついた結論がここでした。

• 当日、対応できるサービスが一目で分かるメニューにあたるものを用意できるか検討する

• 現在の待ち時間が分かる、カンバンにあたるものを用意できるか検討する

費用をかけるなら電光掲示板などになるのでしょうが、費用を抑えて同じようなものを用意することもできそうです。

当初の事前予約のウェブフォームより、イメージしやすいものになりました。

後日談として、業務の流れを見直しつつ社内で議論を重ねた結果、やはりシステムは必要という結論で再度相談が来ております。

最終的な判断は同じかもしれませんが、お互いに情報不足だった点を補った後というのが大きな違いです。

何が必要で、どう解決すべきか焦点が定まっています。

改革の前に改善、改善の前に「小さくテスト」

IT化、システム導入という言葉には幻想がつきまといます。

「これがあれば、状況が一気に変わるはず！」そんな期待を持って相談いただくことも少なくありません。

状況が一気に変わるというのは改革です。しかし、大がかりなものになることは確実です。

であれば既存を改善してという考えになりますが、改善のつもりが思った通りにはならなかったというオチもあり得ます。

改善策を考えるにも現場からのヒアリングが必要ですし、実際の業務を回すにも教育だったり配置の見直しなど付随するものがあります。

自分のアイディアが正しいのか、効果があるのか、それは実行してみるまで分かりません。

現場の変化を最小限にしつつ効果を検証するには、とにかく「小さくテスト」できる手段を考えることです。

これならすぐにできそう！そういう手応えは試す価値があります。

事業規模の大きさは関係ない、というのは自分の経験からですが。

改革は壮大すぎて理解しにくく、改善は現場の痛みを伴います。小さくテストするためのアイディアは、どうすれば思いつくことができるのでしょうか？

私はたったひとつの視点を心がけています。

やらなくて良い方法から考えるとアイディアが出る

今回のように「こんな手段が欲しい」と相談されたとします。

まず私が考えるのは「その手段をとらずに解決できるか？」ということです。

アイディアがすぐ出るわけではありません。戒めのようなもので、やらなくよい方法を考えようとすると、足りない情報に気付きやすくなるのです。

欲しいものではなく必要なものを見極めるためには、スキルより経験より情報収集がまず先です。

かといって、よくできた資料を正しいものとして情報収集を始めていたら、必要なものが何か分からないままだったかもしれません。

やらなくて良い方法から考える。

それが問題解決への第一歩となります。