イノベーション実践、コンセプチュアルスキル、プログラムマネジメント、プロジェクトマネジメント、ＰＭＯについての最先端の情報、研修、セミナー、コンサルティングをお届けします。

番外編　ＳＩ組織におけるミドルマネジメントの問題（2009.03.15）

プロジェクトマネジメントオフィス　好川　哲人

• Tweet
• 

◆システムにはモノとは異なる品質が概念が必要である

多くの企業は、商品や品質に対して強い関心をもっており、古くから、ＩＳＯに代表される品質管理制度に、大きなコストを投資し、取り組みを行ってきた。しかし、商品が複雑になるにつれて品質管理が難しくなってきている。

商品が複雑になるという意味は、システム化されるという意味である。例えば、センサーを作っている会社が顧客や市場の求めに応じて、センサーだけではなく、計測・データ収集装置を作るようになるということが起こっている。センサーであればモノをしっかりとチェックすれば市場の要求品質は実現できたし、プロセスの品質を上げることによってさらなる品質向上を行うことができた。

ところが、装置になるとそう単純ではない。１社だけで全体を作ることはできなくなっているし、プロセスも固定化しにくい。機能も複雑であり、品質検査も難しい。また、ユーザ側の事情によって特殊な利用方法が求められることもあり、網羅的な検査も難しくなる。このような性格を持った商品の代表が情報システムである。


◆品質は現場だけで作られているわけではない

ＳＩサービスに関わる組織がまず理解しておきたいことは、この点を踏まえた上で情報システムの品質を向上させることが最大のミッションであるということ。そして、その品質は現場だけで作られているわけではないということだ。

品質マネジメントの先進業界である製造業を例に考えてみると、品質に定評のある企業は例外なく、現場の品質をあげるために組織全体が動いている。品質管理活動、技術支援や、管理技術の開発や運用の支援はもちろんであるが、評価、人事制度に至るまですべてが現場の品質を実現するために方向付けられている。言い換えると、現場の品質を組織全体で支えている。


◆品質が評価するのは「顧客」

次に理解しておきたいことは、ＳＩサービスの品質を決めるのは、顧客であるということだ。

情報システムの品質というときに出てくる、性能、信頼性、整合性、耐久性、保守性、デザイン、顧客満足などさまざまな要素はベンダーが顧客と相談の上で決定していくものである。しかし、ＳＩサービスにおいてベンダーが提供しているのは情報システムというモノの提供を中核にしたサービスであり、モノの品質は最終的にはサービスの品質に吸収されるものである。

このように捉えると、ＳＩサービスの品質というのは、すべて顧客の知覚品質に集約されると考えてもよいかもしれない。

この点について、２つの事例を通じてその意味するところを考えてみたい。


◆品質について考える事例１〜モノの品質よりサービスの品質

一つ目はある物流システムのＳＩプロジェクトの事例である。

このプロジェクトではシステムの開発が遅れ、顧客側の供用開始の時期に間に合わないという事態になってしまった。このプロジェクトは顧客の新しい商品群への対応のためのシステム更新であったので、そのシステムが間に合わないと顧客は新しい商品の発売時期を遅らさざるを得ない。

そこで、このＳＩ企業が顧客と相談してとった手段は、不完全なままのシステムで一旦リリースし、自動化部分を人的にカバーするという方法だった。この状態をなんと４０日続けた。そして、４０日後にはシステムも完成し、新システムへの切り替えもスムーズに行き、システムは無事に稼働を始めた。

ここで思わぬ効果がでた。導入したシステムやシステムを活用した業務への顧客の習熟度が高くなっていた。上のような状況で業務の運用をしていたことが思わぬ教育・サポート効果になった。

このことが判明したのは、運用を始めて１年くらいしてトラブルが発生したときだったが、顧客はたいへん、喜び、そのタイミングで社長がＳＩ企業に出向き、会社の意を表したという。

