コーディング以外のエンジニアリング / About Engineering Without Coding

2019年7月17日に株式会社イグニスで行われた Matching Dev Meetup #4 での登壇資料です。
https://matching-dev-group.connpass.com/event/133322/

* 工学 - 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

Transcript

1. コーディング以外の エンジニアリング Matching Dev Meetup #4 @株式会社イグニス :1
2. :2 Tomohiro Imaizumi - @imaizume Androidユーザー歴8年のiOS開発者 株式会社Diverse : Poiboy iOS版 株式会社UZUMAKI 今⽇の⼀⾔: iOSDC 2019登壇決定 ⾃⼰紹介
3. :3 本⽇のテーマ :「エンジニアリング」ですが… そもそも「エンジニアリング」とは?? 類似の質問:「デザイン」とは? → 模範解答:『問題解決』
4. :4 「エンジニアリング(=⼯学)」の辞書的定義 جૅՊֶΛ޻ۀੜ࢈ʹԠ༻͢ΔͨΊͷֶ໰ɻ
   ػց޻ֶɾ౔໦޻ֶɾిࢠ޻ֶͳͲͷ΄͔ɺਓؒ޻ֶͳͲͦͷݚڀํ๏Λ ԉ༻ͨࣗ͠વՊֶҎ֎ͷ෼໺ͷ΋ͷʹ΋͍͏ɻ https://dictionary.goo.ne.jp/jn/72060/meaning/m0u/⼯学/ なんか難しそう、理解しにくい ⼯学（こうがく）の意味 - goo国語辞書
5. :5 「エンジニアリング組織論への招待」より 広⽊⼤地 (2018) 『エンジニアリング組織論への招待』 技術評論社 ΤϯδχΞϦϯάͱ͸ɺͭ·Δͱ͜Ζ ʮ࣮ݱʯ͍ͯͨ͘͠ΊͷՊֶ෼໺ͱ
   
   ͍͑ΔͰ͠ΐ͏ɻ
   தུ
   ͭ · Γ ɺ ʮ ᐆ ດ ͞ ʯ Λ ݮ Β ͠ ɺ
   
   
   
   
   
   
   
   
   
   
   ʮ۩ମੑɾ໌֬͞ʯΛ૿΍͢ߦҝ͕ ʮΤϯδχΞϦϯάͱ͸Կ͔ʯͱ͍͏ ౴͑Ͱ΋͋ΔͷͰ͢ɻ エンジニアリングとは 「実現のための科学」「曖昧さを減らすための⾏為」
6. :6 「曖昧さを減らす」⾏為 • 仕様決定 • コード記述 • リリース • ログ集計・計測 • 意思決定 • ⾔語化 • 可視化 • 図式化 専⾨技術が必要 (ハード) エンジニアリングには必ずしも 「専⾨技術が必要」なわけではない 専⾨技術が不要 (ソフト)
7. :7 本⽇の内容 コーディングではない 3つのエンジニアリングの話 1. 意思決定の材料を揃える 2. ⾔語化・可視化する 3. イニシアチブを取る
8. :8 意思決定の材料を揃える
9. :9 (チームでの)意思決定場⾯ • 課題に対する解決⽅法 • 施策やタスクの実施順序・実現⽅法 • 新しい何かにチャレンジする判断 良い意思決定に必要なこと • 認識差異をなくす(ビジネス&プロダクト間等) • 選択肢を増やす(別の⽅法でも実現できるかも) • リソース状態の把握(リソース有限やること無限)
10. :10 もしこんな状態だったら… 仕様決定者と実装者が別 各⾃の持つ仕事量が⾒えない 優先度と期⽇だけが書かれたタスクリスト
11. :11 実は…昔のPoiboyチームの状態 仕様決定者と実装者が別 各⾃の持つ仕事量が⾒えない 優先度と期⽇だけが書かれたタスクリスト 実際に使われていたタスク管理⽤スプレッドシート iOSだけで独⾃に⾏っていた⼯数⾒積もり [PM & プランナー] 仕様とスケジュール決め [関係者] 仕様の伝達 (と相談) [開発者] デザインと実装 ⼯数は労働時間でカバー 実装は開発速度優先
12. 仕様決定者と実装者が別 各⾃の持つ仕事量が⾒えない 優先度と期⽇だけが書かれたタスクリスト 実際に使われていたタスク管理⽤スプレッドシート iOSだけで独⾃に⾏っていた⼯数⾒積もり [PM & プランナー] 仕様とスケジュール決め [関係者] 仕様の伝達 (と相談) [開発者] デザインと実装 ⼯数は労働時間でカバー 実装は開発速度優先 :12 何が問題か • より良い実現⼿段を提案不可 • ⽬的に沿っているか検証不可 • ⾃分たちの能⼒を認知できない • ⼯数不⾜はパイを無理に⼤きくしてカバー • 優先度の基準が曖昧 • ⼿段とリソースが変化に対応しにくい 実現に継続性がなく曖昧さも残ったまま
13. :13 施策仕様決定に開発者も参加 ベロシティ計測 全員の⾒える場所に貼り出されたタスク スプリントバックログ バーンダウンチャート [全員] 施策の書き起こし [全員] 実現⽅法の提案・修正 [全員] 緊急重要度マップと⾒積もり ⾒積もり精度の向上 持続的な開発 現在のPoiboyでのスクラムの様⼦ 緊急重要度マップ
14. :14 施策仕様決定に開発者も参加 ベロシティ計測 全員の⾒える場所に貼り出されたタスク スプリントバックログ バーンダウンチャート [全員] 施策の書き起こし [全員] 実現⽅法の提案・修正 [全員] 緊急重要度マップと⾒積もり ⾒積もり精度の向上 持続的な開発 緊急重要度マップ 得られたもの • より良い実現⼿段を提案可能 • 実現⽅法を全員で考えるように • チームやメンバーの能⼒を把握可能に • 費⽤対効果の認識がメンバー間で⼀致 • 優先度の基準が明確に • 前後のコンテキストも全てオープン 継続性効率性が⽣まれ曖昧さが減った!!
15. :15 振り返ると… スクラム開発の導⼊ = よりよい実現と曖昧さを減らす作業 正しいエンジニアリングをするには スクラム開発をツールとして正しく理解する スクラムの各タスクを「なぜ」するのか思い出す
16. :16 ⾔語化・可視化
17. :17 可視化・⾔語化が必要な場⾯ • 数字の羅列やコードから情報を抽出する時 • コンセプトや仕様の定義・確認時 • 突発的な⼝頭コミュニケーション発⽣時 ⾔語化・可視化も曖昧さを減らす⾏為の1つ
18. :18 昔話 データ選択・表現上の問題 • 朝会で数字のリストを⾒ながら話す • ツールがスプレッドシートしかなかった • KPIに必要なデータがない 現在 • ツールを活⽤しながら可視化を推進 • lookerやFirebaseの導⼊ • 施策時にログ送信と計測を習慣化
19. :19 タスクの⼀覧 2年前 現在
20. :20 朝会・施策検討で⾒るデータ 2年前 現在 (久々に開いたらChromeがフリーズした)
21. :21 朝会・施策検討で⾒るデータ 2年前 現在 (久々に開いたらChromeがフリーズした) 数値の可視化は曖昧さを削減する = エンジニアリングの1つ
22. :22 ⼝頭コミュニケーションでの問題 • 記録に残らない • 論点が整理されない 広⽊⼤地 (2018) 『エンジニアリング組織論への招待』 技術評論社 ࢲ͸҉ࢉ͕͋·ΓಘҙͰ͸ͳ͍ͷͰɺܻಉ࢜ͷ͔͚ࢉΛ͢Δ৔߹ɺ චࢉΛ͠ͳ͍ͱղ͘͜ͱ͕Ͱ͖·ͤΜɻ
    தུ
    ͱ͜Ζ͕ɺ࢓ࣄ΍ਓੜͷ໰୊ͱ͍ͬͨʮ͔͚ࢉʯΑΓ໌Β͔ʹ೉͍͠ ໰୊Ͱɺ͠͹͠͹චࢉͤͣʹղ౴Λ୳ͯ͠͠·͍·͢ɻͦͷචࢉʹ͋ ͨΔ͜ͱΛख఻͏ͷ͕ɺϝϯλʔͷ໾ׂͰ͢ɻ
