SIVA Development Guide プロダクトに「価値」を届ける開発 Guide VERSION 1.0 2024/06/28 USE TEMPLATE Click 1

2 SIVA 開発の原理原則

3 アジャイル開発の原理原則を元に 「価値」を届けます SIVA 開発の原理原則 参考:アジャイルソフトウェア開発宣言 プロセスやツールよりも個人と対話 プロセスやツールも大事だが、 対話をより重要と考える 包括的なドキュメントよりも動くソフトウェア 契約交渉よりも顧客との協調 計画に従うことよりも変化への対応 ドキュメントも大事だが、 動くソフトウェアをまず提供する 契約やルールも大事だが、 顧客に合わせて協調する姿勢が重要 計画も大事だが、 「価値」にフォーカスする

4 アジャイル開発でプロダクトに 「価値」を届けます スプリント計画 Plan スプリントで次に何をする か？を計画する。 様々な部署の要望や課題を並 べて決める SIVA 開発の原理原則 実装 Doing 計画を実行する。 モブプロ等を用いて、チーム でスプリントゴールを目指す スプリントレビュー Check 社内・社外のユーザー・ス テークホルダーからフィード バックをもらう レトロスペクティブ Action スプリントで学んだ事を次の アクションとして決める

5 開発のこだわり 「価値」検証へこだわり、仮説からの検証の フィードバックループの仕組みを構築してます α Release Product Release Type フィードバックをもらうための プロトタイプリリース β Release 一部のユーザーにフィードバッ クをもらうためのリリース GA Release 一般ユーザーにフィードバック をもらうためのリリース 検証 フィードバック 検証 フィードバック 小さく始めて、実際に検証を行う プロセスを反復的に実践するために Product Release Type を定義して 組織内で浸透しています。 小さく反復的に価値を検証 YAGNI 原則 You ain't gonna need it 機能は実際に必要となるまでは 追加しないのが良い KISS の 原則 Keep it simple stupid シンプルで愚直にする。 必要な複雑さを避けてできる だけ簡潔な設計を心がける

6 開発のこだわり QCD を意識して、SaaS 開発に取り組みます Quality Cost Delivery CX Development SaaS はビジネスモデルであることを 理解して、中長期的なユーザーの 利益を考えながら、 開発計画を実施しています。 SaaS のバランスを取ったバックログ選び Sales,CX,Development の バランスが崩れると SaaS としての 価値が下がること理解して、 技術課題にも Just In Time で 対応していきます。 Sales,CX,Develop のバランスを均衡に Sales

7 約束 開発をする上での最低限の「約束」について

8 HRT の原則をもって全てに対応します 約束 Humility (謙虚) 他人の意見や指摘を素直に受け入れ て自分を改善していく心構え Respect (尊敬) 相手に対する思いやりを忘れずに 敬意をもって接して、 異見も聞き入れる姿勢 Trust (信頼) お互いに信頼しあい役割を任せる 協調関係 チーム事、自分事として捉えて他責にしない。 事実と意見を切り分ける 対話する姿勢を常に持って、感謝を忘れない 異見を聞き入れて本当の「心理的安全性」を エンジニアという肩書きを持った時点であなたはプロです 子供扱いをしません。大人として接します

9 約束 納期を組織と基本約束はしませんが、 開発組織としての目標は設定します Quality Cost Delivery 色々な開発現場で「納期が」という言い訳 に出会います。 これは目標を自分達で決めていないから だと捉えています。 スケジュールの手綱を自分たちで しっかり握り、コントロールして下さい。 重要なのは、「不確実性」を考慮して 小さくデリバリーをして組織に対して Delivery の信用貯金を貯めることです。 スケジュールの手綱は自分達で持つ 納期ドリブンの弊害 腐敗の進行が早くなる Product Development Team Feature の Release 目標 自分たちで決める

