SI開発のレビュー文化を変えよう

 ジョイ・インクを読んでいるんですが…ちょうどこの辺り。

これまで経験してきた中でこれは参考になるかもしれないと思って書いているエントリの中のプラクティスがこの本に散りばめられている感じがしないでもないのです。

ジョイ・インクでは組織として回しているところもあるので洗練度合いは濃淡があるのは当然としても、プロジェクトマネージャやマネージャをそれなりに経験しているとエンジニアはだいたい同じようなことを考えるのだなぁ、と思うのです。

SI開発でレビューをする理由（PMの立場で）

SI開発のかったるさの一つにアウトプットの品質検証があると思うのです。でも、プロジェクトマネージャの立場だと工程毎にプロジェクトの品質要求レベルを満たしていることが次工程に突入できるクライテリアになるから現場に任せたとは言えないし、リリース後に明らかに工程毎に出さなければならない不良はその工程で出しておかないと契約形態によっては横並び点検などしなくてはならなくなった時に絶望するのでそうした容易く想定ができることは工程毎にカタをつけておきたいのです。得てして、注意が行き届かない、でもちょっと気になっていることがリリース後に不良として発現するので。

そういったこともあって、工程毎の品質を確保する、違うな、機能検証するためにレビューを全ての工程で行うのです。

SI開発のレビューがイケてない（エンジニアの立場で）

とは言え、SI開発でのレビューは「これいいやり方だぜ」というものに出会えた記憶がない…ない…。

プロジェクトの規模が大きくなればなるほど、レビューはフォーマルになるし、フォーマルになればなるほど形式ぽくなるので本来設定するレビュー観点が曖昧になるのですよね。

じゃあ、規模の小さいプロジェクトで効果的、つまり、レビュー観点に沿った指摘ができているレビューはどのくらいあるかと言えば、これもだいぶ怪しくなってくるのです。なぜならレビューができるレビューアがチームの中で限られるから。

SI開発でやりたいレビューとは

立場的にやりたいレビューは、そうそう、対象は設計書はもちろん、コードも。コードは機械に任せられるもの、例えば静的なチェックは機械に任せるとしてそれ以外の、ですが、要件をもれなくカバーしているか、実現したい機能仕様は存在するか、制約事項、前提事項は考慮されているか、そうした要件をコードに変換できているか、とやりたいことはリリース時に実現したいプロジェクトの目的がレビューを通して検証したい、のです。

レビューアの技量が足らないと、そこがすっぽりと抜けてしまって本来二の次の「てにをは」や体裁に走ってしまって本来レビューで得たい成果が得られない、と。

ライブレビューがイケてた

そう言えば、すっごく大変なプロジェクトで制約が多く、めんどくさいテーマがあって、そのときにやったレビューがライブレビュー（名前は今つけた）がイケてたことを思い出したのはジョイ・インクのペアプロが心のどこかに残っていたからかもしれません。

最近でも、セルフレビューを新規参画メンバにスキトラする際に、いかに効果的にレビューの観点を技術移転するにはどうしたらいいかを２分だけ考えてやったのがやっぱりこのライブレビューを頭で考えていることを言語化して見せるというやり方です。

■環境
外付けディスプレイとPC
■参加者
レビュースキトラしたい人、受ける人
■やり方
・ディスプレイにセルフレビューする資料を映す
・レビュー対象のコンテンツにレビュー観点でツッコミを書いていく
・書きながら、どうしてそう判断したのか観点、判断基準を示す 

こんな感じです。

前のすっごく大変なプロジェクトで制約が多く、めんどくさいテーマがあって、そのときにやったレビューがライブレビューの場合は、レビューのたたき台をスライドに作っておいて、参加メンバがそれぞれ知っていること、例えば、それを実現するならこうした制約があるから考慮が必要、とか、技術的に確立できていないから検証が必要、とかとか全員が持っている経験と知識を総動員してスライドに書き込んでいくのです。

上記のいずれのケースもレビューで検証したい目的を実現できているのです。対象が仕様書なら後者の方法（人数は必要最小限）でやればいいし、コードなら二人でやったらいいのです。

もちろん、少人数、特に二人でやる場合は、一人は経験していないと二人でダメレビューになりかねないので、先行するペアを作って何度かチームの中で経験をして、経験者を散らす工夫が必要ですけど。

ジョイ・インク 役職も部署もない全員主役のマネジメント