タイム・コンサルタントの日誌から

全てをスケジューリングする必要はない

前回の記事で、日本企業はしばしば、過剰に計画したがる傾向がある、と書いた。その主な理由は、先にお金の出入り（予算）を押さえておきたいためと、リスクに対する不安があるためだ。研究開発や業務改革などは、スコープ自体が柔らかくて、行うべきアクションの内容や仕事量が精度よく見積もれないのに、過剰な細部まで先に決めたがるのである。

似たような事情は、プロジェクト・スケジュールや、生産スケジュールにおいても起こり得る。そもそもスケジューリングとは計画作業の一部だから、まぁ当然と言えば当然である。

この傾向は、日本よりも計画重視の傾向が強い米国発で、日本に持ち込まれたのかもしれない。もともとPERT/CPMなどのプロジェクト・スケジューリングの手法は、1950年代に、アメリカで開発されたものだ。

実は同じ頃、生産スケジューリングの理論においても、アメリカで重要な発見がなされた。それは、ジョンソン法と、ジャクソン法と呼ばれる手法だ。いずれも、RAND研究所における発見である。RAND研究所は米軍系列のシンクタンクであり、当時の作戦研究（OR = operations research）のメッカでもあった。

これについては、かつて拙著「革新的生産スケジューリング入門」で触れたことがあるので、以下その第3章から少し引用させていただこう。

「今日はまず、ジョンソン法の話から始めましょう。

ジョンソン法は、生産管理の本などには必ずのっている、古典的なスケジュ ーリング理論の手法です。ある意味では古典的理論の成果といってもいいでしょう。

今、2段階の工程からなる製造過程を考えます。ジョンソン法は、この2段階の工程に複数の生産オーダーが出ているとき、どういう順序でやれば全体の作業期間が最短になるかを教えてくれます。具体的には以下の手順で順序付けを行います。

(1) 未決定の生産オーダーのうち、工程作業時間が最短のものを選ぶ。

(2) その作業が第一工程なら未決オーダー群の着手順の最初に、また第二工程なら最後に割付ける。

(3) そのオーダーを、未決オーダー群から削除し、(1) に戻る。

こうして未決オーダー群がなくなったら終了です。

この例では、2つの工程の加工の順序が決まっていますが、製造作業の内容によっては加工の順序を逆にしてもいいものがあります。そのような工程を、ランダム・ショップと呼びます。工程の順序が決められていて変えることができないものは、フロー・ショップと言います。ジョンソン法はフロー・ショップの順序付け手法ですが、これをランダム・ショップに拡張したものがジャクソン法です。

ジョンソン法の考え方を、自由度という観点から解釈するならば、作業時間の最も短いものから順に端に置いていくのですから、『自由度消費が最小になるような順序で着手順を決めよ』ということになります。

さて、このジョンソン法の成り立つ条件は、次のようなものです。

・すべてのタスクの作業時間が確定していること(1点見積り)、かつその見積りどおり変動なく実行できること

・すべてのタスクの納期が同じであること、ないし納期(の優劣)は気にしないこと

・すべてのタスクが着手可能であること (EPST = Earliest possible start timeが同じ)

・タスクが後から次々飛びこんできたりしないこと

・2工程であること (3工程以上には簡単に拡張できない)

このように条件をならべてみると、ジョンソン法が実務上使える範囲はきわめて限られていることがわかります。数学的に最適性が保証されているので理屈としては面白いですが、実用上の価値はほとんどないといっていいでしょう。」

金字塔的な古典理論に、実用的価値がない、などと書いたためかはわからないが、本書は出版当時、スケジューリング学会からは、必ずしも好評ばかりを得たとは言えなかった。スケジューリングの研究者たちは、スケジューリング問題を数学的な最適化の枠組みで解きたい、と言う問題意識を持っているからだ。

しかしわたしは同本の中で、「スケジューリングは最適化の問題ではない」とまで主張したので、議論を呼んだ訳だ。最適化の問題でなければ、一体何なのか。それは、動的な適応制御である。次々に入ってくる注文、時々刻々と変わる生産現場の状況、あるいはサプライヤーの納入、こうした外乱や変動にどれだけ上手に適応しながら、生産していくかを考えるのがスケジューリングだ。

そのためには最適化し過ぎてはいけない。最適化しすぎると、ちょっとした変更に対しても、計画全体がもろくなってしまう。変更の影響範囲が広がるし、再計算にも時間がかかる。むしろスケジュールの中に一定程度の自由度を残して、外部環境や内部状況の変動にうまく適応できるようにするべきだ。——これが同書で主張した私の基本的なスタンスである。

もともとスケジューリング問題は、いくつかの視点から分類 することができる。

機械群における最適な製品生産順序を求めるスケジューリング手法は、対象となる製造オーダの条件があらかじめ全て決められている静的問題と、オーダがつぎつぎ飛び込んでくる動的問題に分類される。

また、作業時間が確定的なものと、確率的なものがある。さらに工程数および加工順序に関して、いくつかに分類される。加工順序が決まっているものをフローショップ、加工順序が製品により前後しうるものをランダムショップと呼ぶ。これら問題の種類により、用いるべき解決手法が異なるのだ。

さらに、スケジューリングそれ自体に、多目的性がある。スケジュールを評価する指標として代表的なものは、

・最大滞留時間(総生産時間):全作業が終わるまでの時間

・最大納期遅れ:製品のうち納期に最もに遅れた時間

・機械の平均稼働率:機械群の稼働率の平均値

