出動! 火消しエンジニア 火事場では何が起きているのか

加山恵美
2006/3/9

プロジェクトでのトラブル発生を「火が出た」、さらに悪化し収拾がつかなくなると「火事場」などと呼ぶ。そんな修羅場でITエンジニアは何を見、何を学んだのか。事態収拾を図る「火消し部隊」として燃えさかる現場に投入されたあるITエンジニアに、火消しの極意を聞く。

火災発生、緊急出動せよ

 どんな仕事場にも多少のトラブルはある。不具合は質も規模も多岐にわたるが、端的にいえば何かが「うまくいかない」。それが積み重なるとプロジェクトは制御不能な状態に陥ってしまう。

 日本ヒューレット・パッカード(日本HP) コンサルティング・インテグレーション統括本部 金融アカウント第一本部 第三部 プロジェクトマネージャの田中淳一氏も、いくつかの修羅場をかいくぐってきた1人だ。通常の勤務に比べて何倍も激烈な経験だが、多くの教訓を得る場でもあるという。

 田中氏はこれまでに何度か、火事場となったプロジェクトに助っ人として合流した経験がある。まずは火を噴いた現場の生々しい様子を話してもらった。

 「最初はとにかく混沌(こんとん)としています」

 あるプロジェクトの規模は、総勢で約100人。そこに火消し部隊として田中氏を含め約60人が追加投入された。田中氏が着任したとき、そこは混乱を極めていたという。

 「誰もが『自分(が担当した範囲)は正しい』と主張しているのですが、システムは正しく機能していない。不具合の原因特定も困難な状態でした」

これでは検収ができない

日本ヒューレット・パッカード コンサルティング・インテグレーション統括本部 金融アカウント第一本部 第三部 プロジェクトマネージャ 田中淳一氏

 システムの不具合の再現性さえも定かではなかった。不具合の出た機能の1つにメールによる通知があった。ある状況の変化をメールで通知する機能があるのだが、メールが正しく届かない現象が確認されていたのだ。だが正常に受信できるときもある。発信するアプリケーションに原因があるのか、経由するネットワークに原因があるのか。複数の要因が絡んでいるようでもあった。

 そのほかの不具合も絡み合い、システム全体の性能や信頼性も評価できる状態ではなかった。検収間近にして関係者は頭を抱えていた。

 幸いなことに顧客とはつきあいが長く、関係がこじれるところまではいっていなかった。だが「この状態では検収の印を押せない」と顧客側の責任者はいった。不具合があるなら原因を特定すること、どうしても納期に間に合わない機能があるなら、完成する見通しを出すこと。こうしたことをクリアにしなくては顧客に説明ができない。

 混沌とした中では、まず現状把握から始めなくてはならない。不具合を洗い出し、原因を明らかにすることだ。

 「コントロールを取り戻すことが最初の目標でした」

合流直後は一触即発の緊張状態

 まずは制御不能な状態から脱しなければならない。例えてみると、操縦ができずに急降下している飛行機にメンバー全員が乗り込み、運命を共にしているような状態だ。多少機械に欠陥があるのは承知だが、まずは何とか操縦できる状態にする必要がある。

 危機的な状態は突然発生することもあるが、多くは気付かぬうちにゆっくりと進行している。問題が明らかになるころには事態はかなり深刻になっていることが多い。まずいと思ってももう自分1人では抜け出せない。

 収拾がつかなくなれば救助隊が駆けつけることになるのだが、残念なことにたいてい拒絶反応が出てしまう。

 「最初の3日間は大ゲンカですよ」

 田中氏は苦笑いする。現場でそれまで努力してきたメンバーにはプライドがある。加えて疲労と緊張で気が立っている。そこへふらっとやって来たメンバーから基本的なことを質問されたり、「ここが原因じゃないの?」と担当範囲の不具合を疑われたりすれば、怒りが爆発してしまうのも無理はないのかもしれない。胸ぐらをつかんでケンカ寸前になるとか、怒鳴り声が上がるとか、そういう場面を田中氏は幾度となく目にしてきた。

不具合はコミュニケーション不全から

 一般論として、収拾がつかなくなる原因を考える。よくあるのが「もともとの仕様や定義があいまい」のままプロジェクトを進行させてしまうことだ。これは顧客だけが悪いとは限らない。顧客の要求を正しく把握せずに開発側が開発を始めてしまうこともある。

 例えば顧客がおでんを思い浮かべながら「ここは温かいものが食べたいですね」と話し、開発側が即座に「ああ、温かいものですね。了解しました」とシチューを作り始めてしまうような思い違いだ。「温かいもの」という言葉で思い浮かべるものはそれぞれ違うのに、それに気付かないまま分かったつもりで物事を進めてしまう。顧客は調理場でぐつぐつ煮え立つ鍋の湯気を見て「おでんを作っているのだろう」と期待するのだが、出てきたシチューを見て当惑してしまう。

 開発側の連携が失敗していることもある。自分の割り当てられた処理を指示どおりにやったにもかかわらず、その先の処理で問題が起きてしまうこともある。再び調理場を例にするなら、指示どおりに肉を切る処理をしても、実は途中で違う肉に変わってしまったのに気付かずに流れ作業が進んでしまい、違う料理になってしまうようなことだ。

 いずれにせよ、鍵はコミュニケーションの不具合にある。田中氏も「コミュニケーションのすれ違いがよく問題を引き起こします」と話す。

 問題に気付かない、気付いたのに伝え損ねたということも往々にしてある。同僚の作業の欠陥に気付いても伝える勇気がなかった、自分の成果物で懸念すべき部分があったが、指示の範囲内と解釈して報告しなかったなど。完成度を追求しすぎてあだになることもあるが、勇気がなかったわけでも無視したわけでもないのに問題の深刻さを読み違えてしまうことだってある。

 不具合の発生するところには、コミュニケーションで問題が起きている可能性が高い。できるだけ早いうちに発見し対処できればいいのだが、放置すれば傷は深くなる。

   

今回のインデックス
 出動! 火消しエンジニア 火事場では何が起きているのか (1ページ)
 出動! 火消しエンジニア 火事場では何が起きているのか (2ページ)
自分戦略研究所、フォーラム化のお知らせ

@IT自分戦略研究所は2014年2月、@ITのフォーラムになりました。

現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。

これからも、@IT自分戦略研究所をよろしくお願いいたします。