PMstyle 2024年5月~7月Zoom公開セミナー(★:開催決定)

カテゴリ

Powered by Six Apart

« 【プロデューサーの本棚】ひらめきを計画的に生み出す デザイン思考の仕事術 | メイン | 【PMスタイル考】第38話:ゲームというスタイル »

2012年3月 2日 (金)

【PMスタイル考】第37話:リフレクションというスタイル

◆自分の失敗は

プロジェ4532316790クトマネジャーがプロジェクトの進め方について考えるときに、自分の失敗行動についてあまり考えようとしない(計算に入れようとしない)傾向があります。リーダーたるもの、正しい行動をし、メンバーを導いていくものであって、リーダーが失敗を認めると、メンバーに対して示しがつかないと思っている人は、意外と多いようです。

もっとも、この傾向はプロジェクトマネジャーに限らず、リーダー一般にあるようです。興味のある人は、この本を読んでみてください。多くの事例が紹介されています。

リチャード・テドロー(土方 奈美訳)「なぜリーダーは「失敗」を認められないのか―現実に向き合うための8の教訓」、日本経済新聞出版社(2011)


◆あるITプロジェクトの事例

あるITプロジェクトXの事例について考えてみましょう。プロジェクトXでは要求仕様についてプロジェクトと顧客が共同で確定していく方針でしたが、顧客の社内調整が不十分で未確定な部分が相当あります。何度か、スケジュール通りの進行を申し入れしてはいますが、積極的に取り組んでいる様子もなく、迷走気味でスケジュールが遅れてきました。

そこで、プロジェクトマネジャーのAさんはプロジェクト側で仕様を仮決めして、決めたものを顧客側で調整してもらうという方針を打ち出し、顧客に通告し、メンバーにも指示をしました。

この方針での作業が軌道に乗り始めたころ、顧客側から、仕様の取り纏め体制を整えたので従来通りの方法で進めていきたいという申し出がありました。ここで、Aさんは、もともと、初期の計画では顧客側の体制は決まっていた。今回の申し出も実現性が低いと判断し、顧客の方針を受け入れませんでした。

あなたはAさんの決定についてどう思いますか?支持しますか?しませんか?

結果として、プロジェクト側から提案を断られた顧客側は単独で公言したことをきちんと実施し、少し、遅れたものの、仕様をまとめてきました。プロジェクト側で独自でまとめたものとの調整がつかず、結局、プロジェクトは顧客側の仕様を丸のみすることになり、構築に難しい部分が出てきて、プロジェクトは大幅な納期起きれ、赤字を出して終わりました。


◆自分の行動の適切さを客観的に判断する

この問題はかなり難しい問題です。顧客側からの申し入れがあった際に乗っていればよかったのかというとそれも疑問が残ります。一方で、Aさんの判断に感情的なバイアスがあったことは明らかですし、プロジェクト終了後に本人もそれを認めています。

ここで重要なことは、顧客に何度も催促をし、プロジェクト側でやるという宣言をしてから、顧客側からの申し入れがあるまでの間、自分の行動が適切であったかどうかを客観的に判断をすることです。

行動を振り返るときに、よく、良かった、悪かったという評価をします。たとえば、顧客に催促をしたのはよかった、顧客が動かないので別の形の作業方法を提案したのはよかったといった感じです。ところが、この評価が曲者で、流れにそって断片的に評価をすると大抵は妥当だったという評価になります。

そこで、良い/悪いではなく、行動を客観的に書き並べてみて、その局面で何ができたかを考えてみることが効果的です。

たとえば、顧客に再三、スピードアップを催促したわけですが、この局面で何ができたかを考えてみます。この段階で、最初の分担にこだわらず、プロジェクトを前に進めるという視点で話し合いをすることができたのではないか、といったことです。

結局、顧客側は最終的には動いているわけですので、この局面でそのような話し合いをしていれば、状況が変わった可能性は大です。

仮にできなかったとすると、では、プロジェクト側で引き取るという判断をした局面では、他にどのようなことができたかと考えてみます。スケジュールの組み替え、体制の組み替えなどができたかもしれません。


◆リフレクション

このような振り返りを当時の状況をできるだけ詳細に思い浮かべながら行います。そして、過去の経験に照らし合わせてみます。すると、いま、置かれている状況が明確になってきます。たとえば、催促の代わりに話し合いをしていたら、状況が変わったと思われるのであれば、今の状況は適切な状況だとは言えません。そのときに、話し合いをしたとして、今、至っていることが想定される状況に近い状況を作ることが是正行動だということになります。また、ここで是正行動を取るということが新しい知恵になります。

ITの専門の人であれば、リフレクションという技術をご存じだと思います。プログラムの実行過程でプログラム自身の構造を読み取ったり書き換えたりする技術のことです。マネジメントでも、最近、リフレクションという概念が注目されています。いろいろな定義がありますが、プログラムの実行過程においてプログラムが自身を変えていくのと同じように、不安定で不確実な現場に身を置く実務者が、働きながら刻一刻と変わる状況を振り返り、その中で自分はどうあるべきかを瞬時に読み解いていくことをリフレクションといいます。

この概念に最初に気づいたのは、マサチューセッツ工科大学で組織学習の研究に取り組んでいたドナルド・ショーンです。彼は、一般企業のマネジャーから医師、科学者、建築デザイナーといった専門職までさまざまな仕事の現場を観察し、その特徴に内省があることを気づき、こうした仕事のあり方を、「行為の中の内省(reflection in action)」と名付けました。


◆リフレクションを前提にしたプロジェクトマネジャー像

リフレクションを前提に考えていくと、プロジェクトマネジャー像はまったく変わってきます。計画を示して計画通りにプロジェクトと動かすのではなく、計画を振り返りながら、プロジェクトがどうあるかを考え、計画を変えていくことがプロジェクトマネジャーの役割だと言えます。

さらに、その場合、プロジェクトマネジャーだけで取り組むより、チーム全体で取り組む方が質が高まりますので、そのようにチームを動かしていくことも役割となるわけです。

不確実性の大きいプロジェクトを動かしていくには、リフレクションが鍵になります。チームによる振り返りも含めて、自分なりのリフレクティブなプロジェクトマネジメントの方法を模索してはどうでしょうか?


コメント

コメントを投稿