C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 1 株式会社オプティム 技術統括本部 プラットフォームサービス開発部 和田 開発生産性を始める前に開発チームができること

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 2  ターゲット ◼ 新たに開発チームを立ち上げようとしている方 ◼ 0->1プロダクトフェーズで開発生産性がうまく導入できない方  話さないこと ◼ 開発生産性の評価指標の解説 ◼ OPTiM サスマネのプロダクト詳細 ◼ プロダクトフェージングの定義 本資料のターゲット

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 3  基本情報 ◼ 名前: 和田 ◼ 入社: 2018年に新卒入社 ◼ 担当: 現在はスクラムでいうプロダクトオーナー ◆ PMM(Product Marketing Manager)の担当者と二人三脚で担当中 ◼ 役割遍歴 1. Webフロントエンジニア 2. 開発リーダー 3. スクラムマスター 4. プロダクトオーナー(スクラム)  得意と興味関心 ◼ 0->1のプロダクトをローンチするのと、開発チーム作りを得意とする ◼ 組織論や心理学、プロダクトマネジメントをベースに開発組織へアプローチ ◼ 育成と開発スピードの両立は難しいなというのが最近の悩み 自己紹介 出典: 馬本寛子.GAFAでは常識!? 新職種「PMM」はPMと何が違うのか、SmartHRに聞いた【前編】.CORAL. 2020-10-22.https://coralcap.co/2020/10/product-marketing-manager/

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 4 開発生産性を始める前に開発チームができること

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 5  開発生産性は「誰が」発言するかで意味が異なる ◼ 経営 視点 ◆ 売上: ビジネス成果への貢献、組織全体への貢献 ◼ PdMやEM 視点 ◆ 付加価値生産性: 顧客満足度(NPS)、市場での競争力 ◼ 開発チーム 視点 ◆ 物的生産性: コード量、バグ修正速度、機能追加の速度、テストカバレッジ、デプロイ頻度  開発生産性を評価する指標は色々あるらしい ◼ Four Keys ◼ SPACEフレームワーク ◼ エビデンスベースドマネジメント(EBM) 開発生産性は曖昧な表現で難しい よし、開発生産性の指標を今日から取り入れよう！ 一方で、「今」プロダクトチームに効率化が受け入れられる状態なのか、見極める必要がある

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 6 とある記事に出会う 出典:吉羽 龍太郎.【資料公開】価値創造と開発生産性.Ryuzee.com.2024-06-28.https://www.ryuzee.com/contents/blog/14592

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 7 0->1のプロダクトは、開発生産性による効率化の前に不確実性が沢山存在 事業計画 顧客要望 プロダクト バックログ 開発チーム 成果物 PdM ミッション/ビジョンが不足しており、 正しい優先度が判断できていない。 結果、多機能で曖昧な製品ができあがる。 顧客課題をそのまま鵜呑みにする。 バーニングニーズを捉えきれていない。 能力の不足、属人化が深刻でメンバーの技量に差がある。 メンバー間での対話が少なく、開発することが目的になっている 大きなバックログアイテムで見積もりができない。 優先順位の根拠が誰もわからない 頑張って作ったのに、リリース後に不具合が見つかる。 営業からリリース内容は前もって知りたいと言われる。 過度な楽観主義で決められた数字。 市場と顧客への理解不足、競合の過小評価。 作りっぱなしのロードマップ 契約してきたから、来 月までに機能作って 営業Aさん プロダクトチーム全体に不確実性が存在する。 良い循環になるように、点ではなく面で不確実性への対応が必要。

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 8 0->1のプロダクトは、開発生産性による効率化の前に不確実性が沢山存在 開発チーム 成果物 最初にボトルネックになるのは (実体験的にも)デリバリーになることが多いため、 ここからカイゼンするのはとても良い！ こちらも一緒に考えていきたい。 ①もし開発チームがデリバリーに集中した場合のリスク ②開発チームが効率化を受け入れられる状態であるのか

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 9 ①もし開発チームがデリバリーに集中した場合のリスク PdM ボタンは機能の例ですが、顧客が求めているのは本当にその機能だったのだろうか？ 開発チームがデリバリーのHowに集中しすぎると、Whyが抜け落ちるリスクがある。 この新しいページにボタンを追加してください。 ユーザーがクリックすると、特定の機能が動作するようにしてほしいです。 PdM 次は、違うページにも似たようなボタンを追加してください。 少し違う動作をするように。 PdM あともう一つ、トップページにもボタンを追加して、 また別の動作をさせたいです。 PdM 了解です！ボタンを追加しました！(10日で実装できた) 開発チーム 了解です！ボタンを追加しました(5日で実装できた) 開発チーム もっと早く作ろう！！ 開発チーム

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 10 ②開発チームが効率化を受け入れられる状態であるのか 開発組織の皆さんへ 本番へのデプロイ頻度を 上げてください！ 形成期 チームの形成 チームできたばかりで、 本番環境がまだないが？ 開発チーム 混乱期 ぶつかり合い チームメンバー同士が 仲が悪くてそれどころではないが？ 開発チーム 機能期 チームとしての成果 かしこまり！ (ちょうどふりかえりで議論してたんだよね) 開発チーム 偉い人 開発チームの成長段階も考慮して、効率化を考えるのが良さそう

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 11 タックマンモデルとは、チーム結成から成果を生み出せる状態になるまで、 チームの成長段階を5つに分けたモデルのこと。 心理学者のブルース・W・タックマンが提唱しました。 タックマンモデル 形成期 チームの形成 混乱期 ぶつかり合い 統一期 共通の規範が形成 機能期 チームとしての成果 散会期 チームの解散 混乱期を早く脱して、機能期に持っていくことがスクラムマスターの腕の見せどころ

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 12  開発チームからみたときのプロダクトバックログ ◼ 製品版開発フェーズのとき: 顧客要望が少なく開発チームとPdMのバランスが釣り合っている ◆ 開発チームからみたとき、プロダクトバックログは良く整理されている。PdMと対話が出来ている。 ◆ ユーザーストーリーの仕様や優先度の変更が少ない。受け入れ基準は明瞭で、ものによっては技術的な不確実性の調査結果まで書いてある ◼ 製品版ローンチ後フェーズのとき: 顧客要望が多く開発チームとPdMのバランスが釣り合っていない ◆ 開発チームから見たとき、プロダクトバックログは以前よりメンテナンスされなくなっている。PdMと対話が減った。 ◆ ユーザーストーリーの仕様や優先度の変更が多い。受け入れ基準は不明瞭。 ⚫ 昨日見積もりしたユーザーストーリーとは、別のユーザーストーリーが高い優先度でいつの間にか積み上がっている 機能期となった開発チームが気をつけるべき視点 開発チームからは見えないところで、PdMがマーケットの不確実性対応にシフトしている。 良いプロダクトにするために、開発チームがディスカバリー領域も担えると良い。 プロダクトバックログの先が見えないため、開発チーム からはバランスが釣り合ってないことに気づかない

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 13 チーム成長と効率化の実体験

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 14 OPTiM サスマネ沿革 2024 3月 祝！！ 製品版リリース 2024 4月 機能リリース: 1回 パッチリリース: 3回 2024 5月 機能リリース: 3回 2024 7月 機能リリース: 2回 2023 12月 β版リリース 2023 9月 α版リリース 2024 6月 機能リリース: 3回 パッチリリース: 2回 2023 2024 2024 8月 機能リリース: 3回 パッチリリース: 1回 α版→β版→製品版をそれぞれ 3ヶ月のマイルストーンで 開発フェーズを進めてきた 機能リリースを月3回のペー スでリリースできている。 複数の連携先サービスと接続 する必要があり、複雑なプロ ダクトである。

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 15 どこも最初の始まりはふわっとしたイメージ、ここから不確実性を潰していく あなたが開発チームを編成するなら、 どのように不確実性と向き合い、チームを成長させますか？

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 16 開発体制の変化 プラットフォーム チーム (ウォーターフォール) Webアプリ チーム (スクラム) エージェント チーム (ウォーターフォール) アプリ開発(スクラム) プロダクト バックログ プロダクト バックログ プロダクト バックログ Aチーム Bチーム プロダクト バックログ エージェント チーム (ウォーターフォール) プロダクト バックログ アプリ開発(スクラム) Aチーム Bチーム プロダクト バックログ 23/07〜23/09 新機能開発 チーム (スクラム) サービス連携開発 チーム (ウォーターフォール) プロダクト バックログ プロダクト バックログ α版開発フェーズ 3領域で技術的な不確実性を解決し、 β版の本質的な開発着手可能な状態にする β版開発フェーズ お客様がトライアル開始できるMVPを作りきる 製品版開発フェーズ 製品版品質の提供とMLPの実現 製品版ローンチ後フェーズ 真の顧客課題を見極めて、 素早くリリースを行う 23/10〜23/12 24/01〜24/03 24/04〜 ユーザーストーリー ユーザーストーリー 機能チケット 機能チケット 機能チケット 機能チケット エピック ユーザーストーリー エピック 機能チケット 開発チームのマインドが、徐々に物的生産性から付加価値生産性にシフトしていった。

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 17 開発チームの成長 時間 形成期 チームの形成 混乱期 ぶつかり合い 機能期 チームとしての成果 統一期 共通の規範が形成 課題:他チームの成果物や進捗状況に関心がない 課題:結合を意識しておらず、 ローカル環境のみでしか動かない 課題:チーム文化が異なる開発チーム統合による混乱 課題:デプロイ作業の属人化、 特定の人しかデプロイできない 課題:BFFのOAS変更に伴う フロントエンドへの破壊的な変更 課題:完了の定義(DoD)が曖昧、 成果物は出てきたが実装漏れが多数 α版開発フェーズ 3領域で技術的な不確実性を解決し、 β版の本質的な開発着手可能な状態にする β版開発フェーズ お客様がトライアル開始できるMVPを作りきる 製品版開発フェーズ 製品版品質の提供とMLPの実現

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 18  α版開発フェーズ: 形成期から混乱期 ◼ 他のチームの成果物や進行状況に関心がない ◼ 結合を意識しておらず、ローカル環境のみでしか動かない ◆ モックでは動いてましたよ！@仮称Aさん  β版開発フェーズ: 形成期から統一期 ◼ チーム文化が異なるチーム統合による混乱 ◆ プラットフォームチームはウォーターフォール、Webアプリチームはスクラム ◼ デプロイ作業の属人化、特定の人しかデプロイができない  製品版開発フェーズ: 統一期から機能期 ◼ BFFのOAS変更に伴うフロントエンドへの破壊的な変更(属人化の影響) ◆ APIの負債返却でリファクタリングしたが、フロントへの影響度を考慮できなかった@仮称Bさん ◼ 完了の定義(DoD)が曖昧、成果物は出てきたが実装漏れが多数 ◆ スプリントレビューで実装漏れをPOから開発チームに指摘。受け入れ基準には記載がある  製品版ローンチ後フェーズ:機能期 ◼ ユーザーストーリーの受け入れ基準に技術仕様(バリデーション、初期描画状態…)のが限界に ◼ スプリントレビューで成果物に対するズレ ◆ 指摘してもこれ明日にリリースするんだよね？もっと事前にリリース内容確認したかったな@PMM 開発フェーズにおける発生課題と指標追加タイミングの実績 ストーリーポイント 指標追加タイミング North Star Metric(NSM) チームが うまく行っているか Net Promoter Score(NPS) デプロイ頻度 SLO OKR 個人が うまく行っているか ベロシティ テストカバレッジ 開発チームの成長段階を考慮して、指標を追加していく

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 19  α版開発フェーズ:形成期から混乱期 ◼ コミュニケーションツール整備  β版開発フェーズ:形成期から統一期 ◼ バザー形式のスプリントレビュー  製品版開発フェーズ:統一期から機能期 ◼ デュアルトラックアジャイル 各フェーズで実施した具体的な施策の紹介

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 20 [α版開発フェーズ:形成期から混乱期]コミュニケーションツール整備 全体告知系 all-xxx 自動通知系 info-xxx つぶやき系 random-xxx 依頼系 req-xxx チーム系 team-xxx 開発チーム内コミュニケーション: Slack

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 21 [α版開発フェーズ:形成期から混乱期]コミュニケーションツール整備 プロダクトチーム内の横断資料を配置: SharePoint プロダクトチーム内の横断コミュニケーション: Teams

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 22  スプリントレビューのアンチパターンを防ぎたい ◼ 顧客目線の欠如、目的と手段の逆転: なぜその機能を作っているか、開発者が説明できない ◼ 他チームとの断絶: プロダクトオーナーと開発チームだけで開催しているため、他チームが参加しずらい ◼ 普段のコミュニケーション不足: プロダクトオーナーによる進捗確認の場になりがち ◼ 継続的デプロイの不足: 参加者がアプリを触れない or 「ローカル環境なら動いています！」 [β版開発フェーズ:形成期から統一期]バザー形式のスプリントレビュー  当日までのスケジュール ◼ 全社にバザーを告知・案内 ◼ 開発チームで出し物を検討・準備  当日必要なモノ ◼ 展示用PC ◼ 周辺機器(モニター,キーボード,マウス)  当日の進め方 1. 5分 オープニング 2. 司会がタイムキーピングし、ブース移動の指示 3. 15分×3回 レビューを実施 ⚫ 参加者に触ってもらうことが大事 ⚫ 出し物次第で時間は適宜調整 4. 10分 フィードバック&質疑応答

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 23 [製品版開発フェーズ:統一期から機能期]デュアルトラックアジャイル(アレンジあり) プロダクト バックログ リリース プランニング スプリント プランニング 開発 スプリント レビュー スプリント レトロ スペクティブ デイリー スクラム リリース デザイン思考 課題を探索する リーン 適切なモノを構築する スクラム 適切にモノを構築する マーケット (顧客) 事業計画 (ロードマップ) 共感 テスト プロト タイプ アイデア 課題定義 ディスカバリー デリバリー 過剰なユーザーストーリー インタビュー エピック ユーザーストーリー MVP特定 (ユーザーストー リーマッピング) 参考文献: 市谷 聡啓.正しいものを正しくつくる.ビー・エヌ・エヌ新.2019.328p 参考文献: selmertsx.アジャイルとリーン・スタートアップを組み合わせた開発プロセス ( 施策立案編 ).はてなブログ.2020-07-27.https://selmertsx.hatenablog.com/entry/2020/07/27/アジャイルとリーン・スタートアップを組み合わ 参考文献: 角 征典.組み合わせで理解しよう「デザイン思考、リーン、アジャイル」by Jonny Schneider.medium.2018-3-5.https://medium.com/waicrew/組み合わせで理解しよう-デザイン思考-リーン-アジャイル-76b59988447f

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 24 クイックリファレンス 施策 形成期 チームが形成される 混乱期 ぶつかり合う 統一期 共通の規範が形成される 機能期 チームとして成果を出す コミュニケーションツール整備 ◯ インセプションデッキ ◯ GOOD＆NEW ◯ ミッション・ビジョン・バリュー ◯ ドラッカー風エクササイズ ◯ ◯ バリューズカード ◯ ◯ ワークショップ ◯ ◯ ◯ ファイブフィンガー ◯ ◯ ◯ スクラムイベント ◯ ◯ ◯ ◯ プランニングポーカー ◯ デリゲーションポーカー ◯ Working Agreement ◯ スクラムオブスクラム(SoS) ◯ ◯ むきなおり ◯ ◯ バザー形式のスプリントプランニング ◯ ◯ リリースプランニング ◯ デュアルトラックアジャイル ◯ OKR ◯

C O N F I D E N T I A L © 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 25  開発生産性を開発チームに直ぐに導入できたから苦労しない  ただし、0->1プロダクトで最初にデリバリーをカイゼンするのは良い ◼ 最初にデリバリーがネックになりがち ◼ こちらも一緒に考える必要がある ◆ もし開発チームがデリバリーに集中した場合のリスク: HowだけではなくWhyに気をつける ◆ 開発チームが効率化を受け入れる状態であるのか: タックマンモデルを活用した開発チームの成長を把握する  開発チームの成長度合いに応じて、少しずつ開発生産性の効率化を取り込むのがベスト まとめ

© 2019-2024 OPTiM Corp. All rights reserved. 26 26