などがあり、スケジューリング問題の多目的性を示している。

こう考えてみると、古典理論におけるジョンソン法は、すべてのオーダーがあらかじめ与えられていて、かつ作業時間は確定的で、しかも評価指標は最大滞留時間を一番短くすること、と言う問題を解いていることがわかる。おまけにフローショップで、2工程の工場に限る。とても制約が多い。

だから、実際にジョンソン法を用いて生産スケジュールを動かしている会社というのは、少なくともわたし自身は日本で見たことがない。

古典理論は数学的な最適性が保障されているが、現実にはあまり使えない。そこで90年代以降出てきたのが、APS(Advanced planning and scheduling)と呼ばれるソフトウェア群だ。最適解は保障されないが、少なくとも現実的な規模の問題を、短い時間で解くことができる。

では、この道具を用いれば、あらゆる製造現場の問題を解決することができるか?　なかなか、そうはいかないのだ。

マスターデータの整備の手間が大変だ、と言う事はよく指摘される。それ以外に、私は2つボトルネックがあると思っている。

その1つは、生産の実績進捗を、なかなかリアルタイムに把握して、次のリスケジューリング時にフィードバックできないと言う問題。もう一つは、そもそも作業時間自体にある程度、ムラや幅があって、計画の精度が上がらない問題だ。

後者は例えば、なかなか品質が安定しない製造工程や、作業者の技量に大きく依存してしまう工程などで顕著である。工場と言うところは、同じものを同じペースで確実に製造できる、と思い込んでいる人も多い。そういう人は、半導体の後工程などを勉強すると良い。もう昔の話だが、Intel Pentium CPUなど、初期の良品率は10%すらなかったと言う。

そこまで特殊な例を出さずとも、多くの製造現場では、作業時間のブレに結構悩んでいる。そういうところで、すべてを細部までスケジューリングしようというのは、必ずしも得策ではない。

ではどうすべきなのか?　APSベンダーの人に聞くと、APSの適用には、概ね2つのパターンがあると言う。1つ目は、計画者が全部を細部までスケジュールするやり方。この場合、スケジュールを現場におろして、現場は単純にその指示に従うということになる。

もう一つのやり方は、現場側にある程度の裁量を残すやり方だ。例えば、タイム・バケットを1日単位で集約し、1日の中の各オーダーの着手順については、現場側の裁量に任せる。こうすれば、作業時間に多少の伸び縮みがあっても、1日の中で収めることさえできれば、現場のやりやすい順序で仕事を流すことができる。

このように、全てを細部までスケジューリングするばかりが、ベストな方法とは限らない。頭のいい計画者がいて、現場は全員、そのロボットのように動く、というイメージは、英米や中国のような中央集権的経営思想の強い国には向くかも知れない。だが、少なくとも日本では、必ずしも受け入れられないだろう。また、作業時間のブレを考えた場合、現実的でもない。

だからといって、現場側にあまりに裁量を残しすぎるのも、いささか心配がある。というのも、製造現場はしばしば縦割り組織になっており、必ずしも各職場が「全体最適」を意識して判断してくれるとは限らないから。

そこで、このような時に役に立つ知恵が必要になる。その一つが、優先番号法である。だが、また長くなってきてしまったので、これについては項を改めて、また書こう。

→「プロジェクトを計画しすぎてダメにする方法」 (2021-07-18)

→「生産マネジメント手法の系譜を考える(3) 90年代以降の発展とこれから」 (2018-08-11)

プロジェクトを計画しすぎてダメにする方法

「日本企業は、計画しすぎなんです。」——最近、ある外資系戦略コンサルタントから、こんなセリフを聞いた。いわゆるDXに関する話題の時だ。「計画して、それも細かく緻密な計画を立てて、石橋をたたくようにリスクを全て洗い出してから、はじめようとします。そして動き出したら、すぐ進捗率を問題にする。でも、そんなやり方では、イノベーションは動きません。」

たしかにまあ、日本企業、とくに製造業は、まず計画ありきで動いていると言ってもいい。年度計画（いわゆる「予算」）、月度計画、小日程計画・・。建設業も、似たところがある。全体工程表、月間工程表、週間工程表、等々。現場に行くと、計画表は、必ず目立つ位置にはり出してある。

だが、新しいビジネスモデルを創出するような、イノベーティブな試みは、目指すべき目的地が最初から決まっている訳ではない。登るべき山の頂が明確なら、アプローチの経路を地図の上に引き、どこまで登ったかで進捗率を測ることもできる。しかしイノベーションは、行き先も地図も定かならぬ旅路（ジャーニー）である。大きな方向性はあるだろうが、実際には小刻みに、道を探りながら進むしかない。

にもかかわらず、とくに国などの公的資金が入るような研究開発などでは、「計画しすぎ」の弊害が見受けられるように思える。研究開発には最低でも数年単位の時間がかかる。しかし国の予算は年度単位だ。だから年度ごとに、達成すべき目標をあらかじめ定めてから、始める。そして異様に細かな経費記録や詳細な経過報告が求められる。

このような考え方の底には、「研究開発に携わる研究者という連中は、自分たちの興味のおもむくまま、勝手に好きなことをやりたがるものだ」という信憑だか不信があるのだろう。たしかに、 大企業の中央研究所というお堀の中に住む人の中には、技術を具現化して利益を生み出すより、学会誌に論文を何本出すかに情熱を集中するタイプも、いることは、いる。実用よりも、真理探究の知的好奇心が、行動基準なのだ。

