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

【補助線】概念的に考える

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

◆問題解決における例

見積もりが甘かった。このアクティビティを担当する人がいない。

プロジェクトではこんな問題がよく起こる。この問題をどのように解決していくか。上位組織に要求してもすぐに対応して貰うのは難しい。スケジュール遅れは必須だ。

こんな時によくやるのが、問題を見る抽象化レベルをワンランク上げることだ。この問題は比較的簡単で、抽象化レベルを上げると、リソースが足らないということになる。すると、問題解決の方法はリソースを増やすことである。リソースには、人、モノ（ツール）、金、時間があり、いずれかを増やすという解決策が考えられる。このレベルで、たとえば、人を増やすことができなければ、金を増やそうと考えられる。その答えを具体（計画）に適用し、可能性を考える。外注することができないか、派遣のエンジニアを確保できないかなどの可能性を検討する。そして、可能であれば、その方向で問題解決をする。

できなければ、もう一度、リソースのレベルの問題解決に戻り、たとえば、時間を増やすことにして、具体に戻す。時間を増やす方法として、現在のフェーズのマイルストーンを延ばして次のフェーズで吸収することはできないか、顧客を説得することはできないかなどの可能性を検討する。

通常、人が足らなければ外注する、時間を金で買うといった問題解決方法は、こういうメカニズムで行われている。つまり、具体的な問題が出てきたときに、直接的に解決が難しい場合には、問題の抽象度を上げて問題解決の方向性を検討し、それを具体的な策に落として、検討していく。

このような問題解決をうまくする際に求められるのが、概念化能力（コンセプチュアルスキル）である。

【補助線】プロジェクトリーダーが戦略思考を求められる５つの局面

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

◆戦略とは

多くのプロジェクトリーダーは戦略は、あまり身近なものではないと感じている。それは正しい側面と、誤解している側面の両面がある。

この議論をするにあたっては、まず、戦略と戦略思考の違いを明確にしておかなくてはならない。

戦略とは、もともと、軍事用語であり、（戦争に勝つために）戦場に到達するまでの段階で用いる計画である。これに対して、戦場に部隊を送り込んだ後の段階は戦術と呼ぶ。戦術とは、戦場で部隊をどう運用するかである。

このレベルの戦略を考えると、プロジェクトは戦術であり、プロジェクトを立ち上げるまでの経営レベルの計画が戦略ということになる。ゆえに、プロジェクトは戦略上の必要性に基づいて目的が決定され、その目的を実現する活動として実施されることになる。

では、プロジェクトを立ち上げたのちはどうだろう。プロジェクトリーダーに求められるのは、基本的にはプロジェクトにおいて、人・モノ・カネのリソースをどのように活用するかに関わるものであり、プロジェクトマネジメント計画という戦術を作り、実行していくことが求められる。

【補助線】われわれはなぜ、プロジェクトで仕事をするのか

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

◆はじめに

７月１９日に「プロジェクトの補助線」でワールドカフェ「われわれはなぜ、プロジェクトで仕事をするのか」を開催した。

このワールドカフェの告知の中で、アジャイル、リーン、デザイン思考について考えるという表現をしたのだが、どういう関係があるのかと疑問を持たれた方がいた。この問題に対する私見を述べておく。

 

【補助線】情報を集めれば、真実が見えるのか？

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

◆「情報を集めれば真実が見える」は正しい？

プロジェクトマネジャーが上位管理者に対して持つ不満の一つに、報告は求めるが、フィードバックがないという不満がある。つまり、報告は求めるが、行動はしないということだ。実はメンバーの中にもプロジェクトマネジャーに同じような見方をしている人も結構、多い。

なぜ、上位管理者は情報を欲しがるのか。直接的な動機は、さらに上位に報告するために必要だということに尽きると思うが、それにしても、この行動にはある前提がある。それは、

情報を集めれば真実が見える

という前提である。ついでもいっておくと、この前提に基づく行動の中で、目につくのは、情報共有である。情報共有をすることが自分の仕事にどんなメリットがあるかを明確に説明できる人は多くないだろう。

ここで疑問に思うのは、この前提は本当に正しいのかということだ。ものを決めて、行動しなくてはならないときに、先送りするのは情報が不十分だからであることは間違いない。問題は、どの程度の情報があれば十分なのかである。

【補助線】オーナーシップの本質

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

◆オーナーシップとは

オーナーシップという概念がある。辞書を引くと、所有権、持ち主といった説明がされている。オーナーシップはさまざまなレベルに適用される概念だ。会社、プロ野球球団などのオーナーシップもあれば、会社の業務レベルのオーナーシップもある。あるいは、作業レベルのオーナーシップもあるし、少し、視点を変えれば、問題のオーナーシップという考え方もある。

会社や組織のオーナーシップというのはイメージがあると思うので、それ以外について少し、触れておく。まず、業務のレベルのオーナーシップであるが、その業務の進め方に関する決定権を持つ人である。たとえば、人事や、ファイナンス、マーケティングなどのオーナーシップはどこの会社にいっても明確だ。最近では情報システムや技術についてもオーナーシップを明確にしている会社も増えてきた。オーナーシップを持つ人は、チーフオフィサーと呼ばれ、ＣＨＯ（人事）、ＣＦＯ（財務）、ＣＭＯ（マーケティング）、ＣＩＯ（情報）、ＣＴＯ（技術）などのロールが決められている。

