「技術者じゃなくても納得できるプロジェクト企画書」の作り方を解説：技術ではなく、財務的な視点を強調することが重要

TechTargetは、「ソフトウェアプロジェクトのビジネスケース」に関する記事を公開した。ソフトウェアプロジェクトを提案する場合、技術的な側面に関する詳細な調査が欠かせない。だが、プロジェクトのビジネスケースにおいては、技術的な話を抑える必要がある。

[Matt Heusser，TechTarget]

　TechTargetは2023年12月16日（米国時間）、「ソフトウェアプロジェクトのビジネスケース」に関する記事を公開した。ビジネスケースとは、そのプロジェクトの投資的価値を判断するために使う、いわば企画書のことだ。

ソフトウェアプロジェクトの強力なビジネスケースを作成する方法（提供：TechTarget）

　アーキテクチャの再設計や革新的なアプリケーションの開発など、新しいソフトウェアの取り組みでは、まずプロジェクトを提案することから始まる。しかし、技術的な観点から見てどれほど包括的で詳細なものであったとしても、ビジネスサイドの管理者から賛同が得られないような提案は、始めるきっかけすら得られないまま終わる可能性がある。

　アーキテクト、開発リーダー、その他の上級ソフトウェア開発者は、ビジネスサイドとのコミュニケーションをマスターすることで、より多くのプロジェクトを承認してもらえるだろう。本稿は、ソフトウェアプロジェクトのビジネスケースを作成する上で重要な要素について解説する。

PoCで強力な財務的根拠を示す

　ソフトウェアベースのPoC（概念実証）は、技術的な観点から重要と見なされる取り組みへの資金獲得を目的としているが、表面的にはビジネスニーズを反映していないこともある。

　例えば、「技術的にはまだ使えるが、新しいアプリケーション設計アプローチを追求したり、最新の開発ツールを実装したりすることが難しいレガシーアーキテクチャを置き換えたい」と思っているソフトウェア開発チーム（以下、チーム）があるとする。プログラマーなど開発に携わっている人であれば、そうした取り組みの意味や利点を理解できるだろう。しかし、製品を管理するマネジャーや他の上級ビジネスサイドのマネジャーにしてみれば「彼らの議論はそれほど重要ではない」と感じるかもしれない。

　そのためチームは、PoCを通じてプロジェクトに対する強力な財務的根拠を示し、その作業が企業にとって投資を正当化するのに十分な利益をもたらすことを実証する必要がある。

意味のある指標を見つける

　ソフトウェアプロジェクトの強力なビジネスケースを作るには、PoCに、レビューするビジネスサイドのマネジャーが感覚的に、具体的で現実的かつ実証可能なROI（投資利益率）の数字に変換できる指標（メトリクス）を含める必要がある。

　ただ、どのような指標がビジネスサイドにとって重要なのかを知ることは簡単ではない。以下は、チームが財務用語に変換する必要のある、幾つかの典型的なPOCメトリックだ。完全なリストではないが、参考になるだろう。

技術的負債の削減

　技術的負債にはさまざまな形があるが、アジャイル開発のパイオニアであるウォード・カニンガム氏は「技術的負債とは、チームが実際の対象領域を無視して機能を実装し、プログラマーが学んだ情報を使わずにソフトウェアを修正したときに形成される運用上の副産物である」と説明した。

　技術的負債が増えるにつれてソフトウェア間の接続性が失われていき、アプリケーションコンポーネントと機能の開発に多くの時間が必要になる。ソフトウェアの専門家であれば、この技術的負債を削減する価値を理解しているが、ビジネス側に「技術的負債の削減を目的としたプロジェクト」を承認してもらうのは依然として難しい。なぜなら、技術者以外のスタッフにとって、そのようなプロジェクトは、既に動作しているソフトウェアを書き直すだけのように見えてしまうからだ。「会社に新たな価値を提供せず、チームの時間を浪費するだけだ」と。

　そのため、技術的負債の削減を目的としたPoCは、プロジェクトがもたらす具体的な財務的な利点（または生産性上の利点）を示す具体的な数値を提供しなければならない。

レジリエンスの向上

　ソフトウェアや、ソフトウェアをサポートするアーキテクチャの回復力向上を目的にすると強力なビジネスケースを作成できる。

　レジリエント（弾力性、柔軟性、回復力がある）なソフトウェア設計のコンセプトは、ソフトウェアにエラーが発生しないようにするのではなく、実稼働中のソフトウェアで障害が発生することを予測し、そのような障害への対策を開発者に前もって講じるように求めるものだ。

　例えば、Webサイトで特定のページを表示させるにはユーザーのログインが必要だとする。ログインせずにそのページを表示しようとした場合、単に「404エラー」を出すこともできるが、ログインする必要があるといったカスタムメッセージをユーザー向けに表示した方が柔軟性は高い。

　ビジネスの観点でいえば、レジリエントソフトウェア設計は、障害復旧時間を短縮し、ユーザー体験を向上させることができる。そのため、アーキテクトは、ダウンタイムの減少、顧客維持率の向上、販売量の増加などに回復力がどのように関連しているかを実証することで、回復力の向上を目的としたプロジェクトのビジネスケースを構築できる。

回帰テストの費用

　チームが機能の追加やその他の更新によってコードベース（アプリケーションを構成するソースコードの集まり）が壊れるのを防ぐのが回帰テストだ。これらのテストは役立つが多くの時間と労力がかかる。だからといって、回帰テストを遅らせたりスキップしたりすれば、最終的にコードベースの更新処理能力に関する不確実性を生み出すことになる。

