コラム

前回のコラムでは「RFP（提案依頼書）作成の勘所」と題して、「なぜ」「だれが」「どのように」の3つ視点から説明をしました。 「なぜ」は情報システム化の設計書として、後々、プロジェクト遅延や予算オーバーに陥らずに経営計画を具現化するため。
「誰が」は自社が主体性を持って想いを詰め込むことで、結果的に満足度の高い情報システムができる。
「どのように」はPRFの情報が曖昧にならないよう過不足なく、多くのシステムベンダーが理解しやすいRFPを作成する。場合によっては外部支援を仰ぎ、自社の想いを正確に記載することが重要。という結論でした。
どの項目も後々自分たちのメリットとなるので、「なぜ」「だれが」「どのように」の3つ視点を十分意識してRFPを作成することが、良い提案依頼が出来ると理解していただけたかと思います。

さて、RFPをまとめるためには要件や要望を洗出し、利用者が業務を進める際に情報システムを使って何がしたいのか、何ができなければ困るのかといった内容をまとめる「要件定義」という作業をまず行います。

「要件定義」を実施していく上で、社内外含め多数の利害関係者にヒアリングを行い要件や要望をまとめていくため、会社の規模が大きくなればなるほど利害関係者の人数も増えて、日程や内容のすりあわせなどの調整が非常に難しくなっていきます。 今回のコラムでは、これら「要件定義」の作業をスムーズに進行させるために、必要な準備、実際の進め方とその終了条件について説明していきます。

要件定義前の準備

1.　要件の種類を知る
要件定義は「誰に」、「何を聞くのか」によっていくつかの分類があります。これらを捉えておくことで、スムーズなヒアリングが可能になり、また後々のRFPを作成する際に提案依頼の内容が誰から出たものなのかが明確になり、システムベンダーにも提案の強弱が伝わりやすくなります。具体的に以下のような分類になります。

要件定義は大きく機能要件と非機能要件の2つに分かれ、機能要件は更に業務要件、ユーザー要件に分けることができます。機能要件とはソフトウェア側に期待すること、非機能要件はハードウェアやインフラ等に期待することと位置づけられます。そして、機能要件をブレイクした業務要件は情報システム導入の目的を示しており、これは「経営者」の要望といえ、もう一つのユーザー要件はまさに「現場の人達」の要望ということになります。業務要件、ユーザー要件をブレイクせずに機能要件と分類することもありますが、ここでは2つに分けて説明をしていきます。

第1回のコラムでもお話しましたが、経営者から見た場合、情報システムは「経営計画」実現のためのツールであり、業務の基本的要件として組み込まれます。

本コラムのテーマである海外拠点への情報システム導入の場合、経営者の要件として、現地への投資対効果および進出・撤退の判断材料などの情報取得が業務要件となります。これらを計る主な指標としては、売上高、期間利益額、売上高利益率、原価管理、予実管理等があげられますが、海外子会社は国内事業部と比べて単純に売上高を重視する傾向があります。それは日本本社では、現地の環境変化を細かく考慮して指標の数値を分析することが難しいためです。しかし、本来、海外進出後の経営判断の材料として、どのような要件が必要かを上げるのであれば、国内にはない指標も必要となることは明白です。予実管理を例に取ると、昨今の円安傾向をタイムリーに予算に反映し、実績金額とより現実的な対比をおこうといった要件が必要になりますが、これは国内でも輸出入などを行っている企業では当然のことです。しかし、海外ではニュースに出てくるような、現地情勢や事件、マーケットの動きや雇用の問題などの影響を大きく受けて、予実に限らず指標数値が瞬時に変わる可能性があるため、海外拠点の経営戦略として重要視している指標と受け取りたいタイミングなども正確に伝える必要があります。

一方、現場から見た場合の情報システムは「運用方法」そのものになり、ユーザー要件として組み込まれます。海外拠点導入の場合は、まずは現地言語、現地通貨の対応が要件となります。例えば、現地政府への報告書は英語が必要だが、日本本社への報告書は日本語にしたい、実際の取引する通貨と報告する通貨は別なので複数通貨を管理しなくてはならないなど、日本国内の機能要件だけでは不足してしまいます。
ただし、ユーザー全員の要望を吸い上げていては、要件はまとまりません。後述の進め方でも記載しますが、各業務のリーダーを決めて、その人を中心にヒアリングするか、各部門の承認権限者と一般職員一名ずつに参加してもらいヒアリングするケースが一般的です。 また、経営者の要望である業務要件との整合性の確認も必要で「やりたいこと」よりも「やらなければならないこと」を優先することが重要になります。

2.　登場人物の確認
要件定義の参加者は大きく3グループに分けられ、それぞれの役割と重要なミッションは以下の通りです。

