Q. 開発レビューは面倒ですが取り入れた方がいいですか？

まずは開発レビューが取り入れれらない理由について考えてみましょう。

1. スケジュール調整を含めて面倒
2. レビュワーに適した人がいない
3. 開発チームがごく少人数

開発レビューを行うことは大前提です。唯一行わない合理的な理由があるとしたら3の開発チームの人数だけです。 極めて少人数のチームで開発を行なっている場合、改まってレビューの場を設けずともお互いの設計情報やステータスは詳細まで連携が取れていることがあります。特にソフトウェア開発できちんとgitのようなシステムを使っている場合、またハードウェアの開発でも図面を引く人間とオーダーする人間がわかれているような場合では、すでに日常がレビューになっています。これは非常に都合の良い状況で、私の経験則ですがチームの合計人数が6人まではそのような緊密な連携をごく自然に作り出すことが可能だと思います。 しかしながら開発チームがある程度の規模になるとそうはいきません。チームの端と端でやっていることをお互い共有するのは週一回の定例会のみ。タスク管理表や進捗状況はシステムで共有されているがお互いそんなものは見ていない。そのようなチームでいざレビュー会を開催すると多くの場合で「その場で初めてお互いの回路図を見た」ということにもなります。初見の人の指摘というものは得てして本質を射抜くことがあります。お互いの素朴な質問をぶつけ合えば実りのあるレビュー会になることは間違いありません。

課題に視点を移してみましょう。 スケジュール調整はとても厄介な課題です。これが理由でレビューが形骸化してしまうということは往々にしてあり得ます。 特定の部門の責任者が毎回調整がつかず欠席が続いたり、何度も何度もリスケになっている間に何ヶ月も経過してしまってリスケになったこと自体が忘れ去られてしまったり。 これは組織的な問題なのでそれぞれ独自に解決するしかないのですが、いくつかアイディアを示しておきます。

＜元々決まった時間を確保しておく＞

例えば「毎月第二水曜の9:30-10:00」というような形で。普段のミーティングが入っていない時間帯が好ましいです。 特にレビューすべきものが無いときはその枠はリリースします。 押さえてあるスケジュールなのでそこに別のミーティングをねじ込むことは禁止です。そこそこ製品数や案件数が多い組織では有効な方法だと言えます。

＜決まった人を確保しておく＞

これは2とも関連する話ですが、レビュワーにはある程度の経験値が求められます。それは的確な指摘をする必要があるからというだけでなく、ある種のミスのパターンを踏まえた上で常に疑った目で見る必要があるからです。 このようなことができる適任者は案外限られています。したがってその人員を前もって指名してその人間のスケジュールだけをきちんと押さえにかかることでスケジュール調整の労力を下げることができます。大企業では多くの場合でベテランエンジニアがその役割を担っていますし、場合によってはフリーランスなど外部で適材を探しておくのも良い手です。

なおレビューの実行に対して「マネージャーが厳密に管理する」「レビュー無しでは出荷できないようにシステムを構築する」というある意味罰則的なシステムでどうにか解決をはかるということも当然考えられます。その方が強制力も強いですし即効性もありそうです。しかし中規模以下の会社には負荷が高く、あまり向いていないように思います。 極力無理のない運用方法を見出すことは開発レビューだけに関わらず何かしら新しいプロセスを組織に導入する際のポイントとなります。

このポストの内容は以下の書籍の一部（原文）です。興味のある方はぜひ書籍をお求めください。

幸せなIoTスタートアップの輪郭