ブラックボックス化したシステムの刷新における「不」に向き合う

なぜこのプロジェクトは困難な状況に陥ったのか？

このプロジェクトのマネジメントを担当していた当時は、目の前の難局を乗り切ることで精一杯だったのですが、今振り返ってみると、プロジェクトの開始前から幾つかの「トラブルの条件」がそろっていたように思います。以下、トラブルの条件を紹介しましょう。

長命のシステムであったこと

第一の条件は、今回リプレース対象となったのが「寿命の長いシステム」であった点です。例えば、Webサービスのシステムなどは、ビジネス環境の変化に応じて絶えず仕様の見直しが行われますし、数年おきに比較的大きな改変も行われます。しかし、今回リプレースの対象となったのはバックオフィス業務を担う基幹システムで、頻繁に入れ替えが発生するものではありません。そのため、自ずと長期間運用し続けることになり、その間に初期構築時のナレッジやノウハウが失われがちです。

しかも、業務の変更や法改正対応などで細かな修正やメンテナンスが長年のうちに重なり、つぎはぎ状態になっていることも多々あります。長年の運用で構築当初のノウハウは失われている上、細かな増改築を重ねて複雑化したシステムの仕様を把握するのは、やはり至難の業だといえます。

業務のブラックボックス化

長年の運用の過程でシステムに対して加えられた増改築は、その場しのぎのために行われたものも多く、本来はリプレースのタイミングで「必要な機能」と「不要な機能」をきちんと切り分けて、無駄を削るのが理想です。しかし長年使われてきたシステムの場合、システムそのものがブラックボックス化しがちであるだけでなく、それを使って業務を遂行する人員も戦略的にアウトソース化されていることが多く、業務そのものもブラックボックス化されていることが少なくありません。

本来であれば、定期的に業務の棚卸しをして、必要な業務と不要な業務の仕分けをするのが理想的ですが、業務がブラックボックス化された状態ではそれも叶いません。結果、運用を続けるうちに不要な業務がどんどん溜まって業務の肥大化が進み、最終的にはそれらを温存したまま無駄なコストと時間をかけてシステムのリプレースに臨まざるを得なくなります。

業務の現状を語れる人がいない

こうして業務がブラックボックス化されてしまうと、要件定義でユーザーから要件やニーズを引き出そうとしても、誰も現状の業務を語れなくなっているため、どうしても「とりあえず現状のままで」となりがちです。

私たちはこれを「現ママ問題」と呼んでいるのですが、これでは要件定義で正確な要件を洗い出すことはできません。それではと、現行システムの仕様から逆算して現行業務を割り出そうと思っても、先述の通りパッケージ製品は中身がブラックボックスなので、それもままなりません。

パッケージから別のパッケージへの移行

本プロジェクトが困難を極めた要因の1つが、「パッケージ製品を乗り換えた」ことにありました。もともと使っていたパッケージ製品のバージョンアップだけで済めば、これほど苦労することはなかったはずです。しかし今回は、異なるパッケージ製品への移行だったため、既存業務とのフィット＆ギャップを一からやり直す必要がありました。

これが意図通りに運ばなかったのは、既に書いた通りです。加えて、パッケージの導入効果を最大限高めるために、今回のプロジェクトでは「業務をパッケージの仕様に合わせる」ことを目指しました。これによりアドオン開発が不要になりますし、パッケージがもともと実装しているベストプラクティスに業務を合わせることで、業務効率アップの効果も期待できます。

しかし実際には、今回リプレース対象となったシステムはリクルートグループ全社で利用されるものであり、ユーザーやステークホルダーが極めて広範に渡っていました。パッケージ導入に合わせて業務のやり方を変えるとなると、実に多くの業務現場で仕事のやり方を見直す必要があり、場合によっては業務効率の悪化やコスト増も懸念されました。それら懸念点の一つひとつを検討する時間は、今回のプロジェクトでは到底確保できませんでした。

• 

トラブルを防ぐために心掛けておくべきポイント

今振り返ってみると、こうした大きなプロジェクトの発足を見越し、開始前にこれらの「リスク」を丁寧に摘み取っておけば、もう少しプロジェクトを順調に推進することができたと思います。

例えば、パッケージ製品のフィット＆ギャップに関しても、私たちは事前に1100項目にも及ぶ極めて入念な確認を行っていたにもかかわらず、検討を進めていくうちに「実はフィットしていなかった」というケースに多々突き当たりました。そこで現在では、机上でのフィット＆ギャップと実態との差異は必ず発生することを前提に、実際に差異が発覚した際の対応方法をあらかじめプロジェクト方針として決めておくよう心掛けています。

また既に述べたように、本プロジェクトが困難な状況に陥った要因の1つは、システムと業務がブラックボックス化されていたことにありました。したがって、現行のシステムと業務を見える化する継続的な取り組みが、後に控える刷新プロジェクトでのリスクを取り除く最も有効な対策になります。

実際、現在ではシステムおよび業務について知見を持った社内の人員を常に一定数キープしており、ナレッジの消失を防ぐとともに、機能拡張のたびにシステムや業務が無駄に肥大化する事態を回避して、次の刷新までシステムの健全性を保てる体制を保持しています。

とはいえ、場合によっては平時からこうした人員を社内で確保しておくことは現実的には難しいかもしれません。そんな場合は、せめて刷新プロジェクトが本格的に立ち上がる前に十分な準備期間を確保して、その間にシステムおよび業務の現行仕様を正確に把握してからプロジェクトを始めるべきでしょう。

もし、そうした準備期間すら確保できない場合は……もはや大トラブルに陥る可能性はかなり高まることを覚悟するほかありません。逆にいえば、そうしたケースではあらかじめ「覚悟」を決めて、備えを十分に整えておけば、乗り切れる確率は上がります。

ここで最も重要になってくるのが、経営層や意思決定者に対して「この条件下ではプロジェクトリスクの顕在化は必至であり、納期やコストを守ることは困難である」ことをきちんと説明し、理解を得ておくことです。これをやらずに、達成困難な計画を無理やり押し通そうとすると、大抵の場合は品質が犠牲になり、結局プロジェクトは失敗に終わります。

プロジェクトの状況が厳しくなることは避けられないことを理解してもらうために、あらかじめ一部の機能だけでプロトタイプ開発を実施してみるのも手です。あらかじめどのあたりに不確定要素があるのか確認できますし、選定したパッケージ製品に最適な工程の組み方も学習できます。

• 

当社では、これらのポイントを組織としての学びに昇華し、各プロジェクトで共有するようにしました。結果、大規模なパッケージ導入プロジェクトや、ブラックボックス化したシステムの刷新プロジェクトで発生しがちな「不」に向き合い、先を読んだマネジメントを実現できるようになりました。状況や背景など多少異なるかもしれませんが、私たちのこうした経験を、皆さんのプロジェクトマネジメントに役立てていただければ幸いです。