Slide 1

Slide 1 text

コーディング以外の エンジニアリング Matching Dev Meetup #4 @株式会社イグニス :1

Slide 2

Slide 2 text

:2 Tomohiro Imaizumi - @imaizume Androidユーザー歴8年のiOS開発者 株式会社Diverse : Poiboy iOS版 株式会社UZUMAKI 今⽇の⼀⾔: iOSDC 2019登壇決定 ⾃⼰紹介

Slide 3

Slide 3 text

:3 本⽇のテーマ :「エンジニアリング」ですが… そもそも「エンジニアリング」とは?? 類似の質問:「デザイン」とは? → 模範解答:『問題解決』

Slide 4

Slide 4 text

:4 「エンジニアリング(=⼯学)」の辞書的定義 جૅՊֶΛ޻ۀੜ࢈ʹԠ༻͢ΔͨΊͷֶ໰ɻ ػց޻ֶɾ౔໦޻ֶɾిࢠ޻ֶͳͲͷ΄͔ɺਓؒ޻ֶͳͲͦͷݚڀํ๏Λ ԉ༻ͨࣗ͠વՊֶҎ֎ͷ෼໺ͷ΋ͷʹ΋͍͏ɻ https://dictionary.goo.ne.jp/jn/72060/meaning/m0u/⼯学/ なんか難しそう、理解しにくい ⼯学(こうがく)の意味 - goo国語辞書

Slide 5

Slide 5 text

:5 「エンジニアリング組織論への招待」より 広⽊⼤地 (2018) 『エンジニアリング組織論への招待』 技術評論社 ΤϯδχΞϦϯάͱ͸ɺͭ·Δͱ͜Ζ ʮ࣮ݱʯ͍ͯͨ͘͠ΊͷՊֶ෼໺ͱ ͍͑ΔͰ͠ΐ͏ɻ தུ ͭ · Γ ɺ ʮ ᐆ ດ ͞ ʯ Λ ݮ Β ͠ ɺ ʮ۩ମੑɾ໌֬͞ʯΛ૿΍͢ߦҝ͕ ʮΤϯδχΞϦϯάͱ͸Կ͔ʯͱ͍͏ ౴͑Ͱ΋͋ΔͷͰ͢ɻ エンジニアリングとは 「実現のための科学」「曖昧さを減らすための⾏為」

Slide 6

Slide 6 text

:6 「曖昧さを減らす」⾏為 • 仕様決定 • コード記述 • リリース • ログ集計・計測 • 意思決定 • ⾔語化 • 可視化 • 図式化 専⾨技術が必要 (ハード) エンジニアリングには必ずしも 「専⾨技術が必要」なわけではない 専⾨技術が不要 (ソフト)

Slide 7

Slide 7 text

:7 本⽇の内容 コーディングではない 3つのエンジニアリングの話 1. 意思決定の材料を揃える 2. ⾔語化・可視化する 3. イニシアチブを取る

Slide 8

Slide 8 text

:8 意思決定の材料を揃える

Slide 9

Slide 9 text

:9 (チームでの)意思決定場⾯ • 課題に対する解決⽅法 • 施策やタスクの実施順序・実現⽅法 • 新しい何かにチャレンジする判断 良い意思決定に必要なこと • 認識差異をなくす(ビジネス&プロダクト間等) • 選択肢を増やす(別の⽅法でも実現できるかも) • リソース状態の把握(リソース有限やること無限)

Slide 10

Slide 10 text

:10 もしこんな状態だったら… 仕様決定者と実装者が別 各⾃の持つ仕事量が⾒えない 優先度と期⽇だけが書かれたタスクリスト

Slide 11

Slide 11 text

:11 実は…昔のPoiboyチームの状態 仕様決定者と実装者が別 各⾃の持つ仕事量が⾒えない 優先度と期⽇だけが書かれたタスクリスト 実際に使われていたタスク管理⽤スプレッドシート iOSだけで独⾃に⾏っていた⼯数⾒積もり [PM & プランナー] 仕様とスケジュール決め [関係者] 仕様の伝達 (と相談) [開発者] デザインと実装 ⼯数は労働時間でカバー 実装は開発速度優先