　回帰テストが後になればなるほど、テストサイクルはより長く、より困難になる。そうなれば、チームはますます回帰テストの実行回数を減らし、問題は指数関数的に拡大するだろう。これは仮にテストを自動化しても解決しない。エンドツーエンドの広範な自動テストスイートの作成とメンテナンスには多くの時間が必要だからだ。

　この回帰テストの問題を解決する方法は、コンポーネントまたは機能ベースのコードベースを促進するアーキテクチャ設計を実装することだ。そうすることで、アプリケーションのある領域の更新が他の領域に影響を与えないようにできる。別の視点では、チームが独立してコンポーネントや機能をテストできることを意味する。これによって、アップデートの実行やバグ修正の展開に必要な時間と労力を削減可能だ。

　このようなアーキテクチャプロジェクトのROIを定量化するには、チームが回帰テストの実行にどれだけの時間を節約できるか、ソフトウェアの変更がどれだけ早く展開されるか、そしてそれらの改善が会社の経済的利益にどのように変換されるかを見積もる必要がある。

複雑さに対する生産性の測定

　ほとんどのアジャイルチームは、開発サイクルの速度を測定する何らかの方法を持っている。例えば、チームが毎週完成させる機能の数を計算する、各開発イニシアチブにどれだけの労力をかけるのが合理的かを評価するなどだ。

　スクラムのようなアジャイル特有の方法論は、理論的には1週間により多くの仕事をこなそうとする試みだが、現実には、時間の経過とともに、ソフトウェアコンポーネントの結合が進み、凝集度が低くなり、元のドメインモデルマッピングが実際のドメインを反映しにくくなるなど、さまざまな状況が生じる。言い換えれば、チームは、時間がたつほど開発が速くなることを期待するかもしれないが、そうなることはめったにないということだ。そのため、開発者の生産性を評価する際には、使用するソフトウェアシステムの相対的な複雑さを常に考慮する必要がある。

新規開発力

　ソフトウェアプロジェクトのビジネスケースは、重要なユーザー向けアプリケーションを開発、展開する全く新しい方法をチームに浸透させる能力にある場合もある。

　例えばチームは、開発者が再利用可能なAPIを使用してモバイル用に既存のWebアプリケーションを再設計できるローコードツールを推進するかもしれない。これは、ユーザーエンゲージメントの新たな分野を切り開くのに役立つだけでなく、専門的なモバイルアプリケーションプログラマーを雇う必要がなくなるため、企業がコストを削減できる可能性もある。

　「APIの再利用性」のような技術的なメリットをアピールしたくなるかもしれないが、そうではなく、ビジネス価値を考慮するよう努力することが重要だ。

ビジネスケースとPoCを構築するためのヒント

　プロジェクトの提案でビジネス面を語るには、ちょっとしたコツがいる。ありがたいことに、技術側のスタッフが採用できる特定の手法と戦略がある。それを使えばソフトウェアプロジェクトの強力なビジネスケースを作成する能力を強化できるだろう。

　ここでは、アーキテクト、開発リーダー、その他の上級技術スタッフが心に留めておくべきヒントを幾つか紹介する。

　1つ目は「PoCの指標は具体的であればあるほどよい」だ。

　もしある取り組みが、アジャイルチームがチームメンバーを追加することなく、1週間により多くのユーザーストーリーを生成するのに役立つのであれば、それは具体的な生産性の向上につながる。従業員の離職率や入社にかかる時間は、ソフトウェアチームのリーダーが新しい取り組みや開発アプローチの生産性の利点を測定するための指標として使える。

　2つ目は「強調すべき3つの指標がある」だ。

　ソフトウェアアーキテクトが特定のプロジェクトのビジネスケースを作成するために定量化しようとするメトリックは無限にあるが、特に強調すべき指標がある。「開発の生産性に関連するROI」「取り組みを追求するコストと何もしないコスト」「予測される財務上の利益に対する取り組みにかかるコストを計算した"包括的な”のROI」の3つだ。

　3つ目は「チームのリーダーはインフルエンサーとして活動する」だ。

　ビジネス側との関係形成に関しては、チームのリーダーがインフルエンサーおよびアドバイザーとして機能する必要がある。例えば、リーダーは最初に汎用（はんよう）プロジェクトのPoCを企画し、次に下位レベルの技術スタッフがそのPoCに具体的なアイデアを提供できるようにする。最終的には、下位レベルの技術スタッフが実装の一部を所有できるようになるのが理想だ。

　4つ目は「既存のアプリケーションを基にPoCを実施する」だ。

　可能であれば、新しい独立したアプリケーションではなく、既存のアプリケーションの改良実装としてPoCを構築するといいだろう。そうすればPoCのデモを準備できるまでに、チームは実装とデモンストレーションの準備ができている機能のコレクションをすでに構築していることだろう。これは、ストラングラーパターン（特定の部分のアプリケーションを徐々に置き換えていく方式）の実装が役立つ分野の一つだ。

　5つ目は「ソフトスキルが重要」だ。

　正式な会議に先立ち、主要なスタッフやビジネスパートナーと会い、彼らのアイデアやフィードバックを収集する。PoCによって彼らのニーズに応えられるように、プロジェクトまたは取り組みについての懸念を事前に尋ねておくことが重要だ。