「システム導入に失敗しないための勘所」第2回です。前回は、システム導入を始める前に「そもそも改革で何を目指すのか」「目指すゴールと現状にどんなギャップがあるのか」「将来のビジネスモデルに本当にシステム導入が必要なのか」などをきちんと関係者で議論し合意すること、システム導入が必要だからといってすぐに要件定義に入らず、まずは「要求」定義をして作るものと作らないものを切り分けることが極めて重要、とお伝えしました。

今回から、要求定義フェーズの進め方についてお伝えします。

　

　

要求定義フェーズで最初にやることは「将来あるべき業務」の定義です。
いきなりシステムのことを考えるのではなく、まず、今の業務をどう変えるか、将来どのような業務をすべきか、をユーザーと議論し決めていきます。改革の主役はあくまで現場のユーザーです。しかしユーザーに「どんなシステムにすべきか」をいきなり問いかけるのはお門違いです。あくまで業務目線で「将来あるべき」をひざを突き合わせて議論するのです。
　
将来の業務を記述せよ、といきなり言われると、雲をつかむような作業に思うかもしれません。しかし、今まで誰もやったことのない全く新しい事業を起こすのでない限り、現状の課題に立脚した将来像であれば、これまでに積み上げたドキュメント（改革のコンセプト、現行業務の棚卸し結果および課題の分析結果、将来のビジネスを実現するための施策一覧など）を活用すれば、まったくゼロからの作業ではないことがおわかりでしょうか。各業務領域のトレンドを押さえたビジネス書籍も役に立ちます。それでもうまく将来業務を定義できない場合は、もう一度、現行業務をECRSの原則（なくせないか、統合できないか、変えられないか、シンプルにできないか）などで見直してみてください。
　
将来業務の表現方法は、業務の複雑さに拠ります。
よく「業務フロー形式で書くと時間がかかるのですが・・・」とご相談をいただきます。フローチャートやスイムレーンチャートは、あくまで業務の分岐が多発するケースや、業務を遂行する部署が横断するケースに有効な表現方法です。もし、単一の部署で、順を追って遂行するような業務であれば、一覧形式で十分です。「なんとなく様になっている資料」を時間をかけて作るのが目的ではありません。ユーザーを含む関係者が「これならわかる、良し悪しや改善点を議論できる」と思える必要十分な情報量を表現できる方法を採用しましょう。

　

ケンブリッジでは、将来業務の複雑さに合わせて、以下のフォーマットを使い分けています。
　

　

　

将来業務の記述範囲については、改革のコンセプトや範囲、施策の方向性などで、ある程度決まってきます。また、現状業務を踏襲する部分があったとしても、その部分を省略してはいけません。なぜなら、将来業務に関するドキュメントを一度きちんと作れば、後続のフェーズで、導入を決めたシステムのカスタマイズ箇所の確認、テストケースの作成、業務マニュアルの作成などに活用できるからです。

　

将来業務の記述粒度は「ユーザー同士でシステム機能の要否を議論できる程度」「今後、選定するパートナーが読んで『あぁこういう業務をするんだな』『この業務でシステムを使いたい／使わないんだな』と理解できる程度」に留めましょう。ここで大幅に時間を取ってしまうと、本丸である「どんなシステムを作るか／作らないか」の議論ができなくなります。特にシステムを使わない業務については、時間を使いすぎないよう注意が必要です。例えば、ドライバーが顧客への商品の配送ルートを平日と休日で変えていたとしても、それがシステムの機能に関係なければ、シンプルに「顧客へ商品を配送する」とする、など、チームであらかじめ粒度を合意してから記述に取り掛かりましょう。

　

記述の漏れを防ぐコツとしては、現状業務のヒアリングの時と同様、大きく業務のパターン（例えば、販売チャネルや請求方法など）をざっくり定義してから詳細を記述すること、年間のイベントカレンダーを使い業務の流れを追っていくことなどがあげられます。

　

　

将来業務を言語化できれば、いよいよ、その業務を実現するためのシステム機能を棚卸しします。
ケンブリッジでは、これを「ファンクショナリティ・マトリクス（通称FM）」と呼ばれるシートで表現します。

FMは通常、このような形のものです。縦軸に機能グループを定義し、横に機能名を記述していきます。

　

　

FMの利点は「視認性の高さ」です。再々申し上げるように要求定義フェーズは「作るものと作らないものの切り分け」をするフェーズです。その機能を将来使う予定のユーザーとFMをベースに機能の切り分け議論をし、その結果をFMに視覚的に表現していきます。具体的には、今すぐ作るものの背景は白、作らないものは黒、今すぐ作らないものはグレー、といった具合に色分けをしていきます。そうすると、どれくらいのボリュームの機能をすぐに作ろうとしているか、をパッと見てすぐに把握しやすい、というメリットがあります。もちろん、FMは本質的には機能一覧です。マトリクス形式ではなく一覧形式で書いても、視認性は低くなりますが、果たすべき役割は変わりません。ユーザーと機能切り分けをするためのコミュニケーションツールとして成立していることが重要です。
　
FMで機能をプロットしていく際、最大のインプットは、もちろん、先に作成した将来業務の定義書です。しかし「これだけで機能を書けと言われても」と戸惑う方もいらっしゃるでしょう。そういう場合は、以下のようなドキュメントも役に立ちます。
　
・その領域の主要ベンダーの製品説明文書（Webサイト、パンフレット、場合によってはRFI回答）
・事業領域、技術領域のトレンド書籍
・社内の全体システムアーキテクチャー（社内の別システムとの連携が必要なケースなどは、機能を追加します）
　
よく「現行システムの機能ドキュメントをそのままFMにしては」とおっしゃる方もいますが、ケンブリッジでは推奨していません。なぜなら、社内にあるシステム関連のドキュメントはシステム会社が作ったものが多く、ユーザー目線で作られていないためです（粒度が細かい、技術用語で書かれている、など）。先にも述べた通り、FMはユーザーとのコミュニケーションツールですから、ユーザーフレンドリーでないものを作っても意味がありません。それに必ずしも、現行システムの機能ドキュメントが、稼働後もきちんと更新され続けている保証もありません。
　
　
今回は、要求定義フェーズで、一見すると作成するのが非常に難しいドキュメントの、意義と作り方のコツについてお伝えしました。手をこまねいていてもしょうがないですから、まずは作ってみましょう。そして、改革の主役であるユーザーと議論しながら、中身をブラッシュアップしていくことが重要です。次回は、FMの作り方や使い方について、さらに深掘りしていきます。