ウォークスルーを実施するには、それなりの成果物が書かれなければなりません。したがって、これは“副次的な効果”とは言えないかもしれませんが、このようなウォークスルーの洗礼を受けることで、そこを通ってきた成果物は読みやすく、欠陥の潜んでいないものとなります。勿論１００％、事前に指摘できたかどうかは分かりませんが、取り組み方次第では、相当に精度が上がるはずです。
指摘したり、指摘されたりすることによって、ひとりの人のスキルやノウハウが、メンバーの中に広がっていきます。このことは「ソフトウェアの文化」という観点からも、とても重要なことです。
これが為されていないことで、多くのソフトウェアの開発組織では、その中に優れた「個人」が一人二人傑出することはあっても、全体のスキルが向上しないのですから。
このことから、ウォークスルーを“設計”に限定しないで、もっと広い範囲で実施することも出来ます。要するに「成果物」があればウォークスルーは実施できるのです。
組織は一つの行動単位であり、そこでは迅速な「決定」が求められます。特にこれからはそのスピードが重要になります。しかしながら「決める」ということは簡単に出来ることではありません。プロジェクトを進める中で、何度か「決める」ことが求められる場面があります。そこで旨く決められれば、メンバーの作業は捗るのですが、逆に決められなければ、暫定的な作業が入ってしまったりして、あちこちにリワークの原因を作ってしまうことになります。
「決める」ためには、十分な情報が必要ですし、それを元にして「判断」するメカニズムを持たなければなりません。さらに、決めたことを「説明」することも求められます（今風にいえば、アカウンタビリティに相当する？）。通常、これは「訓練」されなければ身につくものではありません。しかしながら今日のソフトウェア開発組織において、残念ながら「決める」ことの訓練の場がありません。ウォークスルーの様なものを実施しても、現実には担当者が思案することなく参加者全員で決めてしまいます。もっとも、その場合、その決定に誰が責任を持つかという問題があるのですが、何故かそこだけは本来の担当者になっているのです。これでは、何にもなりません。
「担当者」というのは、その部分の「責任者」でもあるのです。そして２１世紀に入って、組織をダイナミックに運営するためにも、この訓練に早い段階から取り組むべきなのです。
ウォークスルーは、これをうまく運用することで「決める」訓練が出来るのです。
ソフトウェアはそれを“作り込んだ”ときに“動作”させて評価すれば、そこに潜む問題の殆どは検出されるはずです。特に、作り込んで直に実施すれば、その効果も高くなるでしょう。しかしながら現実には、そのような作り込んだときに動作させずに、いわゆる「テスト」とと称してソースの変換した後になって動作させています。
これをもっと早い段階に“動作”させれば、原理的には「テスト」は不要となるのです。それは「テスト」段階では何も作り込んでいないからです。“作り込んだときに動作させる”―これがクリーンルーム手法の考え方なのです。そしてそれを支えるのが、高度なレビュー技法なのです。厳密なレビュー技法を導入することで、作り込んだときに、まるで実際に動いているかのようにレビューするのです。ウォークスルーによってそのノウハウを修得しておくことは、将来的にも有効なのです。