Workdayのファイナンスにクラウド版Informatica、壮絶な“初物導入の舞台裏”全部見せます怒濤の5並列プロジェクトを振り返る(3/8 ページ)

» 2019年07月04日 12時00分 公開

「業務をいかにパッケージに合わせられるか?」という永遠のテーマ

 Workdayはクラウド型の製品であることもあり、基本的にはカスタマイズなしでそのまま導入し、利用することが前提となる。事実、クックパッドでもカスタマイズは最小限に留めて導入しており、そのおかげでIT部門および業務部門双方から「バージョンアップや、たびたび発生するシステムリプレースに掛かる手間とコストが不要になり、とても助かった」という声が挙がっている。クックパッド側のプロジェクトメンバーとして、今回、Workdayの経理システム導入を担当したエンジニアは次のように述べる。

 「プロジェクト内でも、クラウドサービスであるWorkdayを採用するということは『カスタマイズを最小限に抑えることを意味する』という認識がしっかりと根付いており、実際に経理システムのカスタマイズは最小限で済みました。その結果、オンプレミスのパッケージ製品に多くのカスタマイズを加えた場合に発生する、『4年に一度のバージョンアップのための大工事』がなくなったのはとても大きいと思っています」(クックパッドのFinance導入担当)

Photo Workdayと人事労務管理クラウドサービス「Workcloud」の連携イメージ

 しかし、その一方で、カスタマイズなしで導入するには、どうしても業務を製品の仕様に合わせる必要があるため、業務現場の理解と協力が不可欠になる。この点については、プロジェクト側と業務現場側とで、若干認識の相違が生じたという。

 「プロジェクトを立ち上げる際、今回、導入するWorkdayが海外製パッケージで、かつ国内初物ということもあり、必ずしも弊社の既存業務にマッチしているとは限らないという点は、業務現場にもきちんと伝えてありました。その上で、もし製品仕様と既存業務がマッチしなかった場合は『業務をシステムに合わせる』という方針を互いに確認したつもりでした。

 しかし、いざプロジェクトが始まって、そうしたアンマッチが明らかになってくると、業務側から『そこはどうしても譲れない』という声が多く挙がり、調整が発生しました。

 最初にきちんとコンセンサスを取ったつもりでいたのですが、業務側では『業務をシステムに合わせる』ことの具体的なイメージができていなくて、『せいぜい付随的な業務をちょっと変えればいい程度だろう』ぐらいに思っていたふしがあります。実際には、極めて重要な業務まで手を入れなくてはいけないことが徐々に判明してきて、『そんなつもりではなかった』という話になってしまいました」(クックパッド:HR導入担当)

 結果的に、業務現場からの強い要望を一部受け入れた仕様を別途、実装したという。この点について、これまで数多くのプロジェクトのマネジメントやファシリティーションを経験してきた白川氏は、自身の経験を踏まえ次のように述べる。

 「プロジェクト立ち上げ当初は、誰もが『業務をパッケージに合わせる』と言うのですが、実際にはその通りに実装できることはほとんどありません。そこでコンサルタントとして私が心掛けているのが、『ユーザーにとって嫌な質問』をあえてする、ということです。

 例えば、業務をシステムに合わせると『生産性が20%落ちる可能性がありますよ』『それでも本当にパッケージに合わせますか?』――といった言葉を投げ掛けます。あえてこうした議論をプロジェクトの企画段階で行っておくことで、その後のコンフリクトをある程度、避けられると考えています」(白川氏)

並行稼働をしなかった理由

 今回のプロジェクトは、常に時間とリソース不足との戦いだったという。そのため、通常なら新システムのカットオーバー後、しばらくの間は問題発生に備えて旧システムも並行稼働させるが、今回のプロジェクトでは新システムの稼働開始と同時に旧システムの運用を完全に停止させたという。これにより、新システムと旧システムの並行稼働に伴う業務部門の労力を削減でき、少ない人数でプロジェクトを完遂できたという。

 しかし、その副作用として、新システムのカットオーバー直後は初期トラブルに伴う混乱が生じ、今回の振り返りイベントでも「並行稼働させるべきだったのでは?」という意見がクックパッド側のプロジェクトメンバーから出た。

 「もちろん、並行稼働をする方がいいに決まっていますが、経理部門の工数が限られていたため、どうしても並行稼働する余裕がありませんでした。そこで思い切って並行稼働しないことにしたのですが、その結果カットオーバー後にWorkdayの検索機能を中心にさまざまな不具合が発覚しました。

 並行稼働しない分、本来なら事前に全ての業務プロセスを一通りテストしておくべきだったのですが、それもスケジュールの都合上ままならなかったので、結果的にテストケースが不十分なままカットオーバーせざるを得なかったのです。もう一度プロジェクトをやれるとしたら、やはり並行稼働か丁寧なテストのどちらかはやるでしょうね。ただ、当時のリソース不足の状況を鑑みると、やっぱり並行稼働は諦めざるを得なかったと思います」(中野氏)

 最終的に「並行稼働しない」という決断を下した中野氏自身も、「理想を言えば並行稼働する方がいいに決まっています」と述べつつ、それでも当時の状況を踏まえ以下のように述べる。

 「パッケージベンダーの米国本社からも『並行稼働の必要はない』というコメントをもらっていたので、それをうのみにしていたところもありました。しかし、『国内初物』となると、予想だにできない問題がいろいろ出てきました。ただ、どうしても並行稼働に必要なリソースを捻出できなかったので、ほかに選択肢がありませんでした。それより、『出てきた問題をいかに早くつぶすか』の方にリソースを集中投下する方策を考えた方が、現実的ではないかと考えたのです」(中野氏)

 これに対して白川氏は、「私自身はこれまでどのプロジェクトでも、必ず並行稼働をしてきたので、その決定にとても驚いた」と述べる。

メンバーが振り返る、プロジェクトの「良かった点」

 このプロジェクトを振り返ったとき、「ここが良かった」「この点は今後のプロジェクトにも生かしたい」といった声も数多く挙がった。ここでは、その中から代表的な声を幾つかピックアップして紹介する。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