同じ変更でも、営業・PM・エンジニアが知りたいことは違う
AIでコードや資料を早く作れても、チームには背景の確認や判断が残ります。一つの顧客要望を例に、役割に合う説明の細かさと、共通の前提を考えます。
Steven WongAIでコードの下書きや提案資料を早く作れるようになると、チームの仕事もそのまま速く進むように思えます。ただ、一つの成果物を作ったあとには、別の担当者への説明、条件の確認、判断やレビューが続きます。
そこで時間がかかる理由には、仕事の背景を取り戻すことや、相手に必要な詳しさで伝え直すこともあると考えています。
たとえば、顧客から「案件一覧に担当部署を表示したい」という要望が届いたとします。営業が要望を伝え、PMが仕様をまとめ、エンジニアが実装を考える。画面案をすぐ作れても、「どの時点の部署を表示するか」が曖昧なら、確認は残ります。
次にする仕事が違えば、必要な細かさも違う
この変更について、全員が同じ情報を同じ深さで読む必要があるでしょうか。それぞれが次に進むための問いを並べてみます。
| 役割 | 次へ進むために必要な情報 |
|---|---|
| 営業 | 顧客ができること、提供範囲、回答前の確認事項 |
| エンジニア | 部署データの所在、更新条件、欠損時の扱い |
| PM・責任者 | 要望の目的、影響範囲、優先順位を決める条件 |
技術上の細部をそのまま渡すと、営業は顧客への説明を組み立て直す必要があります。逆に「部署名を追加します」とだけ伝えても、エンジニアは実装の条件を決められません。説明が長いか短いかに加えて、次の判断に必要な点が入っているかが大切です。
先ほどの例で、当初は現在の担当部署を表示するつもりだったのに、顧客が知りたいのは受注当時の部署だったと分かったら、どうでしょう。過去の部署を保存しているか、どこまで対応するかを考え直す必要があります。営業への回答も、責任者が判断する作業範囲も変わります。
説明を変えても、判断の前提は共有する
役割に合わせて説明の細かさを変えながら、何が変わり、なぜ変わったかは同じ記録から確かめられる。そんな受け渡しを支えたいと思います。
要望の目的、変更前後の条件、すでに決めたこと、まだ確認が必要なこと。そのつながりが分かれば、詳しい人に経緯を最初から説明してもらう負担を減らせます。必要な人は、要点から元の会話や資料へ戻って確認できます。
Lyqaでは、接続され、読み取りを許可された会話や資料から、背景や経緯、変化、確認事項を整理することに取り組んでいます。役割が違っても、必要なときに共有済みの前提へ戻り、その続きを考えられる状態を目指しています。現在は初期パイロットの準備段階です。
新しい要望を採用するか、実装が妥当か、顧客に何を約束するかは、人が協議し、確認する必要があります。記録にない意図や不足した条件も、当事者に確かめます。
次に仕事を渡すときは、「相手はこれを読んで何を判断するのか」を一つ書いてみてください。その判断に必要な細部と、共通の背景に戻れる参照先がそろっているか。AIで作る速さと合わせて、そこも整えていきたいと思っています。