Upgrade to Pro — share decks privately, control downloads, hide ads and more …

『盛れる』をつくる開発プロセス

 『盛れる』をつくる開発プロセス

CEDEC2021にて発表した資料となります。

furyu-puri

April 12, 2022
Tweet

More Decks by furyu-puri

Other Decks in Technology

Transcript

  1. 5 © FURYU Corporation. 井内 聡 自己紹介 いうち さとし •

    主な役割はソフトウェアに関わる部分の、 計画と進行管理、課題の特定と解決、 メンバーが開発しやすい仕組みづくり。 ◆役割 プリントシール機 ソフトウェアチーム リーダー ◆働き方
  2. 14 © FURYU Corporation. 似てるけど違う プリの特徴 ◆特徴 • 瞳にアーチ状のキャッチライト •

    カメラの画角を ユーザーが調整できるズーム機能 • 自分のこだわりを詰め込んだシールが 作れるシール編集
  3. 15 © FURYU Corporation. 似てるけど違う プリの特徴 ◆特徴 • 約80万通りの組み合わせ「顔編集」 •

    外装にインパクトを与えるサイネージ • 撮影準備タイム機能で 撮影開始をユーザーが選べる
  4. 16 © FURYU Corporation. 似てるけど違う プリの特徴 ◆特徴 • カメラを動かしてお好みの画角で撮影 •

    全身盛れる ボディレタッチ • 「いらすとや」とコラボレーション
  5. 17 © FURYU Corporation. 似てるけど違う プリの特徴 ◆特徴 • カメラを動かしてお好みの画角で撮影 •

    全身盛れる ボディレタッチ • 「いらすとや」とコラボレーション
  6. 22 © FURYU Corporation. プリの開発を分類 複雑 (Complex) カオス (Chaotic) 単純

    (Simple) 煩雑 (Complicated) ◆クネビンフレームワーク • 問題を分類するためのフレームワーク • 問題は4つに分類できる ※無秩序は省略します
  7. 23 © FURYU Corporation. プリの開発を分類 複雑 (Complex) カオス (Chaotic) 単純

    (Simple) 煩雑 (Complicated) ◆単純(Simple) ▶ 特徴 問題が理解ができており、 それに対する解決策も明確な物事 ▶ 対処 問題を把握、分類し、 ベストプラクティスを適用
  8. 24 © FURYU Corporation. プリの開発を分類 複雑 (Complex) カオス (Chaotic) 単純

    (Simple) 煩雑 (Complicated) ◆カオス(Chaotic) ▶ 特徴 完全に予測不能で因果関係も分からず、 コントロールできない問題 ▶ 対処 とにかく、目の前で起こった問題を 解決するしかない
  9. 25 © FURYU Corporation. プリの開発を分類 複雑 (Complex) カオス (Chaotic) 単純

    (Simple) 煩雑 (Complicated) ◆複雑(Complex) ▶ 特徴 分析だけでは因果関係がわからず、 解決策に向かって実験的なアプローチが 必要な問題 ▶ 対処 不完全な状態で決定を下し、 結果をもとに次の決定を下すサイクル アジャイルが有効なアプローチ
  10. 26 © FURYU Corporation. プリの開発を分類 複雑 (Complex) カオス (Chaotic) 単純

    (Simple) 煩雑 (Complicated) ◆煩雑(Complicated) ▶ 特徴 解くべき問題は分かっているが、 専門知識が必要。 解決方法を特定すれば前に進む問題 ▶ 対処 問題を分析、調査し、行動する。 ウォーターフォールな アプローチが有効
  11. 33 © FURYU Corporation. プリの開発は2種類に分類できる ユーザーに寄り添う開発 ハードウェアに寄り添う開発 LED ペン 多種多様なメイク

    ハードウェアに寄り添う ウォーターフォール開発を行いながら、 ユーザーに寄り添う アジャイル開発を実践
  12. 44 © FURYU Corporation. ユーザーヒアリングの重要性 ユーザーはスペックに興味なし ハートスタンプは人気 だからといって、 「ハートのスタンプ 史上最高の搭載数」

    という機種では人気がでない 技術者として分かりやすい数字で勝負せず、 ユーザーが今求めているモノを探す ユーザーの欲しいを技術に変換 似顔絵は技術力の強さを発揮できる。 しかし、いくら技術が優れても、 ユーザーが必要としなければ、使われない。
  13. 49 © FURYU Corporation. プリ開発に関わるチーム 企画チーム デザインチーム ※これ以外にもチームはありますが、本発表に関わるチームだけ書いています。 ※複数人を表しているだけで、正確な人数を表す図ではありません。 ハードチーム

    ソフトチーム ひとつのコンセプトを 全員でつくる プリ開発に必要な専門チームが集結し 全員でプリをつくる ひとつのコンセプトを軸に 意見を出し合い、開発を進めている
  14. 50 © FURYU Corporation. プリの開発スケジュールの大枠 発 売 生 産 開

    始 コ ン セ プ ト 検 討 ソ フ ト ウ ェ ア チ ー ム 参 入
  15. 51 © FURYU Corporation. プリの開発スケジュールの大枠 発 売 生 産 開

    始 コ ン セ プ ト 検 討 ソ フ ト ウ ェ ア チ ー ム 参 入 期間中の開発目的
  16. 52 © FURYU Corporation. プリの開発スケジュールの大枠 発 売 生 産 開

    始 コ ン セ プ ト 検 討 ソ フ ト ウ ェ ア チ ー ム 参 入 期間中の開発目的
  17. 53 © FURYU Corporation. スクラムに近い開発プロセス ソフト進捗 れんらく会 全体進捗 ふりかえり 昼礼

    ユーザー ヒアリング 開発 開発したプリ タスク一覧 ヒアリングスケジュール ハードスケジュール 課題一覧
  18. 54 © FURYU Corporation. スクラムに近い開発プロセス ソフト進捗 れんらく会 全体進捗 ふりかえり 昼礼

    ユーザー ヒアリング 開発 開発したプリ タスク一覧 ヒアリングスケジュール ハードスケジュール 課題一覧 スプリント バックログ プロダクト バックログ デイリー スクラム インクリメント スプリント レビュー スプリント レビュー レトロスペクティブ スプリント プランニング
  19. 55 © FURYU Corporation. スクラムに近い開発プロセス ソフト進捗 れんらく会 全体進捗 ふりかえり 昼礼

    開発 開発したプリ タスク一覧 ヒアリングスケジュール ハードスケジュール 課題一覧 ユーザー ヒアリング
  20. 56 © FURYU Corporation. れんらく会 全体進捗 ユーザー ヒアリング 開発したプリ ふりかえり

    開発したプリはユーザーヒアリングで評価 ユーザーヒアリングは主に企画チームが対応 プレイ中の様子、プレイ後のインタビューは 中継され、観察することができる 毎週、ヒアリング 開発者全員がユーザーに近く 良い意見も悪い意見も直接聞ける 開発のモチベーション向上 POINT
  21. 57 © FURYU Corporation. れんらく会 全体進捗 ユーザー ヒアリング リ ふりかえり

    れんらく会は 全員で次を決める ユーザーヒアリングの結果を共有 次に向けて改善する内容を決める ターゲットとする ユーザーヒアリングの日程を決める 改善案を決める人がその場にいる 次への行動が早い POINT
  22. 58 © FURYU Corporation. れんらく会 全体進捗 ユーザー ヒアリング リ ふりかえり

    全体進捗は 方向性やチーム間の調整 全体進捗は各チームのリーダーが集まり、 チームの課題共有や、チーム間の納期を調整 責任と権限を持った人がその場にいる 決定が早い POINT
  23. 59 © FURYU Corporation. ソフト進捗 全体進捗 れんらく会 昼礼 ヒアリング ゲーム大会

    生産向け確認 開発 開発したプリ ふりかえり 一週間で何を作るか、どう作るかを決定する 誰と誰が協力するのか モジュール間のIFはどうするのか 開発前に曖昧をできるだけ取り除く MTGが終わると、一週間のタスク一覧が完成 ヒアリングスケジュール ハードスケジュール 課題一覧 タスク一覧 ソフト進捗は 何をどう作るか決定 全員で解決するタスクについて話し合い 計画の透明性を向上 POINT
  24. 60 © FURYU Corporation. 全体進捗 れんらく会 昼礼 ヒアリング ゲーム大会 生産向け確認

    開発 開発したプリ タスク一覧 ふりかえり 開発中は15分間の昼礼を毎日実施 全体連絡と以下を中心に共有 昨日やったこと、今日やること。困っていること 進捗確認ではなく、 チームがゴールに向かっているかを確認 ュール ール 昼礼で問題発見! 短いけど大切な時間 検査・適応の最小単位 軌道修正してゴールを目指す POINT
  25. 61 © FURYU Corporation. 全体進捗 れんらく会 ヒアリング ゲーム大会 リ ふりかえり

    一週間の働き方をふりかえる 個人、チーム、プロセス、ツール、など についてふりかえる ふりかえり自体もふりかえっており 独自のふりかえりフレームワークも誕生 ▶独自のフレームワークはのちほど紹介 ふりかえりで 開発をより良くする 自分たちでプロセスを作ることで チームに対するオーナーシップ向上 POINT
  26. 63 © FURYU Corporation. ハードウェアに関わる開発 ハードウェアに関わる 開発は大きく3つ ハードウェアに寄り添う開発 LED ペン

    ①ゲーム中のハードウェア制御 ②生産工程で使用する機能開発 ③新規部材の検証
  27. 64 © FURYU Corporation. ハードウェアの開発がベース 発 売 生 産 開

    始 キ ッ ク オ フ コ ン セ プ ト 検 討 ソ フ ト ウ ェ ア 開 発 チ ー ム 参 入 • 「生産」という絶対的な納期がある • 計画段階から仕様変更が少ない • プロジェクト開始時に 各マイルストーンから逆算した スケジュールを立てる。 ハードウェアの開発をベースに 全体の計画を考える
  28. 65 © FURYU Corporation. 混ぜて計画して、チームで開発 発 売 生 産 開

    始 キ ッ ク オ フ コ ン セ プ ト 検 討 ソ フ ト ウ ェ ア 開 発 チ ー ム 参 入 ユーザーヒアリングを軸にした 変化させるスケジュール 生産のマイルストーンを守る スケジュール 1つのチームで開発できる
  29. 68 © FURYU Corporation. ユーザーに寄り添う開発 リソースとスケジュールを固定 スコープ スケジュール リソース スコープ(開発する機能)を調整

    ヒアリングの日程は変わらない 開発チームの人数も基本的に変わらない 作る機能を調整 タスクの制約を意識したコントロール
  30. 69 © FURYU Corporation. スコープ スケジュール リソース リソースを調整 作る機能は変わらない スケジュールも基本的に変わらない

    開発する人数を調整 ハードに寄り添う開発 スコープとスケジュールは固定 タスクの制約を意識したコントロール
  31. 70 © FURYU Corporation. ユーザーヒアリング ハードウェア スコープ スケジュール リソース スコープ

    スケジュール リソース タスクの制約を意識したコントロール 調整でコントロールしきれないこともあり まだまだ課題の多い領域 タスクのコントロール
  32. 71 © FURYU Corporation. ユーザーヒアリング ハードウェア スケジュール リソース スコープ スケジュール

    リソース スコープ ハードウェアのリソースを増やすには ユーザーヒアリングのスコープを小さくする タスクのコントロール タスクの制約を意識したコントロール
  33. 72 © FURYU Corporation. ユーザーヒアリング ハードウェア スケジュール リソース スコープ スケジュール

    リソース ハードウェアのリソースを増やすには ユーザーヒアリングのスコープを小さくする タスクのコントロール タスクの制約を意識したコントロール スコープ
  34. 73 © FURYU Corporation. ユーザーヒアリング ハードウェア スコープ スケジュール リソース スコープ

    スケジュール リソース ハードウェアのリソースを増やすには ユーザーヒアリングのスコープを小さくする タスクのコントロール タスクの制約を意識したコントロール
  35. 74 © FURYU Corporation. ユーザーヒアリング ハードウェア スコープ スケジュール リソース スコープ

    スケジュール リソース タスクのコントロール タスクの制約を意識したコントロール ハードウェアのリソースを増やすには ユーザーヒアリングのスコープを小さくする ユーザーヒアリング向けの対応が多い場合は スコープを小さくする
  36. 75 © FURYU Corporation. ユーザーヒアリング ハードウェア スコープ スケジュール リソース スコープ

    スケジュール リソース POINT ハードウェアのリソースを増やすには ユーザーヒアリングのスコープを小さくする ユーザーヒアリング向けの対応が多い場合は スコープを小さくする いずれも、ユーザーヒアリングの スコープの調整が必要 タスクのコントロール タスクの制約を意識したコントロール
  37. 76 © FURYU Corporation. 次のユーザーヒアリングまでに 新しいメイク機能を搭載したいです。 うーん。今のリソースを 考慮すると厳しそうだ。 なるほど、評価したいことは UIの操作性ですか?

    いえ、新しいリップの色味がユーザーに 受け入れられるか見てみたいです。 じゃあ、デザインはそのままで 実際に描画されるリップの色味を 変えるでも良いですか? はい!それで評価できます! スコープ調整の一幕
  38. 80 © FURYU Corporation. ソフトチームはマトリックス型組織 ※複数人を表しているだけで、正確な人数を表す図ではありません。 リーダーグループ 画像処理グループ ゲーム制御グループ 落書きグループ

    • 商品軸とは別に技術軸のチーム • 技術チームの目的 – 技術の共有 画像処理のアルゴリズムを統一 UIの統一など – 開発の相談 – 技術面の教育 … … … … … … チームの一体感を持ちつつ、 技術の間の連携が生まれる POINT
  39. 86 © FURYU Corporation. スキルマップとペア育成 ▶技術力向上を目的にスキルマップを運用 ▶スキルマップはメンバーの保有スキルを 表形式に可視化したもの ▶スキルマップがあればチームのスキル バランスが可視化される

    ▶スキルは「C++」や「Jenkins」のような 一般的な技術と、「画像処理」「カメラ制御」 「メイクアップ機能」などプリ開発に 必要なスキルも洗い出している ◆スキルマップ
  40. 88 © FURYU Corporation. ペア/モブプロ と ペア/モブ設計 ◆ペア/モブ 効果 ▶有識者から初心者への教育、作業効率化

    ▶悩んだ時に一緒に悩んでメンタルケア ▶内容の理解者が増え、負荷分散できる ◆ペア/モブ 活性化 ▶全員がペアモブの効果を認識 ▶ペア、モブのきっかけがある
  41. 90 © FURYU Corporation. 進化するふりかえり ◆KPT KPT KJPT GTPA ▶Keep:続けたいこと

    ▶Problem:悪かったこと ▶Try:改善したいこと ◆KJPT ▶KPT + Joy ▶Joy:楽しかったこと ▶Good & New の考えを参考に追加 ▶仕事の中から楽しみを探すように設計
  42. 91 © FURYU Corporation. 進化するふりかえり ◆GTPA KPT KJPT GTPA ▶G:Good、Great、頑張った

    ▶T:楽しかった ▶P:ぴえん、ぱおん、プロブレム ▶A:アイデア、案 事実だけでなく、感情も共有することで 言いたいことが言いやすい環境になる。 自分たちでプロセスを改善する事例を 作ることでチームを自分事として考えられる。 POINT
  43. 92 © FURYU Corporation. コロナ禍を乗り切る分報 ◆コロナ禍を乗り切る分報 週報、日報のように報告を分単位で行う 毎日チームごとのチャンネルに 個人のスレッドを立てて 返信する形で書き込む

    テレワーク普及の以前よりも お互いの状況が分かるようになり ちょっとした困りごとにもリアクションできる ちょっといいですかコミュニケーションが オンラインでもとりやすい。 POINT
  44. 94 © FURYU Corporation. まとめ ◆盛れるは普段の自分よりも良くなっていること ◆ユーザに寄り添う開発 ▶技術本位ではなく、ユーザーの欲しいを作る ▶ユーザーヒアリングの目的は 作った機能の評価

    と ユーザーと開発者の感性を近づける ◆ハードに寄り添う開発 ▶ゴールから逆算で計画を立てる ▶計画が変わらないハードウェア開発をベースに計画する