「気持ちが左右するITプロジェクト」
〜ITベンチマーキングSIG〜

1．はじめに
　 私は数年前からIT-SIGのPS研究会に参加し、プロジェクトに所属する個々のメンバーの気持ちや、やる気についての研究をさせていただいています。測れないものは制御できないという研究会代表の指導から始まり、さまざまなPSアンケートを作っては変えて、分析していますが、まだまだ整理できません。本稿では、典型的なシステム開発事例と、その失敗の原因となった「人の気持ち」に着目し、システム開発者側の反省や希望をまとめます。

2．典型的な事例(よくある話)
　 担当者から「予定されていた品質管理会議開催日までに結合試験が終わらない」と報告を受けた開発請負側のPMは試験途中までの分析を行い、全体の品質状況を予想して、あたかも終了した印象を持つ資料を作成し、お客様に報告しました。
　 結合試験が完了し、品質管理会議でお客様の承認を得た場合、次工程である総合試験を開始することができます。品質管理会議で様々な質問が出ましたが、PMはそつなく受け答えできたため翌日から総合試験を開始することになりました。
　 結合試験を終えずに開始した総合試験のため予想以上に故障が発生し、お客様側の責任者から強烈なクレームが発生しました。一部の機能については試験のやり直しを要求されました。単体試験のやり直しと再度実施する結合試験の状況は、それまでの報告頻度である週１回から、毎日報告が義務となりました。その後さらに再試験で故障が発生するとその原因や修正内容のお客様側の確認チェックが強化され、作業に遅れが生じてしまいました。遅れが発生したことに対して毎日１回であった報告が朝、昼、晩の1日3回報告となり、現場の作業者の報告粒度が異常に高まった結果、さらに作業が遅れるという悪循環を招いてしまいました。
　 最終的にはサービス開始予定時期が半年も遅れてしまったため、お客様側の情報処理部門の責任者は間接部門に異動になり、請負開発会社側だけでなく発注側も大きなコスト負担が生じてしまいました。

3．隠された事情(行動の元となる気持ち)
3．1　開発側の事情(PMの気持ち)
　なぜPMは結合試験終了していないにもかかわらず終了しているように報告したのでしょうか。多くの場合、結合試験が完了してプログラム納品する契約となっています。この納品日が、ずれた場合、違約金の問題が生じたり、納期延長手続きをしたりするのが大変なだけでなく、会社の信用問題にも発展することがあります。根本的な解決に向かう前に、いろいろな事情を考えてしまい、事なかれ主義や穏便に済ませたいという気持ちになった結果がこのような事態を招きます。
(1)作業するうえで表面上の体裁を取り繕ってしまいたいと考えてしまう。
(2)プロジェクトの目的より会社としての影響を優先して考えてしまう。
3．2　お客様側の事情(責任者の気持ち)
　 発注側にとっても請負会社からの進捗問題や納期遅延の問題が発生すると、社内的な説明が発生し、契約に基づいた面倒な手続きが発生する事態となります。たとえ、開発側からお客様側に相談していても「終わった報告にしてくれ」などという話になることが多いのです。
(1) 面倒は避けたい、計画通り進んでいると思いたい。　
　 このような気持ちに対して、開発側もお客様がそういう気なら、ということで割合と気が楽になって「結合試験は完了していないが、たぶん大丈夫だろう」と前述の通り、事なかれ主義を助長します。
　その後、実際の試験が進むと状況は内部事情を知っているお客様にとどまらず、上位責任者に問題が伝わり、事態が悪化していきます。試験が進まないくらい品質は悪い、特に設計工程以前の問題が内在していたため、表面上に現れたプログラムのケアレスミスをいくら刈り取っても品質が安定しないことが良くあります。このような場合の対策が「作業管理の強化」「報告粒度の極小化」など事態をさらに悪化させて行きます。このときのお客様の精神状態は、
(2) 開発側は信用できない。監視強化してさぼらないようにさせることが大事である。
　開発側も言い分は沢山ありますが、もはや何を言っても言い訳にしか聞こえません。お客様側の要求事項が曖昧で設計品質が悪いとか、報告のための作業がプログラム開発者のプログラミング作業時間より多いため、作業効率が極端に悪化するとか、本質的な問題を議論する余地が無くなります。

4．開発者側の取るべき態度(反省点)
　このような典型的な例は少ないにしても部分的には非常に似たケースが色々な場面で発生していると思います。例えばシステムで扱うデータが異常になるという、影響が生じる故障が発生した場合に、根本的な対策を打たず、故障発生箇所だけの対処を行った結果、データ異常となるケースが拡大した、などの事例なども類似のケースとなります。問題として捉える時点が早ければ早いほど、また考えられる影響や根本原因を追究し、対策が早ければ早いほど影響範囲の拡大を防止できるという、当たり前の摂理を「その時の気持ち」が狂わしてしまうことを忘れないようにしたいと思います。
　私の従事していたプロジェクトでも類似の事態が発生していましたが、何度も同じ過ちを繰り返すうちに「問題を早めに相談する」ことがお客様側の情報処理部門でも歓迎されるという、共通の価値観が醸成されてきました。開発側やお客様情報処理部門が利用部門へ問題の大きさや原因の所在を合理的に説明できるのは「問題発生初期」であることが理解されてきたのです。いちど「ごまかし」「怠慢」などを経て問題が大きくなった後は、合理的な説明がつかないので、さらに問題を隠蔽したり、事実と違う原因と対策が打たれたりして解決が遅れることが経験的に理解されてきたのです。

5．お客さまに求めたい態度(希望)
　お客様である皆さんが「問題は早く教えて欲しい」とか「問題はエンドユーザー部門も巻き込んで調整しよう」とか「こちらが悪いことは早めに是正しよう」となれば素晴らしいと思います。これまでの受発注の関係ではどうしても請負側へ要求することが多かったと思います。しかし、たいていの問題は一方的に是正できることは少ないので「協力して早めに解決する」ことがお客様の立場にとっても、最も有利な対策だと思います。契約条項にペナルティや賠償要綱を盛り込んで安心することとは全く正反対の対策です。開発現場の人の気持に左右されてプロジェクトは失敗もすれば成功もします。決して、契約だけではプロジェクトは成功しません。問題を言いやすいプロジェクトにすること、早めの問題摘出と根本原因追求、受発注相互の対策実施が、お客様側にとっても成功へのリスクヘッジではないかと思います。

以　上

IT-SIG，内容にご意見ある方、参加申し込みされたい方は こちらまでメールください。歓迎します。

ITベンチマーキングSIGホームページは こちら