認定スラクム マスター研修 受講報告 受講日: 2021年10月

認定スクラムマスター研修について • アジャイルとスクラム • 認定スクラムマスター研修の概要 • アジャイルのその後…

いきなりですが、 質問です。

2020年度において 日本の500人月以上の 大規模プロジェクトが 予定した工期通りに 終わらなかった割合は 次のうち、どれでしょうか？ A) 5% B) 15% C) 30%

D) 50.6% refs.日本情報システム・ユーザー協会(JUAS) 企業IT動向調査報告書2021　

期限を遵守できた 割合 期限を遵守できな かった割合 プロジェクトが 大きくなるほど 工期が遅れる 工期遵守状況

プロジェクト が難航する 理由 プロジェクトが難航した要因 回答者の割合 ユーザーが非協力的(Lack of User Input) 12.80% 不完全な要件定義&仕様書 12.30% 要件定義&仕様書の変更 11.80% 経営層のサポートの欠如 7.50% 技術力の無さ 7.00% リソース不足 6.40% 現実離れした期待感 5.90% 不明確な目標 5.30% 非現実的なスケジュール 4.30% 新技術 3.70% その他 23.00% The Standish Group CHAOS Reports (1994)

要件定義不足はプロジェクト完了後の システムトラブルにもつながる

そもそもユーザーに使われない機能は要件定義を満たしていると言えるのか？ refs. スクラムマスター研修資料

プロジェクトを成功させたい 要件定義の策定を成功させたい ウォーターフォールに則り 要件定義の方法論を 頑張って精緻化する refs.要求工学知識体系(REBOK) そもそも要件定義をプロジェク トの最初に一括で作りこむ既存 の手法は無理があるのでは？

プロジェクトを成功させたい 要件定義の策定を成功させたい ウォーターフォールに則り 要件定義の方法論を 頑張って精緻化する refs.要求工学知識体系(REBOK) そもそも要件定義をプロジェク トの最初に一括で作りこむ既存 の手法は無理があるのでは？ 2001年、既存の開発手法では駄目だと考えた先進的な開発者が集う ↓ 各自、俺が考えた理想の開発手法を発表 ↓ まとまらなかったのでアジャイルソフトウェア開発宣言という マインドセット(お気持ち)を発表 ↓ スクラムはこのマインドセットを実装した手法の一つ

スクラムとアジャイルの関係 アジャイルソフトウェア開発宣言と宣 言の裏にある原則 スクラム XP(Xtreme Programming) クリスタルク リア カンバン マインドセット (抽象クラス) マインドセットを実践 するための フレームワーク (実装クラス) プロジェクト管理 あっさり GitHubも採用 開発スタイル

アジャイルソフトウェア開発宣言が 発表されたのは20年前 なぜ今も受け入れられているのか？

アジャイルソ フトウェア開 発宣言で重 要視 されているマ インドセット ✤対面コミュニケーション 個人同士の対話を通じて相互理解を深めること で、よりよいチームが作られる。 ✤実働検証 動くソフトウェアを使って繰り返し素早く仮説検証を し、その結果から学ぶことがよりよい成果を生み 出す。 ✤顧客とのWin-Win関係 お互いの立場を超えて協働することにより、よりよ い成果と仕事のやり方を作ることができる。 ✤変化を味方に 顧客のニーズやビジネス市場の変化は事前計画 を狂わす脅威ではなく、よりよい成果を生み出す 機会と捉える。

15 ©NISSHO ELECTRONICS CORPORATION ALL RIGHTS RESERVED. ITの急速な発展により、顧客ニーズの変動は顕著になり（Volatility） 社会環境の変化により、ビジネスの見通しが不確実になり（Uncertainty） グローバル化により、個人とコミュニティの接点が複雑になり（Complexity） それらが組み合わさる事で、前例が通用しない曖昧な世界となった（Ambiguity） 計画主義の終わり、VUCA時代へ突入 経験主義の台頭: 不確実だからこそ何でも試す時代へ

アジャイルの「マインドセット」「12の行動原則」をスク ラムではどのように実装したのか？ 2. スクラムの 成果物 1. スクラム チーム 3. スクラムイベント +アクティビティ