なので、そういう、いわば「ネコ型」の研究者の首に鈴をつけるために、大部な計画書の作成が義務づけられ、詳細な（しかも文章記述中心の）進捗報告の書式が定められる。計画書の提出で研究費が配分され、進捗が遅れると鞭打たれる。こうすれば集団で一つの目標を追いかける「イヌ型」の行動をとるはずだ、と思うのであろう。これが研究開発型プロジェクトを「管理」しがたる側の、ロジックである。

だが、技術開発というのは、未知に挑む仕事だ。途中で、大きなやり直しも生じやすいものだ。なのに、こういう官僚的な管理システムの中では、最初に決めた目標に向かって、計画で決めた通りのペースで進むことが求められる。途中でうまくいかないことが明らかになっても、大きく方針転換したり、中止する決断を、誰もしない（官僚組織でそんな事を決めれば、責任を追求されるからだ）。

かくて、数年後には意味の乏しい成果しか得られぬと分かっているのに、延々と無駄金を投じるような研究開発が進んだりする。公的資金が絡まなくても、官僚的体質の大企業では、似たようなことが起こりがちだ。

研究開発以外でも、新事業開発や業務改革といった分野のプロジェクトも、同様の問題を抱えるケースが少なくない。新事業の開発は、（同業ライバルのまるっきり真似をするのでない限り）どんな答えが出てくるか、あらかじめ決められない。業務改革プロジェクトもしかり。在庫削減だの省人化だの、KPI的な目標は先に与えられるかも知れないが、方法は誰もよく分からない。それなのに、詳細な計画を立てろと言われる。

だったら、計画なんて一切、立てなければいいではないか。まず動いてみて、考える。必要なのは、現場力。それで何が悪いのか？　誰か困る人がいるのか？

もちろん、時間が無限にあり、お金も使い放題、人も好きなだけ動員できるなら、それもありだろう。だが組織が抱える経営資源は、お金も人も有限だ。それは、なるべく有効に使いたい。これが、経営者の論理である。急にお金がいると言われたって困る。当期利益や来期予測から大きく外れたら、株主からも叱られる。

経営管理側が、プロジェクトチームに計画を要求する主な理由は、資金調達、つまりお金の出入りを予定したいからだ。でも、それだけではない。上に書いたとおり、実行者側に対する一種の不信感がある場合、どうしても詳細な計画を作らせ、説明させ、なおかつ実行段階に入ったら、進捗確認で尻をたたいて、都度モニタリングしたい、と考えがちだ。

ところが実行者側は、プロジェクトの初期段階ではそんなに詳細な計画なんて立てようがない、と考えている。仮に立てたって、その通りに進むはずがない。ここにギャップがある。

このギャップは結局、プロジェクト計画は誰のためにあるのか、何を目的として作るのか、という認識のズレから来る。

本来、プロジェクト計画は、プロジェクトの実行主体（現場側）が、必要なアクションの特定と、リソース（特に人と予算）のニーズを明らかにする目的で作るものだ。それにより、実行の当事者が、自分たちの進め方をある程度、イメージアップする。別の言い方をすれば、プロジェクト計画とは、モデル作りなのである。プロジェクトがどう進むか、どう進めたいか、に関するモデリングだ。

モデルとは、一種の近似である。全ての細部にわたって正確なモデルを作ることはできない。ただ、重要な部分だけは、ある程度精度良く、おさえたい。それが良いモデルだ。そして良いモデルができると、外部環境の変化などのイベントに、どの程度影響されるのか、どこが弱いのか、などのシミュレーション的検討にも使える。

つまり、プロジェクト計画というのは、実行主体が、頭の中で様々なシミュレーションを行って、いろいろな環境変化にも対応できるようにするために作るのだ。だから、前回の記事で説明したように、最後に「リスク・アセスメント」が来るのである。

ところで、プロジェクト計画は、実行主体（とくにプロマネ）が、外部のステークホルダ（利害関係者）に対する説明にも使う。そのステークホルダとしての最初で最大の説明相手が、じつは経営管理層なのである。そして、管理する側は、「プロジェクト計画とは、自分たちへの説明文書だ」と考える。ここが誤解の始まりだ。

とくに、実務内容を指導できない「管理者」は、計画の中でも、コストとリスクの項目しか、見ようとしない。だが実際にはコストは、プロセスの結果で決まる。プロセスとは、アクション（PM用語ではActivity）の連鎖である。アクションの連鎖が、品質とスケジュールを決め、結果としてコストが定まる。プロセスを支えるのは、人や設備などのリソースからなる「体制」である。

だから本当にコストを「管理」しかかったら、アクションを指導し体制を指示することが必要だ。だが、技術の中身が分からない管理者は、任命したリーダーの「資質」と、結果としてのコストだけしか口を出せる範囲がなくなる。あと、口を出せるのは、「リスク」であろう。

ただ、それは管理者としての、一種の責任逃れの本能から見たリスク評価になるケースが多い。プロジェクトのリスクの評価は、本当は、問題解決能力と表裏一体だ。自分がすぐに解決できる問題は、普通リスクとは言わないからだ。

結局、管理側が現場から遠く、その仕事の内容を良く理解できないまま、口だけだそうとするから、計画過剰になるのだ。それも、自分では計画を立案できない。現場側に計画を立てさせて、足りなそうな点を批評するだけだ。かくて、管理過剰に陥るのである。計画しすぎてダメにするのは、つまり管理しすぎてダメにすることの一部なのだ。

