今回の「動かないコンピュータ・フォーラム」では，気遣いと動かないコンピュータの関係について考えてみたい。いい人が多いプロジェクトは成功の可能性が高いのか，と言い換えても良いかもしれない。

　前回の「動かないコンピュータからは脱出できない，陥らないことが重要」で，記者は「システム開発にたずさわっている技術者には誠実で紳士的な方が多いと感じますが，『動かないコンピュータ』からの脱出には蛮勇も必要ではないでしょうか」と書いた。気遣いとは，ここでいう誠実さや紳士的という言葉を言い換えたものだと考えてほしい。

　偶然だが最近，この言葉を痛感するようなシステム開発にまつわるトラブルを知ったこともあり，もう少し詳しく「誠意とシステム開発の関係」について考えることにした。

　なお，動かないコンピュータ・フォーラムについての説明は文末に記した。ご不明の方はお読みください。

気を利かせたはずの対応でプロジェクトが泥沼に

　記者の知ることとなったトラブルとは以下のようなものである。

　ある中堅システム・インテグレータが，急成長しているサービス業者の受発注管理システムの開発を請け負うことになった。営業開始から稼働までの期間が短かったこともあり，そのインテグレータの担当エンジニアは，正式な契約書を取り交わす前から要件定義を開始した。

　インテグレータ側の意見になるが，このときユーザーとベンダーであるインテグレータの間では，口頭でシステム開発をこの会社に発注するという確約を得ていたという。正式な受注を待っていると開発期間は3カ月しかなかった。「到底，システムを完成させることはできない」。こう判断したベンダーのエンジニアは，ユーザーから契約をほのめかすメールが届いたことで，要件定義をスタートさせたのである。ユーザーのことを気遣ったといって良いだろう。

　だが，このプロジェクトはその後，トラブルに突入する。要件を確定する間に開発規模が膨らみ，当初の見積金額を大きくオーバーすることになったからだ。ベンダーは，要件の確定後に新たな見積もりを提示したが，ユーザーはこれを受け入れなかった。

　すでに作業を進めていたベンダーは，作業終了分についての支払いを求めたが，ユーザーは，「正式な契約書を交わしたわけでもないのに作業を開始したベンダーの勘違いだ」として，要件定義などの作業分の支払いを拒んだのである。このベンダーとユーザー企業の間で，トラブル処理の方法は今も決着していない。

　最近では多くのベンダーで，有償作業を開始するかどうかについて，法務部門などがチェックしている。この会社は，正式な契約書を交わす前，あるいは入金を確認する前の段階で作業を開始した。作業の進め方に甘い点があったことは確かである。だが，記者には，気遣いを示したつもりのベンダーの対応が，プロジェクトをトラブルに巻き込むキッカケに思えて仕方がない。

気遣いなのか責任回避なのか

　システム開発プロジェクトには，システム部門，利用部門，開発ベンダーなど，利害の異なる様々な立場の人間が参加する。当然，これらの人間の思惑は異なる。とはいえ，プロジェクトを進めていくためには，こういった思惑の異なる人間をまとめていく必要がある。

　全体をまとめるプロジェクト・リーダーやプロジェクト・マネジャーが必要なことは間違いないが，こういった人間がいればすべてが順調に進むわけではない。通常であれば，複数の人間で共同作業を進める場合に，気遣いは不可欠だといってよい。しかし，システム開発プロジェクトにおいては，気遣いがマイナスの方向に働くことがあり得ると思うのだ。

　ここでも実例を挙げたい。

　ある大手企業が有名ベンダーに依頼したプロジェクトがトラブルに陥った。基幹系システムの再構築を進めていたのだが，要件定義すら完全に終えることができなかった。ユーザーはこのプロジェクトを中途で断念した。プロジェクトを断念するまでの間に多額の費用をかけていたという。

　このプロジェクトで問題なのは，ユーザーもベンダーもプロジェクトが順調に進んでいないことを知りながら，互いに対処策を取らなかったことだ。ユーザーに言わせれば，「ベンダーの成果物は歯抜けが多く，実際のプロジェクトで利用できるものではなかった」。ベンダーに言わせれば，「ユーザーの仕様がどんどん変わっていき，要件をまとめることができなかった。そのため追加開発分が膨らんで，結局見積もりを大きく見直すことになった」ということになる。

　だが，ユーザーはある時期まで，ベンダーの要望通りの契約金を支払った。逆にベンダーは，ユーザーの責任者に対して，仕様変更が相次いでいるために膨大な追加開発が必要になること，その結果，開発金額が当初の見積もりを大きく上回ることを知らせなかった。プロジェクトをそのまま続けることが不可避な段階になって初めて，両社は相互に問題があったと指摘し合うようになった。

　なぜ両社は，問題点を相互に伝えようとしなかったのか。記者の取材の範囲では，「毎日のように顔を付き合わせて仕事を一生懸命にやっている人間に，これではもうダメだというようなことを言うのは難しかった」というものだ。相手を気遣っていたからだ，ということになる。

　実際には，ベンダーやユーザーには別の思惑があったのかもしれない。ベンダーは開発規模を大きくすることで売り上げを伸ばそうと考えていたのかもしれないし，ユーザーの担当者は自分の責任を認めたくなかったのかもしれない。

　ともあれ，間違った気遣いがプロジェクト全体に悪影響を与えたことは間違いない。記者には，気遣いという言葉で自らの責任を回避することで，トラブルが拡大した典型例のように見える。

　日経コンピュータでは，システム開発におけるトラブルを減らすための有効な手法として，プロジェクトマネジメントがあることを指摘してきた。プロジェクトマネジメントの重要な要素の一つに，コミュニケーションマネジメントがある。その意味するところを乱暴にまとめると，プロジェクト・メンバー間で，迅速で正確なコミュニケーションを実現することがプロジェクトを成功させるために必要だということだ。

　コミュニケーションマネジメントの観点から見ても，ここまで書いてきたベンダーやユーザーの対応に問題があることは間違いない。以上のようなことから，システム開発における，気遣いに疑問を持つのである。

信頼感のない関係でプロジェクトを進めるのは難しい

　だが，プロジェクトを成功裏に終わらせるためには気遣いが重要だという声も多い。記者は，前々回の動かないコンピュータ・フォーラムで，システム・トラブルからの脱出方法を，IT Proの読者の皆さんに尋ねた。この問いに対して，皆さんから90件弱のご意見をいただいたが，誠意ある対応や信頼感の回復が重要だという意見がいくつもあったのだ。以下に実際のご意見を示すことにする。