第207回(2009.04.14)
スキルは人から切り離せるのか?

◆「佐藤さん、鈴木さん」か、「Aさん、Bさん」か

新年度を迎えたので、久しぶりの戦略ノートを書くことにした。今日のお題は「スキルは人を切り離せるか」という話。

PMBOK(R)流のプロジェクトマネジメントへの批判としてもっとも多いのはドキュメンテーションの量だろう。これを過剰管理だと言っている人たちもいるが、何か、勘違いしているのではないかと思う。ドキュメントの多さを過剰管理と結びつけて考える人が多いのは、上位組織に対する報告ドキュメントをどれだけ作らされているか、また、ISOやCMMI活動でどれだけドキュメントを作っているかということを物語るものだと思う。これらは確かに過剰管理だという議論はあると思うが、それは組織の事情であってここで議論したいことではない。

PMBOK(R)がどうしてドキュメントが多いかというと、「本質的に必要だから」の一言に尽きる。なぜ、必要か。ここが問題である。

日本の仕事は、「この仕事は佐藤さんに頼もう、この仕事は鈴木さんに頼もう」というやり方で進められてきた。どこの国にいっても経営企画系の業務が属人的なことは同じだが、日本では現場まで、この方式でやってきた。ここが一つのポイントだ。

ところが、PMBOK(R)の仕事の仕方は、「Aさん、Bさん方式」である。つまり、誰に頼んでもできるようにするというのが基本にある。ただし、マニュアル化ではない。ここが二番目のポイント。あくまでも、「独自のプロダクト、サービス、所産」を生み出すのがプロジェクトであり、そのための作業プロセスはマニュアル化はできない。


◆プロセスは作業マニュアルではない

ここでもう一つ考えておかなくてはならないのは、「プロセスマネジメント」である。
マニュアル化をすることができないが、プロセス(手順)を決めることはできる。

手順とは、設計手順であったり、開発手順である。手順はあくまでも概念的なものであり、作業計画ではない。したがって、個々のプロジェクトでは手順に従って、具体的な作業の計画を作らなくてはならない。作業の計画や実行を支援するのがプロセスであり、プロセスマネジメントである。

ソフトウエアプロセスなどで、プロセスマニュアルがあるので計画はおおざっぱに作ればよいと言っている組織があるが、これは東芝が80年代に言い出した「ソフトウエア工場」的な発想で、そのようなやり方で間に合うのであればプロジェクトマネジメントは必要ない。

ちょっと話が脱線するが、なぜ、ソフトウエア開発にプロジェクトマネジメントが必要かというのをきちんと理解しようとすれば、MITのマイケル・クスマノ博士の2冊の著書を読み比べてみるとよい。一冊はソフトウエア工場に代表される80年代のニーズへの対応であり、もう一冊はインターネットが普及した後の90年代後半以降のソフトウエアニーズに対する要求である。両方とも「組み込みソフト」やソフトウエアパッケージなど、ソフトウエアそのものが付加価値になるものを取り上げた本だが、プロセスの持つ意味合いが全く変わっていることがわかる。

マイケル・クスマノ「日本のソフトウェア戦略―アメリカ式経営への挑戦」、三田出版会(1993)

