2021年10月に認定スクラムマスター研修を自腹で受講した時の報告書です。
認定スラクムマスター研修受講報告受講日: 2021年10月
View Slide
認定スクラムマスター研修について• アジャイルとスクラム• 認定スクラムマスター研修の概要• アジャイルのその後…
いきなりですが、質問です。
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(XtremeProgramming)クリスタルクリアカンバンマインドセット(抽象クラス) マインドセットを実践するためのフレームワーク(実装クラス)プロジェクト管理 あっさり GitHubも採用開発スタイル
アジャイルソフトウェア開発宣言が発表されたのは20年前なぜ今も受け入れられているのか？
アジャイルソフトウェア開発宣言で重要視されているマインドセット✤対面コミュニケーション個人同士の対話を通じて相互理解を深めることで、よりよいチームが作られる。✤実働検証動くソフトウェアを使って繰り返し素早く仮説検証をし、その結果から学ぶことがよりよい成果を生み出す。✤顧客とのWin-Win関係お互いの立場を超えて協働することにより、よりよい成果と仕事のやり方を作ることができる。✤変化を味方に顧客のニーズやビジネス市場の変化は事前計画を狂わす脅威ではなく、よりよい成果を生み出す機会と捉える。
15©NISSHO ELECTRONICS CORPORATION ALL RIGHTS RESERVED.ITの急速な発展により、顧客ニーズの変動は顕著になり（Volatility）社会環境の変化により、ビジネスの見通しが不確実になり（Uncertainty）グローバル化により、個人とコミュニティの接点が複雑になり（Complexity）それらが組み合わさる事で、前例が通用しない曖昧な世界となった（Ambiguity）計画主義の終わり、VUCA時代へ突入経験主義の台頭:不確実だからこそ何でも試す時代へ
アジャイルの「マインドセット」「12の行動原則」をスクラムではどのように実装したのか？2. スクラムの成果物1. スクラムチーム3. スクラムイベント+アクティビティ
プロダクトオーナー 開発者 スクラムマスター
プロダクトオーナー✤プロダクトのWHAT(どんな機能)とWHY(なぜ作るのか？)を担当✤プロダクトの価値の最大化に責任を持つ※プロダクトオーナーが方向性を決める✤プロダクトに１人必要で、複数人や委員会ではない※二人以上いると意思決定が遅れるのでアジャイルの良さが失われます✤プロダクトバックログの管理に責任を持つ※プロダクトバックログはざっくり言えばスクラムにおける要件定義みたいなもの(後述で説明します)✤ステークホルダーマネージメントrefs. スクラムマスター研修資料
開発者✤プロダクトのHOW(どうやって？)を担当✤ モノを作る✤ 肩書やサブチームはなし✤ 全員揃えばプロダクトを作れる能力が揃う（機能横断的=クロスファンクショナル）※少人数でチームを回すからこそ、意識するrefs. スクラムマスター研修資料
ref. 三菱UFJインフォメーションテクノロジー株式会社のインフラチームのアジャイル実践ジャーニー
スクラムマスター✤ スプリント計画会議の進行✤ スタンドアップミーティングの開催✤ 問題の解消✤ 振り返りの実施✤ プロダクトバックログのサポートrefs. https://asana.com/ja/resources/scrum-master→かっこよく言えば: サーバントリーダー※スクラムチームに奉仕をしながらスクラムを伝授する→悪く言えば: チームの雑用係？※直接チームの利益に結び付く役割ではない→支援職→開発(プログラミングや設計)は行わない※レビューなどは参加
スクラムマスター研修で実際にあった質問Q. スクラムマスターの工数を顧客に請求するためにどのように説明すればいいか？A. スクラムマスタというポジションを設けた方がよりチームがプロダクトに集中できる環境だと経験的にわかっている。その旨(ユースケース)を顧客に説明したらどうか。
こんなときにスクラムマスターは活躍するCase1) チームを兼任しているプロダクトオーナーが多忙のため、なかなか時間が取れない。そこでアプリケーションに埋め込んだユーザーのメトリクス情報を元にレポートを作成することで、次のプロダクトの方向性を決めるために必要な情報をプロダクトオーナーに提供した。Case2) 朝会で顔色の悪いメンバがいた。隣の席に座ってる親しい開発者曰く、独り言がいつもより多いとのこと。当の本人にチャットのDMで大丈夫？と聞くと彼女と喧嘩したそう。今日一日、当メンバの作業サポートと愚痴の聞き相手になることにした。
関係図経営&営業 開発現場プロダクトオーナースクラムマスター開発者ステークホルダーステークホルダーの干渉をブロック
プロダクトバックログプロダクトを作成するにあたっての要求事項を作る順番に並べたリスト✤ プロダクトゴールと言われる、プロダクトの目指す 姿に向かって やりたいことを一列にならべる※優先度が同じ要件が複数存在してはいけない✤ いわゆるスクラムにおける要件定義だが、 各プロダクトバックログアイテムの粒度は違う ※直近は詳細に、将来は簡素に。✤ この表の作成責任者はプロダクトオーナー ※必然的にステークホルダーや顧客と衝突する
プロダクトバックログには何が書いてあるか？ある企業では、以下のような内容をプロダクトバックログアイテムに含めているそうですが、チームよりまちまちです•解決すべき課題•ユーザーストーリー•プラットフォーム•KPI•リリース希望日•見積り•リスク•関係者•参照情報システムがユーザーにどのような価値をもたらすのかを示したもの。顧客目線を維持しつつ、開発するために利用する。『＜ビジネス価値＞のため<役割>として<機能や性能>がしたい』といったテンプレートであらわされる。例えば、ダイエットアプリでは…refs. https://www.ryuzee.com/faq/0029/「夜食を防止するために、深夜に冷蔵庫を開閉するとユーザーに警告する。それによって深夜にご飯を食べる罪深さをユーザーに思い出させる」
refs. SCRUM MASTER THE BOOK p.190を改変スプリントプランニング毎日の作業リリース判断可能なインクリメントデイリースクラム(朝会)要求プロダクトバックログスプリントバックログステークホルダースプリントレビューレトロスペクティブ(振り返り)開発プロダクトバックログリファインメントスプリント(2週間)リリース
refs. 【習得必須】5つのスクラムイベントの概要を簡単解説 |はじめてのスクラム開発 (do-scrum.com)
スクラムマスター研修で実際にあった質問Q. スプリントを2週間スプリントでスクラムに取り組んでいます。 スプリントの中では、要件定義→開発→テスト項目作成→テスト→ユーザー受け入れテスト→リリースの順番に進めていますが、ミニウォーターフォール型との違いが分かりません。どう進めたら良いでしょうか？A. スプリントをまたいで実施している仕掛中のタスクが複数あったり、テスト工程を一番最後にまとめて実施するようなプロジェクトを進めていませんか？スプリントでの作業の進め方 | Ryuzee.com
• 設計の肥大化• 見積り精度• 後半ほど高リスク(テストで問題が生じた場合直せない)• 計画の柔軟性がなくなる• 機能統合が終わらない• スプリントの途中で開発が終わった分だけリリースしたいと思ってもリリースできないし、ユーザーからのフィードバックも受けられないrefs. スクラムマスター研修資料
refs. スクラムマスター研修資料
スクラムマスター研修の概要• アジャイルとスクラム• 認定スクラムマスター研修の概要• アジャイルのその後…
認定スクラムマスター研修概要• アトラクタ社が主催している• スクラムに関する書籍を多数発行。アジャイル界隈では著名• 研修受講後、試験を受けることで認定スクラムマスターという資格を得ることができる• 研修の流れ• 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クッションを挟むことでハードウェアとソフトウェアを分離しているcontainerruntime
ハードウェア側の事情に左右されることなく、あらゆるものをソフトウェアエンジニアリングで対応する時代へ現代のシステムはあらゆるものに抽象化レイヤーが入っている
旧来の方式なら…ユーザー数の増加に伴い、システムの増強を考えています。下記リソースを新しく追加してください・HTTPサーバーのNginx x 3台・APIサーバーのKong x 3台・アプリケーションサーバー(Spring Boot) 多数・ベアメタルサーバー x 3台→インフラチーム&アプリケーションチームの折衝→サーバーリソースの準備、環境設定→サーバー間のネットワーキングの調整→アプリケーションのセットアップ等
Nutanix AHV + OpenShift(Kubernetes)なら…Manifestファイル(構成ファイル)の準備で終わりますapiVersion: v1kind: Podmetadata:name: dns-examplespec:containers:- name: testimage: 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 CuriousAbsence of Scrum”(Big Techの技術プロジェクトの進め方とスクラムの不思議な欠如)• アジャイルのマインドが成熟したチームにはスクラムというプロセスすら重いので、kanban等のさらに軽量なプロセスを使用する• エンジニアリングチームにPMという役職はない(スケジューリングなどはエンジニアの自己管理が鉄則)• 技術部隊へのサポートはTPM(テクニカルプログラムマネージャー)が担当。Uberの場合、技術者50人に対して1人の割合らしい(間接部門が小さい)
“How Big Tech Runs Tech Projects and the CuriousAbsence of Scrum”(Big Techの技術プロジェクトの進め方とスクラムの不思議な欠如)・スクラムの欠点を指摘するものではない メンバにアジャイルマインドが浸透しているので技術に全振り• Big Techではない従来企業の下記のケースでは依然有効• kitchen sink(台所の流し)チーム: 要件定義を最初から全て見出そうとして、その結果、要らなくなった要求を捨ててしまうチーム※アジャイルの原則は優先度によって粒度にメリハリをつけること/Agile サムライが出典• タックマンモデル(チーム形成のためのモデルで、アジャイルマインドが”形成期”や”混乱期”にあるチーム• デプロイの頻度を(数か月に一度から)数週間に一度に上げたい• 統一されたプロジェクト進捗報告(ex. JIRA)を上げたい
“How Big Tech Runs Tech Projects and the CuriousAbsence 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の原則(行動指針)
sssssssssssshhhhhhhhhh
k1low
leveragestech
hokaccha
colopl
takasehideki
route06
kojira
ikumatadokoro
tsukubachallenge
codenote
keiko713
rilmayer
marktimemedia
jrom
addyosmani
chriscoyier
paulrobertlloyd
jponch
panda_program
ufuk
holman
speakerdeck
tenderlove