人事情報システム基礎講座

（１）システム更新の企画段階

　５）導入企画書の作成

　手続き論になりますが、導入の必然性が議論された後、経営層に対して関連情報を提供し、経営判断を仰ぐことになります。

　一番大事なのは「ＷＨＹ」で、どうして導入（リプレース）の必要があるかを明確にした後、残りの４Ｗ２Ｈを整理していきます。もともと経営の意志決定をするために必要なのは、５Ｗ２Ｈと言われていますが、順番に考えていきましょう。

　①　ＷＨＹ

　これは「導入の必然性」という項目で説明してきた通りです。いまさら繰り返しませんが、「何故」という問いに答えられるものでなければなりません。

　②　ＷＨＥＮ

　どういうタイミングで行うか。２つめのＨと重なりますが、予算の関係もあります。企業の業績やキャッシュマネジメントとの関係で、「今やることか」「先延ばしできないか」「他にやるべきこととの相関関係は」等の疑問に答える必要があります。

　また実施のタイミングは、「予算」を意識させる、「予算」に計上させる、「キャッシュアウト」のタイミングを意識させるという意味では、業績管理部門や経理部門とも話し合った方が良いでしょう。
　「どこかで大規模な投資や費用計上が予定されているかどうか」等は、日頃から経理担当者と話をしておくべきです。そうでないと、「あいつは事の軽重が分からないヤツだ」と批判されてしまいます。

　③　ＷＨＡＴ

　「何をするか」は至極当たり前のコンテンツなのですが、極めてシンプルに記述した方が良いです。いろいろな要素を折り込んでしまうと、所期の目的を見失うこともあります。
　「何」は「何故」と密接に繋がっており、何故を突き詰めていくと、ある日「何」が変わってしまうことがあります。つまり、「何」は「何故」の従属変数であり、その他の要素も似たようなものです。
　大抵の導入企画書のタイトルが「人事給与システムの再構築」のような題名になりがちですが、「人事給与業務の効率化に伴うシステムの再考」のような形にしておけば、「何故」と「何」がリンクしていて分かりやすいです。

　④　ＷＨＥＲＥ

　これは「ＷＨＯ」とも関係しますが、対象は何かと考えるとより理解が進むかもしれません。ステークホルダーの明確化にも良いです。「おれたちには関係ない」という部外者意識を払拭するのにもなります。
　特に最近の人事情報システムは、インターネットの進展で一般社員にもサービスが及びまた当事者意識でオペレーションしてもらわないと成立しない構造になっています。

　具体的には、スコープの範囲ということになりますが、当社１社でやるか、グループ会社を巻き込むか。稀に事業部で試験的に行うということもありますが、実施する範囲を決めることです。

　問題は「被害者意識」を持たないように、企画段階から巻き込めば良いのですが。例えば、意見を伺いつつ、それらの課題や不満を満たす代わりに必要条件としてプロジェクトに参加させる等。
　「いっぱい食わされた」と苦笑するユーザが、稼働後は当たり前のように使いこなしていくという図が最高ですが。

　⑤　ＷＨＯ

　プロジェクトを推進する体制や責任の所在の設定などは当たり前ですが、実はここで失敗する例が多いです。特にユーザは自分のやるべきことを希望的観測で外に追いやる傾向が強いです。
　システム導入はそんなに甘くない。パッケージといえども、システム開発と同じで、しっかりユーザがやるべきことは決まっています。また、導入コンサルやＳＩｅｒに甘えかだるのは理解できますが、契約書以上のことはやらないと思った方が良いです。
　特に注意したいのは要件定義とユーザ受け入れテストです。

　⑥　ＨＯＷ

　パッケージ導入においてのＨＯＷは導入手法になるでしょうか。それともＷＨＯを加えて、体制の問題になるでしょうか。いずれにしても、完璧なパッケージというものはあり得ないので、アドオンや別のソリューションを組み合わせる等の改修が必要になります。
　すべてターンキーで完成までやってくれるＳＩベンダーと契約するのであれば、彼らの導入手法に従うことになります。どんな手法であろうと、ほぼプロジェクトマネジメントは同じです。その意味では、ユーザはプロジェクトマネジメント手法はかじっておいた方がよいでしょう。システム部門の力を借りられれば、それに越したことはありませんが、御社のシステム部門はどうでしょうか。開発をやったことがないといしシステム部員が増えているので、足手まといになるようなら、自分で勉強することです。

