2012/09/18

Lessons and learnedで、ついでにしておくと良さそうな2つのこと

先日、ひとつプロジェクトが終わったので、プロジェクトのまとめを行いました。
かっこいい言葉、業界用語?、それっぽい表現で言えば、Lessons and learnedを行いました。

(andは入っていませんが・・・)lessons learnedを日本語訳すると、教訓、得られた経験、学んだこと、今後どうするかの教訓といった訳が出てきます。

ということで、簡単に言えば、仕事を振り返って、改善ポイントやら何やらを整理することを言います。

どのように整理するか、その切り口などは、おそらく仕事の評価・・・ということで、どこでもやっていますし、意識の高い方達は、仕事の区切りに限らず常に意識してやっていると思いますので、その辺の細かい話はしません。

今回は、Lessons and learnedを行った際に今までとちょっと違うことをしたのですが、それが良さげだったので、軽く共有しておこうと思います。

仕事で一区切りが付いたら、ちょっと長い休みに入る・・・という方もいるかと思います。
私も今回で言えば、3連休&週の半ばにサッカーのチャンピオンズリーグがある・・・ということで、このタイミングでヨーロッパに行けば、8試合ぐらい試合が楽しめそうだ・・・という状態だったので、タイミング的には行ってもおかしくなかったです。

が、ヨーロッパに行かなかったので、ちょっと時間が取れました。
その時間で今までと違う事をしたのですが、それがなかなか良かった。

そんなお話をしていきます。

早速ですが「何をやったのか?」と言うと・・・

”プロジェクトの繰り返し”

です。

どういうことかと言うと、プロジェクトのまとめを行った際に「あの時にああしておけば良かった」「次に同じようなことがあったら、こうする」という改善ポイントが出てきます。

その改善ポイントは、次回のプロジェクトで注意して実行するのですが、そうではなく、その前に同じプロジェクトでやってみる・・・ということです。

今回の例であれば・・・。
(・・・と実例を書いていきますが、専門用語を出します。わからない方、ごめんなさい。)

プロジェクトの関係者が少ない&それぞれのタスクも項目数はそんなに多くないので、「こちらが把握していれば大丈夫かな」ということで、エクセルを使ってWBS・ガントチャートではなくリスト形式で管理していました。(WBS・ガントチャートをわざわざ作成するのも面倒だし・・・。)

が、エクセルで管理した結果、クリティカルパスが見えにくくなり、作業が遅れた結果、プロジェクト終盤で、他の作業が異常な負荷がかかる結果になってしまいました。
(細かい話をすると、関係者全員、タスクの依存関係は把握できているのですが、それぞれの作業ボリュームが見えにくかった。作業の遅れがどれだけ他に影響を与えるのかが、うまく共有できていなかった。自分が担当する目先のことは集中できているが、全体像、全体のボリュームが見えにくいので、危機感の共有が難しい。)

という反省がありました。

それを踏まえ、整理していくと、今回のプロジェクトでは、タスクを直列で進めていけば作業工数は少なくて効率的でしたが、一つの作業の遅れが致命的になる、作業品質が下がるリスクが高まっていました。

一方、事前に並列処理にしておけば、作業工数は増えるのですが、タスクが遅れる可能性を減らせた&もしかすると品質も上がっていたかもしれない・・・みたいなことがわかりました。

ということで・・・

・ガントチャートを作って、どうやってメンバーと共有するのか?
・どのタイミングで共有するのか?

などを実際に作ってみて、いろいろとシミュレーションをしました。

シミュレーションと言えば、空想妄想の域を出ないのですが、今回の場合であれば、過去の実績に照らし合わせながらなので「このタイミングだったら話ができるな」とか「その前にここを決めたり整理しておかないとダメだな」とか「他にもこういう情報が必要だよな」とか、いろいろと発見があります。

上記はわざわざガントチャートを作らなくても「仮に作ったとしたら?」と仮説ベース、想像ベースでも可能です。

が、実際に手を動かすとリアリティが出てきて、想像もしやすくなります。
自分だけかもしれませんが、せっかく手間をかけたのに、意味がないものにしたくない・・・となると、頭が働くんでしょうね、いろいろと発見が増えました。

とまあ、ごく一部の例を出したのですが、同じ様にプロジェクトのまとめを踏まえ、他のこともやっていくと、かなり理解が進みます。

