メディア

全関係者の“納得”が、レビュー成功の大前提：ソフトウェアレビュー入門（2）（3/3 ページ）

» 2009年06月25日 12時00分公開

[森崎修司，奈良先端科学技術大学院大学情報科学研究科]

レビューの「効果」を全関係者に理解してもらうために

　さて、以上の各項目に配慮することで、現実的な計画を立案できると思います。問題は、計画だけ作っても、開発関係者はなかなか実践に向けて動いてくれないことです。計画を実践したり、レビューを定着させたりするためには、前述のように、レビューの計画とともに、その効果や意義、重要性を、しっかりと認識してもらうことが必要になります。

　とはいえ、実際に計画をきちんと立てて、レビューの意義を理解してもらおうと各関係者に働き掛けたことのある人は、「合意が大切なんてことは分かってるし、計画もきちんと立てている。それでもちゃんとレビューに取り組んでくれないんだ。そう簡単に理解なんかしてくれるわけがない」と思われることでしょう。

　実は私自身、自分の研究テーマであるレビュー関連のメソッドやツールをソフトウェア開発に従事している方に使ってもらい、その効果を計測しようとすることが多いので、同じような悩みを持っています。そこで、ここでは私が試しているやり方を紹介したいと思います。

　まず、各関係者にレビュー計画やレビューの重要性を理解してもらううえで、私が最も重要と感じているのは組織風土に合わせて働き掛けることです。ここ数年で、ソフトウェア開発企業180社との相談を繰り返してきましたが、組織によって“風土”はさまざまです。

　「トップダウンで決まりさえすれば、ある程度うまくいく」「現場が了解しないと決まりごとがあっても守られない」「現場の反発があっても、支援部門が手厚く支援すれば浸透していく」「現場をよく知る中堅が納得しない限り、すぐに形がい化してしまう」といったように、あらゆるタイプがあります。

　そこで、まずはご自身の組織の特徴を考えてみましょう。具体的には、まず「過去に導入された新規の取り組み」事例にどんなものがあるのかを調べてください。「新規の取り組み」はどのような組織にも必ずありますから、参考事例に困ることはないと思います。その中から、レビュー計画に最も似たものを1つ選び、その取り組みが「どのように始まり、定着していったか」を調べ、分析するのです。

　また、そうした事例を大まかに分類すれば、“トップダウン”と“ボトムアップ”、いずれかのタイプになると思います。このうちトップダウン型の場合は、「レビューによってコスト・リスクを低減できることをデータで裏付けながら、経営層、管理層に意義を訴える」という方法を軸にすべきでしょう。その点、過去の事例を参考にしながらも、通常の稟議（りんぎ）と同じような手順で進めることが有効かと思います。

現場で信頼されている人を巻き込む

　一方、ボトムアップ型の場合、特に決まった手順があるわけではありません。なかなか難しいのが現実ではないでしょうか？そこで提案したいのが、技術面で信頼されている人や、プロジェクトリーダークラスの人を説得する方法です。あまり長い時間を掛けず、例えば、1時間半程度の少人数での勉強会を開くのです。

　忙しいメンバーを巻き込む場合には、ランチミーティングのような形態を取り、社内の会議室で弁当やパンを食べながら40分ほどで済ませる、という手もあるでしょう。説得する相手と1対1で話すのではなく、あなた以外にも1～2名、レビューに対して好意的なメンバーに同席してもらい、その場で実際に、説得相手に小規模なレビューを実践してもらうのです。内容は以下のとおりです。

エラー指摘をする
指摘したエラーが見逃された場合、後でどのくらいの手戻りを引き起こすのか、大まかな工数を想定してもらう
指摘したエラーを、その場で修正する場合の工数を想定してもらう
2と3で必要な工数を比較してもらう。可能であれば、スケジュール遅延リスクなども考えてもらう

　1では、致命的なものだけを挙げてもらうようお願いしましょう。最も重要なのは2です。後で問題を修正することによって、ほかの部分との整合性を確認、調整するためにはどのくらいの工数が必要なのか──修正を確認するためのテストの工数、回帰テストの工数などを、もれなく列挙してもらうのです（多くの有識者が集まって会議をするタイプのレビューでは、工数単価が高くなる傾向にあります。必要であれば、その点を考慮に入れてもらうのもよいでしょう）。

　そのあと、3で得た結果との比較をしてもらいます。多くの場合、2の方が3よりも工数が大きくなると思います。そのことに納得してもらうのです。そうすれば、レビュー実施に対する同意、あるいは有効なレビューの定着に、一気に近付いたといえるでしょう。

