CASE
STUDYお客様事例

富国生命保険相互会社様

画像：富国生命保険相互会社様
scroll

富国生命保険相互会社様は、約30年間利用してきた人事・給与システムを再構築し、プロジェクト発足から約1年で人事管理と給与計算機能をリリース。さらにその1年半後には、それまで紙で管理していた勤務管理について新システムによりシステム化を行いました。
要件定義から人事管理、給与計算のリリースまで1年、勤務管理などその他のリリースを含めても2年半という短期間で新システムを稼働できたのはどのような要因があったのか。今回、プロジェクトメンバーの皆様に当時を振り返ってお話しいただきました。
また、ケンブリッジからはクライアントパートナーの白川、プロジェクトマネージャーの桑原が参加しました。

・矢嶋氏　　　事務企画部　部長
・八田氏　　　事務企画部　部長
・三沢氏　　　人事部　課長
・波多野氏　　事務企画部

※所属はプロジェクト実行当時のもの

#01プロジェクトのきっかけ

まず、プロジェクト発足の経緯をお聞かせください。
矢嶋 人事情報を管理するシステムのサーバー更改時期が迫っていたことがきっかけでした。また、給与計算システムは昭和60年に開発されたホストシステムで、これも変えたかった。
八田 人事情報はACCESSで、給与は長年使っているホストと別々だったこともあり、私が人事部にいたときからシステムを刷新したいと思っていました。 システムだけでなく人事制度も変えないといけないという意識もあったけど、ホストでガチガチに作り込まれたシステムは、なかなか直せるものじゃない。 当時は矢嶋さんが担当で「コストセンターに金はかけられない！」と言われたことを覚えています。（笑） その後、人事から、事務企画部に異動した時に、労基署の監査で勤怠の出社や退社の記録は電子的に記録をとるよう指導されました。 冒頭で話に挙がった人事システムのサーバー更改もあり「これを機会にひとつのシステムにまとめてしまおう！」となりました。

#02プロジェクト成功のための体制作り

そして1年で人事・給与システムの再構築をされ、さらに1年半で勤務管理のシステム化までされた訳ですが、このような短期間で再構築までできたのはどのような要因があったでしょうか？
矢嶋 人事システムを開発した三沢が人事部にいたことが大きい。三沢が人事部にいなかったら、このプロジェクトは始めなかったね。
白川 三沢さんが業務もシステムも両方分かることがこのPJの鍵でしたね。実は業務もシステムも分かる人材ってなかなかいない。業務とシステムに断絶があって話が通じないなどネックになりがちです。
矢嶋 どこの部署もシステムを分かる人が欲しい。ましてやシステムの所管部署なら尚更です。実際はなかなか人を出せません。今回はチャンスだと判断しました。
三沢 私が人事部に異動したのも、たまたまタイミングが合ったのだと思います。
このプロジェクトが始まってしばらくしてから波多野さんと若手の安宅さんがフコク情報システム（以下、FIS）から富国生命に出向されていますね。なぜ情シス子会社であるFISのままではなく「出向」という形をとられたのでしょうか？
三沢 「腰を据えて開発する」という理由と、コミュニケーション向上のために出向してもらいました。
八田 こっちで開発することが優先。だから出向。 
波多野 私は当初「参加」ではなく、「協力」だと思っていました。 異動の直前、直属の部長に「FISのシステムと新システムとの調整が役割ですよね」と確認したところ、「違うんだ、あっち（富国生命）の立場で作業せよ」と言われました。これほどまでがっつり開発するとは思っていませんでした。（笑）
白川 PJの体制は、議論しても理想通りいかないものですが、三沢さんのように、業務の主幹という立場と旧システムをわかっている方、が入るというのは珍しい。かつ、新システムの担当の方がちゃんと揃っている。そこは矢嶋さんと八田さんがいろいろ糸を引かれていたのかなと思っています。
体制という意味でケンブリッジに声をかけていただけたのはなぜでしょう。
矢嶋 その頃、ケンブリッジが人事パッケージ導入の経験が豊富ということを知ったことがきっかけです。
白川 我々は人事パッケージを良く知っている桑原をプロジェクトマネージャーとして、また手際よく仕事をしてくれるコンサルタントとして藪口をアサインし、この2人を中心のコンパクトなチームで支援しました。

#03要件定義からパッケージ選定までを３ヶ月でやりきる