それらを都度、記録していきました。


そして、プロジェクトの繰り返しを行う際に是非やっておくといい事があります。

それは・・・

”ツールの見直し”
(もしくは新しいツールの試用や比較・選定)

です。

先ほどの例では、WBS・ガントチャートはエクセルではなく、プロジェクトマネジメントソフトを使いました。

プロジェクトマネジメントソフトを使えば、計画と実行の差異を見るだけでなく、変化に対して柔軟に修正ができるんですよね。
(計画変更の際にかかる作業時間も全然違います。)

当然ですが、全体像の把握も簡単に出来ます。
(始めに作るのが面倒&時間がかかるので、その辺でどうしてもあわよくば端折ってやろうとなりがちなんですが・・・。)

さらに今回の例でいけば、情報の共有と言うのもポイントになりました。
エクセルだと、そのままWBS・ガントチャートを見せても、わかる人にしかわかりません。

従って、プロジェクト初心者の方でもわかるような形に落とし込むために、ゴチャゴチャ加工しないといけないのです。
その作業時間もバカにならないのですが、ソフトウェアならレポート機能が充実しているのでボタン一つ。

という当たり前の話もあるのですが、それより何より「今回必要だった情報(共有すべきだった情報)はレポートのどの部分か?」というのが、より鮮明に判断できるので、機能を知っている、わかっている・・・というレベルから「使える」レベルに持っていくきっかけになります。
(MS Projectと、MacのOmniPlanの2つを持っているのですが、その違いもはっきりしてくるので、使う場面がより確実になります。)

ということで、これだけではなく、ちょっと気になるツール、使ってみたいツール、他に良さそうなツールなど他のものも試してみました。

なぜ、このタイミングでツールの見直しをやるといいか・・・と言うと、実データを使えるので、使い勝手が試せるからです。

実際、機能面で言えば、どのツールも差はほとんどありません。
従って、キモになるのは、わかりやすさ、使いやすさです。

細かい話で言えば、WebツールでURLを入力した時に、リンクを自動で貼ってくれるものとそうではないもの・・・。
添付ファイルをするのに、ボタンや画面遷移が多いものと少ないもの・・・。

画面レイアウトでカラムが3個と1個のもの・・・。
ほんと些細なことですが、その辺のちょっとしたことで、わかりやすさ、使いやすさが格段に違ってきます。

これを実際のデータで試すことができるので、リアルな感覚で判断がしやすい。
テストデータをぶち込んで適当にやる時よりも数段、判断しやすいです。

今回、ツールの見直しを行った結果、プロジェクトマネジメントソフトのアップグレードとiPad版の購入などをすることにしました。
(他にもいろいろとツールを整理しました。)

新しいツールを購入すると慣れるまで時間がかかるのですが、一度、実データで試しに使っているのは心強いですよね。

ということで、時間の兼ね合いにはなるのですが、「こうすればよかったよね」だけで終わらせるのではなく、実際に「こうだったよね」とやってみるのは、それだけで良い経験です。

例えば、作業時間を測っておけば、作業工数の見積の精度をあげることもできますよね。実際は、2度目なので、かかった時間に割り増しをしないといけませんが・・・。

今後も、できるだけ時間を作って、常にパワーアップしていきたいと思います。


追伸)
ツールがなくても何とか形に持っていけるのは、良くも悪くもプロジェクトマネジメントのポイントを押さえていたり、経験があるからなのかもしれませんが、ツールを使えば、いろいろと捗るのは間違いないのは、今回とても痛感しました。

ツールは使うと言うよりも、使い倒さないといけないですね。

2012/09/03

理想のリーダー像に迫ってみる???

今回は、先日の飲み会トークを簡単に残しておこうかなと思います。

仕事を進めて行く中で「理想のリーダー像」を考えたり、人事で「誰をリーダーにするか?」などで悩んだり、一方、現場ではチームを引っ張る人というのが必ずいますが、そのような人はどんな人なのか・・・など、リーダー像に関して、ちょっとした考えるきっかけになってくれればと思います。

いきなりですが、リーダーと聞かれるとどんな人を思い浮かべますか?

人によっては「オレに付いてこい!」というリーダー像を掲げる人もいれば、縁の下の力持ち、メンバーを支えながら進めて行くサーバントリーダーシップを取るリーダー像を思い浮かべる人もいます。
(サーバントなんて聞き慣れない言葉をしれっと使ってごめんなさい。)

このようにタイプで分けて行くと様々なリーダー像が出てきます。

ということで、複数人で話をしていると人それぞれイメージが違う。
また互いの会社の話を共有していくと、ホント様々です。

その中で正解があるのか?

と言われると、おそらく全て正解なのかなと思います。

その多様性は聞いている分には新鮮で面白いのですが、何かに役立てよう、自分に取り込もうとすると、ちょっとバラバラで意味合いが見出せません。

では、どうすれば良いのか?

おそらくリーダーはざっくり下記2つを満たしてリーダーになったハズです。

・過去に仕事で目覚ましい結果を出した。
・人格的にも優れている。

この上記2つをそれぞれ評価する。
項目の数やレベル感が会社それぞれ固有にあって・・・新鮮で面白い。

評価するタイミングや方法、その深さなども含めると、どうでしょう・・・考えるべき要素が多すぎて、話を聞きながら、何かを得ようと思うと、ちょっと整理したくなってきます。

また、仮に良さげなので真似しようと思った時に、そのままそのやり方を取り込んでいいものか?

と考えると、効果も含め、ちょっと怪しげな気がしてしまいます。

そこでベストプラクティスと称したり、導入社数や事例がたくさんあれば安心して取り込めるよね・・・というのは、コンサル業界やら何やらが行う商売のやり方ですが、まあ、それってね・・・。

ということで、もう少し話を抽象化して、お互いの会話のレベルが合わないかなと思いました。

すると、ちょっと面白い質問が思い浮かびました。

それは・・・


「その人に、自分の子供を預けたいかどうか?(その人のもとで働かせたいか?)」
「それはなぜか?」


元ネタはドラッカーさんがどこかで言っていた話だったと思うのですが、これって細かい人事評価を並べるよりもざっくりと会話のレベルが揃いそうな気がします。

ということで、やってみると、なかなかに面白い。

仕事で結果も出して、人格的にも優れている・・・のに、預けたいとは思わない。
なぜなら、預ければ平均以上にはなるだろうけど、失敗を恐れず前に進むようなチャレンジはしなくなるんじゃないかな・・・など、リーダーに期待する要件が鮮明になってきます。

ここで出てきた内容と、現在の評価基準、評価指標、タイミング、方法などを見直すと、修正ポイントが見えてきたり・・・。

結局出てくる内容のレベル感はバラバラなので、話が合っているか・・・と言うと、依然としてズレているのですが、少なくとも自社に取って何が良くて、何がいらないか・・・などを判断できる一つのやり方にはなりそうでした。


この質問。
きっかけはリーダー像でしたが、他にも応用できますよね。

例えば、採用や業者の見極め。

「一緒に仕事をしたいと思う」人にすればいいよ・・・みたいな話も聞きますが、ちょっと直感的な気がします。

自分は割と「来るものは拒まず。去る者は追わず。」のスタンスだったりするので、協業などの話があった場合、一緒に仕事をしたいと先方が思っているのであれば、基本一緒に仕事をすることを前提に話をしていきます。

もし仕事を進めて行く中で障害が出てきたら、それは課題として潰して行く・・・というスタンスです。(で、実際それをしていました。)

それが「その人に、自分の子供を預けたいかどうか?」と問えば、もう少し踏み込んで考えることができるような・・・。

ドラッカーさんが言っていたと思いますが、この問いで真摯さが見えてくるような・・・。

「一緒に仕事をしたいと思う」という直感に頼ると場合によっては、善悪ではなく、損得だけで判断する可能性もあります。

それを防ぐ意味でも、この質問は良さそうですよね。

他にも周りのメンバーから「自分の子供をぜひ預けたい!」と言ってもらえるような人になる・・・と努力をすることは、のちのちリーダーになるためにも良い心がけのような気がします。
もちろんリーダーになっても常にそれは意識して努力を続けないといけないですよね。

ということで、ちょっとした質問をきっかけにいろいろと考えることが出てきたので、ちょっと備忘も兼ねて記録をしておきました。

これによって自分の今後のアクションがどう変わっていくのか、とても楽しみです。