【社内システムMover強化プロジェクト】アイデアをカタチに。　～要件定義編～

　シェアリングテクノロジーでは、暮らしのお困りごとをスピーディーに解決するための社内システム”Mover”を自社で開発しています。
（参照ストーリー：「お客様・業者様・社内ユーザーの「三方よし」を叶える社内システムMoverとは？！」）

　お客様情報から、業者様情報、案件の一覧等、様々な情報を管理する機能を内包しており、主に、お客様や業者様と直接やり取りをすることの多い、コールセンタースタッフがメインで使用するシステムです。
　シェアリングテクノロジーの開発チームでは、日々、この社内システム”Mover”の開発を行っています。
（参照動画：「”Mover”とは」）

　今回は、その”Mover”のユーザーインターフェース（以下UI）を大きく変更した、「Mover強化プロジェクト」のご紹介をすべく、プロジェクトリーダーを務めた、IT関連のユーザーサポート部門を担う社内IT課（当時）の稲垣さんより、プロジェクトの背景や部署との連携、要件定義の進め方等について、お話を伺いました。

Mover強化プロジェクトの背景

目的は「工数削減」＆「UX改善」！

ーまずは「Mover強化プロジェクト」が行われた背景を教えていただけますか？

　本プロジェクトの対象である、”Mover”というシステムは、5,000以上の業者様の情報を管理し、150以上あるジャンルについて毎日約2,000件以上もの案件を取り扱っています。
　コールセンタースタッフが案件登録や情報確認の度に使用するシステムなので、そのシステムの運用実態に基づいた大規模かつ大胆な改修を行うことで、運用現場であるコールセンターの負担軽減と効率・品質向上をもたらすUX改善が本プロジェクトの目的でした。

複数部署から集ったメンバー

ーなるほど。では、プロジェクトはどのようなメンバー構成で行われたのでしょうか？

　実施効果を最大化するために、メインユーザーであるコールセンター部門、実際に開発を行うシステム開発部門からそれぞれアサインされた担当者と、要件定義を行う僕とで、プロジェクトチームを結成し、協議を重ねつつ開発を進めました。なぜコールセンタースタッフでも開発メンバーでもない管理部社内IT課に所属する僕がアサインされたかは後ほど、ご説明しますね。

稲垣さん流！要件定義の進め方

ファシリテーター的役割？！

ーでは、本プロジェクトにおいて稲垣さんはどのような役割を担われたのですか？

　これまで、システム開発チームと、ユーザーであるコールセンターでは、同じ会社とはいえ部署として離れていて、お互いの業務も分かりづらいという問題点がありました。要望の詳細な背景や意図が明確に伝わらず、狙いと外れたものができてしまったり、逆にユーザーであるコールセンタースタッフは、システム開発について全く知識がないので、要望するものが技術的・リソース的な限界を超えている、いわゆる「無茶な要望」を開発側にお願いしてしまうこともありました。

　僕は、前職で業務システムの企画・開発に携わっており、システム開発のこともだいたいわかりますが、コールセンターを10年ほどやっていたこともある珍しい経歴なんです（笑）なので、コールセンターの業務フローや気持ちなどもよくわかるので、開発側とユーザー側、それぞれの事情・内情を知る僕が、コミュニケーション不足、情報不足になりがちな両者の橋渡しをすべく、中立的ポジションで要件定義を行ったわけです。

　例えば、開発の観点からすると、ソフトや技術上の制約や工数などリソースの問題などがあり、100％ユーザーの要望やニーズに応えられないこともあります。そんな時、「ではどこを削ったらできるか」等、システム開発側ではわからない優先度のところを確認し、「この機能は今度入れるとしてまずはこっちの機能を開発してもらいましょう」とか「要望したこの動きは優先度として低いから、いったん保留にしましょう」などの調整を行ったり、折衷案を両者に提示し、着地点を模索しました。そういう意味では、要件定義というより、ファシリテーター的意味合いも大きかったですね。

プロトタイプでイメージのズレを防止！

ー本プロジェクトで今までとは変わった試みなどはありましたか？

　本プロジェクトでは、開発初期段階で、「高精度なグラフィック」プラス「操作時の画面変化やページ移動などのアクション要素」を組み合わせた仮想Mover開発（プロトタイプ）を構築・活用することで、コールセンターと開発チーム間での認識のズレ…いわゆる「思っていた動作と違う」、「希望がかなっていない」など、注文開発で起こりがちなトラブルを未然に防ぐ、という試みを行いました。

