はじめに
私のチームでは、数週間に1度のタイミングで、チームの皆で過去の出来事を振り返って、良かった点や改善点を挙げてチームを改善していく活動を「振り返り」と呼んで実施しています。
今回は、データをもとに振り返りをする方法の紹介です。
前提として、振り返りについて以前に2つの記事を公開していますので、よろしければ参照ください。
チームの皆が積極的に発言する楽しい振り返りにする方法として「ファシリテーターを皆に任せて楽しい振り返りに」という記事を以下で公開しています。
また、そのように全員が積極的に発言する振り返りができるようになっても、だんだんマンネリ化することがあるため、それを防止する施策として、「自分の考えたオリジナルの振り返り手法で楽しい振り返りに」という記事を以下で公開しています。
振り返りのためのデータ計測
前の章で紹介した振り返りのやり方をすれば、チームの皆が積極的に発言する楽しい振り返りになり、マンネリ化もせずに長期間続けられます。
しかし、紹介した方法は、データを用いたファクトベースの改善案を出す方法について、あまり言及していません。
そこで、まずは私のチームで振り返りのために計測しているデータを紹介します。
ちなみに以下の記事で紹介した DX Criteria という企業のDXを推進する上で活用できるガイドラインにも、「ふりかえりのテーマごとに数字を集めたり計測するなどして、ファクトベースで議論できるようにしているか。」というチェック項目があります。
よって、データを用いたファクトベースの振り返りは一般的に推奨されていると言えます。
私のチーム振り返りのために計測している「データ」は、対象のプロダクトを開発するための成果量、工数、不具合数などです。
ただし、データを用いた振り返りは毎回の振り返りで行うわけではありません。
プロダクトの大きな節目のリリースが終わった時など、年に数回だけの頻度で行っています。
(計測する規模が小さいと改善点を挙げるための分析がやりづらいため)
以下に扱うデータの詳細を説明します。
これらのデータを一つの帳票にまとめて、それを入力に改善案を検討します。
(チームはスクラム開発ですが、対象プロダクトがデスクトップアプリのため、クラウドのWebサービスでのデータ分析やFour Keysと観点が異なる点はご了承ください)
成果量
対象期間に開発した成果量として主に以下を計測しています。
- 追加・変更したプログラムのコード行数(LOC)
- 追加・変更したテストケース数
- 実現した機能価値ポイント(詳細はこちら)
工数
前提として、私のチームでは、メンバー全員がどのタスクにどれだけの工数をかけたのかを毎日入力しています。
それにより、精度の高い工数データを利用できます。
工数の入力に利用しているツールは TimeTracker NX というツールです。
以下に計測する工数を記します。
- 対象プロジェクトの工数をまず「エンジニアリング工数」「管理工数」「改善工数」に分類し、その比率を算出する
- エンジニアリング工数：エンジニアリングの作業に費やした工数。仕様書を作成したり、設計を議論したり、ソースコードを書いたり、テスト実施したりの工数。
- 管理工数：プロジェクトのマネジメントに費やした工数。計画の作成・変更、進捗管理など。毎日の朝会の工数もこちら。
- 改善工数：直接的にプロダクトを作るための作業でなく、今後のための改善活動に費やした工数。振り返りで挙がった改善活動を実施したり、新しい技術・ツール・プラクティスを試行したりなどの工数。
↑こんな感じに工数比率を過去の結果と比較(データは架空のものです)
他にも、以下の工数なども計測しています。
- エンジニアリング工数を工程ごとに計測する。ここでの工程とは、要件定義、設計、実装(コーディング)、テスト設計、テスト実施など。
- 工程ごとの工数を「作り込み」「レビュー」「レビュー指摘修正」に分けて計測する。
- テスト実施およびテストで検出した不具合修正にかかった工数比率を計測する。テストで不具合が大量に見つかると生産性が大きく低下するため、この比率を一定以下にする。
不具合数
ここでの不具合とは、各工程でのレビュー時に検出した不具合と、テストで検出した不具合の両方を指します。
レビューで不具合を登録するために利用しているツールは Lightning Review というツールです。
対象期間に検出した不具合として主に以下を計測しています。
- 工程ごとの検出不具合数
- テストで検出した不具合を原因工程別に分けた上で、原因工程ごとの不具合数
- [テスト検出不具合数 / ソースコード行数] で、追加・変更したソースコード行数当たりでのテストケース数を算出(テスト前に十分に不具合を除去できていたかを確認する目安の1つ)
改善案の検討方法
前の章で計測したデータをもとに、具体的にどんな改善案を考えると良いのか、その例をいくつか紹介します。
管理工数比率を下げる
エンジニアリング工数・管理工数・改善工数の工数比率の分析結果を見た時に、下図のように「管理工数」が多くなってきた場合は、その比率を下げる改善を検討します。
前提として、プロジェクトのマネジメントは、プロジェクトのQCDなどの目標を達成するためにやることですが、それはエンジニアリングを効率的に進めるための補助的な活動と言えます。
従って、プロジェクトが目標達成できた前提ならば、管理工数の比率は少ない方が良いです。
プロジェクトのマネジメントは、凝ったことをやればどこまででも工数が使えてしまいますが、「プロダクト開発の生産性か品質への貢献がないマネジメント活動」は意味がありません。
よく聞くアンチパターンは、「今までそうしていたから」「標準の帳票やプロセスにあるから」という理由で、意味のないことに工数をかけてしまうことです。
マネジメントで具体的に何のタスクに工数をかけているのかを確認し、その中に「プロダクト開発の生産性か品質への貢献がないマネジメント活動」がある、もしくは工数に見合わない小さな貢献しかない活動については、それをなくしたり省力化したりできないかを検討します。
そうすると、一部の会議や帳票記入の工数を削減できることがあります。
エンジニアリング工数の中で一番比率の高い工程を改善
改善するならば、できるだけ費用対効果の高いところを改善する方が良いです。
従って、エンジニアリング工数の中で、一番比率の高い工程を対象に改善案を検討するのが効率的です。
上図の場合、実装(コーディング)の工程が最も高い比率なので、その工程を改善候補にします。
あとは、その工程の中で、どのタスクに工数を多くかけていたのかを確認して改善案を考えます。
例えば、確認した結果、ブランチ開発時のコンフリクト解消に工数がかかっていたことが分かったとします。
そして、コンフリクトの解消に工数がかかった理由は、対象のブランチでリベースを1度も実施しなかったために大量のコンフリクトが発生したことだったとします。
その対策として、コンフリクトが発生するブランチを特定して毎朝 Slack に通知してくれる GitHub Actions を作成すれば、小さなコンフリクトのうちに解消することが徹底され、工数削減に繋がります。
不具合の多い工程を対象に不具合を防止する改善
効果が高くて取り組みやすい改善の1つに「レビューやテストでよく検出される不具合を作り込み時点で事前に防止する」というものがあります。
よって、一番不具合の多い工程を改善対象とします。
その工程で検出した不具合を確認して分類します。
分類した結果、類似不具合を作り込み時点で防止する対策を考えます。
例えば、実装工程の不具合を分析した結果、UIとして表示するウィンドウをリサイズしたり最大化したりした場合に意匠が崩れてしまう不具合が複数あったとします。
それを事前に防止する対策として、プルリクエストテンプレートにそういう不具合がないかをチェックする項目を追加することで、プルリクエストのレビュー前に自分でチェックして防止することができます。
レビュー工数比率が低い工程を対象に改善
工程ごとのレビュー工数比率を確認したときに、レビュー工数が極端に低い工程は、注意が必要です。
例えば、上図のように、過去と比較して要件定義のレビュー工数比率が極端に低かったとします。
要件定義のレビュー工数比率が低くても、その後の工程で要件定義が原因の不具合が検出されなければ、少ない工数で十分な品質のレビューができたので問題ありません。
しかし、後工程で要件定義の不具合が多く検出されたのであれば、レビューが不十分であるため、レビューのやり方を改善することが必要です。
もし、レビューが不十分の原因が、レビューする人が忙しくてレビュー工数が十分取れなかったのであれば、それができるよう状況に合わせて柔軟にタスクの割り当てを変えられるようなマネジメントに改善します。ただ、柔軟にタスクの割り当てを変えるためには、そもそもメンバー全員が全機能の全工程を担当できるように育成する必要があるため、そういう育成計画も合わせて行います。
テスト検出不具合数を減らす
前提として、不具合は後工程で見つけるほど、その対応に工数が多くかかります。
例えば、要求仕様の不具合をテストで検出すると、レビューで検出した場合と比較して何倍もかかると言われています。詳しくは以下を参照ください。
JASPIC SPIJapan2009 奈良隆正 「ソフトウェア品質保証の方法論、技法、その変遷」の発表資料P31
上記の理由から、不具合の中で、最も減らしたい不具合は、納入後に見つかる不具合です。
ただしリリース直後の時点ではまだ見つかっていないはずなので、リリース直後での振り返り時に減らすことを検討する不具合は、テストで検出する不具合となります。
そして、テストで検出した不具合が過去と比較して多いか少ないかを判断する目安の1つが [テスト検出不具合数 / ソースコード行数(KLOC)] で算出する値です。
これを私のチームでは「テスト検出不具合密度」と呼んでいます。
上図の場合、過去のバージョンと比較して、テスト検出不具合密度が高くなっています。
これは、テストの前に行う作り込みとレビューの品質が不十分のために、テストで多くの不具合を検出してしまった可能性が高いです。
よって、テストで検出した不具合を確認して、それらのいくつかを作り込みやレビューで事前に防止する対策を考えます。
チームの皆で改善点を挙げる
ここまでの章で、どんなデータを用いて、どんな改善案を挙げるのかを紹介しました。
改善案の例に挙げたものは、そんなに難しいことをやっているわけではありませんし、実はチーム全体の改善案を考えることは、特殊なスキルやドメイン知識がなくてもできます。
よって、これはチームのマネージャーだけが考えるのでなく、メンバー各自がデータを入力にして改善案を考えた方が、多角的な視野から改善検討されるため、大きな改善効果が見込めます。
また、近年は特にシェアドリーダーシップが推奨されています。
メンバー全員がリーダーシップを発揮し、担当者目線でなく、マネージャー目線でチーム全体に対する提案を主体的に行う方が、楽しく創造性の高いチームになりやすいです。
マネージャー目線になるように視座を上げるためには、マネージャーの立場になって様々なマネジメント活動の経験を積むことが有効です。
従って、私のチームでは、メンバーそれぞれが成果量・工数・不具合のデータを入力に、改善案を検討しています。
（視座を上げるために行っている活動は他にもありますが、本稿では省略します）
まとめ
成果量・工数・不具合数などを入力に各自が改善点を考える方法を紹介しました。
これを参考に、みんなで楽しく改善活動をするきっかけにしてもらえれば幸いです。
ちなみに私はITエンジニア向け情報誌「Software Design」の2022年5月号から「ハピネスチームビルディング」を題材に連載記事を書いています。Web上でも以下で公開しています。
X(旧Twitter)でも役立つ情報を発信しますのでフォローしてもらえると嬉しいです → @kojimadev