そうだ 案件、振り返ろう。

はじめに

ふと気づくと、2023年も残り数日。皆さまは、年の終わりに振り返りをする習慣はあるでしょうか？

私はないです（ないんかい）。なのですが、参加していたプロジェクト¹が少し前に終了したという事情もあり、今年は忘れる前に振り返りをしてみようと思ってます。

そして、「振り返り大事だとは思うけど苦手なんだよな...進まんのよな...」と毎度感じている自分のためにも、振り返りを進めるためのポイントをまとめてみました。
同じような思いを抱えている方に、ちょっと役立つ記事になれば幸いです！！

記事の概要

この記事では、プロジェクトの振り返りを進めるために役立つポイントをまとめています。

• なぜ振り返るの？（モチベーション・やる気を高める）
• 何を振り返るの？（フォーマットを決める）
• どのように振り返るの？（具体的な進め方を知る）

の3点構成となっており、そもそもやる気が出ない方は初めから、フォーマットで困っている方は途中から、進め方のヒントが欲しい方は最後から、もしくは気が向いたところからお好きに読んでもらえればと思います。

「プロジェクト」に関して「個人」の振り返りを進めるポイントをまとめています。1年の振り返りや目標に対しての振り返りをしたい場合、チームでの振り返りをしたい場合は、違う観点や進め方が必要かもしれません。

なぜ振り返るの？

「振り返りって大事だよね」「振り返りをしなさいと言われたからやろう」、という漠然とした起点でも着手しようという気にはなります。ただ、思ってるけど進まない。あるあるではないでしょうか？（あるある）

何故それをやるのか、自分が納得できる目的や意図があると、振り返りを進めるための動力源になったり、具体的に何を書けばいいのかを想像しやすくなり、手を進めるきっかけが増やせるような気がしています。

私の中では、振り返りを行う理由は3つあります。

1. 自分自身の変化・成長を確認するため
2. 今後の成長の道筋・方向性を決めるため
3. 人に成長を伝えるため

1. 自分自身の変化・成長を確認するため

当たり前じゃんという声も聞こえてきそうですが、まず第一の目的はここかなと思います。
変化・成長を確認する事自体が大事というよりは、成長した事がわかると嬉しいよね、更に頑張ろうって思えるよね。というのが大事なポイントです。

ゲームに例えてみましょう。
あなたはポ○モンXXXを遊んでいますが、バグで自分の相棒のレベル、HP、覚えた技などの情報が一切見えないとします。ジム戦に挑むも勝てず、野生のポ○モンと戦いレベル上げを頑張って再度挑戦。1ターン分くらい早く相手を倒せるようになっている気がするが、奇しくも勝てず再度レベル上げ（上がっているかは見えない）。再挑戦でジム戦を制すが、次のジム戦は相手も強くなっており、勝てるかどうかは感覚で推しはかるしかない。。。
ポケモ○マスターになるまで、このゲーム続けられそうでしょうか？（私は途中でゲーム機を投げます）

変化・成長を確認するということは、レベルが見える状態にすることと近いんじゃないかなと思います。
実際は余裕で相手を倒せるようになっていても、レベルが見えないと直前でやめてしまうかも。できれば、その勿体無い状況は減らせると嬉しいですよね。
楽しく次の挑戦に進むために、都度振り返りで変化・成長を確認することは大事なのだと思ってます。

2. 今後の成長の道筋・方向性を決めるため

ここでのポイントは、現在地がわかっているからこそ、次にやりたいことを自分で考えられるという点です。

何かの技術を学んでいるとしましょう。自分がどこまでその技術を分かっているのかが不明な状態だと、タスクをする際などに依頼されるまま動いて必要以上のエネルギーを使ってしまうかもしれません。
それが、名前を知っているだけでまだ全くわかっていないのか、ドキュメントを読めば使えるのか、完璧にマスターしているのか、今どの地点にいるかが分かると、その先のアクションを自分で決められます。もっと極めたいからここにまだ時間を使うのか、ある程度把握できて満足なので、今後は時間を使いすぎずに新しいことに手を出してみる（困ったらドキュメントを見るか、〇〇さんに聞く事とする）のか、現在地を起点にすると次に何をしたいかを想像しやすくなります。
自分で好きなように、やりたいことを決められると思うとワクワクしてきませんか？

3. 人に成長を伝えるため