アジャイルの「マインドセット」「12の行動原則」をスク ラムではどのように実装したのか？ 2. スクラムの 成果物 1. スクラム チーム 3. スクラムイベント +アクティビティ

プロダクトオーナー 開発者 スクラムマスター

プロダクトオーナー ✤プロダクトのWHAT(どんな機能)とWHY(なぜ作るのか？)を担 当 ✤プロダクトの価値の最大化に責任を持つ ※プロダクトオーナーが方向性を決める ✤プロダクトに１人必要で、複数人や委員会ではない ※二人以上いると意思決定が遅れるのでアジャイルの良さが失われます ✤プロダクトバックログの管理に責任を持つ ※プロダクトバックログはざっくり言えばスクラムにおける要件定義みたいなもの(後述 で説明します) ✤ステークホルダーマネージメント refs. スクラムマスター研修資料

開発者 ✤プロダクトのHOW(どうやって？)を担当 ✤ モノを作る ✤ 肩書やサブチームはなし ✤ 全員揃えばプロダクトを作れる能力が揃う（機 能横断的=クロスファンクショナル） ※少人数でチームを回すからこそ、意識する refs. スクラムマスター研修資料

ref. 三菱UFJインフォメーションテクノロジー株式 会社のインフラチームのアジャイル実践ジャー ニー

スクラムマスター ✤ スプリント計画会議の進行 ✤ スタンドアップミーティングの開催 ✤ 問題の解消 ✤ 振り返りの実施 ✤ プロダクトバックログのサポート refs. https://asana.com/ja/resources/scrum-master →かっこよく言えば: サーバントリーダー ※スクラムチームに奉仕をしながらスクラムを伝授する →悪く言えば: チームの雑用係？ ※直接チームの利益に結び付く役割ではない →支援職 →開発(プログラミングや設計)は行わない ※レビューなどは参加

スクラムマスター研修で実際にあった質問 Q. スクラムマスターの工数を顧客に請求するために どのように説明すればいいか？ A. スクラムマスタというポジションを設けた方が よりチームがプロダクトに集中できる環境だと 経験的にわかっている。その旨(ユースケース)を 顧客に説明したらどうか。

こんなときにスクラムマスターは活躍する Case1) チームを兼任しているプロダクトオーナーが多忙のため、なかなか時間が 取れない。そこでアプリケーションに埋め込んだユーザーのメトリクス情報を元に レポートを作成することで、次のプロダクトの方向性を決めるために必要な情報を プロダクトオーナーに提供した。 Case2) 朝会で顔色の悪いメンバがいた。隣の席に座ってる親しい開発者曰く、独 り言がいつもより多いとのこと。当の本人にチャットのDMで大丈夫？と聞くと彼女 と喧嘩したそう。今日一日、当メンバの作業サポートと愚痴の聞き相手になること にした。

関係図 経営&営業 開発現場 プロダクトオーナー スクラムマスター 開発者 ステークホルダー ステークホルダーの 干渉をブロック

アジャイルの「マインドセット」「12の行動原則」をスク ラムではどのように実装したのか？ 2. スクラムの 成果物 1. スクラム チーム 3. スクラムイベント +アクティビティ

プロダクトバックログ プロダクトを作成するにあたっての要求事項を作る順番に並べたリスト ✤ プロダクトゴールと言われる、 プロダクトの目指す 姿に向かって 　やりたいことを一列にならべる ※優先度が同じ要件が複数存在してはいけない ✤ いわゆるスクラムにおける要件定義だが、 　各プロダクトバックログアイテムの粒度は違う 　※直近は詳細に、将来は簡素に。 ✤ この表の作成責任者はプロダクトオーナー 　※必然的にステークホルダーや顧客と衝突する