では、どうしたら良いか。

この問題の背景には、経営管理側と実行者側との認識のギャップがある。そこで、簡単ではないが、このギャップを埋めなければならない。そのためには、「プロジェクト・ガバナンス」の原則と、「スコープが固まるタイミング」について、両者がともに理解するべきである。

「ガバナンス」という言葉は一般に、「マネージャーをマネジメントする」意味で使われる。プロジェクト・ガバナンスとは、つまり、プロマネをどう経営層がマネージするか、いいかえると、どんな権限を委譲するか、に関する決め事である。

たとえば英国のPM標準「PRINCE2」が推奨するように、スケジュール・コスト・スコープ・リスクなどに関して、権限と許容度を設定しておく。たとえばプロジェクト・レベルでは1ヶ月以内まではプロマネの裁量とし、それ以上になる場合は、スポンサーやステアリング・コミッティに上申して裁可を仰ぐ、といった決まりを作る。このように、現場側にある程度の自由度を残し、かつ、野放図にならぬよう制限をつけるのだ。

もう一つの「スコープが固まるタイミング」については、とくに自発型プロジェクトで重要になる。というのも、研究開発・新事業開発・業務改革など、自発型プロジェクトの多くは、最初はかなり「ソフトな」スコープでプロジェクトが開始する。そして、ある程度検討が進んで、何をどうすべきかかなり明確になった段階で、はじめて、残りの仕事が「ハードな」スコープとして見えてくるのである。

この事情はIT開発プロジェクトも似ていて、初期の段階ではスコープは非常に柔らかい。それが、要件定義を完了すると、ようやく作るべきシステムの規模や機能詳細が見えてきて、コストやスケジュールを、精度よく予測できるようになるのである。

この事情を、わたしはよく魚の形にたとえる。初期の検討はまだ、魚の顔の鼻先をみているようなものだ。それが、基本設計や要件定義を進めると、しだいに目や口の位置が見えてくる。そして、エラの形まで分かるようになったら、あとはどれくらいの体が後ろについているかが、推定できるようになる。そうなれば、計数管理ができるようになる。

だから、経営層が詳細な（コスト的）計画を求めるタイミングは、魚の頭がかなり見えてくる時まで、待つべきなのである。

およそ、自発型プロジェクトの多くは、非常に柔らかなスコープからスタートする。その初期は、コストやスケジュールで管理するのではなく、プロジェクトの生み出す成果物の「前向き品質」（魅力品質）と、技術リスクの検討に集中すべきである。だから、初期のプロジェクト計画は、当面のアクションとリソースについてカバーする範囲で十分だ。

もし進捗を見たければ、数量ベースではなくマイルストーンで見ていく。あるいは、アジャイルのようにiterationベースで見ていく。この段階で使うコストは、どうせ知れている。だから遂行の効率性よりも、生み出す有用性を高める努力の方が、ずっと大切になる。

そして、ある程度進んだら、プロジェクトの中に、かなり固まったスコープの部分が見えてくる。そこではじめて、計数管理に基づくベースライン計画を作り直すのである。初期の段階でも、この段階でも、プロジェクト計画で使うステップは、共通している。だが、目的とフォーカスが違うのである。

計画は、必ず必要だ。だが、物事は決して計画通りに行かないからこそ、我々の対応能力を高めるために、計画づくりの作業が必要なのである。

＜関連エントリ＞

　→「成功するプロジェクト計画はこうして立てる」 (2021-07-07)

　→「PMBOK Guideに欠けている、３つの重要事項」 (2019-04-16)

お知らせ：「次世代スマート工場と製造業の活力再生」を日経研月報7月号に書きました

お知らせです。

日本政策投資銀行のグループ企業である、（一財）日本経済研究所の依頼で、機関誌「日経研月報」2021年7月号に、「次世代スマート工場と製造業の活力再生」という解説論文を書きました。

この機関誌は、原則として日本経済研究所の賛助会員に配布されるもので、読者層の多くは企業経営者や金融関係者、あるいは官庁自治体の政策立案部門の方と思われます。そこで、製造業の工場のあり方に詳しくない読者向けに、今、日本の工場の何が問題なのか、どうしていくべきかを、できる限り分かりやすく解説することにしました。

日本の製造業は世界一、と無条件に信じている人達は、非常に多いと思います。それは、むしろ製造現場から遠い層ほど、強い信憑を抱いているかも知れません。しかし、現実の課題と格闘している製造業の実務家の人達は、目に見えぬ壁のようなものに突き当たり、もがく気持ちをしばしば抱いています。

その壁を突き崩すには、製造現場から遠い経営者や金融・政策立案関係の人たちに、問題のアウトラインを理解してもらう事が必要です。その一助になればと思い、執筆しました。もちろん、わたしの勤務先の取り組みも少しは紹介しましたが、宣伝くささは抑えて書いたつもりです。

内容は、以下のような章立てになっています：

1 はじめに

2 このままでは二流になる日本の製造業

3 工場ぐるみの賢さを

4 スマート工場化への先進的取組事例

5 スマート工場化のロードマップ

6 工場づくりはアウトソーシングの時代へ

この機関誌は、Webでも会員向けに限定公開されていますが、おそらく本サイトの読者の多くは入手が難しいと思われます。そこで許諾を得て、PDF版を下記のUrlにて公開することにしました。

「次世代スマート工場と製造業の活力再生」佐藤知一、日経研月報 2021年7月号

https://mgt-technology.a2hosted.com/lib/exe/fetch.php/sato_2021__dbj_smartfactory.pdf

