プロジェクトのゴールを設定する

前回のおさらい

ユーザー側でのシステム導入にあたって、プロジェクト計画書をベースにシステム導入の勘所とRFPに記載すべき要件をお話ししていく「システム導入のエッセンス」、第４回目です。

前回まで一般的なプロジェクト管理手法であるPMBOKやPM7Keysを元に、ユーザー側でチェックすべき以下の７つのポイントを紹介しました。

１．ゴール
２．スコープ
３．スケジュール
４．チーム
５．コミュニケーション
６．コスト
７．リスク

今回からはこれらを１つずつ考察しながら、RFPやプロジェクト計画書として落とし込んでいきたいと思います。

ゴールがあればスタートがある

プロジェクトのゴール＝目的を明確にする。
言葉にするのはとても簡単です。

システム導入をすることで、これをできるようにする、これを省力化してこれだけの効果を生む。

システムの「売り手」側のゴールはこれでOKです。
「買い手」側のゴールはもう少し複雑です。

何故なら「買い手」毎にシステム導入前の状態＝スタートが違うからです。
現状どのような業務を行っていて、どのような課題があるか。
基本的にはこれを解決することがゴールになります。

その業務に関わる人は誰か

営業活動、生産管理、販売管理、受発注、導入するシステムによって関わる人は様々です。
真っ先に思いつくのは「入力する人」です。
上記の例だと営業担当者、製造ラインの担当者、店舗従業員、経理担当者などでしょう。

恐らく一番システムを操作する頻度の高い人で、現行業務の問題・課題などを洗い出すためにはキーマンになる人です。
ではそのキーマンの思いを100%聞くことが重要かというと、そうとも限りません。

「入力する人」の効率を上げることは重要です。
それが特定の「入力する人」の思いに偏ったり、現在のやり方の踏襲に固執すると、全体として効率的な方法になりません。
企業全体として見た時には「マニュアル通りにやれば誰がやっても同じ結果になる手順」「全社で統一された手順」のほうが効率的です。

特定の作業者を固定せず人員の流動性が保てること、制度や手順の変更や見直しを全社同時に行えること、操作誤りやルール外の操作を簡単に検知できる、もしくは操作できなくする。

所謂「標準化」によって得られる効果は長期的には大きくなります。

とはいっても実際に手を動かす現場の担当者の声を無視していいものでもありません。
トップダウンで手順の見直しを行う場合もあると思いますが、現場しか知らないOutputも存在することがあります。
（そういうものを無くすことが標準化の目的なのですが）
別の方法になるにしても、新たなシステムで拾い上げておかなければいけない業務が無いかを確認しておく必要があります。

また「入力する人」が入力した情報は、誰がどのように利用するのかも考えておく必要があります。

SFAやCRMなどの営業ツールであれば、入力は各営業担当ですが、活動状況を見るのは管理職や部門長であったり、データを元にマーケティングへの活用も考えられます。

生産管理や販売管理、受発注などは、当月の売上予測や予算対比などを部門長や経営層がウォッチすることも考えなければいけません。

その人たちにとって、今何ができていなくて、何をしたいかというのも考えなければいけません。

これらは「こうしたい」という思いのある相手であれば話はスムーズですが、そもそも何ができるのかが分からなかったり、何をしたいのかが不明瞭であることは往々にあります。

しかしこの部分こそ新しいシステムが提供できる付加価値であることが多いです。
どのように巻き込んでいくか、どのようにニーズを掘り起こし具体化していくか。
RFIで提案された製品からピックアップしたベンダーや外部コンサルなどの力も借りたほうがよい場合もあります。

優先順位は効果の大きいものから⇒効果の大きさの基準は？

現状の課題もやりたいことも、出せと言われればどれだけでも出てくる、という場合もあります。
あれもやりたいこれもやりたい、と言っても費用や期間などの制約もあり全てを実現できるとは限りません。

そうなると実現したいゴールに対して優先度を考える必要があります。

今回のシステム導入において是が非でも実現しなければいけないことなのか、あわよくば実現できればよいくらいのものなのか、抽出した要件毎に順位付けをしていきます。
この順位付けがなかなか難しいものになります。
それぞれ立場の異なる人の要望が混在するため、観点やレベル感のバラつきが出ることになることが想定されます。

「導入効果が大きいもの」といっても、誰にとっての効果なのか、どの時点での効果を考えるのかによって同じ基準での比較は困難になるかもしれません。

正直100点満点の回答を出すのは難しいです。
決めの問題として「本当に優先しないといけないものは何か」をプロジェクトとして提示し、関係者間での合意を得て進めていきます。

今回優先度を落としたからと言って長期的には解決すべき課題もあります。
第１回でお話したシステム導入計画のように中長期的にいつまでに何を行うかを落とし込むなど実現時期を漏らさないようにしたり、要件として今後の拡張性をRFPに盛り込むことなどが必要になると考えます。

情シスとして求めたいゴールも考える

業務要件をゴールとして設定する中に、非機能要件としての情シスが考えるゴールも含めるようにしましょう。

動作環境はオンプレなのか、IaaSなのか、SaaSなのか。
対応するクライアント環境の条件はどこまでか。
バックアップやレスポンスはどのような要件とするか。
データ移行や研修対象はどの範囲までを想定するのか。
ライセンスや保守の考え方はどうなるのか。

これらの要件はRFI時点で目星をつけたシステムの要件に寄せる、というのも一つの手法です。
逆にRFI時点で提供可能なサービスに該当しない要件をRFPに記載しても誰も提案してくれません。
「そんなクラウド（オンプレ）サービス存在しないよ」というものもあります。

また、「何故クラウド（オンプレ）なのか」をきちんと説明できる必要があります。
ランニングコストや周辺装置を含めた保守工数の差など様々ですが、「情シスのメリット」だけではなく「企業としてのメリット」に訴求できるように考えましょう。
「情シスのメリット」は少なからず「企業としてのメリット」でもありますが、ここで言うのは企業全体に対する効果です。

導入５年間の費用を目安に比較に大きな差が出ればコストを、大差が無ければ別の観点で効果を訴えてみたほうがよいでしょう。