価値提供型エンジニアになるための入門シリーズ、1本目。まずは、技術を誰かの仕事の変化へつなぐ全体像から始めよう。
「何でも作れます」の先で、言葉が止まる
「開発ならできる。でも、相手に何を提案すればいいんだろう。」
コードを書く経験はある。AIを使えば、試作も前より早く作れる。なのに、知り合いの事業者から「仕事を少し楽にしたい」と聞いた途端、何を話せばいいか分からなくなる。そんな場面、ないだろうか。
技術の説明ならできる。予約フォームも、管理画面も作れそうだ。でも、相手が欲しいものを聞いて、そのまま作ればよいのか。使われなかったら、どこまで自分の責任になるのか。考えるほど、最初の一言が重くなる😔
ここから出てくる教室の場面は、考え方を説明するための架空ケースだ。実在する顧客、受注、成果の実績を示すものではない。この3本では同じ教室を追いながら、仕事の進め方を少しずつ具体化する。
教室の運営者は、イベントの申込を受け、入金を確認し、参加者へ持ち物や日時を連絡している。エンジニアはその様子を聞いて、「予約システムなら作れます」と返しそうになる。ところが運営者の話は、少し違った。
申込自体は今のフォームで受けられているんです。困るのはその後で、誰に連絡したか、毎回あちこち確認していて。
作れそうなものと、相手が困っている場所が、まだつながっていない。だからといって技術が無駄だったわけではない。技術を使う場所を決めるために、相手の仕事へもう一歩近づく必要がある。
ValueGateでは、顧客の困りごとを理解し、方法を一緒に選び、使える状態で届け、役に立ったかを確かめるエンジニアを「価値提供型エンジニア」と考える。資格名や、人の能力を採点する呼び名ではない。仕事をどう進めるかの姿勢だ。
頼られるのは、全部を引き受ける人とは限らない
「顧客の役に立つ」と聞くと、営業も見積もりも開発も運用も、一人でできる人にならなければ、と思うかもしれない。頼られたい気持ちがあるほど、「できます」と言いたくなる。でも、その約束を増やすと、自分だけで抱える仕事も増えてしまう。
教室の例なら、運営者が望んでいるのは、すごいシステムを持つことより、申込後の確認と連絡が滞らないことだ。既存フォームの設定を変える、一覧の見方をそろえる、足りない部分だけ開発する。役に立つ方法は一つではない。
今の受付は使えているんですね。連絡までの流れを見せてもらえますか。新しく作る必要があるかも、そこから一緒に考えたいです。
この返事には、まだ派手な提案がない。それでも、相手は何を話せばよいか分かる。こちらも、確認していない仕事を先に約束せずに済む。
「頼られる」は、頼まれたことを何でも引き受けることではなく、次の判断を一緒にできることでもある。 分からないことを言う、選択肢を比べる、協力が必要なところを早めに伝える。その行動が、仕事を前へ進める材料になる。
会社員なら、相手は直接契約した顧客だけでなく、社内の業務担当者やプロダクトの利用者でもよい。副業やフリーランスなら、自分で話を聞ける事業者が相手になることもある。独立やPMへの転向は、この考え方を試すための必須条件ではない。
専門家への相談が必要な課題なら、共有できる情報と相談先を確認する。顧客の情報を勝手に渡さず、誰が何を判断するかも話しておく。技術を深めることと、必要な協力を選ぶことは、両方あっていい。
一つの困りごとを、使われるところまで追ってみる
全体像は、難しい言葉を覚えるより、一件の相談を追うと見えやすい。教室の話なら、次のようにつながる。
| 場面 | エンジニアが確かめたいこと |
|---|---|
| 相手の話を聞く | 誰が、いつ、どの作業で困っているか |
| 方法を一緒に選ぶ | 運用変更・既存サービス・開発のどれが合うか |
| 実現して確かめる | 合意した範囲が動き、必要な情報を守れるか |
| 現場へ届ける | 担当者が実際の仕事の中で使えるか |
| 変化を振り返る | 最初の困りごとがどう変わり、何が残ったか |
運営者と話すと、負担は「フォームから名簿へ転記すること」より、「入金確認と案内の送信状況が別々の場所にあること」に集中しているかもしれない。そこで、まず一つのイベントについて、確認する一覧と担当者をそろえる案を考える。
いきなり全部を自動化しない。次の一回で困りごとを確かめられる大きさに区切り、必要なら足りない部分を開発する。作業の範囲、費用、扱う情報、確認する日を先に話しておけば、「少し見るつもりだったのに、ずっと対応している」を減らしやすい。
GOV.UKのService Standardは、決まった解決策から入る前に利用者と課題を理解し、既存の方法やサービスも検討する考え方を示している。政府サービス向けの基準であり、小さな教室への適用義務という話ではない。ここでは、その順番を日常の相談に置き換えている。
この進め方には、実装の経験がそのまま効く。データの扱いを考える、壊れやすい条件を見つける、変更の影響を見積もる。顧客の話を聞いたあとなら、何にその技術を使うとよいかも判断しやすくなる🔍
ただし、完成した一覧を渡すだけで終わると、運営者は使い始める時間を取れないかもしれない。自分は分かっている操作でも、担当者には入口が見つからないことがある。一緒に一回使い、困ったときの連絡先と、いつ振り返るかまで決める。
「作った」「使えた」「困りごとが変わった」は、別々に確かめる。 テストが通ったことは、利用者が使えたことや、仕事が楽になったことをそのまま証明しない。逆に、変化がまだ見えなければ失敗と決めず、使われた場面と残った負担を聞き直せる。
今日の一歩は、技術の追加より三行のメモ
全体像を見ても、「明日から全部やろう」とすると重い。営業に自信がなければ連絡するだけで緊張するし、仕事を受けていれば、今の約束を守るだけでも忙しい。最初から一人で全工程を担当する必要はない。
教室の例で最初に変えたかったのも、立派な肩書きではなかった。「予約システムなら作れる」と言う前に、運営者の仕事を一つ聞く。その小さな順番だった。
今の仕事か、関心のある業務を一つ選び、次の三行を書いてみよう。
- 誰が、どの場面で困っていそうか。
- 自分が知っていることと、まだ本人に聞いていないことは何か。
- 何が変われば助かったと言えるか。まだ分からなければ、そのまま問いにする。
たとえば、「教室の運営者が、イベント前の案内漏れを確認するのに困っているかもしれない。確認方法と頻度は未確認。次回の案内前に、誰に何を送ったか分かると助かるか聞く」と書ける。推測を事実にしないだけでも、次の会話は変わる。
まだ案件がなければ、公開されている業務の案内を読み、聞いてみたいことを一つメモするところからでいい。話を聞く接点の作り方は、顧客との最初の会話へ進める。
相談を受けたら、シリーズ2本目の顧客の困りごとを一緒に整理するで、その会話を具体化しよう。
「つくれる」から「頼られる」への第一歩は、誰かの仕事を理解しようとすること。 全部を約束する前に、一つ確かめる。そのくらいの大きさから、技術を相手の役に立つ力へつなげていける🌱
