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

僕の好きな倉科遼氏の書いたコミックスで、夜王というコミックスがある。テレビドラマでもやっていたが、新宿歌舞伎町を舞台に一人のホストの成長を描いた物語だ。

倉科遼「夜王」

このコミックスを読んで、ホストの行動規範、思考規範に興味を持った。

二つ三つ考えてみてほしい。

（１）あなたは顧客の満足を得るのにホストのような行動ができるか

（２）あなたは派閥の長として、ホストのリーダーのようにチームのパフォーマンスをあげるがことができるか

（３）あなたは組織をまとめ、組織を拡大にするためにホストクラブの店長のような行動ができるか

（１）。何でもお客の言いなりになるホストに顧客満足は生まれない。顧客をコントロールし、自分のイニシャティブの中に引き込んで、そこで素晴らしいサービスを提供して、初めて、顧客の満足は生まれる。これ、ビジネスでもまったく一緒。

（２）。チームのメンバーのココロを掌握ができないホストに、顧客を満足するサービスは提供できない。自分のロジックではなく、相手のロジックの中で、何を支援すれば相手のパフォーマンスが上がるかを考える。これ、チームマネジメントの基本中の基本。自分のロジックの中で一生懸命どうすれば相手が動きやすいかを考えてもパフォーマンスはあがらない。

（３）。リスクがあることを察知し、しかし、あきらめない。如何にそのリスクを小さくするを全知全能を絞って考える。リスクが見えた時点で、君子危きに近寄らずこそがリスクマネジメントだといっていたのでは、組織としての成功はない。

これらはまさしく、プロジェクトやプログラムのマネジメントのコアな部分である。

◆ＩＴにおけるプログラムマネジメントの適用事例

最近は企業統合が珍しくなくなっている。この際、たいてい問題になるのが、情報システムの統合である。例えば、東京三菱とＵＦＪの経営統合ではまさに、情報システムの統合スケジュールが問題になり、監督官庁も絡んで経営統合のスケジュールそのものが二転三転したのは記憶に新しい。

この例からも分かるように、規模の大きなプロジェクトの情報システムを統合しようとすれば、数十の情報システムを統合しなくてはならないことは珍しくない。このようなときに、これを一つのプロジェクトとして行うと２～３年では到底完了しないだろう。それゆえに、このようなプロジェクトでは、全体をプログラムとして管理し、プログラムマネジメントを実施するのが当たり前になっている。

◆リードタイムの短縮を実現するプログラムマネジメント

このような話は、決して、経営統合の際の情報システムに限ったことではない。ライフサイクルがどんどん短くなっている最近のビジネスでは、工法やプロセスの工夫では思ったようなリードタイムの短縮ができず、課題をプログラムとして捉え、並列的に実行することにより、リードタイムの短縮を図ることは珍しくなくなってきた。

製品開発の世界では、従来よりコンカレントエンジニアリングという手法でリードタイムの短縮を図ってきた。コンカレントエンジニアリングは企画・開発から販売・廃棄にいたる製品ライフサイクルの全フェイズに関連する部門が、製品の企画や開発、設計などの段階に参加・協働し、同時にプロセスを進めていく開発手法である。これもある製品を開発するという一つのプロジェクトであるが、プログラムとして扱い、マネジメントを行っている。

◆プログラムマネジメントと分散マネジメント

企業の戦略があって、その戦略を実行するためにどのような課題があるかが決まる（戦略課題）。この戦略課題を実際のアクションに落とすものがプログラムであり、プロジェクトのコントロールの対象は戦略に対するベネフィットになる。そして、ベネフィットを最適化するために、複数のプロジェクトをデザインし、実行していく。

これが、Ｐ２Ｍなどで言われているプログラムのイメージであるが、プログラムはこのような形だけではなく、上のような形態が増えている。一方で、プログラムにすればスムーズに進むプロジェクトを強引にプロジェクトとして実行しようとして失敗している事例も目立つ。

ＳＩプロジェクトでは何らかの形で並列開発をすることが多くなっているが、これをプロジェクトをみなして開発すると必ずといってよいくらい失敗している。スケジュール的に無理があり、タイムマネジメント、リソースマネジメントが破綻をきたしている。このようなケースはプログラムとしてマネジメントしていかないとうまく行かない。

その意味で、プログラムマネジメントはプロジェクトマネジャーにとっても現実的で重なマネジメント手法になってきている。大規模、納期の厳しいプロジェクトをマネジメントしなくてはならないプロジェクトマネジャーにとっては必須スキルだといってもよいだろう。

