HOME > ソフテックだより > 第102号(2009年11月18日発行) 現場の声編「品質向上の取り組み 〜社内レビュー編〜」

「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。

ソフテックだより(発行日順)のページへ
ソフテックだより 技術レポート(技術分野別)のページへ
ソフテックだより 現場の声(シーン別)のページへ


ソフテックだより 第102号(2009年11月18日発行)
現場の声編

「品質向上の取り組み 〜社内レビュー編〜」

1. はじめに

ソフトウェア開発には属人性が高く、外から見てわかりにくいという特徴があります。そのため、担当者の考え方・スキルの違いによっては処理抜けや認識違いなどのミスにより、品質低下を招いてしまうことがあります。
そこで、ミスの早期発見のための、「レビュー」が重要になってきます。

ご存知とは思いますがソフトウェア開発の現場で行う「レビュー」とは、ソフトウェア製品の設計品質およびそれを実現するために、ソフトウェアライフサイクルの各工程において客観的に知識や知恵を集めて評価し、改善点を提案し、次の工程に進める状態にあることを確認する作業のことを言います。

もし、各工程でのミスに気づけずに開発を進めてしまうと開発終盤で不適合として表面化し、いくつかの工程を戻って作業をしなければなりません。この戻り作業が大きいほど、コスト、納期に大きな影響を与えてしまいます。また、何度も変更を繰り返すことでプログラムの保守性低下や、あらたな不適合が紛れ込む可能性が上がってしまうため、品質も低下していきます。
また、最終工程であるテストで見つかればまだ良いのですが、そこで見逃してしまうとお客様に大変なご迷惑をおかけしてしまいます。
この問題を防ぐためには、工程毎に品質を確保しながら開発を進める必要があります。

その必要性をあらためて感じていた今年の夏ごろ、ある開発に着手しました。その開発は、これまで作り上げたシステムをベースとして、別のシステムを立ち上げるという開発ですが、納期厳守が必須の開発でした。そこでこの開発では、『各工程での成果物の検証を徹底する』をスローガンに掲げ実践しましたので、その内容をご紹介します。

2. 社内レビューの取り組み

レビューは、計画、実施、改善の3ステップで進んでいきます。

(1). 計画

まずレビューの計画を行います。
実施する日時、レビュー対象、レビューイ(レビューを受ける側)、レビューア(レビューする側)、予定時間、目標不適合検出数、などを計画し、その通りに実施をしていきます。

今回の開発では納期厳守が必須の開発でしたので、以下のような全ての成果物に対してレビューを行い、納期を前倒しする計画としました。

  • 見積書
  • 設計書
  • ソースコード
  • 試験項目書
  • スケジュール表
  • コスト予測表
  • 残件や今後の見通し

今回は実力者が揃った開発であったため、チームレビューをメインに、パスアラウンドやウォークスルーを組み合わせて実施する計画としました(レビューの種類については「■レビューの種類」を参照)。

■レビューの種類

レビューでは、主に成果物に対して意図した通りに作成されているかをチェックしていきます。
特に、CMMI(能力成熟度モデル統合:Capability Maturity Model Integrationの略)では、チームメンバー同士による作業成果物の欠陥と改善の機会を探す目的で実施するレビューを『ピアレビュー(Peer review)』と呼んでいます(ピアとは、開発者と対等な立場の同僚を指します)。

このピアレビューにはいくつか種類があり、実施方法などにより、以下のように分類されます。

  • アドホックレビュー(Ad hoc review)

    計画的なレビューではなく、必要に応じて対応できる担当者へ確認してもらう、即席のレビュー。
    特に記録を作成するなど管理的要素は無い。

  • パスアラウンド(Pass around)

    多重かつ同時進行型のチェック。
    電子メールなどで作成成果物のコピーを何人かに配布し、複数のコメントを依頼。

  • ペアレビュー(Pair review)

    作成者とレビューアがペアを組み、作業成果物を確認。

  • ウォークスルー(Walk through)

    作成者が作業成果物をグループ員へ説明し、コメントを求める。

  • チームレビュー(Team review)

    複数のメンバーが参加して確認する。
    計画、定義された手順に従って実施される。

  • インスペクション(Inspection)

    もっとも体系的で、各参加者に特定の役割を与え、多段階のプロセスが存在など厳格なレビュー。
    作成者以外の参加者が会議を主導し、チェックリスト使用、分析なども実施する。

(2). レビュー実施

