Workdayのファイナンスにクラウド版Informatica、壮絶な“初物導入の舞台裏”全部見せます:怒濤の5並列プロジェクトを振り返る(3/8 ページ)
あの、話題のプロジェクトの現場で、実際にどんなことが起こっていたのか――。初物ソリューション導入の「いいことも悪いことも全て」公開するというイベントが開催された。
「業務をいかにパッケージに合わせられるか?」という永遠のテーマ
Workdayはクラウド型の製品であることもあり、基本的にはカスタマイズなしでそのまま導入し、利用することが前提となる。事実、クックパッドでもカスタマイズは最小限に留めて導入しており、そのおかげでIT部門および業務部門双方から「バージョンアップや、たびたび発生するシステムリプレースに掛かる手間とコストが不要になり、とても助かった」という声が挙がっている。クックパッド側のプロジェクトメンバーとして、今回、Workdayの経理システム導入を担当したエンジニアは次のように述べる。
「プロジェクト内でも、クラウドサービスであるWorkdayを採用するということは『カスタマイズを最小限に抑えることを意味する』という認識がしっかりと根付いており、実際に経理システムのカスタマイズは最小限で済みました。その結果、オンプレミスのパッケージ製品に多くのカスタマイズを加えた場合に発生する、『4年に一度のバージョンアップのための大工事』がなくなったのはとても大きいと思っています」(クックパッドのFinance導入担当)
しかし、その一方で、カスタマイズなしで導入するには、どうしても業務を製品の仕様に合わせる必要があるため、業務現場の理解と協力が不可欠になる。この点については、プロジェクト側と業務現場側とで、若干認識の相違が生じたという。
「プロジェクトを立ち上げる際、今回、導入するWorkdayが海外製パッケージで、かつ国内初物ということもあり、必ずしも弊社の既存業務にマッチしているとは限らないという点は、業務現場にもきちんと伝えてありました。その上で、もし製品仕様と既存業務がマッチしなかった場合は『業務をシステムに合わせる』という方針を互いに確認したつもりでした。
しかし、いざプロジェクトが始まって、そうしたアンマッチが明らかになってくると、業務側から『そこはどうしても譲れない』という声が多く挙がり、調整が発生しました。
最初にきちんとコンセンサスを取ったつもりでいたのですが、業務側では『業務をシステムに合わせる』ことの具体的なイメージができていなくて、『せいぜい付随的な業務をちょっと変えればいい程度だろう』ぐらいに思っていたふしがあります。実際には、極めて重要な業務まで手を入れなくてはいけないことが徐々に判明してきて、『そんなつもりではなかった』という話になってしまいました」(クックパッド:HR導入担当)
結果的に、業務現場からの強い要望を一部受け入れた仕様を別途、実装したという。この点について、これまで数多くのプロジェクトのマネジメントやファシリティーションを経験してきた白川氏は、自身の経験を踏まえ次のように述べる。
「プロジェクト立ち上げ当初は、誰もが『業務をパッケージに合わせる』と言うのですが、実際にはその通りに実装できることはほとんどありません。そこでコンサルタントとして私が心掛けているのが、『ユーザーにとって嫌な質問』をあえてする、ということです。
例えば、業務をシステムに合わせると『生産性が20%落ちる可能性がありますよ』『それでも本当にパッケージに合わせますか?』――といった言葉を投げ掛けます。あえてこうした議論をプロジェクトの企画段階で行っておくことで、その後のコンフリクトをある程度、避けられると考えています」(白川氏)
並行稼働をしなかった理由
今回のプロジェクトは、常に時間とリソース不足との戦いだったという。そのため、通常なら新システムのカットオーバー後、しばらくの間は問題発生に備えて旧システムも並行稼働させるが、今回のプロジェクトでは新システムの稼働開始と同時に旧システムの運用を完全に停止させたという。これにより、新システムと旧システムの並行稼働に伴う業務部門の労力を削減でき、少ない人数でプロジェクトを完遂できたという。
しかし、その副作用として、新システムのカットオーバー直後は初期トラブルに伴う混乱が生じ、今回の振り返りイベントでも「並行稼働させるべきだったのでは?」という意見がクックパッド側のプロジェクトメンバーから出た。
「もちろん、並行稼働をする方がいいに決まっていますが、経理部門の工数が限られていたため、どうしても並行稼働する余裕がありませんでした。そこで思い切って並行稼働しないことにしたのですが、その結果カットオーバー後にWorkdayの検索機能を中心にさまざまな不具合が発覚しました。
並行稼働しない分、本来なら事前に全ての業務プロセスを一通りテストしておくべきだったのですが、それもスケジュールの都合上ままならなかったので、結果的にテストケースが不十分なままカットオーバーせざるを得なかったのです。もう一度プロジェクトをやれるとしたら、やはり並行稼働か丁寧なテストのどちらかはやるでしょうね。ただ、当時のリソース不足の状況を鑑みると、やっぱり並行稼働は諦めざるを得なかったと思います」(中野氏)
最終的に「並行稼働しない」という決断を下した中野氏自身も、「理想を言えば並行稼働する方がいいに決まっています」と述べつつ、それでも当時の状況を踏まえ以下のように述べる。
「パッケージベンダーの米国本社からも『並行稼働の必要はない』というコメントをもらっていたので、それをうのみにしていたところもありました。しかし、『国内初物』となると、予想だにできない問題がいろいろ出てきました。ただ、どうしても並行稼働に必要なリソースを捻出できなかったので、ほかに選択肢がありませんでした。それより、『出てきた問題をいかに早くつぶすか』の方にリソースを集中投下する方策を考えた方が、現実的ではないかと考えたのです」(中野氏)
これに対して白川氏は、「私自身はこれまでどのプロジェクトでも、必ず並行稼働をしてきたので、その決定にとても驚いた」と述べる。
メンバーが振り返る、プロジェクトの「良かった点」
このプロジェクトを振り返ったとき、「ここが良かった」「この点は今後のプロジェクトにも生かしたい」といった声も数多く挙がった。ここでは、その中から代表的な声を幾つかピックアップして紹介する。
関連記事
- 1年半でシステム刷新のクックパッド、怒濤の「5並列プロジェクト」に見る“世界で勝つためのシステム設計”
海外展開を視野に入れ、“世界で勝つためのシステム構築“に取り組むことになったクックパッド。海外企業を参考にプロジェクトを進める中、日本企業のシステムとそれを支える組織との間に大きな差があることを認識した同社は、どう動いたのか。また、分散と分断が進み、Excel職人が手作業で情報を連携している状態から、どのようにして統合された一貫性のあるシステムに移行したのか――。怒濤のプロジェクトの全容が対談で明らかに。 - CIOの役割は「会社の戦闘能力を上げること」 でも、どうやって? 変化の渦中でRIZAP CIOの岡田氏が描く戦略は
これから自社の戦略を大幅に変更し、成長路線を目指すRIZAPグループ。ファーストリテイリング出身で、現在、RIZAPグループでITと経営をつなぐ役割を果たすCIO、岡田章二氏に、変化の時代に会社の戦闘能力を上げるための方法や業務現場との付き合い方、CIOとしての持論を聞く。 - 改革に成功するリーダーと失敗するリーダーはどこが違うのか “きれいごとですまない仕事”をやり遂げるために
フジテックCIOの友岡氏とクックパッド情シス部長、中野氏の対談最終回。今回は「改革に成功するリーダーと失敗するリーダーの違い」というテーマで話が進んだ。 - リーダーに大事なのは「IQより愛嬌」? 変革の大敵、“変わりたくない人々”を巻き込む方法
企業の変化を妨げる「変わりたくない人々」。CIOはどうやって彼らを納得させればいいのか。 - 日清食品HDのIT部門トップに聞く 「変化に強いリーダー」はどうやったら育つのか
これまでの当たり前を疑える目を持ち、社内外からさまざまな情報を集めてくるフットワークの軽さがあり、変化に対応できる柔軟なマインドを持っている――。そんな“変化の時代に必要とされるリーダー”は、どうやったら育つのか。
Copyright © ITmedia, Inc. All Rights Reserved.