トピック；中間管理職が考えるシステム、サービス導入におけるスコープ・マネジメント ポイント；伝統的なスコープマネジメントは有効。できるだけシンプルかつ網羅的に。スコープはビジネス領域で調整、交渉すること。システムではなくビジネス全体への影響、効果を配慮してスコーピングする。調整には非機能要件も含めること。 キーワード；スコープマネジメント、ビジネス領域、システム領域、ビジネス全体への影響

Topic: A scope management for implementing of IT systems and services considered by IT middle manager. Points:The traditional scope management method is still effective. It should be simple and exhaustive. Also, it should be managed and negotiated on business area not IT. Managers should review from a business point of view NOT IT point of view. Nonfunctional requirement should be considered in scope management. Keywords: Scope management, Business area, IT area, Effects for whole “Business” process NOT IT.

ベースラインは定額、全部入り？

システム開発のヒト・モノ・カネにおいて最大の前提条件かつ制約条件は”カネ”であることは間違いないでしょう。最初の見積りの段階でシステムの内容が決まってもいないのに偉い人がペロリと舐めた金額に合わせるように見積りが実施され、その金額は制約としてシステム完成（或いは完成後も）まで付きまといます。となると、お客さんとしてはその金額で”全部入り”のシステムを作ってほしいわけです。さらに厄介なのが”何が全部なのかお客さん自身がわかってない”ことです。ここに”限られたコストに対してスコープを広げたいお客さんと、開発規模を小さくしたい開発側の乖離”が発生することになります。

要求スコープと見積の関係（ppt file）

そのために”ベースライン”を作成し、然るべきステークホルダーが承認してシステム開発に着手することになるのですが、

• 最初から全てのスコープがわかっていることは決してない
  開発中、ベースライン上の仕様が変わらないシステムは基本的に無い
• ベースラインは誰が決めたのか
  そもそも”然るべきステークホルダー”とは誰か？偉い人がハンコを押しただけ？というケースもあり
• グレーゾーンのせめぎあい
  初期のベースラインに記載されていないグレーゾーンとしての追加、変更は
  ・お客さん；初期ベースラインに含まれている
  ・開発側　；初期ベースラインに含まれていない
  という水掛け論

という”仁義なき戦い”にプロジェクト・マネジメントのリソースがどんどんつぎ込まれることになります。ここでやり方が悪いとデスマーチが流れ、コスト、スケジュール、品質の悪化や、体調やメンタル不良のけが人が発生して悪循環となっていきます。そもそも概算見積もりなんて所詮は”当てずっぽう”、”政治的背景”に因る部分が多いです。これは近年でも変わっていません。

３つの真実
1.プロジェクト開始時点に全ての要求を集めることはできない
2.集めたところで要求はどれも必ずといっていいほど変わる
3.やるべきことはいつだって与えられた時間と資金より多い

出典；Jonathan Rasmusson著「アジャイルサムライ−達人開発者への道−」（オーム社）ISBN;978-4274068560

見積り根拠の合意形成～日本語で話してください

「ファンクション・ポイントとはどこの通貨か？わかる言葉で話してくれ」
見積り根拠を出してくれとお客さんに言われ、ロジックの積み上げをファンクション・ポイントでまとめて、過去事例や他システムとの比較で見積り根拠にしようとしたことがありました。しかしながら、まずファンクション・ポイントが何かというところで話が止まってしまい、上記のような言葉をもらいました。当然です、お客さんも上司に説明しなければならないので、同じことを上司から言われてしまいますね。開発側としての根拠ももちろん必要ですが、お客さん側での稟議を通すための見積り根拠が必要です。

• ビジネスとしての投資対効果が語れているか
• 本当に必要なシステム、サービスを見積もろうとしているか

がまずありきになります。
これらに対して高値の見積りしていないか、ということに対しては、類似や過去のシステム、サービスとの比較提示や、他者との相見積りをとってもらうで合意形成することになります。とにかく、アプローチとしては、”システム領域”ではなく”ビジネス領域”で語ることが最重要です。”この投資で自分達のビジネスが確実に良くなる”と思える提案、見積り根拠を提示するようプロジェクト・マネージャーに指示する必要があります。

スコープ・マネジメントで調整できるのは”スコープ”だけ～増やした分は減らしましょう

要件定義→ベースライン作成→ステークホルダーでベースラインのローリング(*)
が基本的なスコープ・マネジメントの流れです。(*)ローリングは概算見積りから見積り精度を上げていく活動を表していますが、その際の軸は、

• コスト（リソース）
• スケジュール
• 品質
• 仕様（スコープ）

の４つです。
コストは冒頭記述した通り、政治背景で決まることが多く、大抵は前提条件です。あからさまなビジネス要件変更や追加でなければ金額は動かないでしょう。スケジュールも同様です。スケジュール延期は人工の維持延長を意味し、ダイレクトにコスト増加になります。また、システム切り替えなどのタイミングもあるでしょう。品質については、当初のテスト計画を変える方がリスクがあります。マスターメンテナンスなど単純機能のテストを省きましょうという提案をしたこともありますが、実際に得られる効果（工数削減）は微々たるものです。

