今回はちょっとポエム的な内容となります。
「AIを使って生産性を上げよう！」というと、多くの場合は「AIが自分の代わりにプレゼン資料を書いてくれる」とか「コードを生成してくれる」といった『作業の自動化』に注目が集まりがちですよね。
もちろんそれもそうなのですが、最近僕がより重要だなと感じているのは、「AIをチームのコミュニケーションやプロセスの潤滑油として使う」という視点です。
実は「書く作業」そのものよりも、その前後の「確認」や「認識合わせ」の方が工数かかっていませんか？という話です。
今回は、僕が考えている「コミュニケーションコストを削るためのAI活用」について、大きな2つのポイントと、その先に待っている未来の考察をまとめてみます。
1.上流からの「実機ベース」のすり合わせで手戻りをなくす
まず徹底しているのが、「より上流工程でのAIによる精度向上」です。
これは僕自身の作業だけではなく、さらにその手前の「要求定義」の段階から始まっています。最近では、PdM（プロダクトマネージャー）から要求をもらう際、AIエージェント（GenSparkなど）を使って実際に動くモックを提供してもらうようにしています。
やっていること
単なるドキュメントベースのやり取りではなく、実際に動くものを見ながら、「ここをこうしたい」という議論を要求段階で行います。
その「精度の高い要求」をインプットにして、AIを使って必要な設計観点をもれなく洗い出し、設計に漏れがないよう精度を上げています。
具体的には、フェーズ毎に検討すべきことを網羅した専用のプロンプトを用意しており、それを適用することで、未決定事項を漏れなくあぶり出し、考慮漏れのない成果物を作成できる状態にまで持っていきます。
効果
動くモックをベースにしているので、要求の解像度が最初から極めて高いです。そこからさらにAIでロジックを補強して下流（開発やQA）に流すため、「そもそも論」の手戻りがほぼゼロになります。「より上流の精度が、プロジェクト全体の品質や精度に大きく影響する」と実感しています。
2.相手ドメインの「たたき台」を提示し、MTGを「判断の場」に変える
自分たちの解像度が上がったら、次は他部署との関わり方です。
次に重要視しているのが、デザインやQAといった他チームとのやり取り、およびレビュー工程の効率化です。
やっていること
単に「これお願いします」と依頼したり要件定義資料を投げてチェックを待つのではなく、相手の専門ドメインに一歩踏み込み、AIを駆使して具体的な「たたき台」を作成して提示するようにしています。
デザインチームへ: 言葉で伝えるだけでなく、AIにUI構成案や構造を作らせて、「こんなイメージの叩きがあるんだけど、どう思う？」と渡す。
QAチームへ: 仕様を渡す際、AIに「想定されるテスト観点、テストケース」をリストアップさせて添える。
これは、先ほどのPdMがGenSparkで画面モックを作るのと本質的に同じアプローチです。抽象的な言葉での相談ではなく、具体的な「成果物のプロトタイプ」を持って対話することで、認識のズレをその場で解消し、不毛な確認MTGを減らしています。
効果
ゼロから説明して「作業」をお願いするのではなく、相手に「判断」だけをお願いする形に持っていっています。これにより、これまで2回、3回と繰り返していたSlackでのやり取りやMTGが激減しました。相手も本質的なフィードバックに集中できています。
見えてきた課題：AIを使いこなすための「ドメイン知識」
ただ、ここで一つ大きな壁にぶつかっています。それは、「相手（別職種のプロ）が真に求めている成果物を100%提示するのは難しい」ということ。
AIを使って「たたき台」は作れますが、相手の専門分野（デザインの定石やQAの深いノウハウ）に自分がある程度精通していないと、AIに適切な指示が出せません。AIをハブにするには、結局のところ「相手のドメイン知識を学ぶ」ことが不可欠だなと感じています。
考察：この先、働き方はどう変わっていくのか？
これらを突き詰めていくと、仕事の進め方の中でコミュニケーションの割合が大きく減っていくと思います。
① 他チームへの依頼が「作業」から「判断」へ変化する。
これまでの他チームへの依頼は、資料作成や実作業などの「手を動かすこと（作業）」が中心でした。しかし、AIによって専門ドメインのたたき台を提示できるようになれば、他チームに求める役割は「専門家としての意思決定」と「さらなる価値向上のための判断」にシフトします。
相手は単なる『作業者』ではなく、コミュニケーションの密度が上がり、よりクリエイティブな議論ができると思います。
② 「自律的なドキュメント連携」の世界
今はまだ人間がAIを使ってドキュメントを繋いでいます。要求が一つ変わると、自チーム内のドキュメントの修正と、他チームへの説明および他チームで管理している設計書の修正が発生します。
今後は「1箇所を直せば、関連する全ドキュメントが勝手に更新される」環境が当たり前になると思います。
要件定義書を1行書き換えたら、裏側でAIがデザイン仕様書もテストケースも「整合性が取れるように書き換えておきました、確認してね」と通知してくる。そんな「ドキュメントが自律的に育つ」世界です。
すでに実装についてはそうなっています。バグチケットを元に、修正内容の理解から、修正内容洗い出して設計書修正からソースコードを修正し、単体テスト、E2EテストまでAIで自動的に実行できる環境にあります。人間が行うのは、AIが行った作業成果チェックや判断です。今後は他ドメインにも波及して、僕たちの主な仕事は「作業」ではなく、AIが繋いでくれた情報の整合性を最後にチェックし、「責任を持って判断する」ことだけになっていくと思います。
最後に
「責任を持って判断する」って重い言葉ですよね。そのためには自分がその分野のプロフェッショナルとしての知識をもって判断できるだけのスキルが必要だと改めて思っている次第です。