プロダクトバックログには何が書いてあるか？ ある企業では、以下のような内容をプロダクトバックログアイテムに含めて いるそうですが、チームよりまちまちです •解決すべき課題 •ユーザーストーリー •プラットフォーム •KPI •リリース希望日 •見積り •リスク •関係者 •参照情報 システムがユーザーにどのような価値をもたらすのかを示 したもの。顧客目線を維持しつつ、開発するために利用す る。 『＜ビジネス価値＞のため<役割>として<機能や性能>がし たい』といったテンプレートであらわされる。 例えば、ダイエットアプリでは… refs. https://www.ryuzee.com/faq/0029/ 「夜食を防止するために、深夜に冷蔵庫を開閉するとユー ザーに警告する。それによって深夜にご飯を食べる罪深さを ユーザーに思い出させる」

アジャイルの「マインドセット」「12の行動原則」をスク ラムではどのように実装したのか？ 2. スクラムの 成果物 1. スクラム チーム 3. スクラムイベント +アクティビティ

refs. SCRUM MASTER THE BOOK p.190を改変 スプリント プランニング 毎日の作業 リリース判断可能な インクリメント デイリー スクラム (朝会) 要求 プロダクト バックログ スプリント バックログ ステークホルダー スプリント レビュー レトロスペクティブ (振り返り) 開発 プロダクト バックログ リファインメント スプリント(2週間) リリース

refs. 【習得必須】5つのスクラムイベントの概要を簡単解説 | はじめてのスクラム開発 (do-scrum.com)

スクラムマスター研修で実際にあった質問 Q. スプリントを2週間スプリントでスクラムに取り組んでいます。 ス プリントの中では、要件定義→開発→テスト項目作成→テスト→ ユーザー受け入れテスト→リリースの順番に進めていますが、ミニ ウォーターフォール型との違いが分かりません。どう進めたら良い でしょうか？ A. スプリントをまたいで実施している仕掛中のタスクが複数あった り、テスト工程を一番最後にまとめて実施するようなプロジェクトを 進めていませんか？ スプリントでの作業の進め方 | Ryuzee.com

• 設計の肥大化 • 見積り精度 • 後半ほど高リスク (テストで問題が生じた場合直せない) • 計画の柔軟性がなくなる • 機能統合が終わらない • スプリントの途中で開発が終わった分だけ リリースしたいと思ってもリリースできない し、ユーザーからのフィードバックも受けら れない refs. スクラムマスター研修資料

refs. スクラムマスター研修資料

アジャイルの「マインドセット」「12の行動原則」をスク ラムではどのように実装したのか？ 2. スクラムの 成果物 1. スクラム チーム 3. スクラムイベント +アクティビティ

スクラムマスター研修の概要 • アジャイルとスクラム • 認定スクラムマスター研修の概要 • アジャイルのその後…

認定スクラムマスター研修概要 • アトラクタ社が主催している • スクラムに関する書籍を多数発行。アジャイル界隈では著名 • 研修受講後、試験を受けることで認定スクラムマスターという資格を 得ることができる • 研修の流れ • 1日目: 座学 • 2日目: ワークショップ • 3日目: 振り返り • ワークショップは5人x4チーム=20名 • フルリモート

どんな人たちが研修を受講していたか？ • 既に現場でスクラムを実践していて、より改善するための学び を得るために受講している方が多かった • 参加者のウェブアプリケーションを運営しているユーザー企業 もいれば、SIerも...

ここが良かった • スクラムなんも知らんから、ちょっとワカルになれた • Slackで質問すればなんでも回答してくれるフレンドリーさ • 講師の吉羽さん(@ryuzee)がスクラムに関する色々な情報 を公開してることを知った • スクラムに登場する様々な考え方、手法を実践しながら学 べた

例えばワークショップにて…

スクラムに則ってチームで ペーパープロダクト (アプリの画面)を作り、 レビューに臨みました

1回目のスプリントレビュー 説明が機能に偏ってる ユーザーが何を期待して このアプリを使いたくなるのかわから ない だが、松岡修造が 食事の内容に突っ込むという コンセプトは面白い このアプリは 食事を管理します 食事を写真に撮っ てうんたらかんたら … 受講生 講師&他の受講生

一回目のレビューの結果はさ んざんだった。 レビューのやり方も 改善しなくては… だが、松岡修造だけは ウケてたぞ？