10 Large-Scale Scrum をベースとした開発サイク ルを採用していますが、Scrum にこだわりません 開発サイクル 参考: Less (Large-Scale Scrum) プロセスやツールよりも個人と対話 色々な開発現場で、Scrum の How についての不毛な議論が行われます。 アジリティ（Agility）とは 機敏性 敏しょう性 軽快さ であり、Scrum のプロセスの How に固執 することは Scrum の本質ではありません 動くソフトウェアを中心とした考え方、 動き方をしてください。 Scrum の How に固執しない 包括的なドキュメントよりも動くソフトウェア

11 価値を検証する前にオーバーエンジニアリング をしないで下さい 開発サイクル オーバーエンジニアリング 必要以上に複雑にしたり、現時点では不要な機能をあらかじめ組み込んだりすること YAGNI 原則 You ain't gonna need it 機能は実際に必要となるまでは 追加しないのが良い KISS の 原則 Keep it simple stupid シンプルで愚直にする。 必要な複雑さを避けてできる だけ簡潔な設計を心がける 小さく始めて、実際に検証を行うプロセスを 反復的に実践して下さい。 小さく反復的に価値を検証 計画 実装 ユーザーの フィードバック 結果の分析 価値のデリバリーサイクル 参考: 余計な「念のため」でプロジェクトが死に至る 「オーバーエンジニアリング」の問題とは？

12 アジャイル開発の役割とチーム

13 アジャイル開発の役割 アジャイル開発の役割とチーム Developers Developers Product Owner Developers Product Owner ステーク ホルダー Sales Manager CX Manager CEO サポーター 組織のみんな 開発グループ Unit Unit

14 一人のプロダクトオーナーと複数のチーム アジャイル開発の役割とチーム Developers Product Owner Developers Product Owner Developers プロダクトオーナーとチームという通常の Scrum チーム で編成をした場合、部分最適化に 走りやすい傾向があります。 それを防ぐためにプロダクトオーナーは一人にして プロダクト全体での最適化を目指します。 Unit Unit チーム単位で 個別最適化が発生する Product Dev Teams サイロ化 サイロ化を防ぐための１人のプロダクトオーナー

15 開発は全て Developer という肩書で 職能で分けません アジャイル開発の役割とチーム プロダクトをデリバリーをするためには、 Frontend も Backend、 データを見る力や Infra の知識等 多種多様な知識がないとプロダクトに デリバリーはできません。 Frontend,Backend。という職能で分けてチーム開発を 行った場合、選択したバックログの比重とメンバー構成で スピードがでないリスクがあります。 なので、全て肩書は Developer でフルスタックです。 但し、全ての能力に対して、完璧を求めていません。 最低限の能力を要するようにしてください。 Developers Product Owner Developers Product Owner Developers Unit Unit 組織の肩書とチームの肩書は別です

16 アジャイル開発 スプリント

17 一つのプロダクトバックログに複数のチーム スプリント計画 アジャイル開発 スプリント 実装 スプリントレビュー レトロスペクティブ Product Dev Unit1 Product Dev Unit2 直近 3 ヶ月分のロードマップやバックログをスプレッドシート で管理しています。 Jira は Sprint バックログ管理で利用しています。 Product バックログでプロダクト全体の管理(直近 3 ヶ月程度) Sprint バックログでSprint の管理(直近3 Sprint 程度) 管理粒度が違います。 Product バックログ と Jira

18 一つの Feature に複数の Unit スプリント計画 アジャイル開発 スプリント 実装 スプリントレビュー レトロスペクティブ Product Dev Unit1 Product Dev Unit2 Feature 1 Feature 2 Product Dev Unit1 Product Dev Unit2 Feature 1 機能単位でチーム担当範囲を分割すると、 分断が始まりサイロ化が発生しやすくなります。 なので常に分割ができる最大迄、同じ Feature に対して 複数の Unit で同時に取り組みます。 ただしFeature の分割の限界がきた場合は、 別のバックログを選択します。 チームのサイロ化を防ぐために

