参加していないソフトウェア開発プロジェクトの事後分析方法①
PM は、製品開発を終えた後にも仕事があります。
プロジェクトの事後分析をして、ノウハウを形式知にして残し、問題点の改善策を提案し、改善のための計画を立てます。
しかし、ときとして自分の参加していないプロジェクトの事後分析を任される場合があります。
何回かに分けて、その時の経験を記事にしようと思います。
自分の知見を整理する意味も込めて。(^^)
《「振り返り」の議事録を調べてみよう》
私は、プロジェクトの分析を始める前に、その組織の過去の「振り返り」を調べてみます。
【振り返り】
現場のエンジニアたちが、自分たちの業務を振り返り「良かった点」「悪かった点」などを洗い出す一連の作業、または話し合い。
事後分析の一環として行われる。
過去の「振り返り」の議事録を見ることで、発生している問題が
プロジェクト固有の問題なのか？
組織に起因する問題なのか？
を見極める手助けになります。
◎メンテナンスを任されたシステムの「反省会」
まだ、肩書がエンジニアだった頃の話です。
（PL と称してエンジニアがプロジェクト管理をすることは、ざらです😅）
転職したばかりの私は、リリース済みのシステムのメンテナンスを任されました。
そして、その会社では、まさに終了したプロジェクトの「反省会」が行われている最中でした。
今では「振り返り」という言葉が定着していますが、当時はこの「反省会」を使っている組織が多くありました。
事後分析は、犯人捜しではありませんし、”ごめんなさい” をする場でもありません。客観的に問題点を洗い出し、具体的な改善策を講じるための作業です。
「反省会」という言葉は相応しくないため、徐々に使われなくなっていきました。
「反省会」という言葉が気になって、私は議事録を見てみました。
「もっと～～すればよかった」
「～～したのがよくなかった」
「～～に気付くのが遅れた」
そこには、エンジニアたちの多くの反省が列挙されていました。
ただ、ここまでは問題ありません。エンジニアたちの ”気付き” を洗い出すのは、事後分析の基本です。
ただ、”反省した” だけで終わっているのです。
これらの反省は、次に生かされることなく埋もれていきました。
実は、この職場には以下の問題がありました。
【見つかった問題】
・明文化された開発プロセスを持っていない。
（または、プロジェクト立ち上げ時に明文化していない。）
開発プロセスがなければ、当事者たちが
「開発プロセスのどこに問題があったのか？」を分析することは困難です。
開発プロセスを明文化し、改善目標 を計画書の項目に加えておくだけで、開発者たちも自然と「改善策」を立案するようになっていきます。
◎品質に問題を抱えるクラウドサービス
肩書きが正式に PM になってから、クラウドサービスの改善に携わることがありました。
過去の経験に習って、私は「振り返り」の議事録を読んでみました。
定期的に振り返りが行われ、議事録が残っている。
改善案はタスク化され、管理されている。
この辺は、問題ありません。
しかし、以下のようになっていました。
最近、振り返りが行われていない。
改善案の（特に品質に関する）タスクが放置されている。
この組織には以下の問題がありました。
【見つかった問題】
・品質を専門に管理する担当者がいない。
テストチームは存在しているのですが、開発者が管理を兼任していました。
品質の専任担当者がいなければ、品質に工数が割かれません。
おそらく、以下のような順序で悪化していったと思われます。
開発者が空いている時間で品質を管理
繁忙期に品質のタスクが後回しになる
不具合が多くなり余計に時間が無くなる
振り返りを行う時間も無くなる
私は、品質の専任担当者を新設し、テストチームをその下に配置するよう進言しました。そうすることで、少なくとも品質の工数が開発者の都合で削られることはなくなります。
《まとめ》
詳細な分析をする前に、まず以下のことを確認しましょう。
その組織に、改善策を実施する土壌があるのか？
でなければ、いくら事後分析をしても放置されるだけです。
「振り返り」を行っていない組織は論外ですが（まずは実施しましょう😅）
議事録を確認するだけでも、その組織が抱えている構造的な問題点がある程度分かります。
◇「振り返り」が、ただの「反省」で終わっていた
⇒ 改善策を次のプロジェクトに組み込むプロセスを構築。
◇ 改善策が放置されていた
⇒ 改善のための工数が削られない体制を構築。
まずは、改善が実施される仕組み作りが大切です。
(2024-12-23 追記)
続編を公開しました。