費用対効果の高いレビューを模索する(課題設定編)

まだ結論はありません。チームで取り組み始めたことに対して、その取り組み内容と結果を記録するためのエントリです。連載形式になると思いますが、まず最初になぜこの取り組みを始めたのか、課題の周辺についての状況整理と課題の設定について書いてみたいと思います。

何故レビューを改善するのか？

以下の過去エントリでも説明していますが、私がマネージャになってからのここ半年間は開発プロセスの大まかなフローを身につける、作り上げることに集中してきました。現時点で開発のキックオフからプロダクトのリリースまでのタスクフローについては、かなりチームになじんできていると思います。その結果、今のチームに足りないところがより明確に見えてくるようになりました。

mao-instantlife.hatenablog.com

mao-instantlife.hatenablog.com

品質保証に対する自信が足りない

もちろん開発フローの完了基準の中に「レビューをすること」は含まれています。完了基準が形骸化しているという訳でもなく、レビュー対象への指摘も活発です。週次で行っているチケットの棚卸しでも、プチレビューのようなことは自然発生しています。

プロセス全体の中でレビューが足りていないとは思っていないのですが、レビューやテストを通じて品質保証できているか、となると若干自信がなくなってしまうところがあります。自信と言っても対外的な自信(レポート的な何か)で、これだけのことをやっているから品質は十分です、と安心してもらうためのネタが自分たちから出せると良いな、というものです。そこに、できれば数値で評価可能なものが含まれているとより安心してもらえるかと。

やりたいこと

取り組みの中でやっていきたいことは以下です。

• 最小限のコストで最大限の効果があるレビュー
• 対外的な報告にも使えるレビューの記録
• レビューの指摘をチームのナレッジと使い倒す
• 重点的に確認する箇所を選択してレビューしたい

やりたくないこと

逆にやりたくないこともあります。

• 観点チェックリストのようなレビューにしか使わないドキュメント作成
• 指摘数によるレビューの評価
• 時間を多く使ってしまうレビュー

いずれも、私の経験で形骸化してしまったレビューの要素です。

観点チェックリストはレビュアーの思考停止を招きます。本来別の観点で確認しなければならないアーキテクチャや要件の場合でも観点チェックリストに基づいてチェックをしただけで満足し、後で不具合を出すような現場がかなりありました。その不具合の後に観点チェックリストがどうなるかというと、たいていチェック項目が増えて、ダブルチェックをするようになります。害悪です。

指摘数によるレビューの評価は、指摘の質の低下を招きます。特に最低指摘件数をもうけているようなレビューだと、たいてい誤字脱字など数合わせ的な指摘が乱立し、本来指摘しなければならないことに対する議論がおざなりになります。レビュアーの指摘件数を評価に組み込んでいるとか最低ですね。議論が十分にされないままの重要な仕様がユーザの受け入れ時に爆発するとかありました。たいてい「言った」「言わない」の話になります。害悪です。

時間については、基本的にコストかけ過ぎな状況にしたくないだけです。

レビューに期待すること

改善内容について考える前に、私がレビューに期待していることについて少し考えてみます。

品質的側面

まずは静的テストとしてのレビューです。テスティングフレームワークや仮想化の普及で、動的テスト実施に伴うコストが下がっているとは言え、静的に見つけられるレベルのものは早めに見つけておきたい。間違った方向に進んでいないか早めに確認しておきたい、というのが主な期待となります。

教育的側面

もう一つは、プロダクトに対してチーム全体の理解を深めるという教育的な側面です。メンバーそれぞれ、仕様面や技術面で持っている知識の偏りがあり、その知識に従って指摘をします。レビューを通じてそれらの知識を共有してもらう、というのがもう一つの期待です。

試行しようと思っていることリスト

• レビュープロセスの明確化
• レビューの記録と活用
• メトリクス活用による重点レビュー項目の選定
• CI環境の整備