「ウォークスルー」を成功させるコツ
――ソフトウェア工学のテクニックがHDL設計を支援 part II


伊藤 昌夫（いとう・まさお）
ソフトウェア・コンサルタント


　ソフトウェア開発の世界では，「ウォークスルー」は，プログラム・コードの品質を高める有効な手段であると認識されている．さらに，設計チーム全体の知識の底上げや，リスクの回避にも役立つ．しかし，やりかたを誤ると，たちまち膨大な時間のムダに終わってしまう．そうしないためには，実行するにあたって，参加者の心理的な側面に気を配らなくてはならない．

　ここでは，ハードウェア記述言語（HDL）を利用しているハードウェア設計者にとっても重要となるであろう「ウォークスルー」の考え方を紹介する．

●たんなる確認行為ではない

　ソフトウェア開発の世界で，ウォークスルーの考え方が提唱されたのは，ずいぶんと昔のことだ．ウォークスルーに関する名著であるエドワード・ヨードンの『ソフトウェアの構造化ウォークスルー』1)の原書（第1版）が1977年に発行されている．それだけ実績のある手法と言える．

　ウォークスルーは，もともと「演劇の下げいこで，それぞれの役柄をあっさり演じる」というくらいの意味である．ソフトウェア開発の世界では，各工程の成果物である設計ドキュメントやプログラム・コードを，みんなで順番に見ていきながら，その妥当性を確認し合う作業を指す．

　ウォークスルーは非常に単純な手法ではあるが，実行するうえで考慮すべき問題がいくつかある．先に紹介したウォークスルーの語源は，この点で非常に的を得ている．たとえば，「あっさり」と演じるためには，当然参加者は，それなりの技術や知識を持っている同僚ということになる．また「配役」というのも必要で，参加者はそれぞれ「発表者」，「レビューする人」，「書記」，「進行役」といった役割を与えられる．

　ちなみに，「ウォークスルー」と「レビュー」は，ソフトウェア開発の世界でははっきりと区別されて使われている．一般にレビューは契約ないしは，標準として定められた正式な認証行為である．これに対して，ウォークスルーはよりインフォーマルな活動を指しており，レビューにはない利点をもっている．たとえば，自分では気づかない，あるいは知らないテクニックを他の参加者から学ぶことができる．そのプロジェクトに関する知識を参加者の間で共有し，いざとなれば，互いのピンチ・ヒッターを務めることができる．

　つまり，ウォークスルーは最終的なコードの確認というよりも，設計品質やコード品質の向上を目的とする品質管理の一手法なのである．

●してはいけない四つの行為

　良いところが多々あるウォークスルーではあるが，成功させるためには参加者の心理的側面への配慮が重要になる．ウォークスルーの場で，してはいけない行為を四つ紹介しよう．

(1)管理者（マネージャ）を参加させてはいけない．

　もともと管理者は，コードが読めないなど，役に立たないことが多い．まして，だれかが誤りを見つけたときには，エンマ帳に「ボーナス，マイナス」と書き込む可能性もあり，怖くてだれも発言できなくなる．つまり，参加者は同僚同士，というのが原則である．

　さらに，もう一つの原則を忘れてはいけない．いわく「バグを憎んで，人を憎まず」．

(2)あらさがしをしてはいけない．

　参加者は，明らかな誤りを見つけること以上に，より建設的な意見を述べるようにしなくてはならない．プログラマや設計者というのはこだわりをもっている人が多い．そのこだわりは，とかく趣味の押しつけ合いや，けんかに発展しやすい．

　あくまでも参加者は代案を出すだけにとどめること．最終的な選択権や決定権は発表者（その設計をした人，あるいはコードを書いた人）にある．

(3)長時間続けてはいけない．

　他人の設計ドキュメントやコードを読むのであるから，集中力が必要である．したがってウォークスルー自体は短時間に区切って進めるべきである．集中はするが，時間としては「あっさり」すませるべきだ．前述の『ソフトウェアの構造化ウォークスルー』では，ウォークスルーの時間は30分以内が望ましいとしている．

　短い時間で，断片ではなく全体を追いかけることが肝要である．もちろん，そのためには，必要な資料は事前に配布しなければならない．参加者は，その資料を良く読んでおくこと．レビューが始まって，初めてその内容を知る，ということがあってはいけない．

(4)すべてをやろうとしてはいけない．

　すべてをウォークスルーしようという強迫観念から逃れること．とくに，まじめな人はこの傾向がある．次のような点に絞ってウォークスルーを実施する．

[1]設計された全体の構造
[2]重要で困難な設計箇所
[3]複雑なロジックを実現しているコード

　ウォークスルーは，実施すればしただけ設計品質やコード品質がよくなるには違いないが，その経済性についても考慮するべきである（もっとも，上流工程での設計品質の向上は，下流工程における作業効率の大きな改善につながるので，単純にその経済性を見極めるのはむずしいのだが…）．

●心理的な圧力が良いコードを作る

　以上が，ウォークスルーを成功させるためのコツである．次に，心理的な側面から，ウォークスルーの良い点をいくつか挙げておこう．

　ウォークスルーを実施するということが，プログラマや設計者にとって良い心理的圧力となる．誰かが自分の書いたコードを真剣に読むとしたら，自分にしか分からないコードは書けない．もちろん，つねにそうでなくてはならないが，それが遠い何年後かの保守（HDL設計で言えば，設計再利用か？）のときではなく，来週来るとしたらそのコードを書く真剣さも違うだろう．

　また，どんなに優秀なプログラマや設計者であっても思い込みからは逃れられない．他者の目は，すべてではないかもしれないが，その思い込みから来る誤りを見つけるのに役に立つ．

　さらに，他の参加者にとっても，書かれたコードを読む訓練になる．良いコードを作成するためにもっとも必要な能力は，きちんと読み書きできることである．だとすると，ウォークスルーは読み書きの能力を向上するための場とも言える．

　とかくプログラマや設計者は，個人的な技能レベルから抜け出せないといわれる．ウォークスルーは，この個人的なレベルを，本人や参加者といったチーム・レベルに引きあげる有効な手段となる．先に述べた心理的な側面に注意するならば，ウォークスルーの考え方はHDLのコーディングにおいても，十分に効果を上げることだろう．

参考文献
1)エドワード・ヨードン，『ソフトウェアの構造化ウォークスルー』，近代科学社，1991年．


(本コラムは1999年2月発売の本誌20号付属CD-ROMに収録されました)


◆筆者プロフィール◆
伊藤昌夫（いとう・まさお）．自動車会社，航空機関連会社のソフトウェア・エンジニアを経て，ニルソフトウェアを設立．ソフトウェア・プロセスおよび開発環境が専門で，そのためのコンサルテーションおよびツールの提供を行っている．設計における人間の認知活動に興味を持っている．



Copyright(C) 1999 CQ Publishing Co., Ltd. All Rights Reserved.