変更管理時のスコープ・マネジメント（ppt file）

結果として調整できるのは仕様のみということになります。「コストやスケジュールを変えられない以上、増やした分は減らしましょう」ということになるのですが、お客さんとしては

1. そもそも”追加仕様である”ことが理解できない
2. 当初”やる”と決めたことをやめることが理解できない
3. 追加対応することのインパクトが理解できない

というスタンスになり、大抵はスコープ調整の水掛け論になります。

ベースラインをきちんと握れ～1.そもそも”追加仕様である”ことが理解できない

システムやサービスを導入を開発、導入する際、よほどコモディティ化されたものでなければ、経験上、ベースラインは100%変更されます。但し、うまくベースライン承認の合意形成をしなければ、お客さん側は”定額料金全部入り”を頼んだ気になっている訳で、自分達の言い分が変わったとは言いません。実際、それは仕様を決めたステークホルダーではなく、現場のユーザーにとっては当たり前の機能だったり、非機能要件だったりします。また、システム、サービスの導入はお客さんにとって”大きな買い物”ですから社内稟議や上司への説明などがあります。ベースラインを提案する際にはコストや効果の異なる複数のプランを提示して「一番良いプランを選んだ」というアクションをお客さん側に持たせるべきです。過去、類似のシステムや他社のサービスとの比較を提示して合意するようプロジェクト・マネージャーに指示しましょう。
また、プロジェクト・マネージャーには初期ベースラインを決める際に下記に留意してもらい、レビューしましょう。

• ビジネスロジックで合意形成しようとしているか
• 非機能要件（処理時間や画面構成など）の工数について言及されているか
• ”現場で本当に必要なビジネスロジックなのか”を押さえているか
• お客さん側でビジネスロジックをコミットした人のオーソライズをきちんととっているか
• ベースラインが変わった（仕様変更、追加）の場合はコスト、スケジュール、品質、スコープのいずれかを変更する必要があることを合意しようとしているか
• お客さんに”勝ち”（選択肢）を持たせることができるか

ビジネス全体像と新機能を押さえているか～2.当初”やる”と決めたことをやめることが理解できない

多いパターンが”現行踏襲”という言葉で済まされてしまうパターンです。昨今はクラウド化によってプラットフォームの変更や集約による固定費の削減を狙うシステム、サービス導入が多いですが、お客さんとしては「今やれてることは当然やれるだろう」というスタンスの方がまだまだ多いです。また、ベースラインを決める際、話す相手が企画部門の人だったり、ビジネスの現場から遠のいた管理職の人だったりします。
実際にビジネスロジックを知っているのは現行のビジネスをしている若手の人だったり、派遣社員の人だったりする訳ですが、その人たちも知っているのは自分の業務だけでビジネス全体や、新システム、サービスに必要な”ビジネスの全体像”や”今後のビジネス戦略を踏まえた新機能”を考えることはできないのです。
すると誰が書くのかというと開発側が書くしかないです。要件定義をきちんとやって”なにをやるか・なにをやらないか”をベースラインで明確になっているかレビューしましょう。

• ”現行踏襲”というキーワードに要注意
• 現場で本当に必要な機能なのかを現場のお客さんに確認する
• ”ビジネスの全体像”と”今後のビジネス戦略を踏まえた新機能”は要件定義で吸い上げてベースライン化する

スコープを漏れなく語れ～3.追加対応することのインパクトが理解できない

よくあるケースが非機能要件です。例えばデータ構造的に複数のデータベース・テーブルにクエリをかけるので処理時間がとてもかかってしまったり、複数の外部サーバにアクセスするためトラフィックによる処理時間超過やセキュリティ要件を満足できなかったりする場合があります。これらはビジネスロジックではないため、お客さんと握りにくい部分です。また、画面構成も土壇場で物言いがつくことが多いですね。「表示ラベルくらいはすぐに変えられるだろう」から入り、どんどん対応スコープが増えるのはよくあることです。水面下の対応になってしまうと言えば、テストやドキュメンテーションへのインパクトも説明しにくい影響範囲です。
変更を管理する際には以下に留意しましょう。

• 非機能要件について言及する
  「概算だから」と、ロジックの積み上げだけやって、やっつけの見積りにせず、非機能要件やドキュメンテーション、テスト工数も加味して提案しましょう。
• ”逃げ”のインパクト説明にならないようにする
  見積る側としては追加、変更対応はできるだけ避けたいところ。どうしてもネガテイブな説明になりがちです。”ビジネスとして本当に必要な追加、変更”であるならば他の仕様スコープを調整することで押し込んだり、フェーズやイテレーションをかえて対応するなど柔軟な提案が必要です。