Slide 12

Slide 12 text

仕様決定者と実装者が別 各⾃の持つ仕事量が⾒えない 優先度と期⽇だけが書かれたタスクリスト 実際に使われていたタスク管理⽤スプレッドシート iOSだけで独⾃に⾏っていた⼯数⾒積もり [PM & プランナー] 仕様とスケジュール決め [関係者] 仕様の伝達 (と相談) [開発者] デザインと実装 ⼯数は労働時間でカバー 実装は開発速度優先 :12 何が問題か • より良い実現⼿段を提案不可 • ⽬的に沿っているか検証不可 • ⾃分たちの能⼒を認知できない • ⼯数不⾜はパイを無理に⼤きくしてカバー • 優先度の基準が曖昧 • ⼿段とリソースが変化に対応しにくい 実現に継続性がなく曖昧さも残ったまま

Slide 13

Slide 13 text

:13 施策仕様決定に開発者も参加 ベロシティ計測 全員の⾒える場所に貼り出されたタスク スプリントバックログ バーンダウンチャート [全員] 施策の書き起こし [全員] 実現⽅法の提案・修正 [全員] 緊急重要度マップと⾒積もり ⾒積もり精度の向上 持続的な開発 現在のPoiboyでのスクラムの様⼦ 緊急重要度マップ

Slide 14

Slide 14 text

:14 施策仕様決定に開発者も参加 ベロシティ計測 全員の⾒える場所に貼り出されたタスク スプリントバックログ バーンダウンチャート [全員] 施策の書き起こし [全員] 実現⽅法の提案・修正 [全員] 緊急重要度マップと⾒積もり ⾒積もり精度の向上 持続的な開発 緊急重要度マップ 得られたもの • より良い実現⼿段を提案可能 • 実現⽅法を全員で考えるように • チームやメンバーの能⼒を把握可能に • 費⽤対効果の認識がメンバー間で⼀致 • 優先度の基準が明確に • 前後のコンテキストも全てオープン 継続性効率性が⽣まれ曖昧さが減った!!

Slide 15

Slide 15 text

:15 振り返ると… スクラム開発の導⼊ = よりよい実現と曖昧さを減らす作業 正しいエンジニアリングをするには スクラム開発をツールとして正しく理解する スクラムの各タスクを「なぜ」するのか思い出す

Slide 16

Slide 16 text

:16 ⾔語化・可視化

Slide 17

Slide 17 text

:17 可視化・⾔語化が必要な場⾯ • 数字の羅列やコードから情報を抽出する時 • コンセプトや仕様の定義・確認時 • 突発的な⼝頭コミュニケーション発⽣時 ⾔語化・可視化も曖昧さを減らす⾏為の1つ

Slide 18

Slide 18 text

:18 昔話 データ選択・表現上の問題 • 朝会で数字のリストを⾒ながら話す • ツールがスプレッドシートしかなかった • KPIに必要なデータがない 現在 • ツールを活⽤しながら可視化を推進 • lookerやFirebaseの導⼊ • 施策時にログ送信と計測を習慣化

Slide 19

Slide 19 text

:19 タスクの⼀覧 2年前 現在

Slide 20

Slide 20 text

:20 朝会・施策検討で⾒るデータ 2年前 現在 (久々に開いたらChromeがフリーズした)

Slide 21

Slide 21 text

:21 朝会・施策検討で⾒るデータ 2年前 現在 (久々に開いたらChromeがフリーズした) 数値の可視化は曖昧さを削減する = エンジニアリングの1つ

Slide 22

Slide 22 text

