企画

価値発見と業務要件を、専門領域として深めたい

私は、与えられた課題をどうシステム化するかだけでなく、そもそも何を変える価値があるのかを見つけるところから関わりたいと考えています。そのためRosariumでは、企画を独立した知識・判断の領域として設けました。

利用者・事業・組織にとっての価値を確かめ、どの業務課題を優先するか、何を変え、何を変えないかを決める。その判断を業務要件とシステム化範囲にまとめ、要件定義へ渡す仕事を、今後の専門領域として深めたいと思っています。

価値 → 業務課題 → 業務要件 → システム化範囲 → 要件定義 → システムアーキテクチャ → 実装・検証 → 運用・改善、というつながりを考えます。技術検証や利用者評価の結果から、価値や要求を見直す反復も含みます。

出発点は「AIで何を作れるか」ではありません。「何を変える価値があるか」を確かめた後で、AI、既存システム、通常のソフトウェア、業務手順や人間の役割の変更、システムを作らない選択を比較します。AIを使わないことも、企画の正式な判断です。

ここで示すのは、今後深めたい知識と判断領域です。現在、私がシステム企画を担当した公開可能な実務Caseはありません。将来、実際の企画判断を公開できるようになったときの受け皿としても育てていきます。

現場での具体化と、企画の問い

FDE的な仕事には、現場理解、課題把握、プロトタイプ、利用者評価、要求具体化、実装・改善が含まれます。ここでは「現場課題をどう具体化し、どう実装・改善するか」という問いとして捉えます。

企画で強調したい問いは「そもそも何を変える価値があり、何を業務要件として定義するか」です。目指す業務成果、KPI、優先順位、今回の範囲と対象外を決めます。現場での具体化と重なる部分もありますが、職種の優劣ではなく、主に扱う判断の違いとして区別します。

企画で決めること

• 課題・価値・目標

  現状（As-Is）と目指す業務（To-Be）を比較し、利用者・事業・組織にとっての価値と優先する業務課題を特定します。業務プロセスを見直し、業務要件・KPI・効果目標を定めます。

• 対象・投資・優先順位

  システム化する業務と対象外を分け、既存システム、通常のソフトウェア、業務手順や人の役割の変更、作らない選択も比較します。費用・期間・維持責任から優先順位を決め、刷新・維持・縮小・統合・廃止を判断します。

• 新技術・PoCの企画判断

  AIを使うか使わないかを含め、新技術の採用を目的にせず、不確実性を確かめるPoCが必要か、何が分かれば継続するか、費用と期間の上限を決めます。技術方式・評価データ・合格条件の設計は要件定義・システムアーキテクチャで具体化します。

• 要件定義への引渡し

  対象業務、目的、業務要件・業務目標、範囲と対象外、制約、優先順位、未確定事項を渡します。業務要件を技術名へ置き換えず、実現可能性を確認した結果は企画へ戻します。

企画からシステム要件へ

企画 → 業務要件・業務目標 → システム要件 → 実現方式を区別します。業務要件・業務目標は、企画の中で決める内容です。企画では、何を変え、何を変えないか、何をシステム化し、何を対象外にするかを決めます。

システム要件は、企画で決めた業務要件を受けて、情報システムとして満たすべき条件を定義したものです。利用者とシステムの役割、機能・非機能の条件を具体化します。実現方式では、その条件を満たすためにAI、ベクトル検索、RAG、HITLなどの方式を比較・選択します。

上の企画方針と業務目標は企画部門から与えられた前提です。生成AI / RAGによる顧客サポートDXは、その業務要件をシステム要件と実現方式へ具体化する事例であり、企画実績ではありません。目標値は達成実績を示しません。

この流れは固定的な工程順ではありません。現場理解、仮説、プロトタイプ、利用者評価を通じて要求を具体化し、PoCや運用の結果から企画へ戻ることもあります。企画を変更する判断と、実現方法を変更する判断は分けて記録します。

企画の判断を考える

• IT戦略では「何を作らないか」も設計する

  システムを新しく作る前に、保守・変更・移行・廃止までの負担を考えます。既存の仕組みを使う選択も含め、作るものと作らないものを判断します。

• AI化する前に、業務そのものを疑う

  AIへ任せる前に、その仕事をなくす・まとめる・変える・単純化できないか考えます。業務改善の手順（ECRS）を踏まえ、残る仕事を人間・既存ソフトウェア・AIのどれへ任せるか判断します。

現在、公開中の企画事例はありません。この領域では、企画の知識と判断原則を整理しています。