ウォークスルーとは

ウォークスルーという言葉は、元々、演劇の立ち稽古を指して使われていました。一通りのシナリオを出演するキャストで演じてみて、それぞれの立ち位置やセリフのタイミングなどを確認していきます。このように関係者を集めて確認することで本番に向けて問題がないか確認していくことができます。この関係者を集めて問題を確認することはシステム開発にも通じるもので、システム開発の世界でも、ウォークスルーという言葉は使われます。

システム開発において、関係者を集めて問題を確認することはなぜ必要とされるのでしょうか。それは、現在のシステム開発における環境に原因があります。顧客ニーズや市場動向が短い期間で変化する一方で、ライバルになりうるサービスに対抗するため高い品質が求められています。このように、システム開発の現場では、短納期と高品質が同時に求めらている状態です。短納期と高品質を同時に求められるあまり、リスク管理やレビューが十分に行われず、リリース後の品質問題やインシデントが発生したり、その後のシステム開発に遅れがでるといった事態が起こっています。短納期と高品質が同時に求められる状況では、関係者を集めて早期に欠陥を確認する、ウォークスルーのようなITレビューの重要性があがってきています。

前述したように、ウォークスルーはITレビューの手法の1つです。ここでは、ウォークスルーは誰が行い、いつ、どのように行われるのか説明します。まず、ウォークスルーの主催者となるのはレビュー対象物の作成者になります。開催されるタイミングとしては様々です。開発作業開始後すぐ、ということもあれば、作業が行き詰まったときに行われることもあります。どのように行われるかについてですが、主催者がプロジェクトメンバーに声をかけて、自主的に行われます。その際、成果物について説明していくことになりますが、成果物は設計書やソースコード、テストケースなど多岐に渡り、種類や工程は問われません。主催者と参加者は机上でシュミレーションする形で、欠陥を発見していきます。正式な議事録は取られず、自由に内容が検討されていくカジュアルなものです。

ウォークスルーの目的

ウォークスルーの目的の1つは、前述した短納期・高品質を実現するために、欠陥を早期に発見・除去することにあります。特に、システム開発の上流工程（要件定義や設計フェーズ）で行われるなら、効果的に品質をあげていくことができます。
しかしながら、ウォークスルーの目的は開発チームによって異なる場合があります。欠陥の発見だけでなく、成果物の改善や、仕様に沿って開発が進められているかの確認など、多岐に渡る場合があります。
以下では、ウォークスルーの、主な目的を4つ取り上げて紹介します。

問題点の指摘

ウォークスルーを実施するなら、作成者以外の視点が加わり、より客観的に成果物を評価することができて、問題を発見しやすくなります。結果として、成果物の品質向上に繋がります。
どんなに熟練したエンジニアであっても、ミスをしないとは限りませんし、先入観のせいで問題に気が付けないときもあります。このようなときに、異なる感性・経験をもつ開発メンバーの目を通してチェックしていくことで成果物の品質はより向上していきます。

より良い代替案の検討

ウォークスルーを実施するなら、成果物の作成者である主催者はより良い実現方法を参加者と検討することができます。作成者自身では気がつかない、もしくは、作成者が知らないテクニックを参加者から得ることもできます。
ウォークスルーの場合、レビューしてもらう箇所は作成者が決め、指摘されたとしても修正するかどうかは作成者の判断に任されます。

スキル向上（教育的側面）

ウォークスルーによって、主催者と参加者、双方のスキルが向上することが見込めます。
ウォークスルーの主催者は、成果物の内容を他人に分かりやすく説明することが求められます。それで、他人に伝わることを意識したプレゼンテーション能力が強化されます。また、参加者においては、第三者目線で成果物を評価する分析力や、実りある議論を進めるためのコミュニケーション能力が向上していきます。

開発メンバー間での認識共有

ウォークスルーによって、開発チーム内で、レビュー箇所について認識を共有することができます。認識を共有することにより、作業者にノウハウが属人化することを防ぎ、メンバー間の連携を円滑にすることができます。開発チームのもつスキルの底上げにも繋がりますし、何かの問題が起こったときにも助け合うことができます。
メンバー間の連携について言えば、例えば実装担当のエンジニアが設計書や仕様書のウォークスルーに参加すれば、プロダクトへの理解が深まり、設計書の意図や顧客が求めるものを把握しやすくなります。この時、得られた共通の認識は実装の際に役に立つはずです。
また、問題が起こった際の助け合いについては、例えばテスト担当がトラブルで不在になったとします。この時、テストケースなどの知識をウォークスルーで共有しておけば、代理の担当者をたてることもしやすくなります。

ウォークスルーの開催の仕方

ここでは、ウォークスルーの進め方について紹介します。各ステップで、気をつけたいことも合わせて説明します。ウォークスルーのおおまかなステップは以下です。

1. 参加者の選定・参加依頼
2. レビュー対象物・資料の事前共有
3. ウォークスルーの開催
   • 目的の共有
   • ウォークスルーの実施
   • 振り返り
4. プロジェクト関係者への報告
5. 指摘事項への対応

それでは順番に紹介していきます。

①参加者の選定・参加依頼

