業務切り替えの山崩し、あるいはプロジェクトを段階稼動させる理由

★「稼動」はプロジェクトの華
新しいWebサイトがオープンする、古い経理システムが新システムに切り替わる、といったシステムの稼動はドキドキするし、ワクワクするし、ビクビクする。
システムに限らず「業務手順や制度や役割分担を今日を境に変える」という業務切り替えの場合もある。もちろんシステムの変更と業務の変更を同時にやるケースも多い。

プロジェクトが始まってから、半年とか長ければ2年とか、議論を積み重ねまくり、システムを作りまくり、業務が上手くまわるかをチェックしまくり、担当者の皆さんに説明しまくり・・
全ては稼働日に、新しいシステムや業務に上手く切り替えられることをいったんのゴールとして進めていく。

稼動判定会議で「本当にリスクがないのか、リスクがあったとしても許容範囲内か？」をシビアに議論する時もある。稼動が決まったとしても、1週間近く切り替え作業をミスなく進めなければならない場合もある。

どちらにせよ、稼動≒業務やシステムの切り替え、というのはプロジェクトの一つの終着点であるし、華である。
「お祭り」と呼ぶ場合もある。僕は学生時代に学園祭の運営委員だったのだけれども、延々一年かけて準備したことが、たった3日間の学園祭当日に凝縮される感じが、感覚としてすごく近い。

★業務のことを考えると、稼動は緩やかにやるしかない
この「プロジェクトの稼動のさせ方」について、僕らは結構早い段階から議論する。
もちろん細かいところは後から詰めていけばいいのだが、大きなレベルでは、プロジェクト計画を立てる際、つまりプロジェクト予算が確定する前の構想立案時点で決めてしまうことが多い。
何をどうやって稼動させていくか、というのはプロジェクトのマスタースケジュールを決めるとても重要な要素だし、色々なことへの影響が大きいからだ。

もちろんプロジェクトやお客さんの会社の事情によって、立ち上げ方は様々なのだが、極力一発稼動は避け、段階的に稼動させることを目指す。
なぜなら、一発稼動は業務を担当する方々（システム構築プロジェクトの場合はユーザー）の負荷が高くなりすぎるからだ。

もし、単にシステムを置き換えるだけのプロジェクト、ユーザーの業務が何も変わらないプロジェクトならば、業務担当者の負荷はあまり気にしなくても良いのかもしれない。だとしたら、単純にシステムを作るコストが一番安い方法、つまり一発稼動をすれば良い。段階稼動は通常、一発稼動よりもコストが高くなるのだから（高くなる理由については今回は割愛）。

しかしせっかくシステムを変えるのであれば、そのタイミングでしかできない業務整理や制度変更をセットにすることが多い。そうするとどうしたって、業務担当者の負荷をある程度押さえなければならない。

業務ルールや役割分担を新しくすると、現場はたいてい混乱する。
そして新しいことがあまりに多く、準備ができていないと大混乱、大不具合、大残業になり、ちょっとくらい頑張ったって乗り越えられない。
業務担当者の時間というものは、プロジェクトで数少ない「お金で買えないモノ」なのだ。

従って、稼働時の大変さはマネージできるレベルに押さえなければならないし、そのためには1回の稼動で起きる「新しいこと」を分散させるしかない。

これを僕らは「山崩し」と呼んでいる。
イメージ図を見て欲しい。

大変さの山が高すぎると組織が耐えきれないから、後回しできることを最初の稼動からはずしていく。そうは言っても、やることの総量は変わらない訳だから、高原状態になる。ずーっと大変さが続く、という意味ではこれはこれで精神的にキツイのだが・・。

★忘れてはいけない、もう一つのメリット
山崩しのメリットはそれだけではない。
稼動の大変さを一定以下にすると、通常業務との掛け持ちができるため、プロジェクトの仕事をコンサルタントやベンダーに丸投げせずに済むのだ。

その面では、コストは安くなる。それよりもっと大切なことは、プロジェクトを乗り越えた経験、業務やシステムを一から設計する経験を積めること。
これはお金では買えない価値だ。ノウハウが（外部のベンダーではなく）組織内に残るから、稼動後に改善をする際に何かとお金が必要に・・とはなりにくい。
社員も成長する。はっきり言って、プロジェクトの一番「おいしいトコロ」なのだ。

★山崩しの方法は色々

山崩しの典型的な方法は、稼動対象の組織を絞ることだ。例えば10工場のうち、2工場を先行稼動させる作戦。
また、業務領域ごとに順番に稼動させる方法もある。まずは人事領域、次に販売管理領域・・という具合に。

その2つの作戦がどちらも採用できない場合もある。業務やシステムが密接に絡みすぎていて、稼動タイミングを分けるとかえって混乱したり、インターフェースプログラムを作るのが大変過ぎたりする場合だ。

それでも稼動を分け、業務担当者の方々の負荷を一定レベルに押さえたいときがほとんどで、そんなときは仕事の「重要度や必要性」でグルーピングして、段階的な立ち上げを目指す。

それを最初からやらず、単にダラダラと「間に合わなかったから後回し」は最悪だ。そうするくらいなら、最初から計画的に段階稼動させた方が、プロジェクト予算的にも、参加しているメンバーのモチベーション的にもずっといい。

計画的にやる以上、ステージごとにテーマを決めるべきだ。「今はこの段階だから、これが大事！」を共有しているチームは強いからだ。
僕はこんな↓感じの4段階に設計することが多い。

ステージ1：ないと死んじゃうものだけ

ステージ1.5：ホントはステージ1でやるべきことを拾う

ステージ2：これぞプロジェクトでやりたかったこと

ステージ3：成功に味を占めてどん欲に

★段階稼動のメリットをもう一つ
こうやって稼動を段階的にやることのメリットはもう一つある。ステージ1を最低限に絞るということは、ステージ1までの期間がかなり短縮できることだ。

色々なプロジェクトの計画を立てていると、様々な理由で「とにかく急がなければ」というケースが多い。ただ、「急ぐ」の中身をキチンと検討すると、ほとんどの場合はステージ2や3でやるようなことまで求めている訳ではない。プロジェクトが完璧に終わって成果を出し尽くすことのスピードではなく「まずは最低限、ステージ1だけでも形になっていること」のスピードが求められているのだ。

以前「プロジェクトファシリテーション」という本に書いた古河電工のケースでは、関係会社の上場という、プロジェクトの事情よりはハイレベルな経営的なニーズで、無茶なスケジュールを求められていた。

あのとき、その無茶に応えられた理由は色々あるけれど、もっとも根本的な勝因は、プロジェクト計画を立てたときに、ステージ1でやろうとしたことをかなり絞り込んでいたこと。
お客さんのプロジェクトメンバーの多くは、本来やりたかったチャレンジを後回しにしていたことに不満をお持ちだったと思うけれど、何もかも第1ステージに盛り込んでいたら、絶対に経営ニーズには応えられていなかった。

ステージ1から3まで、各ステージの特徴についてもう少し語りたいことはあるのだが、ちょっと長くなったので続きは次回に。