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

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

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

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

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

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

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

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

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

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

コントロールをしない関係では、信頼がその代わりを果たす。信頼で結ばれた関係を育てることができたなら、あなたがコントロールを手渡せば、渡された相手は責任ある行動をとるようになる。（シャーリーン・リー、コンサルタント）

【成分】

◆リーダーは何をどの程度コントロールできているのか？
◆コントロールするには基準と手段が必要である。
◆なぜ、戦略実行はコントロールできないのか
◆プロジェクトをコントロールする手段とは
◆コントロールできないという前提で何をすべきか
◆どのように信頼関係を築いていけばよいか
◆徹底的な情報共有に「責任」を持たせる

PMstyleのfacebookページで、「ストーリーで学ぶプロジェクトマネジメント」という連載を始めました。よろしければ、お読みください！

現在３話まで進んでいます。

第１話：プロジェクトに一体感を生み出す
第２話：目線を一つ上にして考える
第３話：プロジェクトはポジティブな逸脱をするためにある！

◆これまでの振り返り

第３回にパフォーマンスコンサルティングにおける問題解決（改善）の視点として、

（１）ビジネスニーズ
（２）パフォーマンスニーズ
（３）能力ニーズ
（４）環境ニーズ

の４つがあるという話をした。また、第４回では、問題解決の視座として、

・プロセスレベル
・戦術レベル
・戦略レベル

の３つがありうるという話をした。

◆アジャイルの前提

アジャイルプロジェクトマネジメントには、原則や価値があるが、それ以前に「前提」がある。この前提は、アジャイルプロジェクトマネジメントの手法に関わらず、つまり、ジムハイスミスのＡＰＭであって、ＳＣＲＵＭであっても同じように成り立つ。その多くは、精神的なものであり、アジャイルマインドと呼ぶことにしよう。

アジャイルマインドがもっとも象徴的なのは、リスクに対する態度（スタンス）である。プロジェクトマネジメントにとってリスクは敵である。そして、組織を上げて、徹底的にリスクと戦うのはプロジェクトマネジメントだといっても過言ではない。

アジャイルでは、リスクに対してどのような態度をとるのか？「戦わない」という態度である。もし、手元に今取り組んでいるプロジェクトのリスクリストがあれば、取り出して眺めてみてほしい。プロジェクトのタイプにもよるが、ＩＴのようなプロダクション（生産）型のプロジェクトだと、リスクの７～８割は上位組織、顧客、社内関係部門、プロジェクトメンバー、ベンダーなどのステークホルダとの利害関係がリスクの源泉になっているのではないかと思う。

パワーとリーダーシップは互恵関係にある（ウォレン・ベニス、南カリフォルニア大学・教授）

【成分】

◆パワーを有益に使うのは難しい
◆プロジェクトマネジャーのパワー
◆パワーがないとリーダーシップにはならない
◆権限によるパワーでは変革リーダーにはなれない

本当に役に立つ商品を出し続けるためには、商品を買ってくれる顧客よりも、商品を実際に使う本当のユーザの声に耳を澄ますことが大切。だから、ＣＳではなく、ＵＳを追及してきました（小宮山栄、コミー社長）

【成分】

◆コミーとユーザ満足
◆真の顧客は誰か　→　ユーザ
◆ユーザがプロジェクトマネジメントに大きな影響を与える
◆ユーザも一枚岩ではない
◆「満足させる」から、「役に立つ」に
◆コ・クリエイション

◆開発マネジメントからプロジェクトマネジメントへ

１９９０年代後半から２０００年代前半にかけて、ウォーターフォール型の開発マネジメントがプロジェクトマネジメントに発展したように、２０００年代後半から、２０１０年代前半にかけて、アジャイル型の開発マネジメントはアジャイルプロジェクトマネジメントに発展していくだろう。アジャイルプロジェクトマネジメントは、今、やっとドミナントデザインが確立されたような時期で、いくつかの方法の代表的な方法が考案されている。

開発マネジメントがプロジェクトマネジメントに進化をした理由は、「戦略価値」の追求と安定性である。より、戦略に貢献できる成果を、より安定的に生み出すためには、開発マネジメントだけでは不十分だった。

なぜ、不安定になってきたのだろうか。理由は戦略の高度化によって、戦略実行のプロジェクトが大規模化、複雑化したためである。このため、開発は安定したスケジュールでできなくなってきた。それに伴って、品質が不安定になり、結果としてコストが暴れるという現象が起こるようになってきた。

そこで、プロジェクトマネジメントによって安定したスケジュールを取り戻し、品質を安定させ、コストを予算内に収めようとした。そのためのヒーローは、リスクマネジメントと、コミュニケーションマネジメント、および、統合変更管理（統合マネジメント）である。

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

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

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

という指摘があった。

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

◆問題をどう見るか

前回、コミュニケーションの事例に基づき、パフォーマンス改善には

（１）ビジネスニーズ
（２）パフォーマンスニーズ
（３）能力ニーズ
（４）環境ニーズ

の４種類の視点（ニーズ）があり、どこがもっとも重要なニーズであるかを見極め、そのニーズに対して手を打っていく必要があることを説明した。

しかし、この話はそんなに単純な話ではない。仮に、事業部長がＰＭＯに相談したとしても、必ずしも、事業部長の言い分だけを聞いておけばよいとはならない。研修とパフォーマンスコンサルティングの違いはこれまでに述べてきたが、この違いは単に活動の違いだけではなく、問題の見方、言い換えると問題のオーナーの違いでもある。

実は前回のコミュニケーションの問題もそうだが、組織は問題が発生したときに、「下」の問題だと考えたがる。たとえば、コミュニケーションが悪ければ、現場のメンバーのコミュニケーションスキルの問題だと考えがちである。そもそも論をいえば、プロジェクトマネジメント自体、たとえば、納期の問題とか、品質の問題を現場の問題だと考えたから、導入されたものだ。

しかし、前回も述べたように、問題のとらえ方が不適切であればいくら一生懸命、問題を解決しても、本質的な問題は解決しないし、本当の問題が別の問題を引き起こすだけだ。実際に、プロジェクトマネジメントの導入はそのような失敗をしている。

これはガバナンスやメンツやいろいろな要素が絡む組織の不条理だと思うが、パフォーマンスコンサルティングではこの不条理に切り込んでいく必要がある。