第２０７回（2009.04.14） スキルは人から切り離せるのか？
◆「佐藤さん、鈴木さん」か、「Ａさん、Ｂさん」か 新年度を迎えたので、久しぶりの戦略ノートを書くことにした。今日のお題は「スキルは人を切り離せるか」という話。 ＰＭＢＯＫ（Ｒ）流のプロジェクトマネジメントへの批判としてもっとも多いのはドキュメンテーションの量だろう。これを過剰管理だと言っている人たちもいるが、何か、勘違いしているのではないかと思う。ドキュメントの多さを過剰管理と結びつけて考える人が多いのは、上位組織に対する報告ドキュメントをどれだけ作らされているか、また、ＩＳＯやＣＭＭＩ活動でどれだけドキュメントを作っているかということを物語るものだと思う。これらは確かに過剰管理だという議論はあると思うが、それは組織の事情であってここで議論したいことではない。 ＰＭＢＯＫ（Ｒ）がどうしてドキュメントが多いかというと、「本質的に必要だから」の一言に尽きる。なぜ、必要か。ここが問題である。 日本の仕事は、「この仕事は佐藤さんに頼もう、この仕事は鈴木さんに頼もう」というやり方で進められてきた。どこの国にいっても経営企画系の業務が属人的なことは同じだが、日本では現場まで、この方式でやってきた。ここが一つのポイントだ。 ところが、ＰＭＢＯＫ（Ｒ）の仕事の仕方は、「Ａさん、Ｂさん方式」である。つまり、誰に頼んでもできるようにするというのが基本にある。ただし、マニュアル化ではない。ここが二番目のポイント。あくまでも、「独自のプロダクト、サービス、所産」を生み出すのがプロジェクトであり、そのための作業プロセスはマニュアル化はできない。 ◆プロセスは作業マニュアルではない ここでもう一つ考えておかなくてはならないのは、「プロセスマネジメント」である。 マニュアル化をすることができないが、プロセス（手順）を決めることはできる。 手順とは、設計手順であったり、開発手順である。手順はあくまでも概念的なものであり、作業計画ではない。したがって、個々のプロジェクトでは手順に従って、具体的な作業の計画を作らなくてはならない。作業の計画や実行を支援するのがプロセスであり、プロセスマネジメントである。 ソフトウエアプロセスなどで、プロセスマニュアルがあるので計画はおおざっぱに作ればよいと言っている組織があるが、これは東芝が80年代に言い出した「ソフトウエア工場」的な発想で、そのようなやり方で間に合うのであればプロジェクトマネジメントは必要ない。 ちょっと話が脱線するが、なぜ、ソフトウエア開発にプロジェクトマネジメントが必要かというのをきちんと理解しようとすれば、ＭＩＴのマイケル・クスマノ博士の２冊の著書を読み比べてみるとよい。一冊はソフトウエア工場に代表される８０年代のニーズへの対応であり、もう一冊はインターネットが普及した後の９０年代後半以降のソフトウエアニーズに対する要求である。両方とも「組み込みソフト」やソフトウエアパッケージなど、ソフトウエアそのものが付加価値になるものを取り上げた本だが、プロセスの持つ意味合いが全く変わっていることがわかる。 マイケル・クスマノ「日本のソフトウェア戦略―アメリカ式経営への挑戦」、三田出版会（1993） マイケル・クスマノ「ソフトウエア企業の競争戦略」、ダイヤモンド社（2004 ◆マニュアル化できなければ、計画ドキュメントはたくさん必要 さて、もう一度、本線に戻る。 ソフトウエアの例を考えてみてもわかるにように、マニュアル化のできない分野で誰でも作業ができるようにするには、相当細かな計画（ドキュメント）が必要になる。 これ自体を否定する人はいないだろう。それを計画として準備した上で、Ａさん、Ｂさんに作業をしてもらうという発想なのだから、当然のことながら、ドキュメント量は膨大になる。過剰管理でも何でもない。 では、これをなぜ、過剰管理と感じるのだろうか？ここがこの議論のポイントだと思われる。 日本企業である程度の期間仕事をしてきた人であれば、この問題に対して作業者のスキルを上げることによって、ドキュメントや計画時間を減らすアプローチが効率的だとすぐに気づくだろう。実際にプロセスマネジメントの活動にしても、作業者のスキルを重視する傾向がある。 ◆日本企業と米国企業ではマネジメントの「パラダイム」が違う つまり、日本の企業は、米国のように人間とスキルを徹底的に切り離してしまおうとは考えていない。その成功例がトヨタ自動車である。トヨタ自動車は、グローバル展開において、初期の失敗経験から、マニュアル化だけではなく、作業者のスキル向上との合わせ技を模索し、成功している。逆にこの発想にとらわれて失敗してきたのがオフショアである。オフショア展開は、国にもよって違うが、著者の経験でいえば、中国であればＰＭＢＯＫ（Ｒ）的な発想でやらないとうまく行かない。現地リーダーに過剰な期待をしても、無理だ。 日本企業のＰＭＢＯＫ（Ｒ）に対する抵抗の本質は、ドキュメント作成の量ではなく、実はこのスキルの形式化にあるように感じる。 だとすれば、ＰＭＢＯＫ（Ｒ）的なマネジメントを導入してもうまく行かないものを改善でなんとかしようという発想は一旦止めた方がよい。「パラダイム」が違うのだから、いくら改善しても改善でどうにかなるような話ではないし、最初に馴染まなかったことが馴染むとは思えない。現に、ＰＭＢＯＫ（Ｒ）の導入をして１０年近くなる組織でも、この問題はくすぶっているし、組織によってはドキュメント作成が形骸化している。 スキルを人から切り離すかどうかというのは、実は現場レベルで決められることではない。マクロな生産体制の議論も含めて、経営戦略である。その意味で、そろそろ、しっかりとこの問題を考えてみる時期に来ている。 この問題も戦略ノートのスレッドにしていく（まだ、プロジェティスタ問題などいくつかのスレッドが走っているが）。 ◆関連するセミナーを開催します ━【開催概要】━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 　 ◆コンセプチュアルなプロジェクトマネジメントのポイント　　　◆7PDU's　 　　　日時・場所：【Zoom】2024年 11月 05日（火）9:30-17:30（9:20入室可） 　　　　　　 【Zoomハーフ】2024年 12月 18日（水）13:00-17:00＋３時間 　　　　　　【Zoomナイト】2025年 01月 22日（水）24日（金） 19:00-21:00＋３時間 　　　　　　　　※Zoomによるオンライン開催です 　　　　　　　　※ナイトセミナーは、2日間です 　　　　　　　　※ハーフセミナー、ナイトセミナーは、事前学習が３時間あります。 　　講師：鈴木道代（プロジェクトマネジメントオフィス，PMP，PMS） 　　詳細・お申込　https://pmstyle.biz/smn/conceptual_pm.htm 　　主催　プロジェクトマネジメントオフィス、ＰＭＡＪ共催 　※Youtube関連動画「コンセプチュアルスキルとは」「コンセプチュアルスキルで行動が変わる」 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 　　【カリキュラム】　　　　　　　　　　　　　　　　　　　　　 　　　１．ＶＵＣＡ時代に必要なコンセプチュアルなプロジェクトマネジメント 　　　２．プロジェクトへの要求の本質を反映したコンセプトを創る 　　　３．コンセプトを実現する目的と目標の決定 　　　４．本質的な目標を優先する計画 　　　５．プロジェクトマネジメント計画を活用した柔軟なプロジェクト運営 　　　６．トラブルの本質を見極め、対応する 　　　７．経験を活かしてプロジェクトを成功させる ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
前の記事 | 次の記事 | 記事一覧
著者紹介 好川哲人、ＭＢＡ、技術士 株式会社プロジェクトマネジメントオフィス代表、PMstyleプロデューサー ２０年以上に渡り、技術経営のコンサルタントとして活躍。プロジェクトマネジメントを中心にした幅広いコンサルティングを得意とし、多くの、新規事業開発、研究開発、商品開発、システムインテグレーションなどのプロジェクトを成功に導く。 １万人以上が購読するプロジェクトマネジャー向けのメールマガジン「PM養成マガジン（無料版）」、「コンセプチュアル・マネジメント（無料）」、書籍出版、雑誌記事などで積極的に情報発信をし、プロジェクトマネジメント業界にも強い影響を与え続けている。 メルマガ紹介 本連載は、「PM養成マガジン」にて、連載しております。メルマガの登録は、こちらからできます。
スポンサードリンク