技術を土台にして自分なりのQAエンジニアを目指す本連載、第9回のテーマは「コーチング」です。 QAやテストの専門性からすると、少し遠い領域だと感じる方も多いかもしれません。正直、私自身、コーチングというものを「なんだか怪しいもの」だと思っていました。 しかし、アジャイルコーチなど現場の最前線で活躍する方々の話を聞くうちに、その認識は大きく変わりました。 人々のアウトプットとしての「品質」を本当に良くしていく、あるいは組織の「品質文化」を変えていくためには、コーチングの技術が極めて有用であると考えたのです。 その気づきから、私自身も本格的に個人やシステムに対するコーチングを学ぶため、スクールに通い始めました。 今回は、私にとって最も直近で築かれた新たな「土台」であるコーチングについてお話しします。 記事一覧：技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして 【第8回】幕間：「品質」という言葉に向き合う 【第9回】コーチング：相手の中にある答えを引き出し、品質文化を育む 「教える」から「引き出す」への転換 QAエンジニアとして活動する中で、私は品質やテストについて、比較的解像度高く言語化してきた、あるいは『自分にはそれができる』という自負がありました。 しかし、その自負が、時にチームに対して「専門家としての正解を押し付ける」ような振る舞いを生んでしまっていたと今では思います。 テストにおいても、品質保証においても、「こうあるべきだ」という強い思いがありました。 そういった状態で特に「QAエンジニア」という役割を担ってしまうと、「高圧的で怖い人」として映ってしまうことも少なくありません。 もちろん、専門家として意見をはっきりと伝えることが必要な場面は多々あります。 しかし、人の行動やマインドセットを変容させようとするフェーズになったとき、専門家からの一方的な指摘だけでは人は生き生きと動くことは困難だと気づいたのです。 そんな中で、コーチングという技術を詳しく知る機会がありました。コーチングという技術あるいはその関わり方が、その人の内発的動機を高め、行動に繋げることができるものだと知りました。 そして、実際にコーチングを実践するときには、単なる「聞く」「質問する」といった目に見える表面的な技術だけでなく、自己基盤やコーチングマインドが大事だと知ったのです。 私が実際に通った銀座コーチングスクールでは「コーチングピラミッド」という形で示されています。 図：銀座コーチングスクールのコーチングピラミッドを参考に作図 https://www.ginza-coach.com/overview/feature/curriculum.html （参照日:2026/3/21、最終更新日2026/1/20） 自己基盤 まず、コーチングピラミッドにおける「自己基盤」という考えを示しておきたいです。 これは私の理解で言えば、コーチ自身がクライアントに対して恥じることのないあり方を体現していることです。「プロのコーチ」としてプロフェッショナリズムを持っていることだと考えています。 これはQAエンジニアとしての土台にも同じことが言えます。私自身の自己基盤もまた、「プロであること」に加え、例えば「高い倫理観を持つ」「自分自身を裏切らないこと」をベースとしています。 安易に「見栄えのいい専門家」を演出してしまうと、結果として自己欺瞞に繋がり、それは自分自身の自己基盤を揺るがしてしまうと考えています。 泥臭くても自己開示し、困難に対しても正面から向き合えるような、「良いクライアントの鏡でもある」という自負が、私自身のプロフェッショナリズムを育てていると考えています。 コーチングマインド コーチングを学んだことによる最大の収穫は、「答えは相手の中にある」というマインドセットを得たことです。 コーチングを書籍などで表面的な手法だけ学んでしまうと、「質問」や「聞く」といったスキルで終始してしまうことも少なくありません。私自身も実際にそういった過ちを犯していました。 今ではコーチングマインドや自己基盤、信頼関係といった土台の構築こそが、専門性として身につけるべき本質だと思っています。 相手の中にある視点や気づきをどのように発見し、どう繋げていくか。 この「あり方」こそが、特にQAエンジニアがコーチングを学び、品質文化を醸成する上で非常に重要だと確信しています。 その「答え」は、実は相手が自覚していない場合があります。 むしろ「答え」に向き合う過程で、相手を困難に直面させるようなこともあるかもしれません。 そのような場合であっても、相手のプロフェッショナリズムを心から信頼し、目を背けたくなるような事実を鏡のようにフィードバックすることも、コーチとして時に必要になると考えています。 コーチングの技術を品質保証に活かす コーチングには「聞く」「認める」「フィードバックする」「質問する」といった技術があります。 上記で述べたように、これらの技術を土台なしに実施することは、本質を欠いたまま適用してしまう危うさがあります。 一方で、正しくこれらを用いて、クライアントの壁打ち相手になったり、適切な問いかけを行ったりすることは、品質保証の活動と非常に相性が良いです。 ここからは、コーチングの技術が、これまでの連載で触れてきた専門性とどのように組み合わさるのかを紹介します。 専門性の組み合わせ：テスト計画(リリース基準)との組み合わせ テスト計画を立てたり、リリース基準をチームで合意したりする際、コーチングの「問いかけ」や「フィードバック」の技術が力を発揮します。 第３回 でテストマネジメントは「合意形成」の技術だと述べましたが、その合意を真に納得感のあるものにするための具体的なアプローチの一つが、このコーチング的な「問いかけ」です。 QAエンジニアが一人で基準を決めるのではなく、チームに対して次のような問いを投げかけます。 「どういう状態になれば、自信を持ってリリースできますか？」 「あなたがステークホルダーであればこの製品に対してどう感じますか？」 「あなたが知っているステークホルダーはどのような人ですか？」 このように相手の思考や気づきを引き出すことは、チームが品質に対するオーナーシップを持つことに役立ちます。 自分自身の言葉で紡ぎ出したオーナーシップは、「生きた品質文化」として根付いていくと考えています。 専門性の組み合わせ：テスト実行との組み合わせ テスト実行を通じてメンバーの成長を促す場面でも、コーチングは有効です。 テスト実行中に手が止まっているメンバーや、バグを見つけたメンバーに対して、「こういう視点でテストしなさい」と教えるのではなく、気づきを促す問いを投げかけます。 「今、テストを実行していて何に気づきましたか？」 「もし自分ではなく、別のユーザー(あるいは尊敬するテスター)だったら、次にどうすると思いますか？」 「あなたが作り手だったらどんなフィードバックを望むでしょうか？そのためには何をすればいいですか？」 「こういう視点があるよ」と教え込むのではなく、「あ、こういう視点もあるんだ」と自分自身で気づいてもらうこと。 これが、テスト実行における個人のスキルアップや深い洞察に繋がります。 おわりに QAエンジニアとしてコーチングの技術を扱う上で重要だと考えている点があります。 それは「コーチング技術を自分自身の存在価値のため、あるいは相手のメンタルケアのために使わない」ということです。 QAエンジニアの専門性とコーチングを複合した時に、個人の感情やモチベーションだけではなく、「システム（構造）」に直面することがあると感じます。 例えば、バグが放置されがちな現場があったとします。 ここで「どういう理由で直さないの？（本当はどうしたいの？）」と個人のモチベーションを聞いたり、あるいはただ共感して寄り添うだけでは、根本解決にならないと感じています。 コーチであると同時にQAエンジニアとして考えたとき、このような状況では品質保証の原則である「源流管理」に立ち返ることも時には必要です。 プロのQAエンジニアが行うコーチングとは、我々が理解できていることや、ソフトウェアの動作、バグの発生状況といった「客観的な事実」と向き合うことです。 そして、「この事実が、今の私たちのシステム（開発プロセスやチームのコミュニケーション構造）のどこに問題があることを示しているのか？」という問いを立て、メンバーのプロフェッショナリズムを信じて共に探索していくことだと考えています。 コーチングは、ソフトウェアテストや品質保証とは遠い場所にあるように思えるかもしれません。 しかし、それは「プロとしてのあり方」を学び、チームと協調しながら根本的な品質文化を形作るための、非常に強力な技術です。 この新たな土台が、皆さんのQAエンジニアとしての幅を広げる一つのヒントになれば幸いです。 【連載】技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして 【第8回】幕間：「品質」という言葉に向き合う 【第9回】コーチング：相手の中にある答えを引き出し、品質文化を育む The post 【第9回】コーチング：相手の中にある答えを引き出し、品質文化を育む first appeared on Sqripts .