　今までの開発では、ユーザーから「こういう機能を追加して欲しい」といった要望のみだったのですが、今回はUI、つまり画面構成変更のプロジェクトだったので、よりユーザーの要望に沿えるよう、「画面のどこにいれるか」や「どういった挙動をしてほしい」などが具体的かつ視覚的にわかるように、ざっくりとしたアイデアである、プロトタイプ（試作版）を複数用意し、ヒアリングを行うことでさらにニーズを明確にしていきました。

　ツールとしては、「Figma（フィグマ）」というWebデザインツールを使用して、UIデザインやワイヤーフレームワークなど、実際のインターフェースとほぼ同じデザインや挙動を確認し、徐々にアイデアをブラッシュアップし、問題点を解決できるよう、精度を上げていきました。ちょうど、カメラでどんどん対象物をフォーカスしていくような感覚ですね。

　そうして、プロトタイプが完成し、どういう見た目でどういう挙動をさせて欲しいかといった、具体的で明確な要件を確定させてから、開発チームへ依頼しました。そして、その中で手戻りを防ぐべく、仕様や所感を細かくすり合わせるというのが今回の僕の要件定義のやり方です。

要件定義の内容

ーでは最終的な要件定義の内容を教えていただけますでしょうか？

　繰り返しになりますが、今回のプロジェクトは、コールセンターにおける「受付業務の工数削減」及び「UX改善」を目的としました。

　その目的を達成するために、①受付画面のレイアウト刷新　②ヒアリングテンプレートの構造変更の2軸で開発を行いました。

　「受付画面のレイアウト刷新」については、従来すべての情報を縦長に配置してスクロール表示していましたが、新Moverでは左右中央の3フレーム構造に改め、一部項目を固定表示としました。これにより、Moverの操作性、また各種情報へのアクセス性を向上させました。

　「ヒアリングテンプレートの構造変更」については、フリー記入式から項目選択式へ抜本的な構造変更を行いました。フリー記入式では、どうしても確認漏れや記載のばらつきがありましたが、項目選択式にすることでヒアリング内容を統一させ、入力する手間も大幅に省く事が可能になりました。また、留意事項を併載できるスペースを設けており、応対面では品質向上、標準化、教育面では研修期間の圧縮が見込まれます。

立場の違うメンバーとのブレインストーミングでシステムの質向上へ

ー今回のプロジェクトを振り返られてどのようにお考えですか？

　まず、今回のUI変更により、その目的である「工数削減」＆「UX改善」は達成出来たと思います。

　というのも、まだ数値として出せてはいませんが、現場の方から「わかりやすくなった」、「使いやすくなった」という声を聞きますし、フリースペースではなく、各項目に沿ってヒアリングしその内容を記録することになったことで覚えることも減り、実際に教育工数も減っています。また、事前にサンプルでユーザーの方々に確認し、それを実装できたので、より希望に沿った操作性の高いUIを実現でき、効率・品質向上をもたらすUX改善が行えました。

　また、もう一つの大きな成果としては、部署間の垣根を超え、立場の違うメンバーとのブレインストーミングによって、システムの質の向上を可能にするという考えが根付き始めたことでしょう。

　つまり、本プロジェクトでは、先程お伝えしたような立場、分野の違うメンバー…開発を行うシステム開発スタッフと、お客様と直接やり取りしシステムを使うコールセンタースタッフと、その両方のポジションのニーズがわかり、そのニーズのすり合わせが可能である中立的ポジションの僕という、多様なメンバーで行われ、意見やアイデアを出し合い、議論を重ね、新しいシステムを開発しました。
　このプロジェクト以降、それぞれの部署のメンバーが集まって、意見を出し合い、立場の違う者同士でブレインストーミングを一緒に行うという機会が増えてきています。
　そうした、立場の違う、みんなのアイデアをカタチにできることこそが社内システム開発の面白さですし、他の部署・立場の人の目線が入ることで、よりシステムの質の向上が可能になり、ひいては会社全体の成長につながっていくのではないでしょうか。

ー最後に、Wantedlyをご覧の方向けに、どんな方に当社がおすすめか教えてください！

　本プロジェクトのみならず、当社のシステム開発では、そうした、意見を汲むスキル、いわゆる傾聴力や問題解決力、提案力などが磨かれるお仕事なので、これから要件定義のスキルも身につけていきたい、もしくはそうしたスキルを活かしたい、伸ばしたいという方にはぴったりの環境だと思いますよ。

ーー稲垣さん、貴重なお話ありがとうございました！
　　
少しでも気になった方はぜひ、当社ホームページをチェックしてみてください♪