ソフトウェア開発において、品質向上の取り組みのひとつにレビューが実施されることがあります。レビューの中でもウォークスルーは必要なときにカジュアルなやり方で実施されるものであり、チームの情報共有や問題点の明確化など、様々な効果が期待できます。本記事ではそのウォークスルーの基本や導入方法などについて触れていきます。
ウォークスルーとは？
ウォークスルーとは、ソフトウェアやシステム開発において、成果物の品質向上を目的とした作業工程のひとつです。ウォークスルーを実施するときは、システムの仕様やプログラム自体に間違いがないか、全体をチェックしていきます。参加者は作成者のほか、開発関係者・レビュアーなどが集まってレビューが行われます。
作成者は受けたフィードバックを基にして改善に活かします。ミーティングで指摘があった内容は文書に保存され、管理者への報告書も作成します。
もともとのウォークスルーはプログラムの机上チェックのことでしたが、時が経つにつれてレビュー対象、レビューアの人数が広がった影響を受け、もっと広い意味で使われるようになりました。言葉の意味合いは演劇用語から来ており、「演劇の下稽古で軽く演じる」というニュアンスで使われます。
開発過程でウォークスルーなどのレビューが必要な理由
プログラムやコードの品質を向上させる目的もありますが、それ以外ではほかのメンバーが持つ知識を学ぶことによってチーム全体の知識量が増加する効果もあるためです。ウォークスルーの実施によって、プログラマーは改善点の発見に役立てることができ、参加者はコードを読む訓練にもなります。それは、今後より質の高いコードを記述していくための良い勉強になるはずです。
さらに、メンバー同士が知識を共有する機会を持っておけば、一人に何かあったときでもメンバーの誰かが代わりを務めやすいでしょう。また、ウォークスルーなどで作成者以外のメンバーを集めてシステム全体の妥当性を確認することは、開発上で発生する様々なリスクの回避に役立ちます。
ウォークスルーを導入するメリット
ウォークスルーの導入によって、作成者は人に見られることを前提にしてプログラムの作成に取り組む必要が出てきます。このため、誰が見ても読みやすいコードを書くという意識を持ちやすくなります。
自分にしか分からないコードは、いずれ実施するメンテナンスの障害にもなりかねません。そこで、ウォークスルーの機会を設けることで他人の目に触れる機会が近いうちに訪れるようになり、作成者にいい意味での緊張感が生まれます。また、ウォークスルーのミーティングで説明をする際は考えを整理して人に話すことになるため、その時点で自ら矛盾点や欠陥に気づくこともあります。
また、孤独なまま作業を進めるよりも発表の場を設けた方が評価・反応を得られる機会があるため、作業に取り組むやりがいや手応えのようなものを感じやすいです。
ウォークスルーの導入方法
本レビュー方法を実際に導入したい場合の手順についてわかりやすく解説していきます。準備するべきものや点検物として対象になりやすいもの、事前にやっておいた方がよいこと、ミーティングで実施することなどについて触れます。
レビューアを選んで資料を準備
成果物をレビューするレビューアは複数人必要です。レビューに必要な資料や点検対象となる成果物を準備し、資料配布はミーティング開催の数日前に行います。レビューアは自分の役割を理解し、事前に資料を確認しておきましょう。
点検対象物としては、システムのDFD、データ正規化の結果、ER図、データ、処理機能の記述などが該当します。欠陥とみなすものは矛盾や不整合、重複、あいまいさ、実現性、キャパシティやパフォーマンスから見た問題などです。品質向上の必要性を感じるデータやコードなどを対象にしてウォークスルーを実施します。
ミーティングを実施
ミーティングは資料配布から数日後に開催します。基本は開発の行き詰まりなど不定期で行われるため、開催を告知するときはシステム作成者側からホワイトボードなどで知らせます。
依頼者側はレビュー側に課題点、悩みを伝えて共有しておきましょう。重要な部分を明確に意識しておくと、有益な話し合いや問題点の発見に繋がりやすいでしょう。ミーティングが始まったら作成者は資料などを読み上げ、レビューする内容の説明を順番に行います。説明の過程では、不明確な点があればそうなる理由を明らかにしたり、修正点があれば意見を出したりします。問題点はその場でできるだけ解決するようにしますが、できない場合はペンディングリストに入れます。
ミーティングの終了時には指摘項目の確認、新しく追加された問題点、コメントなどを確認して終わります。ウォークスルーは欠陥の発見を目的に実施するため、実際に修正するかはその場で作成者が決定しません。上司や顧客とのすり合わせのあとに判断されます。
ウォークスルーを行う際の3つのポイント
レビューを円滑かつ効率よく実施するために押さえておきたい3つのことについて順番に解説します。真剣に取り組むのはよいことですが、ウォークスルーを実施する目的から考えると時間をかけ過ぎるのはあまり良くありません。
少人数に適したスペースを確保
場所は会議室などが適しており、集めるのは4～6人程度の少人数が適当です。ウォークスルーはあっさり、短く効率的に実施するもののため、大勢いるのは望ましくありません。また、数人で開催する方が場にいるメンバーの積極的な発言が期待できます。参加者はそれぞれで机上シミュレーションの形式を取ってテストケースを想定しつつ、点検対象物を確認して欠陥・問題点の発見に務めます。
プロジェクトの内容ごとに時間帯を設定
基本的に長時間行うものではないため、1回あたり30分～1時間程度で終了するのが適切です。時間は適度な範囲内に収め、長引きそうなときは別の日に改めて行うようにします。そのため、レビューに使う資料もそれほどの量を必要とせず、適度に小さい単位でまとめると効率的です。
参加者の都合のよいときに短時間かつフットワーク軽く実施できるのがメリットのため、長時間行う必要はありません。必要なときに都度集まるようにし、レビューは手際よく行いましょう。
良いところもコメント
問題点を見つけることも大切ですが、同時に良い点について触れることも同じぐらい大切です。ウォークスルーは成果物への理解を深めたり、解決策のアイデアを生んだりするために活用される手法でもあります。そのため、品質向上に繋がる意見、メンバーが共有すべき良い点についても触れるのが基本です。
ウォークスルーの実践で特に重要なことは、作成者の批判は避けて成果物に建設的な意見を言うようにすることです。こだわりの押しつけ、粗探し、人格否定など建設的ではない意見は品質向上に繋がることはなく、チームの意欲を下げたり、場の雰囲気を悪くしたりする恐れがあります。アイデアを出すだけにとどめるといった配慮をしたほうが、良い方向に向かえます。
ウォークスルー以外のレビュー方法とは？
ソフトウェア開発工程のレビュー方法には様々な種類があります。ウォークスルーは非公式的な方法ですが、形式が決まった公式レビューもあり、目的に応じて使い分けられています。以下ではそのほかのレビュー方法について、簡単に解説します。
技術的な視点でチェック可能なテクニカルレビュー
技術リーダーが主導するやり方であり、主に技術的な観点で成果物の品質チェックを行います。技法の中ではピアレビューのひとつに分類される方法であり、カジュアルに行われるウォークスルーとは異なる公式レビューです。レビューアの経験や知識に基づいて、ディスカッションや判断、技術的な正しさ・評価、欠陥の発見、仕様や規定に沿っているかなどの確認が行われます。
進捗状況を中心にチェックするマネジメントレビュー
経営層・管理職が行うものであり、プロジェクトの進捗や承認を主な目的にして実施する非公式レビューです。準備レビュー、ゲートレビューとも呼ばれており、プロジェクト自体の継続や工程の移行などに関わるチェックを責任者のレビューを通して行います。レビューの結果に応じてプロジェクトの継続や中止、コミットメントの変更など様々な調整が行われます。
最も行われることが多いインスペクション
ウォークスルーとは逆で、体系的かつ厳格なルールがある公式レビューがインスペクションです。参加者は決められたルールや与えられた役割に従って進められます。少人数・短時間で効率よく済ませる点はウォークスルーと同じです。取り決めによっては指摘のあった問題点の修正も行う必要があります。
プロセスにはチームへのフィードバック、問題点の検知と改善方法の発見、チェックリストの使用や分析などの工程が含まれており、それらを総じてインスペクションと呼ぶことがあります。工程は多いですが、完成した成果物にインスペクションを実施することで、修正点があっても少ない手戻り工数で済ませられます。また、レビュー記録を残すことで開発プロセスの改善、問題の再発防止に繋がります。
まとめ
ウォークスルーとは非公式なソフトウェアレビュー方法のことです。実施により技術情報の共有、問題点の発見などのメリットがあります。
効率よくウォークスルーを行うには、OBPM Neoのようなプロジェクト管理ツールの活用がおすすめです。
