費用対効果の高いレビューを模索する(プロセス試行編)
前回の続き。各回でやることが思ったよりも少なくなりそうですが、計画ばかりが先行すると計画したことに満足してしまいそうなので、細かく刻んでいきます。
mao-instantlife.hatenablog.com
まずは、プロセス面から改善できないか注目してみたいと思います。直接的にレビューと品質に貢献する改善ではないと思いますが、ミーティングやナレッジの運営方法などチーム内のアクションに対してある種の型をもうけて、レビューの運営を楽(気楽)にすることを考えてみます。
現状整理
先日の関するエントリで書いた開発プロセスを元に現状のレビューを整理したいと思います。
デザインレビュー
まずレビューというとたいていの人が思い浮かべる(ですよね？)デザインレビューについて。
私のチームでのデザインレビューは、各チケットごとに指定されたフェーズにおけるゲートレビューをピアレビュー形式で行います。ゲートレビューの対象となるのは、各チケットごとに以下の2段階です。
- 実装完了(ユニットテスト含む)
- 検証完了(手動テスト結果含む)
ユニットテストは元品質の関係上コストがかかりすぎて書けない箇所があるので、検証フェーズはプロセス上必須としています。検証フェーズには手動テストでなければ実施できないテストも含まれていますので、結果を残してレビュー対象とします*1。そして、このゲートレビューが完了して初めてチケットは次のフェーズに進みます。ちなみに、レビュアーの指定は完全にレビュイー任せです。
これとは別にトピックがあるときには不定期にチームレビュー形式でレビューを開催します。会議体形式で全員が集まって実施するレビューです。おおよそ以下のようなトピックがある場合に開催をしています。
- レビュアーをチーム外から呼ぶ必要がある対応
- 対応範囲が広いため周知を兼ねる場合
- 対応範囲が複雑な場合
チームに不安要素や知識のムラがありそうな場合ですね。トピックそのものが大きくなりがちなレビューです。
プロジェクトレビュー(チケットの棚卸し)
設計そのもののレビューの他に、プロジェクトとしての進捗が健全かどうかを確認するレビューを行います。これは、タスクの進捗度合いや進捗を阻害するリスクなどを確認し、対応方針を議論する場です。現在はふりかえりの時間にチケットの棚卸しという名目で実施しています。
マネージャとして確認したいことは、主に以下の3点です。
- 最新のステータス
- プロセスに問題はないか(レビューしてないのにクローズとか)
- マネジメントレベルで解決する問題がないか
結果として優先順位の変更によるスケジュールの組み替えが発生したり、手つかずのチケットへのアサインがあったり、プロジェクトの状態が変化します。定期的にプロジェクトを軌道修正して少しでも炎上リスクを低減させるために必要なレビューです。軌道修正は少しずつするに限ります。
課題
今のレビュープロセスに対して課題だと感じているところ、改善したいポイントを考えてみます。なお、今回はデザインレビューが中心です。
レビューにかけているコストは最適か？
レビューを開催するにあたって必要なコストを改善できないか考えてみます。まずはレビューにかかるコスト(人的)を洗ってみましょう。
- 日程調整コスト
- レビュー範囲の事前把握コスト
- レビューで拘束されるコスト
- 記録のコスト
- 指摘事項反映後の確認コスト
上記はどれも必要なコストの一部だと思いますが、無駄に使っていないか考えてみたいと思います。コストを削ることが目的ではなく、必要な項目に必要なだけかけているかを検討します。
1は不定期開催だと人のスケジュール調整や場所の調整などで都度発生するコストとなります。定期開催が可能であれば下がるはずのコスト(イレギュラーはあるがそれはカバーできるはず)。繰り返すお仕事はなるべく省力化したいところです。
2,3,5あたりは範囲と複雑度が広がると指数関数的にコストが増していく傾向があるように思います(あくまで実感)。レビュー対象が大きすぎてレビューに何日も必要としたり、はたまた時間が足りずにレビューを省略したりというのは、私も何度か経験がありました。省略のような形でコストを下げるのは本意ではありません。小さな単位で区切って回数を多くした方が、一回あたり理解する範囲も小さくなり複雑度も押さえられ結果としてコストが下がっていくのではないかと思います。
4の記録については、現状ではむしろ必要なコストを費やしていない、省略している傾向があります。レビューの結果をどう記録し、指摘から得られたナレッジを活用する方法が十分に整備されていないため、プルリクエストやチケットへのコメントで済ませている感じです。
レビューから属人性を排除できるのか？
直感的に答えれば「できない」でしょう。
レビューから属人性を排除するとなると、一番最初に思い浮かぶのはレビュー観点表です。ところが、抽象的すぎて意味がなかったり、細かくなりすぎてメンテもできない「死んだ」レビュー観点表はいたる所で散見できます。プロジェクトやアプリケーションごとに目的も構成も異なるため、レビュー観点表を標準的に作ろうとすることは不可能です。また、アプリケーションに標準を合わせて属人性を排除するためにレビュー観点を作ろうする場合、誰でもできるレビュー観点を作ろうとするとそれこそ仕様を網羅せざるを得なくなり、仕様書と変わらなくなります。メンテナンスが必要になるドキュメントが増えるだけです。
私は、レビューにおいてある程度の属人性は仕方がないことと捉えるべきだと思います。
じゃあ、個別のピアレビューだけで良いのかというとそれも違う気がします。属人性が出てくることと、オープンでないことは別の問題だからです*2。レビューの指摘内容やそこから得られたナレッジをオープン(チーム全員が当事者意識を持てる状態)に管理をすることで、属人性に対する効果の出にくい努力をしなくともレビュー観点の精度はチーム全体で上がっていくのではないかと。結局のところ、目の数と学びの数ではないか？と捉えています。
試行
で、今プロセスをちょっと変えて試してみています。
定期的なチームレビューの導入
毎週ふりかえりとチケットの棚卸しをしていたのですが、そのペースを少し変えてふりかえりを隔週にしました。そして、チームレビューを隔週で行うようにしました。チケットの棚卸し(プロジェクトレビュー)は毎週やっているので、気持ち的には「設計、実装フェーズ」の1サイクルは1週間のままです。
レビュー対象はメンバーの自己申告です。開始したばかりで、まだトピックがないという状況は発生していません(そのケースに対する準備は今の所してません)。時間が1時間と限られておりあまり大きな単位でできないため、品質面での中心的な活動をピアレビューに置くことは変わりませんが、定期的に開催することでプロダクトに対するメンバーの学びが進み、全体的なレビューのコストが下がれば、と思っています。
また、ふりかえりが隔週になることによって、チームのペースが変わって戸惑いが出てくるかもしれないので、その点についてはよく観察しておこうと思います。
レビュー指摘(ナレッジ)共有方法の整備を始めた
属人性を排除することはあきらめていますが、共有することをあきらめるつもりはありません。チーム全体で共有しておくべき新たなレビュー指摘について、それをナレッジとして共有できる方法の整備を始めました。
指摘内容はだいたいそのままでは個別のケースにフォーカスしすぎています。というわけでまずはそういう指摘を集めて集約し、その内容について議論できる場が必要だと感じました。redmineに案件とは別にチーム用のプロジェクトを作って、フォーカスを利用して今までに気づかなかったような指摘内容を集めることを始めました。まだ数も少なく、議論も活発ではないですが、ふりかえりやプロジェクトレビューなどを通じてうまく活用できる方法を模索していこうと思います。
企画サイドを含めたメンバー全員での設計ミーティング
レビュー時に対象を把握するためのコストを事前に支払うことをもっと突き詰めてみようという試みです。
それまでもチーム全体での設計ミーティングは案件の最初期に必ずやるようにしていましたが、そのときは私が顧客プロキシに近いことをやっていました。私も要件が持つ背景に対する理解が十二分ではない所があるので、手段ベースの考え方をしてしまうことがあります。その結果、設計ミーティングの合意事項にバイアスがかかって、要件とずれてしまう。修正コストが後払いになってしまう訳です。この後払いのコストは非常に痛い(気分的にクライアントや企画サイドの修正が効かないタイミングなので、精神的な消耗も含めて)。
最初の最初に方向性を合わせておけば、合意と理解が進んでいれば、レビュー時にもその知識が生かされるし、そもそもレビューの指摘も格段に減るのではないか、と考えています。メンバーの時間を何時間か拘束するだけでそのコストが前払いできるのであれば、十分に試す価値はあると思いました。これの効果が出るのはおそらく3〜4ヶ月後だと思います。
