この記事は フリュー Advent Calendar 2022 の10日目の記事となります。
１．はじめに
フリューでプリントシール機の開発をしている井内です。年末ということで今年の登壇をふりかえってみたいと思います。
今年は2022/07/21に開催されたDevelopers Summit 2022 Summerで登壇機会を頂き、「継続的なユーザーヒアリングでプロダクト改善！それを支えるプロセスと体制」というタイトルで発表させていただきました。フリューのプリ開発の特徴でもある「毎週のユーザーヒアリング」をどのようなプロセスや体制で行っているか紹介しました。
２．発表の概要
『生産性が高いとは「価値」のあるプロダクトを「早く」届けること』だと定義して、 ユーザーに響く価値を高める方法 と 開発効率を高める方法 、さらに 開発力の高め方 について紹介しました。一つ一つの概要も紹介させていただきます。
2-1.ユーザーに響く価値を高める方法
プリは多様なユーザーの期待に応えるために機種ごとのコンセプトが異なります。トレンドも移り変わりがあり、これを作れば正解！というものはありません。そこで、プリの価値を最大化するため、毎週のようにユーザーヒアリングを実施しています。
ユーザーヒアリングの目的もフェーズによって変わっていきます。開発初期のころは「搭載を判断するフェーズ」として、後戻りができない部分(ハードに関わる部分など)の評価を中心に開発します。開発中盤以降は「ブラッシュアップするフェーズ」として、搭載した機能がより使いやすく、より理解しやすくなるように改善を重ねます。評価はユーザーヒアリングや社内レビューの結果を加味して複合的に判断します。
2-2.開発効率を高める方法
毎週ユーザーヒアリングを実施するには開発スピードが求められます。そのために色々な施策がありますが、今回は 「オリジナルプロトタイプツール」「開発プロセス」 について紹介しました。
オリジナルプロトタイプツール
上記の「搭載を判断するフェーズ」の時期は「搭載しない判断」もありますので、少ないコストで素早く開発することが求められます。一般的なプロトタイプツールではカメラやカーテン等のプリントシール機特有のハード制御が難しいため、「オリジナルプロトタイプツール」を作成して活用しています。
開発プロセス
社内ではアジャイル、スクラムという言葉はほとんど使っていませんが、スクラムに近いプロセスになっています。狙ってこうなったわけではなく、ユーザーヒアリングを中心に考えて試行錯誤を繰り返した結果、スクラムに近いプロセスになっていました。スライドでは各項目毎のPOINTについても説明していますので、ぜひご覧ください。
2-3.開発力の高め方
「価値の最大化」や「開発効率」のベースとなる開発力も大切です。そのための施策として役割別のチーム体制とスキルマップを活用したマンツーマン指導について紹介しました。
役割別のチーム体制
チーム体制は2つの課題がありました。チームごとの「マネジメント力のムラ」と「認知負荷の高さ」です。今年からチャレンジしたことはチームの分割とチームを支援するチームを作ることです。 「メインチーム」「サポートチーム」「メンテナンスチーム」「支援チーム」の4つ に分けました。
- メインチーム：プリにあると嬉しい新機能（＝ウリ機能）を中心に開発するチーム
- サポートチーム：メインチームが集中してウリ機能を開発するためにサポートするチーム
- メンテナンスチーム：メンテナンス機能を開発するチーム
- 支援チーム：技術課題、マネジメント課題を解決するチーム
この施策はチャレンジ中で常に改善しつつではありますが、定量的に工数の面で効果が見えてきていますし、定性的にはメインチームがウリ機能に集中して開発が出来ているようにも感じます。
スキルマップを活用したマンツーマン指導
個人の成長速度に合わせた育成をするため、自身が伸ばしたいスキルに秀でた人を師匠とするマンツーマン指導を行っています。秀でた人を探すときや自身のスキルを客観視するときにスキルマップを活用しています。師匠と本人でスキルに応じた課題を設定しフィードバックしながら進めています。
３．発表をふりかえって
今までは聴衆者として参加していたデブサミに登壇できるということで、とてもとても嬉しく光栄な時間でした。プリ開発が行っているプロセスを出来る限りわかりやすく、伝えたつもりです。何か一つでも参考になる部分があれば幸いです。
デブサミの運営のみなさまは本当に素敵な方ばかりでした。事前の打ち合わせや発表における注意点などを親切に説明頂きました。また、発表当日のリハーサルで、私の作ったスライドのメモ欄が長すぎて配信環境の画面に映りきらない問題が発生したときもスタッフの皆さまのご協力ですべて表示できましたし、「発表中に問題が発生した場合は焦らずに私たちに声をかけてください」というお声がけのおかげで最後までスムーズに発表することが出来ました。その節は本当にありがとうございました。緊張しながらも安心して発表することができました。
今回はプリ開発の全体像をお伝えする発表でしたので、次は一部にフォーカスした具体的な発表もしてみたいと思っています。
４．登壇資料作成のTips
ありがたいことに、なんどか登壇する機会を頂き、資料作りも自分なりのスタイルが出来てきました。私なりの資料作成のコツを言語化したいと思います。すこしでもお役に立てば幸いです。
-
資料作る前のラフ版に時間をかける
よく言われることですが、いきなりスライドから書かずに テキストベースで構成を作り込んだ方が良い です。スライドを作りきった後に大きな修正が発生した場合の手戻り時間と絶望感は半端ないです(経験談)。 -
伝えたいことを明らかにする
スライド毎に伝えたいメッセージを明確にします。テキストベースのラフ版には「〇〇を伝える」と一言で表現できるか確認します。これをすることで、考えが整理できますし、1スライドの情報が増えすぎることも抑えられます。 -
メモ欄に想定経過時間を書く
メモ欄に想定経過時間をメモしておきます。当日の発表では想定時間か確認しながら、話すスピードを調整したり、説明を省略したりしながら進めます。 -
メモ欄は書き過ぎない
発表環境によっては メモ欄の見える範囲が決まっている ので、メモ欄はほどほどの量にした方が良いと思います。事前に運営の方からメモ欄の目安を教えてくださることもあります。
私はメモ欄にカンペを書きすぎて、配信環境の画面に収まらない問題が発生し、スタッフの方に調整頂いた経験があります。 -
みんなが見える場所でつくる
出社している場合のTipsなのですが、社内で資料を作っていると通りがかった人が声をかけてくれます。その時に資料を見てアドバイスやアイデアを頂けることがあります。 -
社内インタビューする
自分では分からない過去のことなどありますよね。そういったときは、思い切って社内インタビューすると良いです。商品に対する想いや今のプロセスになった経緯を知ることができ有意義です。ストーリーを知ると今のプロセスや仕組みの見え方も変わってきます。資料作りのTipsというよりも、資料作りを通して今後の開発に活きる経験になりますが、継続して改善を進めるにしても過去の経緯を知っていると改善の方向も変わると感じます。
５．さいごに
今後も多くの方が楽しめるプリを開発できるように改善を繰り返していきたいと思います。そして、そこから得られた知見を登壇やQiitaなどで発信し、少しでも開発に関わるすべての皆さまに貢献できればと思います。