最近はシステムの品質は過剰品質ではないのかといった議論がみられるようになってきた。例えば、止まらないＡＴＭシステムが本当に必要かと言った議論である。現実に、顧客が品質に厳しいので、プロジェクトの方針に品質絶対という方針を掲げるが、実際には顧客が望んでいるのは自分たちのビジネスがその情報システムを使ってスムーズに進むことであるというケースは多い。顧客側にしてみればこの事例のように問題なのは情報システムの品質なのではなくて、サービスの品質なのだ。


◆品質について考える事例２〜出荷品質より顧客満足

二つ目は携帯電話の事例である。

携帯電話は第３世代になってから、オンラインでファームウエアの更新をするようになってきた。あまり情報公開がされていないようので正確なところはわからないが、何らかの不具合の修正、あるいは、仕様の変更をそのような形でやっているものを推察される。つまり、これまでは出荷前に対応していた不都合を出荷後に是正している。

モノを作っていると考えるとこれはゆゆしき事態だといえるが、製品の提供も含めたサービスの提供だと考えると何の問題もない。むしろ、製品の品質を上げるために納期を遅らせてしまうより、スピーディーに出してあとで品質的な対応をするという方が顧客にとって満足感の高い対応だといえる。

また、製品の出荷後に顧客の動向みて、ある程度の仕様変更の余地を残しておくことも、顧客の満足に結びついていく。顧客の方も発想の転換を求められるのですぐに定着するかどうかは別にして、長期的にはより高い顧客満足に結びつくだろう。


◆拡張される品質概念に対応するために必要なもの

これらの事例から見えてくるのは、上にも述べたように品質の概念は拡張されつつあるということだ。

品質はプロダクトの品質から、プロジェクトの品質、あるいはサービスの品質に拡張されつつある。問題は拡張された品質を実現するために、何が必要かという点である。これらの事例からわかるように、従来通りのモノに対する品質管理の考え方だけでは答えは見えてこないし、また、体制的にもプロジェクトだけで完結して品質を実現するということも難しくなってきている。


◆討議１

まず、事例１が自組織の中で起こったと想像してみてほしい。どのような対応をするだろうか？

このようなケースでほとんどのＳＩ組織は、「要員を追加しなんとか間に合わせる」、「納期を遅らせて貰うように顧客と交渉する」といった情報システム開発としてできる問題を解決する方法を選ぶだろう。

ところが、このＳＩ企業はそうはしなかった。なぜ、このような対応ができたかというと、この局面で、顧客のビジネスを成功させるにはどのような対応をすればよいかという発想の行動をとったからだ。

ここで押さえておきたいポイントは、プロジェクトはシステムの開発をすることを目的に組織されたものであり、できるのは開発であり、その枠を超えて活動するというのはかなり難しいことだ。つまり、仮にプロジェクトマネジャーがそのようなアイディアを思いついたとしてもそれを現実のものにするためには、プロジェクトに直接参加するかどうかは別にして、社内の他の部門の協力が不可欠だし、その協力を得るためにプロジェクトの上位組織の支援も不可欠だろう。もう少しいえば、上位組織がプロジェクトを支えるような組織の風土、あるいは組織の柔軟性がなくてはこのような
活動は実現できないといっても過言ではない。


◆討議２

携帯電話の例はより複雑である。商品開発であるので、当然のことながら初期段階でのスコープは決まっている。ところがそれが実現できないとなったときに、プロジェクトとしてはスコープを縮小し、他の部門にあとをゆだねることになる。これを行うためには相当にダイナミズムの高いプロジェクト組織が必要である。

次の問題は、そのような組織風土や組織をどのように実現していくかという問題である。あるいは、実現するためにはどのような要素が必要かという問題である。これが、できる組織問題の本質であろう。


◆できる組織を作る「ミドルアップダウン」

いろいろな切り口が考えられるが、ここでは、その一つとしてミドルを中心にした「ミドルアップダウン」という考え方に注目してみたい。

ミドルアップダウンというのは文字通り、トップダウンでもなく、ボトムアップでもなく、ミドルが経営（トップ）と現場（ボトム）の連結ピンの役割を果たし、組織全体を一体化して動かしていくマネジメントの考え方である。

もともとは、ナレッジマネジメントの方法として野中郁次郎先生が提唱されたもので、野中先生は

====（野中郁次郎＋竹内弘高「知識創造企業」より引用）
チームやタスクフォースのリーダーを務めるミドルマネジャーが社内でタテとヨコの地の流れの交差する中心点に立ち、トップと第一線の社員（フロント＝ボトム）を巻き込んで知識創造のプロセスを創造すること
====

と定義されている。今、ＩＴ企業に求められているのは、この概念を知識創造だけでなく、マネジメント活動全般に拡張していくことではないだろうか。


◆なぜ、ミドルか？

最初に、なぜ、ミドルかということに触れておきたい。

その前に、ミドルという言葉のイメージであるが、これは企業で聞いてみるといろいろな認識がある。年齢で認識している組織もあれば、役職で認識している組織もあるし、ミドルという言葉はピンとこないという組織もある。この議論も重要だと思うが、ここでは割り切って、「年齢的には３５〜４５歳くらいで、大規模なプロジェクトのプロジェクトマネジャー、あるいはプロジェクトスポンサーになるべき立場の人」と限定してミドルという言葉を使う。プロジェクトの体制の中で言えば、チームリーダーや技術リーダー、あるいはプロジェクトマネジャーの上司に位置づけられ、案件の「とりまとめ」となる人をイメージしている。

そのミドルが中心にならなくてはＳＩプロジェクトはうまく行かないと考える理由は、ミドルが顧客の業務に専門技術を結びつけることのできる唯一の存在だからである。

ＩＴ業界的にはソリューションという考え方がある。例えば、ＳＣＭのように情報処理の方法を変えることによって顧客のビジネスをスピード化するという課題があったとする。すると、課題にコミットできる技術を考える、あるいは、技術をどのように課題にコミットさせていくかを考える必要がある。この部分のロジックとロジックを実現する環境を提供しようというのがソリューションである。

元来、ソリューションの適用をうまくやるには、上に述べたように顧客の課題と技術をマリアージュさせる役割が不可欠である。一般的なやり方としてはこれをコンサルタントという専門家を作ってやろうとしているが、コンサルタントには顧客の業務に対する深いレベルの理解と、技術に対する包括的な理解、そして、そのような知識に基づくソリューションの実行能力が求められる。この３つがそろわない限り、ソリューションの適用はうまくできない。顧客との仕事の経験と技術的な経験が必要であると同時に、その経験を経営的な視点から再構成し、業務に活かしていくことが求められる。さらには、その視点から現場を動かしていき、プロジェクトの完遂をファシリテートできなくてはならない。組織の中で、そのような資質を持っているのはミドルである。つまり、ミドルは、現場（技術）と経営（顧客、市場）の中間に位置して、技術を売り上げや顧客満足という成果につなげていくことのできる唯一といってもよい存在である。職称はコンサルタントでも構わないが、これがミドルにこだわる理由である。


◆ミドルアップダウンとは何をするのか

次にそのミドルが活躍するミドルアップダウンとは具体的には何をすることなのかを考えてみたい。ナレッジマネジメントもそうだが、ミドルアップダウンの背景にあるのは「強い現場」である。経営学流にいえば、上の階層が下の階層を支える逆ピラミッド型の組織。冒頭に述べた品質力強化の議論からもわかるように、現場を強くするには組織全体の協力が必要であるし、特にトップコミットメントが不可欠である。ミドルアップダウンはこのための仕組みである。そのように考えると、すべきことは比較的明確である。

（１）現場の要求（問題）を吸い上げその問題解決を経営を巻き込んで行うこと
（２）経営の課題（顧客の課題）を吸い上げ、現場を巻き込んで課題解決を行うこと

の２つである。

一方が欠けてはならない。経営の課題とは顧客や市場へのサービス提供のあるべき姿の実現、つまり戦略の実現である。これに対して、現場の問題とは現実である。当然のことながら、この２つの間にはギャップもあるし、矛盾もある。このギャップを埋め、矛盾を解消することがミドルマネジメントの責務であり、それが現場力の強化につながっていく。