計画を元にレビューを実施します。
今回レビューでは特に以下の4点に注意してレビューを行いました。

  1. 成果物をチェックしやすい工夫

    特に設計書においてですが、どのような仕様をどのように実現するのかという部分にポイントを絞りより具体的に表現することで、レビューしやすい状態としました。
    仕様の認識がどんなに一致していても実装方法によって、性能、コスト、保守面などで大きな違いが出てしまうのがソフトウェアの特徴です。そのため、せっかくレビューしたのにあと一歩足りないという状況を軽減するために、チェックしやすい成果物とすることをメンバー全員で第一に考えて進めました。

  2. 成果物の事前チェックの徹底

    今回は、レビュー対象の成果物を、レビュー前に各自事前チェックすることとしました。
    レビュー回数を進めていくうちに、レビューをきちんと行うほど、1回1回のレビュー時間が長くかかってしまうため、コストやスケジュールを圧迫する可能性が出てしまいました。
    最初は「確認する内容が多いため仕方ないのかな」と思いながらレビューを実施していましたが、このままではまずいと考え、レビュー効率を少しでもあげるために、レビュー出席者による事前チェックの徹底を行いました。

  3. 週1回のレビュー実施

    レビューは、各成果物が出来上がった時点だけではなく、週1回定期的に開催し、途中成果物に対してもレビューを実施しました。
    これも、初期計画では盛り込んでいませんでしたが、実際にレビューを行っていったところ、いろいろな手戻りが発生してしまいました。
    そのため、こまめにレビューを実施することにより、できる限り早い段階で間違いに気づき、戻り作業を最小限に抑えるよう計画を変更しました。

  4. レビュー記録の徹底

    レビューを実施した内容は、実施中に記録をとっていきました。
    その記録には、どのような問題があり、どのように修正するのか?また、いつまでに誰が対応するのか?その問題は予定通り修正済みか?といったことまで全て記録に残します。
    後から記録するのではなくその場で記録することにより、せっかく指摘を受けたのに修正を忘れてしまったという、つまらないミスをなくするためです。

(3). レビュー結果による改善

レビュー結果を元に、不適合の発見だけではなく、次へ向けた改善内容も見つけ出し実施していきます。

  • 不適合を発見しやすい環境づくり

    本開発における全不適合は約60件で、その内レビューで発見された不適合は50件(全不適合の8割)でした。

    レビューで見つかった不適合の中には、

    • 見積レビューでは、要求仕様に不明確な点があったことや、実施すべき作業が抜けていた
    • 設計レビューでは、要求仕様を満たせない可能性があった
    • ソースコードレビューでは、稀に意図しない動作をしそうな記述があった・・・

    など、複数人の目でチェックしなければ発見が難しい不適合や、後々の工程に大きな影響を及ぼしそうな不適合を、レビューで早期に見つけることができました。

    前工程での不適合の見逃しは、後工程になればなるほど、影響が多岐に渡ってきますし、問題の致命度や修正の緊急度や修正時間も大きく異なってくるものです。
    そういう点では、不適合数は決して少ないとは言えないものも、早期に不適合が発見できたのは、レビュー毎に不適合の発見・修正をしっかり行ったことによって、不適合を見逃しにくい環境づくりができたためではないか?(大量の不適合が一度に見つかると、細かい不適合を見逃す可能性もあがる)と考えています。

  • 不適合の早期水平展開およびレビュー時間短縮

    今回のレビューでは、多くの問題点を早い段階でつぶすことが出来ましたが、その大きな要因は、「成果物の事前チェックの徹底」だったと考えています。
    今回のレビューではレビューを受ける側はもちろん、レビューする側も開発の詳細まで把握しているため、1つ1つ詳細に説明を受ける必要が無いところが多く存在することに気づきました。そこで、レビュー前に事前に成果物のチェックを各担当者で実施することで、レビューではその指摘事項の確認と前回指摘事項の修正確認と水平展開に集中して実施することができました。つまり、レビューと同時に不適合の水平展開が可能となりました。

    同時に、これまでレビューに費やしていた時間は大幅に短縮することが出来ました。もちろんレビューの質は保ったままです。

    この方法は、今回は効果的でしたが、レビューする側もそれなりの知識とスキルが求められるため毎回この方法が取れるわけではありません。
    よって、効率の良いレビュー方法に関しては、まだまだ改善が必要と感じています。

3. 最後に

今回は、私が携わった開発で行ったレビューについてご紹介させていただきました。

今回の開発では、レビューで徹底的に成果物の検証を行ったことにより、工程毎に品質を確保することができました。その結果、開発途中で大きく戻る事も無く、少しですがお客様のご希望納期よりも前倒しして開発を終えることが出来ました。
ベースとなるシステム開発時には、出荷後に多くの不適合が発生してしまい大変なご迷惑をおかけしていましたが、今回の開発では大きな問題も無く、品質の良いシステムを納める事ができました。
これもレビューによる効果だと、思っています。

ただし、レビューだけに頼るのではなく、作成担当者が責任を持って品質を高めていくことが重要なのは言うまでもありません。それでも見逃してしまいそうなところを『再確認』の目的で実施するレビューは非常に有効な手法です。

しかし、レビューの実施においては、コストやスケジュールも無視することができませんし、そのためにはそもそもの不適合数を減らすことを先に考えなければなりません。
よって、効率と効果の高いレビューと、そもそもの不適合を減らすことについては今後の課題として取り組みたいと思います。

今回はレビューについてご紹介しましたが、その他にも当社では品質向上のため、様々な取り組みを行っています。
次の機会に、ご紹介させていただければと考えています。

(T.O.)

[参考文献]

「ソフトウェア・レビュー技術 基礎から実践までのノウハウ」

編著者:織田 巌
出版年:2007/12/25
出版社:株式会社ソフトリサーチセンター

関連ページへのリンク

関連するソフテックだより

ページTOPへ