ウォークスルー(うぉーくするー)情報システム用語事典

walkthrough / walk through

» 2011年11月07日 00時00分 公開

 ソフトウェア開発において、ソフトウェア成果物(注1)の品質向上を目的に、その作成者が主体となって開催するレビューのこと。インスペクションに準じる公式なソフトウェアレビュー(注2)に位置付けられることが多い。

 ウォークスルーは、レビューを希望する作成者が数人のレビューアを招集、成果物の内容を順に説明する形式をとる。それに対してレビューアは、説明を通じて対象を追跡・検証し、その誤りや矛盾、抜け漏れなどを指摘するというのが大まかな流れである。カジュアルなグループディスカッションから公式レビューまで、幅広いバリエーションが存在する。

 ソフトウェア分野でいうウォークスルーはもともと、プログラムの机上チェックを指していたが、やがてレビュー対象やレビューア人数が広がり、より拡張された意味でも用いられるようになった。そのため、ピアレビューの同義語として使われることもある。

 ウォークスルーの基本的な進め方は次のようなものになる。レビュー対象(成果物)の作成者は自身の作成物を点検してもらうためにレビューアを数人選定し、ウォークスルーミーティングへの参加を要請する。承諾を得てレビューアが決定したら、作成者はミーティングに先立って成果物や資料を配布する。レビューアは自分に期待されている役割から資料を事前チェックしておく。

 ミーティングは資料配布から数日後に開催する。ここで作成者はプレゼンテーションや資料の読み上げを行い、レビュー内容を始まりから終わりまで順を追って説明する。レビューアは作成者のプレゼンテーションを聞いてその考えを追体験しながら、欠陥や問題点を指摘する。

 指摘された内容は文書化するが、欠陥を修正するか否かについては作成者の責任として、ミーティングでは取り扱わない。作成者はミーティングの終わりに指摘項目を読み上げ、追加の問題点やコメントの有無を確認する。ミーティング後には管理者向けて報告書を作成、検出された欠陥の除去に努める。

 このうち、事前の資料配布や報告書作成は省略されることもある。資料配布をしない場合、レビューアはミーティングの時間を割くだけなので負担は最小化される。ただし、説明がミーティング時のプレゼンテーションだけだと、レビューアが一方向からの影響を受け過ぎ、不具合検証の機能が低下するリスクがある。

 語源的にはウォークスルーは演劇からの借用語である。演劇用語のウォークスルーは立ち稽古・通し稽古の意味で、筋の流れや演者の動きを確認するためにすべてのシーンをひと通りやってみることをいう。

 ここから、作成したプログラムの誤りを確認するために、ハードウェアは使わずに処理の流れをひと通り、人力で追跡する方法がウォークスルーと呼ばれた。往時はハードウェアがごく限られた時間しか使えなかったので、不具合のあるプログラムを計算機センターに持ち込むことが許されなかったのである。

 このウォークスルーは、サンプルのデータを用いて制御パスを1ステップずつ実行していき、論理やと振る舞いが正しいかどうかをレビューアたちが検証していくものだった。作成者本人が行う方法(机上チェック)もあったが、他者の視点が入れて数人で行う方が効果が高いとされた。これはテスト技術者がテストケースを用意して実施されるソフトウェアテストと同様の方法で、ハードウェアを使わないテストといえる。

 コンパイラやデバッガの発達によってコードの机上チェックが不要になっても、ウォークスルーという言葉は、さまざまな成果物の事前点検を意味する言葉として使われ続けた。要求書であれば、そのシステムを使った場合の業務手順・操作手順に再現して、意図された業務プロセスとのズレがないかを検証する。仕様書であれば、仮定の入力パターンを用意し、それに対応する出力や状態変化を追っていくことで不正確な記述がないかを検証する。

 ウォークスルーはエドワード・ヨードン(Edward Nash Yourdon)の『Structured Walkthroughs』(1977年)によって定式化が試みられたこともあって、しばしば公式レビューの一種に位置付けられる。この系統のウォークスルーは次のような原則を掲げている。

  • マネージャ(人事評価の権限者)は参加しない。欠陥検出はよいソフトウェアを作る1つの過程だが、この部分だけを個人の評価に結び付けるとマイナス査定になりがちである。さらにこのことがレビュー対象者(作成者)が知れば、よいレビュー評価ばかりウォークスルーを目指すことになり、ウォークスルー本来の役割が失われる。
  • レビューアは成果物をレビューする。作成者を批判するのではなく、成果物に対する指摘を行うこと。あらさがしではなく、建設的な意見を述べるように配慮する。
  • ミーティングは1〜2時間を限度とする。時間は厳守し、超過しそうな場合には日を改めて行う。資料もそれに合わせて小さな単位にしておく。ただし、部分に区切るのではなく、抽象化の粒度で調節することが望ましい。
  • 欠陥修正決定会議にしない。ウォークスルーは欠陥の発見が目的であり、それを修正するか否かは作成者が(上司や顧客との議論を経て)決定する。

 ウォークスルーは、ミーティングで指摘や意見が得ること以外にも効果がある。ウォークスルーの開催を前提にすれば、作成者は成果物を作る段階からそれが読まれること、他人に説明することを意識することになり、独りよがりな表現や論理展開が抑制される。

 また、作成者はミーティングで自身の考えを論理を説明する作業を通じて、自分自身で問題点や矛盾点に気付く場合もある。この効果を期待するのであれば、レビューアは問題点を指摘する力量よりも、よい聞き手であることの方が重要であろう。

 作成者は特定の前提知識、事前状況を自明のものとして、それが具体的に表現されていない成果物でも行間を読んでしまうことがよくある。他者の視点・専門外の視点を持つ聞き手、読み手が「分からない」「分かりにくい」と指摘するだけでも、気付きに到達する可能性は大きいといえる。

 さらに、どのような成果物であってもひたすら孤独に作業するよりも、発表する場があって周囲の評価や反応がある方が、やりがいが向上するはずだ。自主性を強調するウォークスルーでは、やりがいは重要なファクターである。

 ソフトウェア開発の世界以外にも手順を踏んで、予行演習的に事象を確認する方法は採用されている。

 内部統制の分野では、文書化された内部統制システムの有効性を評価方法として「ウォークスルー」が行われる。主要な取り引きについて、取り引きの発生から財務報告までのプロセスを帳票や記録で追跡し、その適正性を確認する作業である。

 ユーザビリティの領域には、ピーター・ポルソン(Peter G. Polson)らが考案した「認知的ウォークスルー」というユーザビリティ評価法がある。マニュアルやトレーニングなしに操作を理解できるかどうか、目標の設定・探査・選択・評価の4つの探査学習ステップごとに評価を行う。