（参加者の選定）
ウォークスルーを開催するにあたり、まずレビュアー（レビューする人、参加者）を選ばなければなりません。このとき、できるだげ幅広い開発メンバーを選定するようにしましょう。様々な角度から成果物をチェックしてもらえれば、上記のウォークスルーの目的を達成しやすくなります。ちなみに、レビューされる人（作成者、開催者）のことをレビュイーと呼びます。
ここで気をつけたい点としては、人数を多くしすぎないこと、原則、管理者を参加させないことです。
人数を多くすると、時間がかかりやすく、発言しづらくなるので注意が必要です。また、管理者を参加させると、管理者のシステム知見が浅いときは、ウォークスルーの目的全体が達成できませんし、成果物の作成者が人事評価を気にして、完成度の高さを求めてしまうと、より良い代替案を考えるというウォークスルーの目的を阻害することがありえます。

（参加依頼）
ウォークスルーはその時々で、対象物や議題が異なります。また、開催のタイミングも不定期なので、成果物の作成者自身が参加者に呼びかけます。ウォークスルーに参加するかはレビュアーの自由なので、ウォークスルー開催のために承諾を得るようにしましょう。
通例、呼びかけるタイミングは開催日の2〜3日前となります。

②レビュー対象物・資料の事前共有

ウォークスルーの参加者には、レビュー対象物・資料を事前配布するのが一般的です。これは、成果物であるレビュー対象物や資料を事前に配布し、議題を事前に共有することで、ウォークスルーの進行をスムーズなものにし、また、議論を濃密なものにすることに役立ちます。
このとき、もし成果物が複雑だったり、ボリュームがあるものだったりするなら、わかりやすい資料を作成しておくことが必要です。また、資料の確認依頼もチャットやメールだけで済ませるのではなく、口頭で確認をお願いするなら、レビュアーが資料を確認してくれる確率をあげられます。

③ウォークスルーの開催

ウォークスルーの開催は以下のような順序で行われます。

1. 目的の共有
2. ウォークスルーの実施
3. 振り返り

（目的の共有）
ウォークスルーの目的を果たし、濃密な議論をするには、この過程が必要になります。ウォークスルーの最初に、作成者から、確認してほしい点、相談したい内容を明確にして、今回のウォークスルーでの目的を共通したものにします。ウォークスルーはカジュアルな形式であるため、目的から逸れた議論になってしまうことがありますが、先に目的を共通させておくことで、これを防ぐことができます。
また、ウォークスルー実施前に目的を共通しておくなら、議論自体を短時間に収めることにも役立ちます。参加者の集中が途切れないようにするためにも、ウォークスルーは30分から1時間以内に終えられるように心がけましょう。

（ウォークスルーの実施）
ウォークスルーの実施はごくシンプルです。2〜3日前に事前配布しておいた資料をもとに、レビュイーが成果物の内容を説明していきます。一方、レビュアーは、レビュイーの説明にそって、問題点や不明点があればその場で指摘していきます。指摘事項は、レビュイーまたは議事録担当者が記録していきます。その場で解決できない指摘事項に関しては宿題事項として記録します。
レビュイーが、説明をしていく際に気をつけたいこととして、システムの全範囲についてウォークスルーを行おうとしないことがあげられます。ウォークスルーは、開発作業の開始直後や、行き詰まったときに実施されるものなので、前提として、網羅的に行うものではありません。また、システムを網羅的にウォークスルー実施しようとすると膨大な時間がかかってしまいます。重要な箇所（複雑なアルゴリズムを含む部分やはじめて連携する外部システム部分など）に絞っていくことを心がけましょう。
一方で、レビュアーが指摘事項をあげていくときには、粗探しをしないことが重要です。否定や主観の押し付けが強いと、品質を向上させる建設的な議論が進まなくなってしまいます。意見を述べるときには、問題点の指摘だけでなく、代替案やヒントを可能な限り言及するようにしましょう。

（振り返り）
ウォークスルーの最後に、作成者が指摘事項（修正点や宿題事項）を読み上げます。このとき、開発チーム内で対応方針を協議したり、全体的な問題点やコメントも集めることができます。指摘事項への対応方針は作成者に委ねられる場合もあります。

④プロジェクト関係者への報告

ウォークスルーの際にあがった指摘事項をまとめて文書化し、プロジェクト関係者に展開します。この際、ウォークスルーに参加しなかった管理者にも、指摘事項をまとめて報告するようにすることを覚えておきましょう。作成された文書は開発メンバー内で管理するようにします。
インフォーマルな形式で行われるウォークスルーでは、文書や議事録が作成されない場合もあります。

⑤指摘事項への対応

ウォークスルーを通して、固まった対応方針に則って、作成者が指摘事項に対応していきます。この時、レビュー対象となった成果物を直接変更するのでなく、新しく修正版を作成します。このようにすれば、指摘事項対応後に差分を確認することができます。指摘事項の対応が完了したら、修正版の成果物をプロジェクト関係者に展開します。

まとめ

この記事ではITレビューの1つであるウォークスルーについて紹介しました。QCDのバランスを保ちつつ、ソフトウェアの品質を高めていくには、ウォークスルーのようなITレビューが必要になってきます。問題点を指摘するだけでなく、良い代替案を見つけることや、開発メンバーの教育、共通認識をもつことなど、ウォークスルーには様々な目的が存在しています。
ウォークスルーの効果を高めるためには、様々な角度からシステム開発について考慮していくことが必要です。下流工程のテスト知見をもつ人材からの意見は多いに役に立つはずです。