19 スプリント計画 1 スプリント計画 アジャイル開発 スプリント 実装 スプリントレビュー レトロスペクティブ 主にプロダクトバックログの Why What を事前に各 Unit の代表者と話し合い、 スプリントバックログの大枠を決めます。 見積もり等詳細等は決めずに Why と What の Goal を確認します。 Unit 代表者とプロダクトオーナーの事前計画 Product Owner プロダクト バックログ Unit Unit EM or TL EM or TL スプリント バックログ Why What を対話して バックログの説明を行う 次やるの これだな スプリント バックログ 次やるの これだな

20 スプリント計画 2 スプリント計画 アジャイル開発 スプリント 実装 スプリントレビュー レトロスペクティブ スプリント計画 1 でUnit の代表者と プロダクトオーナーで事前に話した プロダクトバックログをスプリント計画 2 では 各 Unit 単位で話し合い、スプリントバックログ を作成します スプリントバックログの Jira も Unit 単位で別々に管理します Unit で分かれて計画する Product Owner プロダクト バックログ Unit Unit Team Team スプリント バックログ 必要であれば説明 具体化 スプリント バックログ 具体化

21 実現可能な見積もりを各 Unit で作成してください アジャイル開発 スプリント STEP1 Sprint Cost 1 日 6 時間 + 急な MTG を等を差し 引いた時間でスプリントで実行できる コストを算出 STEP 2 Sprint Goal Sprint で達成したい Goal を明確に提 示をして、ゴール目線をチームで 合わせる STEP 3 Sprint Planing 1 Sprint につき、1.5 時間 - 2 時間 利用して、「ムダ・ムラ・ムリ」を 議論して、計画を立てます。 STEP 4 Sprint Approved Product Owner との了承事項を最終 チェックして Sprint を開始します。

22 デイリー朝会 スプリント計画 アジャイル開発 スプリント 実装 スプリントレビュー レトロスペクティブ 実装フェーズでは、Unit 別に行動をしますが 同じ Feature を選択しているので 時に協調しあいながらスプリントを進めていきます 各 Unit の特色を出しながらスプリントゴールを 目指して下さい 協調しあいながら実装フェーズへ Unit Product Dev Unit 別々に実施 Unit Product Dev Unit 昨日のやった、今日のやる、困った を各 Unit で共有

23 モブプログラミング等を用いて、チーム一丸で スプリントを達成させています スプリント 共同化 (Socialization) 表出化 (Externalization) 連結化 (Combination) 内面化 (Internalization) 創発 対話 システム 実践 モブプログラミング等で 共通の体験を作る 個人の暗黙知を言語化し ドキュメント化 異なる形式知を組み合わせて 新たな知を創出する 新たに得た形式知を 学習により体験する 暗黙知 形 式 知 形式知 暗 黙 知 多様な人種・バックグラウンドが 集まる開発組織でより活躍が できるように様々な 工夫して下さい 知識差分を埋め合うように スパイラルの ように絶えず 繰り返す

24 スプリントレビュー スプリント計画 アジャイル開発 スプリント 実装 スプリントレビュー レトロスペクティブ スプリントレビューでは Unit が合同して プロダクトの Feature 等を ステークホルダーやサポーター等から フィードバックをもらいます スプリントレビューの準備等も Unit で 協力して行います。 合同でスプリントレビュー Unit Unit Product Dev Unit Product Dev Unit Doen された Feature Doen された Feature プロダクト 動作可能な状態 動作可能な状態 デモデー (スプリントレビュー)

25 色々な部署や実際のユーザーからフィードバックをもら い、改善のフィードバックループを実現しています アジャイル開発 スプリント Sales セールス視点からのプロダクトへの フィードバック CX ユーザーの代弁者としてのプロダクト へのフィードバック ステークホルダー 事業者目線でのプロダクトへの フィードバック 健全なフィードバックを元に、 プロダクト開発を進めています

