価値提供型エンジニアになるための入門シリーズ、2本目。1本目の全体像で出てきた教室の相談を、もう少し近くで見ていこう。教室の場面と会話は説明用の架空ケースで、実案件や成果の実績ではない。
作れそうな相談ほど、返事を急いでしまう
「予約システムがほしいと言われた。これなら自分でも作れそうだ。」
開発者にとって、具体的な機能が出てくる相談は少し安心する。フォーム、一覧、通知。必要な画面が浮かぶと、曖昧だった仕事が急に見積もれそうになる。早く提案を出して、頼れる人だと思ってもらいたくなること、ないだろうか。
教室の運営者も、最初はこう言っていた。
申込から連絡までできる予約システムがあると、楽になると思うんです。
エンジニアは「できます」と言いかける。でも、まだ申込後の仕事を見ていない。今のフォームがどこまで使えているか、どの連絡に時間がかかるか、使う人は誰かも分からない。
聞き返すのは、少し怖い。「それくらい分かるでしょ」と思われないか。話を止めたら、相手の期待が冷めないか。そこで画面の説明へ進むと、自分の得意な話には戻れる。ただ、相手の困りごとからは離れてしまう😅
「予約システムがほしい」は、相談の入口であって、作るものが確定した合意ではない。 相手の要望を否定せずに、その要望が出てきた仕事を一つ聞いてみる。
その仕組みで、特に楽にしたいのはどの作業ですか。直近のイベントで、申込が来てから案内を送るまでの流れを教えてもらえますか。
「それは課題ではなく解決策ですね」と採点する必要はない。相手は困りごとを伝えるために、自分なりの言葉で方法を挙げてくれた。その言葉を手掛かりに、どんな場面を変えたいのか近づいていけばいい。
理想の機能より、最近の一回を一緒にたどる
「どんな機能が必要ですか」と聞くと、会話は要望の一覧になりやすい。あれも便利、これもあるとよさそう。相談が盛り上がるほど作る範囲が広がり、肝心の困りごとは見えにくくなる。
そこで、直近の一回に戻る。申込が入ったとき、誰が何をしたか。何を開き、何を照合し、どこで手が止まったか。相手が答えやすいところから順番に聞く。
教室の例では、運営者がフォームの通知を見て、名簿を更新し、別の画面で入金を確認していた。案内はメールで送る。ところが名簿には送信済みかどうかを残す欄がなく、直前になると送信履歴を開き直している。
申込を受けるところより、案内を送った人と、まだの人を確かめるところで手が止まるんですね。
そう書き返すと、運営者は「そうです。ただ、入金待ちの人には違う案内を送るので、そこも迷うんです」と補足できる。最初から正しく理解することより、相手がこちらの理解を直せる形で返すことが大切になる。
問いは、次の三つを軸にすると整理しやすい。一度に全部聞く必要はない。
- 誰が、いつ、どの作業で困っているか。
- 今は、何を見て、どう判断し、どんな手間がかかっているか。
- 何が変われば「助かった」と言えそうか。
運営者が契約や費用を決める人でも、実際に案内を送るのは別の担当者かもしれない。参加者の側にも、案内が見つからない、重複して届く、といった困りごとがあるかもしれない。費用を決める人、毎日使う人、影響を受ける人を、同じ一人だと決めつけない。
画面や記録を見るときは、個人情報が入っていない例や、必要な部分だけを示してもらう。会話のために顧客名簿を丸ごと受け取る必要はない。録音や記録の共有も、相手に確認してから行う。
GOV.UKのService Standardは、利用者が達成したいことと、その背景を理解し、早い段階で仮定を確かめることを勧めている。ここでの問いは、その考え方を小さな業務の相談へ置き換えたものだ。質問の数を増やすためではなく、相手が変えたい仕事を見失わないために使う🔍
要望、分かったこと、次に確かめることを混ぜない
話を聞いたあと、すぐ「やはりシステム化しましょう」とまとめたくなるかもしれない。顧客理解のために時間を取ったのだから、きれいな結論を出したくなる。でも、結論を急ぐと、自分の推測が相手の希望にすり替わる。
教室の相談を、三つに分けて短く書いてみよう。
| 種類 | 教室の例 |
|---|---|
| 相手の要望 | 申込から連絡まで扱える予約システムがほしい |
| 会話で確認できたこと | 入金状況と案内の送信履歴が別々で、イベント前に照合している |
| まだ確かめたいこと | 照合の頻度と時間、別の担当者の作業、今のサービスの設定で改善できる範囲 |
「一覧に状態を残せば楽になる」は、ここから考えた案だ。まだ効果が確認できた事実ではない。相手へ返すときも、その違いを残す。
今の話では、入金と案内の状況を照合するところに負担がありそうです。まず一つのイベントで、同じ一覧から状況を確認できると楽になるか、試す案を考えています。今のサービスで対応できるかは、まだ確認が必要です。
「分からない」を書くと、自信がない人に見えそうで落ち着かない。でも、ここで未確認を置ければ、相手も「担当者へ聞いてみます」「そこは今のままでよいです」と判断を足せる。確認できた範囲を正確に言うことが、提案を一緒に直す余地になる。
次に、同じ困りごとへ届く方法を比べる。
- 運用を変える：案内の状況を一覧に残し、更新する担当とタイミングを決める。
- 既存サービスを使う：今のフォームや管理機能で状態をそろえられるか確認する。
- 開発する：手作業や設定では難しい部分だけ、連携や画面を作る。
選びたいのは、機能が最も多い案とは限らない。日々の手間、費用、情報の扱い、困ったときに維持できるかを比べる。既存サービスにも料金や機能の制限があるので、未確認のまま「それで全部できます」と約束しない。
運営者が複数イベントを同時に扱うなら開発が合うこともある。一方、一回ずつ少人数で開く教室なら、一覧と担当の決め方だけで確かめられることもある。作らない案を検討するのは、開発の仕事を軽く見るためではない。技術が必要な場所へ、時間と費用を使いやすくするためだ。
次の約束は、完成形より「何を確かめるか」
会話の終わりに「では作ってみます」と返すと、気持ちよく終われる。その一方で、相手は完成を待ち、こちらは調査や試作のつもりで動き始めるかもしれない。段階が違うまま期待だけが膨らむと、あとで言い直すのが苦しくなる。
教室の例なら、次は一つのイベントの案内業務を対象に、運用変更と既存機能の案を整理するところまでに区切れる。実施する範囲、費用の有無、使う情報、返す日を話しておく。
まず次のイベント一件を対象に、今の仕組みで試せる案と、開発が必要な案を比べて返します。今日は作業開始の約束ではなく、進め方を考えるための確認までにしましょう。
調査を依頼されるなら、その調査の条件を決める。本番に触るなら、対象環境と操作の許可を確認する。ここで細かいことを聞くのは、相手を疑うためではない。お互いが同じ段階を待てるようにするためだ。
今日の一歩として、直近の相談を三行にしてみよう。
- 相手は何を作ってほしいと言っていたか。
- その背景で、誰のどの仕事が止まっていたか。未確認なら、次に聞く問いを書く。
- 何が変われば助かるかを、一度相手に書き返す。
すぐ解決策が出なくてもいい。相手から「そこが困っていた」と返ってくれば、機能の一覧より先へ進めている。困りごとを一緒に整理できると、提案は「何が作れるか」から「どんな変化を選ぶか」へ進む。
次は、シリーズ3本目の小さく届けて、役に立ったかを確かめるへ。選んだ案を、使われる仕事へつなげよう。提案の伝え方を深めたいときは、言い方より順番を見直すも近い。
相手の仕事を知るための質問は、能力不足の告白ではない。最初の「できます」を少し待って、一つ確かめる。その方が、相手も自分も無理のない選択をしやすくなる🙂
