日本初！？ コードレビューのスキル・ベンチマークを作成

　奈良先端科学技術大学院大学は2010年1月30日、「ソースコード リーディングワークショップ2010」を開催する。参加者全員で同じソースコードを読み、ディスカッションを通じてソースコード読解やソフトウェアレビューの方法論を共有しあう場を提供するほか、日本IBMの細川宣啓氏、電通国際情報サービスのひがやすを氏、楽天のよしおかひろたか氏らを招いたパネルディスカッションを実施する。
　また、新たな試みとして、当日参加者に行ってもらった読解結果を基に「読解とソフトウェアレビューのスキル・ベンチマーク」を後日作成する。これは世界的にも極めて珍しい取り組みになるという。イベントに先立ち、この試みについて同大学 情報科学研究科 助教 森崎修司氏に話を聞いた。
●読解が難しいコードの特徴、レビューに必要なスキルの傾向を把握
　コスト削減とソフトウェアの品質向上が同時に求められている昨今、ソフトウェアテストよりも早期に問題を発見できることから、ソフトウェアレビュー（以下、レビュー）の認知度はますます高まっている。


　しかし、多くの企業が開発プロセスにレビューの工程を組み込んでいるものの、そのノウハウについては十分に浸透しておらず、要件定義書や設計仕様書、ソースコードといった各種ドキュメントを効率よくチェックできているとは言い難い状況にある。特に開発案件は時間との戦いになるほか、コストやリソース上の制約も大きいことから、レビューがなおざりに済まされている例も少なくない。
　こうした状況について森崎氏は、「ドキュメントが大量に存在する以上、すべてを網羅的に読むことは現実的にみて難しい。その点で、いま多くの企業は“与えられた時間内でいかに効率的に実施するか”というテーマに強い関心を寄せている。特に『実際にレビューを行う開発メンバー』『プロジェクトをけん引するリーダー層』という2つのレベルにおいて、効率的に行うためのスキル・ノウハウが強く求められている」と解説する。今回のワークショップにおけるベンチマーキングの試みも、「解決策を提示するための取り組みの一環として行う」という。
　具体的には、旧バージョンと新バージョンのソースコードを参加者らに読んで理解してもらう。新バージョンは、旧バージョンとのパッチ（差分）の形で提供される。パッチはそれぞれタイプの異なる「変更」や「追加」になっており、パッチのタイプごとに、適用して問題ないかどうかを各々の参加者に判断してもらう。その読解に要した時間を答えてもらい、統計を取る。
　そのうえで、各「変更」「追加」におけるソースコードの特徴を明らかにするとともに、それらを短時間で判断した人の属性を調べることで、「判断を誤りやすい、あるいは、判断に時間のかかるタイプの変更・追加は、このようなソースコードの特徴を持っている、といったことや、このタイプの変更・追加を早く読解・判断できた人は、こうしたスキルや経験を持っている、といった“傾向”を明らかにする」（森崎氏）という。