23. :23 業務でのコミュニケーション 新しいポップアップを 出す条件どうする?? カードをスワイプしたら もっと滑らかに⼤きくしてほしい ダイアログでOFFを選んだかか ポップアップで未選択の⼈に表⽰したい スクロールのスピードが 不安定なので直してほしい GitHubとTrelloの運⽤が よくわからないです… (QA担当者) (デザイナー) (デザイナー) (PM&エンジニア) (PM&エンジニア&QA)
24. :24 業務でのコミュニケーション 新しいポップアップを 出す条件どうする?? カードをスワイプしたら もっと滑らかに⼤きくしてほしい ダイアログでOFFを選んだかか ポップアップで未選択の⼈に表⽰したい スクロールのスピードが 不安定なので直してほしい GitHubとTrelloの運⽤が よくわからないです… (QA担当者) (デザイナー) (デザイナー) (PM&エンジニア) (PM&エンジニア&QA) 会話の参加者にしか⾒えない曖昧な情報を オープンで具体的な情報に変える
25. :25 図式化やフレームワークでの整理 直感的に理解でき論点がまとまる
26. :26 図式化やフレームワークでの整理 直感的に理解でき論点がまとまる ⾔語化 + 図式化 = ドキュメント を書くのもエンジニアリング
27. :27 デザイナーによる⾔語化 https://note.mu/yuaono/n/n8720ac1c66a5 【Poiboy】アプリのコンセプト⽂をチューニングした話｜Yu Aono｜note 具体的な⾔葉や評価軸を使い コンセプトへの曖昧な認識を統⼀
28. :28 イニシアチブを取る
29. :29 ⽬の前で問題が起きた時 • 宙に浮いたタスクが⾒つかったら • 朝会で突発的に議論が起こったら • ビジネスの⼈が判断に困っていたら
30. :30 イニシアチブを取ろう • タスクが進まない原因を調査し⾔語化する • フレームワークに意⾒を整理する • 必要なデータを定義してまとめる 知識や⼿段があっても ⾏使しなければやっていないのと同じ
31. :31 イニシアチブを取ろう • タスクが進まない原因を調査し⾔語化する • フレームワークに意⾒を整理する • 必要なデータを定義してまとめる 知識や⼿段があっても ⾏使しなければやっていないのと同じ 究極のエンジニアリング = ⾏動
32. :32 まとめ ✓意思決定の材料を揃える ✓ ⾔語化・可視化する ✓ イニシアチブを取る 「エンジニアリング」は誰にでも実践可能
33. :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