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度目なので、かかった時間に割り増しをしないといけませんが・・・。

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


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

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