システム化プロジェクトの悩みどころ！スコープを選択・決める際の基準とは
ubstorys_admin（2022/4/2 更新しました）
いざシステム開発。
あれもこれも入れたくなるものです。
さて、あなたがプロジェクトリーダーなら どうしますか？
あなたが、最終選択する必要があります。
メンバーの要望かなえてあげたいですよね。
一方で、全てに対応していたら コスト・期間もかかります。
今回は、私自身がプロジェクトリーダーとして スコープを選択し決める際に 基準としていたこと について紹介したいと思います。
スコープの選択とは
システム構想・要件定義フェーズで、ユーザーの要望を織り込みます。
せっかくの機会です。
困っていること 織り込みたいですよね。
少しでも利便性も 良くしたいところです。
システムの仕様は、どんどん膨らみます。
当初の計画の２倍ぐらいに膨らむケースも 多くあります。
とはいえ、開発費用には 制約があります。
開発期間も それほど伸ばせるものではありません。
システム構想・要件定義フェーズの最終段階では、選択する必要があります。
選択というのは、要望を取り下げること・落とすことです。
当然、反発も起こります。
プロジェクトリーダー、ひとりの人間です。
感情もあります。
悩みますよね。
私自身も、いつも頭の痛い問題でした。
それでも、選択しないといけません。
選択基準を持つ必要性とは
システム構想・要件定義フェーズの各最終段階で、見積もりの工程があります。
各フェーズの仕様を織り込んだ場合のコスト・期間の見積もりです。
大体の場合、見積もり結果が出るのは 各フェーズの終わり ギリギリのタイミングです。
選択できる期間は、ほとんどないのが 現実だと思います。
見積もり結果は、仕様の各機能に対して コストが出ているのが普通だと思います。
○○を作成する機能：２０人月 といったイメージです。
先ずは、機能単位で選択します。
そして、工数の多い機能で 削減できることはないか検討します。
これを短い期間で選択することになります。
選択の時期から考え始めていたら、とても間に合いません。
そのためには、事前に選択の基準を持っている必要があります。
スコープの選択基準
どんなシステムを開発するかによりますが、３つに分けて考えると 選択は早くなります。
私は、ほとんどの場合 この基準に基づき 選択しています。
- 絶対必須なもの
- 運用するのに必要なもの
- それ以外
重要性・緊急性など評価基準を使って選択するのではないの？
疑問 ごもっともです。
ただ、前記したように短時間での選択が必要です。
評価基準で評価して決める時間はありません。
システム開発のユーザー部門のプロジェクトリーダー経験者であれば、わかっていただけると思います。
どちらかというと、評価基準は 選択した後に納得してもらうために使うもの と割り切っています。
もちろん、最終的には きちんとまとめています。
絶対必須なもの
今回開発するシステムの目的・コンセプトに該当するものです。
問題解決のために システムを開発・導入します。
その問題解決する機能は、絶対に必須ですよね。
以前の投稿で、コンセプトの創り方を 紹介しました。
システムの構想書に織り込むことも 紹介しています。
（下に投稿記事記載します）
少なくても、システム構想書に織り込んだコンセプトは、絶対に達成する必要があります。
これならば 絶対に必須なもの、見分けができると思います。
そして、必ず選択します。
運用するのに必要なもの
システムは、ツールです。
運用があって、初めて利用できます。
以前の投稿で、システムでやること・運用でやることを 明確に分けることを 紹介しました。
そして、業務フローに落とすことも 紹介しています。
（下に投稿記事記載します）
絶対に必須なシステム機能も、単独では動きません。
例えば、新製品の情報を入力するとします。
そのためには、入力する用の箱を 最初に準備する必要があります。
箱を作成する機能がなければ、入力もできません。
運用するのに必要なものは、必ず選択します。
但し、年に１件とか頻度の少ないものは、システム側の運用とする方が良いです。
そのために画面を作成するのは、ムダな投資です。
それ以外
大きく３つに分けられると思います。
- 品質を担保するもの
- 利便性を向上させるもの
- この機会に入れたいもの
以下、順番に紹介します。
①品質を担保するもの
今回開発するシステムに必要な 情報の精度によります。
お客様・社外に提供する重要な情報であれば、できる限り選択します。
ミスを誘発した事例 たくさん持っていると思います。
パレートの原則にのっとり、選択します。
全て織り込むものではありません。
②利便性を向上させるもの
「これぐらいシステムでやってくれないか」後からクレームが入るものですね。
システムを立ち上げると 必ずこの手のクレームがきます。
費用対効果を考え 選択します。
利便性に関するものは、後からでも機能追加できるものが ほとんどです。
大きなクレームになりそうなものを優先します。
最後は 「どこかのタイミングで検討しよう」
プロジェクトリーダーは、言い切るしかありません。
③この機会に入れたいもの
本来の目的・コンセプトとは、異なるものです。
コスト・期間との関連で、無理ならば落とします。
但し、中には 後からの機能追加では難しいケースもあります。
この場合は、費用対効果で選択します。
私の場合は、よほど費用がかからない限り、選択する方を選びます。
その分、どこかの機能を落とします。
ほとんどの場合、見積もりが出てから１日か２日での選択です。
皆で集まって議論していては、とても間に合いません。
メンバー毎に、選択基準が異なります。
選択は、中立的な立場であるプロジェクトリーダーの責務だと思います。
また、プロジェクトリーダーは 後日メンバーに納得してもらう必要があります。
説得ではなく納得です。
システム構想・要件定義の中で、３つの振り分けができるレベルで機能を把握しておくこと 重要です。
まとめ
システム構想・要件定義で、ユーザーの要望を織り込みます。
やりたいこと一杯ありますよね。
当然、システムの仕様は どんどん膨らみます。
とはいえ、開発費用には 制約があります。
開発期間も それほど伸ばせるものではありません。
今回は、私自身がプロジェクトリーダーとして スコープを選択し決める際に 基準としていたこと について紹介しました。
選択基準を持つ必要性とは
システム構想・要件定義フェーズの各最終段階で、見積もりの工程があります。
各フェーズの仕様を織り込んだ場合のコスト・期間の見積もりです。
ほとんどの場合、見積もりが出てから１日か２日での選択です。
選択の時期から考え始めていたら、とても間に合いません。
そのためには、事前に選択の基準を持っている必要があります。
スコープの選択基準
私の場合、３つの基準で選択します。
- 絶対必須なもの：システムの目的・コンセプトに該当するもの。必ず選択
- 運用するのに必要なもの：必ず選択
- それ以外：以下参照
それ以外
大きく３つに分けて 選択します
- 品質を担保するもの：パレートの原則にのっとり 選択
- 利便性を向上させるもの：大きなクレームになりそうなものを優先
- この機会に入れたいもの：後からの機能追加では難しいケースは 基本選択
私自身も、スコープを決める際は いつも頭の痛い時期です。
それでも、選択し最終決定をしなければなりません。
選択は、中立的な立場であるプロジェクトリーダーの責務だと考えています。
また、プロジェクトリーダーは システム構想・要件定義の中で、３つの振り分けができるレベルで機能を把握しておくこと 重要です。
これもプロジェクトリーダーの重要な責務です。
今回は システム開発で投稿しましたが、プロジェクト全般でいえることだと思います。
参考投稿記事：円滑なシステム導入のために！導入前の運用検討が最も重要