これは前の2つとは少し違った観点です。頭の中だけで振り返るのではなく、実際に書き出す場合の意義をここに挙げてみました。

後出しの背景ですが、私の所属している部署では人事考課の際に上司にプロジェクトレポート（主に案件の振り返りをまとめたもの）を提出しています。今回の「案件、振り返ろう」のきっかけも元を辿るとこれを書かなくてはいけないから。という理由があります。
ここでのポイントは、振り返りを書くことで、自分だけでなく他の人もあなたの成長を知ることができるという点です。

前述のプロジェクトレポートは、「動的なプロジェクトアサインの中でも、自ら役割や課題を設定し、能力向上に努めたか？を評価したい！」という目的で作られています。
1年の目標を初めに設定すると、アサインされるプロジェクトによってはその目標が達成できないこともあるかもしれません。プロジェクトごとに自ら課題を設定して達成の努力をすること、を評価する方針とすることで、環境の変化に関係なく全員が評価をしてもらえるような設計です。

日々の業務の中での学びや変化は、売上や稼働時間のような数字だけでは分からない部分も多いですが、振り返りとしてまとめることで、普段あなたのことを見れていない人にも努力や成長が伝わります。
あなたの上司、意外とあなたの褒めるところを探しているかもしれません。伝えてあげましょう。

こんなに頑張ってるのに課長マジわかってない！！というようなすれ違いも、振り返りを見せることでなくせるかもしれません。

何を振り返るの？

振り返りをする気持ちは高まったけど、具体的なフォーマットがなくて進められない！というあなた、安心してください。ここでは振り返りフォーマットとして、3つの観点を共有します。

1. 役割
2. 技術的なチャレンジ・学び
3. コミュニケーションにおけるチャレンジ・学び

前述のプロジェクトレポートから抜粋しているためオリジナルではないのですが、良いフォーマットなので補足をしつつお裾分けさせていただきます。（ヨイショ）

1. 役割

• 期待された役割をどう認識したか、どのような役割を自分に課したか
• やってみて、うまくいった点、想定と違った点　それはなぜだったか

プロジェクトを通しての目標や役割を意識すること、それに対して、何をして、何を学んだかを振り返るための観点です。小項目として設定された、上記の2点を振り返っていきます。

2. 技術的なチャレンジ・学び

プロジェクトの中でのハードスキルに関する向上点を振り返るための観点です。
前章の内容を引きずると、レベル・覚えた技を確認するという点で重要になってきます。

3. コミュニケーションにおけるチャレンジ・学び

プロジェクトの中でのソフトスキルに関する向上点を振り返るための観点です。
定量的には推し量りづらい、考え方や戦略・戦術的なポイントやコツを改めて確認するという点で重要なのかなと思います。

どのように振り返るの？

フォーマットが用意されていても、いざ振り返ろうとすると手が進まない。自分何も成長できていないから書くことないなぁと絶望してくる。。あるあるではないでしょうか？（あるある泣）

でも、本当に、何もしてない、変わっていないのでしょうか？

かくいう私は、過去に上のフォーマットに「特になし」と書く悲しいレポートを出したことがありますが、ちょっとやり方を変えると何かは書けたかもしれないなとも思う今日この頃です。「成長したこと」を探そうとして手が止まってしまったら、この後の方法で変化がちょっと出ないか試してみてもらいたいです。

1. 役割

• 期待された役割をどう認識したか、どのような役割を自分に課したか
  → 思いを書く。

ここは、もうシンプルに思っていること・考えていることを書く項目かなと思います。
期待があっているかどうかや、できたかどうかは気にしなくて OK です。次の項目で振り返りましょう。

• やってみて、うまくいった点、想定と違った点　それはなぜだったか
  → やったこと（事実）、結果、その結果をどう受け取ったか・どう解釈したか、を書く。

ここが役割の振り返りパートです。
まずやったことを何も考えずに書いてみましょう。その上で、それはスムーズにいったのか、問題がでたのか等の結果を書き、その結果に対する考えを書いていきます。

例

期待された役割をどう認識したか、どのような役割を自分に課したか
プロジェクトの主力人員として、メンバーをサポートしながらタスクを着実に進めていく役割

やってみて、うまくいった点、想定と違った点　それはなぜだったか
【想定と違った点】
・お客様とのやりとりはリーダーに任せつつ、タスクの把握や共有は率先して行う進め方をした。
→お客様とのやりとりも含めて対応してほしいと早々に伝えられ、期待されている役割と行動がずれていることがわかった。期待値の確認をしなかったことが原因。またリーダーの工数や状況を考慮せずに自分の役割を狭く考えてしまっていたため、相手の状況も加味して期待値を考えるようにする。

