プロジェクトの「補助線」

【戦略ノート264】主任・係長のプロジェクトリーダー抜擢で問われるもの

本ブログは移転しました。こちらをご覧ください

◆主体性を期待する部課長と、補佐意識の主任・係長のギャップ

濱田秀彦さんという方の書かれた「主任・係長の教科書」という本を読んでいたら、面白いことが書いてあった。係長・主任とその上司である課長や部長との間には、いくつかの意識のギャップがあるという。

一つ目のギャップは、主任・係長は「上司をフォローし」というが、上司は「リーダーとして先頭に立ち、周囲を引っ張る」ことを期待している。

二つ目のギャップは、主任・係長は「期待に応えて」というが、上司は「自ら問題を発見する」ことを期待していること。

三つ目のギャップは、主任・係長は「育成をサポートする」というが、上司は「指導者として育成する」ことを期待している。

一言でいえば、上司は主体性を期待しているのに、主任・係長は上司の補佐で動く役割になろうとしている。

【戦略ノート263】ライフサイクル考

本ブログは移転しました。こちらをご覧ください

◆プロジェクトライフサイクルとは何か

プロジェクトライフサイクルという言葉がある。フィージビリティから、ハンドオーバー（引き渡し）くらいまでを指す言葉で、一般的には

（１）フィージビリティ
（２）プロジェクトデザイン
（３）プロジェクト実行
（４）ハンドオーバー

のようなライフサイクルである。たとえば、ＰＭＢＯＫ（Ｒ）が想定しているプロジェクトライフサイクルは

（１）プロジェクト立上げ
（２）体系的な準備
（３）作業の実行
（４）プロジェクトの終結

という対応になっている。

【戦略ノート262】統合マネジメントに不可欠なコンセプチュアルスキル

本ブログは移転しました。こちらをご覧ください

◆「プロジェクトのさまざまな要素」の調和を取る

ＰＭＢＯＫに統合マネジメントという概念がある。

プロジェクトのさまざまな要素を調和の取れた形に統合するのに必要なプロセス

と定義される。この表現は深い表現で、「プロジェクトのさまざまな要素」には、作業もあれば、ベースライン計画もある。さらには、プロジェクトの目標もあれば、プロジェクトの目的もある。多少、拡大解釈をすれば、そのプロジェクトの実行の背景になっている事業戦略や経営戦略も含まれるという解釈もできなくはない。

統合マネジメントの重要な活動の一つに統合変更管理がある。ベースライン計画を変更せざるを得なくなったときに、統合的に変更を考える。たとえば、自発的な理由でスケジュールが遅れてきたときに、スケジュールを間に合わせるように要員の追加をする。それに伴ってコストが増加する。これは統合変更管理ではない。ベースラインのレベルで考えると、スケジュール、コスト、スコープ、要員の４つの要素を総合的にみて、「調和（バランス）」をとる。これが統合変更管理である。

【戦略ノート261】組織的コミュニケーションでやらされ感を払拭する

本ブログは移転しました。こちらをご覧ください

◆３つのプロジェクトコミュニケーション

プロジェクトマネジャーのもっとも重要な役割を一つだけあげるとすれば、コミュニケーションマネジメントである。この持論はもう５年くらい変わらない。

プロジェクトのコミュニケーションには３のタイプある。

一つは、作業上必要なコミュニケーションである。これを手段的コミュニケーションという。要求や仕様に関するコミュニケーション、作業進捗に関するコミュニケーション、問題やリスクに関するコミュニケーションなどがこれに該当する。この種のコミュニケーションは一般にはホウレンソウと呼ばれ、プロジェクトコミュニケーションというと、これを思い浮かべる人が多い。

二つ目は、動機づけやチームビルディングを目的にしたコミュニケーションである。これは充足的コミュニケーションという。ホウレンソウがコミュニケーションが手段であるのに対して、このタイプのコミュニケーションはコミュニケーション自体が目的であるところに特徴がある。

三つ目は、組織的なコミュニケーションである。たとえば、プロジェクトの背景、戦略、戦略ゴール、あるいは、プロジェクトの目的、顧客の想いなど、メンバーが意識しなくてはならないプロジェクト目標の背景にあるものに関するコミュニケーションである。

このタイプのコミュニケーションは行われているといえば、行われている。たとえば、キックオフミーティングで、これらのことは一式まとめて話をするプロジェクトは少なくない。しかし、戦略ゴールやプロジェクト目的などは、そもそも、形式的に表現されたものを聞いてもそれで理解したということにはならない。それらがプロジェクトのメンバーの活動と結びつき、腹に落ちてはじめて理解できたといえる。