(注1)http://www.atmarkit.co.jp/aig/04biz/deliverables.html

(注2)http://www.atmarkit.co.jp/aig/04biz/review.html

参考文献

▼『ピアレビュー ――高品質ソフトウェア開発のために』 カール・E・ウィーガーズ=著/大久保雅一=監訳/日経BPソフトプレス/2004年3月(『Peer Reviews in Software: A Practical Guide』の邦訳)

▼『コードコンプリート――完全なプログラミングを目指して』 スティーブ・マコネル=著/石川勝=訳/アスキー/1994年8月(『Code Complete: A Practical Handbook of Software Construction』の邦訳)

▼『ソフトウェアインスペクション』 トム・ギルブ、ドロシー・グラハム=著/伊土誠一、富野壽=監訳/構造計画研究所/1999年8月(『Software Inspection』の邦訳)

▼『ソフトウェアの構造化ウォークスルー〈第2版〉』 エドワード・ヨードン=著/國友義久、千田正彦=訳/近代科学社/1991年11月(『Structured Walkthroughs 4th Edition』の邦訳)

▼「Cognitive walkthroughs: A method for theory based evaluation of user interfaces」

Peter G. Polson、Clayton Lewisa、John Riemanc、Cathleen Wharton=著/International Journal of Man-Machine Studies, Vol.36, Issue 5/1992年5月


Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