それだけではない。プログラムマネジメントはプロジェクトの分散型マネジメントという非常に興味深い枠組みも提供する。これについては次回！

pmstyleでは、研修に必要な条件として

【条件１】経験を意味づけ、経験に弾みをつける

【条件２】研修をスタンドアロンで完結させず、プロジェクトマネージャーとしてのアサインに連動させる

【条件３】研修をトップマター（事業部）だと認識する

の３つを掲げ、これに基づいて研修をデザインしている。

条件２は制度上実現困難な企業が多いが、残りの２つの条件はやろうと思えばできる。特に、条件１は重要だ。

経験が重要だというのは多くの人が言うが、経験はしっぱなしでは意味がない。難しい言葉でいえば概念化ができて初めて経験の意味があるし、学習につながる。例えば、失敗したときになぜ失敗したのか、うまく行ったときになぜうまく行ったのかをきちんと分析し、概念化をする。これはレッスンズラーンドの一つであるが、ここで、単にノウハウとして蓄積するだけではなく、理論との結び付けをすることが重要である。プロジェクトマネジャーに対する研修ではこれが最も重要な事項であろう。

それができて初めて、応用力のあるノウハウになるし、また、次の新たな経験につながる。例えば、自分なりに行っている進捗管理が実はＥＶと同じ原理で行っているというのはよく見かける現象である。

その際に、自分のやり方がＥＶと結びつけばＥＶの世界で発見されていること（手法）やノウハウを纏めて使うことができるようになる。そして、それらの手法を自分のやり方に加えることによってさらに、自分のやり方が幅を持つようになる。これが経験を意味づけ、さらに、経験に弾みをつけることだ。

ちなみに上のような条件を考えた弊社のトレーニングはキャリア段階にあわせ、以下の４段階としている。

【ステップ１】
プロジェクトマネジメントの基礎知識を身に付ける

【ステップ２】
プロジェクトマネージャーとしての行動規範を身につける（PMコンピテンシーの獲得）

【ステップ３】
業務の中で遭遇した問題に立ち返り、経験を分析し、必要な知識を補給する

【ステップ４】
業務経験を振り返り、自分のプロジェクトマネージャーとしての特性を知り、自分のスタイルを作っていく

ステップ３、ステップ４の段階においては上に述べたような経験の意味づけと、弾み付けができて初めて研修としての意味が持つことを忘れてはならない。しかし、この指摘をすると、多くの人は、そんな理論を持ち出さなくても分かっているし、できているという態度を取る。もう少し、謙虚にありたいものだ。

ＷＥＤＧＥの９月号に製造業の品質問題の記事が掲載されている。

「電子化偏重・人間軽視」開発現場から崩れる製造業

という記事だ。なかなか、興味深い記事なので、機会があれば目を通して見られるとよいだろう。

この中に、プロジェクトマネジメントの立場からは気になる指摘が書かれている。

トヨタでは、この１年くらい、過去に市場に送り出した商品の品質問題に頭を痛めている。マスコミでも何度も取り上げられているように信じられないようなリコールが多発しているのだ。それを受けて、品質担当の副社長を１名増やして２名にし、さらには担当専務まで設置したが、それでも思ったような効果がでない。なぜか？

これがこの記事の問題提起である。その上で効率とコストを追求するために起こっている「開発プロジェクトでのコミュニケーション不足」があると指摘している。これはトヨタに限らない。僕のコンサルティングをしたプロジェクトでもこの問題はよく直面する。

この種の問題は極めてやっかいである。プロジェクトスコープの中に現れてきにくいからだ。自動化された設計上の問題はない。品質基準も満たしている。そのような中でも、設計者同士が議論をしていると気づく問題も多い。しかし、効率追求・コスト優先の中ではその時間がままならない。

この問題は今に始まったことではない。僕が三菱重工で仕事をしていた頃に、ＣＡＥのシステムの自動設計の開発に携わっていたことがある。このときに多くの設計エンジニアにインタビューしたことがあるが、多くの人はこの問題を指摘していた。僕流に言えば次のようなことを言っていたように思う。「設計というのは形式化できない。ナレッジベースを作っても無理。コラボレーションの中で生まれてくる部分が多い」

さて、この問題、トヨタも気づいていなかったわけでも、手をこまねいていたわけではない。記事によると、早くから問題の所在に気がつき、手を打ってきた。２００３年くらいから、開発段階における設計、生産、調達の横断的なすりあわせを強化してきたという。タラレバになるか、だから、この程度で済んでいるともいえよう。

