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

by furyu-puri

Slide 1

Slide 1 text

1 © FURYU Corporation. ～ハードウェアも含めたアジャイル開発～『盛れる』をつくる開発プロセスフリュー株式会社井内聡

Slide 2

Slide 2 text

2 © FURYU Corporation. さっそくですが、

Slide 3

Slide 3 text

3 © FURYU Corporation. 『盛れる』知ってますか？

Slide 4

Slide 4 text

4 © FURYU Corporation. 【盛れる】 ◆意味普段の自分よりかわいくなったり、きれいになったということを表す言葉です ◆例文このプリ、めっちゃ盛れるよ

Slide 5

Slide 5 text

5 © FURYU Corporation. 井内聡自己紹介いうちさとし • 主な役割はソフトウェアに関わる部分の、計画と進行管理、課題の特定と解決、メンバーが開発しやすい仕組みづくり。 ◆役割プリントシール機ソフトウェアチームリーダー ◆働き方

Slide 6

Slide 6 text

6 © FURYU Corporation. INDEX プリのソフトウェア開発の特徴ユーザーに寄り添う開発プリのゲームハードウェアに寄り添う開発「ユーザーに寄り添う」「ハードウェアに寄り添う」を混ぜるユーザーに寄り添うプロセス 01 02 03 05 06 08 04 チームで作るソフトウェア開発の工夫 07 まとめ

Slide 7

Slide 7 text

7 © FURYU Corporation. プリのゲーム

Slide 8

Slide 8 text

8 © FURYU Corporation. プリの撮り方

Slide 9

Slide 9 text

9 © FURYU Corporation. プリの撮り方コインを入れたら画面をタッチしてスタート、好きなコースを選ぶゲームスタート

Slide 10

Slide 10 text

10 © FURYU Corporation. プリの撮り方一眼レフとストロボで本格撮影ポーズ誘導やガイダンスで失敗しにくいこだわり撮影

Slide 11

Slide 11 text

11 © FURYU Corporation. プリの撮り方多種多様なペンやスタンプリップやチークや涙ぶくろ多種多様な落書きでカスタマイズ自由に落書き

Slide 12

Slide 12 text

12 © FURYU Corporation. プリの撮り方シール出口からシールが印刷撮影したデータはケータイにも送信上手に盛れたかな出来上がり！

Slide 13

Slide 13 text

13 © FURYU Corporation. 似てるけど違うプリの特徴

Slide 14

Slide 14 text

14 © FURYU Corporation. 似てるけど違うプリの特徴 ◆特徴 • 瞳にアーチ状のキャッチライト • カメラの画角をユーザーが調整できるズーム機能 • 自分のこだわりを詰め込んだシールが作れるシール編集

Slide 15

Slide 15 text

15 © FURYU Corporation. 似てるけど違うプリの特徴 ◆特徴 • 約80万通りの組み合わせ「顔編集」 • 外装にインパクトを与えるサイネージ • 撮影準備タイム機能で撮影開始をユーザーが選べる

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

18 © FURYU Corporation. 似てるけど違うプリの特徴機種ごとにハードウェアが違う動かすカメラ、ズーム機構、など機種ごとにターゲットユーザーが違う多種多様なメイク、ゲームシーケンス、など実現するプロセスを紹介

Slide 19

Slide 19 text

19 © FURYU Corporation. プリのソフトウェア開発の特徴

Slide 20

Slide 20 text

20 © FURYU Corporation. 機種ごとにハードウェアが違う動かすカメラ、ズーム機構、など機種ごとにターゲットユーザーが違う多種多様なメイク、ゲームシーケンス、などプリ開発の2つの特徴

Slide 21

Slide 21 text

21 © FURYU Corporation. 問題を分類するためのフレームワーククネビンフレームワークで分類

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

26 © FURYU Corporation. プリの開発を分類複雑 (Complex) カオス（Chaotic）単純（Simple）煩雑 (Complicated) ◆煩雑(Complicated) ▶ 特徴解くべき問題は分かっているが、専門知識が必要。解決方法を特定すれば前に進む問題 ▶ 対処問題を分析、調査し、行動する。ウォーターフォールなアプローチが有効

Slide 27

Slide 27 text

27 © FURYU Corporation. 機種ごとにハードウェアが違う動かすカメラ、ズーム機構、など機種ごとにターゲットユーザーが違う多種多様なメイク、ゲームシーケンス、などプリの開発を分類

Slide 28

Slide 28 text

28 © FURYU Corporation. ユーザーに寄り添う開発は複雑複雑(Complex) ユーザーが何を喜んでくれるか分析だけでは答えは分からないアジャイルなアプローチ多種多様なメイク、ゲームシーケンス

Slide 29

Slide 29 text

