開発したシステムの利用者に弟子入りしてみました。 - Cybozu Inside Out

こんにちは。Sales System チームの小林俊久です。最近、少しお腹が出てきました。

Sales System チームでは、お客様がサイボウズのクラウド製品をお試し運用したり、購入や管理するためのサイトcybozu.com Storeや、サイボウズの全売上を管理している販売管理システム等を開発しています。

今回は、Sales System チームで行った 「弟子入り」 についてご紹介したいと思います。

その要望、真の要望？

開発者のみなさんは、実装したシステムをリリースして利用者からの反応がイマイチだったことはありませんか？または、しばらく経つと使われなくなったことなどありませんか？

私たち開発者は、要望をもとに設計書を作成し、システムを実装します。要望を満たすために必要な画面や入力項目を用意してめでたく完成。何も文句はないはずです。

にもかかわらず、前述のようなことが起こります。なぜでしょう？利用者でないと分からない悩みや問題があるのでしょうか？

きっかけ

販売管理システムは、サイボウズ社内のセールスデスク部、マーケティング部、営業部など多くの社員が利用しています。しかし、私たち開発の人間が利用する機会はあまりありません。利用していないのでどのように使われているかイメージすることが難しく、要望として上がってきた要件が何故必要なのか、どういう状況で、どうやって使われるのかがわからないという問題がありました。チーム内で問題解決に向けて議論した結果、でてきた案の1つ 「弟子入り」 を実践してみることになりました。

弟子入りとは

販売管理システムの メイン利用者を「師匠」 として弟子入りし、業務体験を通じて利用者の言葉にならない真の要望を探るという手法です。この手法は、サイボウズ社内で行っているデザイナーワークショップに講師としてお招きした樽本氏から教わりました。デザイナーワークショップはサイボウズ社員に限らず、内容に興味のある方は自由に参加いただいています。

弟子入り準備

弟子入りするにあたって、以下の目標を設定しました。

業務体験を通して業務知識を高める
問題点や改善できそうな箇所がないか発見する
利用者と仲良くなる

「業務知識を高める」は、問題と感じていた点なので問答無用に目標です。

つぎに、体験を通して操作につまづいたり、入力しずらいと感じる部分があるかもしれません。既に業務に慣れている人にとっては あたり前 となって要望にも挙がって来なかったりするものです。その点、弟子である私は新人も同然です。その視点から「問題点がないか発見する」ことも目標としました。

さいごに、「利用者と仲良くなる」です。開発部が他部署と仕事以外でコミュニケーションを取る機会は少なく、同じ会社の人間であっても関係が希薄になりがちです。今回の弟子入りを機にお互いのひととなりを分かり合うことで今後の要望や意見交換等がやり易くなるのではと考えました。他部署との交流を考えた施策は、ほかにも社内部活動や誕生会「社内コミュニケーション活性化のための施策」を参照等もあります。今回はその一環として目標に設定しました。

ちなみに私はボードゲーム部の部長をしています。カタン、カルカソンヌ、トーレスやドミニオンなど、海外アナログゲームをメインに活動しています。他社交流戦などご希望する方がいらっしゃいましたらご連絡お待ちしております。精鋭がそろってますよ！

目標を建てたところで、利用部門に相談です。相談先は利用頻度が一番高いセールスデスク部にしました。セールスデスクは受注/請求/代金回収業務を行う部署で、販売管理システムは必要不可欠です。

こちらのやりたいこと(目標)
受け入れ時期調整
弟子入りカリキュラムの作成依頼

などなど。他には業務に必要な権限付与の承認を上長に申請しています。お互いスケジュールの都合もあり、業務体験と業務観察をそれぞれ 1 日、合計 2 日間の弟子入りとなりました。

弟子入り

1 日目の業務体験では、セールスデスクマスターとも言うべき方に 「師匠」 になって頂き、手取り足取り教えてもらいながら、日常的に行っている以下の業務を体験しました。

受注入力（主にFAXでくる発注書を販売管理システムへ入力）
受注から納品までの手続き処理
入金確認処理
未払い処理

体験中は、どうして付箋を貼るの？どうしてこんなに確認する画面が多いの？など師匠に質問責めです。

2 日目の業務観察では、師匠の後ろに張り付き、日常業務を行ってもらいました。その過程で、作業中に心の中で喋っていることを口に出してもらいながら、なぜ今そう思ったのか？なぜその入力順なのか？など、気になった部分を逐一質問して師匠の今の行動が何に起因しているのかメモを取っていきました。