この問題、プロジェクトマネジメント的にはどうすればよいのだろうか？

難しいのはコストと時間の制約が極めて大きいために起こっている問題で、コミュニケーションマネジメントをきちんとすればよいといった単純な問題ではない。かといって、いまさら、リードタイムや製品原価を緩くする方向に向かうというのはできない相談だろう。

このような状況で唯一の解になりうるのは、今まで真剣に考えてこなかったチームマネジメントではないかと思う。ただし、自動車メーカは製品アーキテクチャーから組織を作りこんでいるので、チームマネジメントを何とかしようといってもそう簡単にはいかないだろう。そこは悩ましい点だ。

一方で、他の業界ではこの矛盾に満ちた問題を解消できるようなチームマネジメントは比較的容易に実現できるように思うのだが、如何だろうか。

実は、この問題、マスプロダクションだけに限った話ではなく、受注生産製品でも起こっている。その典型がＳＩプロジェクトである。ＳＩプロジェクトでは、顧客コミュニケーションの悪さは目に見える形で品質の問題として出てくる。しかし、システム内部の不適合はそう簡単には出てこない。そこで、要件定義や設計時のプロセスマネジメントで品質の作りこみを行うのだが、短納期化やエンジニアのスキルの問題などでコミュニケーションの品質が落ちてきて、それが製品の品質問題になっているケースが増えている。

ＳＩの場合であれば、チームマネジメントを丁寧に行うことで、納期と品質のコンフリクトという問題は解消できる。

日本の現場の強さは、コミュニケーションの強さであるし、上流工程のさまざまな問題のバッファになってきた。実際に「現場あわせ」という言葉が象徴するように、上流工程のコミュニケーション不足を現場のコミュニケーションで解消してきた。

それができなくなってきたのだとすれば、ある意味で転機だといえる。製品開発プロセスにプロジェクトマネジメントを導入し、コミュニケーションマネジメント、リスクマネジメントなどをチームマネジメントで統合していくようなマネジメントが求められるようになってきたといえる。

自民党の総裁選挙が近づいてきて、マスコミがこぞって特集番組を放映し始めた。小泉という首相は非常に面白いことを見せてくれた。それは、議員内閣制でもここまでできるという限界である（本当に限界か、まだできるか、常識的限界を超えて属人的に許される限界かは分からない。おそらく次の首相が方向を決定付けることになるのだろう）。

なぜ、こんな話題を持ち出したかというと、これまでずっと述べてきた組織によるプロジェクトマネジメントのイメージは、ある意味で議員内閣制に似ているからだ。プロジェクトマネジャーは首相である。プロジェクトチームは内閣。スポンサーは与党。ステークホルダは野党や国民。

小泉以前の内閣は少なくともこのフォーメーションであった。ところが、小泉はこのフォーメーションをひっくり返した（と表面的には見える）。世論の支持を背景に、カリスマリーダーのごとく行動した。彼の行動がよいか悪いかはまだしばらく答えがでないと思うが、少なくとも、今までの首相ではフォーメーションをひっくり返すことにより今まではできなかったことをやってのけた。

プロジェクトマネジャーにはあまり権限がないと思っている人が多い。内閣総理大臣もそうだった。しかし、やればこれだけできた。問題はやり方と意志である。

大志あるプロジェクトマネジャーは小泉的を目指せ！

岡野工業の社長（正確には代表社員）である岡野雅行さんが新しい本を書かれた。

岡野 雅行「世界一の職人が教える仕事がおもしろくなる発想法―結果が出ない人はいない」、青春出版社（2006）

岡野さんは今までに４～５冊出版されているが、どの本を読んでも元気付けられる。特に今回の本は、岡野さんの仕事の仕方、考え方のエッセンスを抽出されているので、非常に啓蒙的内容が濃い本だ。

岡野さんの仕事のモットーはこの本にあるとおり、誰も無理だ、できないという仕事をやるのが最高に楽しい、アドリブで仕事をするからこそ楽しいなど、「技術屋」が聞くと涙を流しそうなものばかりだ。

岡野さんは僕の尊敬する経営者の一人だ。大企業に勤める「サラリーマン」と岡野さんの話をすると、決まって返ってくる答えが、社長だからできるとか、中小企業だからできるである。