プロジェクトマネジメントについても、チーフオフィサーを定めている組織が増えており、ＣＰＯと呼ばれている。

【ＰＭスタイル考】第13話：プロジェクトマネジメントのオーナーシップ
http://people.weblogs.jp/pmstyle/2010/09/style13.html

【補助線】不確実な状況における意思決定

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

◆リスクと不確実性

不確実性という言葉がある。リスクではない。リスクとはその事象の発生が想定されるが、本当に起こるかどうかはわからないことを言う。リスクマネジメントでは、どの程度起こりそうかを確率としてあらわす。不確実性というのは、この確率が分からないケースである。

たとえば、プロジェクトリスクとして、プロジェクトでやらなくてはならない作業は過去に経験のあるもので、計画に対してメンバーのスキルの問題で、スケジュールが遅れる可能性があったとしよう。これは、過去の経験から類似プロジェクト（あるいは、タスク）の生産性の変動が起こる確率は予測できるので、リスクである。

ところが、その作業は全く経験がないし、過去のそのようなプロジェクトは例がないとする。すると、なにかまずいことが起こるかもしれないが、それがどのくらいの確率で起こるかすらわからない。これは不確実性になる。

【補助線】顧客から学ぶ

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

◆思い込みを捨てて、顧客から学べ

エリック・リース氏が、「リーン・スタートアップ」の中で、「思い込みを捨てて、顧客から学べ」と言っている。

「顧客の声を聞く」ことと、「顧客から学ぶ」ことはどう違うのか？

顧客から学ぶことの重要性を最初に指摘したのは、おそらく、ドラッカーである。ドラッカーは、仕事の目的や目標を決定するために

・顧客にとっての価値は何か

を明確にし、その上で、

・顧客から学ぶことは何か

を明確にするように指摘している。

【補助線】ミドルマネジャーがイノベーションを起こす方法

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

いま、イノベーションが求めらています。イノベーションを実現するポイントは

（１）トップやシニアのビジョンと熱意
（２）ミドルの創造力と行動力
（３）現場の創造力と実行力

の３つだと言われます。

イノベーションにおいて、ミドルマネジャーが中核になるのは間違いありませんが、その道は２つあると思われます。ポイントは創造です。

一つは、創造は部下に任してしまうという方法です。部下の創造力を引き出し、さらには、その実現においても部下に権限委譲し、やらせる。自分は、社内の調整や、部下の支援を中心に動く。この場合、ミドルマネジャーの創造活動は、「質問」で行われます。部下のアイデアを喚起する質問を投げていく。言い換えると、課題を見つけ、どんどん、部下に投げていき、アイデアを求め、よいアイデアにリソースを投入していきます。

もう一つは、ミドルマネジャー自身が創造の中心になることです。みずから、どんどん、アイデアを出していきます。そして、部下を巻き込みながら、そのアイデアを実現していきます。


どちらの方法がよいかは一概には言えません。管理者に求められているものによっても違いますし、業務によっても違うと思いますし、組織風土によっても違うでしょう。

立場的にいえば、前者はスポンサーです。これに対して、後者は「プロジェティスタ」と呼ばれます。

この連載のリードは、２つの連載のリードになっています。一つは、「プロジェティスタ養成講座」、もう一つは「イノベーションを生み出すマネジメント」です。

では、ぼちぼち、書いていきますので、お楽しみください。

【補助線】曖昧な責任と振り返り

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

◆責任者は社長です。

日本の組織は責任の所在がはっきりしないと言われることが多い。よく笑い話になるのが、責任者は誰かと聞いても、「何に関する責任ですか」といわれるという話だ。ＲＡＭ（責任分担表）のようなものを作って、責任分担をしているのでそのような対応になるのかというと、必ずしもそうでもない。阿吽の呼吸のもとに、そのような責任分担が行われており、責任の所在があいまいになっている。そして、責任を突き詰めていくと、社長ということになってしまう。もちろん、正常なロジックではない。現場の問題で社長が責任者というのは、責任者はいませんということに等しい。

冒頭から何を意気込んでいるかというと、いまさら責任論をしたいわけではない。この記事で議論したいのは、責任が不明確なのに、振り返りができるのかという問題だ。

【補助線】持論作りのエクスサイズ（加筆とまとめ）

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

メルマガ１０周年記念のアクティビティとして、持論をつくるという活動をやっている。

補助線にも何度か持論に関するコメントを書いたが、メルマガで誌上体験と称して、持論をつくるエクスサイズを行った。この補助線は、エクスサイズに加筆し、まとめたものである。

ぜひ、実践してみてほしい。

なお、持論作りのアクティビティは、現在、応募者３０名で、あと、１８名、応募があれば実施することにしている。応募はこちらからできます。

ＰＭ養成マガジン１０周年記念イベント第２弾 アクティビティ「持論を持とう！」
http://people.weblogs.jp/ppf/2012/02/jiron.html