1. 初回はRFPが雑ぱくだったため，要件定義の段階でつまずく 2. 2回目は開発委託先やシステム・アーキテクチャの選定を誤る 3. 3回目は例外処理を網羅した業務定義書を作成し，構築に成功

　リクルートの子会社で，書籍出版やアニメーション制作などを手掛けるメディアファクトリーは2008年1月，印税などの管理システム「RASかる」をカットオーバーさせた。それ以前にシステム構築を2回試みたが，初回は要件定義の段階で，2回目は実装段階で，プロジェクトが頓挫した。RFP（提案依頼書）が雑ぱくだったり，開発委託先やシステム・アーキテクチャの選定を誤ったりしたことが原因である。3回目の挑戦でも，思わぬ問題が生じたが，プロジェクト・チームの工夫で乗り切り，成功に結び付けた。

　構築したRASかるは，著者や装丁家，出資者など出版物ごとの権利者との契約内容管理，ライセンス収入管理，印税計算，分配金計算といった機能を備える。このうち特に重要なのが，分配金の計算である。

　分配金とは，出版物ごとの利益をその出資者に対して応分に分配注1したもの。その計算の処理手順は極めて複雑で，従来の印税システムでは自動化できなかった。そのため，経営管理部のスタッフが四半期ごとに，Microsoft Excelを用いて手作業で計算することを強いられていた。

　そこでRASかるの構築に当たっては，分配金計算の複雑な処理を自動化することが強く求められた。これが，RASかる構築の大きな壁になった。

　以下で，3回にわたったプロジェクトの様子を，時間の流れに沿って紹介していく。

1回目の挑戦
雑ぱくなRFPが命取りに

　最初のプロジェクトは，2002年春に始めた。基幹システムの刷新に併せ，そのサブシステムとしてRASかるを作る計画だった（図1）。同社には当時，システム専任の社員も，システム構築の経験を持つ社員も満足におらず，社内の共通部門から集めた数人の社員によってプロジェクト・チームが編成された。

図1●初回のプロジェクトが失敗した経緯

[画像のクリックで拡大表示]

　プロジェクト・チームは，手始めにRFPを作成した。ただし，「具体的に何をどのように書いたらよいのか分からなかったので，出来上がったRFPは雑ぱくなレベルにとどまった」（経営管理部 部長 福田広司氏）。後日，このことがプロジェクトを失敗に追い込む。

　RFPに対して，基幹システムの開発委託先であるベンダーA社から，概算見積もりが示された。予算とのかい離は小さく，A社への発注を決めた。

　プロジェクト・チームは，会計コンサルタントと相談しながら業務定義書の作成に着手した。しかし出版物の契約内容によって，印税や分配金の支払い条件が異なる上に，税務処理が多岐にわたるため，作業が難航した。「出版物の売れ行き次第で分配率が変わるケースもある。基本的な業務処理の手順について記述するだけで手いっぱいとなり，例外処理にまで踏み込めなかった」（福田氏）。

　業務定義書の完成度が7割程度の段階で，A社から「予定していたよりも，システムの機能が複雑になるので，請求額が当初見積もりの倍になる」との通告を受けた。RFPが雑ぱくであったため，機能がこれほど複雑になることをA社は予見できなかったのだ。

　プロジェクト・チームはそれでも諦めず交渉を重ねたが，A社とは折り合いがつかなかった。こうして，初回のプロジェクトはいったん白紙に戻った。唯一の救いは，機能が複雑になることを予見できなかった事実をA社が認め，費用が発生しなかったことだった。