要件定義が終わり、「どのソリューションでいくか」を決めるフェーズで行うのがソリューション方針検討です。
良さそうなソリューションはいくつか見つかるものの、
- そもそもソリューションって何？
- 比較はしているけど、どうやって決めたのか説明できない
- なんとなく「これが良さそう」で進めてしまい、後から不安になる
といった悩みを感じたことはないでしょうか？？
ソリューションとは、要件を実現するための方法のことです。 新規開発、既存システム改修、ツール導入などがその例です。
PMやIT企画、情シスの立場では、このソリューション方針の決め方で一度は必ず詰まります。ですが実は、勘や経験に頼らずに進められる「決め方の型」があります。
この記事では、ソリューション方針をどう考え、どう決めていけばよいのかを、実務目線で整理します。
この記事でわかること
- ソリューション方針とは何か
- ソリューションをどう比較・評価すればよいか
- 実務で使える成果物（比較表・判断根拠）の作り方
ソリューション方針とは何か？
ソリューション方針とは、複数のソリューションの中から、プロジェクトで採用するものを決めることです。
ただし、単に「これが良さそうだから選ぶ」という話ではありません。
ソリューション方針は、複数のソリューションを、共通の観点で比較し、責任者が選択するための意思決定プロセスを経て決まるものです。
ここで重要なのは、次の2点です。
- 「良さそうだから選ぶ」ではない
- 「比較した結果、これを選んだ」と説明できること
そのため、ソリューション方針は、比較表とセットで検討・決定されるのが基本になります。こんなイメージです。
なぜソリューション方針を決めるのか？
ソリューション方針を検討する際は、複数のソリューション案を比較します。
では、なぜわざわざそのようなプロセスを踏むのでしょうか。
理由は、次の3つです。
- より良いソリューションを選択するため
- ソリューションを選択した理由を説明するため
- 手戻りを防ぐため
① より良いソリューションを選択するため
最初に思いついた案が、必ずしも最適とは限りません。
たとえば、
- 内製で作る
- パッケージを使う
- 既存システムを改修する
といったように、複数の選択肢を並べて初めて、違いが見えてきます。
これらを、要件実現度やコストなど同じ観点で比較することで、「なんとなく良さそう」という主観ではなく、客観的な判断でソリューションを選びやすくなります。
② ソリューションを選択した理由を説明するため
プロジェクトが進むと、必ず次のような質問を受けます。
- なぜこの方式にしたの？
- 他の選択肢は検討した？
特に、投資決裁を得る場面では避けて通れません。お金を出す側としては、「このソリューションに投資して本当に大丈夫か」が気になるからです。
ソリューション方針のプロセスを踏んでいれば、なぜこのソリューションを選んだのかを、論理的に説明することができます。
③ 手戻りを防ぐため
ソリューション方針が曖昧なまま進むと、
- 後から別案が出てくる
- 「やっぱり違った」と方針がひっくり返る
- プロジェクトが止まる
といった事態が起こりがちです。
特に、開発に入ってから「このソリューションでは要件が実現できない」や「想定以上にコストがかかる」と判明すると、大きな手戻りになります。
こうしたリスクを避けるためにも、事前にソリューション方針のプロセスを踏んでおくことが重要です。
ソリューション方針の決め方
ソリューション方針は、次の 4STEP で進めます。
- STEP1：比較観点を決める
- STEP2：ソリューション候補を集める
- STEP3：評価する
- STEP4：ソリューション方針を決定する
全体像としては、次のようなイメージです。
今回は、案件管理・進捗管理機能の実現を目指すプロジェクトを例に、各STEPを解説していきます。
プロジェクト概要
背景：
- 既存業務がExcel・メール中心で属人化している
- 業務進捗をリアルタイムに把握できない
- 事業拡大に伴い、手作業での運用に限界が見えてきた
目的：
- 案件・進捗管理をシステム化し、管理業務の効率化を図る
要件：
- 案件情報を一元管理できる
- 案件のステータス（未対応／対応中／完了）が把握できる
- 担当者・期限を設定できる
- 関係者が同じ画面で進捗を確認できる
- 将来的な機能追加・拡張の可能性がある
それでは、順番に解説していきます。
STEP1：比較観点を決める
ソリューション方針を決めるにあたって、いきなりソリューション候補を調べ始めるのはNGです。
まず最初に行うのは、「どの観点でソリューションを比較するか」を決めることです。
比較検討を行う以上、比較観点がなければ判断はできません。プロジェクトとして、どの観点でソリューションを評価するのかを先に決めておきます。
とはいえ、比較観点はある程度、定型化できます。よく使われる観点は、次のとおりです。
よくある比較観点
- ソリューション概要
- ソリューション詳細
- コスト
- 要件実現度
- 納期
- 開発難易度
- メリット
- デメリット
プロジェクトの特性によっては、ここに観点を追加します。たとえば、セキュリティが重要なプロジェクトであれば「セキュリティ」、利用者が多い場合は「ユーザビリティ」などを追加するとよいでしょう。
ポイントは、すべてのソリューションを同じ観点で比較することです。
また、比較観点が決まったら、どの観点を重視するか（優先度）も決めておきます。これは、後続の評価フェーズで判断軸として役立ちます。
今回の例では、上記の観点で十分と判断し、特に「コスト」と「納期」を重視する観点として設定します。
STEP2：ソリューション候補を集める
次に、比較対象となるソリューション候補を調査します。
この段階で大切なのは、「これが正解だ」と決め打ちしないことです。STEP1で決めた比較観点を意識しながら、まずは複数のソリューション案を集めていきます。
ただし、闇雲に集めると数が膨らみすぎるため、次のように整理して考えるのがおすすめです。
内製ソリューション
- スクラッチ開発
- 既存システム改修
外製ソリューション
- パッケージ
- SaaS / ツール
まずは内製の場合を検討します。
新しくスクラッチで開発するのか、既存システムを改修するのか、どのようなパターンが考えられるかを洗い出します。
次に外製ソリューションです。
パッケージやSaaS、ツールなど、要件に合致しそうなものを調査し、情報を集めます。DeepResearch などのAIを活用すると、効率よく調査できます。
いずれの場合も、STEP1で決めた観点に沿って情報を集めることが重要です。後続のSTEP3で評価を行うため、本STEPでの整理がそのまま効いてきます。
今回の例では、次のようなソリューション案を候補とします。
STEP3：ソリューションを評価する
次に、STEP2で集めた候補を、STEP1で決めた観点をもとに評価します。ここでは評価のみを行い、まだ決定はしません。
まず、これまでに集めた情報を比較表に整理します。
（比較表のサンプルはこちらからダウンロードできます。）
表にまとめたら、各観点について「○・△・×」などで評価を入れていきます。あわせて、評価理由のコメントも残しておきます。
最後に、全体を見て総合評価を行います。
このように整理することで、「なぜこのソリューションが良いのか／なぜ合わないのか」を客観的に判断できるようになります。
STEP4：ソリューション方針を決定する
最後に、比較表にまとめた評価結果をもとに、ソリューション方針を決定します。
ここでの重要なポイントは、責任者に決めてもらう、もしくは承認してもらうことです。プロジェクト計画書には必ず責任者が定義されています。しかるべき責任者に意思決定を委ねることで、プロジェクトを安全に進めることができます。
PMやIT企画の役割は、判断に必要な材料を揃え、比較結果をわかりやすく提示することです。
一方で、どのソリューションが最適かを最も理解しているのも、実はPMやIT企画担当者であることが多いです。
そのため、「どの案を選んでもらいたいのか」を意識しながら、比較表や資料を作ることも、実務では非常に重要なポイントになります。
まとめ
ソリューション方針は、プロジェクトで「何を作るか」「どう実現するか」を決める、非常に重要なプロセスです。だからこそ、主観やノリで決めてしまってはいけません。
ソリューションは、選ぶものではなく、比較して決めるものです。
複数の選択肢を同じ観点で並べ、客観的に評価したうえで決めた、という事実そのものが重要になります。
比較観点を定め、ソリューション候補を集め、比較表として整理する。
このプロセスを踏むことで、
- なぜそのソリューションを選んだのか説明できる
- 後から方針がぶれにくくなる
- 手戻りや炎上のリスクを下げられる
といった効果が得られます。
ソリューション方針を「感覚」ではなく「構造」で考えること。それが、プロジェクトを前に進めるための、確実な一歩になります。
おまけ：よくあるNGパターン
ソリューション方針検討で、現場で特によく見かけるNGパターンを2つ紹介します。
どちらも「やっているつもり」になりやすいので要注意です。
NG①：比較観点が曖昧・少ない
一応ソリューションの比較はしているものの、
- 比較観点が揃っていない
- そもそも、何を基準に比べているのか決まっていない
といったケースです。
この状態では、評価が担当者の主観に大きく依存します。結果として、
- 好き嫌い
- 過去の経験
- なんとなくの印象
で判断されがちになります。
その結果、
- 本当に最適なソリューションを選びにくい
- なぜそのソリューションを選んだのか説明できない
という問題が起こります。比較する以上、比較観点を先に揃えることが不可欠です。
NG②：ソリューションが先に決まっている
プロジェクトの初期段階から、「このソリューションを使う前提」で話が進んでいるケースです。
いわゆるソリューション先行で、手段が目的化してしまっている状態。
この場合、
- 要件実現度
- コスト
- 納期
- 開発難易度
といった観点での評価が十分に行われていません。
そのまま開発に進むと、
- 要件を満たせないことが後から判明する
- 想定以上にコストがかかる
- 手戻りや炎上が発生する
といったリスクが高まります。
また、比較検討を経ていないため、ソリューション選択の根拠を説明できず、投資決裁を得にくいという問題も起こりがちです。
たとえ最初から有力なソリューションがあったとしても、必ず他の選択肢と並べて比較し、客観的に判断することが重要です。
関連記事