システム化計画プロジェクトのポイント！！（その11最終回） 〜つまらないIT仕事をワクワクさせる
「システム化計画プロジェクトのポイント」シリーズの第11回目では、前回に引き続き「新システム構築計画の策定」の進め方について説明していきましょう。
- システム化の目的の定義
- 新業務/システムの概要設計
- 新システム構築計画の策定
「新システム構築計画の策定」の中では以下のようなタスクがあります。
- 開発工程の定義
- 実行プロジェクトの定義
- 開発工数の見積もり
- 開発計画（スケジュール）の策定
- 推進体制の定義
- 課題に対するアクションアイテムの整理
今回は最後に「推進体制の定義」と「課題に対するアクションアイテムの整理」の２つのタスクを説明します。
５．推進体制の定義
前回の、開発スケジュールを引くときに仮定した人数規模で、推進体制を定義していきましょう。この段階では、人物の名前は全て入らないと思います。
そして重要なことは、社内の人間の行うべき役割、タスクと外部のコンサルタント、ベンダー等の行うべき作業を明確にしておくことです。特に上流工程、基本設計工程あたりまでは、内外混成メンバーとなることが普通なので、以下のようなプロジェクトのポリシーをしっかり決めておきましょう。例えば以下のような標準的なプロジェクトチームの役割があったとします。
- リーダー
- マネージャー
- エキスパート（外部可）
- ファシリテーター（外部可）
- スタッフ（外部可）
この中でリーダー、マネージャーは必ず社内の組織の人間でないと務まりません。しかしスキル補完の意味でエキスパート、ファシリテーターの役割は外部のコンサルタントでも良いと思います。スタッフは社内の人材育成の観点もあるので多少は内部の若手を入れておいた方がよいでしょう。ただ要員補完という意味で外部のメンバーでも良いと思います。
実際のプロジェクト体制は、開発工程によっても違いますが、各工程にあわせたチーム編成をこのプランの段階から見積もっておくことは可能かと思います。
６．課題に対するアクションアイテムの整理
ここまでで、システム化計画の最後のステップである新システム構築計画がだいぶ形になってきたものと思います。しかし、ここで作成されたドキュメントは仮説を積み上げた物であり、検討するべき事項が沢山できていると思います。
そうした検討すべき事項、すなわちプロジェクトに対する「課題」とそれに対する「アクション」を最後に整理することがとても大事なこととなります。
課題を洗い出す方法論は、これまでと同じです。
一人で全ての課題を洗い出すことはできませんし、またそれをメンバー全員が認識、共有することが大事なのです。したがって、この段階での「課題認識」と「アクション洗い出し」のおなじみのファシリテーションを使ったワークショップを行いましょう。
まず、全員でこのプロジェクト計画を実行する上で課題になることを付箋やホワイトボードを使いながら、どんどん洗い出して行きましょう。アプリケーションのこと、技術のこと、またはプロジェクトマネジメントのこと、どんな小さなことでも課題認識は大事です。とにかく可能な限り洗い出しましょう。
そのときに、参考になるフレームワークとして「フォースフィールドアナリシス」があります。以前のワクワクする会議シリーズでも紹介しましたが、以下のような２軸の中で課題を整理する方法です。
- プロジェクトに対する推進力
- プロジェクトに対する抵抗力
この２つのベクトルがせめぎあって、組織としてこれから、ポジティブな力が強いか、ネガティブな力が強いかを予測するのです。またこの後のアクションのステップでは、抵抗力をかわしたり、弱くするにはどんなアクションが良いかを考えることができます。
ある程度課題がホワイトボードに書き出されたら、次にそれをグルーピングしていきましょう。グルーピングすることで全体が見えてきます。このあたりもワクワクする瞬間ですね！
グルーピングして課題がカテゴライズできたら、次にそれぞれのカテゴリーに対して、その課題をクリアするアクションを考えていきましょう。例えばいかのような軸で考えると良いと思います。
- 業務／アプリケーション上のアクション
- 技術基盤／テクノロジー採用上のアクション
- プロジェクトマネジメント上のアクション
- 経営上のアクション
次に出されたアクションを今度は上記軸を参考に整理していきましょう。その際、アクションですから、どの段階でアクションを起こすかが重要となります。
次の要件定義の段階から行うべきアクションがほとんどだと思いますが、その後の設計開発導入の段階でもそのアクションは継続が必要でしょうか。また継続する場合、段階的にアクションで解決するべき粒度やレベルが変わるかもしれません。そうしたアクションの時間軸での対応一覧表を作っていきます。
ここまでの「課題」と「アクション」の整理が終わったら、このシステム化計画の段階も終わりをつげます。
ただし、この後、一般の組織では、コンセンサスを取る、または合意形成を図る、さらにはトップの承認をとりつけるという承認ステップに入ります。その中で、今までの検討してきた内容に修正を入れざるを得ないかもしれません。
その場合、システム化の目的や新業務／システムの概要設計については手戻りをあまりするべきではありませんが、この最後のステップである新システム構築計画については以下のような修正がはいることがあります。
- システム化の目的の定義
- 新業務/システムの概要設計
- 新システム構築計画の策定
＜新システム構築計画の修正可能性ポイント例＞
- 開発範囲
- 開発期間
- コスト
要は最初から大きな開発を一気に行うのか、または範囲を小さくしてその後長い期間で段階的にシステムを開発していくのか、またその中間か、ということです。
こうした計画本来のバリエーションについてもプロジェクトメンバーでアイデア出して、複数案作っておくという方法も、その後のコンセンサスを考えると良いのかもしれません。
以上がとても長いシリーズになりました「システム化計画」立案に対して、ファシリテーションという方法を活用したワクワクした方法論！になります。
当方法について具体的にご興味があれば是非、ご連絡ください！！