2回目のスプリントレビュー 受講生 講師&他の受講生 これは ジョークアプリです 深夜に飲食店に近 寄ると松岡修造が 叱りに来ます 人を笑わせるという コンセプトがわかり やすい 松岡修造最強() 使いたくなるし ダイエットにも 繋がる

ここが良かった • 要件定義は、ユーザーのフィードバックにより簡単に 変わるし、そこに迅速に柔軟に適応していくことがア ジャイルだという実感を得られた • 松岡修造というキャラクターは、一発ネタで終わるかと 思ったが、実際はチームのメンタル管理などスクラムマ スターのロールにも深く結びつく存在 (チームで一体感を得る材料になった)

偉大なスクラム像 自分のチーム・組織 がよりアジャイルにな るためには？

ワークショップだけで完結するわけではない • スクラムを実践するための経験値が足りることはな い。改善あるのみ ※既にスクラムを現場で実践している人が認定スクラムマスター研 修を受講するモチベーションに。 • プロダクトバックログ、レトロスペクティブ(振り返り)、 タスクの見積もり方法(プランニングポーカー)等、概 要レベルから実践レベルへ挑戦したいことは正直多 い

認定スクラムマスター研修の概要 • アジャイルとスクラム • 認定スクラムマスター研修の概要 • アジャイルのその後…

認定スクラムマスター研修から 発展した話として アジャイルが浸透した 今後について語ります。

1. アジャイルがインフラ チームにやってきた ら？

現代のシステムはあらゆるものに抽象化レイヤーが入っている ハイパーバイザ
 (VMWare ESXiなど)
 ハードウェア ハイパーバイザ型
 ホストOS (Linux Kernel)
 ハードウェア コンテナ型
 ゲストOS
 (Kernel)
 ミドルウェア
 bin/libs
 VM
 App
 App
 ゲストOS
 (Kernel)
 ミドルウェア
 bin/libs
 VM
 App
 App
 ゲストOS
 (Kernel)
 ミドルウェア
 bin/libs
 VM
 App
 App
 ミドルウェア
 bin/libs
 コンテナ App
 App
 仮想ハードウェ ア 仮想ハードウェ ア 仮想ハードウェ ア ミドルウェア
 bin/libs
 コンテナ App
 ホストOS
 VMならハイパーバイザー、 コンテナなら Container Runtimeが OS等の影響に 1クッションを挟むことで ハードウェアとソフトウェアを 分離している container runtime


ハードウェア側の事情に左右されることなく、 あらゆるものを ソフトウェアエンジニアリングで対応する時代へ 現代のシステムはあらゆるものに 抽象化レイヤーが入っている

旧来の方式なら… ユーザー数の増加に伴い、 システムの増強を考えています。 下記リソースを新しく追加してください ・HTTPサーバーのNginx x 3台 ・APIサーバーのKong x 3台 ・アプリケーションサーバー(Spring Boot) 多数 ・ベアメタルサーバー x 3台 →インフラチーム&アプリケーションチームの折衝 →サーバーリソースの準備、環境設定 →サーバー間のネットワーキングの調整 →アプリケーションのセットアップ等

Nutanix AHV + OpenShift(Kubernetes)なら… Manifestファイル(構成ファイル)の準備で終わります apiVersion: v1 kind: Pod metadata: name: dns-example spec: containers: - name: test image: nginx # (中略) searches: - ns1.svc.cluster-domain.example - my.dns.search.suffix # (中略) • アプリチームはインフラチームに慮ることなく、 リソースの増強を行える • OpenShiftの仮想ネットワーク(CNI)&DNS機能により、 どのサーバーにアプリケーションがあるかをデプロイ時 に意識しない • コンテナ作成時にセットアップはほぼ完了 • 旧来のインフラチームはNutanixの物理レイヤー部分 にのみ、責任を持つ(責任分界点が変化) ※Manifestファイル側にcpuコア数やメモリ数の設定があり、 この辺はインフラ→アプリに責任を委譲したとも言える Manifestファイルの一例 圧倒的にスピードが向上

2. アジャイルのマインド が成熟したチームには スクラムすら不要な世 界が来る？