要件定義とパッケージの選定はどのように進めたのでしょうか？
桑原 人事の業務や必要となるシステム機能を人事部と検討しました。ケンブリッジが用意する業務フローやシステム機能要件定義書のたたき台をベースに、週に2、3回のセッションを実施していました。最終的に費用対効果分析や価格交渉の結果、ワークスアプリケーションズ社（以下ワークス）のCOMPANYでいこうと決めました。3ヶ月弱でしたね。
3ヶ月弱とは非常に短い期間だと思いますが、もう少し時間をかけた方が良かったなどありますか？
桑原 今から思うともう少し時間をかけて業務の棚おろしや機能の調査をすればよかったかもしれないですね。後からパッケージで対応できない業務が見つかったりしましたし。後に判明した社会保険をホストから移管できない問題がこの段階で見つかったかもしれない。
白川 他システムとの連携などは調査したのですが、ホストが残って、その繋ぎがややこしい話になる、ということは気づけなかった。後で足元をすくわれた感がありますね。  
三沢 そもそもパッケージなのだから、データを登録すれば一通りできるのだろう、で終わっていました。蓋を開けたらできません、というものがでてきましたね。 
白川 本当にできるのか、ひょっとしたらできないのか、と重大問題として気づいて調べればよかったですね。それができなかったことが、大きな反省点のひとつです。
波多野 このような問題は我々がパッケージの仕組みを理解してようやく見えてくるのだと思います。FISが本格的に参加していなかった要件定義の段階では、気づくことはできなかったと思います。
三沢 実際にGAP分析を詳細にやろうとするとこの期間では厳しかったと思いますから精一杯の成果だったのではないでしょうか。

#04パッケージ導入の難しさ

開発にあたっての苦労や戸惑いなどありましたか？
三沢 初めてパッケージの設定をやりましたが、こんなに設定しないと動かないんだ、と思いました。 購入した段階で基本的には動いて、少しだけ自社向けに変更するくらい、と思っていました。
波多野 開発に着手して1か月ほど経過してパッケージの特徴が見えてきたときに、三沢さんと「あと2～3人いないと絶対終わらないですね」という話をしていました。三沢さんも「俺もそう思う」とおっしゃっていたことを思い出します。
白川 普通の生産性、かつ、積み上げ型でスケジュールを組んでいたら足りなかったんでしょうね。無理がなかったといえば嘘だとは思います。でも第1ステージはなんだかんだいってやりきってしまった。
やりきることができたのはなぜでしょうか？
白川 パッケージでシステム構築するとなると、組織の体系をどうするかなど、人事部の立場で決めて頂かなきゃいけないことが山ほどあります。三沢さんがとてもスピーディーに数多くの細かい意思決定をして頂いたのが大きかったですね。
矢嶋 システムが分かり業務が分かる人は中々いないですよね。三沢は人事部なのにシステム部門の人みたいに思っています。
白川 三沢さん以外にも、現行システムを知っている波多野さんがいたこと、ケンブリッジとしてもCOMPANYに詳しい桑原が全体を押さえ、少し綻びがあると藪口がフォローするという、チームワークのよさで走りきったのが1次リリースでした。このチームはスペシャルなんだと思います。

#05プロジェクトのスピード かっちり VS スピード