マイケル・クスマノ「ソフトウエア企業の競争戦略」、ダイヤモンド社(2004


◆マニュアル化できなければ、計画ドキュメントはたくさん必要

さて、もう一度、本線に戻る。

ソフトウエアの例を考えてみてもわかるにように、マニュアル化のできない分野で誰でも作業ができるようにするには、相当細かな計画(ドキュメント)が必要になる。
これ自体を否定する人はいないだろう。それを計画として準備した上で、Aさん、Bさんに作業をしてもらうという発想なのだから、当然のことながら、ドキュメント量は膨大になる。過剰管理でも何でもない。

では、これをなぜ、過剰管理と感じるのだろうか?ここがこの議論のポイントだと思われる。

日本企業である程度の期間仕事をしてきた人であれば、この問題に対して作業者のスキルを上げることによって、ドキュメントや計画時間を減らすアプローチが効率的だとすぐに気づくだろう。実際にプロセスマネジメントの活動にしても、作業者のスキルを重視する傾向がある。


◆日本企業と米国企業ではマネジメントの「パラダイム」が違う

つまり、日本の企業は、米国のように人間とスキルを徹底的に切り離してしまおうとは考えていない。その成功例がトヨタ自動車である。トヨタ自動車は、グローバル展開において、初期の失敗経験から、マニュアル化だけではなく、作業者のスキル向上との合わせ技を模索し、成功している。逆にこの発想にとらわれて失敗してきたのがオフショアである。オフショア展開は、国にもよって違うが、著者の経験でいえば、中国であればPMBOK(R)的な発想でやらないとうまく行かない。現地リーダーに過剰な期待をしても、無理だ。

日本企業のPMBOK(R)に対する抵抗の本質は、ドキュメント作成の量ではなく、実はこのスキルの形式化にあるように感じる。

だとすれば、PMBOK(R)的なマネジメントを導入してもうまく行かないものを改善でなんとかしようという発想は一旦止めた方がよい。「パラダイム」が違うのだから、いくら改善しても改善でどうにかなるような話ではないし、最初に馴染まなかったことが馴染むとは思えない。現に、PMBOK(R)の導入をして10年近くなる組織でも、この問題はくすぶっているし、組織によってはドキュメント作成が形骸化している。

スキルを人から切り離すかどうかというのは、実は現場レベルで決められることではない。マクロな生産体制の議論も含めて、経営戦略である。その意味で、そろそろ、しっかりとこの問題を考えてみる時期に来ている。

この問題も戦略ノートのスレッドにしていく(まだ、プロジェティスタ問題などいくつかのスレッドが走っているが)。

◆関連するセミナーを開催します
━【開催概要】━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ◆「コンセプト力」でプロジェクトを動かす
    〜コンセプチュアルプロジェクトマネジメントの進め方      ◆7PDU's 
  日時:【2日版】2017年 12月 21日(木)〜22日(金)  10:00-18:00(9:40受付開始)
     【1日版】2018年 01月 19日(金)        10:00-18:00(9:40受付開始
  場所:国際ファッションセンター(東京都墨田区) 
  講師:好川哲人(エム・アンド・ティ コンサルティング代表)
  詳細・お申込 http://pmstyle.biz/smn/conceptual_pm.htm
  主催 プロジェクトマネジメントオフィス,共催PMAJ
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
  【カリキュラム】                     
  【2日版】
   1.コンセプト力をモノにする
    1-1 プロジェクトに必要な「コンセプト力」とは
    1-2 構造化・概念化・直観で本質を見抜く
    1-3 コンセプチュアル思考によるコンセプト作成
    1-4 コンセプチュアル思考でプロジェクトを設計する
    1-5 コンセプチュアル思考でチームを動かす
   2.コンセプト力でプロジェクトを動かす
    2-1 目的・目標の設定
    2-2 要求の洞察
    2-3 マネジメント計画の策定
    2-4 ステークホルダーマネジメント
    2-5 トラブルの本質的な問題の見極め
    2-6 統合マネジメント

  【1日版】
   1.プロジェクトに必要な「コンセプト力」とは
    1-1 「コンセプト力」とは
     1-2 コンセプチュアル思考によるコンセプト作成
   2.コンセプト力でプロジェクトを動かす
    2-1 コンセプト・目的・目標の設定
    2-2 要求の洞察
    2-3 計画の策定
    2-4 統合マネジメント  
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
前の記事 | 次の記事 | 記事一覧
著者紹介
好川哲人、MBA、技術士
株式会社プロジェクトマネジメントオフィス代表、PMstyleプロデューサー
20年以上に渡り、技術経営のコンサルタントとして活躍。プロジェクトマネジメントを中心にした幅広いコンサルティングを得意とし、多くの、新規事業開発、研究開発、商品開発、システムインテグレーションなどのプロジェクトを成功に導く。
1万人以上が購読するプロジェクトマネジャー向けのメールマガジン「PM養成マガジン(無料版)」、「PM養成マガジンプロフェッショナル(有料版)」や「プロジェクト&イノベーション(無料)」、書籍出版、雑誌記事などで積極的に情報発信をし、プロジェクトマネジメント業界にも強い影響を与え続けている。

メルマガ紹介
本連載は、「PM養成マガジン」にて、連載しております。メルマガの登録は、こちらからできます。
スポンサードリンク