受発注を変革するインフラへ。PRONI岸本悠生氏が語る、事業にコミットするEMの思考

海外でプロサッカー選手として活動していた時期にプログラミングに出会い、独学でスキルを習得しました。2024年にPRONIへ入社し、現在はEM(エンジニアリングマネージャー)として「PRONIアイミツ」の開発・保守・運用を統括しています。

技術に対する向き合い方自体は大きく変わっていません。一貫して、技術はあくまで課題解決の手段であって、目的ではないと考えていました。
エンジニアになった当初も、コードを書くことそのものに価値を感じていたというより、「その先にある課題が解決されるかどうか」に関心がありました。

ただ、実務を重ねる中で見えてきたのは、プログラミングの能力だけでは解決できない課題があるという事実です。プロダクトの価値を最大化するには、解くべき課題の設定、組織のマネジメントまで含めて設計する必要がある。
そして最終的に向き合うべきは、プロダクトの完成度ではなく、それが事業にどれだけのインパクトをもたらすかでした。

だからこそ、プロダクトマネジメント（PdM）の視点やチーム全体の出力を高めるリーダーの役割に自然と関心が向いていきました。アウトプットではなく、事業成果に責任をもってコミットしたいと思うようになったんです。

日々の開発の中で、「この仕事は本当に事業を前に進めているのか」と問い続けていました。技術を磨くこと自体はとても重要です。ただ、それがユーザー価値や売上、プロダクトの成長につながっていなければ、十分とは言えないとも感じていました。

そう考えるようになると、技術力をどう使うかがより重要に思えてきました。どんな課題を解くべきか、ボトルネックはどこにあるのか、そして組織としてどう成果を最大化するのか。実装の精度だけでなく、課題設定や意思決定の質こそが、事業への影響を決めると感じたんです。

その延長線上で、プロダクトマネジメント（PdM）の視点や、チーム全体の出力を高めるリーダーの役割に自然と関心が向いていきました。個人の成果ではなく、事業成果に責任を持つ立場でありたいと思うようになったんです。

アウトプットの捉え方が変わったというより、成果の定義が変わった、という感覚ですね。実装は依然として重要ですが、それ自体を成果とは見なくなりました。今は、そのアウトプットがどんなアウトカムを生み、事業にどう寄与しているかまでを含めて成果だと捉えています。

一番大きいのは、意思決定の前提を自分で設計するようになったことです。プレイヤー時代は与えられた前提の中で最適解を出していましたが、今はその前提自体をどう置くかを考えています。

「数字を読んで、数字で話す」ことを徹底しています。売上やコスト、KPIといった事業指標を理解せずに議論しても、意思決定には影響を与えられません。まずは同じ指標を見ている状態をつくることが前提です。

技術的な正しさをそのまま説明することはしません。例えば「アーキテクチャを改善したい」「負債を解消したい」とは言わず、それが事業にどう影響するのかに置き換えて話します。前提として、ビジネスサイドも私たちエンジニアも目的は全社レベルでは同じです。違いがあるとすれば、見ている時間軸だけだと思っています。

例えば、短期的な依頼が来たとしても、それをすべて処理することが最適とは限りません。重要なのは、限られたリソースの中で、どの課題を解くことに集中するのが最も期待値が高いかを選ぶことです。

その判断を属人的にしないために、時間軸を含めた数字で整理します。いま対応することで事業の選択肢は広がるのか、それとも将来の課題解決を制限するのか。数字は事業として合理的な判断のための材料です。

特定のアーキテクチャへの投資が必要な場合、「もし今この仮説に投資すれば、半年後の開発コストがこれだけ削減され、保守に伴う不具合発生率が何％下がる」といった形で、現在とは違う時間軸の数字を見せるようにしています。

これにより、感情論や「やりたい・やりたくない」といった主観を排除し、冷静にリソースの配分を決定できるようになります。

現在私が共に働くチームでは 「全員PdM（プロダクトマネージャー）」 という意識が浸透しています。これはエンジニアにPdMの調整業務まで負担させるという意味ではなく、全員がエンジニアリングの専門性を発揮しながら「事業成長にコミットする視座を持つ」という意味です。

目指すべき北極星が同じだからこそ、アプローチが違っても最終的には「価値最大化」のために協力し合えるんです。

その通りです。プロとして求められるのは、技術を使ってどれだけの事業インパクトを出せるか。そのために、ビジネスサイドの領域にも自ら越境し、共通言語で議論する姿勢を持つことが、自身の視座を上げることに直結するはずです。

