何か新しいことを始める時の、期待と不安が入り混じったような気持ち――こんな気持ちを味わうのは入社式以来かもしれない――秋山さと美はそんなことを考えながら、エレベータのボタンを押した。

　秋山は本日付で、アーキテクト部に配属になった。これまで所属していた開発部の本部はビルの5階に置かれていたが、異動先のアーキテクト部の部屋は7階にある。左手には私物を詰め込んだ紙袋が3つ。たった2年でこんなに私物が増えていたことに我ながら驚きつつ、短いようで長かった2年の歳月を改めて思い返す。2階分の移動がこの2年で積み重ねた自分の進歩のように思えて、なんだかくすぐったい気持ちになった。

　「始めまして、本日付でアーキテクト部に配属となりました、秋山さと美です。未熟者ですが、精一杯頑張りますので、どうぞよろしくお願いします！」。

　秋山の明るい声が部屋に響き渡り、おー、という声とともにパチパチと拍手の音。
「入社2年目かぁ、ういういしいねぇ」
「ほんと。私にもあんな頃があったのね〜」
「いや、お前は最初からふてぶてしかった」
「なにそれ、失礼ね！」

　先輩メンバーたちの盛り上がりをよそに、秋山は早くも心細い気持ちになりかけていた。
――なんだか経験豊富な先輩ばかりみたい…私みたいな新米に、ほんとにアーキテクト部の仕事なんて勤まるのかな？――
　一抹の不安を感じつつ私物をデスクに片付けていると、主任の阪井から声がかかった。
「秋山さん、一段落したらちょっとこっちに来てもらえるかな？」

初体験トラブル・シューティング！

「すみません、お待たせいたしました！」
ノートとペンを片手に阪井のところへ駆けつけると、
「あ、急かしちゃったみたいで申し訳ない。そんなに急ぎってわけでもなかったんだけどね」と、ちょっとすまなそうな顔をしながら、
「ええと、秋山さん。改めまして、アーキテクト部へようこそ。既に話は行っていると思うけれど、秋山さんには、先月から新しくスタートしたナレッジセンター・レスキュー・サービスの要員として活躍してもらいたいと思っています。ご存知のとおり、ナレッジセンターでは社内外から寄せられる依頼に応えてトラブル・シューティングや技術調査を行っている。こういった作業を、先輩メンバーと一緒にやってもらうことになります。さて、秋山さん。これまでいくつかのプロジェクトで開発に従事してきたと思うのだけれど、その過程でトラブル・シューティング、あるいはそれに類する作業を担当したことはあるかな？」

「トラブル・シューティングですか？えーと…自分の作ったプログラムの不具合を修正するためにソース・コードを見直したりしたことはありますが、大規模な調査を担当したことはまだありません」
「なるほど。じゃあ今日は、簡単なサンプル案件を題材にして、実際にトラブル・シューティングの進め方について学んでもらうことにしようか。まず、この資料に目を通してみてくれるかな」

　そういうと阪井は、手元のファイルから一枚の資料を取り出して秋山に手渡した。

「わぁ、文字化けですか…実を言うと私、このあたりの話はちょっと苦手なんですよ」
「ははは、最近の若い人には多いみたいだね」
「はい。新人の頃にJSPのコーディングをしていて、文字コードではまったことがあって…ちょっとトラウマになっています」

「なるほど。最初に苦手意識を持ってしまうとなかなか回復しづらいものかもしれないね。まぁ、ここにいればイヤでもその手の問い合わせに頻繁に触れるようになるから、徐々に苦手意識は薄れていくと思うよ。さて、話を戻すけれど、レスキュー・サービスの仕事は、基本的には何らかの問い合わせや調査依頼がトリガーとなって始まります。問い合わせは電話で来ることもあるし、メッセージング・ツールやメールで来ることもあるんだけど、今回は『メールで調査依頼が届いた』という設定にしよう。この資料にある通り、今回の依頼者は『メールの文字化け』について悩んでいる。まずはこの調査依頼に対応するためのプロセスについて考えてみようか。――突然だけど秋山さん、今から君がこの依頼を担当するとしたら、まず何から始めるかな？」

「えっ、私がこの依頼を担当するとしたら、ですか？ええと、そうですね…まずは文字化けについてWeb上の文献を調べたり、社内の資料をあたったり…」

「うーん、なるほど。何か問題を解決しようという時に情報収集は欠かせないし、秋山さんはさっき『文字化け問題は苦手』と言っていたから、実際に作業を開始する前に予備知識をつけておこうという気持ちも理解できるかな。ただ、効率を重視してトラブル・シューティングを行おうという時には、情報収集の方法やタイミングにもちょっと気を配った方がよいことが多い。

図1●トラブル･シューティングのプロセス

　今回のケースでいうと、今はまだ依頼のメールを読んだだけの段階だよね。この時点で「文字化け」という漠然としたキーワードだけを頼りに情報収集を行うのは、あまり効率の良いやり方ではない。どんな作業でもそうだけど、仕事を効率良く進めるためには着手から終了までのプロセスを明確にして、常にそれを意識しながら作業を進めるようにするといい。トラブル・シューティングを行う場合も同様だ。特に、このサンプル案件のように急ぎの調査を依頼された時などは、それなりに準備に時間をかけた方が結果として迅速に問題が解決できることが少なくない。トラブル・シューティングのプロセスには色々なパターンがあるけれど、このサンプル案件のようなケースに対応する場合にウチで一般的に用いられているのは、1. 問題を把握し、 2.仮説を立て、 3. 検証を行い、 4.解決に導く というシンプルな方法論だ」