こんな話は自分が岡野さんの立場になった想像をしてみて１０秒考えれば間違いだと分かる。要するに、違う点を言い訳にしたいだけに過ぎない。岡野さんと彼らの違いは、岡野さんややる方法を考えるが、そのような言い方をする人はやらない言い訳を考える。言い尽くされた話だが、まさにそのもの。

まあ、それは人生観も折込の話になるので、どうでもよい。生涯サラリーマンの人はその人なりの価値観があるだろう。

ただ、考えてほしいことは、顧客や上司から「無理難題」を吹っかけられることは中小企業であろうと、大企業であろうとある。何にしても顧客はエライのだ。

例えば、痛くない注射針を作ってほしいというのに匹敵するような、あるいはそれ以上の無理難題な要件を言われたことのあるＳＩプロジェクトのプロジェクトマネジャーは少なくないと思う。

このときに、「あ～、だから何もわかっていない顧客とはやってられない。営業を巻き込んでから断るか」と考える人と、「お～！、面白い、なんとかしてやろうじゃないか」と考えれられる人では、しんどい目をするのは、間違いなく前者である。

サラリーマンをやっている人に、トム・ピーターズや岡野さんのように、あえて積極的にリスクをとって面白いプロジェクトを作ろうと呼びかけるつもりはない。しかし、おかれた境遇から逃げれないのもまたサラリーマンだ。まさか、公務員のように不作為というわけには行かないだろう。

であれば、そんな人こそ、岡野さんのような考え方をできるようになってほしいなと思う。プロアクティブなプロジェクトマネジメントはそこから始まる。

プロジェクトマネジャーの人にこの本は読んでほしいな。

「失敗学会」の副会長を勤められている飯野謙治さんが最近ソフトバンク新書から

「失敗をゼロにする」のウソ

という本を出 された。大変、よい本だと思うので、ぜひ、読んでほしいのだが、この本のまえがきに、「失敗学」を活用するためのポイントを３つ書いている。

三つ目は

　「失敗を繰り返さないための仕組みづくり」

という失敗学のメインストリームの主張なのだが、その前の２つが非常に興味深い。

一つ目は

「人は失敗をやらかすもの」だと意識すること

だという。そして、二つ目は

「失敗を隠そうとするのは自然の心理」だと素直に認めること

だという。この２つが組織の風土となって、最初に書いた三番目の仕組みづくりが可能になるという指摘をしている。

リスクマネジメントというのは、この

「失敗を繰り返さないための仕組みづくり」

に他ならない。リスクマネジメントの効果が出ないのは、飯野謙治さんが指摘する２つの風土に問題がある。

多くの企業、特に、大手企業でプロジェクトリスクマネジメントのコンサルティングをしているときにこれをひしひしと感じる。つまり、

　自分たちは失敗はしない

という思い。この背景には当然、組織として失敗は許されないという風土がある。この意識がある限り、リスクマネジメントはできない。問題はあってもよいのだが、その問題によって失敗をすることは１００％ないと考える。リスクというのはその問題における失敗行動を取る可能性であるので、当然、失敗しないという前提であれば、リスクはないことになる。

このように考えると、基本的にはプロジェクトを開始する前にすべてのリスクを回避できていなくてはならないということになる。これは、プロジェクトマネジャーと上司の間、また、プロジェクトメンバーとプロジェクトマネジャーの間の両方に言えることである。

ただ、プロジェクトであるのでデッドラインがある。そのため、事前にすべてのリスクを回避できないことがある。このような場合には、その問題は確実に解決できるという仮定の上にプロジェクトを進めることになる。「よきに計らえ」である。当然、失敗するとは思っていないので、その対応で問題が生じると責任問題になる。

この問題と関係するのが二番目である。失敗はないという前提であるが、当然、人間であるので失敗することもある。そこで、失敗した場合には隠すことになる。

リスクマネジメントの枠組みでいえば、リスクモニタリングを公正に行わないことになる。仮に、リスク識別をしていても、そのリスクは発生していないという報告をすることになるのだ。

リスクマネジメントを効果的に行うためには、失敗を隠すことが自然だという認識が重要だ。これはプロジェクトメンバーを信じるとか信じないという視点で捉えてはならない。隠すことは自然なことであり、特定のメンバーの固有の問題ではないと考える。そのような前提でリスクモニタリングをしていく必要がある。

プロジェクトマネジャーがプロジェクトリスクマネジメントを行う際には、一番目のポイントの

「人は失敗をやらかすもの」だと意識すること

を徹底的に意識付けする必要がある。このためには、原理を重視する。正しいことと正しくないことを明確にするのだ。それをしないと失敗を失敗だと認めない（リスクの発生を無視した）ままで前に進んでしまう危険がある。