【戦略ノート260】大規模プロジェクトのマネジメントには概念化スキルが不可欠

本ブログは移転しました。こちらをご覧ください

◆マネジャーの３つのスキル

ハーバード大学教授のロバート・カッツは、マネジャーの能力を

（１）テクニカル・スキル、
（２）ヒューマン・スキル
（３）コンセプチュアル・スキル

の３つに体系化した。

テクニカルスキルは業務スキルで、プロジェクトマネジャーであれば、ＰＭＢＯＫのようなものだ。ヒューマンスキルは、コミュニケーションスキル、交渉スキル、モチベーションスキルなど、人間力に相当するものだ。コンセプチュアルスキルは概念化スキルとも呼ばれ、物事を概念化して捉えたり、抽象的に物事を考えたりする能力のことである。

【戦略ノート259】アクティブ・ノンアクションと概念化スキル

本ブログは移転しました。こちらをご覧ください

◆アクティブ・ノンアクションとは

アクティブ・ノンアクションという概念がある。２年くらい前に、プロジェクトの補助線ブログにこんな記事を書いたことがある。

アクティブ・ノンアクションという問題

簡単にいえば、「忙しいけど、忙しさに見合う成果がでない」現象をいう。スマントラ・ゴシャール先生が著書『意志力革命』で言及し、目的を伴う意識的行動をとっていないことがその原因だと指摘している

確かに、このような現象の原因に目的意識の欠如があるというのはその通りだと思うが、では、目的意識の欠如を引き起こす原因はなんだろうか。

【戦略ノート258】失敗を重ねるプロマネに欠落する「概念的思考力」

本ブログは移転しました。こちらをご覧ください

◆エンジニアの一流と超一流の違い

エンジニアは「ものごとを具体的にモノで考えてナンボ」という商売である

と思われている。機械のエンジニア、プラントのエンジニア、ケミカルのエンジニア、ＩＴのエンジニアなど、一流のエンジニアはすべてものごとを具体的に考える能力にたけている。

しかし、具体的に考えるだけでは、「超一流」のエンジニアにはなれない。あなたの周囲にもし、超一流のエンジニアだと思われる人がいれば、観察してみてほしい。必ず、ものごとを概念的に考えている。概念的に考えた上で、具体的な設計に落としている。なぜ、概念的に考えるのか？それは、新しいことを考えるには、理論や智慧に立ち返る必要があるからである。理論のレベルで考えて、問題を解決し、それを具現化し、具体的なものにしていく。つまり、理論という人類の共通の智慧を活用できない限り、超一流のエンジニアにはなれない。

そもそも、エンジニアの主業務である設計とは概念的な仕事である。にもかかわらず、具体的な思考だけでも優れた設計ができるには、訳がある。知識と呼ぶものである。知識にもいろいろあるが、一番簡単なものは、事例である。設計であれば事例を参考にして設計するので、具体的な思考だけでも設計できる（そこに、特徴をみた事例の選定とか、カスタマイズのところなどに、概念的思考のスパイスを振り掛ければ十分だ）。

ただ、これでは歯が立たないことがある。まったく新しいものの設計だ。いままで、企業では、この部分は超一流のエンジニアが担当していた。そして事例ができれば、一流のエンジニアでもそれを知識として使って設計ができるようになる。

僕がエンジニアだったころにそんなことを考えていた。もちろん、自分ひとりでその境地に達したわけではなく、会社で先輩からいろいろと聞かされたり、本を読んだり、大学の先生との付き合いの中でそんなことを聞いたりした。中でも、人工知能の開発の仕事に従事したときに、頭の整理ができたように思う。

しかし、このような構図はもう通用しなくなった。新しいものがどんどん求められるようになってきた。イノベーションだ。すると、新しいものを設計しなくては一流のエンジニアの地位は危うい。

━━[PR]━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
概念的思考力を身に身につけたい人に！
「プロジェクトリーダーのためのコンセプチャルスキル強化講座」
http://www.pmstyle.biz/smn/conceptual.htm
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

【戦略ノート257】プロジェクトの上位管理者考（３）～経営へコミットするとは

本ブログは移転しました。こちらをご覧ください

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

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

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

という指摘があった。

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

【戦略ノート256】プロジェクトマネジメントチーム

本ブログは移転しました。こちらをご覧ください

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

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

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

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

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

【戦略ノート255】プロジェクトの上位管理者考（２）～現場力と組織力

本ブログは移転しました。こちらをご覧ください

◆売り手市場と現場力

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

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

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

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

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