なお、もしも本記事を引用される場合は、「日経研月報 2021年7月号」からの引用であることを明記の上、著作権法の許す範囲で引用ください（・・つまり、全文をコピペしたり、図や写真を借用したりしちゃダメ、ってことです^^;）

よろしくお願いいたします。

佐藤知一@日揮ホールディングス（株）

成功するプロジェクト計画はこうして立てる

「あなたは、同期30人の集まるパーティの幹事になりました。

　あなたが最初にすべきことは何ですか？」

－－これはプロジェクト・マネジメントを人に教えるとき、わたしが必ず出すクイズの一つだ。実はその答えについて、以前このサイトで書いたことがあるのだが、もう9年も前の記事（笑）なので、覚えておられる読者も少ないだろう。そこで、あらためて考えてみていいただきたい。最初にすべきことは何か？

相手が学生の場合、「日程を決める」「店を探す」「参加者のリストを決める」等々、いろいろな答えが思いつく限り出てくる。もちろん、どれもそれなりに正しいように見える。でも、求めている答えはそれじゃないです、どんな種類のパーティやイベントの場合にもあてはまる、唯一の普遍的な正解があるのです、とわたしは続けて説明する。しかし、その『正解』が出てくることは、まずない。

一方、相手が企業人の場合は、ほしい答えを言い当ててくれる人が、ときどき、いる。わたしの求める答えとは、『計画を立てる』である。同期3人の飲み会なら、その場の勢いで決めて動ける場合もある。だが30人の参加するイベントとなったら、計画を立てずに進めることは、まず、できない。

イベント（という種類のプロジェクト）では、

　(1)計画を立てる、

　(2)準備をする、

　(3)当日のイベントを実行する、

　(4)終結する、

という大きな4つの段取りを、必ず経ることになる。その第一歩が「計画を立てる」ことなのは、ある意味、企業人から見たら当然だろう。だが、学生にとっては（たとえ東大の大学院生であっても）、「当然の常識」ではないのだ。

そしてここに、わたし達の文化の持つ、弱みが透けて見える。計画という仕事の位置づけが、社会の中で薄いのだ。わたし達の社会が、大規模な兵站（ロジスティクス）に弱いことは、今回のワクチン供給騒動でもあらわになった。その根本原因は、計画能力の弱さにある。だからこそ、わたしは拙著『世界を動かすプロジェクトマネジメントの教科書』で、大事な「チャレンジのOS」の3要素の一つとして、「かならず計画を立てる」を入れたのである。

それでは、計画とは、どうやって立てるのか？　成功する計画立案の技術があるとしたら、それはどのようなものか？

計画の技術について、大学で教わったという読者は、何人おられるだろうか。あるいは、小中高校で聞いた記憶がある、という方は？　まあ、たぶんどちらも、ほぼゼロであろう。じゃあ会社に入って、計画の技術について、教わったことはあるだろうか？

ある、という方は、それでもきっと少数派だ。だからこそ、当サイトのの存在意義があるのである。

計画を立てるとは、次のようなステップからなるプロセスである。

０ 何をなすべきかを明確にする。ゴールは何か。目的・目標は何か。そして制約条件は何か

　→Project Charterに、それを書く

１ それを実現するために必要なActivityをすべて洗い出し、構造化・リスト化する。重複も、洩れもないように

　→Activityリスト・WBSに、それをまとめる

2. それぞれのActivityを誰がやるべきかを考える

　→組織図・分担表で、それを定める

3. Activityの順序と必要な期間から、全体工期と着手・期限を決める

　→Logic network図とマスタスケジュールに、それを表す

4. 必要な期間・作業量から費用を見積り、収支を計画する

　→実行予算で、それを規定する

5. リスク・アセスメントを行い、計画全体を修正する

　→リスク登録簿に、それをまとめ、必要に応じて1〜4に戻って、計画を修正、完成する

個別のステップの説明よりも、なぜ、このような流れなのかを、ぜひ理解しよう。まず、最初はプロジェクトという活動の目的（Why）と、目標・制約を明らかにするところから、出発する。これを定めずに、お金や人の話をしても仕方がない。

では、なぜ次に、ビジネス界で一番重要な、お金の計画に進まないのか？　答えは簡単だ。具体的に何をやるかが決まっていなければ、コストを見積もりようがないからである。だからWhyの次は、何をやるべきか（What）、つまりアクションの洗い出しになる。それが見えてきたら、誰にやってもらうのがふさわしいか（Who）を考える。ここには、外注とか調達などの要素も入ってくる。

そして、誰が何をやるか、が見えてはじめて、スケジュール（When）について議論することができる。スケジュールが分かってはじめて、プロジェクトを構成する各種の活動Activityについて、費用を見積ることができるのだ。とくに人件費や場所・ツールといったリソースの費用は、期間に応じてコストがかかるのが通例だから、スケジュールが決まってはじめて、コスト計画が可能になるのである。

そして、誰が何をいつ、どうやって、どれだけの費用をかけてやるのかが明らかになって、はじめてリスク・アセスメントが意味を持つのである。その結果、何らかのリスク対策が必要になるかも知れない。つまり、計画の見直しとアップデートだ。ここで、計画立案作業に、多少のリワークが生じる可能性がある。だが、この作業を、もっと前の方のステップでやることは、できない（やっても意味がない）。それは失敗への道である。