　「もちろん個人情報は取らず、すべて匿名で行う。集めたデータは、これまでの類似の研究に基づいて、まず最初にはずれ値を除去し、“人に依存せず、誰でも同じような傾向が認められるもの”と、“発見時間が人の属性に依存する傾向にあるもの”に明確に分類したうえで分析する。これによって、変更されるソースコードの特徴（ソースコードメトリクス）の明確化、変更を判断する際に“あると有利なスキル・知識”の分析、誰にとっても時間がかかるタイプの変更の分類などが行える。また、こうしたデータがあれば、バージョンアップに必要な工数を見積もる際の参考にもなる」（森崎氏）
　ただ、レビューに携わる人たちの間では、「読む時間は、書き手と読み手の相性によるのではないか」という見方も多い。これについても、「確かにそれは事実だが、前述のような“分類”を行うことで一定の傾向はつかめる。ソースコード読解やレビューのスキルアップを図るための指針とすることが期待できる」という。
　実際、レビューは「読む」という行為に集約されるため、スキルアップの手掛かりがなかなかつかみづらい。そこで森崎氏の所属する奈良先端科学技術大学院大学では、以前からレビューの速度とレビューアの知識、スキルセットなどとの関係を明らかにする研究活動を実施しており、「○○の類の問題指摘には、○○ の知識や○○のスキルを持っていると有利」といった“傾向”分析に努めてきたという。
　森崎氏は「今回のワークショップによって、レビューのスキルアップに必要な要件がさらに明らかになる。今回の参加者をはじめ、開発に携わるより多くの人たちに有益な情報を提供できるはずだ」と期待を寄せる。
●読み方のバリエーションを知る
　一方、『プロジェクトをけん引するリーダー層』にとっては、以上のようなベンチマークに加え、各種ドキュメントの“読み方”のバリエーションを学んでおくこともレビューを大幅に効率化する武器になるという。
　例えば、各レビューアが自分のペースで読み進める「アドホックリーディング」、レビューアによる観点のブレをなくし、偏りなくチェックする「チェックリスト・リーディング」、エラーをタイプ別にチェックするためのシナリオを用意し、それに沿って各レビューアがそれぞれ異なる観点で読み進める「ディフェクトベースド・リーディング」といった、さまざまなリーディング技法があり、それぞれにメリット・デメリットが存在する。
　森崎氏はこうしたバリエーションを示したうえで、「読み方の特性に基づいて、『この読み方を採用すると、こんな成果が期待できる』『こうした場合は、この読み方を使う』といったように、ソフトウェアの要件や仕様、あるいは開発メンバーのスキルレベルなど、そのときどきの状況に応じて最適な手段を選べると理想的だ」と話す。
●レビューに事前合意と実施エビデンスを
　ただ、森崎氏は「こうした方法論も大切だが、いま何より求められているのは、普段は会えない人たちが集い、レビューについてお互いに語り合い、情報を交換することではないか」と、あらためて強調する。
　「多くの人にとって、組織内など比較的限られた範囲の開発メンバーと働くパターンが一般的だと思うが、そうした中では“社会一般における自分の読解力やレビューのスキルレベル”を把握したり、磨き続けたりすることはなかなか難しいと思う。私自身、企業で開発者として勤めていた当時は、自分のレビューのスキルは社外ではどんなレベルなのか、ほかにはどんな視点や方法論があるのかとても知りたかった。今回のような場があれば、自分のおおよそのレベルがつかめるはず。そうした中で、何らかの気付きや発見を得てもらえると嬉しい」（森崎氏）


　また、今回のワークショップに限らず、今後についても「開発に携わる人たちが情報共有できる場の創出に努めたい」と力説する。最終的には「すべての開発関係者がメリットを享受できる方法論を提供するとともに、そのフィードバックを得られる“エコシステム”を構築していきたい」という。
　例えば現在、ソフトウェアの発注者と受注者の間で「レビューの事前合意が取れる仕組み」の設計も並行して検討しているという。これはソフトウェアの特性に応じて、例えば『追加機能の品質に関する部分のレビューは行うが、保守や拡張性に関するレビューは行わない』といった具合に『どのような問題を優先的かつ漏れなく発見すべきか』を明確に切り分け、受注者と発注者の間で“事前合意”を取るという仕組みだ。そのうえでレビューを実施することで、事前合意とそのレビュー結果を“成果物に対する一種のエビデンス”とする仕組みだ。
　「これにより、重要な問題を確実・効率的に指摘できるとともに、レビューにかける時間、コストを大幅に削減できる。また、レビューすべき内容をソフトウェアの発注者と受注者の間で明文化する仕組みがあれば、成果物に対して双方が納得できる。より多くの企業にとってレビューが真に有益なものとなるはずだ」（森崎氏）
　なお、この“事前合意”の考え方は、意思のすれちがいが生じがちなITシステム一般の受発注においても有効なことから、奈良先端科学技術大学院大学では、大阪大学とともに文部科学省次世代IT基盤構築のための研究開発プロジェクト「StagEプロジェクト」において、「ITシステム受発注に関する事前合意の仕組みや関連する法的問題について検討している」という。
　森崎氏は最後に「開発には経営層やプロジェクトマネージャ、リーダー、プログラマ、レビューア、ユーザーといった、あらゆる職級・役割の人が関係している。このそれぞれの人たちが仕事とプライベート双方の充実を望んでいる。しかし、開発の品質や効率のカギを握るレビューについてはメソッドが整備されていない」とあらためて指摘。今後も研究活動を通じて、「開発関係者の暗黙知の明文化や、新たな方法論の提示に取り組むとともに、多くの関係者らと交流を図りながら、ともにレビューの浸透を推進していきたい」とまとめた。

2010年 5月3日
参照atmarkIT