2. 技術的なチャレンジ・学び

• やったことを書き出す
  • 案件の中でどのような技術、ライブラリに触れたか
  • 書籍等で新しい知識を学んだか
• その案件で学んだ範囲を具体化する
  • どの範囲まで学んだのか（名前を知った段階、理解が深まった、ドキュメントを参照すれば使えるレベル、使いこなせる等々）

ここでも、まずはやったことを単純に書き出してみると第一歩が進めやすいかなと思います。
書籍を読んだのであれば本のタイトル、具体的に触ったライブラリやサービスがあればその名称、などを書き出します。

「技術的」なチャレンジ・学びでのポイントは、やったことを書き出した上で更に一歩踏むこみ、学んだ範囲を具体化するという点です。
案件で新しい技術に触れても、まだ理解できてないと思うと学んだ点を書きづらかったり、逆に新しい技術に触れられていない時は何も成長がないように感じてしまうことがあります。

しかし「〇〇（新しい技術）を使った → 実装はまだできないが主要な機能を把握した」、「□□(既知の技術)で、ソースコードのリファクタリングを行った → XXXという設計思想があることを知り、リファクタリングに関する理解が深まった」のように範囲も具体化することで、前の自分との違いが見つけやすくなるかと思います。

例

【チャレンジした点】
・リーダブルコードを読んだ（3/15章まで）
→命名のベストプラクティスを知り、コードレビュー観点に取り入れた。

【学んだ点】
・Material UI を使っての実装に初めて取り組んだ
→主要なコンポーネントを把握した。またスタイルのカスタマイズ方法が何パターンかあることを知り修正対応も実施した。（プロジェクトに1から導入することはできないが、導入済みのコードであれば修正やカスタマイズが行えるようになった段階）

※チャレンジした点、学んだ点どちらかだけ書くパターンもあり。また、レビューで指摘されたことを学びとして書くのもGood！

3. コミュニケーションにおけるチャレンジ・学び

• 工夫したこと、意識したことを書き出す（チャレンジ）
  • それに対する結果、その結果をどう受け取ったか・どう解釈したか、を書く。
• 指摘されたこと、知ったことを書き出す（学び）
  • それに対する学びを書く。

コミュニケーションに関しても基本的な流れは役割の振り返りと同じです。ただ、ここでは事実と学びをセットにするという点がポイントです。

当たり前のようなことが重要な学びになることもあるので、学びだけを書くと何かの受け売りのような印象を持たれてしまうこともあるかもしれません。
事実とセットにすることでストーリーが生まれ、納得や共感がしやすい学びにレベルアップできると思ってます。

例

【学んだ点】（お客様に対して）
・情報を正確に伝えることが信頼につながる
→メンバーが感染症で数日休みになることがあり、その際に診断を伝えずに日々の進捗確認で休みの旨のみ伝えていた。その状況と別タスクの進捗が当初の見込みよりも遅れることが重なり、お客様から進捗管理について問い合わせの連絡を受ける事となった。
→休みも進捗の遅れも原因を伝えたつもりで、正確に伝えられていなかったことが、お客様の不安と問い合わせにつながってしまったと思われる。逆に早い段階で状況を正確に伝えることで、相手にも事前に対策を考える余裕ができ信頼につながる。

最後に

ここまで読んでいただきありがとうございます。思った以上にポエミーな記事になってしまいましたが、頑張って読んでくれたあなたに拍手を送ります👏

個人的に、振り返りをしているとつい反省してしまったり、できてないことに目が向いてしまいがちな気がするのですが、「やったこと」をとりあえず書いてみる、とか意識的にいいことを探してみる、上手くいったことを書いてみる（自分が納得してなくても！なんなら少し誇張してるかもと思っても！）。というのは意外と大事かなと思ってます。
もし良ければ、そんなことも頭の片隅に自分の成長を褒めつつ振り返りをしてみてください。

振り返りに悩みを感じていた方に、少しでも寄り添える記事になったら幸いです。
それでは、皆さま良いクリスマス&年末をお過ごしください！！

1. タイトルでは案件と書いていますが、この記事ではプロジェクトと案件を同じ意味の言葉として使っています。 ↩