PMBOK Guide(R)などで勉強した方は、ともすると、スコープ・コスト・スケジュール・品質・調達・コミュニケーション、などの領域を、お互いに対等で平等な関係だと誤解しがちである。だが、そんな事はないのだ。スコープ→人的リソース→スケジュール→コスト→リスク、という5大要素は、お互いの間に、明らかな順序的な依存関係がある。計画段階では、それを意識しなくてはならない。

ちなみに、最初のStep-0とStep-1の二つをあわせて、『スコープ定義』Scope definitionと呼ぶこともある。Charterができあがり、Activity ListとWBS辞書が作成された段階で、プロジェクト・スコープはかなり明確になる。つまり、やるべきことは明確になるのだ。仕事の地図が見えたと言ってもいいだろう。

その段階ではまだ、誰が、いつやるか、金はいくらかかるのか等、未定事項も多い。でもここが、プロジェクト計画策定プロセスの、前半の山場だとも言えるだろう。ようやく地図の全体像は見えた。目指すべき地点もはっきりしてきた。だがルートはまだ、ぼんやりしている。

ルートを明確にするのが、後半の作業だ。それは最終的には、お金とリスクの話に収束する。そして会社の経営者が一番気にするのも、この２つだ。だが、それを最初から考えることは、できない。地図もなく、ルートもわからないのに、切符代や旅行保険を議論できないのと同じだ。この順序で立てるから、実行可能な、つまり成功するプロジェクトの工程表と予算が出てくるのだ。

このアプローチのもう一つの特徴は、やるべき仕事（Activity）から、それを遂行する人や組織を考える点にある（上記のStep-2）。仕事を起点に、それに向いた組織を計画する。今すでに存在する組織と人を前提にして、仕事の仕方を考えるのではない。なぜなら、プロジェクトとはかならず初めての試みを含むものであり、それはしばしば、既存組織の境目やスキマに落ちるからである。

あるいは、計画づくりとは、建物のようなものだと考えることもできる。地盤の上に基礎（土台）があり、柱を立て、1階・2階と順に積み上げていく。コストとリスクは最上階だ。最上階から、先に作ることはできない。地盤に相当するのはProject Charterであり、基礎に相当するのがWBSだ。ここが不整形でヤワだと、その上にちゃんとした建物が建つはずがない。WBSはプロジェクト計画に共通する基礎なのである。

計画立案とは、ある意味、プロジェクトのモデリングを行う仕事である。モデルだから、一種の近似である。あまり細部までつっこむよりも、主要な点をうまく模倣できるかどうかが肝心だ。そしてモデルだから、あれをしたらどうなるか、ここを変えたらどうなるか、という検討のたたき台になる。

「ものごとは、計画通りには決して進まない。だが、計画は絶対に必要だ」との名言を残したのは、第2次世界大戦の連合国側の将校だった、アイゼンハワー元大統領である。彼は兵站（ロジスティックス）の重要性を、よくよく認識していた。大勢の人を動かす作戦は、出たとこ勝負では回せない。事前に頭の中で、シミュレーションが必要なのである。たとえ現実が予想から外れたとしても、頭を使ったことは無駄にならない。

わたし達の社会では、しばしばこの逆のパターンを見かける。最初に、ゴール地点の幸せなイメージがありるが、どういうルートをたどるとベストかの思考実験はない。かわりに、既存の人や組織に号令を下せば、あとはなんとか現場の頑張りで実現できるはずだ、という奇妙な楽観論があるだけだ。

そういうやり方も、今から半世紀以上前、前回の東京オリンピックのころまでは有効だったかも知れぬ。あの頃は、「突貫工事」という言葉が流行語になった。それはある意味、昭和的な単純思考の産物だが、社会もそれだけシンプルだった。21世紀の複雑系社会に生きるわたし達は、いきなり走り出す前に、もう少しだけ考える時間が必要なのである。

＜関連エントリ＞

　→「Structured Approachができる人、できない人」 (2012-07-08)

ネゴ（交渉）が苦手な人のために(2) 〜 解決策のビジョンを導く3 x 3の質問

交渉（ネゴ）は苦手だ、と悩む人は多い。しかし、わたし達が組織や社会で仕事をしている限り、上司や顧客・周囲の人などへ、自分の意見への合意や理解を求める場面は、数多い。自分のアイデアを理解してもらう事は、広い意味のセールス（売り込み）であり、交渉の一種である。そしてもちろん、相手の人達から、何らかの譲歩を取りつける必要だって、しばしばあるだろう。

わたしは大学や社会人相手に、プロジェクト・マネジメントの授業や研修を行うとき、できるだけ「交渉」に関するレクチャーを入れることにしている。プロジェクトを進める際には、必ず交渉の場面が出てくる。交渉能力は、プロマネの能力の重要な一部だ。だから拙著『世界を動かすプロジェクトマネジメントの教科書』 でも、交渉の練習をする場面を入れている。

だが、ネゴシエーションの技法や、交渉の戦略論を教えてくれる大学の授業は、滅多にない。だからたいていは、素人同然のまま社会に出てくる。先輩だってちゃんと教えてくれないし、実は教えるようなテクニックももっていなかったりする。仕方なく、見よう見まねで、ネゴに向かうことになる。これが海外相手のプロジェクトだと、向こうは交渉に百戦錬磨だったりするから、まあ結果はいうに及ばずである。

かといって、交渉の場面を避け続けると、どうなるか。自分がどんなに優れたアイデアを持っていても、その賛同者を得ることができないだろう。賛同者がいなければ、実現の可能性だっておぼつかない。まして、もっと具体的な交渉、たとえば追加費用の交渉などから逃げ続ければ、当然、赤字という結果に陥るだろう。