これがクリアできれば、隠す必要性が小さくなる。つまり、リスクへの早期の対応が可能になる。そのとき初めてリスク対策が意味を持ってくる。

そんなプロジェクト組織の作り方を議論するセミナーを開発した。

リスクに強いプロジェクトと組織を作る（リンクあり）

ＰＭコンピテンシーの仕事をしているうちに、だんだん、プロジェクトマネジャーに足らないと思われるものがはっきりしてきた。

　コアマネジメントスキル

である。

プロジェクトマネジメントというのはどちらかといえば、テクニカルな色彩の濃いマネジメントである。ＰＭＢＯＫはその象徴でもあるが、「ツール」や「技法」に依存する割合が多い。

確かに、建設の仕事だとかを考えてみると、このようなマネジメントは必要なのだと思う。延べ人数で数万～数十万人の人を動かして一つの目標を達成する。このような仕事では今のようなプロジェクトマネジメントの枠組みは不可欠だろう。

一方で、今、盛んにコミュニケーションやネゴシエーションといったヒューマンスキルが注目されるようになってきている。これらに注目が集まる理由をよくよく聞いていると、マネジメントスキルの欠如をヒューマンスキルでカバーしようとしているようだ。正しいかどうかは別にして、この感覚はちょっと違う。

家を建てることに例えてみると、以下のような比喩ができる。

　基礎：コアマネジメントスキル

　デザイン（機能性）：プロジェクトマネジメントスキル

　デザイン（快適性）：ヒューマンマネジメントスキル

今、行われていることは、基礎工事が悪くて、ドアの立て付けが悪くなったときに、ドア枠をフレックスな構造にしておくことにより隙間風が入らないようにする仕掛けを作っているようなものだ。要するに、「ギミック」なのだ。

もっといえば、コアなマネジメントスキルを持たない人材がもつプロジェクトマネジメントスキルというのもギミックだという気もしなくもない。これは少し言いすぎかな、、、

「ギミック」が悪いどうかは別問題だ。

組織としての評価のポイントは２つある。一つは、その家にどれだけ住み続けるかだ。仮住まいで１０年ほど住んだら取り壊してしまうのであれば、それも一つの選択だ。

その際のもう一つのポイントは、コスト。基礎をしっかりするのと、このような「ギミック」を施すためのコストを比較し、「ギミック」の方が安いとすればそれでもいいのかもしれない。

個人のとして評価は言うまでもない。その会社が潰れても生きていかなくてはならない。基礎が大切だ。基礎がしっかりとしていれば、「ギミック」など必要ない。

「ギミック」を身につける前に、本物のマネジメントスキルを身に付けたいものですね。

新・ＰＭコンピテンシー強化術（スキル編）～プロジェクトマネジメント実践を強化するマネジメントの原理原則（リンクあり）

プロジェクトマネジメントのあり方について

プロジェクトマネジャーにとって技術や分野の専門知識は必要である

という命題がある。

この命題が真だという人は、プロジェクトの成功が技術リスクに強く依存しているため、技術の素養がないとプロジェクトはうまくマネジメントできないという意見が多い。特に、管理職とは違うという言い方をする人が多い。

逆に偽だという人は、プロジェクトは専門家を集めて、彼らに権限委譲して行うのだから、マネジメントスキルがあればよいという意見の人が多い。

この議論はキャリアの議論としては意味があると思うが、プロジェクトマネジャーの任命やプロジェクトマネジメントの中ではほとんど無意味な議論だと思う。神学論争である。

この命題よりもはるかに重要なのは、

一人の技術者が技術者としていい仕事をするためにはマネジメントの資質が必要

だという命題である。

僕自身のコンサルタントとしてのキャリアの中で１５年間、多くのエンジニアに出会ってきたが、この命題を否定するような人材に出会っていない。この命題は明らかに真だと思う。

この理由は２つある。

一つは最近、エンジニアにもプロジェクトマネジメントのスキルが必要だという指摘の根拠になっている組織で仕事をしているからである。ただ、これはそんなに大きな問題ではないように思う。

もう一つは、自分が満足すればよい仕事だという人は別にして、はやり、自分が満足し、人からも評価されるためには、マネジメントの資質が必要になるという事実である。これは、組織に認められるからとかいったレベルではない。エンジニアの取り組む仕事で絶対的に価値のある仕事は残念ながら少ない。プロジェクトＸのような大きな仕事を見ていてもそんな数はない。

