ウォークスルーとは？目的やレビュー方法、実施ルールについて解説

ソフトウェア開発において、納期は非常に重要な要素です。

しかし、納期を重視するあまり、リリース後に不具合や仕様変更が多発し、結果的に利用者の離脱につながってしまっているケースがよく見られます。こういった状況の場合、それだけではなく、後続開発作業も着手が遅れ、ますます短期開発を余儀なくされる悪循環が発生します。

そうならないためにも、納期を重視しつつ、QCDのバランスを保ちながら、ソフトウェアの品質を高める活動もしていかなければなりません。

その際、闇雲にテスト工程に厚みをもたせ、下流工程で不具合を取り除く戦略も一つの手ではありますが、上流工程の品質が不十分であった場合、膨大なテスト工数・工期が必要となりますし、そもそもリリース直前での品質確認は、納期に直接的な悪影響をもたらすため注意が必要です。

納期を優先するためには、上流工程での改善に注力する必要があります。その一環として、ITレビューは欠かすことができない取り組みです。

ウォークスルーとは、会議室などで参加者が机上でシミュレーションする形で、欠陥を発見していくレビュー手法です。

ウォークスルーは、あらかじめ日程を決めて実施するものではなく、開発作業の開始直後や、作業が行き詰まったときなどに、レビュー対象物の作成者自身がプロジェクトメンバーに声をかけて自主的に実施します。正式な議事録はとらず、参加者が自由に内容を検討していくカジュアルな進行が特徴です。

ウォークスルーは、ITレビュー手法の一つであるため、欠陥の早期発見と除去を目的として実施します。要件定義フェーズや設計フェーズといった、システム開発の上流工程での品質点検や品質向上に効果的です。ですが、その他にも、他のITレビュー手法にはない目的が2点あります。

1点目は、よりよい実現方法を参加者と一緒に検討することに重きが置かれている点です。レビューしてもらう箇所は作成者が決め、指摘されたとしても修正するかどうかは作成者が判断します。自分では気づかない、あるいは知らないテクニックを参加者から学ぶことができます。

2点目は、レビュー箇所に関する知識を参加者の間で共有することが目的に含まれている点です。こうすることで、ノウハウが属人化することを防ぎ、チームがもつスキルの底上げにつながります。何か問題が起きた際には、お互いに助けあうこともできるのです。

このように、ウォークスルーは最終的な品質確認というよりも、設計手法や作業アプローチの質を向上させる品質管理手法なのです。

では、次に実施方法(ルール、手順)について解説します。

ウォークスルーには一定のルールをもたせ、実施していくことが重要です。

管理者のシステム知見が浅い場合、ウォークスルーの目的を達成することができません。また、検討段階で行うことが多いウォークスルーでは、初歩的な誤りも多く含まれるため、作成者が人事評価への影響を懸念し、完成度の高さをこの段階で求めてしまうことがあります。こうなってしまうと「よりよい実現方法を参加者といっしょに検討する」というウォークスルーの目的を阻害する可能性があります。

前述のとおり、ウォークスルーの目的は品質確認というよりも、設計手法や作業アプローチの質を向上させる品質管理という側面があります。参加者は、あくまでレビュー対象物に対しての指摘を行い、意見を述べる際にも、建設的な意見になるように心がける必要があります。主観の押しつけや、否定が強すぎると、議論が進まなくなってしまうため注意が必要です。

他者が作成した成果物を、その場で読み解くことは容易ではありません。適度に集中力が維持できる時間内で終わらせることを心がけなければなりません。目安として30分から長くても1時間で実施しましょう。

前述のとおり、ウォークスルーは、開発作業の開始直後や作業が行き詰まった時などに実施します。つまり、網羅的に実施する前提で行うものではありません。全範囲において実施していては、膨大な時間がかかります。

もちろん、実施するほど設計手法や作業アプローチの質は向上しますが、重要なポイントに的を絞って実施することをおすすめします。具体的には、費用対効果を意識し、複雑なアルゴリズムを採用している部分や、はじめて連携する外部システム部分などがあげられます。

つづいて、ウォークスルーの具体的な手順について解説します。

なお、前段でも記載しておりますが、ウォークスルーはカジュアルな進め方をすることも重要であり、ルールを決めすぎてしまうと効果が軽減してしまう点も念頭に入れ、手順について確認いただければと思います。

1. 会議体の設定

ウォークスルーは、工程完了時のレビューや、承認を得るための最終レビューとは性質が異なり、その時々で対象物や議題が異なり、実施タイミングも不定期であることが多いため、レビュー対象や議題に適したレビュアーを作成者が数人選定し、ウォークスルーミーティングへの参加を要請します。設定タイミングは、開催日の数日前が通例です。まわりに促されるものではなく、作成者自身が自発的に設定をするものと理解をしてください。

2. レビュー対象物と議題の事前共有

ウォークスルーは、短時間で済ませることも重要です。そのため、前もってレビュアーには対象物と議題を理解してもらい、議論を濃密なものにしなければなりません。レビュアーは作成者が求めている役割に応じて資料を事前にチェックしておきましょう。

3. 目的意識の共有

実施当日、最初に作成者から、確認してほしい点や、相談したい内容を簡潔に述べ、共通認識の形成を行います。カジュアルな会議体であるため、目的から逸れた議論になってしまうことを、ここで抑止しておきます。

4. ウォークスルーの実施

作成者が対象物(資料)を順に読み上げ、レビュアーはそれを説明に沿って確認していきます。その過程で不明点や問題点があれば、即座に意見を述べます。参加者は、問題提起だけで終わらず、可能な限り解決することを目的として意見を述べ、案やヒントをたくさん示しましょう。その場で解決できないものが出た際には、必ず宿題事項をリストに追記します。

5. 振返り

ウォークスルーが終わったら、最後に作成者から、これまでにあがった修正点や、宿題事項を読み上げ、参加者に口頭で周知します。このとき、全体を通した問題点やコメントの有無も合わせて確認をします。

6. 参加者、および管理者に向けて報告書を作成し、展開

実施時にあがった修正点や宿題事項を、最後に報告書としてまとめ、参加者に文書として展開します。このとき、参加していない管理者(前途の通り、原則管理者は不在で実施する)にも展開し、議論した内容や修正点、宿題事項については報告をします。

ソフトウェア開発を取り巻く環境に追従するためには、QCDのバランスを保ちながら、ソフトウェアの品質を高める活動もしていかなければなりません。そのためにも、上流工程での品質のつくりこみを重視し、レビュー方法としてウォークスルーを採用してみてはいかがでしょうか。設計書やプログラムのみならず、計画書や戦略においても、ウォークスルーは有効です。専門家のレビューを入れたい場合は、我々のような品質保証における専門家に依頼するのも一つの選択肢です。

SHIFTでは、開発の上流工程からテストまでの一気通貫でのシステム開発を請け負っています。多数の導入実績を誇っており、あらゆる分野の開発に携わってきました。

また、一部分だけのご依頼も可能です。本記事で紹介したソフトウェアテストだけの実施でもご相談ください。特にソフトウェアテストは弊社が力を入れてお客様のサポートをさせていただいている分野です。安心・安全にソフトウェアを使うためにも、ソフトウェアテストでお困りであればぜひSHIFTまでお問い合わせください。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