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

◆ゲゼルシャフトのゲマインシャフト化

サントリーで情報システム部長、事業部企画部長、工場長、商品開発研究所長、ＳＣＭ本部長、取締役、サントリー食品工場社長などを歴任され、現在は多摩大学大学院で教鞭をとられている橋本忠夫先生の「変革型ミドルのための経営実学」（芙蓉書房出版、2010）という本を読んでいたら、

評論家の堺屋太一氏が「組織の盛衰」で指摘する「ゲゼルシャフト（機能体）のゲマインシャフト（共同体）化」の軋轢を避けるには、専門家（技術者）が経営にコミットするのが一番自然で分かりやすい

という指摘があった。

もう少し、橋本先生の指摘を補足しながらもう少し詳しく説明しよう。技術の進歩の激しい分野で、専門家が４０歳になったときには、新しい世代が専門用語も異なる世界を引っ提げて迫ってくる。たとえば、ＩＴがそうだ。ＩＴの現役世代で専門性を考えると、５０代はエンドユーザコンピューティング、４０代はオープンネットワーク、３０代はインターネット、２０代はクラウドである。１０年ごとに新しい概念が出ている。ベテランの技術者は本質は変わっていないというが、実はここがくせ者なのは後で述べる。

◆分業型のチームと協働型のチーム

世間ではチームマネジメントがブームである。この半年で、チームマネジメントをテーマにした本は３０冊は出ていると思う。チームで仕事をすることの重要性への認識が高まってきているのだろう。

チームで仕事をすることの重要性は、プロジェクトでは改めていうまでもない。

チームで仕事をするといった場合、チームのスタイルは二つに分かれる。分業型のチームと協働型のチームである。分業型は生産を目的とするプロジェクトでよくみられるスタイルである。ＷＢＳで仕事を分け、責任者を決め、最終的にチームとして成果を統合していくスタイルである。

これに対して、協働型のチームは、チームで行うべき課題を全員でやっていく。細かくみれば作業分担をすることもあるが、基本的にはプロジェクトの一つ一つのイシューに対して、全員で知恵を絞り、動いていく。

◆売り手市場と現場力

前回は、上位管理者の役割が混乱しているという話をしたが、今回はこの問題の背景を考えてみたい。

日本企業の強みの一つは間違いなく、「現場力」である。類まれともいえる現場力で成長してきた。ここで一つ、はっきりしておかなくてはならないのは、その間、売り手市場だったということだ。売り手市場ではよいものを作れば売れる。おまけに日本の高度成長期は規制による横並びの市場だった。言ってしまえば統制経済に近かったので、本当の意味での競争もなかった。このような環境であれば現場力が強いと全体が回っていく。

現場力が強みという話が怪しくなってきたのは、市場も成熟し、いわゆるバブルもはじけ、モノ余りが言われるようになってからである。

ここで多くの企業が考えたのは、モノが売れないのは、良いモノを作る力が落ちている、つまり現場力の低下だと考えた。品質、リードタイム、コスト、・・・

そこで、より一層の現場力向上をしようとした。その一つの施策がプロジェクトマネジメントである。この判断自体が間違いだとは思わないが、そのあとの方向性で致命的なミスをしている。それは、現場力を直接上げようとしたことだ。

◆混沌を極めるプロジェクト上位管理者の役割

プロジェクトマネジメントはなんとか形になってきた組織が多いが、プロジェクトの上位管理者の役割や機能については、まだまだ、混沌としている企業が圧倒的に多い。大きな理由は２つあるように思う。

一つは、責任分担が不明確なことである。もう一つは、上位管理者がプロジェクトマネジメント（ロール）をあまり理解していないことである。このスレッドでは、プロジェクトの上位管理者の役割や機能を整理してみたい。戦略ノートでは、２００８年に１７６回から８回かけて、一度、この議論をした。しかし、消化不良の部分もあり、また、当時とは考え方も変わっているので、異なる枠組みで改めて、議論をしてみたいと思っている。

第１７４回（2008.01.29）
組織が行うべきプロジェクトマネジメント（１）～責任のフレームワーク

◆１０年間使い続けることのできる情報システムは作れるか？