私が意識しているのは、「制約を減らし、主体的に判断できる余白をつくる」ことです。ルールを増やせば統制は取りやすくなりますが、その分、現場の判断は止まります。

「ラウンドアバウト」という信号機がない環状交差点の例えをよく使いますが、重要なのは、ただルールがない「放置」状態にすることではありません。メンバー全員がプロ集団としての高い基準を持ち、解くべき課題と進む方向の共通認識が取れているからこそ成り立つ、自律とスピードを両立するための仕組みです。

だからこそ、「進むべき方向性や目的」といった本質的な対話を、信号の代わりに徹底して行います。細かな手順を縛るのではなく、期待値を揃える。一人ひとりが自分自身の判断で動ける「余白」を設計すること。それがEMとしての私の重要な仕事だと考えています。

もちろん、自律的な行動を促進する過程で情報格差や認知負荷が生まれます。だからこそ、解くべき課題の設定や期待値、前提条件を言語化し、都度すり合わせる必要があります。

最近では、ある人にとってタスクレベルでは担当外の課題に対しても「この施策は全体最適と言えるか」という問いのもと自然に活発な議論が起きるようになってきました。 それはルールで動いているのではなく、目的で動いている状態だと感じています。

ルールで統制するのではなく、解くべき課題を共有する。その結果として生まれる自律の総量が、組織の自律性と実行力を決めると思っています。

私たちはAIを単なる生産性向上ツールとしては捉えていません。AIによって実装のコストは限りなく下がりました。設計や実装、テストコードの生成までを一気通貫で任せられるようになっています。

ただ、それ自体が競争優位になるわけではありません。実装のコストが下がると、次にボトルネックになるのは「どんな課題を解くのか」と「それが事業に貢献しているかをどう評価するのか」です。価値の源泉は、実装そのものから、事業にコミットした課題設定とエンジニアリングの質へと移っている感覚があります。

現在はドキュメント駆動で開発を進めることが増えています。まず人間が事業課題を構造化し、仕様として明文化する。その上で、実装をAIに委ねる形です。重要なのは、AIに何を書かせるかではなく、そもそも何を解くのかをどう定義するかです。

つまり、問いの解像度が、そのままアウトカムの質に跳ね返ります。実装のコストが下がった分、課題設定や評価の設計こそが、より重要になっていると感じています。

AIレビューの定量化も、その思想の延長です。定量的な基準で運用しているのは、単にレビュー工数を減らすためではありません。

目的は、どこまでをAIに任せ、どこからを人間が責任を持つのかという判断の線引きを明確にすることです。実装の正確性や規約準拠など、再現性の高い領域の一次チェックはAIが担う。一方で人間は、「この施策は事業として合理的か」といったトレードオフを伴う判断や、より難易度の高いアーキテクチャ設計に集中します。

決して品質管理を放棄しているわけではありません。むしろ、チェックの量ではなく質を変えることが重要だと考えています。これまで人間が時間を割いていた構文や規約レベルの確認をAIに任せる分、人間は「ビジネスロジックとしての妥当性」の最終承認に注力できる。

責任の所在を、実装の細部から、意思決定の妥当性やビジネス価値の創出へとシフトさせている、という感覚です。

AIがコードを書ける時代だからこそ、エンジニアリングの本質はより明確になります。それは、コードを書くことではなく、事業課題を構造化し、持続的に解き続けられる仕組みを設計することです。

エンジニアの役割は、与えられた仕様を実装することではなく、事業の期待値を設計することにあると考えています。

AIによって実装の生産性は大きく向上しました。ただ、本質はそこではありません。実装のコストが下がるほど、どの課題を解くか、どの時間軸で意思決定するかといった判断の重みはむしろ増していきます。

浮いたリソースを何に再投資するのか。その選択こそが、事業の方向性を決めます。AIは生産性を高める存在であると同時に、私たちの判断構造をより直接的に事業成果へ結びつける存在だと感じています。

マネジメントは人を管理することではなく、より抽象度の高い問題を解くことだと思っています。実装のみではなく、前提や構造を設計する側に立つこと。

一つの判断でチームの動きや、事業の速度が変わる。そのレバレッジの大きさは、とても刺激的です。引き受ける責任の範囲が広がることで、自分が解決すべき課題の抽象度も上がっていく。その自己の拡張が、面白さだと思っています。