プロジェクトの「補助線」

【補助線】計画論～３種類の計画

本ブログは移転しました。こちらをご覧ください。

◆３種類の計画

業務の計画は組織によって、名称や、段階など、さまざまであるので、一般論を論じることは難しいが、計画の本質的な役割を見ると、おおよそ、以下の３つに集約できると思われる。

・構想計画
・基本計画
・実施計画

の３つである。

【補助線】目的と手段

本ブログは移転しました。こちらをご覧ください。

◆目的と手段を混同してはならない

プロジェクトの企画にしろ、戦略策定にしろ、目的と手段を混乱してはならないという話は、昔から、よく言われる話である。

たとえば、野球の投手。何とかバッターを抑えたいと思って、早い球を投げれるようになりたいと思った。とりあえず、１５５Ｋｍの球を投げれるようになろうと決める。早い球を投げることに熱中するあまり、いつのまにか、１５５Ｋｍの球を投げることが目的になってしまい、本来の目的であるバッターを抑えるというのは忘れてしまっている。

イメージとしてはこんな話だ。

プロジェクトでもこの種の話をよく聞く。本来、目的があって、スコープが決まるのだが、「とりあえず」スコープが決まっているケースがよくある。つまり、目的が曖昧なままでスコープを決めている。

すると何が起こるかというと、スコープを忠実に実現することが目的になってしまう。

プロジェクト目的の秘密（全３回）～その１ 目的と目標について理解しよう

本ブログは移転しました。こちらをご覧ください。

◆はじめに

プロジェクトマネジメントの研修や、ワークショップで、「このプロジェクトの目的を設定しましょう」というと、必ず出てくる答えがある。

（例１）顧客の要求を満たす○○システムを作る
（例２）収益を増加させる

このような目的はほとんどの場合、あまり適切な目的だとはいえない。第１回の目的は、なぜ、これらの例がなぜ適切でないのかを理解していただくことである。

また、第２講「プロジェクトの目的・目標の秘密」（全３回）を通しての「目的」は、どのように考えて「プロジェクトの目的や目標」を設定すれば適切な目的の設定ができるかだ。

【補助線】プロジェクトを「作業」から「仕事」に

本ブログは移転しました。こちらをご覧ください。

◆仕事と作業の違いは？

いきなりで恐縮だが、ＰＭＰ（Ｒ）の方に質問。work、task、activity　の違いが説明できますか？

山﨑裕司さんという方が書かれた本に「日本語で書いた経営の教科書」という本がある。経営者やマネジャーにとっては示唆に富むたいへんよい本だ。

この本の中に、「仕事」と「作業」はどのように違うのかが明確に書いてある。それによると、

作業：定められたことをすること
仕事：目的に対して、効率的に貢献をするように作業を定め、割り当てること

だという。

【補助線】ポジティブでいこう

本ブログは移転しました。こちらをご覧ください。

◆ネガティブを裏返すとポジティブ

「ポジティブな感情を持とう」、「前向きに考えよう」とかいうと精神論みたいだが、意外とそうでもない。この議論、プロジェクトマネジメントの中で、「視点」を変えるのに意外と効果がある。ポジティブ心理学の本を何冊か読んで、いくつか気がついたことがあるので、ときどき、書きたい。

自分たちにとってよくないことを、ポジティブに捉えてみるというのは、場合によっては相手の立場でものごとを考えることに通じる。「ポジティブ心理学の祖父」と言われ、「ストレングス・ファインダー」という自分の強みを評価するシステムの発明者であるドナルド・クリフトンという人がいる。このシステムは世界中で１００万人以上の人に使われているらしいが、日本ではあまり、噂を聞かない。むしろ、マーカス・バッキンガムと一緒に書いた「さあ、才能(じぶん)に目覚めよう―あなたの5つの強みを見出し、活かす」という本の方がよく知られているかもしれない。この本も、ポジティブ心理学の本であるが、彼が、ポジティブに考えるためには、「相手の身になって考える」ことが必要だといっているのはまさしく表裏一体だといえる。

たとえば、多くのプロジェクトマネジャーが忌み嫌う顧客の「要求変更」という問題がある。確かに、途中で顧客の要求が変わると言うのは極めて面倒だ。いくつかの作業が無駄になってしまうだろう。

