中小企業をITで元気に!

7-4 具体的なトラブルの内容を見てみよう

 |  | 

【業務要件の変更によるトラブル】

情報システムを構築する場合に大きなトラブルに発展するケースの一つは、業務要件を正確に情報システムに作りこめない場合です。もともと業務要件を正確に定義することが難しいとを「7-2 正しい要件定義はできない」で説明をしました。

現実はシステムの開発過程で要件定義とずれていることが判明した場合、修正をしながら開発を継続します。修正する作業を「仕様変更」と言います。正確には間違っているのを正すのですから仕様変更というのはおかしいのですが、もともとの業務要件定義書を修正することになるので仕様変更と呼んでいます。定義書は正しくてその理解が間違っているケースでは修正行為になるのですが、工程間にまたがっている場合はやはり仕様変更という表現を使います。そしてこの原因が依頼側にあるか、受託側にあるかが極めてグレーなことがトラブルの根源になります。要件定義の質が悪かったり(時にはしっかりと文書として残っていないケースもあります)、システム開発に携わている人のスキルが低いと仕様変更が頻発して手戻り作業が一気に増えます。それでもプロジェクトマネジメントがしっかり行われていれば早期に対策を立て、被害を最小に抑えることができますが、マネジメント力が低いと開発の最終工程まで引きずり問題が増幅するのです。当然完成時期はずれ込み、完成までの費用は大きく膨らむわけです。家を建てる場合を例にとると、コンクリートに埋め込む鉄筋の数を設計で間違えたとき、基礎工事で気が付けば影響は少ないが、完成した後気がついたらほぼ建て替えに相当する費用が必要になるという事です。そしてこのケースに外部委託が絡んでいると、責任が委託側・受託側どちらにあるかを明確にする過程で責任転嫁の泥試合になってしまいます。以下代表的なトラブルの事例を説明します。

 

システムの性能が悪い】

システムの性能と言ってもいろいろな性能があります。機能性が足らない、画面表示に事時間がかかり過ぎ、入力データのチェックが甘くて不良データが入力される等です。

ここではわかりやすいように、スピードについて考えてみます。機能的な業務要件は正しくシステムで実現されていても、動作スピードが遅いと実際の利用場面で役に立たないことがあります。これもシステムの欠陥として問題視され、複合的な原因が絡んでその責任の所在が明確にならないことが多くあります。通常発生する原因のいくつかを以下に掲げます。

①コンピュータの能力不足

②利用しているインフラのソフトウェア性能が悪く過剰負荷になる

③業務プログラムの設計不良で過剰負荷になる

これ等の原因は相互に関係しあっているので、通常どこに原因があるのか断定が難しいのです。そしてもこの問題も当事者(ハードベンダー、インフラソフトベンダー、システム開発者)の特定が難しく犯人捜しをしている間にトラブルの影響も大きくなります。

 

【納期遅れの発生】

一口に納期遅れといいますが、その影響は軽微なものからシステム開発の成否にかかわるものまであります。例えば特定の部門だけが納期遅れで予定通りシステムを利用できなくても代替え手段があったり、従来通りの手作業で進めても現場にあまり負担をかけないケースは大きな問題にはなりません。しかし重要なシステムであるほど稼働が遅れると取引先や顧客に迄迷惑をかけることになり、大きな損失に直結することになります。それでも原因がはっきりしている場合は、対策や責任の取り方などそれなりの対応ができますが、複合原因である場合は厄介です。特に上流工程に原因があり、そのリカバリーに手間取ったり、リカバリーの途上で新たな遅れの原因が加わったりすると混乱に拍車がかかります。それでもプロジェクトの期間内で収束できればいいのですが、このようなケースで対策の当事者、責任者が不明確だと、大きくて長期のトラブルに発展することは間違いありません。そして残念ながらこのトラブルは工程を経ることに雪だるま式に大きく成長し、最終工程で牙を剥いてきます。最終工程を担当する人にすべてのリカバリー負荷がかかることになる訳です。情報サービス産業の一部が「ブラック企業」と取りざたされているのはこの辺にも理由があるのです。

 