矢嶋 今回のプロジェクトの進め方は、「スピード重視」でしたね。開発フェーズ含め、まずやってみるスタイルでした。この進め方、FISから評判悪いんですよ。（笑）
三沢 通常のFISのやり方でやると、カッチリやるので時間がかかる。ホストのウォーターフォール方式で進めていたら、要件定義はもちろん 開発も含めてこの期間ではできなかったと思います。勤怠システムはできてなかったかもしれない。今回はスピード重視でやりたかったんですよ。FISなら3年で100点のものを作ったかもしれないですが、75点でも2年でやりたいというニーズが強かった。スピード感が欲しかったので、少しは品質が犠牲になっても仕方がないと思っていました。そういう意味ではFISでなく、ケンブリッジのほうが、そういう感覚をもっているし、慣れていると思います。
八田 コスト的には、FISで作ると、期間は長いが単価は安いので変わらないかもしれません。ですが、3、4年もメンバーを固定できるのかという課題が出ますね。その辺が時間をお金で買うかの判断ですよね。
桑原 とはいえ、ステージ1の稼動は他社に比べるとスムーズであったと思います。人事給与のリリースでは多少の誤支給が発生してしまうことはあるのですが、今回はありませんでした。細かい不具合を何とか凌いだことはありましたが、それも少なかったと思います。皆さんはどのように思いますか。
波多野 FISの通常の開発だと障害なんか起きないので、そこを目指した結果だと思う。 ステージ1では給与を主に担当しましたが、テストは十分にできました。スケジュールがタイトであったため、何千件という給与計算を1、2時間で検証して不具合の原因を特定するといった作業を何サイクルもやらなければなりませんでしたが、旧システム側にもベテランのメンバーがいたため、電話のやりとりだけで認識を合わせ、問題解決が速やかにできました。賞与については一ヶ月半ぐらいで全部やりました。我々の普通の進め方ではできない。
三沢 規定自体が給与、人事に比べればシンプルだったのと、さらにシンプルに作り直したからできた。
八田 給与・賞与は制度変更で自分が移行を担当しても大丈夫なようにシンプルにしました。 でも、この期間でよくやったなと思う。全般的に計画をみると本当にそんなに早くできるの？と思っていたので、COMPANYってすごいなと思った。だから第2ステージ（勤務管理のリリース。後述）で苦労することになるとはそのときは思わなかった。

#06一点管理した勤務管理のリリース

1次リリースと比較して、2次リリースの勤務管理では苦労があったと聞きました。具体的にはどのような点でしょうか？
三沢 PJの運営スケジュール管理、役割分担などではないでしょうか。
矢嶋 PMは誰？という状況になってしまったことかな。ある面は三沢さん、ある面は桑原さんがやってくれていたが、うちの会社の開発のルールとかやり方をあてはめることを桑原さんにお願いするのは酷。
三沢 当時は人事として立場のやることが多くて、PJマネジメントまで手が回らなかった。人足りなかったもしれないですね。結果をみると。
白川 そこは私もものすごい反省があって、結果としてPMが手薄だったのは間違いなかった。 すくなくとも第２ステージの時は、桑原が勤怠のメイン担当かつPMといいながらそっちがお留守になっていてマネジメントできてなかったので、気づいた時にはスケジュールの遅延が拡大していたのだと思う。そこはFISなり富国IT部門としてのPMが別にいれば違っていたと思う。PMと勤怠の主任は別人格の方がよかった。一時は結構大変でしたが、小火ぐらいで収まったのは幸いでした。
八田 あの頃、火消しのタイミングだとケンブリッジが10人ぐらいいた。白川さん、無理してアサインしたなと思いましたよ。
桑原 内輪の話ですが、あとから入ったメンバー含め、悲壮感に打ちひしがれるという感じはありませんでしたね。私もむしろやってやるぞという感じでした。
八田 僕も見ていてそう感じた。ギスギス感もなくて普通に楽しんでやっているなと思った。 前からずっとやっている人たちはいつ終わるのという悲壮感があるのかもしれないが、救援部隊は俺は助けにきたんだ、と。消防士と同じような感覚だったのではないでしょうか。
波多野 途中から完全に当初の想定から外れ、増員していると思うのですが、ケンブリッジから追加費用の要望はありませんでしたね。赤字だったらどうするのかな、どうしてそれで成り立つのかと気になっていました。
矢嶋 同じようなケースで、全てのベンダーがそういう対応するとは限らない。平気でお前の見積もりミスだろうみたいなことや、条件が違うので追加で費用くださいという会社はたくさんある。
白川 ケンブリッジが一緒にプロジェクトプランを立てたわけじゃないですか。それで第2ステージまで含めて、なんとかこの金額に納めてやろう、となった。いろいろあてが外れたが、会社としてコストがどうこう言う以前に、きちんと目指したことをやりきる、というのを大事にしています。

#07どこまで開発時に作り込むべきか

こうしてリリースした勤務管理については、人事・給与と比較して結構機能を盛り込みました。
矢嶋 振り返ると、正直、勤怠は作りこみすぎたと思うんですよ。 PCにログインした時刻を出勤・退勤時刻に連動するなど細かいことをやりました。
八田 端から見てると、そこまでやるのという感じでした。難しいことを実装したので、結構工数を使ったと思います。工数を使うなら別のところに使ったほうがよかったかもしれないですね。自分は制度系の人間なので、そこに工数をかけるなら、少しくらい人事制度、給与制度を変えたらという思いはありましたね。
三沢 勤怠については全職員を巻き込むので、なるべく良いものを一気に作ろうとしていました。違う立場から見るとやりすぎじゃないかとか、2次開発、3次開発と段階導入すればよいという意見はあると思います。しかし、人事部としてはスタートを切るときに実装したかった。
八田 私から見ると、勤怠は95点のシステムができている。他の機能は、70、80点くらい。 勤怠は元々システムがないので、0点が95点になったわけです。そこまで上げなくてもよくて、逆にほかの70、80点の機能のものをもう少し上げても良いのではと思いました。一点豪華主義になっているのかなという思いはありました。
白川 勤怠のように、今まで紙だったものがシステム化された場合、システムとして勤怠管理はこういうものだ、と理解してから、打刻のような精緻化を図るのが通常の流れです。ですが、今回は最初から人事として100%を目指して頂き、プロジェクトとしても人数を入れて一気に作り上げました。社員からよく見えるところですし、ダイレクトに社員の働き方が変わる部分なのである意味一点豪華主義としては良かったのかもしれません。
波多野 システム的な観点ですと、打刻は配備端末への組み込みやネットワーク負荷の確認といった基盤部門との折衝に労力がいるので我々はとても楽でした。 保守に入ってから対応するとなると何かと調整が大変で、相当苦労するのだと思います。
白川 当時も相当苦労しましたけどね。（笑）
波多野 開発時に事務企画部も人事部もバックについていたのでやれたところがあります。保守案件として人事部と調整となるとできなかったかもしれません。
白川 プロジェクトの勢いがあるときにやったほうがよいものがあって、勤怠のPCログイン打刻機能はそれだったのかもしれません。
三沢 部署の圧力をかけないと難しいこともある。今回は開発プロジェクトだったので、できたのかもしれませんね。

#08業務としての導入効果

システムが導入され、社員の方の働き方や人事管理のレベルなど具体的にどう変わりましたか。
八田 まず、人事管理レベルはあがりましたね。
三沢 また、ペーパーレスが大きいですね。今までは本社と全国の支社に勤怠の担当者がおり、紙で集計・チェックしていました。そこが削減されたので、勤怠に関する仕事は大きく減っています。
白川 他社ですと給与明細、年末調整が楽になったと結構聞きますがいかがですか。
矢嶋 給与明細を発送しなくてよいので楽になっていると思います。
白川 少しでも打刻とかみ合ってないとアラートやエラーメールが来るので、そういう意味でもやりすぎかなと思ったのですが、社員から不満という感じはないですか。
三沢 その辺はないですね。ガチガチでやってちょうどいいぐらいです。そうしないと直らない。 面倒だと思ってやっている人もいると思いますが、目指す姿を実現するにはちょうどよいくらいだと思います。
最後に皆さんにお聞きしたいのですが、もう一回これに近いプロジェクトをやるならばやりたいでしょうか。
八田 本当は私が人事部にいたときにこういうプロジェクトをやりたかった。もし人事部にいたときにやるとすると、業務手順をパッケージに合わせて変えるということができたかなと思います。現在の業務手順にこだわって工数がかかっている部分もあったはずなんですよね。
波多野 とにかく私と一緒に出向した若手の安宅が成長してくれました。彼だけではなく、FISのメンバーがプロジェクトにもっと入っていればな、と思いましたね。良い経験をするチャンスだと思いました。なかなかこのような仕事はないのですが、そこに会社の若手が入っていければ良いなと思います。ただ自分がやりたいかというと、もうそんなにたくさん自分で手を動かさなくても良いかなという感じです。口だけ出して指導するっていう感じがいい。（笑）
三沢 私も自分自身がやるのではなく別の人にやらせて、このような2年ぐらいのプロジェクトを仕切れるような人をもっと増やしたほうが良いと思う。そういう人を育てるための手伝いだったら喜んでやろうかなと思います。
矢嶋 同じく、自分でこなすよりも社内でそういう人を増やしたほうがよいと思いますね。そういう若いやつを育てるほうが最近はうれしい。波多野や安宅もそうですが、プロジェクトが終わった後に成長した姿を見るのが楽しくて。育成はいいなと思います。その立場で上手く携われたらいいなと思いますね。
みなさま、たくさんのご意見、ご感想、ありがとうございました。

このプロジェクトを成功に導いた
ケンブリッジの方法論を知りたい方はこちら