そうなれば、自分の評価・査定が下がってしまう。重要なポジションにつけなければ、面白い仕事にかかわるチャンスだって回ってこなくなる。そういう仕事にありつけるのは、陽気で押しの強い口達者な性格の奴だったり、あるいは生まれつき、他人や上司との交渉に長けた連中だったりする。能力や知識や技術でなく、持って生まれた「性格」が、チャンスを射止めるのだ。組織って、それでいいのだろうか？

それでいいじゃないか、とお思いの方は、この先の文章など読む必要はない。何せ、生まれつきで十分だという、ご意見である。いや、それではまずい、と考えられる方のみ、続きを読まれたい。交渉には方法論があり、ネゴの能力はトレーニング可能だ、という風に、わたしは考えるからだ。

そこでまず、基本的な理解からはじめよう。交渉（ネゴシエーション）とは、相手と共同で進める問題解決プロセスである。ここをまず、よく認識したい。

交渉とは、対決でも口喧嘩でもなく、「知的なレスリング」でもない。もちろん知的な相撲でもない（「知的な相撲」ってのがどんなものか、うまく想像できないが）。要するに、勝ち負けのかかった対立confrontationではない、という事だ。

ネゴは対決勝負だ、と考えるから、どうしても緊張感で、および腰になってしまう。でも、最初から逃げ腰では、よい交渉はできない。そうではなくて、これは相手側との共同作業だ、ととらえる。

相手と自分の間に、認識のギャップがある。越えるべき問題点がある。それを明らかにして、一緒にギャップを埋める解決法を探る。それが交渉なのだ。そう考えれば、ケンカが嫌いで平和主義のあなただって、まずは一緒にテーブルに座ろうかという気持ちになるだろう。

こちらが知っている事で、相手が理解していない事がある。その認識のギャップを埋めるためには、まず、相手のペイン（悩み）を推測し、把握する事からはじめるべきだ、と前回の記事で書いた。

ところで、顧客のニーズには、三段階がある。(1) 隠れたペイン → (2) ペイン → (3) 解決策のビジョン、の三つだ。そして、第1段階の『隠れたペイン』を、第2段階の『ペイン』に意識化して格上げするためには、「その悩みは解決可能である」という希望をもってもらうことが大事だ、と書いた。

次に、相手に、ペイン（問題）の解決は、「こうすればいい」とのビジョンをもってもらう。つまり、第2段階の『ペイン』を、第3段階の『解決策のビジョン』まで持って行く訳だ。そのビジョンには、自分が売りたいアイデア（ソリューション）が組み込まれている必要がある。

そのためには、どうしたらいいか。

前回紹介したボズワースは、３つのステップからなるプロセスを紹介している（『ソリューション・セリング』第2部）。それぞれのプロセスは、質問からなっている。プッシュ型の（押しつけがましい）相手への説明ではなく、プル型の（相手に主導権を持たせる）質問である点に留意されたい。

第1ステップ：「問題点の認識」（原因の特定）

ここでは、まず、相手がペインと意識した問題点について、相手の思考と説明をうながす。そして、その問題点の原因は何かをたずねて、特定する。

第2ステップ：「影響の認識」（組織の力関係とビジネスケース）

次に、そのペイン（問題点）が与える影響について、たずねる。質問の目的は、二つある。一つ目は、相手以外にも共通する悩みである事を、再認識してもらうと共に、そもそも一番解決を欲しているのは誰で、またその決定権を持つのは誰かを、探り当てる事だ。これは特に、社外の誰かと交渉するときに、重要だ。

そして二番目の目的は、影響を金銭的に評価してもらうこと。これにより、どれくらいの改善効果が見込め、逆にどれくらい問題解決に投資できるかを探る。会社では、何かのアイデアやソリューションを導入する場合、出費を正当化するために、投資対効果を求められることが多い。この投資対効果を説明したものを「ビジネスケース」ともいうが、影響に関する質問で、逆に相手が負担できる予算感を探れるのだ。

第3ステップ：「解決策の構築」（解決行動の所在）

ここでようやく、問題解決の方向性について、質問する。ただしまだ、自分が売り込みたいアイデアや商品の名前は、出さない。最初の質問で確認した問題原因を、こんな風に解決できたら、2番目の質問で聞いた影響まで抑え込めるかどうかを、たずねる。これが、相手の意識の中での「解決策のビジョン」になる。同時に、問題解決のための行動が、相手側にある事も、自覚してもらう。

ビジョンを構築できたら、ようやく、ソリューション名やアイデアの中核を説明できるタイミングになる。相手のビジョンが明確になるまでは、質問だけで、説明を急がない。これが大事なところだ。誰も、自分で考えたことでなければ、実行できないのだ。

これだけでは分かりにくいと思うので、例を挙げて説明しよう。あなたは今、新しいタイプの社内コミュニケーション・ツールを導入したい、と考えている。説得の相手は社内関係部門のマネージャー層だ。あなたはすでに会話を通じて、相手が現在のEメールに問題（ペイン）がある、と意識してもらうところまでは、こぎつけた。次は、上記の3ステップだ。

——そうすると、現在の、Eメール中心の連絡のやりとりは非効率だと感じておられるのですね。なぜ非効率なんでしょう？

「まず、保存期間の問題がある。それに、検索機能がいまいちだ。でも、一番の問題は、応答のスレッドが分かりにくい事じゃないかな」