前回、商品開発にしろ、ＩＴにしろ、顧客がもう少し、積極的な参加を望むようになってきた。その中で、プロジェクトマネジメントはどうあるべきかを考える必要があるというところまで話しが進んだ。これから、少し、個別の領域でどうあるべきかを議論していきたいと思っている。まずは、著者がこの議論を考えるきっかけになったＩＴの分野から。

ＩＴの分野でこの問題意識を持ったのは実はもう２０年以上前である。きっかけは、あるコンピュータメーカのユーザシンポジウムで、偶然、聞いたＧＭＳのの情報部門の人の話。おそらく、コンピュータメーカのＳＩ部門に対する要望として、「システムの開発はせいぜい１年だが、我々はそのシステムを１０年間使い続けることになる。そのことを意識して対応をしてほしい」という趣旨のものだった。もっともな話なのだが、その話を聞いた瞬間に思ったのは無理だということだった。

たとえば、ＮＣマシンを調達し、１０年どころか、１５年、２０年使うということは珍しくない。ところが、１０年間使える情報システムの基盤というのは想像できない。自社のビジネスにおける位置づけが違うからだ。もし、１０年間使えるとしたら、情報システムの作りの問題ではなく、その企業のビジネスシステムやビジネスモデルがよほど卓越しているからだろう。実際に、その後、償却期間の設定も短くなり、情報システムのライフサイクルは短くなってきた。

◆プロジェクトという活動

ＰＭＢＯＫでは、プロジェクト・ステークホルダを、プロジェクトという活動に関与する人と定義している。プロジェクトマネジャーもプロジェクトメンバーもみんなステークホルダである。

プロジェクトに対してプロジェクトマネジャーを指名し、そのプロジェクトマネジャーの行う活動というイメージを持つ人が多いが、実はそうではない。プロジェクトには、プロジェクトに投資する人が出す目的があって、その目的に関心や利害関係を持つ人が集まり、役割を決めて目的を達成するというのがイメージに近い。

役割の中では、やや特別な役割となるのが、プロジェクトスポンサーである。プロジェクトスポンサーはプロジェクトを構想し、プロジェクトの目的を決定し、その目的を達成するためにプロジェクトに投資（資源提供）をする。

これがもっとも一般的なプロジェクトのイメージである。

◆はじめに

春先は、新しいプロジェクトが増え、また、人事異動などの影響で新任のプロジェクトリーダーが増える時期でもある。今回の戦略ノートは、基本に立ち返り、プロジェクトリーダーの役割について考えてみたい。

まず、プロジェクトメンバーとプロジェクトリーダーはどう違うのかについて、いくつかの視点から考えてみよう。

◆リカバリーをしたら、リードタイムが短くなった

過去に一度だけ、トラブルリカバリーをして、当初の計画より早く新製品（生産財）が完成し、かつ製品は当初計画より多くに売れた。この話を研修ですると、５人に一人くらいピンとくる人がいる。読者のみなさんのなかにも、気がついた方がいらっしゃると思う。製品機能を予定されていたものから削減をしたのだ。それも、既存機能だ。

スコープを削減する場合には、新規機能を対象とすることが多い。新規機能を対象に考えると、理由にもよるが多くの場合は、頑張ってなんとか実現しようということになる。新規機能に対してマーケティングしているのだから、ある意味、当たり前だ。

ところが、このケースはちょっと事情が違った。スケジュール遅延を引き起こした技術的な問題の解決のためには、既存機能を削るか、新しい機能をあきらめるかという選択をせざるを得なかった。

そこで、ラインナップを変更し、既存機能を削った新製品を開発することになった。

◆失敗の法則

トラブルに陥り、不適切な対応で、大失敗に終わるプロジェクトには共通的にみられる対応行動がある。

（１）即効性のある対応にこだわる
（２）起こっていることを深刻さを見誤る

の２つである。この２つは深く関係しており、深刻さを感じないから、即効性だけを考えた対応、悪くいえば目先の対応をする。

◆米国連邦危機管理庁・元長官のジェームズ・ウィット氏の言葉

米国連邦危機管理庁を公務員的な組織から、危機管理の役割をしっかりと担える組織に立て直したことで知られるのジェームズ・ウィット元長官が自書で

強いリーダーほど、厳しい試練に出会った時にまわりの人たちの力を借りている

という指摘をしている。

では、どのように力を借りればいいのか。これが結構、難しい。試練に出会うとはどういうことかということでもある。今回はこの点について、プロジェクトを念頭において考えてみよう。