1990年代の後半，私はそのころ流行していたデータ・ウエアハウスのパッケージ事業にかかわっていた。大所帯の事業部門を率いてデータ・ウエアハウスのパッケージ導入やサポートの仕事に追われる毎日だった。24時間体制でサポートデスクを運用しており，ユーザーのシステムでトラブルが発生すると，昼夜を問わずトラブル・シューティングのために出動するのである。

　当時，私は優秀な部下たちに恵まれていた。彼らは大概のトラブルは早々に解決して戻って来るのだが，手ごわいトラブルに遭遇して戻ってこれなくなることもあり，さらに応援のエンジニアを投入することもしばしばであった。

　そんなとき，私の部下たちが意識して心がけていたことがある。それは「良いニュースであっても，悪いニュースであっても，定期的な報告を欠かさない」ということである。

　難しいトラブルにぶつかって，その対応に真っ最中のエンジニアは，作業に集中している。ある意味，没頭する傾向がある。トラブル・シューティングでは，原因を想定して調査し確かめる作業を繰り返すわけだが，対応しているエンジニア本人は手順や進ちょくが分かっていても，解決を待っているユーザーにはそのことが伝わらない。結局，ユーザーお客様を苛立たせることになる。

　解決の糸口を見つけることができなくて暗中模索の状態にある場合，エンジニアは「まだ，解決の糸口がつかめていません」ということは言いたくないので，黙々と作業しがちだ。トラブルは解決できてなんぼ，解決できないうちは何を報告しても無駄，みたいな考えをしてしまうからだろう。

　そんなとき「作業を開始して1時間経ちましたが，まだ原因が分かっていません。解決のめどが立っていないことをご報告いたします。応援を呼びましたが，私はさらに続けて作業をいたします。状況の如何にかかわらず1時間ごとに報告いたします」という報告が普通にできるエンジニアがプロなのだ。

　なぜなら，すぐそばでトラブルが解決するのを待っているユーザーの担当者も，今どんな状態なのかについて彼の上司や現場で待っているユーザーに報告しなければならないからである。早々に復帰するめどが立っているのであればそのように連絡したいだろうし，今日中の解決がとても無理なのであればユーザーを待たせたりせず，今日は諦めてもらうなどそれなりの対応をしなければならない。

　こうなってくると，トラブルを解決すればよい，という問題ではなくなってくる。何が重要であるかは，場面によって，人によって，立場によって全く異なるのである。そこまで分かって作業しているかどうかが，プロであるかないかの分かれ目なのだ。

　かつて私は，これができなくてユーザーからひどく叱られたことがある。「全く報告なしで黙って作業して3時間で解決するエンジニアよりも，30分とか1時間ごとに，ちゃんと報告ができて5時間で解決するエンジニアの方がはるかに上等だ」とまで言われた。

　自分のことを待っている人，今自分がやっている作業が終るのを待っている人がいる場合，このような一見意味がないような連絡や報告を欠かさないことが，重要である。ユーザーを相手に仕事をするITのプロとして，身に付けたい基本的な行動パターンである。

木村 哲（きむら てつ）
ビーコンIT
コンサルティング部 チーフコンサルタント
1980年にIT業界入りし，パッケージ・ソフトウエアの販売を担当。1992年頃よりデータ・ウエアハウス，ビジネス・インテリジェンスの分野の事業を担当し，多数のパッケージソフトの輸入，企業導入を行う。2000年よりコンサルティング事業にかかわり，立場をそれまでのRFPを受けて提案する側から，要件定義/RFP作成をする発注側に転じる。発注する側，受ける側の両方の視点に立ったプロジェクト・マネジメントを得意とする。

■本特集に関連して，日経SYSTEMS 2008年4月号に特集「プロフェッショナルの現場　ユーザーに尽くし，ユーザーに信頼される」を掲載しています。ぜひ併せてお読みください。