前回までに解説した勘所

　前回までに、次のプロジェクト立ち上げ7つの勘所を解説してきた。

勘所の1　業務改革策を握る
勘所の2　プロジェクト要件定義による過不足ない遂行とリーダーシップ
勘所の3　プロジェクト方針を明確化し、これを実現する仕組みを仕込む
勘所の4　詰めるべきを詰める
勘所の5　握るべきを握る
勘所の6　意思決定課題を解く
勘所の7　ファクトでレビューする

勘所の1　業務改革策を握る
　業務改革策（イノベーションロジック：IL）は、IT用語を使わず業務の言葉だけでリターンがなぜ得られるのかをシンプルに説明できるロジックだ。ILを明確にしてその達成を意思決定者と握ることで、不要な要件を防止し、要件爆発をコントロールできる。また意思決定者のプロジェクトへの積極的関与を引き出して、推進のリーダーシップを発揮してもらうことを可能にする。

勘所の2　プロジェクト要件定義による過不足ない遂行とリーダーシップ
　プロジェクト要件は、プロジェクトの目指すところ（生み出す成果）と動き方（WBSやスケジュール、体制）を合せたフレームワーク、すなわちプロジェクト立ち上げの押さえ所であり、プロジェクト立ち上げの仮説項目だ。プロジェクト要件の定義・確認と改訂・レビューのサイクルを回すことで、過不足ない遂行とリーダーシップを実現する。

勘所の3　プロジェクト方針を明確化し、これを実現する仕組みを仕込む
　プロジェクト方針は、プロジェクトをなぜうまく進めることができるのか、という問いにシンプルに答えられる論理だ。プロジェクト方針は、プロジェクト活動そのものの改革策（IL）である。プロジェクト方針を定めることで、プロジェクトが具備すべき最適な仕組み（プロジェクト運営上の組織体制や会議体、制度やルールなど）を構築できる。

勘所の4　詰めるべきを詰める
　業務改革策（イノベーションロジック：IL）を論理的に定めることで、業務とITの目指す姿を想定することができるが、企業には複雑な業務ややり方が標準化されていない業務もある。対象がこの様な業務の場合、やり方（方法論のフレームワークにおけるメソッド）を詰めなければ、むやみに業務設計や機能設計をしても手戻りばかりとなる。詰めるべきものを見抜いて的確な進め方で詰めることで、以降のプロジェクト遂行がうまくいく。

勘所の5　握るべきを握る
　プロジェクトで発生する問題の中には、プロジェクト開始前に、関係者としっかり握るべきことを明らかにし、それを握っておくことで回避できるものがいくつもある。握るべきこと・握るべき相手・それをいかにして握るかを明らかにして実行することで、問題の発生をコントロールできる。

勘所の6　意思決定課題を解く
　意思決定課題とは、投資に対するリスクをゼロにすることはできないプロジェクトを、それでも決定しなければならない人が抱く様々な逡巡だ。意思決定課題は、プロジェクト内外の重要事実と意思決定者の意思から洞察する。これを解く提案をすることで、妥当な意思決定を得ることができる。

勘所の7　ファクトでレビューする
　プロジェクト立ち上げ＝システム化計画完了の達成水準は、システム化計画承認後のプロジェクトを計画通りに遂行できること、また、開発した情報システムで、計画通りの業務改革を達成しリターンが得られること、つまり後続する情報システム開発と業務改革のプロジェクトが成功する条件がそろっていることだ。ファクトでレビューすることで、この達成水準を満たしているかレビューを確実にすることができる。

勘所実践のために重要なプロセス（手順）

　勘所は、方法論の体系（ある仕事をするときにそれをうまくやるための統合技術）から見ると、コンセプト（なぜうまくやれるのかの基本的考え方）に相当する。これは連載第1回でも解説した。その中で、方法論の価値はコンセプトの優劣で決まること、プロセス（手順）とはコンセプトおよび方法から展開された仕事の進め方であることも解説した。だからと言って、「コンセプトさえ分かればプロセス（手順）は重要ではない」と理解してはならない。実は組織的にプロジェクト立ち上げのレベルを上げるためには、プロセス（手順）は非常に重要なのだ。

　仮に、あなたやあなたの所属する組織が、既に業務改革とそれを支援するITの開発が成功する条件を完備したシステム化計画を立案でき、承認獲得にも何も問題ない実力を有しているならば、勘所を活かすためのプロセスを学ぶ必要はない。しかし、その水準にない場合は、一人でどれだけプロジェクト要件を深く考え抜いても、大して水準が上がらないことが多い。システム化計画をジグソーパズルに例えるならば、組み立てることが出来る力があっても、パズルのピースが不足していては完成しない。すなわち考え抜くことがいくらできても知識や知見が不足すれば水準が上がらないからだ。

　パズルのピースにあたる知識や知見を一人で蓄積することは、単に時間がかかるだけでなく、意味解釈して「使える知見」にする効率も悪いのである。しかし何人かの社内の有能者を集めてディスカッションすれば、相互触発によって、一人で考えているよりも何倍もの知見の蓄積が可能となる。誰しも、一人で考えて完璧だと思っていた設計が、レビューをすることで思わぬ気付きが得られた経験があるのと同じである。

【次ページ】 MRDR方法論のプロセス9つのステップ