ごきげんよう。
私が携わった過去のプロジェクト進行のしくじりを記録に残し、
「こんなことあったよなー」
「まだここで悩んでいるのか‥」
と未来の自分が成長していることが実感できるよう、このブログに残そうと思います。
(そんなことも知らなかったのかと思うかもしれませんが、よろしければお付き合いください……。)
修正の嵐。プロジェクト進行のしくじり
あるプロジェクトに参画して半年が過ぎた時のことです。
週次の定例会議中に、
- この箇所って修正してもらったところですよね？直っていません
- このデザイン、デフォルト設定のものに戻っています
このようなご指摘が増え、成果物の品質が担保できなくなってしまいました。
ご指摘前のプロジェクト進行の流れ
- Plan ：タスクを確認、タスクの方針決め
- Do ：タスクの実施
- Report：社内で対応完了報告(作業箇所の確認をしているはず？)
- Action：定例会議の挑む
このようなPDRA サイクルで回していました。
定例会議の進捗報告時に事件は起こり続けます。
「対応箇所の確認をして報告をしているのになぜ？」
悩む日々が続きました……。
事前レビューの実施
ご指摘の傾向を踏まえ、成果物の品質検証が限定的・属人的であることが社内で指摘されました。
そのため、品質向上を目的として成果物の事前レビュー会を実施することにしました。
社内報告のみよりも、その場で確認することで
作業者が成果物に確信を得られるようになりました。
さらに仕組みに置き換えるためにチェックシートを作成し、ダブルチェックを行うようにしました。
PDRAのRや。Rがいけなかった。Cが答え。（いわずもがな）
その後はご指摘をいただくことなく、平和にプロジェクトが進んでいきました。
が……3週間ほど過ぎたある日、ふたたび事件が発生しました。今度は
- 修正の意図が正しく伝わっていなかった
- 対応の漏れが発生していた
Checkはしっかりと機能していたはずなのに。
今度は作業者のタスク理解にムラがあること、タスクの起票漏れがあったことが原因でした。
振り返りの実施
定例後に社内で振り返りを行い、全メンバーでタスク理解やプロジェクト評価を行うことにしました。
お客様の会話や意図を正しく掘り下げることは当然ですが、
属人的だったタスク理解をプロジェクト単位で行うことにしたのです。
振り返りを行うことで作業者の「こうだと思う」「こうだった気がする」=バイアスや記憶違いなどは仕組みでなくすことができます。
また振り返りの際に、プロジェクト進行自体を評価することで、
品質に対する意識が向上し、人の努力ではなく仕組みで置き換える動きが多くなったようにも思います。
振り返りの導入後はプロジェクトも円滑に進むようになり、
成果物の品質を保ちながらもスピーディにお客様に価値を届けることができるようになりました。
学び
事前レビューや振り返りなどは、アジャイルやPDCAの定型的な実施内容として
記事や書籍などに書かれていますが、やみくもにそれらを実施するのでは暗黙的な理解になりやすいです。
しくじりを経たことで、その重要性が身に沁みて理解できるようになりました。
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK
