トラブルにおけるマネージメント / 西田 則夫

システム開発の業務に携わって20数年になりますが、現在は、プロジェクトのマネージメントを中心に現場での仕事を長年続けています。ここ5年ほどは、いろいろなトラブルが発生したプロジェクトの火消し役をおおせつかり、なんとか成果をあげて、トラブル発生イコール私の名前がでるという図式で、幸か不幸か存在価値がみいだせています。一口にトラブルといっても、システム設計中、実装局面、テスト中、果ては運用開始後といったいろいろな局面が存在します。
そして、その発生原因にしても種々、いろいろ、複合的な要因がからみあって単純にはいえないのが現実です。ひとついえることは、順調にいっているプロジェクトはそれなりにリスクが前もって対処され善循環のプロセスが働く。それに反してトラブルプロジェクトは打つ手、打つ手が後手になり普通ならやらなくてもよい作業(トラブル対策会議、重箱のすみをほじくる管理資料、顧客、上司へのいいわけ報告書作成等)が割り込んできて、なおかつメンバーのモラール(やる気)を低下させ、それによる工程の遅延、ミスにつながり、悪循環が繰り返されます。
 さて、こんな時どうするかですが、私の経験では、開きなおりしかないです。
普通の手順できれいにまとめることは、とてもできない状況が多いため、ベストとは思いませんが、「トラブルプロジェクトの対応は終わりよければすべてよしの気持ち」で、
1.通常の進め方でなく、早い決断と思い切った処置が必要
2.途中の過程より最終の結果を優先する
 私が携わったこういったプロジェクトのお客様とはその後、良好な関係を続けさせてもらっておりますが、お客様がみな体力のある大企業ばかりであったのも幸いだったかもしれません。これが、中小企業のお客様相手であったとしたら、直接、経営にかかわる問題に発展していく可能性もあったかもしれません。ただ、こういったトラブルはすべてベンダー側の責任というわけでなく、お客様側にも取り組み甘さがあったことは否定できません。
いかにすばらしい目標をかかげてもそれを実際、使えるものにするのが重要で、それには、お客様側の推進者とベンダーがいかに協力しあえるかで、ベンダー側の能力はもとより、推進者の姿勢が大きく影響します。そういった意味で経営戦略からIT導入、運用までをサポートするITCの重要性はますます高くなるのではないでしょうか。


■執筆者プロフィール

西田 則夫(Nishida Norio)
情報処理プロジェクトマネージャー、ITコーディネータ
マネジメントの経験を顧客満足の向上に役立てたいと思います。
Norio_Nishida@cii.csk.co.jp