レビューはソフトウェア開発に何をもたらすのか

今まで製品の企画から製品化まで主体でやってきて、別の目的を達成するために、去年その時のメンバーに全てを委譲しました。

ここ一年は片手間で製品のアドバイスなどをしたりしていたんですが、ここ数か月で積み残した課題を片っ端からつぶすプロジェクトのリーダーとして作業していく中でレビューについて考察したので書き残しておきます。



こんなことを考えたきっかけは、レビューを他の製品にかかわるプロジェクト外のメンバーにやってもらって、違和感を感じたこと。


指摘事項の内容が判を押したように近視眼的かつ保守的なんですよね。


この製品は僕が一人で作り上げた世界観を短期間で僕一人がブレインとして形にしました。

プロジェクトを進めるうえで、この時は全く問題にならなかったことが今問題になりつつあるんです。


将来必ず起こり得る問題に対する早期対処が適切な時期に行えない。


なぜならレビューのその民主主義的な性格から、その課題に多くの人が気づけていない場合少数意見として排除されるからです。


レビューの時点で多くを議論する事はできませんから（離れたい自分としてはする気もありませんでしたが）、多くの反対意見が集まった時点でその対処は後回しになる。

じゃあいったいいつやるのか？と言ったら問題が表面化した時点で大慌てで対処する。


会議を減らすためにレビューにしたのが失敗でしたね。


過去、こんなジレンマには陥りませんでした。
レビューなんてしませんでしたからね。

時間はかかりましたが、説得するための資料を作って会議を実施して合意形成をしてきました。

何でもかんでもレビューすればいいという最近の吹聴はどうかなと。



こんな問題が出るのは、そもそも先にも書きましたがレビューのその民主性にあると思います。

一人一票、専門家１人と素人９人でレビューをやれば、耳触りの良い素人の意見が大勢を占めてしまい、意思決定のほとんどをかっさらっていく。


まさに、ランチェスター戦略で田岡氏が言う「アマチュアの理論の横行」状態。


レビューの実施もメンバー、対象、時期含め、きちんと考えた方がよかろうかと。