【第２章】人事情報システム導入の進め方 その７
［ 掲載日 ］2013/07/08
［ 掲載日 ］2013/07/08
- 今回は、プロジェクトの要員についてです。
- 最近、ワークス社やクレオ社のように、パッケージの導入を自社で行うような導入手法も出てきました。 パッケージ以前では、自社の情報システム部員か、あるいはＩＴベンダーのＳＥとプログラマの組み合わせでプロジェクトを組んで、 システムの開発を行っていましたが、パッケージアプローチでは、俗にコンサルタントと呼ばれる新種の職業も生まれて、 様々なバックボーンを持った人々がプロジェクトを構成するようになっています。
- 第７話 導入開発フェーズ（その２）
- １）コンサルタントの必要性
- 手組開発と異なり、「ブツがある」という点が非常に大きな相違点であることは前回お話しましたが、 「作るべきシステム」と「既に存在している機能」との差分を見つけることが要員に課せられたはじめのテーマです。
- 導入プロセスは下記の通りですが、要件定義以降の部分にポイントがあり、そのための要員を配することになります。 人事給与業務を知り、ＩＴを知り、パッケージを知っているというコンサルタントが必要になるのです。
- ・要件定義
・ソリューション開発
・プロトタイピング（１回～３回）
－設定データ準備
－パッケージ環境構築
－インプリメンテーション（パラメータ設定）
－ギャップ分析
－評価
－設定修正 ・統合テスト
・移行本番 - 「コンサルタント」というと大げさですが、つまりは業務とＩＴとパッケージを知っている要員は、 「来るべきシステム」と利用する「パッケージ」のギャップを探し出して、それにどう対処するかをユーザと決めていくという大事な仕事があるのです。 上記にある「プロトタイピング」は、別名「ＣＲＰ（コンファレンス・ルーム・パイロット）」とも言いますが、 そのギャップを探してはどうしようかを議論する場なのです。
- ２）パッケージアプローチの要員構成
- 要員の構成は、要件定義からテストや移行の至るフェーズのそれぞれで異なりますが、おおむね次のような構成になります。
- ・プロジェクト総括責任者
- 「プロジェクトオーナと呼ばれる、全責任者です。通常、人事統括役員が任命されることが多いようです。 プロジェクトの執行責任者で、経営意志決定機関（例えば役員会や常務会など）に対する報告義務を有します。 本部及び各関係部門間に渡る本プロジェクトに関わる調整を行います。プロジェクト全体に関わる重要事項の決定を行います。 プロジェクトステアリングコミッティの議長を兼務します。」
- ・ステアリングコミッティ
- 「プロジェクト遂行上の意志決定機関です。プロジェクトの執行上の報告を受けると共に、重大な問題についての意志を決定を行い、 その結果について、会社の意志決定機関に対して責任を有します。また、プロジェクトの円滑な遂行と予算内・納期内完了のために必要な部門間調整作業を行います。 プロジェクトマネジャに対して、プロジェクトの目的に則した指示命令を与え、その結果について報告を受けます。 メンバーは、ＰＪ総括責任者の議長をはじめ、人事部長、人事部ラインマネジャ、情報システム部長、人事システム担当マネジャ、 ＳＩベンダー責任者、ソリューションベンダー責任者及びプロジェクトマネジャから構成します。月に１度程度開催されます。」
- ・プロジェクトマネジャ
- 「プロジェクト執行の業務管理責任者です。日常的な意志決定、問題・課題の解決及び執行に関する指示命令を出し、 各チームリーダから報告、相談を受けます。ステアリングコミッティに対して報告義務を有します。ＰＭは原則としてユーザー様から任命し、 必要に応じてサブＰＭを置きます。ＰＭは人事業務システムに精通した経験者か、プロジェクト管理経験のある、ある程度の決定権限を持つ方が望ましい。 ソリューションベンダー等が自社のＳＥやコンサルタント等を管理する為に設置するＰＭは別に規定し、 その場合、サブＰＭとして任命する場合があります。」
- ・事務局
- 「プロジェクト執行に必要なリソース（要員、設備、備品等）の調達管理、及び施設の手配や関係部門とのコミュニケーションと庁内調整を行います。 ＰＪ遂行に関わる情報連絡ツールの管理維持、ドキュメンテーションの管理及び変更管理、更に作成した成果物の管理と保管を行います。 庁内関係部門との協議や調整、コーディネーションが行える位置付けの方が望ましいです。」
- ・各チーム
- 【人事チーム】
- 「人事マスターのデータモデルの設定や組織、資格等級などの設定を行います。 また人事異動や人事考課、昇給昇格などのプロセスについての分析やパッケージの設定を行います。」
- 【給与チーム】
- 「給与計算に関わる計算式の設定や様々な業務プロセスのロジックを設定します。 給与・賞与に関わる支給金の他、福利厚生関係の控除金の設定や、年末調整、昇給計算など、 月例給与支給以外にも年次の業務処理の設定を行います。」
- 【開発チーム】
- 「パッケージで処理できない業務やどうしても追加開発を行う部分については、この開発チームでシステム開発を行います。 パッケージそのものに手を入れない、アドオン開発と呼ばれるものが一般的になっていますが、設計が終了したのちは、 通常のシステム開発と同じ作業になります。従ってこのチームは、システムエンジニアはプログラマの構成です。」
- 【技術支援】
- 「ハードウェア、ネットワーク、データベースの構成と運用等の枠組みの策定を行います。 またシステムの導入（ＤＢＭＳ及びアプリケーションズ）とサーバー等のシステム管理を担当します。 更に開発環境と本番環境導入（ＤＢＭＳ及びアプリケーション）を行ないます。 またサーバー等のシステム管理及びこれらに関係する技術的な要件に対する作業の指導及び支援を行ないます。 大きな企業であれば情報システム部の要員が当たることになります。」
- それぞれのチームは、要件定義やソリューション開発時にはコンサルタントが要員に加わり、 上流の作業を行います。
- ３）要員の要件
- システムを導入するプロジェクトで最も大事なことは、パッケージをよく知っているコンサルタントが、 手を抜かずに参加することですが、次の点によく注意したほうが良いでしょう。
- 【プロジェクトのアドオン開発の比率はどうか】
- 業務パッケージにしろＥＲＰにしろ、標準機能で処理をする姿勢を貫ければよいのですが、事情によってかなりのアドオン開発を行う場合もあります。 大企業のプロジェクトでは、アドオン開発の工数が大きくなると、全体としてみたときには、 パッケージアプローチより手組開発プロジェクトと変わりない様相を呈することがあります。 こうなった時には、大規模開発の経験のあるプロジェクトマネジャの登場が必要です。 コンサルタントに毛が生えたくらいのプロジェクトマネジャでは、リスクが大きすぎることになります。
- 【ベンダー発行の資格を鵜呑みにしない】
- パッケージの導入は、その製品が持つ特異な設定手法があり、その意味ではしっかりと研修を受けたコンサルタントまたは技術員が必要です。 しかし、人事給与をよくしらないで、パッケージのみの教育研修を受けた人もいます。 従って、パッケージをよく知っているだけでなく、リーダやサブリーダクラスには、 人事給与システムの開発経験や運用経験者をアサインする事が重要です。
- 【給与の設定には苦労することが多い】
- ご自分の会社の給与制度はどうですか？ 人事制度は業務、つまり仕事のやり方と異なり、簡単に変えたり妥協したりはできません。給与計算のプロセス設計は習熟したコンサルタントに任せることができますが、思いの他、手数がかかるものです。制度を運用できるのであれば、細かな部分については割り切る必要がトラブルを回避する秘訣です。拘ると予定した工数を超過すしてしまって予算を確保することも難しくなりがちです。この部分を行う要員は、人事給与をよく知っているだけではなく、助言やアイデアを期待できるコンサルタントが望ましいのですが、期待に沿える人は残念ながら多くありません。
- 大事な「プロジェクトマネジャ」「チームコンサルタント」「各チームのリーダ」などは、 経歴をよく知ることと、実際に面談してみることも必要です。