【レポート】知らなきゃ怖い?モバイルアプリ運用の課題と解決ヒント

【レポート】知らなきゃ怖い?モバイルアプリ運用の課題と解決ヒント

Clock Icon2017.06.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

170609_repro_960x400

はじめに

こんにちは。kobayashiです。6月9日にクラスメソッド岩本町オフィスでビジネスセミナー「売上&集客力アップに繋がるモバイルアプリの鉄則とは〜企画・開発・運用の成功事例をご紹介〜」を開催しました。本記事ではその中のセッション「知らなきゃ怖い?モバイルアプリ運用の課題と解決ヒント」のレポートをお届けします。

イベント概要

これから新規アプリ開発を考えている、すでに運営しているアプリをもっと活用したい、アプリをグロースハックしていきたいと考えているEC、小売、飲食業界の企業様を対象としたイベントです。多数のモバイルアプリ開発実績をもつクラスメソッドと、多彩な手法でアプリの成長を支援しているReproとの共催で行われます。EC分野や小売・外食業界での事例とともに、皆さまの「次の一手」に繋がるようなアプリのノウハウをご提供します。

イベントHPはこちら

 レポート

セッション内容

モバイルアプリの運用は、リリースやリプレイスを終えたその瞬間から始まります。アプリのリリース前後にどのような運用課題があるのか、また、その課題をどのように準備して解決していけば良いのか、事例を踏まえてポイントをご紹介します。

スライド

トピックス

運用支援

  • 運用支援範囲
    • カスタマーサポート
      • 体制構築
      • 定型返答文作成
      • 問い合わせ調査
      • アプリガイダンス
      • 対応レポート
    • コンテンツ
      • 運用フロー設計
      • コンテンツ加工
      • コンテンツ登録代行
      • FAQ/お知らせ文作成
  • 本パートでお話しする運用支援経験
    • アプリの新規リリース
      • 既存ブランドは運用中
      • 新ブランドのアプリリリース
    • 既存アプリのベンダー乗り換えリプレイス
      • 既存ベンダーからクラスメソッドへの変更
      • ポイントシステムの大規模な引き継ぎが必要

本パートの狙い

  • モバイルアプリリリース前後の運用リスクを知る
  • 具体的な事例から、運用改善ヒントを知る
  • 自社の運用の課題解決のヒントにする

モバイルアプリの運用課題

  • モバイルアプリリリース前後に起きる頭の痛い出来事
    • リリース前
      • アプリのリジェクト
      • 掲載コンテンツの納品遅延
      • リリース直前の修正
      • 他部署への共有漏れ
      • etc
    • リリース後
      • バグ
      • エンドユーザーから大量の問い合わせ
      • 不慣れなコンテンツ登録によるミス
      • 細かい表記ミスの修正
      • etc
  • なぜこういったことが起きるか
    • 想定できないことは準備ができない
      • 運用に限らず、これまでの経験が生かせたとしてもリリースは初体験の連続
    •  運用でカバー
      • 予算や時間の関係で開発ができない場合運用でカバーすることがある
      • どうしても業務が多岐に渡ったり、やるべきことが増える傾向にある
    • 動き出せるのはアプリが大体出来てから
      • マニュアル作りもコンテンツの登録も、アプリが大体出来てから始められる
      • リリース前後に業務が集中することが多い
      • 短期間で臨機応変に準備を進める必要がある
  • これらを回避するのは、予算や納期やスケジュールの面で簡単ではないが、負担を軽くすることはできる
  • 運用支援の中で起きたことからできるだけ負担を軽くするポイントをご紹介
    • やってよかったこと
    • あまり効果がなかったこと
    • やっておけばよかったこと