29 © FURYU Corporation. ユーザーに寄り添う開発は複雑複雑(Complex) ユーザーが何を喜んでくれるか分析だけでは答えは分からないアジャイルなアプローチユーザーに寄り添う開発多種多様なメイク多種多様なメイク、ゲームシーケンス

Slide 30

Slide 30 text

30 © FURYU Corporation. ハードウェアに寄り添う開発は煩雑煩雑(Complicated) 高度な専門知識は必要だが解決すべき問題は明確ウォーターフォールなアプローチ動かすカメラ、ズーム機構

Slide 31

Slide 31 text

31 © FURYU Corporation. ハードウェアに寄り添う開発は煩雑ハードウェアに寄り添う開発 LED ペン煩雑(Complicated) 高度な専門知識は必要だが解決すべき問題は明確ウォーターフォールなアプローチ動かすカメラ、ズーム機構

Slide 32

Slide 32 text

32 © FURYU Corporation. プリの開発は2種類に分類できるユーザーに寄り添う開発ハードウェアに寄り添う開発 LED ペン多種多様なメイク

Slide 33

Slide 33 text

33 © FURYU Corporation. プリの開発は2種類に分類できるユーザーに寄り添う開発ハードウェアに寄り添う開発 LED ペン多種多様なメイクハードウェアに寄り添うウォーターフォール開発を行いながら、ユーザーに寄り添うアジャイル開発を実践

Slide 34

Slide 34 text

34 © FURYU Corporation. ～ハードウェアも含めたアジャイル開発～『盛れる』をつくる開発プロセス

Slide 35

Slide 35 text

35 © FURYU Corporation. ユーザに寄り添う開発

Slide 36

Slide 36 text

36 © FURYU Corporation. 技術を活かしたプリを開発初めに作った機種は似顔絵をシールにする機種強みだった顔認証技術を使って技術力で勝負自慢の技術を使って似顔絵をシールに出力技術者が自信をもって市場にリリースその結果は・・・

Slide 37

Slide 37 text

37 © FURYU Corporation. プレイ、されていない

Slide 38

Slide 38 text

38 © FURYU Corporation. 技術を活かしたプリを開発さらに似せるための努力をしたキャラっぽさを強くしたりリアルさを出したりより良い似顔絵が作れた！その結果は・・・技術力を磨いて似てるを突き詰める

Slide 39

Slide 39 text

39 © FURYU Corporation. それでもプレイ、されていない

Slide 40

Slide 40 text

40 © FURYU Corporation. ユーザーの声を聞くユーザーの声を聞こう関係会社の方に「ユーザーの声を聞いてみては？」とアドバイスをもらった経験はないが、チャレンジしてみた

Slide 41

Slide 41 text

41 © FURYU Corporation. ユーザーヒアリングの方法ユーザーの声を聞こうインタビューアは社員インタビューイはメインユーザの女子高生筐体をプレイしてもらい意見をもらう声を聞いて、分かった驚きの事実

Slide 42

Slide 42 text

42 © FURYU Corporation. 似てても、いらない

Slide 43

Slide 43 text

43 © FURYU Corporation. その体験から得たユーザーヒアリングの重要性

Slide 44

Slide 44 text

44 © FURYU Corporation. ユーザーヒアリングの重要性ユーザーはスペックに興味なしハートスタンプは人気だからといって、「ハートのスタンプ史上最高の搭載数」という機種では人気がでない技術者として分かりやすい数字で勝負せず、ユーザーが今求めているモノを探すユーザーの欲しいを技術に変換似顔絵は技術力の強さを発揮できる。しかし、いくら技術が優れても、ユーザーが必要としなければ、使われない。

Slide 45

Slide 45 text

45 © FURYU Corporation. 常に新しいをつくるためにユーザーと開発者の感性を近づけるトレンドは変わり続けるユーザーヒアリングが大切なことは変わらない学ぶことを怠ってはいけないユーザーと開発者の感性を近づける感性もインフラ絶え間なく整備する

Slide 46

Slide 46 text

46 © FURYU Corporation. ユーザーと開発者の感性を近づけるコロナ禍でユーザーヒアリングが出来ない時期も蓄積した感性で商品を作り、プレイされている ▼ ユーザーと開発者の感性が近いため、欲しいものが想像できているだからといって学ぶことを怠ってはいけない感性もインフラ絶え間なく整備する自分たちがベストだと思った瞬間負けは始まる

Slide 47

Slide 47 text

47 © FURYU Corporation. ▶ユーザーは新しい技術ではなく、新しい魅力を求めている。それを、探し続けるためにもユーザーと接点を持ち続けることが大切。 ◆大事な点 ◆のびしろ ▶ソフト開発者は主にアイデアを形にする部分に重心を置いている。ユーザーニーズへの理解を向上させ「ニーズ×技術＝新しい魅力」を、さらに発展させたい。ユーザーに寄り添う開発のまとめ