G-gen の佐々木です。当記事では、Pub/Sub から直接 Vertex AI 上の AI モデルによる推論を取得することができる AI 推論 SMT 機能について解説します。 前提知識 Pub/Sub とは Single Message Transforms（SMTs） AI 推論 SMT の機能 基本事項 AI 推論 SMT の利点 使用できるモデル Model Garden で提供されているモデル Vertex AI Endpoints にデプロイしたモデル モデルの入力・出力 入力するメッセージの形式 推論後のメッセージの形式 制限事項 設定手順 手順の概要 サービスアカウントの作成・権限付与 定義ファイルの作成 トピックの作成 AI 推論 SMT を使用するサブスクリプションの作成 動作確認 メッセージのパブリッシュ メッセージの受信 前提知識 Pub/Sub とは Pub/Sub は Google Cloud におけるフルマネージドなメッセージングサービスです。 メッセージングサービスは、システム間に配置することでメッセージを非同期に中継することができます。これにより、システムの拡張性や保守性を向上することができます。 Pub/Sub を始めとしたメッセージングサービスの詳細やユースケースについては、以下の記事をご一読ください。 blog.g-gen.co.jp Single Message Transforms（SMTs） Single Message Transforms （以下、 SMTs ）は Pub/Sub を使用したストリーミング処理のパイプラインにおいて単純なデータ変換を実現する機能です。 この機能では、Pub/Sub のトピックとサブスクリプションのそれぞれに対して単純なデータ変換処理を実装します。これにより、データの形式の変換やマスキング、フィルタリングなどの処理を、メッセージの配信前に行うことができます。 SMTs の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp AI 推論 SMT の機能 基本事項 当記事で紹介する AI 推論 SMT （AI Inference Single Method Transform）は、SMTs の機能の1つであり、Vertex AI にある AI モデル（Gemini など）に Pub/Sub のメッセージを渡し、 推論を取得してメッセージに追加することができる 機能です。 通常の SMTs 同様に、AI 推論 SMT はトピックとサブスクリプションのどちらでも設定することができます。 トピックに設定した場合、推論結果がメッセージに追加されたあと、トピックに紐づくすべてのサブスクリプションにメッセージが配信されます。 トピックに対して AI 推論 SMT を設定した場合 サブスクリプションに設定した場合は、そのサブスクリプションでのみ推論を取得するような動作となります。Pub/Sub のユースケースに合わせて設定するとよいでしょう。 サブスクリプションに対して AI 推論 SMT を設定した場合 参考 : AI 推論 SMT 参考 : 単一メッセージ変換（SMT）の概要 - SMT のサンプル メッセージ フロー AI 推論 SMT の利点 AI 推論 SMT を使用してモデル推論とデータ変換を行う場合、以下のようなメリットがあります。 メッセージに対してリアルタイムで AI モデルによる推論結果を追加することができる（データ エンリッチメント） モデルから推論を取得するための処理をアプリケーション側に実装する必要がなくなる サブスクリプションに設定した場合、Pub/Sub はモデル エンドポイントの過負荷を回避し推論のスループットを最大化するため、リクエストレートを最適化する（フロー制御） ※ 単項 pull では最適化されない点に注意 参考 : AI 推論 SMT - メッセージ フロー 使用できるモデル Model Garden で提供されているモデル AI 推論 SMT では、トピックまたはサブスクリプションを作成する際にモデルの推論用のエンドポイントを指定します。 Vertex AI Model Garden で提供されているモデルを使用する場合、以下のような形式でエンドポイントを指定します。 - ai - aiInference : endpoint : "projects/<プロジェクトID>/locations/<モデルを利用するリージョン>/publishers/<モデルのパブリッシャー>/models/<モデル名>" 使用できるモデルの一覧については、以下のドキュメントで最新の情報を確認してください。 参考 : AI 推論 SMT - 互換性のある MaaS モデル Vertex AI Endpoints にデプロイしたモデル ユーザーが Vertex AI Endpoints を使用して Google Cloud 上にデプロイしたモデル（セルフデプロイ モデル）を推論に使用することもできます。 セルフデプロイ モデルを使用する場合は、モデルのエンドポイントの指定の仕方が異なります。 - aiInference : endpoint : "projects/<プロジェクトID>/locations/<エンドポイントのリージョン>/endpoints/<エンドポイント>" 参考 : エンドポイントにモデルをデプロイする モデルの入力・出力 入力するメッセージの形式 AI 推論 SMT による推論を行うためには、Pub/Sub に入力されるメッセージが特定の形式になっている必要があります。 例えば gemini-2.5-flash のような Gemini 基盤モデルを使用する場合、 Chat Completions API を使用して Gemini が呼び出されるため、以下のように Pub/Sub トピックに送信するメッセージの形式を API の仕様に合わせます。 { " model ":" google/gemini-2.5-flash ", " messages ": [ { " role ": " user ", " content ": " Explain how AI works in a few words " } ] } 参考 : AI 推論 SMT - メッセージ処理 推論後のメッセージの形式 AI 推論 SMT によって取得したモデルのレスポンスは、以下のように元のメッセージに追加されます。 { " original_message ": " <元のメッセージ> ", " model_output ": " <推論によって取得したモデルのレスポンス> " } 制限事項 AI 推論 SMT には以下のような制限事項があります。 トピックまたはサブスクリプションに設定できる AI 推論 SMT の数は1つまで Vertex AI Endpoints のプライベート エンドポイントはサポートされていない（公開エンドポイントのみ使用可） グローバル エンドポイントは、Gemini 基盤モデルでのみサポートされる。その他のモデルではリージョン エンドポイントのみ使用可能 Pub/Sub 側では入力されたメッセージのデータ形式などの検証は行われない。トピックにメッセージを送信する前に検証する必要がある 1つのメッセージごとに1つの推論リクエストのみが可能であり、バッチ推論は不可 指定したモデルによる推論は60秒以内に完了する必要がある 推論が60秒を超過するとタイムアウトとなり、Pub/Sub に設定したメッセージ保持期間と再試行回数の上限まで再試行が行われ、その後デッドレタートピックにメッセージが転送されます。 その他、制限事項に関する最新情報は以下のドキュメントをご一読ください。 参考 : AI 推論 SMT - 制限事項 設定手順 手順の概要 当記事で紹介する手順は、サブスクリプションに対して AI 推論 SMT によるメッセージ変換を設定し、そのサブスクリプションのコンシューマーに対してのみ推論結果を含めたメッセージを配信できるようにするためのものです。 参考 : AI 推論 SMT - AI 推論 SMT を作成する サービスアカウントの作成・権限付与 AI 推論 SMT を使用する場合、Cloud Pub/Sub サービスエージェント（ service-<プロジェクト番号>@gcp-sa-pubsub.iam.gserviceaccount.com ）に対して Vertex AI サービス エージェント （ roles/aiplatform.serviceAgent ）ロールを付与するか、カスタムサービスアカウントに対して Vertex AI ユーザー （ roles/aiplatform.user ）ロールを付与します。 当記事ではカスタムサービスアカウントを使用します。 # サブスクリプション用のサービスアカウントを作成 $ gcloud iam service-accounts create pubsub-ai-inference-smt \ --display-name =" Pub/Sub AI Inference SMT " # Vertex AI ユーザー ロールの付与 $ gcloud projects add-iam-policy-binding < プロジェクトID > \ --member =" serviceAccount:pubsub-ai-inference-smt@<プロジェクトID>.iam.gserviceaccount.com " \ --role =" roles/aiplatform.user " 定義ファイルの作成 ai-smt.yaml という名前で AI 推論 SMT の定義ファイルを作成します。これをトピックもしくはサブスクリプションの作成時に指定することで、AI 推論 SMT を使用することができます。 - aiInference : endpoint : "projects/<プロジェクトID>/locations/asia-northeast1/publishers/google/models/gemini-2.5-flash" unstructuredInference : { parameters : { "temperature" : 0.5 , "max_tokens" : 1000 } } serviceAccountEmail : "pubsub-ai-inference-smt@<プロジェクトID>.iam.gserviceaccount.com" endpoint にはモデルのエンドポイントを指定します。 unstructuredInference.parameters には、モデルに推論リクエストを送信する際のパラメータや最大トークン数などを指定できます。 serviceAccountEmail には、先ほど作成したサービスアカウントを指定します。 トピックの作成 Pub/Sub のトピックを作成します。 # トピックの作成 $ gcloud pubsub topics create ai-smt-topic トピックに AI 推論 SMT を設定する場合、ここで --message-transforms-file オプションを使用します。 参考 : gcloud pubsub topics create AI 推論 SMT を使用するサブスクリプションの作成 トピックに紐付けるサブスクリプションを作成します。 当記事ではサブスクリプション側に AI 推論 SMT によるメッセージ変換処理を設定するため、 --message-transforms-file で先ほど作成した定義ファイルを指定します。 # AI 推論 SMT を使用するサブスクリプションの作成 $ gcloud pubsub subscriptions create ai-smt-topic-sub \ --ack-deadline = 600 \ --topic ai-smt-topic \ --message-transforms-file ai-smt.yaml 動作確認 メッセージのパブリッシュ 作成したトピックに対してメッセージをパブリッシュしてみます。 AI 推論 SMT で Gemini モデルを指定しているため、 --message には、 Chat Completions API の仕様に合わせた形式でメッセージを設定します。 # プロンプトを含むメッセージのパブリッシュ $ gcloud pubsub topics publish ai-smt-topic --message =$' { "model":"google/gemini-2.5-flash","messages":[{ "role": "user", "content": "Vertex AI について簡単に説明して" }] } ' 参考 : gcloud pubsub topics publish メッセージの受信 サブスクリプションに配信されたメッセージを確認します。 # メッセージを受信し、データを復号したあと JSON に変換 $ gcloud pubsub subscriptions pull ai-smt-topic-sub \ --auto-ack \ --format =" value(message.data.decode(base64)) " | jq . 受信したメッセージには、元のメッセージである "original_message" に加え、サブスクリプション側の AI 推論 SMT によって "model_output" が含まれていることがわかります。 以下は受信したメッセージの例です。 { " model_output ": { " choices ": [ { " finish_reason ": " stop ", " index ": 0 , " logprobs ": null , " message ": { " content ": " Vertex AI は、Google Cloud が提供する、**機械学習（ML）開発のための統合プラットフォーム**です。 \n\n 簡単に言うと、MLモデルを開発する際に必要な「データの準備」「モデルの構築」「トレーニング」「デプロイ（公開）」「監視・管理」といった**あらゆる工程を、一つの場所で効率的に行えるようにするための「ワンストップショップ」**のようなものです。 \n\n **主なポイント：** \n\n 1. **統合された環境:** これまでバラバラだったML開発のツールやサービスを一つにまとめ、開発プロセスをシンプルにします。 \n 2. **効率化と高速化:** データサイエンティストやMLエンジニアが、インフラの管理に時間を取られることなく、モデルの開発や改善に集中できるよう設計されています。 \n 3. **幅広い対応:** カスタムモデルの構築はもちろん、画像認識や自然言語処理などの特定のタスクに対応した事前学習済みモデルの利用や、AutoML（自動機械学習）機能も提供します。 \n 4. **スケーラビリティ:** Googleの強力なインフラ上で動作するため、大規模なデータや複雑なモデルのトレーニングも柔軟に対応できます。 \n\n 例えるなら、ML開発に必要なあらゆる道具が揃った「高機能な作業台」のようなものです。これにより、企業はより迅速にMLをビジネスに導入し、価値を生み出すことができるようになります。 ", " role ": " assistant " } } ] , " created ": 1775550770 , " id ": " MsHUaYLcFaKTp_QP1_SwiAw ", " model ": " google/gemini-2.5-flash ", " object ": " chat.completion ", " system_fingerprint ": "", " usage ": { " completion_tokens ": 263 , " completion_tokens_details ": { " reasoning_tokens ": 1066 } , " extra_properties ": { " google ": { " traffic_type ": " ON_DEMAND " } } , " prompt_tokens ": 6 , " total_tokens ": 1335 } } , " original_message ": { " messages ": [ { " content ": " Vertex AI について簡単に説明して ", " role ": " user " } ] , " model ": " google/gemini-2.5-flash " } } 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