モバイルアプリリリース前後の運用事例

  • やってよかったこと
    • チャットによるコミュニケーション手段の準備
      • コミュニケーションは主にチャット(backlog,メール,電話も使用)
      • slackを使用
      • 電話や会議よりも相手の時間を取らず気軽なので忙しい時期に適している
        • 例えばビジネスメール作成時の枕詞がいらないなど
      • チャットコミュニケーションで意思決定を早くできる
    • 定型返答文の作成
      • カスタマーサポート部門への説明が必要な場合
      • 返答の方針は先に決めておく
        • ここを丁寧にやらないと、全ての問い合わせの質問が一旦自分を経由することになる
        • カスタマーサポート部門で返答の判断ができるものが増えるようにして行く
        • 対応内容やり方を教えて自分の持つ仕事を減らす
    • アプリの仕様説明資料作成
      • オペレーターへのレクチャー用に当初作成
      • 内容
        • アプリの機能説明
        • 仕様上の注意点
        • 前アプリからの変更点
        • 新規追記した機能
        • 予想される問い合わせ内容ごとの対応方法
      • 後にオペレーターの人員を増やす時や他部署への説明にも使用
      • 何度も使うものは作り込み、使い回す
    • 誰でも編集できるデータベースを作る
      • リリースし終わってからは、ユーザーへの返答内容が最大の資産
      • 情報は記録しておかないと覚えていられない
      • 対応内容を残しておかないと対応内容忘れによる二度手間が発生する
      • 誰でも簡単に書き込める場所にする
        • リリース直後の記録にクオリティは問わない
        • クリーニングは後で行う
    • システムで解決できるものは極力システムで解決する
      • ヒューマンエラーが起きない工夫<人が介在しなくて良い工夫
      • ミスはどれだけ頑張って防いでも0にできない
      • ケアレスミスが怖い作業ほどシステムに任せる
        • ポイント操作など
      • 人の手でやる場合、ポイント処理操作などはペアワークが必要なため2倍時間がかかる
      • 運用でカバーするヒューマンエラーのリスクと開発工数を天秤にかける
    • 問い合わせ内容のレポート
      • ユーザーの声は改善案の宝庫
      • ユーザービリティ改善
      • 多い問い合わせに対応することで運用負荷も改善
    • コンテンツのスペックを決めておく
      • 例えば紙データをweb用に書き出すだけだと色がくすむ
      • サイズがバラバラの画像だとパフォーマンスに影響が出る
      • レギュレーションはベンダーとすり合わせて画像加工担当者にあらかじめ渡しておくと良い
  • あまり効果がなかったこと
    • 細かいスケジューリング
      • 外的要因でスケジュールが変更されることが多い
      • なかなかスケジュール通りにいかない
      • 一つ崩れると全てが崩れ、自分でコントロールできない
      • マイルストーンを決めて2週間ごとくらいにタスクを決めて動いて行く方があっていた
    • 定型返答文の作り込み
      • 事前に用意した定型返答文でリリース後に使用したものは6割くらい
      • リリース後の1週間で作った文面は事前準備の5倍くらい
      • 準備は8割くらい
      • 「素材」を作るという感覚
      • 悩んだら作らないという選択もする
    • 返答フロー図の作成
      • 自分しか更新できない
        • リリース前後の忙しい時期に直す余裕がない
      • 無くてもどうにかなってしまった
        • 分岐が複雑だったため、オペレーターは返答フロー図を参考にしなかった
      • 「無くても困らない」「使いこなせない」ものを作らない
  • やっておけばよかったこと
    • 問い合わせ調査のタスク管理
      • エンドユーザーからの問い合わせで開発調査が必要なもののタスク管理
      • 最初はスプレッドシートで管理していたが、タスクが長期化するにつれ苦しくなった
      • Myster taskを導入
        • ツールの選定基準
          • それぞれのコメントが誰のものか分かる
          • タグ付けで後から検索できる
          • チケットごとに列が分けられる
          • 既存システムと連携可能
          • UIが直感的で教育コストがかからない
    • 自動集計機能
      • 数値の報告は必ず発生する
      • カスタマーサポートの場合は問い合わせ件数、その他アプリにまつわる数値
      • 自動で集計されるよう設計しておくと便利
  • まとめ
    • 運用はアプリリリース直後からアプリが終了するまでずっと続く
    • 手数をできるだけ減らしてアプリの改善などに集中できる時間を増やす

運用者視点のカスタマーストーリーモバイルご紹介

  • 運用全体の課題
  • 運用が回り出したら以下の課題解決を目指したい
    • 人不足
      • ワンオペ体制
    • 人為的なミス
      • 慣れなどからくるミス
    • 属人化
      • 運用者自身がブラックボックス
  • カスタマーストーリーモバイルとは?
    • オムニチャネルアプリの開発・運用ノウハウから生まれたモバイルアプリ生成サービス
    • カスタマーストーリーモバイルCMSの特長
      • 直感的なUI
        • 教育コストを下げ、属人化を防ぐ
      • APIで外部サービスと容易に連携
        • データ登録のためのデータ作りという手間を省く
        • データを1から作り直す必要がない
      • 運用ノウハウが盛り込まれた機能
        • 豊富な開発・運用経験から得たCMSの要望や運用ノウハウを機能に落とし込んである
      • (デモ)
    • クラスメソッドのモバイルアプリ支援
      • プロトタイプ作成
      • ソースコードレビュー
      • プッシュ通知による再訪率向上
      • 運用支援
        • カスタマーサポートの構築やコンテンツ登録など悩みに合わせて運用をサポート
      • etc

お問い合わせ

カスタマーストーリーモバイルについての詳細説明/お問い合わせはこちら

クラスメソッドのモバイルアプリ支援/運用支援についての詳細説明/お問い合わせはこちら

本イベントの他セッションレポート

Repro様 成功企業に学ぶ、事業成長につなげるアプリの作り方とリリース後のグロースハック Repro株式会社 代表取締役社長 平田 祐介氏 こちら
Classmethod オムニチャネルを成功させるためにアプリ開発で重要な3つのポイント クラスメソッド株式会社 モバイルアプリサービス部 部長 大橋 力丈  Coming soon
Classmethod 知らなきゃ怖い?モバイルアプリ運用の課題と解決ヒント クラスメソッド株式会社 事業開発部 小林 美沙子 本記事

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.