業務システム企画・運用支援 2/26

  業務システムはの開発の問題点は、開発ではなく、企画と運用開始時に発生します。基本的には、業務フロー(仕事の進め方のマニュアル等)のうち、量がおおく単純作業だが量が多い部分にコンピュータなどを導入することが基本なのですが、その業務フローが明確になっていない場合、システムの企画自体、担当者の思い込みばかりが先に立ち、そのシステムを導入することによるメリットが不明確、というか、開発したことにより利益・売上が伸びるならともかく、変わらないもしくは減ったりしては、目もあてられません。業務システムは常に、開発運用のコストと利益のバランスを考えて構築する必要があります。システムとしてうまくいくかどうかは、企画段階でここらへんをキチンと詰めているかどうかで決まります。また、運用開始時に実際に運用する部署と部隊への支援がキチンとしていなければ、使ってもらえないもしくは、使われていないことに気づかない、などという無様なことになります。

 とはいえ、業務フローが明確になっている業務システムの開発というものを残念ながらやってきたことがありません。まあ、なぜそうなのか私がたまたまそうゆうプロジェクトに当たっただけなのかどうかは、また別の機会にコメントするとして、ここでは、業務フローが明確じゃない段階での、業務システム開発運用のための方法について、どのように対処してきたかを述べてみたいと思います。

 ポイントは

お客様が主体になって企画・運用支援体制を整える
ソフトの開発については、ベンダー側主体で体制を整える
あらかじめ、開発途中の仕様変更が煩雑に発生する旨、プログラマーには、徹底しておく
企画と運用支援体制のメンバー・社内組織は同一になるよう調整する
プロジェクトの目的を、各チームごとに明確に持たせる 例 ・企画・運用支援チームは、運用する部隊が運用する気になるような仕様と体制を考える ・プログラマーチームは仕様変更に速やかに対応できるよう、基礎設計しておく コーディネートチームは、目標の優先順位を明確にしておき、常に各チームとの調整を行いつづける

 ここらへんはまさに微妙な駆け引きとなります。小さなプロジェクトなら運用担当者と企画・運用支援担当者がいっしょだったりするので、なんとかなるのですが、大きなプロジェクトになると大変です。コーディネータとして参加したことがある、某建築系DBについては様々部署支店 チームが入り乱れ、それぞれ様々利害関係を持ってくるので、打合せにつぐ打合せで、さらにその後のちょっとした話し合い、人間関係等 根回し等 正直 気苦労ばかり多く、正式には認めてもらえない(お金を払ってもらえない^_^;)作業が非常に多く、直接の発注主には迷惑をずいぶんかけてしまいました。まあ、ほとんどの方には評価していただけなかったですが、当初話しを持ってきた人との間で約束したことは、実現できたので、個人的には満足しています。

 さて、ポイントをいくつかあげましたが、この手の業務システムでもっとも重要なことは、実際に使ってもらうことです。そのために大事なのはシステムの品質もそうですが、実際は根回しと体制作り、それにつきます。結局システムだなんだといっても、大事なのはその企業文化に合った導入方法をきちんと踏まえることです。逆にいえば、現場の企業文化をわかっているキーマンを企画・運用支援体制に組み込めるかどうかが、そのプロジェクトの成否にもっとも重要なファクターとなります。

 みなさんも、こけそうなプロジェクトがあれば、まずキーマンの見直しをしてみてはいかがでしょうか?