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

◆リーダーシップの欠如がプロジェクトを複雑にする

前回、プロジェクトをシンプルにするにはリーダーシップが重要であることを述べた。今回はこの問題をもう少し、高い視点から考えてみたい。もう一度、コッター博士のリーダーシップとマネジメントの定義を確認しておく。

マネジメント：現在のシステムを機能させ続けるために、複雑さに対処することリーダーシップ：現在のシステムをよりよくするために、変革を推し進めることである。

この定義に従うと、プロジェクトマネジメントは現行のプロジェクト業務の方法や、プロジェクトマネジメントプロセスを前提にして、如何にその中でプロジェクトをやりきるかに対する相違工夫だといえる。実際に、プロジェクトの現場で行われているプロジェクトマネジメントはそういうものだろう。

でも、プロジェクトリーダーはどこに行ってしまったのだろうか？

◆「品質優先、コスト、納期は柔軟に対応」

製造業やＳＩでは、プロジェクトマネジメントを品質マネジメントの拡張だと考えているケースが多い。組織を見ても、品質管理部門の中にＰＭＯを設置したり、あるいは、品質管理部門をＰＭＯに組織替えしているケースもある。

その品質のマネジメントも２０年前と較べると大きく変わっている。２０年前であればユーザが不都合だと考える事象は品質に問題があると考えられてきた。しかし、今は商品の複雑化に伴い、すべてのユーザが了とする「絶対品質」というのは無くなりつつある。そこで、商品毎に「品質がよいとはどういうことか」を計画し、顧客や市場と合意しなくてはならなくなっている。言いかえると瑕疵（問題であるという状態）の定義をしなくてはならない。もちろん、提供サイドに品質メトリクスがなくなったわけではないが、知覚的なレベルの品質で市場との合意ができない商品は問題を引き起こす。少し前に世の中を騒がせたトヨタプリウスのブレーキの問題はまさにそうだろう。

このように考えていくと、プロジェクト品質という考え方の合理性が見えてくる。成果物の品質も含めて、（プロジェクト）品質とは計画の精度であると整理できるからだ。つまりは、プロジェクトマネジメントを品質マネジメントの延長線上に取るということは自然である。

◆はじめに

今回のテーマは、この問題の本質に迫るテーマだ。商品を複雑にしたいと思っているメーカの開発者もいない。システムをできるだけ複雑にしたいと思っている情報システム部門の担当者もいない。しかし、プロジェクトで生み出される商品や情報システムはどんどん、複雑になっていく。なぜだろうか？

◆お詫びと訂正

８月６日の第１回（戦略ノート２２３）から久しぶりのシンプルシリーズ第２回。第１回配信後に若干名から、ヘッダーを間違っていると指摘されました。間違っていました。このためひょっとすると第１回ってどこだと思われた方もいらっしゃるかもしれません。戦略ノート２２３が第１回です。お詫びとともに、訂正させて戴きます。

　［１－１］戦略ノート（２２３）
　　　　　　「シンプル」考（１）　顧客とユーザ

です。

もう一つ、第１回の記事のタイトルというか、言葉使いについてシンプルという形容詞はおかしいのではないかという意見を頂いた。まあ、カタカナ英語の場合、形容詞を名詞で使うことはままあると思うのだが、この場合には、simplicityという正しい単語があるので、こちらを使うことに決めた。というわけで、サブタイトルが「シンプル考」から、「シンプリシティ考」になっている。なんとなくかっこよくなったかな。シンプルではないような気もするが。

◆プロジェクトの成果について考える２つの事例

プロジェクトで成果を上げるとはどういうことだろうか？こんな基本的な話題を改めて考えて見た。

わかり易い話から入ろう。ＳＩベンダーは得意先からある業務システムの受託開発プロジェクトを受注した。ＳＩベンダーは得意先の要求通りのシステムを開発し、引き渡した。しかし、得意先は満足しなかった。システムの仕様は自分たちの指定した通りであることを認めつつも、できあがったシステムでは自分たちの狙っていた効果を出すことがないないと主張。全面的な改定を要求した。長年のつきあいは何のためだとまでいった。これに対して、ＳＩベンダーは契約を楯にとって自分たちの仕事の正当性を主張。結局、得意先はＳＩベンダーとの取引を打ち切るという事態に発展した。

議論したいことは、どちらに非があるかではない。非があろうが無かろうか、ＳＩベンダーが得意先を一つ失い、年間数億円の売上げを失ったことは紛れもない事実である。仮に顧客に非があるとしても、失ったものを取り返すことはほとんど不可能だろう。

もうひとつ、今度は多少複雑な話。あるメーカでは、新商品の開発プロジェクトを実施した。そして、開発部隊はコンセプト通りの商品を開発した。企画者はコンセプト通りだと評価し、品質レベルも上々だった。ただ、不幸なことにまったく売れなかった。売れない商品を作ると振り返りという名の犯人捜しが始まる。犯人捜しの中で、開発リーダーがこの仕様では売れないということを指摘していたことが判明した。当然、なぜ、その意見を企画担当に伝えないかという議論になった。聞いてみると一度伝えたが、歯牙にもかけられなかったというのが真相らしい。

ここでも議論したいことはどちらに非があるかではない。いまさらそんな議論をしても手遅れだ。

◆ガラパゴス化とはなにか

１０月２８日に実施するプロジェクトマネジメント無料特別セミナー「ＰＭＯ２.０」の副題に、「ガラパゴス型からの脱出」というタイトルをつけたところ、何人もの方からどういう意味ですかという問いを受けることになった。

