今回は「ユーザのための要件定義ガイド」第4章（４・１・３）「ゴールの抽出」から要件定義に当たっての「（１）経営レベルの目的・目標を明確にして共通認識する」について考察してみたいと思います。
ガイドでは以下のように述べられています。（抜粋）
一般的に、経営方針やシステム化方針は、構想立案や計画立案で打ち出される。要件定義工程では、この経営方針やシステム化方針を達成できるように業務要件やシステム化要求を定義しなければならない。しかし実際のプロジェクトを見ると、要件定義の内容が手作業の機械化や操作性向上の検討に終始し、経営方針やシステム化方針が置き去りになっていることがある。
（中略）
⑴経営レベルの目的・目標を明確にして共通認識する
【解決したい問題】
•経営に貢献する要求、経営方針に合った要求が抽出されない
•経営レベルの要求を収集していない
•経営レベルの要求を経営層と確認していない
経営やビジネスに貢献する要求を抽出するためには、経営レベルの目的・目標や施策が明確でなければならない。本来は、経営レベルの要求は、構想立案書やプロジェクト計画書など事前の工程の資料に掲載されているか企業方針などで明確になっているはずである。しかし、これらが不明確のままプロジェクトが開始されることもある。その場合には、経営レベルの目的・目標や施策を確認し、必要があれば整理して経営層に確認を求めることが必要になる。
（以下、「勘どころ」として以下が列挙されています。）
勘どころ① 経営レベルの目的・目標、経営施策を明確にする
勘どころ② 経営レベルの目的・目標を見極める
勘どころ③ 経営施策(手段)を見極める
上記のように、要件定義の工程で経営レベルの要求を収集・確認していないことが問題として挙げられています。
方や、ガイドではP74「要件定義の位置付け」で下記の図のように工程を定義づけています。
これでは、要件定義の工程において、あたかも企画工程の成果物である「システム化企画書」が全く参考にされていない事態が起こっている・・・と言っているかのようです。
ガイドの執筆者の体験的事象なのでしょうが、「勘どころ」として捉えるべきは企画段階の問題だと思います。どうも、要件定義を語る多くの方々はこの「企画」を軽く考えておられ、何か大きな目標さえ定義できていれば良いと思っておられるように感じてしまいます。
筆者は、「企画工程」も「要件定義工程」も同じ流れの一部だと考えています。なぜならば、この二つの工程の間の違いとは「粒度」の違いだと思っているからです。
最も高いレベルである「経営の要求」とは、非常に「抽象度」が高いレベルです。従って企画工程ではこの抽象度を下げる行為によって、要件定義が出来るレベルまで抽象度を下げる必要があります。
具体的な事例で考えてみたいと思います。
「システムを作らせる技術：エンジニアではないあなたへ」白川克＋濱本佳史著（日本経済新聞社）に以下の事例が紹介されています。
事例③ 本当に標準化すべきか? を逃げずに議論した
ある金属加工メーカーは全国に4つの工場を持っていたが、各工場が近隣から原料を仕入れ、近隣に販売する、最近では珍しいビジネスモデルだった。合言葉は地産地消。金属は輸送費がかさむため、合理的ではある。その結果、同じ商品を作っているにもかかわらず工場ごとの独立性が高く、ビジネス慣習も業務プロセスもシステムもバラバラな状態が創業以来長く続いた。
いくつかの工場のシステムがメンテナンス困難になってきたためにシステム再構築の構想がスタートした。プロジェクト名は ONE。つまり、これを機に全社統一のシステムの上での、全社で統一された仕事のやり方に改める決意を込めた名前だ。
だがプロジェクトがスタートしてしばらくは、プロジェクト内にも、それを取り巻く人々にも、「本当に標準化なんてできるのか?」「今までそれぞれの工場が独自に工夫を重ね、競い合うように発展してきた。それのどこがいけないんだ？」というムードが漂っていた。
この 「本当に標準化/統合化すべきなのか?」というテーマに、一度は腰を据えて向き合う必要がありそうだ。「標準化」はー見合理的で反対しにくいが、そういう綺麗すぎる旗印をゴールに掲げると、大抵はただのお飾りになってしまう。本気で目指していないので、プロジェクトが具体的な検討をする段階にくると「総論賛成だが、各論には反対」が巻き起こり、妥協に妥協を重ねることとなる。
そうなるといっしかゴールを誰も口にしなくなり、「このシステム、完成して誰が嬉しいんだつけ?」と思いはじめる。それは避けなければならない事態だ。そこでこの「本当に標準化すべきか?」についてとことん議論する合宿を開くことにした。
議論は3時間におよんだ。まずは標準化することのメリット、デメリットの整理から(図G1の議論1)。こういった漠然としたリスクや不安は、一度全部書き出してしまうと「とはいっても、これで全部か……Jと安心できる。全貌が見えないから必要以上に心配になるだけなのだ。もちろんプロジェクト発足当時から目指している標準化のメリット(だから標準化すべきなんだよね)を再確認することも必要。
次に 「一口に標準化すると言っても、どの程度?」と、あえて漠然とした問いかけをした(議論2)。妥協なき完全標準化を主張する人もいれば、「俺は真ん中くらいで十分だと思う。なぜかと言えば、地域ごとの商慣習に合わせなければ商品が売れないから」と営業での経験を語る人もいた。
最後にこれまでの議論のまとめとして、「一口に標準化といっても、ルールの標準化もあれば、データの一元化、システム機能の標準化など、切り口は色々ある。それぞれどの程度標準化すべきなんだろうか？」という議論をした(議論3)。
結論としては、ルールやデータは完全に標準化・一元化する。そして業務とシステムについては、2つに分けて考える方針となった。
•顧客に接するフロント業務は、地域特性ごとにある程度のバラバラさは許容する。会社の競争力を維持する上で必要だから
•一方でバック業務 (事務処理など、顧客に接しない業務)は全社で標準化しない理由はない
この方針を決めた後、将来業務を検討する際やシステム機能の洗い出しをする際に何度も 「ウチの工場で今やっていることと違う……」という議論になった。だがこの方針のおかげで 「でも、これは顧客には直接関係のないバック業務なのだから標準化できるはずですよね？」と、立ち戻ることができた。
「全社で標準化します」という聞こえがいい方針に、改めてとことん向き合ったことが、この事例のキモである。「システムが老朽化したので作り直そう。バラバラに作ると投資金額が膨らむから標準化しよう」というよくあるストーリーでは、このプロジェク卜は頓挫してしまったに違いない。
この事例では、当初「標準化」が企画案としてでされたが、あまりに抽象度が高く現場の実態にそのまま落とし込むのにはは無理がありました。そこで「一口に標準化すると言っても、どの程度?」と言う問いかけをして抽象度を下げる議論をした結果、「フロント業務は標準化しない」「バック業務は標準化する」と言う大方針が決まったのです。
繰り返しになりますが、筆者は業務改革＋システム開発とは、最も上位に位置づけられ、抽象度の高い「経営要求」を、構造化して抽象度を下げ＝具象化する一連の作業だと思っています。企画工程・要件定義工程・開発工程などと分けるのはあくまで「便宜的」な区分けであり、根本の点では一本の川のようにつながっているものだと思います。
ガイドでは「経営レベルの要求を経営層と確認していない」と指摘していますが、実際問題として経営層（例えば社長）は抽象的な観念を示すだけで、何か「具体的な」要求を示せることは極めて稀だと思います。従って、後段の事例に示された「現場を知る人間による検討」がまずは必要であり、これがユーザの手による要件定義のスタートラインだと考えます。