【ITニュース解説】You Don't Have a 2.0 Platform Proposal. You Have a Preference.

多くの企業で、古くなった既存システムを新しい技術基盤へ刷新する「プラットフォーム2.0」のような大規模な改修提案がなされることがあるが、その多くは承認されずに終わってしまう。この記事は、なぜそのような重要な提案が拒否されるのか、そしてどうすれば成功させられるのかを、提案する側のエンジニアと、それを評価・承認する側のリーダー、それぞれの視点から具体的に解説している。

エンジニアが改修提案で陥りがちな失敗パターンは主に三つある。一つ目は、解決すべきビジネス上の問題よりも、最新のランタイムやアーキテクチャといった技術的な要素から話し始めてしまう「技術先行、問題後回し」の姿勢である。予算を持つ経営層から見れば、これは単にエンジニアが新しい技術に触れたいだけだと映りかねない。二つ目は、「1.0はレガシーで醜い」「保守が難しい」といった曖昧で漠然とした不満を述べるだけで、具体的な「測定可能な痛み」を提示しないことだ。感情的な表現は、提案の真偽を判断する根拠にならず、承認を得られない。三つ目は、既存システムの保守作業が退屈であり、新しい「まっさらな環境」で開発したいという個人的な願望が提案の根底にある場合である。これは正直な感情ではあるが、ビジネス上の正当な資金提供の理由にはなり得ない。

提案を成功させるためには、エンジニアは次のフェーズを段階的に進める必要がある。まず「準備フェーズ」として、自分の提案の動機が、既存システムに明確な限界があるからなのか、それとも保守が退屈だからなのかを正直に自問自答することが重要だ。そして、誰がこの新しいプラットフォームの恩恵を受けるのか、具体的なユーザーやチーム、彼らが日々の業務で直面している課題を特定しておく。

次に最も重要な「証拠の構築フェーズ」に入る。このフェーズは地味な作業が多く、誰もが避けたがる傾向にあるが、提案が承認されるかどうかの分かれ目となる。ここでは、「ビルドが遅い」といった感情的な表現ではなく、「PRのビルド時間が平均22分かかる」のように、主張する「痛み」を具体的な数値で示すことが求められる。また、現在のシステムの性能や状態を「ベースライン」として記録しておく。さらに、実際に既存システムを使っている5人以上のユーザーと直接話し、彼らが本当に困っている点が自分の考えている問題と一致するかを確認することも重要である。そして、既存システム内で、主張する問題点の中で最もひどいものをいくつか選び、実際に改善を試みる。これは決して時間稼ぎではなく、問題の真の根源を特定するための重要なステップだ。もし改善策が成功し、問題が解決したなら、その時点で改修提案を中止し、既存システムを安価に改善した成功として受け入れるべきである。もし改善が限界に達した場合は、「Xを試したが、1.0の根本的な構造Yが原因で、これ以上は改善できなかった」という具体的な説明を記録する。この具体的な「壁」の説明こそが、提案の説得力となる。

これらの準備を経て「提案書の作成フェーズ」に進む。提案書はわずか2ページにまとめることが原則である。1ページ目には、1.0の問題点を数値化されたボトルネック、改善の試みとその結果、そして明確な「天井」（例えば、「1.0の権限モデルは、新しい組織のアクセス要件を構造的に表現できない」など、既存のアーキテクチャではこれ以上改善できない根本的な制約）として記述する。また、「なぜ今この提案が必要なのか」を、このままでは会社がどのような機会を失うのかという「機会損失」の観点で説明する。2ページ目には、新しい2.0プラットフォームの「譲れない原則」、意図的に「スコープ外」とする事項、目標とする具体的な数値メトリクス（「PRビルド：22分から4分へ」など、達成すべき目標を具体的な数値で示す）を記述する。さらに、既存システムから新しいシステムへ、製品開発を継続しながらどのように切り替えていくかという「移行計画」（例えば、既存システムを少しずつ新しいコンポーネントに置き換えていく「ストランブラー・フィグ・パターン」のような戦略）と、1.0をいつ、どのように停止するかの「廃止計画」を示す。最後に、万が一2.0が期待通りに進まなかった場合に、どのような条件でプロジェクトを中止するかという「キルスイッチ」を明記する。これは提案者の責任感を強く示す、非常に信頼される要素となる。

プレゼンテーション前には「最終確認フェーズ」として、資料なしで「1.0で何を測定し、何を試して、どこで限界に当たったか」という質問に即答できるかを確認する。「レガシー」「モダン」「クリーン」といった曖昧な言葉は全て数値や具体的な制約に置き換え、自分のコードベースを知らない同僚にも、提案内容が理解できるかを確認する。そして、まずは「特定のチームでの期間を区切ったパイロットプロジェクト」のような小さな要求から始めるべきだ。

会議後は、「会議後フェーズ」として、承認された場合は開発の進捗を定期的に共有し、1.0の廃止目標日を死守する。拒否された場合は、感情的にならず、具体的にどの点が不足していたのかを質問し、それを改善するための次の計画を立てる。

一方、リーダーは、提案の真偽を最初の数分で見抜く能力が求められる。リーダーが「見るべき点」は、現在のシステムがどれだけのコストをかけているかを示す数値化されたベースライン、既存システムでの改善試行の証拠、明確に特定された技術的限界（天井）、製品開発を止めない移行計画、そして「キルスイッチ」の存在である。また、無期限の約束ではなく、特定のチームと期間を定めた小さなパイロットプロジェクトの提案かどうかも重要だ。逆に「見てはいけない点」は、特定の技術名が正当化の理由になっていること、「レガシー」のような曖昧な言葉が議論を支えていること、不必要に長い提案書、そして終了条件のない無期限のコミットメントである。リーダーは、提案者に対し「1.0で何を測定したか？」「何を試して、どこで壁に当たったか？」「どのような場合にプロジェクトを中止するか？」という3つの質問を順に投げかけることで、提案の質を迅速に見極めることができる。これらの質問に即座に答えられない提案は、単なる個人的な好みである可能性が高い。

提案を却下する場合も、エンジニアのモチベーションを失わせないよう、「改善のための具体的な課題」を明確に伝える必要がある。「レガシーだからダメ」ではなく、「改善数値が足りない」と具体的に指摘することで、エンジニアは次へとつながる行動をとりやすくなる。承認する場合も、無条件ではなく、所有者の特定、期間、パイロットチーム、1.0の廃止日、そしてキルスイッチといった「条件」を明確に設定すべきだ。これにより、プロジェクトは成果を出すか、早期に、かつ安価に中止されるかのどちらかとなり、永久に二つのプラットフォームを維持するような事態を避けることができる。

結局のところ、わずか2ページにわたる提案書に「測定可能な痛み」「試みられた改善策」「明確な技術的限界」「移行計画」「キルスイッチ」を盛り込めないなら、それは真のプラットフォーム2.0提案ではなく、単なる個人的な「好み」に過ぎない。この原則を理解し実践することが、システムエンジニアとしてのキャリアを成功に導く重要な鍵となる。