こんにちは。ウォンテッドリーでバックエンドエンジニアをしている佐藤です。

AIを活用して実装速度が上がった結果、私たちのチームではエンジニアが企画を担う範囲が広がりました。課題の特定や解決策の検討にも携わるようになっています。本記事では、なぜその変化が起きたのか、そしてエンジニアの仕事のスコープがどう広がり、何が求められるようになったかについて整理します。

エンジニアが企画段階から携わる施策が増えた

AI導入前、私たちのチームではPdMが企画した施策の数とエンジニアが開発で消化する施策の数はおおむね釣り合っていました。企画はPdMが主導し、エンジニアは仕様検討に関わりつつも主な役割は開発でした。

AIを活用することで、設計の叩き台の作成やコードの実装といった個々のタスクが速く片付くようになりました。その結果、開発の消化速度に対して企画の供給が追いつかなくなりました。

企画が不足する状況を解消するため、私のチームではエンジニアが企画段階から携わる施策の数を増やしました。企画に参加する中で、エンジニアの仕事のスコープは開発以外の領域にも広がっていきました。

エンジニアが関わる企画の全体像

企画のプロセスは、「何を解決するか」を決める課題の特定と、「どう解決するか」を決める解決策の検討に分かれます。課題の特定はPdMが主導することが多いですが、解決策の検討ではエンジニア・デザイナー・PdMがそれぞれの観点を持ち寄り議論します。たとえばある既存機能を新しいコンテンツにも拡張するという施策の場合、既存機能と統一するか別機能として作るかといった解決策を発散し、技術面・UX面・動線設計の観点から比較していきます。解決策を比較する段階でおおまかな画面イメージや振る舞いも作るため、大枠の仕様もこの過程で固まっていきます。

私は特に解決策の検討に関わることが多く、議論の段取りやアジェンダの設計を担いながら、合意形成を主導しています。この役割を担う中で、合意形成をスムーズに進めるためにいくつかの工夫をしてきました。本記事ではそれらを紹介します。

合意形成を進めるために工夫したこと

解決策の決定は、案出し、観点出し、案を観点で評価、案の選択というステップで進めます。案出しでは実現可能な解決策を幅広く発散させ、観点出しでは何を基準に評価するかを関係者で揃えます。案を観点で評価するステップでは各案を揃えた観点で比較し、案の選択では比較結果をもとに最終的な解決策を決定します。前半の案出しと観点出しは後続のステップのインプットになるため特に重要です。実際の現場では、観点出しそのものに加え、観点出しから案の選択までを進めるためのMTG設計に苦労しました。それぞれで工夫したことを紹介します。

評価観点のすり合わせ

解決策の検討を進める中で起きやすい課題は、「観点出し」が不十分なまま評価に進んでしまい、議論が収束せず時間がかかることです。参加者の価値観・視点・職能が異なるために、それぞれが別の論点で話してしまい、議論が噛み合わないことが原因です。

この課題に対して、初回のMTGで評価観点を揃えるようにしました。「今回は何を重視して判断するか」を事前に整理し、関係者に示します。目的達成度、ユーザー体験、プロダクトの一貫性、開発工数など、重視する観点はプロジェクトによって変わります。判断軸を先に揃えることで、各自がバラバラな基準で評価して議論が発散する状況を避けられ、合意形成がしやすくなります。

解決策決定までのMTG設計

解決策の決定には、技術調査やデザイン検討など事前に集めるべき情報があり、複数回のMTGを経て合意に至ります。

この中で起きやすい課題は、1回のMTGで解決策を決めようとして、判断材料が揃っていない状態で議論してしまうことです。判断材料を揃えずにMTGを開くと、情報不足のまま結論を出すか、結論が出ずにMTGが終わるかのどちらかになり、意思決定の質が下がります。

この課題に対しては、合意に至るまでの段取りを設計するようにしました。具体的には、1回目のMTGのゴールを「解決策の決定」ではなく「意思決定のためのネクストアクションの洗い出し」に絞りました。アジェンダも、判断軸の確認 → 解決案の共有 → 解決案の発散 → 意思決定に必要な情報の確認 → ネクストアクション確認、という順序で組みました。2回目のMTGでは技術調査の結果を踏まえた比較表をもとに解決策を決定し、技術的な懸念が残った部分はPoCをクイックに回して解消してから開発に進めました。

まとめ

私たちのチームでは、実装速度が上がることで企画と開発のバランスが崩れ、対策としてエンジニアが企画に参加するようになりました。この流れは、AI導入が進む開発現場で起きやすい変化だと思っています。

私自身、エンジニアの仕事のスコープが開発から企画へと広がり、解決策検討における合意形成といった新しいタスクに取り組むようになりました。中でも、評価基準の整理や意思決定ステップの分割は、技術スキルとは異なるものの、問題を分解し構造化してから解決に向かうという進め方はシステム設計と本質的に同じであり、エンジニアリングの思考と地続きだと感じています。同様の変化を経験している方や、体制変更を検討しているチームの参考になれば幸いです。