Download as PDF, PPTX
不確実性と戦うチーム
- 1.
- 2.
- 3. Niwa Takeru （28） 都内某システムインテグレータ システムエンジニア 新規事業開発のお手伝いを 中心にお仕事してます。
- 4.
- 5.
- 6.
- 7.
- 8. Agenda ❏ 第一章：不確実性とちゃんと戦おう ❏ 第二章：リーン・スタートアップという戦略 ❏第三章：心理的安全性を持ったアジャイルなチーム ❏ 最終章：MVP開発活動記
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16. ① 手洗い→洗濯機といった機械化（60年前） 不確実性 時代の変化 の速さ 市場の 成熟 ニーズ 不明瞭さ ■ 作れば売れた時代 ■手動→機械化という 目に見えたニーズがある ■ 市場は未開であり 時代の変化は緩やか ■ 技術的不確実性はあるがビ ジネス的な不確実性は少な い 市場の成長と不確実性の変化
- 17. ② ペーパーレス化が目的なシステム（20年前） 不確実性 時代の変化 の速さ 市場の 成熟 ニーズ 不明瞭さ 市場の成長と不確実性の変化 ■ IT化自体が目的となる 市場の無知がある時代 ■IT化対象は目に見えた 作業で仕様は明白 ■ PJ管理上の不確実性はあ るがビジネス的な不確実性 は少ない
- 18. ③ 飽和状態にある高付加価値家電（10年前） 不確実性 時代の変化 の速さ 市場の 成熟 ニーズ 不明瞭さ 市場の成長と不確実性の変化 ■ 市場は飽和状態にある 一方で新規性が求められる ■顧客のニーズは多様化 ニーズ通りの機能でも 売れるとは限らない ■ ITよりは時代の変化が ゆるやかなのが救い ■ 不確実性はとても高い
- 19. 不確実性 時代の変化 の速さ 市場の 成熟 ニーズ 不明瞭さ ④ SaaS モノからサービスの時代へ（現在） 市場の成長と不確実性の変化 ■ 市場が想像もしていない イノベーションが必要 ■ 売切り型から従量課金型へ 継続的に新機能を提供する スピード感が求められる ■ 不確実性はとてつもなく 高い状態にある そして、 不確実性は増し続ける…
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 29.
- 30.
- 31. リーン・スタートアップの基本 Lean Startup 仮説 プロト タイプ データ 素早く構築する ■ MVP ■Public Cloud etc. 素早く計測する ■ 革新会計 ■ データ分析 etc. 素早く学ぶ ■ 顧客インタビュー ■ ピボット etc.
- 32. MVP (Minimum ViableProduct) 実用最低限の製品
- 33.
- 34.
- 35.
- 36. スライド作成間に合いませんでした ● 革新会計 ○ 単なる赤字・黒字ではなく、未来につながる成長率で測ろう ○計測指標は事業モデルごとに変わる ● データ分析 ○ データサイエンティストは、これからの時代必須 ○ Big Query, Tableau 等の登場で超多量データを扱える時代になった ● 顧客インタビュー ○ 先入観で判断しないで、顧客の声を聞こう ○ 顧客の声に疑問を持ち発言の背景を探る ● ピボット ○ 方向転換のこと（バスケットボール用語のピボットが由来） ○ ピボットまでの学びの中に転換先のヒントがある ○ 方向転換先は、顧客セグメント、市場、事業モデル等がある
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56.
- 57. Make your ownagility.
- 58.
- 59.
- 60.
- 61.
- 62.
- 63. Knowledge of TeamBuilding Person ● ジョハリの窓を意識した雑談 ● 性格診断の共有 ● 1 on 1 コーチング Technology Team ● 小さなチームを保つこと ● 仕掛り中での相談、相互レビュー ● ペア/モブ プログラミング ● 成功体験の明確化 Pizza Party ● マイクロサービス ● ドメイン駆動設計 ● Public Cloud, MBaaS ● CI/CD Tools, SaaS 心理的安全性 の向上
- 64. Step1 ジョハリの窓を意識した雑談 開放の窓 盲点の窓 秘密の窓未知の窓 自分は知っている 自分は気づいていない 他人は知っている 他人は 気づいていない 相互理解を促進する 雑談の内容はプライベートなくだらない話でよい
- 65.
- 66.
- 67.
- 68. Step3 1 on1 コーチング マネージャーは メンバーをサポートするのが役割 コーチングでは相手の思考の 整理役に徹し自発性を尊重する プライベートな悩みも 相談を受けられるような関係性へ マイクロマネジメントは行わない
- 69. Step3 1 on1 コーチング Output Person Tech Team 1 on 1 コーチング 信頼関係 の構築 主体性の向上 自己成長
- 70.
- 71.
- 72.
- 73.
- 74.
- 75. ペア/モブ プログラミング 知識共有 作業効率 ソロ ペアモブ 心理的安全性 意思決定
- 76.
- 77.
- 78. 成功体験の明確化 Pizza Party PizzaParty Output Pizza Tech Team
- 79.
- 80.
- 81.
- 82. Product Owner ScrumMaster Engineer UX Designer チーム構成 Engineer Data Scientist
- 83. MVPをいち早く届けるための技術選定 ※ 今回のMVPは製品版前の使い捨て前提 前提が変われば技術選定も変えるべき Webで開発 製品版ではiOSApp想定だが MVPでは工数が安いWebに Appleの審査も不要なため 即座にデプロイが可能 工数： 100 → 50 デリバリ： 1日 → 10秒 ドメイン駆動設計 ドメイン駆動とは業務知識を 元にシステム化する設計思想 従来のシステム駆動よりも 仕様変更に強い 工数： 100 → 80 MBaaSの活用 バックエンドサーバは作らず Mobile Backend as a Service 知見は0だったが技術調査を 含めてトライ 工数： 100 → 20
- 84.
- 85.
- 86.
- 87. 私のチームでのリーン・スタートアップ Lean Startup 仮説 プロト タイプ データ 素早く構築する ■ MVPの為の技術選定 ■iOS → Web ■ MBaaS Firebase ■ ドメイン駆動設計 素早く計測する ■ エンジニアは現地へ ■ Slack現地レポート ■ Dataは取りまくる 素早く学ぶ ■ 全員での振返り ■ 全員での仮説検討会
- 88.
- 89. 普段の業務で無駄と思うやつあります？ Discussion アジャイルソフトウェア開発宣言 プロセスやツールよりも 個人と対話を、 包括的なドキュメントよりも 動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 どうやって心理的安全性を高めましょう？ Lean Startup 仮説 プロト タイプ データ 心理的安全性
- 90.
- 91.
- 92.
- 93. Let’s refactor the SystemIntegrators