26 レトロスペクティブ スプリント計画 アジャイル開発 スプリント 実装 スプリントレビュー レトロスペクティブ 日本人の完璧主義な国民性から KPT を実施すると できていない点やネガティブな事に フォーカスしがちです。 自発的な行動や自己学習は 感情的な楽しさやモチベーションから発生します。 対話で「気づく」事に フォーカスをして好きなワークショップをしてください KPT に縛られないで下さい Unit Product Dev Unit 別々に実施 Unit Product Dev Unit 次のスプリントでのカイゼン等を 話し合う

27 アジャイル開発 プロダクトマネジメント

28 アジャイル開発 プロダクトマネジメント QCD Quality Cost Delivery 参照:企業IT動向調査報告書 2022 組織規模が大きくなるに従って QCD 全ての確率は下がっていく つまり大きく作るとリスクが大きい 5 回作って 1 回しか成功しない 工期が予定通りに完了した確率 (2022 年 平均) 22.0 % 予算が予算範囲で収まった確率 (2022 年 平均) 25.13 % 予定した品質に達した確率 (2022 年 平均) 16.2 % QCD の3 要素合計の成功確率 (2022 年 平均) 21.11 %

29 アジャイル開発 プロダクトマネジメント システム/ソフトウェア製品品質特性 システム/ソフトウェア製品品質 JIS X 25010:2013（IEC25010：2011） セキュリティ 機能適合性 性能効率性 互換性 使用性 信頼性 保守性 移植性 機能完全性 機能正確性 機能適切性 時間効率性 資源効率性 容量満足性 共存性 相互運用性 適切度認識性 習得性 運用操作性 ユーザエラー 防止性 ユーザインタ フェイス快美 性 アクセシビリ ティ 成熟性 可用性 障害許容性 (耐故障性) 回復性 機密性 インテグリ ティ 否認防止性 責任追跡性 真正性 モジュール性 再利用性 解析性 修正性 試験性 適応性 設置性 置換性 参照: IPA システム・ソフトウェア品質標準 SQuaRE シリーズの歴史と概要 今言っている品質は何の項目で 品質のストーリーと課題はあるのか？

30 アジャイル開発 プロダクトマネジメント 内部品質と外部品質 システム/ソフトウェア製品品質の分類 セキュリ ティ 機能適合性 性能効率性 互換性 信頼性 保守性 移植性 外部品質 内部品質 セキュリティ 内部品質が外部品質に影響する 依存 影響 外部品質は内部品質に依存して、 内部品質は外部品質に影響する。 ユーザーが目に見える外部品質を あげるためには、 内部品質をあげる事が重要。 内部品質が外部品質に影響する

31 アジャイル開発 プロダクトマネジメント ビルドトラップ シンプルで わかりやすい 機能が多くて 分かりづらい 参照: Amazon ソニーテレビリモコン 参照: Amazon Fire TV Stick 第3世代 日本製の TV が海外で売れなくなった 一つの要因で 追加しすぎたリモコンのボタンで ユーザーは分かりづらかった。 機能を足せば売れるわけでは ない。 機能を足せば足すほど満足度は下がる

32 アジャイル開発 プロダクトマネジメント フィードバックループ 仮説 仮説 検証 合っているかも？ 間違いかも？ GA Release 一般ユーザーにフィードバックを もらうためのリリース β Release 一部のユーザーにフィードバックをも らうためのリリース α Release フィードバックをもらうための プロトタイプリリース フィードバックを積み重ねる もう少し仮説を 進めてみる 合っているかも？ 間違いかも？ endless… 全ての施策は「仮説」です。 つまり失敗した場合、破壊が できるかどうか？ がポイントです。 「作り込む」のではなく、 「壊しやすくする」事を 開発で心がけて下さい。 破棄しやすいように

33 小さな失敗をいつまでも行っていこう。 それがやがて成功になるから Let's make small mistakes forever. Because it will eventually become a success.