読者です 読者をやめる 読者になる 読者になる

お客さまの声なき声に耳を傾けよう ~弥生流ヒートマップツール「Ptengine」の活用方法~

こんにちは。 弥生のウシオです。

今回は、先日のブログの最後に申し上げた、弥生で実践している面白いヒートマップツールの活用方法についてご紹介したいと思います。


ヒートマップツールのポピュラーな活用方法

先日のブログでもご紹介した通り、ヒートマップツールとはサイト内でのユーザー行動を可視化するためのツールです。

よって、Google Analytics などと組み合わせて 「本番環境」における「お客さま」の行動分析を行い、サイト改善に役立てるのが最も一般的でポピュラーな活用方法です。

弊社でも同様の目的でヒートマップツールを導入したのですが…

「これ、テストの分析にも使えそうだよね」 (by 田中

「??」

このときはまだ、神の啓示の意味を理解できていませんでした。

ああ、愚鈍なる民よ。


ソフトウェアテストの現状と課題

製品/サービスを開発する際、各フェーズにて必ずテストを行い、品質の担保を行うと思います。

テストすべき内容をテストスクリプト化して、その妥当性ついて修正都度レビューを行うなど、漏れや偏りが起こらないように日々努力されているかと思いますが、

「テストスクリプトが膨大になりすぎて、漏れや偏りがレビューで検出できなかった。。」

「コードの修正内容が限定的であったため、関連するテストケースのみを抽出して実施したが、漏れがあった。。。」

「オフショア開発を行っていたが、納品日に品質がボロボロのソフトウェアが届いた。。。。」


など、ご経験がある方もいらっしゃるのではないでしょうか。

弥生では、品質を最も重要なファクターの1つと位置づけておりますが、極々稀に*1このような状況が発生してしまうことがあります。

発生した場合は当然、再発防止のための策を練るのですが、今までの延長線上の策では飛躍的な改善はなかなか望めません。

何か新しい視点でのチェック方法がないものか…

!!!

f:id:yayoi_ushio:20170419125213j:plain


ソフトウェアテストのチェックツールとしての活用

前にも述べた通り、ヒートマップツールはサイト上でのユーザー行動を可視化することができます。

これは本番環境に限った話ではなく、例えば結合テスト環境や統合テスト環境、はたまた社外の開発・テスト環境にも適用できる話なので、

  • 実施したテストに偏りや漏れがないか

  • テストの実施状況はどうか(そもそも、ホントにちゃんとテストしてるの?

などを、ヒートマップツールで視覚的にチェックすることができちゃうんです!

これはホントにスゴイ!!


実際に活用してみた結果

では、実際にテスト状況を可視化してみて、どうだったのか見ていきましょう。

さてさて、結果は如何に!!

f:id:yayoi_ushio:20170417125513p:plain

f:id:yayoi_ushio:20170417125523p:plain

あ!!

f:id:yayoi_ushio:20170417125533p:plain

通知機能が全然テストされてない!!


「伝えなきゃ・・・みんな騙されてる!!」


使ってよかったヒートマップツール「Ptengine」

前述の画面は今回新設したものなのですが、「ヘッダーは共通部分なのでテスト不要!!」という誤解を生んでしまったようです。

通知機能のテストを改めて行ったところ、見事にバグが1件見つかりました。。

いや、リリース前に気付けて本当に良かった!!


2回に分けて、ヒートマップツールの活用方法やノウハウについて、ご紹介させて頂きました。

他にも弥生では、サービス運用などの場面で様々なツールの活用を行っております。
それらについては、またまとまり次第、順次ブログでご紹介させて頂ければと思っております。

次回ブログ更新をお楽しみに!!

*1:一応、フォントを大きくしておきました。念のため。

お客さまの声なき声に耳を傾けよう ~ヒートマップツール「Ptengine」の導入によって見えてきたこと~

こんにちは。 弥生のウシオです。

今回は、弊社Webサービスにヒートマップツールを導入したことによって、見えてきたことやノウハウなどをご紹介したいと思います。


ヒートマップツールとは

ヒートマップツールとは、サイト内でのユーザー行動を可視化するためのツールです。

これによって、Webサイトのどこがよくクリックされているのか、どこまでスクロールされて読まれているのか等を、視覚的に知ることができます。

例えば、クリック情報を視覚化すると以下のようになります。
(赤い個所がよくクリックされている場所)

f:id:yayoi_ushio:20170316123648p:plain


ヒートマップツールを導入したきっかけ

弊社はインハウスでコールセンターを運営しているため、お客さまのご意見ご要望を収集しやすい環境にあります。

ただ、お客さまの仰ることをそのまま実現していたのでは、魅力的なサービスを作ることはできません。
お客さまの声に耳を傾け、その先にある本当のニーズを分析する必要があります。

そのために、弊社ではGoogle Analyticsを導入するなど、お客さまの行動分析を行う取り組みを実施しておりました。

Google Analyticsは大変便利なツールで、問題を抱えているページの特定などに大いに役立ちますが、該当ページのどこに問題があるのかを知ることはできません。

はてさて困った…

そこでヒートマップツールの登場となった訳です。(パチパチパチ)


ヒートマップツールで可視化したかったこと

とはいえ、いきなりすべてのサービスに導入するのは難しいため、ちょうど同じタイミングでリニューアルを予定していたYAYOI SMART CONNECTという弊社のサービスに導入して、効果を測定することにいたしました。

YAYOI SMART CONNECTは、

  1. 銀行明細やクレジットカードなどの「取引データ」の取込み
  2. 「取引データ」から「会計データ」への自動仕訳
  3. 弥生のデスクトップ製品やオンラインサービスへの「会計データ」の登録

をシームレスに行うためのサービスです。

YAYOI SMART CONNECT

今回のヒートマップ導入では、

  • 取引データの絞込みを行う際の切り口
  • 取引データの登録を行う際のプロセス

などといった観点で、サービス設計時に考えていた利用方法と、実際のお客さまの利用方法にギャップがないかを検証することを目的の1つといたしました。

また、解像度が1366x768であるお客さまが最も多いことがGoogle Analyticsによって判明していたので、サイドメニューの折りたたみや横スクロールの実際の活用状況についても注目しておりました。


ヒートマップツールによって問題は発見できたのか

では、実際にYAYOI SMART CONNECTをヒートマップで可視化した結果を見て頂きましょう。

※ 表示されているデータは、テストデータです。 f:id:yayoi_ushio:20170324161853p:plain

f:id:yayoi_ushio:20170316123733p:plain

  • ヘッダー

    1. [やよいの青色申告オンライン]というサービス名がクリックされている(オンラインの画面に遷移しようとしている?)
    2. パスワード変更インフォメーションバーの閉じるアイコンがクリックされている(当画面からパスワードを変更する人は極少数である)
  • サイドメニュー

    1. [スマートメニュー]がクリックされている(サイドメニューを折りたたもうとしている?)
    2. サイドメニューの折りたたみを頻繁に行っている
    3. 設定メニュー以外は比較的まんべんなくクリックされている
    4. 設定メニューは一部を除き、ほとんどクリックされていない
  • コンテンツ

    1. 絞り込みボタンの活用率は少し低めである
    2. 取込み元の種別(タブ)を切り口として、取引データの絞り込みを行っているケースが多い
    3. 摘要欄がしばしばクリックされている(コピペしようとしている?それとも編集しようとしている?)
    4. [取引の登録]列では「する」をクリックされることが圧倒的に多い
    5. 横スクロールを頻繁に行っている

ヒートマップツール導入以前からある程度想定していたもの、全く想定していなかったものなど、様々な気付きがありました。

主観的な思いこみではなく、このような客観的なデータから仮説を立て
改善し、再度取得したデータから仮説の妥当性を検証、そして更なる改善を重ねていく。

こういった改善サイクルを短いスパンでまわしていくことによって
お客さまにとって本当に使い勝手のよいサービスを今後も提供していきたいと考えております。


ここまでご紹介してきたのは、ヒートマップツールとしては王道的な使い方でしたが
実は弥生では、ヒートマップツールベンダーでも想定していなかったような、面白い使い方もしております。

近々ブログでご紹介させて頂きますので、お楽しみに!!

はじめてのフロントエンド開発で学んだこと


はじめまして。エンジニアのM.Fです。

1.自己紹介

私は今期弥生に中途で入社したばかりの新人で、フロント開発の経験はゼロ。前職ではいわゆるコボラー(※1)をやっておりました。

そんな正真正銘フロント初心者の私ですが、この取り組みを通じて非常に多くの知識と経験を学ぶことができたので、取り組みをご紹介したいと思います。

(※1)コボラー:COBOL言語の開発を行う人を指す言葉。

2.フェーズ2のゴール

フェーズ1(※2)では、基本的なマークアップスキルの習得として、HTML5,CSS3を活用したレスポンシブデザインの作成を行いました。 フェーズ2ではその応用として、実際に利用できるWebアプリ画面の作成をゴールとしています。

(※2)フェーズ1の詳細は「フロントエンドエンジニア育成(序章)」をご覧ください。

私のチームでは、現状メールで運用されている社内の勤怠連絡を、「Webアプリ上で一元的に管理・参照できるようにすること」を最終的なゴールとし、今回の取り組みではその一画面の作成を行うことにしました。

3.アプリのターゲットとベネフィット

そもそも、なぜこのアプリを作ろうと思ったのか? きっかけは私の上司のこの言葉でした。

「勤怠連絡と管理をもっと楽したいよね。」

開発本部では、

メンバーの

  • 休暇
  • 当日の早退・遅刻

の状況が把握できるように、毎朝メールで部内に配信されています。

この一覧はすべて特定の担当者が個々のメール連絡を受けて作成します。

当然毎日のことなので作業に掛かる負荷も高く、担当者が不在の時は代行で誰かがやらねばなりません。

特にリーダーにとって、メンバーの勤怠状況は常に把握しておきたいもの。

そこで、フロント開発の勉強も兼ねて、作成してみよう!というわけです。

ただ、思い付きで作るだけではダメで、そのアプリを開発することで、

「誰にとって(ターゲット・セグメント)」
「どんな利点(ベネフィット)をもたらすか」

という視点で分析を行い、「カスタマージャーニーマップ」を作成しました。

f:id:ochoco0108:20170321182410p:plain

このマップでは、想定されるユーザー(ターゲット・セグメント)がこのアプリを通じて行う行動や思考・感情などをフェーズごとにプロットしたもので、どのようにこのアプリを知り、触れて、継続して使ってもらうかというシナリオを立てています。

4.つまずいたこと

カスタマージャーニーマップも作ったし、早速画面のイメージを作ろう!となるわけです。 作成した画面カンプはこちら。

f:id:ochoco0108:20170323214038p:plain

この画面は、当日の出勤状況を確認するための画面です。

  • 当日の日付
  • 表示したいチームや人を絞り込むための検索フィールド
  • 勤怠の明細一覧

という構成になっています。

あとは作成したカンプの通り画面を作るだけ!・・・なのですが、初のフロントエンド開発ということもありなかなか思い通りにいきません。
特に、勤怠連絡を表示する明細のコンテナ部分には非常に苦労しました。 下記につまづいた点の一部をご紹介。

・IEで表示するとスペースが詰まる!

htmlでアイコンや文字の間に少し広めのスペースを入れたい。でも半角スペースだと記述が長くなってしまう・・・ そう考えた私はhtmlに"&emsp"を記述することにしました。しかし、それが裏目に。 IEで表示すると、なんと!スペースが全て詰まってしまいました。

とはいえ、"&nbsp"を何回も繰り返すのもイヤだし・・・結果、下記のように記述。

f:id:ochoco0108:20170321184741p:plain

こうすればIEでも空白が反映されるし、何回もhtmlに"&nbsp"を繰り返す必要もありません。

・サブメニューが画面の裏に隠れる!

今回、アイコンやボタンはgoogle社が提供するMaterial Design Liteを使用。 見た目や操作時の動きをマテリアルデザインで形成しており、HTML、CSS,JavaScriptにコードをコピーするだけで簡単に作れるので便利ですが・・・

f:id:ochoco0108:20170321184030p:plain

実装してみると、クリックできない(というか見えない)問題が発生。

早速F12キーを押して、ブラウザ開発者ツールで原因を特定します(使い方教えてもらいました)。
怪しいと思われるコンテナをクリックして指定を確認。

f:id:ochoco0108:20170323213606p:plain

すると、cssに記述していないoverflow:hidden;が指定されていました。 Material Design Liteのコンポーネントを使用したため、cssに記述しなくてもデフォルトで指定されてしまうようです。

そこで、style.cssに以下の通り記述。

f:id:ochoco0108:20170321184224p:plain

!importantルールを使うと適用するスタイルを優先させることができるため、 overflow:visible;が適用され、無事表示することができました。

f:id:ochoco0108:20170321184331p:plain

最終的に完成したhtmlはこちら

5.取り組みから学んだこと

本フェーズでは画面の枠組み作成をゴールとしたため、表示される明細の表示方法や内容の処理ロジックをどうするか?DBの管理はどうするか?等課題は山積みですが、ひとまずはhtmlとcssを使ってカンプのレイアウト通りに画面を作ることができました。 また、スケジュールも予定通り、4日間の業務時間外でなんとか作り終えることができました。

フェーズ1では調べものにかなりの時間を費やしていましたが、本フェーズではブラウザ開発者ツールを活用する、ペアプロで調べものを分担するなどを意識することで、作業を効率化できました。

簡単な画面ではありますが、この取り組みを通じてフロントエンド開発の土台となる基礎スキルを習得できたと感じています。 勤怠管理アプリの完成に向けて、引き続きトライしてゆきます。