WEBマガジン

「IT分野における行動観察の適用　～その２～」

2013.04.17 株式会社オージス総研　　鈴村　一美

１．はじめに

　前回の「IT分野における行動観察の適用　～その１～」では、行動観察の概要と一般的な事例を主に紹介してきました。そして、この行動観察手法がIT分野でどのように活用できるのかを、適用フェーズとともに、行動観察の実施イメージや適用のメリットを説明しました。
　今回は、IT分野への行動観察の適用が、IT関連業務の更なるビジネスチャンスの可能性を探るための参考となるよう、実事例を紹介するとともに事例以外の活用可能性について言及します。

２．IT分野での行動観察事例

　今回の行動観察事例は、「システム支援系サポートセンター（コールセンター）」におけるシステム改修に伴う業務要件定義フェーズでの適用事例です。
　業務要件定義は、システム新規開発時及びシステム改修時のどちらでも必要となります。但し、システム改修時は、実際に既存システムを活用して業務を行っているため、システムそのものの使い勝手に注目が集まりますが、行動観察では、使い勝手を含めて"人間を中心とした観点"から現場を分析します。
　その１で、行動観察のシステム開発への適用フェーズを示しましたが、改めて記載します。

図１　「行動観察のシステム開発への適用フェーズと今回事例の範囲」

2-1　行動観察の進め方

　行動観察では、通常、調査計画を立てたあと、実査の準備を経て行動観察（インタビュー含む）調査を実施します。その後、観察結果の内容を整理（ファインディングシートにまとめ）し、その事実内容を関係者で共有するとともに、ワークショップにてソリューションを提案します。
　今回の事例では、前述のステップに加えて、システム改修のための支援内容（機能要件〔案〕）の検討を行いました。

図２　「行動観察の実施ステップ」

2-2　観察のポイント

　通常の業務要件定義では、お客様の担当者から今現在認識している問題点や課題をヒアリングし、実態を確認しながら要件を固めていきますが、行動観察では、それに加えて、潜在的な課題をも抽出すべく、人の言動、コミュニケーションの状況などに注目して調査します。
　今回の事例では、観点ポイントを以下のように設定して観察しました。

通常時のコール受付からお客様の状況確認、ナレッジ検索、インシデント登録など業務の流れ
イレギュラー時の人的対応（管理担当への相談、エスカレーション先への事前告知など）等の業務の流れ
お客様の状況を正確かつスピーディに把握する、あるいはお客さまを安心させるための対応方法
システム利用時（登録、履歴検索、ナレッジ検索など）の操作実態（特にフリーフォーマットの入力状況）
システムを通じたコミュニケーション実態と運用面でのコミュニケーション実態
受付対応時以外の担当者の行動（他スタッフとのコミュニケーション状況など）

2-3　行動観察から得られた新たな発見

　行動観察実施のきっかけは、「ツールそのものの使い勝手が効率／品質に大きく影響するのではないか」、という点にありました。
　既存のツールは「使い勝手が悪い」と評判が悪いのですが、管理側としては、「本当に使い勝手が悪いのか、前のツールと比べているだけではないのか」、一方オペレータ側は、「なぜ現場のことをわかってくれないのか」というように、お互いに言い分はあるものの、だれも現状と本質を正確に把握できていませんでした。
　両者とも「ツールが悪い」とは思っていますが、何がどう悪く、どうしたら良いのかという整理はできていませんでした。なぜなら、具体的に良い点、悪い点を把握していませんでしたし、悪い点を無意識に人力でカバーしていて、本人も気づいていない軽微な問題だと思っているのでは、ということが想定されました。
　本人が意識していないもの（気付いていない、問題だとは思っていない）は、ヒアリングしても出てきません。行動観察の良いところは、「なぜそのような行動をするのか」を、実際の観察とインタビューの組み合わせで、明らかにできるところです。
　こうした中、行動観察の実施で様々な実態が明らかになりました。その内容を一部紹介します。

　◆オペレータの手書き作業

　オペレータは、顧客とのやり取りをノートに書きます。そこで疑問がわきます。なぜツールに直接入力しないのだろう？二度手間になるのに。しかし、このオペレータの行動には意味がありました。インタビューしてみると、ツールがしばしばフリーズするため、未保存の入力データが消えてしまうことがあり、そのため、ノートに書いていることがわかりました。
　これは、ツールの使い勝手の悪さをヒアリングした際には出てこない問題でした。オペレータにとっては「当たり前のこと」であり、意見として出しても意味が無いと諦めていたようです。
　ソリューションアイデアの「メモの自動保存機能」、これがツールの機能要件（案）の一つとなりますが、フリーのメモアプリが存在しているころから、実際に導入し使ってみました。その結果、手書きのメモの量が半分以下になり、結果として効率化が図れたことになります。

図３　「行動観察から得られた実態（1）」

　◆検索機能の利用実態と管理者の思惑が乖離

　検索には、システムに機能として搭載されているものと、FAQツールがあります。そのFAQツールは、便利だからよく使っているはず、と管理者は思っていましたが、実際に観察するとあまり利用されていません。その理由をインタビューで聞くと、見なくても答えられる情報が多い、知りたい情報がない、情報が古い、といったことから利用していない、また都度さまざまな資料を検索するので調べる時間が増えている、ということがわかりました。そのため、自分が備忘録として作成したエクセルデータから探すほうが早く情報をみつけることができる、という安心感からの行動でした。
　これは、利用者と管理者（ツールの提供側）の思惑が乖離している代表的な例です。そのため、情報が色々なところに散在しているのを１箇所に集中させること、すなわち単にシステム機能の追加だけでない提案も行いました。また、ナレッジ登録を行う時間をとって、皆が定期的に内容のメンテナンスを行う、といった運用上の提案も行いました。

