「システム導入に失敗しないための勘所」第3回です。
前回は、要求定義フェーズのざっくりした進め方として、まず将来の業務を定義し、それをインプットにして将来のシステム機能を定義すべし、とお伝えしました。また、業務やシステム機能を記述するためのフォーマットを例示しました。いずれも、精緻に書けばよいというものではなく、ユーザーを含む関係者がその良し悪しや抜け漏れ、優先順位を議論できるくらいの粗さ（あえて「細かさ」とは言いません）で書くのがコツである、とお伝えしました。
　
とはいえ、先日もお客様と「ファクショナリティ・マトリクス（FM）の粒度感の決め方が難しい」「FMだけでユーザーと機能の中身を議論するのは難しいがどうすればいいか」という話になりました。
　
そこで今回は、FMの粒度感を決める勘所と、ケンブリッジが「機能詳細」と呼んでいるドキュメントの書き方についてお伝えします。
　
なお、本メルマガでは、FMを「パッケージやSaaS選定のためのツール」という位置づけでご説明します。フルスクラッチでシステムを開発するケースについては、もちろんFMは作るのですが、粒度感の決め方が今回の内容とは異なりますので、割愛させていただきます。

　

　

昔話で恐縮ですが、1991年にケンブリッジが米国マサチューセッツ州で創業して以来、更新し続けている方法論が「Cambridge Rapid Application Deployment（ケンブリッジRAD）」です。「Rapid（素早い）」と呼称しているとおり、当時、要求定義フェーズのゴールは「とにかく早く『作る／作らない』だけを決めて、システム構築失敗の主要因であるScope Creep（要求の範囲が肥大化すること）を防ぐ」ことでした。現在のケンブリッジの方法論はそこからかなり進化してはいるものの、Rapidに「作る／作らない」を決めることと、それを実現するために特に気を付けている以下の3点は今も変わりません。
　
　・必要な人を巻き込んで議論する
　・使う意義のある機能を見極める
　・手戻りを防ぐ
　
これに照らし合わせると、FMの粒度は以下であるべきです。
(1)議論の余地がない機能は、粗い粒度で記述する。
(2)議論しないとその要否の判断がつかない機能は、その議論に必要な単位の粒度で記述する。議論を尽くして手戻りを防ぐ。
　
それぞれ、具体的にお伝えします。
　
(1)議論の余地がない機能

　
どの企業でも業務が変わらない、そして、どんなパッケージでもスペックが横並びであるようなケースです。
例えば、時給アルバイトの給与計算機能をFMに書くならば「給与計算（時給）」の1セルで十分でしょう。どの企業でも業務はさほど変わらず（「まるめ」の方法が異なるくらい）、時給の給与計算機能を持つパッケージであれば「時給登録」「勤務時間集計」「支給額計算」「まるめ制御」など、時給の給与計算に必要な機能は当然搭載していると考えてよく、議論のためにわざわざセルを分ける必要がありません。例えば「まるめ」に対する個別の要求は、この後ご紹介する「機能詳細」に記述します。
　

　
(2)議論しないとその要否の判断がつかない機能

　

その企業独自の業務要求に起因するような機能は記載すべきです。
例えば、これまで人事部が全国の店舗のタイムカードをファックスで受け取り時給を手計算で集計していたのを、改革施策のひとつとして、勤務時間を自動で給与計算システムに取り込める仕組みを導入することにしたとします。では、どのような仕組みを導入したいのか？　仕組みのイメージは、人によって異なるかもしれません。Webビーコンを使い入退室を自動で記録するような仕組みなのか、スマートフォンの勤怠管理アプリに自ら打刻するような仕組みなのか、によって、機能も費用も様々でしょう。対象者は何名程度いるのか、打刻忘れのリスクをどこまで許容するのか、など、必要な人を巻き込んで議論し、本当に使う意義のある機能を見極めていく必要があります。その結果は、後からFMを見た人（FMを見て見積をするベンダー、実際にその仕組みを使う店舗の責任者など）が「なるほど、そういう機能か」とパッと見てイメージできるような細かさで記述しなければいけません。
　
このように、一つのFMの中に、粗い記述と細かい記述があってよいことがお分かりでしょうか。
　
現場と議論する際には、このことをあらかじめ伝えておくとよいでしょう。最初は慣れないかもしれませんが「これはどこの会社も同じだね」「これはうちの会社独特だね」を切り口にして、議論をしていけばリズムがつかめてくるはずです。
　
粒度感とは若干異なるのですが、FMの網羅性についても、いくつかTipsを記載します。
　
FMの議論をする際には、情報システム部も巻き込み、ユーザーが普段使っている範囲以外の機能についても洗い出しましょう。具体的には、ユーザー管理やセキュリティに関するもの、帳票出力や経営管理に必要なデータ集計、システム間連携などです。これらは他の機能に比べると細かい機能がいくつもあり、セルの数が多くなることもありますので、その際は、FMにはセルを一つだけ記述し（「帳票出力」など）、別に一覧を別紙でつけるなどすればよいでしょう。
　
そしてFMの作成において最も重要なのは「今はいらない」「ここまでは不要」と思うものまできちんと残しておくことです。再々述べますが、FMの目的は「機能のいる／いらないを明確に分けること」です。ですから議論の中で「今はいらない」「不要」と決めたものについては、そうであると分かるようにしてFMに残しておきましょう。
　

　

2. 機能詳細を書く
　
FMはコミュニケーションツールなのですが、さすがにこれだけで「これはこういう業務に必要な機能です」とユーザーやベンダーと認識合わせするのは困難です。ケンブリッジでは、FMのもう一段詳細なドキュメントとして「機能詳細記述書（Functional Specification Sheet）」を作ります。社内では「機能詳細/Function Spec」と呼称しています。
　
Function Specにも、機能の複雑さに応じていくつかのフォーマットがありますが、ここでは、ケンブリッジでも最も一般的なものをご紹介します。

　

　

システム会社が要件定義書で書くような粒度では決してなく、ユーザーと「これで将来業務が回りそうか」を議論できるくらいの粒度感であることがお分かりでしょうか。
　
Funcion Specを記述する際の注意点は、手段ではなく、あくまで要求を書くことです。例えば「XX画面に〇〇を表示したい」といった手段ではなく、「△△を実施する際にスムーズに〇〇を参照したい」といった具合に、業務の流れの中で、どのタイミングで、なんの目的でシステムを使いたいか、を書くのに留めることです。手段まで議論し始めると時間がかかってしまいますし、システムのプロであるベンダーに任せたほうがいろんなアイデアを提示してもらえるからです。
　
　

　
今回は、FMとFunction Specの書き方のコツについてお伝えしました。まとめると、「ユーザーとコミュニケーションできる粒度である」「あくまで業務目線で作る」「やらないことまで書く」の3つです。あくまで将来の機能を決める主体はユーザーであることをお忘れなく。

次回はFMを使った機能の優先順位付けについてお伝えします。