これは、プロジェクト側の立場での話。これをポジティブに捉えるとどうか？この変更によって、それまで決まっていなかったことが決まったのかもしれないし、不適切だったものが適切になったのかもしれない。いずれにしても一歩前進である。

実際に顧客にしてみればそうだ。

前提条件の秘密（全３回）～その１ プロジェクトの前提条件とは何か

本ブログは移転しました。こちらをご覧ください。

◆前提条件はプロジェクトの臍

プロジェクトでは、予算や納期といった制約条件ばかりが注目されるが、ある意味で制約条件以上に重要なのは、「前提条件」である。前提条件をあいまいなままにしていて、失敗するプロジェクトは少なくない。

逆にいえば、プロジェクトマネジメントとは、前提条件を設定できないことで発生する問題を解決するための手段だと言ってもよい。たとえば、

・すべての人は放っておいても自発的に報告をする

という前提条件を設定してもよいし、

・メンバーはリスクを察知し、リスク回避行動を取る

という前提条件を設定しても一向にかまわない。しかし、現実にはそんな前提条件は多くの組織では非現実的であるので前提とはせず、その代わりにマネジメントでその前提が成り立たない場合の対処をする。マネジメントとは理想的な前提条件を獲得するための活動であり、プロジェクトマネジメントの組織習熟度はマネジメントを不要にする前提条件の多さを表す指標に他ならない。

ここで、改めて前提条件を定義しておこう。

前提条件とは、そのプロジェクトを実施する上での「仮定」である。上に述べたように、仮定がまったくなくなることはあり得ないし、かといって、非現実的な仮定をしても意味がない。

たとえば、「プロジェクトメンバーはプロジェクトの利益を考えて行動する」という前提がある。この前提の上に生産性、コミュニケーション計画、リスク計画などの計画をしてプロジェクトを進め、前提が間違っていて失敗したプロジェクトは多い。この例を一つとってみて、前提条件の大切さ・微妙さが分かるというものだ。

前提条件は、些細なことだが、プロジェクトに大きな影響を与える、いわばプロジェクトの臍のようなものである。

【補助線】プロジェクトの神とレバレッジ

本ブログは移転しました。こちらをご覧ください。

◆Der liebe Gott steckt im Detail

神は細部に宿る（Der liebe Gott steckt im Detail）という言葉がある。誰の言葉か不明だが、ドイツの建築家L. M van der Roheが世の中に広めたというのが定説になっている。

もともと、建築について言及した言葉だが、いろいろな使われ方をしている。問題は意味（解釈）だが、これまた、さまざま。細部の細かなところまでこだわるといった使い方をしているケースもあるし、逆に、細部が全体に統合されなくてはならないという意味に解釈している人もいる。結局のところ、この２つは同じことなのかもしれない（であるべきということ）。

新型インフルエンザに学ぶリスクマネジメント

本ブログは移転しました。こちらをご覧ください。

◆「世間さま」というモラル感とリスクマネジメント

岡本薫さんという方が、

岡本 薫『世間さまが許さない!―「日本的モラリズム」対「自由と民主主義」』、筑摩書房（2009）
http://people.weblogs.jp/books/2009/05/post-9761.html

の中で、日本人にはルールに勝る「世間さま」というモラリズムがあるという指摘をされ、その事例の一つとして、リスクマネジメントの欠如について書かれている。

いわく、日本人には「縁起でもないことを言わない」というモラル感があり、このモラル感がリスクを考えずに行動するという行動規範を生み出しているというのだ。

しかし、内部統制の強化、プロジェクトマネジメントの導入などにより、このようなモラル感は薄れ、リスクを考えながら行動することこそ望ましいというモラル感が生まれてきた。

と思いたいところだが、どうも、そうことは簡単ではない。リスクマネジメントの導入をしている企業を５０社くらいは知っていると思うが、共通的にいえることは、事前のリスク回避を目指していることだ。実はこれがくせ者だ。

【補助線】チームを前提にしたプロジェクトマネジメント

本ブログは移転しました。こちらをご覧ください。

◆なぜ、商社が成り立つのか

