こんにちは。 株式会社mikanでiOSエンジニアなどをしている、飯田（@aviciida）といいます。 この記事は「モバイルアプリマーケティングアドベントカレンダー2020」の6日目の投稿です！
前回のTech Blogでは、「mikanがどんなテーマ・やり方で開発を進めているのか」をざっくり触れました。
テーマとしては大きく
ゴリゴリ改善回していく系（色んな改善を回して継続率・LTVをあげよう！）
と
開発基盤整える系（クライアントサイドのDBをFirestoreに統一しよう！）
があり、多くの開発リソースをそこに割いています。
しかし多くのユーザーさんに毎日使っていただいているmikanには、日々多くの問い合わせが寄せられ、不具合も報告されており、不具合修正の開発も必須になってきます。
この記事では、mikanでは不具合に関してどのように向き合っているか、また報告される不具合をどうCSチームと開発チームが連携して管理しているのか、という話を書こうと思います。
目次
不具合との向き合い方
1. 不具合の優先順位
450万DLを突破し、たくさんの方々に使っていただけるようになったmikanですが、正社員は5人と、まだまだ少数精鋭のチームで開発しています。
そのため、クオーターで取り組むと決めたテーマ（今ならDBのFirestoreへの移行。前なら7日後継続率の改善など）に全力でフォーカスしていく必要があります。
一方で、何かにフォーカスしてそこでの成果を最大化しようとすると、どうしても他のことは後回しになってしまいがちです。
今までも、クオーターのテーマに設定しているプロジェクトにフォーカスするあまり、相対的に不具合の優先度が下がってしまうこともありました。
ただ、グロース施策を回すにしても、開発基盤をガツっと開発するにしても、目の前にいるユーザーの困りごとに真摯に向き合うことを後回しにする理由にはなりません。
だから少なくとも、起きている不具合には、メインプロジェクトを走らせながらも、一定のリソースを使って直していかないといけない。という考えをmikanでは大事にしています。
今mikanでは、クオーターのテーマからおりてくるメインプロジェクトと「同等もしくはそれ以上」の優先度を不具合解消に置くようにしています。
良くない不具合が起きてしまった場合は、メインプロジェクトのスケジュールをずらしてでも最優先に対応するようにしています。
そのために、アプリ内で起きている不具合が一覧化され、それが重要度順にしっかりまとめられるようにするための、後述の「不具合の管理方法改善」が必須だったのです。
2. 常にユーザーの声に触れる
自分の実感がないことに対して常に優先度を高く持っておくのは至難の技です。
ユーザーの困りごとを解決すること、ユーザーに寄り添うこと、これらを常に大事にするために、ユーザーの方々から寄せられる声にいつも触れている必要があります。
mikanでは大きくSlackと、月曜朝のWeekly All Handsを活用しています。
Slackには#store-review で「ストアに投稿されたレビュー」、#helpshift で「アプリ内チャットの問い合わせ」が流れるようになっていて、そこから開発メンバーでディスカッションが発生し、そこから実際にissueになることもあります。
また、月曜朝のWeekly All Handsでは、基本的に各チームのプロジェクト進捗状況を全体の場で発表していますが、CSチームからは「先週のユーザーの声」をピックアップして紹介してもらっています。
このように毎日・毎週ユーザーの方々からの声に触れることで、どのようなことに困っているのか、アプリのことをどう思っているのか、という実感が常に湧くようになっています。
3.「プロダクトチーム」として一丸となって向き合う
一般的には、不具合に対する責務から、たくさんくる問い合わせの対応チームとしてのCSチーム、不具合の解消を実装していく開発チーム、という風に分断されがちです。
ですがmikanでは、チームとしては分かれているものの、「mikanを良くしていく」という同じ目的をもったプロダクトチームとして、不具合への対応・解消を進めています。
例えば、実装が主な役割である開発チームであっても、不具合の詳細を深堀るためにサポートチャットを返信することも頻繁にあります。（mikanを創業して3年くらいまでは、CSチームは存在せず、開発陣が毎日返信対応をしていたそうです。）
また、開発チームがユーザー対応をするだけでなく、CSチームが開発寄りのタスクをしてくれることも非常に多いのもmikanの特徴です。
クライアントのSQLiteファイルを展開して調査・修正したり、機種変更した際のユーザーのデータ移行の対応をしたり、AWSのコンソールにログインして音声の修正を行うこともあります。
さらに、開発チームとCSチームの連携のために、毎週1時間、両チームが定例を行い、不具合の詳細の共有や、開発中の不具合の進捗共有などを行っていたりもします。
CSチーム、開発チームが一丸となって問い合わせ対応や不具合解消に取り組むことで、アプリストアのレビューで低い評価を星5に更新してくださったり、素早い対応に感激したと星5をつけてくださる方々もいます。
不具合の管理方法を刷新した話
さて、カッコよく書いてしまいましたが、不具合周りでmikanにはまだまだ多くの課題があります。
ここでは、その中の1つの課題であった「不具合の管理方法」を改善した話を書こうと思います。
1. 当時の課題
時を今年夏まで戻します。 今振り返ると当時の不具合の管理はだいぶ雑だったな...と反省するばかりですが、大体以下のような感じでした。
- 新規の不具合が発生・（問い合わせから）判明
- CSのメンバーがSlackに投稿（当時は独自Notionページでまとめていたり、Spreadsheetを使っていたりと、issueを特定の場所に必ずまとめる、のような仕組みがSlack投稿以外はありませんでした。）
- 開発チームがSlackを確認し、チケットにはせずに、適宜取り組む
課題としては
不具合が一覧化・優先順位付けされていないので、
CSチーム「不具合改善の進捗がわからない」開発チーム「取り組む不具合に抜け漏れが出てしまう」「デバッグに必要な情報が点在していて開発に時間がかかってしまう」
というものが大きくありました。
2. 何をしたか
改善を行ったときに求めていた要件としては以下です。
- 不具合が一覧で確認でき、新規追加されたらストックされていく
- ステータスなどでフィルターできる
- 正しいステータスがわかる（CS確認中なのか、開発待ちなのか、開発中なのか、リリース済みなのか）
その要件を満たすために、今回はNotionのデータベース機能を使って解決しました。
mikanではドキュメンテーションツールとしてNotionを採用していて使い慣れていたこと、そしてこのデータベース機能が、リンクをコピーすれば同じDBを様々なフィルタで別々のviewとして見ることができることが決め手でした。
（上の三枚の画像は、別々のデータベースに見えますが、実は同じデータベースを参照しています。）
これで、新規追加していけば、どんどんそこに蓄積されていき、issueごとにステータスも担当者も付けられるので、とても便利です。
3.「でも運用が大変なんでしょ？」
こういう改善は、改善するだけなら簡単で、本当に難しいのが「運用」部分だと思っています。運用されるように作ることが大事です。
特に今回は運用されなくなる原因の1つである「二重管理」にならないように、というのが肝でした。
今までも、mikanはスプレッドシートで不具合を管理しようとした時期もありましたが、不具合と開発issueが別々で管理されていたため、頻度高くステータスを同期する必要があり、運用が苦しかったです。
そこで今回は、普段チームがissueを管理している、かつ個人がタスク管理をしているデータベースに入れるようにしました。
CSチームは不具合issueの起票から開発に確認してもらうまでを担当。 それ以降、その不具合解消の実装を開発チームのメンバーがアサインされたら、不具合issueのアサインをその人に変更すれば、それがそのまま開発issueに変身。
こうすることで、アサイン以降は開発メンバーによって実装の進捗に合わせてステータスが変更され、CSチームはそのステータスを見るだけで開発の進捗状況がわかります。
つまり、不具合issueのアサインまでのステータス変更はCSチームが、その後は開発チームが行うことで、以前のCSチームと開発チームがそれぞれステータス変更をする「二重管理」の課題が解決されたのです。
運用が始まってからおよそ半年経ち、運用における小さな改善点に関しては挙がり次第解決していますが、頓挫することなく順調に運用が進んでいます！🙌
今の課題: そもそも不具合を出さない体制に
不具合は定常的に発生するものなので、どうしても「どのように解決するか」という方向に考えが寄ってしまいますが、「不具合が発生しない」のが1番大事です。
これに関しては大きく2つ、開発レイヤーとして開発段階でテストを書くなど、壊れにくいコードにする、QAレイヤーとしてテストケースを充実させて、不具合をリリース前に検知する
があります。
一言でいえば、「安定したアップデートを届けるフローを確立する」です。
まだまだmikanではできていないのが現状ですが、ピンときた方（iOS/Androidエンジニア、QAエンジニアの方）は、ぜひお話ししましょう！
採用情報
弊社では一緒にmikanを伸ばしていく仲間を募集中です。 iOS/Androidエンジニア、そしてQAエンジニア、教育事業、英語領域に興味がある方、ぜひご連絡ください！
付録: mikanでのNotion活用術
mikanは2019年からNotionを使っているのですが、弊社のmizoさんが考案したデータベース活用法がとても画期的なので、付録として少し紹介します。
（ちなみに、今回紹介した不具合管理方法も、今から紹介するデータベースに乗っかっただけです。）
mikanではチームごとにも、全体でも、1つのデータベースを参照しながらタスク管理をしています。
全体「チーム」「プロジェクト」「取り組み週」などのタグが入ったissueをそれぞれ追加したマスターのデータベース（画像1枚目）各チームそのマスターデータベースのリンクを各チームのページに貼り付けて、チーム名でフィルタすることで、そのチームのダッシュボードに変身（画像2枚目。コンテンツチームのダッシュボード）
ちなみに、このデータベースは個人のタスク管理としても使えます。
マスターデータベースのリンク貼り付けでCreate Linked Databaseを選択し、
「アサイニー」を自分に、「取り組み週」を今週にすれば、「今週の自分が取り組むtodoリスト」の出来上がりです。
さらに、リリース周りもこのデータベースで管理しています。
Notionで各バージョンのリリース内容がわかるようにまとめているのですが、
このページの中にある「当該バージョンでの変更点」は、このマスターデータベースのリンクを貼り付けて、バージョンでフィルターすれば出るようになっています。
（画像は3.17.8での変更点まとめ）
ですので、開発が完了した不具合は、そのissueにバージョンを記入すれば、リリースノートにも出現しますし、どのバージョンで修正されたのかというのも、追加の手間なしにCSチームが知ることができます。
このような感じで、mikanではNotionを最大限活用して、タスク管理を行っています！
読んでくださり、ありがとうございました！ ざっとmikanにおける不具合の管理方法や向き合い方について書きましたが、少しでも他のアプリ事業者さんのお役に立てていれば幸いです！ （書きながら、まだまだ改善点だらけだなと痛感しています...！）
もっとこうしたらいいんじゃない？ここはどうやっているの？など、コメントや質問などあれば是非是非ご連絡ください！