この際に気をつけなくてはならないのは、この話は単なる戦略の現場への落とし込みではないことだ。落とし込むだけであればミドルの役割はそんなに重要ではない。それは欧米の組織をみればよくわかる。ミドルマネジメントは層が薄い。日本型経営の特徴でもあるが、日本のミドルマネジメントは落とし込むだけでなく、落とし込みの中で、現場の要求も踏まえて、戦略の調整をする役割も担っている。だから、ミドルが重要な役割なのだ。


◆ミドルの役割を果たすには「コンセプトの創出」が必要

そのような役割を果たすためには何が必要か？「コンセプトの創出」である。戦略と現実を両立させるコンセプトを創出することこそが、ミドルに求められている役割である。戦略のベースになっている経営レベルのコンセプトというのもあるが、ここでいうコンセプトはそれではなく、事業のコンセプト、製品やサービスのコンセプトである。ここに戦略を現場の現実を埋めていくコンセプトを設定していく。

ひとつ考えてみてほしい。顧客満足の最大化を戦略に掲げているＳＩ企業がある。これを現場に落とし込んでいくと、顧客の要求をできるだけ丁寧に聞き出していき、それに応えていくという行動を現場（プロジェクト）に求めることになる。しかし、現実のプロジェクトをひとつひとつとってみると、厳しいスケジュールやコスト、リソースの制約があり、おいそれとできる話ではない。ここで、あなたが、「ミドル」であったらどのようなサービスコンセプトの設定をするだろうか？


◆コンセプト創出の事例

ここに「顧客価値の最大化」というコンセプトを設定した組織がある。この事業コンセプトは非常に効果的で、最終的には現場の顧客提案内容や顧客折衝ががらりと変わった。ところが、プロセスはそんなに順風満帆ではなかった。読者のみなさんの中にも感じられた方がいると思うが、「顧客価値の最大化」と「顧客満足の最大化」というのは何が違うのかというのが現場にも、上層部にもなかなか理解して貰えなかった。理屈は簡単で、顧客価値の最大化というのは情報システムを導入した結果であって、プロジェクトで得られる顧客満足よりスパンの長いものである。要は、冒頭に紹介した物流システムの事例のような話で、システムそのものにこだわらずに、顧客のビジネスまで視野を広げ、そこで長期的な顧客満足を達成しようというコンセプトである。口でいうのは簡単であるし、頭での理解は得られやすい。

しかし、このコンセプトの実行には結構高いハードルがある。経営レベルのハードルとしては、短期的に見たときに既存顧客を失うのではないかという心配。現場レベルでは、「そうはいっても顧客も担当者レベルではシステムをつつがなく完成させることが最重要な課題であり、そのあとのビジネスの話で開発システムの仕様を調整していくことは非常に難しい」という心配。この２つの心配をクリアできて初めて設定したコンセプトが生きてくる。

ここでこの組織の行ったことはこれらの問題を直接的に解決するような仕組み作りではなく、バリューワークショップという仕組み作りだった。プロジェクトの提案時に役員、シニアマネジャー、マネジャー、プロジェクトマネジャー候補が集まり、半日のワークショップを行い、顧客価値を徹底的に議論し、価値の明確化を行い、プロジェクトビジョンと呼ばれるものを作る。この段階では受注できるかどうかわからないが、プロジェクトビジョンがまとめられた段階でＲＦＰと異なる提案をすることについての経営的な合意は得られる。受注できた暁にはこのビジョンがプロジェクト憲章に落とし込まれていくが、プロジェクトビジョンに基づいた提案をすることで、現場が困るような案件は激減しているので、特に難しいプロジェクトにはエース級のプロジェクトマネジャーを当てるといったオペレーションができるようになっていく。問題は受注確率である。受注確率は最初は悪化したが、３年後には施策前より向上した
。
そして、リピートオーダーが実質的に随意契約的になるケースが増えてきた。そして何よりも、よかったのは、バリューワークショップによって、顧客価値を優先することは当たり前であるという風土が組織にできてきたことだった。