(1)　情報システムを利用する現場担当者や情報システム担当者からの要望や課題を評価し、導入可否の判断を行う経営者
　　①　会社の進む方向について、社員に正しく伝える
　　②　情報システム投資の方向性を伝える

(2)　利害関係者をまとめる人（主に情報システム担当者）
　　①　経営者と会話し、情報システムを活用した業務改革を企画する
　　②　最新の情報システムについて、自社での活用内容を提案する
　　③　現場担当者とシステムベンダーとをマネジメントし、自社に有効かつ優先される要件を取りまとめる

最後の利害関係者をまとめる人は、現在社内で使われている情報システムを管理し、既存システムのベンダーとの窓口になっている情報システム担当者が担当することが一般的ですが、社内に明確な情報システム担当者がいない場合は次のような利点を生かした人員選出を行うケースがあります。

・　情報システムにあまり詳しくない営業部長
自社を引っ張る力、関連部門をリードできる力を持っており、企業活動の根幹を知り尽くしているため業務改革もリードできる。本人が情報システムに詳しくても理解する努力を周りに示すことで、他の多くの従業員も理解に努めることが出来ると考えられる。

・　経営企画部長
経営者と共に企業活動を活性化させる戦略立案及び現場への指示を行っているため、双方からの要望への理解やそれらの統合力に長けており、バランスの取れたプロジェクト促進が出来ると考えられる。

・　外部コンサルタント
豊富な経験と知識の活用および、利害関係者の調整やプロジェクト管理などを第三者としての客観性を活かして実行できると考えられる。

３.　要件定義の参考になる資料
要件定義に伴い、事前に準備した方が良いものは、以下のようなものです。
(1)　中期経営計画書
(2)　業務マニュアル
(3)　業務記述書
(4)　業務フロー図
（1）は業務要件（経営者）のヒアリングの際に、新情報システム構築に向けた基本的な方針等を確認するための資料となります。
（2）（3）（4）はユーザー要件（現場）のヒアリングの際に、現状の課題や要望、リスクや重複業務などをプロセスの中から抽出する際に使用します。

要件定義の進め方

(1)　プロジェクトメンバー決定
前述した登場人物を参考にメンバーを選出します。

(2)　各方面の業務ヒアリング
プロジェクトメンバーを中心にヒアリングを行います。効率的かつ正確に業務ヒアリングを行うための重要な要素は以下の通りです。

　　①　ヒアリング実施担当者は2名×1チームで実施する
　　②　ヒアリング対応者にヒアリングの目的を事前に伝えておく
　　③　ヒアリング結果を迅速に文書化する

1つ目の要素の人数構成についてですが、ヒアリング実施担当者は2名の1チームとし、1名をヒアリング担当、もう1名をヒアリング結果の書き取り、兼、脇道にそれた際の軌道修正係とする構成がベストです。二人で聞き漏らしを防止する目的もあり、三人だと内容に誤解が発生したとき、誰が正しいのかを判断できないケースが出てきます。

2つ目の要素としては、ヒアリングの対応者にヒアリングの目的を事前にしっかり伝えておくということです。通常、各業務担当者は自分の業務を守りたがるものなので、ヒアリング後に業務内容ががらりと変わってしまう事への抵抗感から、非協力的になりがちです。しかし、ヒアリングの目的を正確に伝えることで「良くなるのであれば」と自分の業務を変えることに前向きになります。さらに、「よくしたい」から、「今がこんなに駄目なんだ」といったように、担当者の現状の不満が多く出てくることもあります。これらの不満には大きな課題を発見するための有益な情報となる場合もあるため、すべてを否定してはいけませんが、ヒアリングの目的と明らかにそぐわない意見を防止するためにも目的をはっきりさせることが重要です。

(3)　現状の業務フロー図の作成
要件、課題をピックアップするには、現状の業務プロセスを知る必要があります。現在、業務システムを利用しているのであれば、「業務フロー図」や「業務マニュアル」といった文書を参考にする場合もありますが、ほとんどの場合、部門間の連携が記載されていなかったり、重複業務の記載が不十分であったり、非システム部分の記述や承認の有無などの記載がないケースがあるため、実際に現場責任者の話を聞いて業務フロー図を作成し、メンバーが共有できるようにする必要があります。この業務フロー図をベースに現行業務プロセスやシステム関連を把握し、その他の課題や要件等もヒアリングした上で文書にまとめていきます。全体に関わる大きな課題はヒアリング時に多くの人が口にするため早期に判明しますが、漠然と思っていたことを文書として明確化し、共有することで、原因や解決方法などを議論することができるようになり、あるべき業務プロセスや新情報システム構築条件としての要件に付け加えることができるようになります。