　また、レビューの題材や実施時間などは参加メンバーと相談して決めるのが一番ですが、その際は次の点に気をつけて下さい。

この場では、規模が小さいものをレビュー対象にする

　なるべく規模が小さいもの、あるいは、部分的に抜粋したものをレビュー対象に選びましょう。あくまで「効果を確認するための場」です。レビュー自体を行う場ではないことを念頭に置いておきましょう。

レビューに対して否定的なメンバーは同席させない

　例えば、「レビューを実施すると工数が増える」と考えているメンバーや、レビューで自身の作成物が批判されることを極端に嫌うようなメンバーです。そうしたメンバーとは別途、議論・説得の場を設けることにしましょう。

開発中の題材を使わない

　開発が進行しているものではなく、完了したプロジェクトの設計ドキュメントやソースコードを使うようにしましょう。オープンソースのもの、研修用のものでもよいでしょう。これも、この場の目的が「レビューの効果を理解・納得してもらうこと」にあるからです。進行中のものを使うと、「スケジュールが逼迫（ひっぱく）している」「メンバーが足りない」など、そのプロジェクトに感情移入した“感想”が引き出されてしまいます。

　話が発展すれば、過去のプロジェクトのバグ票のうち、設計段階で混入されたバグを見直して、それらがレビューで発見されていた場合の修正工数と比較するのもよいでしょう。

レビューがうまくいくための基盤を作ろう

　もちろん、レビューを定着させるうえで大切なのは、プロジェクトマネージャーのようなキーパーソンだけではありません。一般のレビューアに対する配慮も大切です。例えば、ドキュメントの作成者がきちんと準備をしてもいないのに、「エラーをみつけてくれ」といわれると、レビューアの目には作成者が横柄にみえるときがあります。特に作業負荷が高いときにはこの傾向が強くなります。

　これを避けるためには、まずは作成者が率先してツールを使い、形式手順に沿って、「自己チェック」しておくことで、「レビューアの貴重な時間を割いてレビューしてもらう」という姿勢をみせることが大切です。レビュー自体の品質向上のためには、レビューアの“心情的な効果”も無視できません。

　また、レビューに限らず、人は「短期的に、自分には役立たないように思える作業」を避けたくなるものです。この点で、レビューを定着させるために何らかの“インセンティブ”を考案することも大切でしょう。例えば、「○○さんのおかげで、××がうまくいった」など、ほかのメンバーが作成した成果物の品質向上に寄与した際には「アシストポイント」を与えて、個人の評価に取り入れる、といった具合です。こうした仕組みは、有効なレビューを実践するための“風土”作りに大いに貢献するはずです。

　さて、いかがだったでしょうか。冒頭でも述べたように、レビューとは“協力”して行うものである以上、「関係者全員の納得」が前提条件となることがご理解いただけたと思います。レビューに限らず、複数の人が協力して 1つのことを行う場合、そこには必ず明確な計画と、人を動かすための“配慮”が必要になります。

　うちの組織はどんな風土なのか、周りにはどんな人がいて、どんな考え方を持っているのか──ぜひあなたの周りを、もう一度見直してみてください。レビューの定着はもちろんですが、ビジネスそのものをうまく回すためのヒントも、思いのほかみつかるかもしれません。

筆者プロフィール

森崎修司（もりさきしゅうじ）

国立大学法人奈良先端科学技術大学院大学情報科学研究科助教

ソフトウェアレビュー／ソフトウェアインスペクション、ソフトウェア計測を専門とし、研究・教育活動をしている。奈良先端科学技術大学院大学にて工学博士を取得後、情報通信企業でソフトウェア開発、開発管理、レビューに従事。現在、同大学院に奉職。研究成果を業界に還元していくことをミッションの1つと位置付け、ソフトウェアレビュー研究の国際連携ワーキンググループの主導、多数の企業との共同研究、文部科学省「次世代IT基盤構築のための研究開発: StagEプロジェクト」に従事。アイティメディアオルタナティブ・ブログで「森崎修司の『どうやってはかるの？』」を執筆中。

ソフトウェアレビュー／インスペクションの研究グループ：

http://se.aist-nara.ac.jp/html/review/

ソフトウェアレビュー／インスペクション研究の国際連携ワーキンググループ：

http://www.software-inspection-wg.org/

StagEプロジェクト：

http://www.stage-project.jp/

「ソフトウェアレビュー入門」バックナンバー

前のページへ 1|2|3 　　　　　　