Slide 48

Slide 48 text

48 © FURYU Corporation. ユーザに寄り添うプロセス

Slide 49

Slide 49 text

49 © FURYU Corporation. プリ開発に関わるチーム企画チームデザインチーム ※これ以外にもチームはありますが、本発表に関わるチームだけ書いています。 ※複数人を表しているだけで、正確な人数を表す図ではありません。ハードチームソフトチームひとつのコンセプトを全員でつくるプリ開発に必要な専門チームが集結し全員でプリをつくるひとつのコンセプトを軸に意見を出し合い、開発を進めている

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

61 © FURYU Corporation. 全体進捗れんらく会ヒアリングゲーム大会リふりかえり一週間の働き方をふりかえる個人、チーム、プロセス、ツール、などについてふりかえるふりかえり自体もふりかえっており独自のふりかえりフレームワークも誕生 ▶独自のフレームワークはのちほど紹介ふりかえりで開発をより良くする自分たちでプロセスを作ることでチームに対するオーナーシップ向上 POINT

Slide 62

Slide 62 text

62 © FURYU Corporation. ハードウェアに寄り添う開発

Slide 63

Slide 63 text

63 © FURYU Corporation. ハードウェアに関わる開発ハードウェアに関わる開発は大きく3つハードウェアに寄り添う開発 LED ペン ①ゲーム中のハードウェア制御 ②生産工程で使用する機能開発 ③新規部材の検証

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

65 © FURYU Corporation. 混ぜて計画して、チームで開発発売生産開始キックオフコンセプト検討ソフトウェア開発チーム参入ユーザーヒアリングを軸にした変化させるスケジュール生産のマイルストーンを守るスケジュール 1つのチームで開発できる

Slide 66

Slide 66 text

66 © FURYU Corporation. 「ユーザーに寄り添う」「ハードウェアに寄り添う」を混ぜる

Slide 67

Slide 67 text

67 © FURYU Corporation. タスクの制約を意識したコントロールスコープ：開発する機能リソース：開発する人やお金スケジュール：納期変更できる情報と変更できない情報どこに制約があるか把握するプロジェクトの多くは三角形の1辺が固定されるスコープスケジュールリソースプロジェクト管理の三角形

Slide 68

Slide 68 text

68 © FURYU Corporation. ユーザーに寄り添う開発リソースとスケジュールを固定スコープスケジュールリソーススコープ(開発する機能)を調整ヒアリングの日程は変わらない開発チームの人数も基本的に変わらない作る機能を調整タスクの制約を意識したコントロール

Slide 69

Slide 69 text

69 © FURYU Corporation. スコープスケジュールリソースリソースを調整作る機能は変わらないスケジュールも基本的に変わらない開発する人数を調整ハードに寄り添う開発スコープとスケジュールは固定タスクの制約を意識したコントロール

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

76 © FURYU Corporation. 次のユーザーヒアリングまでに新しいメイク機能を搭載したいです。うーん。今のリソースを考慮すると厳しそうだ。なるほど、評価したいことは UIの操作性ですか？いえ、新しいリップの色味がユーザーに受け入れられるか見てみたいです。じゃあ、デザインはそのままで実際に描画されるリップの色味を変えるでも良いですか？はい！それで評価できます！スコープ調整の一幕

Slide 77

Slide 77 text

77 © FURYU Corporation. コミュニケーションを取り、要望の中から「評価したい＆開発できる」を探す「なぜ？」ではなく、「評価したい部分はココですか」と質問する？コミュニケーションをとる場が定例であることも重要 (私たちはれんらく会) 評価したい＆開発できる評価したいを開発する

Slide 78

Slide 78 text

78 © FURYU Corporation. ▶発売日という期限が決まっている開発でも適応範囲を決めることでアジャイルに開発ができる。 ▶スコープ、リソース、スケジュール、タスク毎に変更できる要素、変更できない要素を見極めて調整する。 ▶スコープの調整は「評価したいこと」を軸に「開発できる」とバランスをとって相談する。 ◆大事な点ユーザーとハードウェアに寄り添う開発のまとめ

Slide 79

Slide 79 text

Slide 80

Slide 80 text

80 © FURYU Corporation. ソフトチームはマトリックス型組織 ※複数人を表しているだけで、正確な人数を表す図ではありません。リーダーグループ画像処理グループゲーム制御グループ落書きグループ • 商品軸とは別に技術軸のチーム • 技術チームの目的 – 技術の共有画像処理のアルゴリズムを統一ＵＩの統一など – 開発の相談 – 技術面の教育 … … … … … … チームの一体感を持ちつつ、技術の間の連携が生まれる POINT

Slide 81