(4)　課題・要件の整理
要件・課題は、「誰が」「どの業務で」「どんな課題があり」「どのように解決できるか」「期限があればいつまでにやらなければならないのか」などを一覧表にすることにより、情報をメンバー全員で共有し、網羅的に管理することができます。また、経営戦略上の必要性やコンプライアンス対応など、優先的に取り組まなければならない課題や要件を明確化することにも役立ちます。

(5)　新業務フロー図（あるべき姿）の作成
現状の業務フロー、課題・要件を把握した上で、新業務フロー図を作成します。必要な要素は以下の通りです。

　　①　システムベンダーには参画させない
　　②　業務の当事者以外も参画させる
　　③　業務の標準化・共通化を意識し、よりシンプルに理想形を描く

1つ目の要素が最も重要です。システムベンダーが参画してしまうと、「あるべき姿」＝「ERP標準業務フロー」になってしまうことが圧倒的に多くなります。またシステムベンダーが提案する製品を前提に話を進めて行く可能性があるので、あるべき姿から逸脱することがあります。会社側があるべき姿を自ら考えた上で、それを実現できるERPパッケージを採用すべきです。

2つ目の要素は、当事者以外の発想を有効活用することが望ましい、ということです。業務のやり方を180度変更したいと考える当事者はまずいません。しかし、保守的になりすぎず、少し大胆な発想があってこそ「あるべき姿」の求めるものであり、そのためにさまざまな角度から客観的に業務プロセスを見ることが出来る視点や、複数部門に跨る業務を部門横断的に見ることが出来る視点が大変重要になります。

3つ目の要素は、2つ目の要素にも関連しますが、会社の「あるべき姿」は現状の業務プロセスに縛られずによりシンプルな理想形を描くべきということです。また、理想形を描く際には、業務の標準化・共通化を十分意識して検討すべきです。これにより、イレギュラーが減少し、多くの従業員が同じプロセスで仕事が出来るようになるため、情報システム構築に関しても工数が削減できます。ただし、個別の顧客に係わる業務や非効率となる業務に関しては、業務の標準化・共通化は必須ではないこともありますので、こだわり過ぎず、残さなければならない業務の検討も十分にする必要があります。

(6)　RFP（提案依頼書）としてまとめる
最後に要件、要望を実現しつつ、今の課題を解決し、効率的かつ標準的でシンプルな新業務フローを実現するための提案をしてもらうために、RFPにまとめます。このときシステムベンダーに当社の現状と進むべき未来が正しく理解できるように記載します。（まとめ方は第二回RFP（提案依頼書）作成の勘所を参考のこと。）

要件確定終了条件

(1)　組織の壁
「利害関係者をまとめる人」は必ずどこかの組織に属しており、組織間に乗り越えないといけない壁がありますが、「経営者」はそれを簡単に乗り越えられます。

(2)　経験の壁
「利害関係者をまとめる人」は経験を積んで成長しますが、利害関係者の中には自分より先輩だったり豊富な経験を持った方がいます。「経営者」はそれを上回るリーダーシップを発揮することが出来ます。

(3)　予算の壁
「利害関係者をまとめる人」が持っている（考えている）予算と「経営者」が考えている会社全体としての投資額には違いがあります。双方をバランスよくすりあわせる努力が必要です。

(4)　決断の壁
「利害関係者をまとめる人」と「経営者」の決断することができる事項及び範囲には違いがあります。経営者は頻繁に現場に行き、利害関係者はこまめにわかりやすく経営者に進捗等を報告し、決断するための材料に齟齬がないように努める必要があります。

このように、どの企業においても4つの壁が存在します。「利害関係者をまとめる人」にとっては、とてつもなく大きな壁になる可能性もあり、時間ばかり取られて、調整が難しくなります。「利害関係者をまとめる人」と「経営者」が協力して乗り越えることが大切です。

最後に、
今回「スムーズな要件定義方法」についてお話ししてきましたが、課題のみの解決ではなく効率的で仕事のしやすい業務の流れや方法を現場から要件として吸い上げ、重要性やコスト、期間なども考慮した上で優先順位を付けて社内合意をとり、最後にシステムベンダーにRFPを提出します。但し、要件定義はこれだけでは絶対に終わらず、情報システム構築中も増えていくという事を認識する必要があります。そのことを認識した上で、RFPに記載する段階で線引きをする必要もあります。いつまでも重箱の隅をつつくような検討をしていると、あるべき姿も描けなくなり、本来の目的や方向性を失うことにもなりかねません。先の4つの壁を乗り越えるためにも、経営者に協力いただき、要件をまとめていくことが最も重要になります。

次回は海外拠点情報システム導入する際のRFP（提案依頼書）を参考によくある海外要件を確認していきます。

第4回コラム『海外拠点情報システム導入RFP（提案依頼書）』に続く