エンジニアからコンサルになるときのブレークスルーその５
こんにちは、水上裕介です。
GWですね。いい天気が続いています。皆様いかがお過ごしでしょうか。
さて、前回はファクトについて私が思うことをコラムしてきました。今回はコンサル視点でファクトをどのように育てていくか（効率的に作成する方法）をコラムしたいと思います。
■仮置きファクトを作る前に前提を把握する
前回のコラムで触りだけ話しましたが、仮置きファクトが精度の高いファクトを集める重要なポイントです。すでにファクトが自明なプロジェクトもありますが、今回は10社ほどの開発ベンダが関係するデータ移行プロジェクトを例にファクトが整理できていない状況を考えます。
仮置きファクトの作成の前に、目的、場（会議体）、マイルストーン、体制を正確に把握する必要があります。
- 目的は、旧システムから新システムへの切替に伴うデータ移行およびシステム切替を成功させること。
- 場については、Weeklyで開発ベンダへのヒアリングの場があるとする。
- マイルストーンについては、ローンチまで６ヶ月、要件定義/設計期間が１ヶ月、製造が１ヶ月、テストが２ヶ月、その他２ヶ月とする。
- データ移行チームが２名、システム切替チームが１名とする。私はデータ移行チームのメンバに属する。
今回は上記を前提として仮置きファクトの作成方法を考えてみます。
■仮置きファクトのインプットを収集する
１０社ほどのベンダにヒアリングをかける前提なので、１社１社に細かいことまでヒアリングしていては終わりませんし、そもそもそのような非効率はことをやっていてはコンサルは務まりません。
ヒアリングの基本戦略としては、データ移行に関係するベンダが所持しているインプット（要件定義書、基本設計書など）を収集し、それらをExcelで一覧化し、インプットから読み解ける点、読み解けない点を明確にした上で、Weeklyの場でベンダに回答してほしい点や回答依頼の趣旨を説明する。その回答結果からさらに詳細を確認すべき点は個別にベンダに問い合わせることとしました。
ここで、重要なことは、ベンダが所持しているインプットは、要件件定義や設計という観点ではファクト（仕様）であるということです。さて、現実のプロジェクトでは、ベンダ１社におけるインプットの整合性が合わないこともあるし、１０社となると各ベンダ間のインプットの整合性がきっちり合うことは奇跡といってもいい状況が現実にあります。
データ移行という観点では、ベンダ１０社の整合性が合って初めて意味があるファクトになります。そのためインプット（要件定義書、基本設計書など）と表現しています。さて、ここで間違えてはいけないのは、インプットの整合性を合わせることが仮置きファクトを作ることではないということです。上述した目的に合致するかという観点が重要です。目的に合致しないことには、いい意味で鈍感になり、合致することには敏感になり、本質を掘り下げる姿勢と考え方が重要と換言できます。
■仮置きファクトを作る
さて、前置きが長くなりましたが、仮置きファクトの作り方です。データ移行チームのミッションは、新旧システムの業務データのマッピング（対応関係）を正確に把握することを目的とします。データ移行プランがフィージブルであるかという全体的なプランはシステム切替チームが担当することとします。
業務データのマッピングの大分類としては、以下を意識すると効率的です。
- 新規で作成されるデータ
- 移行すべきデータ
- 捨てるべきデータ
1. および 3. はそもそもデータ移行からスコープアウトできることを意味しています。やらないこと、やるべきでないことを正確に定義できれば、やるべきことだけに時間を使うことができます。
それらを大分類としたデータ項目を網羅的にExcelで一覧化し、ベンダにデータ項目が必要か理由を含めて回答してもらうことで、1.および3.を抽出することができます。当然ですが、ベンダに確認せずにデータマッピングを定義することは絶対にやってはいけないことです。あくまで答え（ファクト）を持っているのはこの例ではベンダになります。
■次回
最後までお読み頂きありがとうございます。
次回は仮置きファクトからファクトに育てる過程をコラムしたいと思います。
前回までの記事は以下にあります。