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

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

Transcript

1. 1 © FURYU Corporation. ～ハードウェアも含めたアジャイル開発～ 『盛れる』をつくる開発プロセス フリュー株式会社 井内 聡
2. 2 © FURYU Corporation. さっそくですが、
3. 3 © FURYU Corporation. 『盛れる』知ってますか？
4. 4 © FURYU Corporation. 【盛れる】 ◆意味 普段の自分より かわいくなったり、きれいになった ということを表す言葉です ◆例文 このプリ、めっちゃ盛れるよ
5. 5 © FURYU Corporation. 井内 聡 自己紹介 いうち さとし • 主な役割はソフトウェアに関わる部分の、 計画と進行管理、課題の特定と解決、 メンバーが開発しやすい仕組みづくり。 ◆役割 プリントシール機 ソフトウェアチーム リーダー ◆働き方
6. 6 © FURYU Corporation. INDEX プリのソフトウェア開発の特徴 ユーザーに寄り添う開発 プリのゲーム ハードウェアに寄り添う開発 「ユーザーに寄り添う」「ハードウェアに寄り添う」を混ぜる ユーザーに寄り添うプロセス 01 02 03 05 06 08 04 チームで作るソフトウェア開発の工夫 07 まとめ
7. 7 © FURYU Corporation. プリ の ゲーム
8. 8 © FURYU Corporation. プリの撮り方
9. 9 © FURYU Corporation. プリの撮り方 コインを入れたら 画面をタッチしてスタート、 好きなコースを選ぶ ゲームスタート
10. 10 © FURYU Corporation. プリの撮り方 一眼レフとストロボで本格撮影 ポーズ誘導やガイダンスで 失敗しにくい こだわり撮影
11. 11 © FURYU Corporation. プリの撮り方 多種多様なペンやスタンプ リップやチークや涙ぶくろ 多種多様な落書きでカスタマイズ 自由に落書き
12. 12 © FURYU Corporation. プリの撮り方 シール出口からシールが印刷 撮影したデータはケータイにも送信 上手に盛れたかな 出来上がり！
13. 13 © FURYU Corporation. 似てるけど違う プリの特徴
14. 14 © FURYU Corporation. 似てるけど違う プリの特徴 ◆特徴 • 瞳にアーチ状のキャッチライト • カメラの画角を ユーザーが調整できるズーム機能 • 自分のこだわりを詰め込んだシールが 作れるシール編集
15. 15 © FURYU Corporation. 似てるけど違う プリの特徴 ◆特徴 • 約80万通りの組み合わせ「顔編集」 • 外装にインパクトを与えるサイネージ • 撮影準備タイム機能で 撮影開始をユーザーが選べる
16. 16 © FURYU Corporation. 似てるけど違う プリの特徴 ◆特徴 • カメラを動かしてお好みの画角で撮影 • 全身盛れる ボディレタッチ • 「いらすとや」とコラボレーション
17. 17 © FURYU Corporation. 似てるけど違う プリの特徴 ◆特徴 • カメラを動かしてお好みの画角で撮影 • 全身盛れる ボディレタッチ • 「いらすとや」とコラボレーション
18. 18 © FURYU Corporation. 似てるけど違う プリの特徴 機種ごとにハードウェアが違う 動かすカメラ、ズーム機構、など 機種ごとにターゲットユーザーが違う 多種多様なメイク、ゲームシーケンス、など 実現するプロセスを紹介
19. 19 © FURYU Corporation. プリ の ソフトウェア開発 の 特徴
20. 20 © FURYU Corporation. 機種ごとにハードウェアが違う 動かすカメラ、ズーム機構、など 機種ごとにターゲットユーザーが違う 多種多様なメイク、ゲームシーケンス、など プリ開発の2つの特徴
21. 21 © FURYU Corporation. 問題を分類するためのフレームワーク クネビンフレームワークで分類
22. 22 © FURYU Corporation. プリの開発を分類 複雑 (Complex) カオス （Chaotic） 単純 （Simple） 煩雑 (Complicated) ◆クネビンフレームワーク • 問題を分類するためのフレームワーク • 問題は4つに分類できる ※無秩序は省略します
23. 23 © FURYU Corporation. プリの開発を分類 複雑 (Complex) カオス （Chaotic） 単純 （Simple） 煩雑 (Complicated) ◆単純(Simple) ▶ 特徴 問題が理解ができており、 それに対する解決策も明確な物事 ▶ 対処 問題を把握、分類し、 ベストプラクティスを適用
24. 24 © FURYU Corporation. プリの開発を分類 複雑 (Complex) カオス （Chaotic） 単純 （Simple） 煩雑 (Complicated) ◆カオス(Chaotic) ▶ 特徴 完全に予測不能で因果関係も分からず、 コントロールできない問題 ▶ 対処 とにかく、目の前で起こった問題を 解決するしかない
25. 25 © FURYU Corporation. プリの開発を分類 複雑 (Complex) カオス （Chaotic） 単純 （Simple） 煩雑 (Complicated) ◆複雑(Complex) ▶ 特徴 分析だけでは因果関係がわからず、 解決策に向かって実験的なアプローチが 必要な問題 ▶ 対処 不完全な状態で決定を下し、 結果をもとに次の決定を下すサイクル アジャイルが有効なアプローチ
26. 26 © FURYU Corporation. プリの開発を分類 複雑 (Complex) カオス （Chaotic） 単純 （Simple） 煩雑 (Complicated) ◆煩雑(Complicated) ▶ 特徴 解くべき問題は分かっているが、 専門知識が必要。 解決方法を特定すれば前に進む問題 ▶ 対処 問題を分析、調査し、行動する。 ウォーターフォールな アプローチが有効
27. 27 © FURYU Corporation. 機種ごとにハードウェアが違う 動かすカメラ、ズーム機構、など 機種ごとにターゲットユーザーが違う 多種多様なメイク、ゲームシーケンス、など プリの開発を分類
28. 28 © FURYU Corporation. ユーザーに寄り添う開発は複雑 複雑(Complex) ユーザーが何を喜んでくれるか 分析だけでは答えは分からない アジャイルなアプローチ 多種多様なメイク、ゲームシーケンス
29. 29 © FURYU Corporation. ユーザーに寄り添う開発は複雑 複雑(Complex) ユーザーが何を喜んでくれるか 分析だけでは答えは分からない アジャイルなアプローチ ユーザーに寄り添う開発 多種多様なメイク 多種多様なメイク、ゲームシーケンス
30. 30 © FURYU Corporation. ハードウェアに寄り添う開発は煩雑 煩雑(Complicated) 高度な専門知識は必要だが 解決すべき問題は明確 ウォーターフォールな アプローチ 動かすカメラ、ズーム機構
31. 31 © FURYU Corporation. ハードウェアに寄り添う開発は煩雑 ハードウェアに寄り添う開発 LED ペン 煩雑(Complicated) 高度な専門知識は必要だが 解決すべき問題は明確 ウォーターフォールな アプローチ 動かすカメラ、ズーム機構
32. 32 © FURYU Corporation. プリの開発は2種類に分類できる ユーザーに寄り添う開発 ハードウェアに寄り添う開発 LED ペン 多種多様なメイク
33. 33 © FURYU Corporation. プリの開発は2種類に分類できる ユーザーに寄り添う開発 ハードウェアに寄り添う開発 LED ペン 多種多様なメイク ハードウェアに寄り添う ウォーターフォール開発を行いながら、 ユーザーに寄り添う アジャイル開発を実践
34. 34 © FURYU Corporation. ～ハードウェアも含めたアジャイル開発～ 『盛れる』をつくる開発プロセス
35. 35 © FURYU Corporation. ユーザに寄り添う 開発
36. 36 © FURYU Corporation. 技術を活かしたプリを開発 初めに作った機種は 似顔絵をシールにする機種 強みだった顔認証技術を使って技術力で勝負 自慢の技術を使って似顔絵をシールに出力 技術者が自信をもって市場にリリース その結果は・・・
37. 37 © FURYU Corporation. プレイ、されていない
38. 38 © FURYU Corporation. 技術を活かしたプリを開発 さらに似せるための努力をした キャラっぽさを強くしたり リアルさを出したり より良い似顔絵が作れた！ その結果は・・・ 技術力を磨いて 似てるを突き詰める
39. 39 © FURYU Corporation. それでも プレイ、されていない
40. 40 © FURYU Corporation. ユーザーの声を聞く ユーザーの声を聞こう 関係会社の方に 「ユーザーの声を聞いてみては？」 とアドバイスをもらった 経験はないが、チャレンジしてみた
41. 41 © FURYU Corporation. ユーザーヒアリングの方法 ユーザーの声を聞こう インタビューアは社員 インタビューイはメインユーザの女子高生 筐体をプレイしてもらい意見をもらう 声を聞いて、分かった驚きの事実
42. 42 © FURYU Corporation. 似てても、いらない
43. 43 © FURYU Corporation. その体験から得た ユーザーヒアリングの重要性
44. 44 © FURYU Corporation. ユーザーヒアリングの重要性 ユーザーはスペックに興味なし ハートスタンプは人気 だからといって、 「ハートのスタンプ 史上最高の搭載数」 という機種では人気がでない 技術者として分かりやすい数字で勝負せず、 ユーザーが今求めているモノを探す ユーザーの欲しいを技術に変換 似顔絵は技術力の強さを発揮できる。 しかし、いくら技術が優れても、 ユーザーが必要としなければ、使われない。
45. 45 © FURYU Corporation. 常に新しいをつくるために ユーザーと開発者の感性を近づける トレンドは変わり続ける ユーザーヒアリングが大切なことは変わらない 学ぶことを怠ってはいけない ユーザーと開発者の感性を近づける 感性もインフラ 絶え間なく整備する
46. 46 © FURYU Corporation. ユーザーと開発者の感性を近づける コロナ禍でユーザーヒアリングが出来ない時期も 蓄積した感性で商品を作り、プレイされている ▼ ユーザーと開発者の感性が近いため、 欲しいものが想像できている だからといって 学ぶことを怠ってはいけない 感性もインフラ 絶え間なく整備する 自分たちがベストだと思った瞬間 負けは始まる
47. 47 © FURYU Corporation. ▶ユーザーは新しい技術ではなく、新しい魅力を求めている。 それを、探し続けるためにもユーザーと接点を持ち続けることが大切。 ◆大事な点 ◆のびしろ ▶ソフト開発者は主にアイデアを形にする部分に重心を置いている。 ユーザーニーズへの理解を向上させ「ニーズ×技術＝新しい魅力」を、 さらに発展させたい。 ユーザーに寄り添う開発のまとめ
48. 48 © FURYU Corporation. ユーザに寄り添う プロセス
49. 49 © FURYU Corporation. プリ開発に関わるチーム 企画チーム デザインチーム ※これ以外にもチームはありますが、本発表に関わるチームだけ書いています。 ※複数人を表しているだけで、正確な人数を表す図ではありません。 ハードチーム ソフトチーム ひとつのコンセプトを 全員でつくる プリ開発に必要な専門チームが集結し 全員でプリをつくる ひとつのコンセプトを軸に 意見を出し合い、開発を進めている
50. 50 © FURYU Corporation. プリの開発スケジュールの大枠 発 売 生 産 開 始 コ ン セ プ ト 検 討 ソ フ ト ウ ェ ア チ ー ム 参 入
51. 51 © FURYU Corporation. プリの開発スケジュールの大枠 発 売 生 産 開 始 コ ン セ プ ト 検 討 ソ フ ト ウ ェ ア チ ー ム 参 入 期間中の開発目的
52. 52 © FURYU Corporation. プリの開発スケジュールの大枠 発 売 生 産 開 始 コ ン セ プ ト 検 討 ソ フ ト ウ ェ ア チ ー ム 参 入 期間中の開発目的
53. 53 © FURYU Corporation. スクラムに近い開発プロセス ソフト進捗 れんらく会 全体進捗 ふりかえり 昼礼 ユーザー ヒアリング 開発 開発したプリ タスク一覧 ヒアリングスケジュール ハードスケジュール 課題一覧
54. 54 © FURYU Corporation. スクラムに近い開発プロセス ソフト進捗 れんらく会 全体進捗 ふりかえり 昼礼 ユーザー ヒアリング 開発 開発したプリ タスク一覧 ヒアリングスケジュール ハードスケジュール 課題一覧 スプリント バックログ プロダクト バックログ デイリー スクラム インクリメント スプリント レビュー スプリント レビュー レトロスペクティブ スプリント プランニング
55. 55 © FURYU Corporation. スクラムに近い開発プロセス ソフト進捗 れんらく会 全体進捗 ふりかえり 昼礼 開発 開発したプリ タスク一覧 ヒアリングスケジュール ハードスケジュール 課題一覧 ユーザー ヒアリング
56. 56 © FURYU Corporation. れんらく会 全体進捗 ユーザー ヒアリング 開発したプリ ふりかえり 開発したプリはユーザーヒアリングで評価 ユーザーヒアリングは主に企画チームが対応 プレイ中の様子、プレイ後のインタビューは 中継され、観察することができる 毎週、ヒアリング 開発者全員がユーザーに近く 良い意見も悪い意見も直接聞ける 開発のモチベーション向上 POINT
57. 57 © FURYU Corporation. れんらく会 全体進捗 ユーザー ヒアリング リ ふりかえり れんらく会は 全員で次を決める ユーザーヒアリングの結果を共有 次に向けて改善する内容を決める ターゲットとする ユーザーヒアリングの日程を決める 改善案を決める人がその場にいる 次への行動が早い POINT
58. 58 © FURYU Corporation. れんらく会 全体進捗 ユーザー ヒアリング リ ふりかえり 全体進捗は 方向性やチーム間の調整 全体進捗は各チームのリーダーが集まり、 チームの課題共有や、チーム間の納期を調整 責任と権限を持った人がその場にいる 決定が早い POINT
59. 59 © FURYU Corporation. ソフト進捗 全体進捗 れんらく会 昼礼 ヒアリング ゲーム大会 生産向け確認 開発 開発したプリ ふりかえり 一週間で何を作るか、どう作るかを決定する 誰と誰が協力するのか モジュール間のIFはどうするのか 開発前に曖昧をできるだけ取り除く MTGが終わると、一週間のタスク一覧が完成 ヒアリングスケジュール ハードスケジュール 課題一覧 タスク一覧 ソフト進捗は 何をどう作るか決定 全員で解決するタスクについて話し合い 計画の透明性を向上 POINT
60. 60 © FURYU Corporation. 全体進捗 れんらく会 昼礼 ヒアリング ゲーム大会 生産向け確認 開発 開発したプリ タスク一覧 ふりかえり 開発中は15分間の昼礼を毎日実施 全体連絡と以下を中心に共有 昨日やったこと、今日やること。困っていること 進捗確認ではなく、 チームがゴールに向かっているかを確認 ュール ール 昼礼で問題発見！ 短いけど大切な時間 検査・適応の最小単位 軌道修正してゴールを目指す POINT
61. 61 © FURYU Corporation. 全体進捗 れんらく会 ヒアリング ゲーム大会 リ ふりかえり 一週間の働き方をふりかえる 個人、チーム、プロセス、ツール、など についてふりかえる ふりかえり自体もふりかえっており 独自のふりかえりフレームワークも誕生 ▶独自のフレームワークはのちほど紹介 ふりかえりで 開発をより良くする 自分たちでプロセスを作ることで チームに対するオーナーシップ向上 POINT
62. 62 © FURYU Corporation. ハードウェアに寄り添う 開発
63. 63 © FURYU Corporation. ハードウェアに関わる開発 ハードウェアに関わる 開発は大きく3つ ハードウェアに寄り添う開発 LED ペン ①ゲーム中のハードウェア制御 ②生産工程で使用する機能開発 ③新規部材の検証
64. 64 © FURYU Corporation. ハードウェアの開発がベース 発 売 生 産 開 始 キ ッ ク オ フ コ ン セ プ ト 検 討 ソ フ ト ウ ェ ア 開 発 チ ー ム 参 入 • 「生産」という絶対的な納期がある • 計画段階から仕様変更が少ない • プロジェクト開始時に 各マイルストーンから逆算した スケジュールを立てる。 ハードウェアの開発をベースに 全体の計画を考える
65. 65 © FURYU Corporation. 混ぜて計画して、チームで開発 発 売 生 産 開 始 キ ッ ク オ フ コ ン セ プ ト 検 討 ソ フ ト ウ ェ ア 開 発 チ ー ム 参 入 ユーザーヒアリングを軸にした 変化させるスケジュール 生産のマイルストーンを守る スケジュール 1つのチームで開発できる
66. 66 © FURYU Corporation. 「ユーザーに寄り添う」 「ハードウェアに寄り添う」 を混ぜる
67. 67 © FURYU Corporation. タスクの制約を意識したコントロール スコープ：開発する機能 リソース：開発する人やお金 スケジュール：納期 変更できる情報と変更できない情報 どこに制約があるか把握する プロジェクトの多くは 三角形の1辺が固定される スコープ スケジュール リソース プロジェクト管理の三角形
68. 68 © FURYU Corporation. ユーザーに寄り添う開発 リソースとスケジュールを固定 スコープ スケジュール リソース スコープ(開発する機能)を調整 ヒアリングの日程は変わらない 開発チームの人数も基本的に変わらない 作る機能を調整 タスクの制約を意識したコントロール
69. 69 © FURYU Corporation. スコープ スケジュール リソース リソースを調整 作る機能は変わらない スケジュールも基本的に変わらない 開発する人数を調整 ハードに寄り添う開発 スコープとスケジュールは固定 タスクの制約を意識したコントロール
70. 70 © FURYU Corporation. ユーザーヒアリング ハードウェア スコープ スケジュール リソース スコープ スケジュール リソース タスクの制約を意識したコントロール 調整でコントロールしきれないこともあり まだまだ課題の多い領域 タスクのコントロール
71. 71 © FURYU Corporation. ユーザーヒアリング ハードウェア スケジュール リソース スコープ スケジュール リソース スコープ ハードウェアのリソースを増やすには ユーザーヒアリングのスコープを小さくする タスクのコントロール タスクの制約を意識したコントロール
72. 72 © FURYU Corporation. ユーザーヒアリング ハードウェア スケジュール リソース スコープ スケジュール リソース ハードウェアのリソースを増やすには ユーザーヒアリングのスコープを小さくする タスクのコントロール タスクの制約を意識したコントロール スコープ
73. 73 © FURYU Corporation. ユーザーヒアリング ハードウェア スコープ スケジュール リソース スコープ スケジュール リソース ハードウェアのリソースを増やすには ユーザーヒアリングのスコープを小さくする タスクのコントロール タスクの制約を意識したコントロール
74. 74 © FURYU Corporation. ユーザーヒアリング ハードウェア スコープ スケジュール リソース スコープ スケジュール リソース タスクのコントロール タスクの制約を意識したコントロール ハードウェアのリソースを増やすには ユーザーヒアリングのスコープを小さくする ユーザーヒアリング向けの対応が多い場合は スコープを小さくする
75. 75 © FURYU Corporation. ユーザーヒアリング ハードウェア スコープ スケジュール リソース スコープ スケジュール リソース POINT ハードウェアのリソースを増やすには ユーザーヒアリングのスコープを小さくする ユーザーヒアリング向けの対応が多い場合は スコープを小さくする いずれも、ユーザーヒアリングの スコープの調整が必要 タスクのコントロール タスクの制約を意識したコントロール
76. 76 © FURYU Corporation. 次のユーザーヒアリングまでに 新しいメイク機能を搭載したいです。 うーん。今のリソースを 考慮すると厳しそうだ。 なるほど、評価したいことは UIの操作性ですか？ いえ、新しいリップの色味がユーザーに 受け入れられるか見てみたいです。 じゃあ、デザインはそのままで 実際に描画されるリップの色味を 変えるでも良いですか？ はい！それで評価できます！ スコープ調整の一幕
77. 77 © FURYU Corporation. コミュニケーションを取り、要望の中から 「評価したい＆開発できる」を探す 「なぜ？」ではなく、 「評価したい部分はココですか」と質問する？ コミュニケーションをとる場が 定例であることも重要 (私たちはれんらく会) 評価したい＆開発できる 評価したいを開発する
78. 78 © FURYU Corporation. ▶発売日という期限が決まっている開発でも適応範囲を決めることで アジャイルに開発ができる。 ▶スコープ、リソース、スケジュール、 タスク毎に変更できる要素、変更できない要素を見極めて調整する。 ▶スコープの調整は「評価したいこと」を軸に「開発できる」と バランスをとって相談する。 ◆大事な点 ユーザーとハードウェアに 寄り添う開発のまとめ
79. 79 © FURYU Corporation. チームで作るソフトウェア開発
80. 80 © FURYU Corporation. ソフトチームはマトリックス型組織 ※複数人を表しているだけで、正確な人数を表す図ではありません。 リーダーグループ 画像処理グループ ゲーム制御グループ 落書きグループ • 商品軸とは別に技術軸のチーム • 技術チームの目的 – 技術の共有 画像処理のアルゴリズムを統一 ＵＩの統一など – 開発の相談 – 技術面の教育 … … … … … … チームの一体感を持ちつつ、 技術の間の連携が生まれる POINT
81. 81 © FURYU Corporation. スケジュールは複数の要素から一つの要素に ◆ソフトスケジュール ヒアリング スケジュール ハードスケジュール 開発 開発中に分かる 課題一覧
82. 82 © FURYU Corporation. スケジュールの計画を個からチームに変えた 今までは個人が 得意な領域のタスクを計画し、開発 考える範囲が担当ドメインに偏る お互いの状況が分かりにくい 個人スケジュールは隙間なく タスクで埋まっている Aさんの計画 Bさんの計画 助け合いが生まれにくい Aさんが開発 Bさんが開発
83. 83 © FURYU Corporation. チームとして必要な機能から計画 その結果、人ごとの作業量のムラができる 落書きが得意なAさんと画像処理が得意なBさん 週によっては忙しさのムラが生まれる チームの計画 作業量のムラ 担当者基準ではなく チームとして必要な計画 スケジュールの計画を個からチームに変えた
84. 84 © FURYU Corporation. 作業量のムラ チームで開発 助け合いが生まれやすい 意識が個人からチームに変わる チームとして必要な機能から計画 その結果、人ごとの作業量のムラができる 担当者基準ではなく チームとして必要な計画 スケジュールの計画を個からチームに変えた
85. 85 © FURYU Corporation. 個人の得意分野を広げる施策 得意領域を 広げる仕組み
86. 86 © FURYU Corporation. スキルマップとペア育成 ▶技術力向上を目的にスキルマップを運用 ▶スキルマップはメンバーの保有スキルを 表形式に可視化したもの ▶スキルマップがあればチームのスキル バランスが可視化される ▶スキルは「C＋＋」や「Jenkins」のような 一般的な技術と、「画像処理」「カメラ制御」 「メイクアップ機能」などプリ開発に 必要なスキルも洗い出している ◆スキルマップ
87. 87 © FURYU Corporation. スキルマップとペア育成 ▶人ごとの成長度合いに応じた育成体制 が必要だと考えて、ペア育成を開始 ▶習得したいスキルから師匠を選定 ▶半年スパンで目標を立てる ▶目標を立てるときはスキルを習得した後の 効果を明確にする ◆ペア育成
88. 88 © FURYU Corporation. ペア/モブプロ と ペア/モブ設計 ◆ペア/モブ 効果 ▶有識者から初心者への教育、作業効率化 ▶悩んだ時に一緒に悩んでメンタルケア ▶内容の理解者が増え、負荷分散できる ◆ペア/モブ 活性化 ▶全員がペアモブの効果を認識 ▶ペア、モブのきっかけがある
89. 89 © FURYU Corporation. チームのパフォーマンスを高める施策 チームの パフォーマンスを 高める施策
90. 90 © FURYU Corporation. 進化するふりかえり ◆KPT KPT KJPT GTPA ▶Keep：続けたいこと ▶Problem：悪かったこと ▶Try：改善したいこと ◆KJPT ▶KPT + Joy ▶Joy：楽しかったこと ▶Good & New の考えを参考に追加 ▶仕事の中から楽しみを探すように設計
91. 91 © FURYU Corporation. 進化するふりかえり ◆GTPA KPT KJPT GTPA ▶G：Good、Great、頑張った ▶T：楽しかった ▶P：ぴえん、ぱおん、プロブレム ▶A：アイデア、案 事実だけでなく、感情も共有することで 言いたいことが言いやすい環境になる。 自分たちでプロセスを改善する事例を 作ることでチームを自分事として考えられる。 POINT
92. 92 © FURYU Corporation. コロナ禍を乗り切る分報 ◆コロナ禍を乗り切る分報 週報、日報のように報告を分単位で行う 毎日チームごとのチャンネルに 個人のスレッドを立てて 返信する形で書き込む テレワーク普及の以前よりも お互いの状況が分かるようになり ちょっとした困りごとにもリアクションできる ちょっといいですかコミュニケーションが オンラインでもとりやすい。 POINT
93. 93 © FURYU Corporation. まとめ
94. 94 © FURYU Corporation. まとめ ◆盛れるは普段の自分よりも良くなっていること ◆ユーザに寄り添う開発 ▶技術本位ではなく、ユーザーの欲しいを作る ▶ユーザーヒアリングの目的は 作った機能の評価 と ユーザーと開発者の感性を近づける ◆ハードに寄り添う開発 ▶ゴールから逆算で計画を立てる ▶計画が変わらないハードウェア開発をベースに計画する
95. 95 © FURYU Corporation. まとめ ◆「ユーザーに寄り添う」「ハードウェアに寄り添う」を混ぜる ▶ハードウェアの開発があっても 適応範囲を決めることでアジャイルな開発ができる ▶スコープ調整は「評価したい＆開発できる」を探す ▶個々ではなく、チームとして計画し、進める ▶個々のスキルアップ、チームのスキルアップ、 どちらも取り組んで柔軟な開発への対応力を高める
96. 96 © FURYU Corporation. まとめ 自分たちがベストだと思った瞬間 負けは始まる 常に学び続けること
97. 97 © FURYU Corporation.