ＰＨＰから発行されている雑誌「Voice」から、雇用問題をテーマに記事を選んで一冊の本が発行された。

「クビ切り不要！」

という本だ。

この中に、伊藤忠商事会長の丹羽宇一郎氏と東京理科大学教授の伊丹敬之先生の対談記事が採録されている。「人を大切にする経営」という記事。伊丹先生は一橋大学の時代から、人本経営を説かれている方である。

この記事がたいへん、おもしろい。この中に、総合商社に関する伊丹先生のこんな発言がある。

商社という組織の経営がなぜ成り立つかというと、まさにチーム力があるからです。アメリカ型の「あなたの役割はこれ」と、仕事を分解していくようなやり方では、とてもできません。それこそ、人のつながりを大事にして、安定的にやっていくからこそ、組織全体が発展する。これは商社に限らず、製造業も銀行も皆一緒でしょう。
（同書、22p）

これに対して、丹羽氏が答える。

じつは伊藤忠商事で昔、日本の商社と同じものをアメリカにつくってほしいと頼まれ、人を派遣したことがあります。ところが絶対に成功しない。彼らは個人主義ですから、隣の人と同じチームでやれといってもどうもうまくいかない（同書、22p）

なるほどと思った。

総合商社は、日本が世界に誇るビジネスモデルである。このやりとりを読んで、ずっと昔から、もやもやしていた２つの疑問が氷解したような気がした。

【システム講座ミニ講座第１回】プロジェクトレバレッジを見つけて、効率的にプロマネを行う！

本ブログは移転しました。こちらをご覧ください。

スケジュールが遅れている

この問題に対するもっとも表層的な解決方法は、「要員を投入し、遅れを挽回すること」である。しかし、経験的にそれでは問題解決にならず、「真の原因」を考えなくてはだめだと言われるようになっている。いわゆる問題解決である。

「真の原因」といういう言葉はなんとなく説得力のある言葉で、かつ、ＷＨＹを５回繰り返せといった経験的な手法があわせられているので、多くの人がそうだ！と思っている。

では、なぜ、５回なのか？真の原因とそうでない原因はどこにあるのか？

と改めて尋ねられるとどうだろうか？

多くの人は、「あれ」と思うのではないか？実は、これは相当難しい話だ。

ソフトウエア開発では、フレデリック・ブルックスが

「人月の神話 狼人間を撃つ銀の弾はない」

でもっとも有名な法則として

「その2：遅延プロジェクトに人員を投入すると、さらに遅れる」

という法則をご存じの方も多いと思うが、なぜかと言われると、この本を読んでいない人が説明できる人は多くないだろう。おそらく、５回のＷＨＹを繰り返してもこの答えは見つからない。

では、真の原因に到達するにはどうすればよいか？

問題の構造をみて判断することである。たとえば、５回ＷＨＹを繰り返し、

スケジュールが遅れている
　←アクティビティにおいて、見積もり工数以上の工数がかかっている
　　←作業担当者の生産性が低い
　　　←残業が続いており、作業担当者の疲労がひどい
　　　　←作業担当者のスキルが低い

となったときに、根本的な問題は「作業担当者のスキルが低い」ことなのだが、プロジェクトの中で注目したい問題は、実はこの問題ではないことが多い。むしろ、その前段の「残業が続いており、作業担当者の疲労がひどい」である。

つまり、真の原因というのは根本的な原因ではなく、その問題を引き起こしている「本質的な問題」であり、これは、問題の構造を考えなくてはわからない。

上の例だと、確かに、

スキルが低いので残業が多い

という因果関係はあるのだが、それ以上に、全体構造を見ると

疲労で下がる生産性とスキル不足で下がる生産性を比べると、疲労の方が大きい

という関係が強い。従って、本質的な問題は「残業が続いており、作業担当者の疲労がひどい」ということができる。

言い換えると、本質的な問題とは、その問題を解決することによって、画期的に状況が変わるような問題であるといえる。最近のはやり言葉でいえば、「レバレッジ」と呼ばれるものである。

このレバレッジをうまく探して、適切な対応をしていくための方法として「システム思考」がある。

今回から、短期連載として、「システム思考ミニ講座」をお届けする。