全3913文字
PR

 コストや期間が限られているシステム化のプロジェクトには割り切りが必要ですが、人は「現状」に固執しがちなもの。特に、パッケージソフトウエア導入プロジェクトでは、機能のミスマッチが炎上の火種になりやすいといえます。設計の見直しを迫られそうになっている事例とその対処策を見ていきましょう。


 プロジェクトマネジャー(PM)の玉田圭は、目をぱちくりさせた。

「印刷機能、ですか?要件定義でも、外部設計時にもそんな話は出なかったと思いますけど」

 黒川経理グループ長は、顔をしかめた。

「まあ、設計書になかったのは確かだけどね。必要なのは事実なの。会計締めの3時前に、入力伝票を束にして突き合わせチェックしてるのよ。2年前の監査法人の指摘でチェックすることになったの。監査指摘なんだから、無視できないでしょ?」

「はあ、しかし…」

 玉田PMは、後の言葉を飲み込んだ。しかし、遅過ぎる。結合テストも半ばを過ぎた今になって機能追加を求められたら、ただでさえタイトなスケジュールがズタズタになってしまう。

 そもそもこの場は、2次リリース分の伝票の要件定義セッションなのだ。玉田は話題を変えた。

「今日は支払伝票と振替伝票について、でしたね」

 黒川がうなずいた。

「まず、処理取消機能について確認したいんだけど」

「処理取消機能?『でんでん丸』の標準機能には、処理を取り消す機能はありません。一度入力した伝票の情報は即座に管理会計機能に連携するので、取り消しはできないんです」

「じゃあ、伝票入力を間違えたらどうするの?」

「伝票修正機能を使います。修正を入れると、自動的に差額の逆伝票仕訳を吐き出します」

「それじゃダメなのよ。取消処理がうちの標準なんだから。あのね、新人が実機で伝票入力の練習できるのも、処理取消があるからなんだから」

 玉田は頭を振った。

「トレーニングに実機を使うのは、問題があるような気がします。見直しを考えられてはいかがでしょう」

「ダメよ。今やってることができなくなるんだったら、何のためにパッケージを導入するのか分からないわ」

 黒川はにべもなく否定した。

 やれやれ。玉田はため息をついた。パッケージを活用してBPR(ビジネス・プロセス・リエンジニアリング)をするという話はどこへ行ったのだろう。業務をパッケージに合わせて簡素化するという方針が示されたにもかかわらず、ユーザー代表の黒川はことごとく現行事務に固執しようとする。

パッケージを使ったBPRを実施するはずが、ユーザーの機能追加要求が続出
パッケージを使ったBPRを実施するはずが、ユーザーの機能追加要求が続出
[画像のクリックで拡大表示]

トラブルの要因

 開発プロジェクトには目的・目標があります。事務の効率化や新商品・サービスの提供、経営の精緻化、内部統制の強化などです。プロジェクト憲章などに定めた目的・目標に沿って、プロジェクトのスコープが定められているはずです。

 気をつけたいのは、目的や方針がお題目にとどまっていて、プロジェクトのステークホルダーに浸透していない場合があることです。そもそも目的や方針は、日常業務レベルまでブレークダウンされるべきですが、組織によっては、それが十分できていない場合があります。特に事務ルールは、問題が出れば責任を問われるのは現場ですから、現状のルールを変えることに抵抗があるのはやむを得ないと言えるでしょう。

 しかし、パッケージの導入を選択するのであれば、簡素化や割り切りは必須です。アドオン開発やカスタマイズは、開発コストだけではなく保守コストも押し上げます。煩雑になった事務を整理して、シンプルにするというせっかくのチャンスも失うことにもなります。スコープに関するあつれきは、看過できない、正しく解決すべきトラブルと認識する必要があります。