2007年度FUJITSUファミリ会 秋季大会
開催日：2007年11月1日 開催地：リーガロイヤルホテル広島

次の事例は、「実際どんなアウトプットを出せるのか」。あるお客様のサービス部門をフィールドワークさせていただいたときの話です。お客様サービス部門というのはカウンターでお客様対応して、かつ後ろに戻ってデスクで電話対応も行う部門です。ここにシステムを提供している情報システム部門が、事前にシステムの使い勝手等をアンケートで現場の声を集めて仮説を既に作っていましたが、あくまでもアンケートベースなので事実の裏づけが欲しいということでした。また、アンケートで寄せられた不具合が、どう具合が悪いのかもっと知りたいというのもお客様のご希望でした。

期間は実質3日間です。大体500ページくらいフィールドノートができ上がって、これに基づいてデータセッションの場で整理していくと、この場合は700件ほど気づきの項目が出てきました。改善や問題点等です。そしてこれを最終的なフィールドワーク報告書ということでお客様に提出しております。本編、観察事象編、業務フロー編等々ございます。（図表8）

報告書の内容を見てみましょう。お客様は、大きな仮説としてシステム間の連携不足が一番まずい、具体的にどの辺の連携が悪いのか等々、もっと事実を知りたいということでした。これに対してフィールドワークの結果、報告書では例えば事実1として、注文処理に多くの機能を並行利用しているため、注文処理に多くのスクリーンを行ったり来たりして作業が大変だということを定性的に表しています。個別明細画面という機能があり、そこからリンクが張られると一番良いという要望があることが現場ベースで非常によくわかってきます。また、システム間の連携不足で電話対応中にあちこち画面を飛んでいるうちにお客様が電話を切ってしまうといった事実も明らかになってくるわけです。

この事実1にはインデックスをつけ、観察事象編に詳細を記述しています。お客様との電話対応を行いながらのスムーズな操作と言っていても、実際には作業者のテクニックで何とかスムーズになるようにこなしている、相当ご苦労されていることを延々と書いています。実際の行動も会話もそのまま記載しています。このように、報告書本編の一つの事象に対応して事実の詳細を観察事象編に飛べるようになっています。

このケースは仮説検証型で、お客様のたぶんここが問題だという仮説に対し、より具体的に課題を明らかにしていくことができます。また、フィールドノートに詳細に記述していますので、後で定量的に表を作成し、定量データをもとに課題解決効果を試算するということもできます。

また、実際に業務を見せていただき、ITだけではなくその前の業務も含めて業務フローを起こしていきます。システム間の連携、行ったり来たりしているところも表して、業務フローでもより明確に表すものができます。これらは全部フィールドノートから起こしています。フィールドノートは事実そのままですから、後で様々な形でのアウトプット加工が可能なのです。

システム間の連携に課題があるという仮説で、主にそこを見てほしいというのがお客様のご要望ですが、そこだけ見るというと他をこぼしてしまう可能性がありますから、実際にフィードバックするときにはあまりテーマは絞りません。この場合もいろいろな想定課題外の気づきが出てきました。この辺がビジネスフィードバックのもう一つの強みでもあります。IE的な手法ですと、テーマを決めて、例えば、ある伝票が各プロセスで何秒かかっているかストップウォッチで計るなど、決めたスコープの中だけやりますよね。それ以外は気づけません。ところがフィールドワークでは、例えばある同一項目を、いろいろなところで入力して多重管理している現場の大変さがわかってくるわけです。Excelで入れたり、システムで入れたり、果てはOutlookでデータを廻している人もいました。さらにホワイトボードでグループ間連絡ということで書き込んで、また別の専用Excelを作っている等々、こういった想定課題外の非常に煩雑な事務処理もわかってきます。

それから、ご参考にですが、最近はやりのトヨタTPSをホワイトカラーの生産性向上にどうやって応用していくかをやってみようということになりました。最初から意図していたわけではありませんが、詳細に記述していますので、こういった整理もできるのです。

ある方の電話応対の内訳を見ると、顧客に価値を与える正味作業は、注文のみ。あとは連絡、問い合わせ、伝言、転送等、顧客にダイレクトには価値を与えない非正味作業に多くを費やしている、そんなこともよく見えてきます。