【役割分担や担当者スキルの齟齬】

プロジェクトのトラブルは、お互いの役割分担が明確でない場合も発生します。これが委託のようなケースになると契約金額の多寡にも跳ね返ってきます。どうしてそのような問題が発生するのでしょうか。システム開発の作業はシステムが切れ間なく論理的につながっていなくてはシステムとして機能しません。従ってその作成にかかわる人たちの基本的な作業の役割分担を明確にしたり、確認する努力を事前にするのが普通です。しかし作業の全景が見えて居なかったり、作業を実施して初めて見えてくる作業等がプロジェクトにはたくさんあります。それがチャレンジングで複雑なシステムであるほどたくさん潜在化しています。そのような悩みが多いプロジェクトに挑戦していくプロジェクトメンバーには緻密なチームワークが望まれるのが当然なのです。しかし参加するメンバーの力量は定量的に示されるわけではありません。気心が知れた少人数でまとまったプロジェクトほど成功率が高いのは推して知るべしです。ひところSEやプログラマーの生産性は人により30倍以上も違うと言われていました。最近のシステム構築技術ではそこまでの違いになならないようですが、上流工程の優劣の差(品質の差と言い換えてもいい)は手戻りの作業の大小にかかわってきますので、参加メンバーのスキルはプロジェクト成否を左右します。仮に対象システムの開発に必要なスキルを持ち合わせていないプロジェクトメンバー構成の時は間違いなくプロジェクトはトラブルという汚物に塗れます。

 

【トラブルの解決に向けて】

ではどうすればいいのでしょうか。いろいろなケースがあるので、簡単に解決策をお示しすることが叶いません。ただ事前に予想できそうなトラブルに対しては、用意周到に対応策を用意しておいていざというときに一気に発動をする。突発的で予想できなかったトラブルには、素早く原因を分析して影響が小さいうちに対策を講じる。この姿勢で臨むしかありません。そしてこれがプロジェクトマネジメントの大きなミッションになります。皆さんも、うすうすお分かりだと思いますが、このような動きができる人材はあまりいません。そして経験が必要なので簡単に育成できません。

 大企業ではプロジェクトマネジメントの重要性を認識していてその育成に注力をしています。しかしいまだに充足してません。そのためにプロジェクト責任者を補佐するためにPMO(Project Manejment Office)という組織に経験豊かな人材を配置し、経験値を共有できる仕組みもとっています。それほど重要な事なのです。

中小企業ではどうすればいいのでしょうか。幸い大企業のような大規模のプロジェクトを発足させることは体力的にできません。従って小さくてリスクの少ないプロジェクトを手掛ける事から始めて下さい。大事なことは規模が大きくなるにつれてプロジェクトマネジメント能力が要求されることを知っておくこと。その場合に相談できる外部の有識者を持つことを心掛けて下さい。

 

【IT特有の問題もあります】

前項でプロジェクトマネジメントがトラブルを未然に防ぐ有力な手立てになると書きました。経験豊かでリーダシップのあるプロジェクトマネジャーなら実際にトラブルの要因が顕在化する前にトラブルの芽を摘み取ることをおこなっています。または発生しても芽が小さいうちに摘み取る芸当もできるのです。しかし情報システムの世界では困った問題があります。技術の進歩が速いのです。そのため一人の人が技術をキャッチアップしながら成長することは至難のわざです。よほど大きなプロジェクトで何人かの技術スタッフがいるプロジェクトならいざ知らず、通常のプロジェクトはプロジェクトマネジャーがテクニカルマネジャを兼務することが多く、そしてそれが一番効率的なのです。自分が未経験の技術を中心に回すプロジェクトのプロジェクトマネジャーはいろいろな局面で自信をもった判断が出来ないので、勢い、技術的な経験を重視したプロジェクトマネジャーの登用になります。そうなると今度はプロジェクトマネージメントの経験が足らないという結果になります。インフラ関係の技術が大転換するときにはこのような理由でプロジェクトマネジメント経験不足によるトラブルが多く発生します。