:22 ⼝頭コミュニケーションでの問題 • 記録に残らない • 論点が整理されない 広⽊⼤地 (2018) 『エンジニアリング組織論への招待』 技術評論社 ࢲ͸҉ࢉ͕͋·ΓಘҙͰ͸ͳ͍ͷͰɺܻಉ࢜ͷ͔͚ࢉΛ͢Δ৔߹ɺ චࢉΛ͠ͳ͍ͱղ͘͜ͱ͕Ͱ͖·ͤΜɻ தུ ͱ͜Ζ͕ɺ࢓ࣄ΍ਓੜͷ໰୊ͱ͍ͬͨʮ͔͚ࢉʯΑΓ໌Β͔ʹ೉͍͠ ໰୊Ͱɺ͠͹͠͹චࢉͤͣʹղ౴Λ୳ͯ͠͠·͍·͢ɻͦͷචࢉʹ͋ ͨΔ͜ͱΛख఻͏ͷ͕ɺϝϯλʔͷ໾ׂͰ͢ɻ

Slide 23

Slide 23 text

:23 業務でのコミュニケーション 新しいポップアップを 出す条件どうする?? カードをスワイプしたら もっと滑らかに⼤きくしてほしい ダイアログでOFFを選んだかか ポップアップで未選択の⼈に表⽰したい スクロールのスピードが 不安定なので直してほしい GitHubとTrelloの運⽤が よくわからないです… (QA担当者) (デザイナー) (デザイナー) (PM&エンジニア) (PM&エンジニア&QA)

Slide 24

Slide 24 text

:24 業務でのコミュニケーション 新しいポップアップを 出す条件どうする?? カードをスワイプしたら もっと滑らかに⼤きくしてほしい ダイアログでOFFを選んだかか ポップアップで未選択の⼈に表⽰したい スクロールのスピードが 不安定なので直してほしい GitHubとTrelloの運⽤が よくわからないです… (QA担当者) (デザイナー) (デザイナー) (PM&エンジニア) (PM&エンジニア&QA) 会話の参加者にしか⾒えない曖昧な情報を オープンで具体的な情報に変える

Slide 25

Slide 25 text

:25 図式化やフレームワークでの整理 直感的に理解でき論点がまとまる

Slide 26

Slide 26 text

:26 図式化やフレームワークでの整理 直感的に理解でき論点がまとまる ⾔語化 + 図式化 = ドキュメント を書くのもエンジニアリング

Slide 27

Slide 27 text

:27 デザイナーによる⾔語化 https://note.mu/yuaono/n/n8720ac1c66a5 【Poiboy】アプリのコンセプト⽂をチューニングした話|Yu Aono|note 具体的な⾔葉や評価軸を使い コンセプトへの曖昧な認識を統⼀

Slide 28

Slide 28 text

:28 イニシアチブを取る

Slide 29

Slide 29 text

:29 ⽬の前で問題が起きた時 • 宙に浮いたタスクが⾒つかったら • 朝会で突発的に議論が起こったら • ビジネスの⼈が判断に困っていたら

Slide 30

Slide 30 text

:30 イニシアチブを取ろう • タスクが進まない原因を調査し⾔語化する • フレームワークに意⾒を整理する • 必要なデータを定義してまとめる 知識や⼿段があっても ⾏使しなければやっていないのと同じ

Slide 31

Slide 31 text

:31 イニシアチブを取ろう • タスクが進まない原因を調査し⾔語化する • フレームワークに意⾒を整理する • 必要なデータを定義してまとめる 知識や⼿段があっても ⾏使しなければやっていないのと同じ 究極のエンジニアリング = ⾏動

Slide 32

Slide 32 text

:32 まとめ ✓意思決定の材料を揃える ✓ ⾔語化・可視化する ✓ イニシアチブを取る 「エンジニアリング」は誰にでも実践可能

Slide 33

Slide 33 text

:33 参考リンク • ⼯学 - Goo辞書 https://dictionary.goo.ne.jp/jn/72060/meaning/m0u/⼯学 • 広⽊⼤地 (2018) 『エンジニアリング組織論への招待』 技術評論社 https://amzn.to/2Lqmuui • 【Diverseエンジニア×Looker対談】データドリブンな会社を⽬指して、BIツール 「Looker」を導⼊! https://www.wantedly.com/companies/diverse-inc/post_articles/158192 • 【Poiboy】アプリのコンセプト⽂をチューニングした話|Yu Aono|note https://note.mu/yuaono/n/n8720ac1c66a5