もう少し、一般化した言葉だと思っていたので、意外だった。この言葉を最初に使ったとされている野村総研のNRI未来ナビに収録される論文「「ガラパゴス化」する日本」
では、以下のように説明されている。

技術やサービスなどが日本市場で独自の進化をとげて、世界標準からかけ離れてしまうという現象が起こっています。このような現象は、生物の世界でいうガラパゴス諸
島における現象にたとえられて「ガラパゴス化」といわれています。

もともとは国内でどんどん高機能化するのに、海外に展開できない携帯電話に対する言及から出てきた言葉であるが、こういう例は今に始まったことではない。呼び名は
ともかく、我々がこの問題を最初に意識し出したのは、パソコンではないかと思う。
一時は、国内で８０％以上のシェアを持ったＮＥＣ製のパソコンＰＣ－９８が、やがて、コストパフォーマンスに優れたグローバル標準ＰＣ／ＡＴ互換機の上陸とともに、終焉した。

最近では、携帯電話、電子マネーといったハードウェアだけではなく、医療サービスや大学、会計基準などでもガラパゴス化という言葉が使われるようになっている。

◆コミュニケーションマネジメント１.０

２１８回でＰＭ２.０宣言をした。今回は、ＰＭ２.０におけるコミュニケーションマネジメントについて考えて見たい。

プロジェクトマネジメントの問題点としてコミュニケーションの問題がよく取り上げられるが、特に問題意識が高いのは顧客をはじめとするプロダクトスコープに影響のあるステークホルダとのコミュニケーションである。重要だと捉えていればこそだろう。実際に、スコープマネジメントの問題はコミュニケーションの問題だと言ってもよい。コミュニケーションの質によって、スコープに対する目標達成のレベルが変わってくるし、それがプロジェクトの成否に関わってくる。このように顧客も含む現場の中でのコミュニケーションで、スコープを決めて行く。

この場合、上位組織とのコミュニケーションは与えられた目標の達成度の報告が基本になる。いわゆる進捗報告だ。そこでは、進捗が芳しくない場合の問題解決は話合われることがあるが、目標設定のイニシャティブは上位組織が持ち、その「妥当性」について話合われることはまずない。目標は妥当であり、進捗が芳しくないのは目標達
成の方法が適切ではないからだという前提で考える。この前提が崩れた場合は「トラブル」になる。

このコミュニケーションのマネジメントをＰＭ１.０に擬えてコミュニケーションマネジメント１.０と呼ぶことにしよう。

これはあくまでも上位組織から目標が与えられた場合の話、つまりＰＭ１.０におけるコミュニケーションマネジメントになる。

◆ドラッカーブーム来る

今年は史上空前のドラッカーブームのようだ。報道バラエティはもちろん、お笑いのメッカ・関西では、お笑いバラエティでもドラッカーが取り上げらている。

きっかけになったのは昨年発売された１冊の本だ。通称「もしドラ」、「もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら」という小説である。高校野球が真っ盛りだが、この小説は弱小野球部の「女子マネジャー」がマネジャーの仕事を知りたくて、ドラッカーのマネジメントを読み、野球部を改革していくというストーリー。

岩崎 夏海「もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら」、ダイヤモンド社（2009）
https://mat.lekumo.biz/books/2010/01/management.html

ドラッカーといえば、ほとんどの出版を手がけているのがダイヤモンド社だ。ダイヤモンド社は大正２年の創業以来、ハーバードビジネスレビューを始め、マネジメント分野で大きな影響を与える出版活動を多数手がけている。もちろん、ドラッカーの著作物の翻訳出版もそのひとつだ。

そのダイヤモンド社が「もしドラ」で創業以来初めてのミリオンセラーを達成したのだ。今起こっているドラッカーブームがどれだけ凄いかよく分かる。

◆複雑化する成果物と厳しくなる制約

今、多くのプロジェクトが頭を抱えている非現実的ともいえる制約条件の根源にあるのが、成果物の複雑さである。複雑な機能の商品に複雑さを実現している組み込みソ
フトウエア、複雑な情報システムなどだ。

この問題の本質は、ユーザはほとんど使わないだろうと思える機能を追加することにより、プロジェクトの制約が厳しくなっていることだ。なぜそのようなことをしているかというと、誰も「意思決定」をする人がいないからだ。言いかえると、戦略的な発想がないからである。

もう少し異なる視点でみると、顧客の声を聞きながら、顧客のことを考えていない。
顧客に言われる通りに作る。それが不便であろうが、使わないものであろうが、顧客が望んだ機能だ。そこにはユーザという視点がない。

◆プロジェクトの２つの側面

プロジェクトには２つの側面がある。ひとつはビジネスであり、ひとつはオペレーションである。プロジェクトマネジャーはこの両方をマネジメントすることを求められる。これがプロジェクトマネジメントの難しさの本質でもあり、品質管理とプロジェクト管理は違う理由でもある。

ＰＭＩでは、オペレーションのマネジメントをプロジェクト（プログラム）マネジメントとして行い、ビジネスのマネジメントはポートフォリオマネジメントなどの経営システムの中で行うように整理している。したがって、プロジェクト（プログラム）マネジメントはプロジェクトポートフォリオなどの形で表明された経営の意図を正確に実現することが求められる。

Ｐ２Ｍでは、オペレーションとビジネスのマネジメントの両方をプログラムマネジメントとして行う。プログラムの中に経営があるといってもよい。