Slide 81 text

Slide 82

Slide 82 text

82 © FURYU Corporation. スケジュールの計画を個からチームに変えた今までは個人が得意な領域のタスクを計画し、開発考える範囲が担当ドメインに偏るお互いの状況が分かりにくい個人スケジュールは隙間なくタスクで埋まっている Aさんの計画 Bさんの計画助け合いが生まれにくい Aさんが開発 Bさんが開発

Slide 83

Slide 83 text

83 © FURYU Corporation. チームとして必要な機能から計画その結果、人ごとの作業量のムラができる落書きが得意なAさんと画像処理が得意なBさん週によっては忙しさのムラが生まれるチームの計画作業量のムラ担当者基準ではなくチームとして必要な計画スケジュールの計画を個からチームに変えた

Slide 84

Slide 84 text

84 © FURYU Corporation. 作業量のムラチームで開発助け合いが生まれやすい意識が個人からチームに変わるチームとして必要な機能から計画その結果、人ごとの作業量のムラができる担当者基準ではなくチームとして必要な計画スケジュールの計画を個からチームに変えた

Slide 85

Slide 85 text

Slide 86

Slide 86 text

86 © FURYU Corporation. スキルマップとペア育成 ▶技術力向上を目的にスキルマップを運用 ▶スキルマップはメンバーの保有スキルを表形式に可視化したもの ▶スキルマップがあればチームのスキルバランスが可視化される ▶スキルは「C＋＋」や「Jenkins」のような一般的な技術と、「画像処理」「カメラ制御」「メイクアップ機能」などプリ開発に必要なスキルも洗い出している ◆スキルマップ

Slide 87

Slide 87 text

87 © FURYU Corporation. スキルマップとペア育成 ▶人ごとの成長度合いに応じた育成体制が必要だと考えて、ペア育成を開始 ▶習得したいスキルから師匠を選定 ▶半年スパンで目標を立てる ▶目標を立てるときはスキルを習得した後の効果を明確にする ◆ペア育成

Slide 88

Slide 88 text

88 © FURYU Corporation. ペア/モブプロとペア/モブ設計 ◆ペア/モブ効果 ▶有識者から初心者への教育、作業効率化 ▶悩んだ時に一緒に悩んでメンタルケア ▶内容の理解者が増え、負荷分散できる ◆ペア/モブ活性化 ▶全員がペアモブの効果を認識 ▶ペア、モブのきっかけがある

Slide 89

Slide 89 text

Slide 90

Slide 90 text

90 © FURYU Corporation. 進化するふりかえり ◆KPT KPT KJPT GTPA ▶Keep：続けたいこと ▶Problem：悪かったこと ▶Try：改善したいこと ◆KJPT ▶KPT + Joy ▶Joy：楽しかったこと ▶Good & New の考えを参考に追加 ▶仕事の中から楽しみを探すように設計

Slide 91

Slide 91 text

91 © FURYU Corporation. 進化するふりかえり ◆GTPA KPT KJPT GTPA ▶G：Good、Great、頑張った ▶T：楽しかった ▶P：ぴえん、ぱおん、プロブレム ▶A：アイデア、案事実だけでなく、感情も共有することで言いたいことが言いやすい環境になる。自分たちでプロセスを改善する事例を作ることでチームを自分事として考えられる。 POINT

Slide 92

Slide 92 text

92 © FURYU Corporation. コロナ禍を乗り切る分報 ◆コロナ禍を乗り切る分報週報、日報のように報告を分単位で行う毎日チームごとのチャンネルに個人のスレッドを立てて返信する形で書き込むテレワーク普及の以前よりもお互いの状況が分かるようになりちょっとした困りごとにもリアクションできるちょっといいですかコミュニケーションがオンラインでもとりやすい。 POINT

Slide 93

Slide 93 text

Slide 94

Slide 94 text

94 © FURYU Corporation. まとめ ◆盛れるは普段の自分よりも良くなっていること ◆ユーザに寄り添う開発 ▶技術本位ではなく、ユーザーの欲しいを作る ▶ユーザーヒアリングの目的は作った機能の評価とユーザーと開発者の感性を近づける ◆ハードに寄り添う開発 ▶ゴールから逆算で計画を立てる ▶計画が変わらないハードウェア開発をベースに計画する

Slide 95

Slide 95 text

95 © FURYU Corporation. まとめ ◆「ユーザーに寄り添う」「ハードウェアに寄り添う」を混ぜる ▶ハードウェアの開発があっても適応範囲を決めることでアジャイルな開発ができる ▶スコープ調整は「評価したい＆開発できる」を探す ▶個々ではなく、チームとして計画し、進める ▶個々のスキルアップ、チームのスキルアップ、どちらも取り組んで柔軟な開発への対応力を高める