　⑦　ＨＯＷ　ＭＵＣＨ

　２つ目のＨが「ＨＯＷ　ＭＵＣＨ」。予算の問題です。
　昔からシステム開発は、終わってみれば目論見の倍かかってしまった、というのが通り相場でした。それほど見積もりは難しいです。ＳＩｅｒとの契約では、事前の見積もりと要件定義か終了した後の、最終開発範囲が確定したからの見積もりと、かなりギャップが生ずると考えておくべきです。事前ではベンダーは重く考え、ユーザは軽く考える傾向がありますが、要件定義が終了してみて、ベンダーは初めてユーザの正体が分かるのです。だからこういったプロジェクトの場合、公的機関以外では請負契約にはなりにくいです。
　また要点定義を行ったとしても、その見積額をひとり歩きさせてはいけません。１００％は信じないことです。可能なら要点定義時に予算の６０～７０％になっていることが望ましいです。というよりそういうガイドをしておいて間違いはありません。
　システムを企画する者は、予算に悩まされるのが常ですが、最終的に予算欠乏症になって、最初の目論見とは似ても似つかないシステムになってしまうことは避けたいです。

　企画書は、大体において導入責任部門が作成しますが、対象がシステムである限り、情報システム部をなおざりにはできません。経営的な判断を求める場合は、システムに限らず、関係する部門との相談が事前に必要で、日本的経営である稟議書のハンコべたべたは、事前に協議した上での捺印である必要があります。では一体、どんな部門との事前協議が必要になるでしょうか、考えてみましょう。

　導入するシステムの特性を考えれば、利用者が人事部門だけであれば、システムという特性上、情報システム部門。そして情報の下流部門である経理部等。また、各事業部の管理部門や事業所の総務部門が関係してきます。
　つまりデータフローを分析すれば、関係部門はハッキリするのですが、この当たりについては日常の業務に絡むので、人事部門も抜かりはないと思います。

　しかし、前にも述べたように、最近の人事情報システムのユーザはひとり人事部門だけではありません。経営に資するといった途端、最上流から最下流まで巻き込むことになります。例えば、オペレーションを分析しても、情報サービスという観点からは全体像は分かりません。つまりこれまで人事部門が意識してこなかった領域が入り込んでくるのです。日常的に経営からは、「こんなデータはないか」「これこれのデータを持ってこい」といったようなアドホックな要求があれば、「それは前に作ったものがありますので、アップデートして持っていきます」「それは前例がありませんので、システム部門と相談して作るとすれば１週間かかります」と答えていました。こういった要求を、システム自体が答えられるような企画をするとすれば、人事部門を探してもニーズは出てこないのです。

　また、人事管理だけを目的とせず、人材マネジメントとして現場が活かせる情報環境を作るとすれば、日常の現場における人事マネジメントや、各事業部のビジネスプランに応じた情報提供の仕組みを考えざるを得ないです。
　つまり、人事部の外からニーズへの対応策を作っていく必要があるのです。それはつまり、システムの導入企画は、現場のマネジメントへの支援であり、これまでの人材マネジメントをある意味否定することにもなり兼ねない、多くの課題を抱えています。

　「要員配置のあるべきプロセスは」「人材育成の仕組みは今までのようなことで良いのか」「ビジネスモデルの変更で必要なる人材モデルのサプライチェーンはどうなる」等々、事業に資することが最も重要なシステムの要件になります。給与計算の合理化等よりも、更に重要度が高まると理解できるでしょう。給与計算が合理化されても、会社が生き残れなければ意味がないのです。

　「そんな企画はできない」というのであれば、いつまで立っても『業務効率化』が題目の企画書しか作れないことになります。人事部員も経営企画的なセンスがないと、経営に資するシステム企画はできないのです。従って、これからの新システムの導入企画は、自社のビジネスモデルへの正しい理解と今後の経営方針が、まずもってスタートの拠り所となります。