• 追加になる対応の判断基準を明確にしておく
  「多少の変更は今のコスト、スケジュールでやります」のラインは曖昧になりがちです。「ラベル名10個の変更」「アウトプットフォーマットの項目順変更はＯＫ、追加はＮＧ」など変更、追加となる基準を明確にしてベースラインと共に合意形成しておきましょう。

初期ベースラインを作った後は

経験上、初期ベースラインでステークホルダーとの合意形成に手を抜くと、コスト（追加費用やコンティンジェンシー）とスケジュール（遅延や延期の調整）がきつくなります。現場とのビジネスロジックの合意形成に手を抜くと品質が悪化したり、持ち出しの仕様拡大がどんどん広がったりします。
近年のアジャイル開発でも、

・最も大切なことは「見積もりをコミットメントではなく、ある時点での予測である」ということに合意すること
・見積もりを駆け引きの道具にしない
・対立構図から問題vs私たちへ

出典；西河誠,、前川直也、細谷泰夫著「わかりやすいアジャイル開発の教科書」（ソフトバンククリエイティブ）ISBN;978-4797371284

というポイントを挙げていますが、アジャイル開発の見積りの位置づけは、外部委託、一括請負契約が多い一般の日本企業のビジネス現場において、まだまだ受け入れられないのが実情だと思います。

システム、サービス見積りにおけるコミットのポイント（ppt file）

但し「問題vs私たちへ」の部分は今も昔も大切なところです。お金をもらっている以上、ベースライン構築と変更に伴う”駆け引き”は避けられないと思います。しかしながら、ビジネスロジックとしての問題や戦略の検討にまで対立を持ち込む必要はありません。We are in the same boat. どちらかというとシステム、サービス開発側がリードして”本当に必要なもの”をベースラインに反映していく必要があります。レビューする立場の中間管理職は対立の渦中に留まらず、プロジェクトが問題そのものと向き合うようにする舵取りも必要です。

We are in the same boat.～問題vs私たちのために

”本当に必要な仕様変更”をベースラインに反映するためにはどうすればよいのでしょう？ポイントは３つです。これらのポイントを押さえているかどうかをプロジェクト・マネージャーに確認しましょう。

1. 適切なステークホルダーをプロジェクトメンバーにする
   ベースラインの合意形成には意思決定をするステークホルダーが必要ですが、ベースラインをローリングしていくフェーズでは現場のお客さんの巻き込みが重要です。
   • お客さんの経営層に報告できるメンバー
   • 現場のビジネスロジックを熟知しているメンバー

   をプロジェクトメンバーに必ずいれましょう。

2. 開発、導入状況を可視化する
   お客さんを巻き込む以上、プロジェクトの状況が共有できなければなりません。だからといってシステム開発、サービス導入のWBSを共有してもIT用語の羅列ではどんなタスクがどんな状況なのかわかりませんね。お客さんと共有するスケジュールのタスクは”システム領域”ではなく”ビジネス領域”である必要があります。意識するのは”お客さん側のプロジェクトメンバーがそのまま上司に報告できる状況の可視化”です。
   ＜システム領域スケジュールの例＞
   基本設計　2日
   詳細設計　3日
   コーディング/単体テスト　3日
   結合テスト　1日
   ＜ビジネス領域スケジュールの例＞
   新規受注登録設計　5日
   新規受注登録実装　5日
   受注機能関係機能テスト　1日
3. 可視化のために工数をかけては本末転倒
   ”ビジネス領域”のスケジュールで共有することは大切ですが、だからと言ってプロジェクト・マネージャーが毎日”システム領域”→”ビジネス領域”の変換をすることは無駄な工数です。私は”出来高管理”で”ビジネス領域”を管理していました。システム成果物を管理するリポジトリの管理単位をビジネス領域にします。タグ打ちされるならリポジトリ内で一定のステータスを満たせば完了とし、これを自動集計するようにしておけば、手間暇かけずにお客さんのわかる言葉で進捗がわかります。
   
   
   システム領域とビジネス領域の連携（例）（ppt file）
   
   実際のPJにおいて、やり方はシチュエーションやお客さんを選ぶと思います。私は上記のようなやり方を実際にやってみましたが、アジャイル手法では”かんばん”、”あんどん”、”バーダウンチャート”といった手法もありますね。ポイントは”可視化のための追加工数をかけないこと”、”生の情報を開発側とお客さん側で共有すること”です。自分のビジネス領域でのベストプラクティスを見つけましょう。

まとめ

• 伝統的、古典的なスコープ・マネジメントはアジャイル開発時代の今も有効です。
• 但し、できるだけシンプルに、かつ網羅的に行う必要があります。
• 効率よくスコープ確認、合意形成するために”ビジネス領域”でスコープを語るようにしましょう。
• 同時に、コストやスケジュールには非機能要件など全体を漏れなく語ることも大切です。

私が実際に使った変更管理プロセスも紹介していますので、そちらも是非参照してください。
参考；IT中間管理職が実際に使ってきた変更管理


– 10th Aug, 2016 / the 1st edition