以上、短い期間でしたが見つけた問題点や改善点は全部で 16 件 ありました。簡単なものから開発業務としてプロジェクトに組み入れる必要があるものまで大小様々です。最初の弟子入りとしては上出来ではないでしょうか。

f:id:cybozuinsideout:20160802094858p:plain

見つけた問題

特に印象に残った問題を紹介します。

受注入力にも何種類かあり、インターネットにある注文画面からの入力もあれば、CSV一括インポートによる取込みや、FAX での受注もあります。その中の FAX による発注書を販売管理システムへ入力する業務を行っていた時です。発注入力はよくある入力画面です。開発時は発注情報を入力するんだなぁ程度にしか考えていませんでした。発注書を見ながら入力するのですが、何と 発注書のフォーマットがいくつもある のです！私は混乱しました。

私　「発注書は 1 種類じゃないのですか？」

師匠　「パートナー契約を結んでる会社毎に発注書は異なります」

私は今までサイボウズが用意した発注書で注文が来るものだと誤解していました。発注書は各社各様、フォーマットが全然違います。しかも 1 社で 1 つのフォーマットとは限らず、合わせると数十種類あります。初見では発注書のどの項目をどこに入力したらいいのか全然わかりません。

しかし、そこは師匠。各社の発注書毎にどの項目をどこに入力したらいいのか Wiki にまとめていました。師匠に感謝しながら Wiki と発注書と入力画面を見比べながら黙々と入力・・・

Wiki から該当発注書を検索
検索した発注書マニュアルを参照して、入力画面の項目との紐づけを確認
発注書の該当項目を入力画面の適切な項目に入力

うーん。非効率です。Wiki をチェックするのが非常に面倒ですが、暗記していない限りは必要です。さらに暗記したとしても覚え違いや勘違いもあるでしょう。しかし、現場ではこれが あたり前 になっているのか、不便だの改善要望などが開発部にあがってくることはなかったのです。

改善

「発注書毎に入力画面のどこに何を入力したらいいか、入力画面の項目の背景色を変えたり、案内があったら楽なのになぁ」

と感じましたが、これを保守性や汎用性を考慮ながらシステム化するとなるとコストがかかるだろう事は目に見えてます。とはいっても、入力の不便さは 身をもって体験 しているので何とかしたいところですが・・・やりたいことは受注入力画面の入力補助です。要件を分解すると

入力箇所を目立たせる
何を入力したらいいか案内する

ふむふむ。見た目の操作だけなので、割り切ってブラウザの拡張機能で実装しよう！

販売管理システムとは独立した実装にすれば、保守性や汎用性は考えずに済みます。さらに、プロジェクトではないので品質管理部のチェックや、システムリリース時期の調整も必要ありません。

合間の時間を使ってさっそく作ってみました。実装は単純で、発注書毎に受注入力画面内の必要な項目の HTML 要素をもってきて、背景色を変えてプレースホルダーに案内を書くだけです。簡単だったので調子にのってオプション機能を追加して、背景色に好きな色を選択できるようにしました。実装にかかった時間は都合 2 日程度といったところでしょうか。次は案内文も編集できるようにしてもいいかもしれません。

効果

早速、セールスデスク部のブラウザを機能拡張してみました。直後の反応がこちらです。

f:id:cybozuinsideout:20160802094859p:plain

機能拡張後、しばらくして効果をインタビューしてみました。

「1 件あたり 30 秒前後短縮した(多い日は 100 件超える受注がある)。短縮もいいけど、なにより 精神的に楽になった のが大きい。今まではマニュアル(Wiki)見ながら本当にこれでいいよねって確認しながら入力していたが、注文書ごとに入力項目や確認項目が色付けされて分かるようになったので、自信をもって登録＆確認できるようになった！」とのこと。

後日、報酬としてドリップ式のインスタントコーヒーを頂きました(＾_＾)

まとめ

「エンジニアはもっと利用者の立場に立った目線を持とう！」 いま自分が思っている以上にです。私も設計時は利用者を意識していたつもりでしたが、弟子入り体験を通してそれは上辺に過ぎないのだなと痛感しました。利用者の声だけでなく、その声があがるに至った 過程を探求する ことで気づかなかった問題(真の要望？)が見えてきました。