——一応、スレッド表示の機能もありますが、たしかに自分もあまり使っていません。何が足りないんでしょうか。

「結局ね、社内連絡の目的は、通知か、依頼か、依頼への回答じゃないか。ところがEメールって、依頼したアクションがクローズされたのかどうか、一目で分からない。開封確認だけでは、相手がよんだかどうかも不確かだし。」

——確かにそうですね。つまり、今のEメールとスレッド表示機能だけでは、社内へのアクション依頼と回答のステータスが分かりにくい、と。それって、問題を引き起こしていますか？

「連絡の不徹底が生じる。たとえば、設計で何らかの変更が発生したとき、それを関連部門に通知するよね。ところが、変更のフォローがちゃんと完了したのかが見えない。うっかりすると、その古い情報のまま、下流部門やサプライヤーに指示が流れたりする。」

——なるほど。つまり、変更通知のトレーサビリティがとれない、ということですね。

「そのとおり。」（注：ここまでが第1ステップ）

——だとすると、依頼のステータスが分かりにくいことで、社内では他にも影響を受けている部門がありそうですね？

「当然だよ。設計部門だけじゃない。購買部門だってそうだし、営業だってそうだ。」

——範囲は広いですね。上の方、つまりマネージャー層はどうですか？

「誰が誰に何を頼んだかが分かりにくいから、部下のワークロードがつかみにくいのも問題だね。」

——それって結局、プロジェクトの混乱をまねきませんか。

「大いに招くね。知っての通り、ウチの某プロジェクトで、数千万単位の赤字を出したばかりで、事業部長がカンカンだ。あれだって結局、連絡の行き違いからトラブルに発展したっていわれている。」

——なるほど、コミュニケーションの行き違いの問題は深刻ですね。（ここまで第2ステップ）

　ところで、社内のオフィシャルな通知や依頼・回答などの連絡ができて、そのステータスが整理して表示されるような方法があったら、この問題は解決しますか？」

「するだろうね。でも、それは、今のメールシステムを改造するってこと？」

——パッケージソフトですから、勝手な機能改造はムリでしょう。Eメールとは別のツールが必要かも知れませんが、問題はあるでしょうか？

「保存や検索の制約さえなければ、それもありかもしれないな」

——保存期間に制限がなくて、かつ、ちゃんと全文検索がきくならOKということですか？

「そうだね。」

——そういうツールがあったら、そちらの部門で使っていただけますか？

「試すくらいなら、いいだろう。」（ここまでで第3ステップ）

ここまできで、はじめて、あなたは自分が導入したいと考えている新しいコミュニケーション・ツールの概要と、そのベネフィット、そして既存のEメールと比べたアドバンテージなどを説明できるのである。

なお、ボズワースは、各ステップで、相手をしずかに（押しつけがましくなく）誘導するために、三種類の質問形を使い分けろ、といっている。それは、

(1) 発想のためのOpen question: 「何でしょうか？」「どう思いますか？」といった、自由回答を求める質問

(2) 誘導のためのControl question: 「Aですか、Bですか？」のような、選択肢を限定した質問

(3) 確認のためのConfirmation: 「Aですね？」という、同意を求める質問

質問は、この順に、誘導的ないし強迫的になる。したがって、質問のエチケットとして、必ず、(1)→(2)→(3)の順に従え、という。

つまり、全体のプロセスは3ステップからなり、各ステップは3種類の質問から構成されるため、９つの質問で、相手と対話する事になる。ボズワースはこれを、縦横3 x 3の箱で表現して、「ナイン・ボックス法」とよんでいる。そして最初のうちは、手に持ったメモか、頭の中のイメージで、この9つのボックスを見ながら、会話を進める練習をすべきだとしている。非常に具体的、かつ実践的なアドバイスである。

読者諸賢も、交渉が上手になりたいとお考えだろうか？　苦手な理由は何だろうか。それは、メソッドを知らず、練習が足りないから、かもしれない。

そして、交渉が苦手であることの影響はあるだろうか？　もしかしたら、業績が上がらない、あるいは評価されない一因だと疑っておられるのでは？　それどころか、組織の成果にも影響が出て、利益を2-3割くらい損している、といったことは起きていないだろうか。

では、解決策は？　もちろん、自分が上手になるしかないはずだ（だって、部下にやらせたら、上司たる自分の立場が弱くなるのが、会社組織だから）。そのためには、交渉（ネゴ）の具体的なメソッドを学ぶべきではないだろうか。

前回の記事でも書いたとおり、わたしの先輩であるKさんは、ここで説明した技法を学び、実践を通して練習し、そしてセールスにおける一流の能力を身につけていった。繰り返し書くが、Kさんは高学歴の技術者である。だが、ゼロから交渉を学ぶ必要があると考え、それを実行したのだ。

この際はっきり言うけれども、日本では、高学歴の人は知識は豊富でも、交渉はむしろ下手なことが多い。交渉なんかしなくても、社会が優遇してくれたからである。そういう人達が産業界をリードしてきたから、わたし達の社会は今、こんなていたらくなのではないか。

コロナ後の社会はむしろ、知識ばかり豊富な高学歴な人よりも、自分の頭で「考える人」が逆転し、有利になれる世の中になるだろう。そうあってほしいと願っている。交渉（ネゴ）とは、すなわちリーダーシップの発揮である。リーダーシップとは、自分が命令できない相手を動かす力だからである。

＜関連エントリ＞

　 (2021-06-19)