こんにちは！ファインディでプロダクト開発部のVPoEをしている 浜田 です。 AI駆動開発が浸透するなかで、エンジニア1人あたりの開発能力は大きく向上しています。しかし、従来のチーム単位のアサイン方式のままでは、そのポテンシャルを十分に引き出せていないと感じていました。 この記事では、私たちが開発プロセスを「チーム単位」から「個人単位」のアサインへ移行した背景と、その結果得られた変化について紹介します。AI駆動開発を取り入れたものの、チームの開発プロセスをどう変えるべきか悩んでいる方に向けた内容です。 これまでの開発プロセス AI駆動開発で見えてきた課題 個人アサイン方式への移行 個人のオーナーシップを高める 技術改善が進みやすくなった まとめ これまでの開発プロセス ファインディのプロダクト開発部には複数の開発チームがあり、それぞれ5名前後のエンジニアにPdMとデザイナーを加えた構成で、協働しながらプロダクト開発を進めています。 これまでの開発プロセスでは、施策開発をチームにアサインし、メンバーそれぞれが優先度の高いタスクをフレキシブルに取っていくスタイルで運用していました。1つの施策開発をチームにアサインすると、結果的に4名程度のエンジニアが集中して取り組み、一気に開発を完了させるという進め方です。いわばフロー効率を重視した開発スタイルで、最も優先度の高い施策を最速で完了させることに注力していました。 この方式はチームの連携が生まれやすく、うまく機能していました。複数人が同じ施策に取り組むことで、設計の議論がその場で生まれたり、実装中に詰まったときもすぐに相談できたりと、チームで動くからこその強みがありました。 AI駆動開発で見えてきた課題 AI駆動開発の導入により、エンジニア1人が同時に扱える開発量は増えました。タスク分解をおこなって依存関係さえ明確にできれば、かなりの数のタスクをAIエージェントに渡して並列で進めることが可能です。加えて、これまではキャッチアップに時間がかかっていたような、自身の習熟度が低い技術スタックの部分であっても、AIをパートナーにして自力で開発を進められるようになりました。 しかし、フロー効率を重視した従来のスタイルでは、このAIのポテンシャルを十分に引き出せませんでした。複数のエンジニアで1つの施策を分担している状態では、一人ひとりが持つタスクの粒度はすでに細かくなっています。そこからさらにタスクを分解して複数のAIエージェントに並列で任せるのは難しく、AIの役割はあくまで副操縦士としての補助にとどまっていました。 加えて、タスクのアサインを明確に決めず、手が空いた人から優先度の高いタスクを取っていくスタイルでは、自分がこの先どのタスクを担当するかが見通せません。先の計画が立たない以上、AIエージェントに先回りしてタスクを渡して並列で進めてもらうこともできず、結局は目の前の1つのタスクをAIと一緒にこなすだけになってしまいます。 個人アサイン方式への移行 そこで、施策開発を個々のエンジニアにまるごとアサインする方式へと切り替えました。 1人が施策全体を担当することで、タスクの分解と計画を自分の裁量で行えるようになります。どの部分をAIエージェントに並列で任せ、どの部分を自分で手を動かすかを事前に整理できるので、AIを副操縦士ではなく、複数の作業を同時に進めるパートナーとして活用できるようになりました。 具体的には、Claude Codeのような自律型エージェントを用いて複数のワーカーを立ち上げます。そして、あるコンポーネントの実装やテストコード生成をそれらに並列で進めさせながら、自身は全体の設計やオーケストレーションに集中する、といった働き方です。 この「1人のエンジニアが複数のAIエージェントを指揮する」具体的なワークフローについては、以下の記事で詳しく解説していますので、あわせてご覧ください。 tech.findy.co.jp フロー効率を重視していた頃と比べると、最も優先度の高い施策が完了するまでの速度は低下します。4名で集中して取り組んでいたものを1名で担当するのですから、これは当然のトレードオフです。しかし、エンジニア間のコミュニケーションコストが減ることや、AIによるアウトプット量と速度の向上により、大きく低下させることなく開発を進められています。さらに、2番目、3番目に優先度の高い施策も別のエンジニアが並行して開発を進めるため、個々の施策にかかる期間が延びても、結果としてより多くの施策を素早くリリースできるようになりました。 実際に、この変化は定量的な指標にも明確に表れています。以下のグラフは紹介した変更を行なった開発チームのPR（プルリクエスト）作成数の推移ですが、個人アサインへの移行を本格的に進めた2026年2月中旬以降、PR数が明確に一段増えていることがわかります。個人のポテンシャルを引き出すアプローチが、開発チーム全体のアウトプット最大化に繋がった形です。 一方で、チーム全体のまとまりという意味では変化がありました。これまでのように全員で1つの開発に集中する場面は減り、どちらかというと個々の集まりに近い形になっています。 ただし、チームとしての連携を完全に手放したわけではありません。たとえば設計の方針に関わる判断は、個人で抱えずチームで議論してから進めるようにしていますし、実装についても「属人化」を防ぐためにプルリクエストをこまめに分割してレビューし合うプロセスを維持しています。さらに、各自が何に取り組んでいるかを定期的に共有する場を設けることで、お互いの状況が見えなくなることも避けています。つまり、チームとしての協働がなくなったのではなく、その関わり方が変わったというのが正確な表現です。 個人のオーナーシップを高める AI時代だからこそ、個人を目立たせることが重要だと考えています。 チームの一員として開発に参加するだけでは、個々のエンジニアの貢献が見えにくくなります。極端に言えば、AIに代替されやすいポジションになってしまう可能性もあります。個人がオーナーシップを持ち、「これは自分がやった」と自信を持って言える状態をつくることが、エンジニアとしての価値を高めることにつながると思っています。 個人アサインに移行したことで、各エンジニアが担当する施策に対して当事者意識を持って取り組むようになりました。設計の意思決定からリリースまでを一貫して担うことで、施策全体を自分ごととして捉える姿勢が自然と生まれています。また、チームで開発していた頃はどうしても窓口がチームリーダーに集中しがちでしたが、施策ごとに個人をアサインしているため、メンバーそれぞれがPdMや事業メンバーと直接やりとりをおこなうようになりました。その結果、施策の背景やリリース後の効果に対する意識が上がるなど、良い効果が出ています。 これはマネジメントの観点からも好ましい変化でした。誰がどの施策を推進しているかが明確になるので、成果の可視化にもつながります。チームの中で埋もれるのではなく、一人ひとりの仕事が見える状態をつくることが、エンジニアのモチベーションにもよい影響を与えていると感じています。 技術改善が進みやすくなった 個人アサインに切り替えたことで生まれたもう1つの変化として、技術的な改善が進みやすくなったことがあります。 チーム全体で施策開発に集中していた頃は、技術改善やリファクタリングはどうしても後回しになりがちでした。個人にアサインされる形になったことで、自分の裁量で改善タスクを差し込みやすくなりました。実際に、以前はなかなか手がつけられなかったライブラリのアップデートやテストの整備といった地道な改善が、各エンジニアの判断で着実に進むようになっています。 チームとしてもリソース配分を明確にしました。施策開発、改善、その他の割合を7:2:1と定めたことで、「2割のリソースは技術改善に使おう」という共通認識が生まれ、改善活動に取り組みやすい環境が整っています。 まとめ フロー効率を重視したチーム開発から、AIのポテンシャルを引き出す個人アサインへと開発プロセスを移行しました。個々の施策が完了するまでの速度は下がるものの、AIエージェントを活用した並列開発によってチーム全体のアウトプットはむしろ増加し、実際にPR数にもその変化が表れています。加えて、個人のオーナーシップが高まり、技術改善にも手が回るようになりました。 チームのまとまりが薄れるリスクはありますが、設計判断の議論やレビューといった連携ポイントを意識的に残すことでバランスを取っています。AI駆動開発を推進するなかで開発プロセスの見直しを検討している方の参考になれば幸いです。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers