オルタナティブ・ブログ > トラパパ@TORAPAPA >

IT、特にコンサルに携わる方々を癒すメッセージを、ついでに趣味のダーツ話も交えて・・

プロジェクトの節目では必ず「ふりかえり」をしましょう。

»

仕事が一通り終わるといつも、帰宅前にカフェ等で何か飲みながら未読メールをさばきつつ、時々休憩に将棋チャンネルをみたりしています。

将棋には「感想戦」といって、終局後に対戦者同士で「ここはこうしたらよかったのかな」「ここでこうしたらどうなったの?」みたいなふりかえりをしています。

さっきまで「対戦相手」だったのに、時には一見楽しそうにふりかえりをしているようにみえます。

私達の業界仕事では、楽しそうにやれるかはわかりませんが(苦笑)、この「ふりかえり」はとても大事なことです。

私は外資系務めが長かったので、英語では「Lessons Learned」と言います。日本語では要はふりかえりのことですが、英語直訳だと「教訓」の方が意味的にはしっくりします。。

コンサルティング業は「勝負事」とは若干異なると思っていますが、関わるプロジェクトのいろんな局面で、勝負を挑むときはあります。「ここでこうしましょう」「!あー、しまった、こうじゃなくてこっちだったかーー。。」とか、判断をすることが多いから。

そこで勝負事的に「失敗」すると、次にリカバリーしないといけません。大きな失敗は時にリカバリーを不能にもします。そもそも弊社で「火消」的にプロジェクトの再建を請けるときは、まさにこの大「失敗」が先に起きていて、そのあとのリカバリーを頼まれるわけなので、大きな失敗はもう許されない、理想的には小さな失敗も許されません。

プロジェクトの「火消術」の詳細については、後日別のエントリーに書くとして、プロジェクト節目のふりかえりの仕方について、今日は基本手順を紹介します。

>プロジェクトのステータスをきちんと整理する

そもそも、「ふりかえり」は個人的にやるでもいいし、関係者で集まってやるでもよいのです。

大事なことは、「ふりかえり」をしないことは一番まずいので、何らか実施をするのがとにかく重要。

(定期的にふりかえりをする前提で)前回の節目から今回の節目にかけて、プロジェクトの推移や起きた出来事を整理します。

・順調に推移したと思っていた作業が突然トラブルに見舞われたとか

・これはやばいかなと心配していた作業が意外にも成功裏に終わったとか

例えばシステム開発プロジェクトの場合、要件定義が終わった時点であれば、定義済の要件一覧をながめ、どうしてそのように要件が固まっていったのか、どんな議論があったのか、合意形成がされるにいたるまでどんな経緯・背景があったからなのかを、だらだらやるのは非効率なので、直感的に記憶や記録をたどって整理していきます。

>プロジェクトに関わっている自身(関係メンバー含む)の行ったアクションと効果測定

その期間に自身や関係メンバーがどのようなアクションをしたのか、作業の推移をふりかえります。

ここでは、印象的なアクションしか記憶を呼び戻せないはずなので、短時間でしっかり考えて、呼び戻せた記憶の中から、どんなアクションがどんな効果(良し悪し含め)を産んだか、整理します。

効果は定量的でなくていいのです。定性的でOK。

このふりかえり作業で大事なことは、「印象的なアクションがどれだけたくさん思い出せるか」です。

多ければ多いほど、その期間の作業が充実していたことになります(ステータスが良いか悪いかは別です)。

>良かったこと、悪かった(と思う)ことの整理

ここでようやく、いわゆる教訓が纏めることができます。

関わったプロジェクトに起きたこと(=インシデント)は、既に事実化したものですから受け入れる以外にありません。それらにおいて、どうしてそのような顛末になったのかをふりかえります。

理想的には、良かったこと、悪かったことが、半々に洗い出せたら、そのプロジェクトは順調に推移しています。反省の少ないプロジェクトはかえって危ないです。のちのち何か見落としていた大事な事項でドツボにはまることの方が多い。反省事項がちゃんと成功事例くらいに一定量出てくる方が、経験的には健全です。

ふりかえりですから結果論、「たられば」上等、何が良かったのか、何が悪かったのか、どうしてそうなってしまったのか、をふりかえります。

個人的には、「あれは良かった」「それはやばかった」と、良し悪しをはっきり判定・評価できるアクションをすることが、何より大事だと思っています。

>次の節目に向けてしっかり意識すべきことの整理

こうしてそのプロジェクトの節目「期間」のふりかえりが基本終わったら、次の節目に向けて、より良い進捗がなされるように、しっかり意識すべきことがないか、整理します。

前述の例で、要件定義の結果で、要件の定義・調整状況が不十分な事項あれば、その領域は後日のシステム化作業に危ない影響を与えるリスクが高いと言えます。そこにどう備えるかを、その「ふりかえり」タイミングでだからこそ、考えることができるのです。

「プロジェクト計画」は、プロジェクトの始まり~終わりの道筋を示すものですが、だからこそこの「ふりかえり」を参考にして、適宜改訂される必要があると思っています。

さらに上段の話でいうと、「経営戦略」というのは、日々は言い過ぎですが、定期的に見直し、改定の繰り返しで成功に導いていくものです。最初にたてた戦略は、その後の外部環境変化(例えば)によって、軌道修正を余儀なくされます。それに気づかずに当初戦略の通りにオペレーションすると、大きな確率で失敗に向かうのです。私達の仕事もまったく同じです。

>他案件に参考になることがあれば共有事項としてさらに整理

こうして次の節目に向けての重要「意識事項」が整理できたら基本「ふりかえり」は完了です。

ただ、せっかくなので、このふりかえりを仲間にシェアしましょう。全部はないけど部分的には参考になることが結構あるはずです。

当該関係者を超えた「他者共有」の意識は、ふりかえり事項がどれだけ参考になるかよりも、その他者共有意識自体が、チームないし貴方自身のパフォーマンス向上に必ず寄与します。

「人間商売」である以上、自身や自分のチームが「ちゃんとやってる」と思っていて、ふりかえりの中で整理された「良し悪し」教訓は、結構に他者の活動に活きるのです。

バーターじゃないですが、自身の教訓が他者にもし活かされれば、その他者からいつか別の新しい「教訓」が参考情報としてお返しされてくるでしょう。私達の仕事はそのような「キャッチボール」で成り立っているのです。

こうして自分の考えを整理していると、基本的には個人ベースで必ずやるであろう「TODOリスト」の日々の更新作業にすら、このルーティンが活かされると思っています。

・当日1日のふりかえりを行い、残となったTODOの繰り越しを翌営業日にどう盛り込むか

・なぜ予定では消化するつもりだったのに残となったのか。翌営業日に同じようなことにならないために何を意識すべきか

・そもそもTODOが自身のパフォーマンス力に比して過大ではなかったか(冷静に作業計画をみつめる)

・自身が得た教訓を他者に共有すべきことはないか(ひいては自身の効率UPのために)

ふりかえり=立ち止まり、が高頻度で大量に行われるのは正直非効率ですが、定期的にやるべきことではあります。合理的にふりかえりをすることで、自身およびチームのパフォーマンスは必ず改善に向かいます。

そのためには、個人ベースのふりかえりと、チームでのふりかえりを計画的、定期的に行うのが良いと思っています。

皆様の何かの参考に少しでもなれば誠に幸いです。

Comment(0)