Pull Requestにドメイン知識を載せること

最近、レビューの話でいろいろ盛り上がってましたが、あわせて考えてみた。

主にはLEANやAgileを重視している、サービス業を展開している開発現場の話しです。
また、以下ではPull Requestベースの話です。

いきなり本題ですが、技術的な実装に対するレビューのためのPull requestに関しても、User Storyを書き、そのStoryの何を行うための実装かをまとめることって、必要なんでないかなと。
ここには利点がいくつかあると思っていて、

1. レビュー対象に対して、単なるコードに対するチェックよりも本質的なロジックやそもそも論のような、より健全な議論ができる可能性がある

2. 異なるドメイン知識を持つメンバがそのpull requestをみたとしても、ある程度健全なレビューアとして参加し、新たな気づきなどを提供できる可能性がある

3. サービスを検証するための、Story Testのセットにそのままなっていく。（最終的に評価すべきStoryという意味合いです。）

3は主にテストエンジニア向けですね。

LEANやAgileの開発体制を敷く場合、コミュニケーションを重視するという話は少なからず耳にすると思います。それは確かに正しく、レビューにおいても例外ではありません。一方、それをふまえた上での本質的なレビューを、比較的規模が大きくなってきた組織においても適用するには、そのPull Requestをみて、何を親として実装や設計が進んでいるのかを理解できる必要があると思います。

つまるとこ、
– ドメイン知識
– 実装対象の親となるユーザーストーリー
– ユーザーストーリーから、なぜそういう実装を行ったのかのまとめ
がない場合、だいたいはこういう文法の方が望ましいとか、そういう話し以上の議論はできないのかなと。また、こういう議論ができると、この場合は？というような、例外処理しなければいけない箇所もだんだんと議論し始められるきっかけになったりとか。そういう効果も見込めるのなかと思います。

そして、これらの取り組みは、これから規模が大きくなっていく開発現場において、ドメイン知識を共有していく基盤になっていくのかなと思ったり。今まで、Pull Requestに載せなくても口頭コミュニケーションでまかなえてた箇所が、組織が複雑になってPull Requestに載せることが必要になったと。

少し手間は増えますが、ドメイン知識がある程度浸透してくると大きな手戻りになるような不具合の予防へつながり、組織全体としては開発速度を落とすことなく、サービスを改善できるのかかと思ったりします。

これはこれで、今度は評価するためのテストセットを作るテスター/テストエンジニアの人もある程度pull requestを追っていく、もしかしたら開発者以上に情報を追わなければいけないハードワークになる可能性もあるのかなと思えたり。

理想的には、テスター/テストエンジニアも、複数人が異なるドメイン知識を持った人たちが集まって、テスト設計や実装、実施までも協力してできる体制がしけることがいいのかなと。

テストエンジニアは、対開発者だけではなく、対非エンジニアとのコミュニケーションも当然のこと含まれるので、100人規模で2,3人、200人規模だと4,5人程度、コードも読めるくらいの、ソフトウェアテストの書籍など呼んだりある程度実施したことのある人が集まるのがいいのかなと思ったりするこのごろです。

ペアテストや、設計に対する詳細レビューとかしたい。うん・・・
何を持ってよいテストセットとするか、まで議論できるペア欲しいな。アウトプットの出力場所がない・・・