価値提供型エンジニアになるための入門シリーズ、3本目。2本目の顧客理解で整理した教室の困りごとを、使われる仕事へつなげよう。教室の場面と会話は説明用の架空ケースで、実在する顧客や改善実績ではない。
渡したのに、前のやり方が続いている
「動くところまで確認した。なのに、まだ前の一覧を使っているらしい。」
開発を終えて案内を送ると、少し安心する。必要な機能はある。テストも通った。あとは相手に使ってもらえばよいはずだ。それなのに、次の打ち合わせで「まだ触れていなくて」と聞くと、言葉が止まること、ないだろうか。
教室の困りごとは、イベント前に入金状況と案内の送信履歴を別々の場所で確認することだった。そこで、まず一つのイベントについて、確認する一覧と更新する担当をそろえる案を選んだとしよう。新しいシステム全部を作る代わりに、必要な設定と小さな連携だけを用意した。
運営者は「ありがとうございます」と返してくれた。でも、案内を送る担当者は、いつ新しい一覧へ切り替えるか聞いていなかった。間違えるのが怖くて、慣れた名簿と送信履歴を開き直している。
エンジニアは「説明したはずなのに」と感じる。追加の作業が増えるのも不安だ。かといって聞き直すと、自分の納品が足りなかったと認めるようで、少し気まずい😔
ここで見るのは、誰が悪かったかではない。動くものを用意すること、現場で使えること、困りごとが変わることを、分けて確かめる。 どこまで進み、どこが止まっているかが見えれば、次の一手も小さくできる。
小さく届けるには、試す仕事と約束を小さくする
「小さく作る」と言うと、画面や機能を減らす話に聞こえるかもしれない。でも、画面が一つでも、現場の全イベントを一度に切り替えれば影響は大きい。小ささは、使う人、対象の仕事、期間、問題が起きたときに戻せる範囲でも考えたい。
教室なら、次のイベント一件と、案内を送る担当者一人を最初の対象にできる。過去の名簿や他のイベントは変えない。新しい一覧に残すのは、案内の対象と状況を判断するために必要な情報に絞る。
次のイベント一件で、案内の前にこの一覧から状況を確認できるか試しましょう。最初の操作は一緒に見て、イベント後に一度振り返るところまでを今回の範囲にしたいです。
こう話せれば、相手はいつ、誰が、何を試すか分かる。こちらも、いつまでもすべての問い合わせへ対応する約束を先に作らずに済む。
始める前に、四つだけそろえる。
- 対象：どの仕事を、誰が、いつ試すか。
- 確認：何が動けばよく、何が変われば助かるか。
- 困ったとき：連絡先と、止める・戻す判断をする人は誰か。
- 終了：いつ振り返り、追加の対応をどう相談するか。
「案内前の照合が減ると助かる」がまだ曖昧なら、今の一回の仕事を見ておく。開いた画面、確認に使った時間、迷って問い合わせた点など、負担に近いものを一つ選ぶ。確認方法は相手が続けられる大きさにする。
GOV.UKのService Standardは、成功した状態と、その状態を確かめる指標を利用者調査と合わせて考えるよう勧めている。教室の例で使う時間や迷いの記録は、その考え方を小さく置き換えたものだ。大きな数値目標を作るためではなく、最初の困りごとへ戻るために置く。
小さく届けるとは、品質を後回しにすることではない。確かめられる仕事の単位と、相手との約束を小さくすることだ。 情報の扱いや必要な権限、失敗したときの影響は、小さい変更でも確認する。
「動いた」「使えた」「役に立った」を順番に見る
確認を一度にまとめると、「テストが通ったから大丈夫」「喜んでくれたから成功」と言いたくなる。早く区切りたい気持ちは自然だ。でも、同じ「大丈夫」でも、見たものが違うと、受け取る人の判断も変わる。
最初は、合意した条件で動くかを見る。教室の一覧なら、対象者と案内の状況が正しく表示され、必要な人だけが見られるか。未入力や重複した記録ではどうなるか。実際に使う環境で、案内までの主要な操作を一度通す。
AIへコードやテストの作成を任せる場合も、報告の文章だけで確認を終えない。依頼した条件と変更内容が合うか、最後の変更後にどのチェックを実行したか、どの操作が未確認かを、人が読める形で残す。詳しい見方はAIの完了報告を確かめる3つの証拠で扱っている。
次は、担当者が自分の仕事の中で使えるかを見る。作った人が代わりに操作するのではなく、担当者に案内を送る場面をたどってもらう。練習なら必要な情報を含まない確認用のデータを使い、実際の送信や本番の更新は、許可された範囲だけで行う。
教室の例では、担当者は一覧を開けたが、「入金待ちの人にどの案内を送るか」で止まった。ボタンが動かないわけではない。仕事上の判断が、一覧を渡すだけでは伝わっていなかったのだ。
この状態のときは、どちらの案内を選ぶか迷うんですね。今の決め方を確認して、一覧と手順にそろえておきましょう。
こう聞けると、相手も「使いこなせなくてすみません」と謝らずに困りごとを話しやすくなる。説明を長くするより、止まった場所を一つ直せばよいこともある🙂
最後に、最初の負担がどう変わったかを見る。
| 確かめること | 教室の例で見るもの | それだけでは分からないこと |
|---|---|---|
| 動いた | 一覧・状態の更新・権限・主要操作 | 担当者が日々使えるか |
| 使えた | 担当者が案内の判断と操作を進められるか | 照合の負担が減ったか |
| 役に立った | 案内前の確認時間、迷い、漏れの心配の変化 | 別のイベントや長期間でも同じか |
前後を比べるなら、対象件数や担当者などの条件も残す。一回だけ早く終わっても、一覧のおかげと断定しない。イベントの規模が違ったのかもしれないし、慣れた人が対応したのかもしれない。数字と、本人がどこで楽になったと感じたかを合わせて聞く。
記録を取れていなければ、「効果なし」や「問題なし」へ置き換えず、未確認と書く。成果を大きく見せることより、分かった変化と残った不確かさを分ける方が、次の判断をしやすくする。
振り返りは、次の仕事を増やすためだけではない
イベント後、「どうでしたか」と聞くのは少し緊張する。役に立っていなかったら、何と言おう。次の改修を頼まれたら、どこまで引き受けよう。そんな不安があると、納品の連絡だけで閉じたくなる。
だから、振り返る日と範囲を先に決めておく。結果を聞くことと、追加作業を引き受けることは別だ。教室の運営者には、最初の困りごとへ戻って尋ねる。
案内前に、別々の履歴を確認するところはどう変わりましたか。前より迷う場面や、まだ残っている手間はありますか。
架空の教室の例では、一覧を開く場所は分かったが、入金待ちへの案内の判断が残っていた。そこで一度に全部を自動化せず、その判断と手順をそろえるところを次の候補にする。対象や費用、対応時期は、改めて相談する。
選択肢には、今の形を続けることも、追加で確かめることも、使うのをやめて別の案へ戻ることも含める。次の開発が決まらなくても、不要な作業や無理な継続を減らせたなら、相手が選べる材料を渡せている。
GOV.UKのService Standardは、公開後も利用者のニーズに合わせてサービスを改善していく考え方を示している。それを日常の仕事へ移すなら、全案件で無期限に支援するという意味ではない。合意した範囲で変化を見て、次にどうするか選べる接点を作ることだ。
今日一つ試すなら、今の成果物について三行だけ書いてみよう。
- 誰が、どの仕事の中で使うか。
- 動作と利用を、どこまで確かめたか。未確認は何か。
- 最初の困りごとの変化を、誰といつ確認するか。
納品の先に一回の確認を置くと、「作ったもの」を「相手の仕事で役立つもの」へ近づけられる。 大きな成果を約束する前に、小さく届けて、本人と変化を確かめる。その繰り返しで、次に何を作り、何を作らなくてよいかも見えてくる🌱
3本を通して見直したくなったら、価値提供型エンジニアの全体像へ戻ろう。案件に合わせた進め方は価値提供の進め方、引き継ぎや確認の境界は納品後の確認を整理するで読み進められる。