図４　「行動観察から得られた実態（2）」

2-4　行動観察からの要件定義支援

　行動観察実施後の多くの気づきから、システム機能面だけでなくコミュニケーション面を含めた利用者ニーズを体系化し、そのニーズを実現するソリューションを提案しました。
　加えて、行動観察した範囲に限定されますが、本調査のシステム改修のための業務要件定義支援として機能要件（案）をとりまとめました。
　実際の要件定義書は、こうした行動観察から得られたファインディング、ソリューション案、そして機能要件案を、要件決定のためのインプット情報として活用しました。　

図５　「行動観察から得られた機能要件案」

2-5　行動観察実施の成果

　行動観察調査を実施することで、業務要件定義を行う管理者は、多くの気づきを得て、以下のような成果が得られました。
　まず1点目は、行動観察を実施することで事実に基づいた問題の本質が明確になり、そのため、現実的かつ具体的なディスカッションができました。これまでは抽象的なディスカッションばかりでしたが、そこから脱却することができました。
　次に、オペレータにとっては、「普段の私たちを見てもらい、それがベースとなった改善なので期待ができる！」と感じてもらうことができ、オペレータのモチベーションが上がり、改善のマンネリ化から脱却できました。
　そして、３点目が具体的な機能要件に関わる部分として、仮説に基づく改善ではなく、実際に存在し、悪影響を与えている問題に対する解決策を実施することで、大きな改善効果が期待できます。

　なお、行動観察実施後、管理者側が業務要件定義時に取りまとめた要件の機能数56個に対して、15個の機能が何らかの形で行動観察が関与した機能でした。
　その機能追加において、運用コスト^（※）がどの程度削減されるのかを想定すると、全体で575人日/年の削減効果があり、そのうち169人日/年　分が、行動観察調査が関与したという結果が得られました。

^{(※）機能追加の投資効果は、その機能があれば操作が何秒短縮できるか、その操作を月に何回行うかを想定し、削減工数を計算してオペレータの原価から運用コストを算出。}

３．更なるIT分野での適用可能性

　紹介した事例は、業務要件定義フェーズへの適用ですが、このフェーズ以外にも、設計、開発フェーズのプロジェクト運営や、実際にシステムが稼動した後の運用フェーズでの適用可能性が考えられます。

3-1　開発プロジェクト運営上の適用可能性

　プロジェクトの設計及び開発フェーズは、プロジェクトを運営するなかでも長期間にわたり、様々な問題が発生する可能性が高いフェーズです。
　プロジェクトを運営するにあたって、うまくいかない理由としては、目標がはっきりしないままなんとなく始める、見積（製品要求事項）が曖昧、責任・役割が不明確、といったことが挙げられますが、加えて、最も大きな問題点としては、お客様やプロジェクトメンバーとのコミュニケーション不足があります。
　目標や見積、責任の所在などの問題点は、PMが目的・目標・成功基準を明確にし、しっかりと計画をたてマネジメントしていくことで防ぐことができます。また、その方法もガイドラインなどに示し周知徹底することが可能です。しかしながら、コミュニケーションに関わる部分の対応は、そのプロジェクトが置かれている状況、そして対応する人によっても様々であり、ガイドライン等で具体的な対応方法を示すことは困難です。
　そこで、実際にプロジェクトを運営しているPMの行動を観察し、ベテランPMと新任PMなどの気づきから行動レベルのノウハウを抽出することで、行動ガイドなどをまとめて教育に活かすことが考えられます

3-2　システム運用上の適用可能性

　開発プロジェクトが完了し、システムが稼動と同時に運用フェーズが始まります。このフェーズは、基本的には規定やマニュアル・手順書などに従って日々の業務をこなしていくことになりますが、これら業務が適切に行われているかの運用状況評価そして業務改善は、単にドキュメント確認やヒアリングだけでは十分とはいえません。事例として採り上げたコールセンター観察も運用フェーズの一例ですが、システム改修の業務要件定義支援に焦点をあてたため、業務改善などのソリューションは十分とはいえませんが、それでも幾つかの提案は行えました。
　システム運用フェーズに行動観察を取り入れることで、例えば業務手順がルールに則っていない、あるいは人によって異なっている等は、単に現状を指摘してルールを遵守させよう、といった改善策を提示するだけでなく、手順そのものが実態に即してない、無駄な作業や負荷の高い作業になっているのではといった発見ができ、潜在的な課題抽出も可能になります。

４．おわりに

　IT分野における行動観察の適用について、２回にわたって言及してきましたが、実際に行動観察調査を実施しようとすると、事前にそのアウトプットや成果が出せるのかどうかを問われます。
　行動観察は、現場により、また同じ現場であっても関与する人々が異なれば、気づきは多岐にわたり、そこからどんなアウトプットが出てくるのかを明確に示せないなかで、お客様に納得していただく必要があります。
　そのために、まずは行動観察そのものをSEやコンサルタントに体験していただき、自分自身が理解を深めた上でお客様に提案していくことが重要と考えます。

*本Webマガジンの内容は執筆者個人の見解に基づいており、株式会社オージス総研およびさくら情報システム株式会社、株式会社宇部情報システムのいずれの見解を示すものでもありません。

『WEBマガジン』に関しては下記よりお気軽にお問い合わせください。

お問い合わせ

さらに見る

「IT分野における行動観察の適用　～その２～」

１．はじめに