効果
ウオークスルーを実施することで、意外にたくさんの質問や、気が付かなかったこと、当たり前と思っているのは自分だけだったというようなことが発見できます。これらを議事メモに落とします。
ウオークスルー議事まとめ
議事メモは各テーマごとに作成し、課題事項、ユーザに対する制限事項、その他議事項目などに分類しながら作成します。

展開と実施
この議事メモは必ず展開をして対応を必ず書くようにします。
担当者をマネージャがいれ、その人に対応及びその具体的内容を入れてもらいます。ここでの具体的内容は、課題の内容に対する対処ではなく、課題自体を課題管理するとか何もしないとかというレベルの内容を管理します。そうしないとプロジェクトの課題管理表と二重管理になるからです。

課題管理に載ったら通常の課題管理に基づいて管理します。

最後に復習です。
このシステムウオークスルーで期待するアウトプットはPJによって様々と思いますが、以下の3点があげられます。
①課題管理表
②サービスレベル一覧（制限事項一覧）
③みんなの理解

あくまでもPJ推進の基本設計レビューと同じ位置づけで、システムのアーキテクチャー上の問題点・課題をあぶりだすのが目的で、洗い出せたら通常の課題管理やPJ推進設計工程に引き継いで実施していきます。

当事者意識をもってシステム全体がどう動くかをみんなでシミュレートすることが重要です。

これらはＩＴアーキテクトが本来行っている手順の一部ですが、誰にでもできるように一般化してその人がいなくても一定のことができるようにすることが必要です。

まずは、ウオークスルー観点を入力として進め方一覧を作ります。

進め方一覧

ウオークスルーの内容と用意するツール、進め方では導入説明者を明示して何を議論に先立って説明してもらうかを明示します。

当日、ウオークスルーはすべてのサブシステムのリーダクラスに集まってもらいます。そのサブシステムの中身を説明してもらう必要があるため、中身が分かっている人が必須です。

司会はシステムの統括責任者が行うのが最適です。実際にウオークスルーを行っている中で指示をしたり、判断をすることが必要だったり、横断的な観点で話す必要があるからです。

１）テーマに沿ってまずは導入説明を行います。
導入説明はウオークスルーの最初10分くらいで軽く行います。本当に概略を説明するだけにしておきます。

ツールはシステム構成図を用いることが多く、なぜならデータの流れを見るのに最適な図であり使うと話がしやすいからです。

２）導入説明が終わったら、今後は観点をベースに、
○業務運用が考慮されているか（月次イベント・年次イベント）
○実際使う人が利用可能か（運用可能か）
○運用時間帯を考慮したつくりになっているか（制限事項は抜き出す）
○データの流れはどうなるか（無理なデータの流れになっていないか）
○必要なときに必要なデータが利用可能な状態で存在しているか
○技術的な無理はしていないか実際に業務を動かしてみたらどうなるか
など、そのシステムで懸念されている観点や運用観点でシステムとして動くかを実際に机上シミュレーションします。

システムの動きを机上シミュレーション
このとき、関連するサブシステムの人に質問をしながら心配事は無いか、分からないところは無いか、質問は無いかを聞きながら進めます。
その場で議論したり、課題の解決指示をすることもあります。
みんなが当事者意識を持ってシステムのイメージを持ってシミュレーションしていくのがコツです。

洗い出しの方法
ユーザの運用業務視点での業務AP・基盤AP・HW/PP・システム監視を通じて、システムのグループ間の整合が取れているかを検討すべきテーマの洗い出しを目的として行います。
あるプロジェクトの例です。
少数のリーダで、今回の場合はサブシステムリーダー以上で集まって行いましたが、ブレーンストーミング形式でプロジェクト全体責任者が誘導司会をしながら、網羅的に意見が出るようにしながら「心配事」「ユーザ視点で今回何が起こるか」「前から変わる点」「異常としてどんなことが想定できるか」などの観点でランダムに出していきます。
今回は１時間くらいで130件出ました。これをプロジェクトマネージメントチームが持ちかえって分類し、ファイルの「ウオークスルーテーマ」タブのように整理します。
このときにどういうウオークスルーテーマにするかがセンスを問われるところです。

