コンセプチュアル・マネジメント

◆２種類のプロジェクト

プロジェクトは、ルーティンではできない業務を行うために行う。ルーティンは業務プロセスと所要時間がおおよそ決まっている業務であるので、プロジェクトは２種類に分けることができる。

一つは、業務プロセスが決まっていない業務を行うプロジェクト。業務変革、組織変革などの変革業務のプロジェクトは基本的にこのパターンである。プロジェクトで仕事をする一義的な意味はここにある。業務プロセスが分からないため、一から業務計画を作り、ローリングウェーブをかけて業務を進めていく。

もう、一つは、業務プロセスが決まっていて、その所要時間、担当者などに不確実性がある業務を行うプロジェクト。情報システム開発プロジェクトのほとんどはこのタイプだ。

このタイプのプロジェクトでは、業務プロセスが決まっていても、そのプロセスでの業務遂行ではスケジュール的に間に合わなかったり、あるいは、コスト的に折り合わなかったりすることがある。

このような場合、まずは業務プロセスを守ろうとすることが多い。つまり、スコープベースラインを変えずに、コストベースラインを変えたり、リソースベースラインを変えたりすることにより、制約をクリアしようとする。ただ、それでも制約がクリアできないケースが増えている。制約が厳しくなっているためだ。

そうすると、次は業務プロセスを変更せざるを得ない。（プロジェクト）スコープの変更だ。

プロジェクトで仕事をする第二義的な意味はここにある。ルーティンの計画では、業務プロセスを変更した計画をすることはできない。


◆業務プロセスと業務支援プロセス

ちょっと脱線するが、業務プロセスを変更しようとすると厄介なことがある。通常の業務はコアの業務プロセスだけでは完結しないことだ。たとえば、ＩＴ開発を行うには、調達・購買、法務、品質保証、人材育成、経理、会計などの支援業務が必要であり、多くの組織ではこれらはプロジェクトの外で、シェアドサービスやオペレーションとして実施されている。通常（ルーティン）の業務プロセスはこれらのシェアド・サービスのプロセスと整合しているというか、業務プロセスの一部になっている。

そのため、プロジェクトで実施する業務プロセスを組み替えると、シェアド・サービスとの整合性が問題になってくる。言い換えるとプロジェクトで業務プロセスを変更するためには、プロジェクトの業務プロセスの中にこれらのプロセスを抱える必要が生じる。

プロジェクトでは、支援業務もプロジェクト業務として設計し、遂行していく枠組みを与えている。


◆プロジェクトに新しい業務プロセスの考え方を取り込む

このように、プロジェクトとして業務を実行することにより、新しいプロセスへのチャレンジが可能なったり、制約条件のクリアが可能になる。特に、新しい業務プロセスをプロジェクトに取り込むことができるようになることは重要な意味がある。

たとえば、最近ＩＴ系で注目されている業務プロセスにアジャイル開発がある。

あるいは、商品開発で注目されているデザイン思考によるユーザ中心の業務プロセスがある。このような新しい考え方のプロセスを取り入れていこうとしたときにプロジェクトという、業務プロセスを定義しなおせる枠組みを使うことにより、マネジメントの枠組みも提供されるからだ。


◆プロジェクトマネジメントにより新しい業務プロセスが価値を生み出す

そして、新しい業務プロセスは、さまざまな新しい価値を生み出す。時に、最近注目されているのがイノベーションである。イノベーションを実現するには、プロジェクトとして目標と業務を定義し、ローリングウェーブを実行していくことが不可欠である（それだけで必ずイノベーションが実現できるわけではないが、必要条件の一つである）。

この際、アジャイルやデザイン思考を業務プロセスだけで行うと、経営的な観点からのマネジメントをどのようにしていくのかという問題が出てくる。そこを補完するのが、プロジェクトマネジメントである。

つまり、プロジェクトマネジメントでは、業務計画（プロジェクト計画）と、業務管理計画（プロジェクトマネジメント計画）を策定することができる。ここがミソである。