・Big Tech(GAFAやUber等情報産業の巨大企業)とその他のユーザー 企業の開発プロセスやチームにおけるロールの違いを解析した記事 • Big Techには… “How Big Tech Runs Tech Projects and the Curious Absence of Scrum” (Big Techの技術プロジェクトの進め方とスクラムの不思議な欠如) • アジャイルのマインドが成熟したチームにはスクラムというプロセスすら重い ので、kanban等のさらに軽量なプロセスを使用する • エンジニアリングチームにPMという役職はない (スケジューリングなどはエンジニアの自己管理が鉄則) • 技術部隊へのサポートはTPM(テクニカルプログラムマネージャー)が担当。Uber の場合、技術者50人に対して1人の割合らしい(間接部門が小さい)

“How Big Tech Runs Tech Projects and the Curious Absence of Scrum” (Big Techの技術プロジェクトの進め方とスクラムの不思議な欠如) ・スクラムの欠点を指摘するものではない 　メンバにアジャイルマインドが浸透しているので技術に全振り • Big Techではない従来企業の下記のケースでは依然有効 • kitchen sink(台所の流し)チーム: 要件定義を最初から全て見出そうとして、 その結果、要らなくなった要求を捨ててしまうチーム ※アジャイルの原則は優先度によって粒度にメリハリをつけること/Agile サムライが出典 • タックマンモデル(チーム形成のためのモデルで、アジャイルマインドが”形成 期”や”混乱期”にあるチーム • デプロイの頻度を(数か月に一度から)数週間に一度に上げたい • 統一されたプロジェクト進捗報告(ex. JIRA)を上げたい

“How Big Tech Runs Tech Projects and the Curious Absence of Scrum” (Big Techの技術プロジェクトの進め方とスクラムの不思議な欠如) FacebookのPMとして1年以上働いてるけど、チケットも タスクも作成したことはない。スプリントもしてないな。 FacebookのPMは、ビジョン、戦略、パートナーシップ に重点を置いている。プロジェクト管理やタスクにはあ まり力を入れていない。 エンジニアがほとんどのプロジェクト管理責任を負い、 自分でタスクを作成してるよ。 いいね！ …PMとは？

3. 将来的には全部アジャイ ルになるの？

Q. 将来的には全部アジャイルになるの？ A. そのようなことはないが、前向きに捉えよう • 内閣官房情報通信技術（IT）総合戦略室(政府CIOポータル)が出してるアジャイル開発実践ガイドによれ ば向いてない領域もある • 業務内容が明らかになっており、作って確認するという余地が少ない領域。 ※ただし、業務内容が明らかになっている領域であっても、具体的な UI（ユ ーザインタフェース）の部 分は、利用者からのフィードバックを得ながら構築するアジャイル開発が向いている場合もあり。 • 大規模な情報システム、業務内容等が極めて複雑、あるいはミッションクリティカルな(業務、サービス 提供上ほぼ一切の障害や誤作動が許されない) ケース • (個人的には最もミッションクリティカルなF-35戦闘機の内部システムでさえ、C2D2というアジャイ ル形式の開発形態を採用しているので、マインドの問題なだけも…) • ベンダ企業、ユーザー企業間のシステム開発に関する契約が障害になるケースもある • 基本的には準委任契約が大前提 • https://www.publickey1.jp/blog/20/ipa_1.html • 「アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと」と厚労省が疑義応答 集を公表してるぐらいなので、外堀は埋まりつつある • https://www.publickey1.jp/blog/21/agile_japan_2021.html →アジャイル開発に向いている・不向きな領域を留意した視座の広い開発方針 の採用を。

Q&Aタイム

✤顧客の満足を求め続ける ✤要求の本質を見抜き、変更を前向きに ✤成果物を2-3週間で、リリースし続ける ✤全員で共通の目標に向かおう ✤人の意欲は信頼から ✤コミュニケーションは直接対話で ✤進捗も品質も現物で ✤一定のペースでプロジェクトにリズムを ✤よい技術、よい設計、よい品質の追求 ✤ムダ＝価値を生まない、を探してヤメる ✤よいモノはよいチームから ✤自分たちのやり方を毎週、調整する アジャイルのマインドセットを実現するために、従うこ とが望ましい12の原則(行動指針)