「公開用ウオークスルー観点」
（内容は参考です：特定のPJを意識したものではありません）
先立っての準備としてこれを公開し、各担当に確認追記をしてもらいます。
「後での整理事項」は多くのグループをまたがないのでウオークスルーをするまでも無いが、課題管理するか質問としてグループが回答するか、みんなに周知すべき事項のものです。質問一覧として各担当に割り振り回答を記載してもらうものです。
テーマとして書いたもののほか、ウオークスルーに入れた方が良いかを各リーダに検討してもらい、入れる必要があるものはウオークスルーテーマに記載してもらいます。
「ブレーンストーミングアウトプット」はブレーンストーミングをやったときに出た内容です。
この○の結果を元にファイル中の「質問回答一覧」「説明会項目・課題管理項目」タグを整理します。

☆「質問回答一覧」
質問回答一覧はブレーンストーミングで出てきた各者の疑問点です。
解答欄に回答の記載をしてもらいます。回答方法は直接回答を記載しても良いし、資料の場所を提示することでも良いと思います。

☆　説明会項目
説明会項目はブレーンストーミングで出た内容のうち、ぜひ説明会で説明してほしいといわれている項目です。
説明会を実施してもらいます。ウオークスルーに絡めてその中で説明をしてしまっても良いと思います。

☆　課題管理項目
課題管理項目はブレーンストーミングで出た内容のうち課題管理したほうがいいのではないかという意見があるものです。
担当者が課題管理の要不要判断して課題管理すべきものは内部課題として課題管理してもらいます。

問題提起
業務とインフラがうまく整合があっていないとか、あっているかわからないというような事に出会ったことは無いでしょうか？わたしはよくあります。
システムアーキテクチャはシステムを実現するに当って一貫性を持って設計する必要があります。そのためには○○システムアーキテクトが実現する業務を踏まえてグランドデザインを行い、それをトップダウンで細分化して実装に落としていく必要があります。
とはいえ、現行システムのリプレース案件などで各サブシステムからのボトムアップでシステムをくみ上げる例もどうしても出てきます。
その場合にありがちなのが、システムの全体はすでになんとなくできてしまっいて、それぞれがその「制限」の中で実装を工夫している状態です。この「制限」が問題で実は一貫性のあるシステムでは変えるべきところである可能性があります。これを放置すると、ねじれたシステムが出来上がります。

どうしてそうなるのか。
いくつか原因は考えられますが、ちゃんと調整している(と思っている)にもかかわらず起きてしまう場合もあります。システムの内部課題として各々から質問として「これはどうなっているのか？」というものに対して、質問を受けた側は実装を考えた上で「こうなっている」と回答をすると、それが質問をした人にとっては前提条件となり大変だと思いつつもそのまま解決する方法を工夫して進めてしまっている場合です。本来は、実装に関して相談をしながら進めるのが良いのですが、お互いにその時点では案が無かったり時間が無かったりすると質問で終わらせてしまう場合にそうなりがちです。

全体整合をあとからとる
この場合はどうしたら良いでしょうか。今からでも遅くありません。全体の整合性を検証(システムウォークスルー)してみましょう。業務からHW・運用まで全般にわたっての人を集める必要があります。大人数になるかもしれません。
一人が全部わかるならばその人をシステムアーキテクトにして設計すれば良いだけなのですが、この場合は複数の人の知識や知恵を出し合って検証する必要があることを前提としています。
効率的なシステムのデザインという観点をぶらさなければ、全体工数を抑えることができるかもしれません。無理を解決する工数が削減できるからです。
システムリスクも減りますから後工程での工数も削減できます。
ここで言うシステムウォークスルーは、
「業務運用：業務AP：インフラAP：ミドルウエア：ハードウエア：監視運用
にわたって一貫性のある問題の無い設計になっているかの検証」とします。
アーキテクトはシステムグランドデザインを行う「役割」です。

システムウオークスルーの具体的な進め方についてお話いたします。
①テーマの洗い出し
②ウオークスルーの実施
③議事録の展開とトラッキング
という流れになります。

例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。