◆プロジェクトの範囲のとらえ方

この事例のポイントの一つはプロジェクトの範囲をどうとらえるかという点にある。プロジェクトの範囲というとプロジェクトスコープと捉える企業もあるようだが、ここでいう範囲は少し違う。このプロジェクト活動の参加者は誰までかという意味である。ＰＭＢＯＫ（Ｒ）ではプロジェクト活動は、ステークホルダの総体だと定義されるが少しわかりにくいので、顧客を「開発」プロジェクトのうちにみるか／外にみるか、あるいは、上位組織をプロジェクトの内にみるか／外にみるかということだと考えてほしい。一つの極にあるのはハリネズミ型プロジェクトである。メンバー以外はみんな敵。鋭い針を身にまとい、プロジェクトを如何に守るかしか考えていないプロジェクト。対極にあるのはアメーバー型プロジェクト。いつのまにか、上位組織も顧客も巻き込まれている。できる組織のプロジェクトはアメーバー型でなくてはならない。


◆現場にベネフィットを与えるか

もう一つのポイントは、コンセプトの意味するところが、現場にとっての無駄な仕事の排除であり、結果としてそれは品質レベルの向上につながっていくこと。さらに、その品質レベルの向上は、経営に収益をもたらす。そして、その収益は顧客に対するさらに良質なサービスの提供を可能にし、利益の増加に結びついていく。さらに、利益の増加が従業員の待遇につながり、さらなる品質レベルの向上につながっていくというベネフィットを増す好循環ループができること。つまり、ＥＳとＣＳの好循環が起こることだ。そして、その拡張ループの中で、コンセプトとして掲げた顧客価値というポイントがレバレッジポイントであるという点だ。レバレッジが効かないようなコンセプトを設定してしまうと、悪循環が起こる。このループはあっという間に悪循環ループになってしまう。例えば、品質向上にレバレッジポイントを置いたためにコスト増とスケジュール遅延で、品質低下を招いている組織は結構ある。


◆上方影響力

そのようなコンセプトを描いて、経営と現場の調整をしていく際に、ミドルのあり方として大きなポイントになる概念があるので、最後にご紹介しておこう。「上方影響力」という考え方だ。上方影響力は、上位への発言力や、上位組織からの信頼度など、いわゆる上位組織に対する影響力なのだが、特に注目されるのは1950年代にミシガン大学のドナルド・ペルツ博士が発見・発表した上方影響力である。ペルツ博士の発見のコアは２つあって、

・上司が部下に対して支持的行動を取ることによる効果の高さは、上司自身の上方影響力の大きさによって左右される

・上方影響力の低い上司による配慮はその度合が大きいほど部下の不満が溜まる

というものである。なんだ、当たり前だろうと感じられる方もいるだろう。プロジェクトマネジャーはプロジェクトスポンサー、つまり、ミドルに影響力を持たなくてはメンバーの動機付けができないし、メンバーに構えば構うほど、いやがられる。プロジェクトスポンサー（ミドル）も同じ。プロジェクトへの発言力を持とうと思えば上方影響力を持つ必要がある。1950年代に価値のあった話で2009年に考えると当たり前の話なのかもしれない。しかし、現実にはプロジェクトスポンサーは上位や顧客に対していい顔をするためにプロジェクトに無理をさせていることが多い。命ずるのであればまだしも、それを動機付けという形でやろうとする。ペルツ博士が指摘するとおり、これではプロジェクトに不満をためるだけだ。


◆ミドルに期待されるのは変革リーダー

多くのミドルはそんなことは言われなくてもわかっていると反論するだろう。では、なぜ、そのような行動をとってしまうのか、そこが問題だ。普通に考えると、組織の中でうまく立ち回るためである。さらにこの問題を掘り下げる。なぜ、うまく立ち回るために、そのような行動をとるのか？これを尋ねると１０人中９人は出世のためではないという。だとすれば、考えられる理由は一つしかない。波風を立てたくないという理由だ。本当のそれでいいのか。これがこの記事の最後の問いかけである。キャリアというものを真剣に考えるのであれば、ミドルという年代が社会的にどのようなことを期待されているかは比較的はっきりしている。次世代のリーダーである。会社の中では変革リーダーである。


