安定したシステム開発を作るユーザーレビューのコツ

上流工程でユーザーレビューを行い品質をつくり込む

バグは後工程で発見されるほど手直しに時間がかかり、コストがかかってしまいます。要件定義などシステム全体の機能を決めていく上流工程で、ユーザレビューを実施しチェックします。

システム開発を外部委託した場合、ITベンダーが発注側（ユーザー企業）の業務分析やヒアリングを行い仕様書にまとめます。ある程度、仕様書がまとまった時点でユーザーレビューを行います。この時に重要なのが森を見ること。

ITベンダーは、どうしても得意分野であるシステムをどう構築するかデータベースをどう持つかなど技術的話題にもっていきがちです。これはユーザー企業側も同じで、ユーザー企業のシステム担当者がレビューに出席するとITベンダーと技術的な話で盛り上がってしまいます。

木を見ずに森を見ること。ユーザー企業は業務知識が豊富な担当者をレビューに参加させ、レビューの目的は機能要件の確認であることを皆で認識し、枝葉の話に陥らないようにします。

重要なのは、業務フロー全体を確認して漏れている業務がないことを確認することです。新システムの開発では既存システムとの連携ができているか確認します。例外処理が起きた時の対処も重要です。想定外の事態が起きた時は、システムを主要な機能だけ動かして他は性能を落とす（縮退運転）など機能として盛りこんでおかなければなりません。

ユーザーレビューが終わったら、レビューで指摘された部分が正しく修正されているか再レビューを行います。修正指示が伝わっていない、相手が勝手に解釈していることはよくあります。再レビューで確認し、品質を作りこんでいきます。

ITベンダーは形式知になっていることを確認

ITベンダー側は、暗黙知が形式知になっているか確認が必要です。ユーザー企業側は業務に精通しているので、業務的に当たり前だと思っている項目はITベンダー側も当たり前だと思っています。これが暗黙知。

工程が進んでいくと、レビューなどで「なぜ、この機能が入っていないんですか？」とユーザー企業から質問が出ます。「そのような機能は口頭でも聞いていませんし、資料にも入っていませんでしたよ」と答えると、「そんな当たり前の機能は常識でしょう」と返ってきます。

ユーザー企業の常識は世間の非常識という認識をもちながら、ITベンダーは業務をまとめていかなければなりません。ユーザー企業も認識を改める必要があり、とくに現場どっぷりの担当者に仕様を確認する場合は要注意。ユーザレビューの機会を活用し、仕様漏れをなくしていきます。

開発工程ではウォークスルーをうまく活用する

開発がすすむとITベンダー内でレビューを行います。上席者が出席する公式レビューやインスペクション以外に、非公式に行うウォークスルーがあります。

ウォークスルーとはもともとは演劇用語で立ち稽古の意味があるように、フォーマルなレビューではなく開発プロジェクトの内輪メンバーが集まって行うレビュー。開発者が息づまったり、意見を聞きたい時に招集します。インフォーマルな会議ですので管理職は参加しません。

時間は30分から長くても1時間ほど。短時間で効率よく行うため、参加者には事前に資料を配って読んでおいてもらいます。開発者が仕様の説明をしながら、皆で問題点を探したり解決策を討論します。時間帯は集中しやすい午前中などの時間帯にし、邪魔が入らないよう会議室を予約しておきます。