すると、すばらしい発見やアイディアを出す以前の問題として、分野の選定が極めて重要である。シーズにさえならないような分野で何をやってもそんなに認められるものではない。ニーズだけではなく、シーズもある意味で市場である。つまり、市場の認めない仕事をしても意味がないということになる。

ここでいう市場を商品市場のような狭い意味で捉えないでほしい。例えば、社内で技術開発をする場合には、自分の所属する組織なり、企業なりが市場を持っている。この市場に適応できなくては話にならない。

もう一つ、僕が持っている命題がある。それは、マネジメントの資質がある人はセルフマネジメントがきちんとできる。自らの目標発見、動機の維持、タイムマネジメントなど。これはいずれも、マネジメントの基本である。

この命題は逆も真である。セルフマネジメントができている人はマネジメントの資質もある。

このように考えていくと、画期的な仕事をできる人は市場を見つける活動と、セルフマネジメントにおいて、マネジメントの資質を持った人であるといえる。

さすがに１５年くらいの仕事をしているだけでは、イノベータに出会う機会はそんなになく、事例は少ない。それでも１０人程度はイノベーッティブな仕事をしたと評価されている人に出会ったことがある。最近の例で言えば、ウィルコムのＷ－ＺＥＲＯシリーズを開発したエンジニアは長い付き合いだが、抜群のマネジメントセンスを持っていた。

エンジニアがプロジェクトマネジメントのスキルが必要だから身につけるというよりは、エンジニアとして自らの仕事を大きく花を咲かせるためにどのようなマネジメントスキルが必要かを考えてほしい。

それがプロジェクトの成功にもつながるし、エンジニア自身の成功にもつながる。

プロジェクト（マネジメント）の議論をするときに、スコープを仕様というニュアンスで使っている人が多いが、ご存知の通り、これは正しくない。スコープというのは成果物と役務の相対を指す言葉だ。ＰＭＢＯＫではこれをさらに明確にし、

●プロジェクトスコープ：規定された特性や機能を持つプロダクト、サービス、所産等を生み出すために実行しなくてはならない作業

●プロダクトスコープ：プロダクト、サービス、所産に特有の機能や特性

と区別して使えと書いている。

ここまではいいと思うが、では、スコープマネジメントというのは何をすることなのか？問題はこちらだ。仕様管理、構成管理、変更管理だと思っている人が多い。これが冒頭の話。

実は、ＷＢＳがうまくかけない悩みを持つＰＭは極めて多いが、ＷＢＳは両方のスコープを統合するツールであるので、このスコープマネジメントの認識がないとまず、上手に作れない。

実際には、ここに工法（仕事の進め方）が絡む。建築プロジェクトを考えてみると分かりやすいが、ある仕様の建築物を作ろうとすれば、必ず、工法を決める必要がある。これがプロダクトスコープとプロジェクトスコープである。プロジェクトスコープとプロダクトスコープは１対１の場合も少なくない。

逆にソフトウエアなどでは自由度が高く、プロダクトスコープは厳密に管理する必要があるが、プロジェクトスコープはあまり真剣に考えない。プロジェクト見積の中でも、プロダクトスコープをベースにして見積もり、それにプロジェクトスコープの配慮を入れるというのが普通である。

実際にはプロダクトスコープとプロジェクトスコープはもっと微妙な関連にある。プロジェクトの目的を達成するためにプロダクトスコープだけを調整するのではなく、プロジェクトスコープを調整することを考える必要もある。つまり、工法の工夫だ（要員数の調整もこの中に含まれる）。

このマネジメントを一口でいえば、プロジェクトスコープで調整するか、プロダクトスコープで調整するかを工夫することより、プロセスをシンプルにし、それによって生産性を上げること。

プロジェクトスコープとプロダクトスコープの両方をマネジメントする方法を説明することは非常に難しいが、よい本を見つけた。経営工学の大家で、良い仕事をされている慶応大学の中村善太郎先生のご本だ。

この本は、仕事を「もの」と「こと」に分けて、整理し、調整することにより、プロセスがシンプルになり、生産性が上がることを書かれた本。

先生の言われている「もの・こと」分析は、例えば

　「素材」を「製品」に変える「こと」

　はじめの「もの」をおわりの「もの」に変える「こと」

として捉え、この変換過程を、「もの・こと」図として書くことによって、スコープがきれいに整理でき、仕事の最適なプロセスを見つけるという発想。これは非常に分かりやすい。