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

◆理解＝分ける＋再構成

今回はちょっと変わった話をしてみたい。

ＷＢＳをベースにしたプロジェクトマネジメントは、分けることを前提にしている。
では何のために分けるのか？分かるためである。つまり、このプロジェクトがどういうものであるかを理解（認識）するためである。

ただし、細分化するだけでは理解に到らない。細分化されたものを再構成する作業が理解を導く。再構成の方法にはいろいろとあるわけだが、一般的にいえばシナリオに
沿って再構成する。プロジェクトではこれをスケジュールといっている。

◆見える化から見せる化へ

見える化はあたり前になりつつあるが、一方で、「見せる化」という言葉が注目されつつある。見える化というのは内向きの話だが、見せる化は外向きの話である。

見せる化の元祖はおそらく、寿司屋である。もう２０年以上前になるが、米国から来日したビジネスパートナーを寿司屋に連れて行ったら、寿司そのものよりも、カウンターで客を前にして握ることに感動していた。確かに、珍しかった。最近では、飲食では、蕎麦屋とか、うどん屋とか、刀削麺の店でよく見かける。

◆リスクマインドの低さがものごとを複雑にしている

突然だが、リスクマインド強化研修の中で、リスクマインドを作り出す５つのプロセスとして

・失敗から学ぶ
・単純化を許さない
・現場を重視する
・専門性を尊重する
・復旧能力を高める

が必要だという説明をしている。以前、この研修を受講して戴いた方と偶然お会いする機会があり、シンプリシティの話になった。彼がいうには、リスクマインドが低いから、ゴテゴテの商品ができるのではないかというのだ。

◆プロジェクト憲章を誰が書くのか

１０月２８日に開催したセミナー「ＰＭＯ２.０」セミナーのパネルで、プロジェクト憲章を誰が書くかが話題になった。一般的なプロジェクトマネジメントの教科書では、プロジェクト憲章はミッションステートメントであり、プロジェクトのミッションとプロジェクトマネジャーの指名を目的としたドキュメントである。

その意味では、例えば、事業部長など、組織のしかるべき人が書く。プロジェクトによっては、社長が書くようなものがあってもおかしくはない。

◆ホールシステム・アプローチとは

戦略ノートの新しいスレッドとして、ホールシステム・アプローチのスレッドを立てることにする。いろいろな意味でずっと関心のあった分野だ。

ホールシステム・アプローチとは、組織や分野の境界を超えてできるだけ多くの関係者が集まり、自分たちの課題や目指したい未来について話し合う大規模な対話の手法である。ホールシステム・アプローチの代表的なものには、ワールドカフェ、OST、アプリシエイティブ・インクワイアリ（AI）、フューチャー・サーチなどがある。

次に、なぜ、プロジェクトマネジメントでホール・システムアプローチが重要かという問題に触れておく。プロジェクトマネジメントでホール・システムアプローチが必要になるのは、広い意味でのコンフリクトを前向きに解消するためである。

◆「○○絶対」

「○○絶対」という考え方がある。例えば、「品質絶対」、「納期絶対」といった考え方もあれば、「顧客絶対」といった考え方もある。

「絶対」といえばいかにも明確な方針を打ち出し、意志決定をシンプルにしているように見える。しかし、これはレトリックであり、実体は何も言っていないに等しい。

にもかかわらず、なかには、「○○絶対」は全社的な価値感であり、その是非について議論をすることすら難しいといった風土の企業もある。総じていえば、「○○絶対」はものごとをシンプルにするどころか、一層複雑にしている。今回はこの問題を話題にしたい。

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

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

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

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

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

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

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

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

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

◆はじめに

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

◆お詫びと訂正

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

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

です。

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