産学連携によるソフトウェアレビュー支援活動において効果のあった取組み

エンジニアから大学研究者に転職してちょうど10年になりました。じっくりと活動を振り返ってみようと思っていたのですが、諸々の作業がありそう簡単にはいきませんでしたが、ソフトウェアエンジニアリングシンポジウム2015で本エントリのタイトルと同じ講演（技術セミナー）の機会をいただいたので、その資料を作成しつつ振り返ることにしました。

本人がどう思うかは別として運によるところも大きいと思うので、成功要因を分析することにどのくらいの意味があるのかは議論の余地がありますが、ここ10年で「あぁ、これやってて助かった」と感じた瞬間を思い出して列挙しました。ここでは、それを簡単に紹介したいと思います。研究者や支援部門の方にとってお役に立てば幸いです。

1. 課題調査
   レビューの研究に取り組む前に、実際のところエンジニアがレビューのどういうところに困っているのかをアンケートとヒアリングでサーベイしました。長い期間ではないのですが、情報通信企業でエンジニアをしていたので「自分の経験では・・」でよいのではないかと思っていました。実際に調査をしてみるともっと様々なことに困っている方がいらっしゃることがわかりました。課題を多く把握しているとテーマ設定が多面的にできるといった感触があり「助かったなぁ」という瞬間が多かったように思います。
2. 効果計測
   レビューの研究に特化した項目です。ウォータフォールの開発を前提とすると、レビューの効果はレビューではなくテスト工数の低減に表れます。手戻りが減るからです。イテレーティブな開発では、一貫性がとれていないことによる手戻りや次以降のイテレーションの拡張に効果が出ると思います。当たり前のことではありますが、このことに早い段階で気づけたことは連携の計画段階や論文の評価の章でどういう評価をするかを考える上で助かることが多かったと思います。レビューで見つける場合の修正コストとテストで見つける場合の修正コストを比較するKusumotoメトリクスというメトリクスがあり、これが大きなヒントになりました。
3. 関係者の立場を意識すること
   産学に限らずDevOpsで言われているような場をはじめどのような場でもそうなのですが、連携している方々の立場と目的を考えていたおかげで「助かった」と思う瞬間が多かったように思います。もちろん完全に把握はできないのですが、想像しない場合と比較すると適切に振る舞えることが多いように感じています。
4. アウトプットを広くすること
   研究者は主に研究の内容と論文の数により評価されることが多いです。なので、アウトプットの主軸は論文です。その点がブレないようにしつつ、機会をいただけたら書籍、記事、技術者向けの講演といった場もアウトプットの場と捉えたことは、「やっててよかった」と思った瞬間もそれなりにあるように思います。しかし、私の場合、もっと主軸をしっかり固めたいとも思っていて、この点は今後考えがいろいろ変わるのではないかとも思っています。

本エントリ公開日を起点として来週になってしまいましたが、上のような内容で2015/9/8に慶応大学日吉キャンパスで講演の機会をいただきました。シンポジウムのWebはこちら。私のセッションの概要はこちらから。

当日参加受付もありますので、ご興味があればお越しください。よりよい取組みにむけて、議論をご一緒できればと思います。このタイプの講演はあまりしていないので、私にとって貴重な場と捉えています。