◆部下が誇りを持って働ける会社にする

ご存じの方も多いと思うが、ユングの太陽運行モデルというのがある。「少年」、「成人前期」、「中年」、「老人」とライフサイクルを分け、成人前期と中年の境を正午に見立てるライフサイクルモデルである。この中で、午前中は「拡大」をする時期。そして午後になると「個性化」をする時期というのがユングの考え方である。いずれもこれらは発達である。

このライフサイクルは年齢とは関係ないのだが、おそらく多くのミドルは成人前期から中年に移行する時期である。この移行において、自らを変革し、自らの信念に基づいて周囲を変革していくというのはキャリア発達にはきわめて重要である。この時期のキャリアをきっちりマネジメントしないと、そのあとの人生は消化試合になりかねない。

上司に意見を具申するのはキャリアに関わることだと思う方もいるかもしれないが、まさに、キャリアをかけた活動である。ミドルはこの時期に、キャリアをかけてミドルアップダウンに取り組み、組織を活性化し、部下が誇りを持って働ける会社にしていく責任があるのではないだろうか。

◆関連セミナー
━【開催概要】━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆コンセプチュアルな組織を創るマネジメント　　　　　　　　　　◆（7PDU's）
日時・場所：【Zoom】2024年 07月 23日（火）9:30-17:30（9:20入室可）
　　　　　 【Zoomハーフ】2023年 03月 15日（水）13:00-17:00＋３時間
　　　　　　　　※Zoomによるオンライン開催です
　　　　　　　　※ハーフセミナーは、事前学習３時間あります
　　　　　　　　※少人数、双方向にて、演習、ディスカッションを行います
　　講師：鈴木道代（プロジェクトマネジメントオフィス、PMP、PMS）
　　詳細・お申込　https://pmstyle.biz/smn/conceptual_management.htm
　　主催　プロジェクトマネジメントオフィス、PMAJ共催
　※Youtube関連動画「コンセプチュアルスキルとは（前半）」「コンセプチュアルスキルで行動が変わる」
　　　　　　　　　　「イノベーションを生み出す力」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　　【カリキュラム】　　　　　　　　　　　　　　　　　　　　　
　１．コンセプチュアルではない組織の問題点
　　・個人レベルの問題点
　　・チームレベルの問題点
　　・組織レベルの問題点
　２．コンセプチュアルなマネジメントのポイント
　　２．１　質問型の組織を創る
　　２．２　コンセプチュアルな組織活動のプラニング
　　２．３　ステークホルダーへのコンセプチュアルな対応
　　２．４　コンセプチュアルな人材育成
　　２．５　コンセプチュアルな組織文化の構築
　３．コンセプチュアルなマネジメントの目標
　４．コンセプチュアルマネジメントでコンセプチュアルな組織を創る仕組みワークショップ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

• 一覧
• 第１回　ミドル・アップ・ダウン（2008.08.26）

著者紹介

好川哲人、ＭＢＡ、技術士
株式会社プロジェクトマネジメントオフィス代表、PMstyleプロデューサー
１５年以上に渡り、技術経営のコンサルタントとして活躍。プロジェクトマネジメントを中心にした幅広いコンサルティングを得意とし、多くの、新規事業開発、研究開発、商品開発、システムインテグレーションなどのプロジェクトを成功に導く。
１万人以上が購読するプロジェクトマネジャー向けのメールマガジン「プロジェクトマネジャー養成マガジン」や「プロジェクト＆イノベーション（無料」、書籍出版、雑誌記事などで積極的に情報発信をし、プロジェクトマネジメント業界にも強い影響を与え続けている。

メルマガ紹介

本連載は終了していますが、コンセプチュアル・マネジメント購読にて、最新の関連記事を読むことができます。