モルトケに学ぶアジャイル組織に必要なもの
"目的を達成する方法は、確実に前もって計画することはできない。"
"予見できる範囲を超えて計画を立てることは避けるのが賢明だ。"
"リーダーは自分自身で状況を判断しなければならず、全体的な意図と一致しつつも、独立して行動する方法を知っていなければならない。"
アジャイルソフトウェア開発宣言の発表から20年が経ち、アジャイルは一般的なものになってきました。しかし予測不可能な環境への適応方法として、アジャイルに似た考え方を提案した150年前の軍人がいました。
それはプロイセン陸軍参謀総長として知られるヘルムート・フォン・モルトケです。最初の引用はアジャイルに関する言葉でなく、モルトケが自身の戦術について語った言葉です。
この記事では、モルトケが考案した訓令戦術にとって重要な要素を理解し、アジャイル組織へのヒントとして活用することを目指します。
訓令戦術とは何か
モルトケが考案した訓令戦術とは、"上官から命令を受けた下級指揮官は、上官の意図を理解して出来るだけ自主的・主体的に任務を遂行する"という命令の方法です。
これは、戦場では状況が非常に急速に変化するため、詳細かつ長期間に渡る指示を上官が出すことは不可能だという認識に基づいています。そこで、計画を立案した指揮官は部下に自らの構想全体を含めた意図と達成すべき目標を伝え、部下はその意図の範囲内で目標を達成するための方法を決定、実行します。
上官の意図を伝えられているため、情勢の変化などで目標達成が困難あるいは無意味になった場合でも、部下は迅速に次の行動に移ることができます。
この原則は現在でもMission Command（ミッションコマンド）という指揮形式として、北大西洋条約機構 (NATO) などの軍隊で採用されています。
アジャイルが目指す自律分散型組織と訓令戦術の類似性
状況が急激に変化する予測不可能な環境に、現場のチームに正しく権限移譲することで対応する、という訓令戦術の方針はアジャイルにおける自立分散型組織に近いものがあると考えます。
例えば、Jeff Sutherland は2005年のThe Roots of Scrumという講演で、新しい組織の特徴として以下を挙げています。これら特徴（Diversified perspective, Uncertain, Local action, Participativeなど）は訓令戦術が目指す軍隊の形に類似した特徴を持っています。
訓令戦術のポイントとアジャイル組織での適用
以下では、訓令戦術で重視されるポイントを理解することで、類似した特徴を持つアジャイル組織に必要な観点を検討します。
Point 1：ミッションに対する深い理解
訓令戦術では、上官から指示された内容をただ実行するのではなく、状況を判断した上で任務を達成するための行動方針を自身で決定します。そのため指揮官はあらゆる命令において、自らの構想全体を含めて何を意図しているのか部下に伝える必要があります。意図を理解することで、刻々と変化する状況に的確に対応できます。
つまり命令ではWhat（目標）とWhy（意図）を伝えることが期待されます。
アジャイルにおいても、マクロな観点ではインセプションデッキの作成などを通じて、プロジェクトメンバー全員が共通の認識と目標を持つことを企図しています。またミクロな視点では、以下のようなユーザーストーリーの記述テンプレートはWhatとWhyの明確化に寄与すると考えられます。
As <Who> <When> <Where>, I want <What> because <Why>
Point 2：高度な判断能力
自分で行動方針を決定するためには、あらゆる階層のメンバーに高い水準の能力が求められます。モルトケが以下のように述べているように、その前提が崩れると訓令戦術も機能しません。
"すべての階級のリーダーが独立した行動をできる能力があり、それに慣れている場合にのみ、大規模な集団を容易に動かすことができる。"
米軍は独立戦争以来プロイセンの訓令戦術から強い影響を受けていますが、ベトナム戦争ではマイクロマネジメントの手法により大きな失敗をしています。フォード・モーター社長から国防長官に就任したマクナマラの手法（例えば、戦場の事象を全て数字で捉えようとする定量化や作戦計画の過度な重視）は、米軍内にマイクロマネジメントの傾向を強めたと言われています。
ただその理由の一つとして、徴兵された兵士の質が低下していたことが挙げられます。ミッションへの理解と判断能力を欠いた部隊が、全体として協調した行動を行うためには、上級指揮官が現場の細々とした事象にまで口を出す必要が出てきたということです。
アジャイルでは自己組織化されたチームが、技術的卓越性と優れた設計に対する不断の注意を保つことが求められています(アジャイルソフトウェアの12の原則)。この点を意識し続けなければ、アジャイルの理想は絵に描いた餅となることが米軍の例から容易に想像できます。
Point 3：コミュニケーション
最後の重要な要素として、コミュニケーションが挙げられます。Point 1では上官から部下に対して意図を明確に伝えるというコミュニケーションを取り上げましたが、モルトケは以下のように部下から上官へのコミュニケーションもまた重視しています。
"コミュニケーションは、上からの命令、下からのメッセージや報告によって維持されており、後者は前者の欠くことの出来ない基礎を形成している。"
部下に行動の自主性が許されているため、上官は状況に関する情報や報告を適宜受けることで、継続的に適切な命令を下すことが出来ます。謂わば、自主的な行動を許すことの当然の帰結といえます。戦闘が激しくなると部隊は報告を後回しにする傾向があるため、戦闘期間であっても適時適切な報告が必要であるとモルトケは述べています。
アジャイルでも、予め定期的なスタンドアップミーティングやスプリントレビューなどをスケジュールすることで、コミュニケーションコストを小さくすることを図っています。またInformation Radiatorを誰でも見れる状態で公開することで、最新の状況を関係者全員に共有することが出来ます。
まとめ
この記事では、アジャイルと類似した特徴をもつ訓令戦術で重視される要素から、アジャイルに必要な要素を検討しました。不確実な状況への適応方法として、"計画して実行する"のではなく、"実行して適応する"という方針を採用した訓令戦術は、アジャイルの適用に大きなヒントとなるように思います。
参考文献
- 軍事学を学ぶ - モルトケが語る訓令戦術（Auftragstaktik）のエッセンス
- The Art of Action: How Leaders Close the Gaps between Plans, Actions and Results (English Edition)
- Moltke on the Art of War: Selected Writings (English Edition)
- イラストでまなぶ！用兵思想入門 現代編
Disciplined Agile Senior Scrum Master (DASSM) 合格への道
2020年9月にリリースされた新しいPMI認定アジャイル資格である Disciplined Agile Senior Scrum Master (DASSM) を取得しました。今回は認定取得までの流れを簡単にまとめます。
- Disciplined Agile (DA) とは何か？
- Disciplined Agile Senior Scrum Master (DASSM) とは何か？
- 受験資格
- 試験方式
- 受験までの流れ
- PMI-ACPとDASSMの違い
Disciplined Agile (DA) とは何か？
ディシプリンド・アジャイル(DA)は、アジャイルプラクティスを包括的に含んだツールキットを提供するフレームワークです。もともとIBMで開発されましたが、後にその知的資産はディシプリンド・アジャイル・コンソーシアムに移譲され、2019年8月にPMIに買収されました。
DAは包括的なアジャイルプラクティスのツールキットを提供することで、多くの手法やメソッドが乱立しているアジャイルの世界で、アジャイル導入・展開を実現するための効果的なプラクティスの選択をサポートすることを目的としています。
ディシプリンド・アジャイル創始者の一人であるマーク・ラインズ(Mark Lines)がDAを説明した内容を記事にしています。詳細はこちらを参照してください。
Disciplined Agile Senior Scrum Master (DASSM) とは何か？
PMIが提供するディシプリンド・アジャイル(DA)認定の一つです。2021年10月時点でPMIが提供するDA認定は4種類ありますが、DASSMはミドルレベルの資格として位置づけられています。
PMIが提供するアジャイル認定には、PMI Agile Certified Practitioner (PMI-ACP) という資格が存在します。これはPMIによるDA買収前から提供されていた認定で、DA認定には含まれませんが現在もPMIからアジャイル認定として提供されています。PMI-ACPの詳細はこちらを参照してください。
受験資格
DASSMの認定を受けるためには、以下条件を満たす必要があります。
DASSM 認定試験はDASSM トレーニングコースの完了者が受験可能なため、実質的にトレーニングコースの受講が必須ということになります。
2年間のアジャイル経験については特に確認されませんでした。私がPMI-ACP認定を保有しているため、この条件の確認を免除された可能性があります。
試験方式
- Pearson VUEが提供するオンラインテスト。
- 全50問の選択方式。
- 試験時間はおよそ120分。ただし30分はチュートリアルの時間のため、テスト自体は90分です。
- 合格ラインは公表されていません。
受験までの流れ
私の認定取得までの流れは以下のとおりです。
1. PMIのDASSM Certification ページから提供されているオンラインコースに申し込む。
私は好きな時間に受講できるメリットから、オンラインコースを受講しました。価格は499ドル（PMI会員は399ドル）で、内容はすべて英語です。
2. オンラインコースを受講後、メールで受講完了をPMIに連絡すると、認定試験に関する詳細な情報が送られてくる。
コース受講完了連絡後、認定試験の情報が送られてきます。試験はこのメール受領後一定の期間（Eligible期間）に受講する必要があります。
この期間はメールには30日間とありましたが、PMIのDashboardには60日間と表示されていました。どちらが正しいか分かりませんが、早めに受けたほうが良いのは間違いないです。
3. オンライン認定試験を受験する。合否はすぐに表示される。
オンライン試験は受験言語を選択することが出来ます。日本語を選べば、英語の原文に加えて、日本語で内容を確認して試験を受けられるのでおすすめです。
ただオンラインコース含めて学習教材が英語であること、アジャイル関連用語の翻訳が稚拙であることなどから、回答時に英語を読むことは必須です。日本語はあくまで補助として使うほうが良いです。
PMI-ACPとDASSMの違い
私はPMI-ACPも保持しているため、DASSMとの違いについて最後に簡単にまとめます。
扱う内容に大きな違いはない
どちらの認定もアジャイルのフレームワークやプラクティスについて幅広く扱う認定のため、内容にあまり違いは感じませんでした。チーム形成に関するタックマンモデルや、5段階のコンフリクトモデルはどちらの認定でも取り上げられています。またアジャイルのマインドセットに関する部分も当然差異がありません。
違う部分はDA固有の名称、考え方など
メンバーのRole名、プロセスゴールやディシジョンポイントの考え方など、DA固有のものがあります。すでにアジャイルに精通している、あるいはPMI-ACP認定を保持している人であっても、上記のようなDA固有の考え方は理解しておく必要があります。
Spotifyモデルを導入した組織で働いて感じたこと
アジャイルをスケーリングする方法の１つに、Spotifyモデルというものがあります。音楽ストリーミングサービスのSpotifyで導入されている組織モデルということから、この名前がついています。アジャイルのカンファレンスなどでも、Spotifyモデルを導入している企業の発表を聞くことがあります。
ただこのSpotifyモデルにはデメリットもあることが指摘されており（あらゆるものにデメリットはありますが）、特に最近 Spotify's Failed #SquadGoals （日本語訳：Spotifyは "Spotifyモデル "を使っていない）という記事が話題になっています。
私自身もSpotifyモデルを導入したITシステム部門で働いた経験があります。その組織では上の記事で指摘された問題点の一部について改善策を適用し、ある面では上手くいきましたが、問題点も残りました。
今回はこの経験に基づいて問題点を考察し、Spotifyモデルに対する私の考え方をまとめてみます。
- いきなり結論
- Spotifyモデルとはなにか
- 私が在籍したSpotifyモデル組織
- "Spotifyは Spotifyモデル を使っていない" で指摘された問題点
- Spotifyモデル組織での経験と問題点の考察
- まとめ
- 関連書籍
いきなり結論
少し長くなるので、結論を先に記載します。
- Spotifyモデルを一言で表すと、"かなりプロジェクト型に近いマトリクス型組織"。目新しい何かではなく、複雑に考えすぎないほうが良い。
- プロジェクト型組織に近いため、メリット・デメリットともに従来のプロジェクト型組織に対する評価とよく似ている。私が考える一番のデメリットはチームがサイロ化しやすい点。
- Spotifyモデルを導入する場合、組織内で情報・知識・意識を共有することを、マネージャーもメンバーも常に心がける必要がある。プロジェクト型組織に近いモデルの性質上、最初にこのような仕組みを構築しても徐々に形骸化しやすい。
- モデル、体制、組織構成だけでできることは限られる。それらを構成するメンバーのマインドセットや文化と合わせて作り上げる必要がある。
Spotifyモデルとはなにか
Spotifyモデルの説明は既に多くの記事あるので割愛します。以下を参照してください。
Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む（Spotifyモデル）leantrenches.wordpress.com
私が在籍したSpotifyモデル組織
私が在籍したある企業のITシステム部門にはSpotifyモデルが導入されていました。体制の概要は以下の通りです。
- ITシステム部門のメンバー構成は日本に100人程度、中国に200人程度。
- サポートする社内のビジネスエリア（人事、財務、購買など）ごとにTribeを構成。
- ビジネスエリア内を更に細分化し、その細分化したエリアをSquadが担当。
- 細分化したエリアに複数システムがある場合、1つのSquadで複数システムを担当。
- 1つのTribeには3~5個程度のSquadが存在。
- Squadの所属メンバーは7~9人程度。
- Squadのメンバー構成は日本メンバーと中国メンバーが半々程度。
"Spotifyは Spotifyモデル を使っていない" で指摘された問題点
詳細は元記事を読んで頂くのが良いですが、以下4点の課題が指摘されています。
- マトリクス経営は間違った問題を解決した
- チームの自律性を重視しすぎた
- チーム同士は協力し合えると思い込んでいた
- モデルは神話化し、変わることができなくなった
Spotifyモデル組織での経験と問題点の考察
在籍したSpotifyモデル組織での経験をもとに、指摘された問題点について私の考えを述べます。
1. マトリクス経営は間違った問題を解決した
エンジニアリングマネージャー（チャプターリード）は、管理対象者のキャリア開発以上の責任をほとんど持ちませんでした。その場合でも、対人スキルの開発を支援する能力は限定的でした。エンジニアリングマネージャーは、チーム（スクワッド）内の日々の状況に十分に関与することが出来ず、このためチーム内の他の人々を十分に管理したり、チーム内の対立に対処するための独自の行動を取ることが出来ませんでした。
この点は私自身も同様に感じました。Chapter Leaderの権限や作業は非常に小さく、あからさまに言うとあまりやることがなく感じられます。
この問題点について、在籍していた組織では「Chapterをなくす」という解決策を取りました。つまりエンジニアもビジネスアナリストも含め、横の繋がりであるチャプターを組織図上からなくし、Tribe-Squadという単純な組織にしました。
結果として、複数のマネージャーから取得していた承認処理が不要になる、マネージャーは各メンバーが何をしているか把握しやすい、責任者が明確になるなどの効果がありました。但し、私の考えではこれは単なる「プロジェクトの終りが見えないプロジェクト型組織」です。この解決策では、メリット・デメリットとも、プロジェクト型組織の特徴が色濃く出てくると感じます。デメリットについてはSquadのサイロ化を強く感じました（問題点2で記載）。
2. チームの自律性を重視しすぎた
Spotifyは、チーム（スクワッド）の横断的なコラボレーションのための共通のプロセスを定義していませんでした。すべてのチームに独自の働き方を認めることは、各チーム同士がコラボレーションを行う際にそれぞれ異なる関わり方が必要になることを意味していました。組織全体の生産性が低下していました。
ここで書かれているほどはSquadごとに働き方の自由裁量はありませんでしたが、やはり隣のSquadが何をどのようにすすめているか、 導入前より分かりにくくなりました。別Tribeの話となると、まるで別部門や別会社のことのように、状況が分かりません。複数のSquadが関与する大きなプロジェクトなどでは、各Squadの情報連携が実施されましたが、普段の作業プロセスにおける改善や技術的挑戦など把握するのが難しくなりました。
加えて、あるビジネスエリアで大きなプロジェクトが発生した場合（例えば購買エリアでパッケージソフトを導入するなど）、ビジネスエリアを超えて人員をサポートさせるということも難しくなりました。各ビジネスエリアごとにTribe/Squad固有のバックログを抱えているため、システム部門全体として最も優先度の高いプロジェクトがあったとしても、メンバーをそのプロジェクトに割り振ることが難しいです。
プロジェクトに単純にメンバーを追加することの効果、是非はあるとしても、システム部門全体として優先度の高いものから開発できているのか疑わしく感じます。部分最適化が進んでしまう可能性があります。
3. チーム同士は協力し合えると思い込んでいた
コラボレーションは知識と実践を必要とするスキルです。マネジャーは、メンバーがアジャイルプラクティスを良く理解していると思い込んではいけません。
SquadやTribeがサイロ化することを防ぐためには、各メンバーが情報・知識・意識を共有することが必要です。私達もGuildやランチセッションなどで情報・知識・意識を共有する試みを続けました。しかし上記でも指摘されているように、アジャイルについての理解、技術的な知識や仕事への思いは人それぞれで、Guildなどの仕組みさえ作ればすべて上手くいく訳ではありませんでした。
一方でマネージャーにも、1. 情報・知識・意識を共有し、2. Squadへできるだけ権限移譲をすすめるという、２つの姿勢が必要です。残念ながらマネージャーの中には、自分しか知らない情報を持つことを力の源と考える方もいたように思います（意識/無意識にかかわらず）。このような姿勢はサイロ化を促進してしまう要因となります。1の共有がないまま、2の権限移譲をすすめることは、誤った判断を招く可能性を高めることになります。
4. モデルは神話化し、変わることができなくなった
ビジネスユニット、部門、チーム、マネージャーは、Spotifyの失敗した方法論に固執してはいけません。彼らはSptifyのモノマネよりも効果的に組織構造の役割と責任を伝えることができるのです。
私が在籍した組織では、Spotifyモデルそのものにはあまり囚われず、改善の土台として扱っていたように感じます。それはChapterを廃止した点からも伺えます。それでも一度構築されたTribe-Squad体制から完全に自由になることは難しいです。
例えば、先進的な技術を活用したプロジェクトを実施するため、高スキルなエンジニアを集めたプロジェクトチームを結成することになりました。1 Squadとしてそのようなエンジニアを集めたチームはないため、複数のSquadからエンジニアを集めてプロジェクトチームとしました。その際でも、体制図上は既存のTribe-Squadがそのまま存在し、このプロジェクトチームはSquadとなりませんでした。
これはモデル自体を有名無実化していくやり方ともいえます。ある意味日本的な対応かもしれません。
まとめ
アジャイルをスケーリングする場合、小規模なチームだからこそ手に入れられた信頼関係と共通の目的意識に基づく適応力向上を、どのように拡大するかがポイントだと考えています。その観点からSpotifyモデルを検討すると、最初に小規模チームを複数構築する点は優れていますが、それらを結合して大きな組織としてのメリットを活かす点には改善の余地が多いと感じます。
この改善点に対する簡単な解決策はありません。ただ私の考えとしては、組織構造やシステム設計自体にこれ以上できることはそれほどなく、その中にいるヒトのマインドセットや価値観（例えば心理的安全性や帰属意識など）がパフォーマンスを左右する要因となると考えています。
関連書籍
小規模なチームで実現できた成果をどのように大規模に適用できるかという内容。著者は、米陸軍の特任部隊を率いてイラク・アフガニスタンのテロ組織と戦った司令官です。
ディシプリンド・アジャイル (Disciplined Agile) って何だっけ？ #PMIセミナー
先日PMI日本支部主催のディシプリンド・アジャイル(DA)概説セミナーに参加しました。 ディシプリンド・アジャイル創始者の一人であるマーク・ラインズ(Mark Lines)が講師というのがポイントでしょうか。セミナーの内容を自分なりにまとめてみます。
PMIとディシプリンド・アジャイルの関係
ディシプリンド・アジャイルは、もともとIBMで開発されたアジャイルのフレームワークです。後にその知的資産はディシプリンド・アジャイル・コンソーシアムに移譲され、2019年8月にPMIに買収されました。
PMIは、PMBOK第6版でアジャイルに関する記述を大幅に追加し、「アジャイル実務ガイド」も発刊しました。DA買収もPMIのアジャイルシフトの一環だと思います。
セミナーの内容
ディシプリンド・アジャイルとは何か？
DAはフレームワークというより、アジャイルプラクティスを包括的に含んだツールキットである。マーク・ラインズは「DAとはアジャイル全体を包む傘のようなもの」と言っている。
下の図から分かるようにスクラム、XP、Kanbanを始めとしたアジャイルに関連する多くのメソッドやフレームワークを取り入れている。スケーリングに関しては、SAFe、Spotify Modelなどからもプラクティスや考え方を取り入れている。(https://www.pmi.org/disciplined-agile/ip-architecture/disciplined-agile-is-a-hybrid)
なぜ必要なのか？
アジャイルの世界は多くの手法やメソッドが乱立してカオスに陥っている。
各メソッドやプラクティスは重要であるが、パズルの1ピースの様なものである。アジャイルをマスターするためには、個別のメソッドについて認定を取得し、自力でまとめる必要がある。加えて、メソッドを理解したとしても、実際に適応することはさらに困難である。
DAという包括的なツールキットを提供することで、このような状態を解決したい。
メリットは何か？
状況に応じて使用すべきアジャイルプラクティスがまとめられている点。いつ、どのような状況で、何をするべきかが明示されているため、ユーザーは簡単にプラクティスの取捨選択ができる。
DAはあくまで選択可能なオプションを提供するだけであり、必須のルールではない。そのため、ユーザーの環境などによって自由に取捨選択できる。スクラム、XP、Kanban、SAFeなどと組み合わせて使用することもできる。
どう使うのか？
状況や問題に応じて、どのようなプラクティスが推奨されるか要約されている。その中から適用するプラクティスを自分で選択する。
例えば、プロジェクト初期にスコープを検討している場合、「初期のスコープを探索する(Explore Scope)」という項目を選択する。
項目内にはスコープ検討に必要な観点や考慮すべき点が記載されており、それらに対処できるアジャイルプラクティスのオプションが並んでいる。オプションの中から、自分たちの状況にふさわしいプラクティスを選択して適用する。
レコーディング
感想
DA以外の解決策もある？ その1
アジャイルを知ることと実際にプロジェクトに適応することの間のギャップが大きい点は、多くの場面で指摘されていると思います。いわゆる「チェスのルールを理解することは大事だが、ルールブック(スクラムガイド)を読んでも偉大なプレーヤーにはなれない。チェスの基本的な戦略を学ぶ必要がある。」という話です。
このような問題点に対応するため、スクラムではスクラムパターンというものが存在します。スクラムがある状況でうまく働いた様子をパターンとして記述し、他のユーザーもそのパターンを参考にすることでスクラムをうまく活用できることを目指します。
スクラムパターンがまとめられた本には、A Scrum Book: The Spirit of the Gameがあります。
A Scrum Book: The Spirit of the Game
- 作者:Sutherland, Jeff,Coplien, James O.,Heasman, Lachlan,den Hollander, Mark,Ramos, Cesario Oliveira
- 発売日: 2019/09/03
- メディア: ペーパーバック
DA以外の解決策もある？ その2
アジャイルを知ることと適応することのギャップに加えて、アジャイルプラクティスと名乗るものが非常に多く、カオスのような状況であることもしばしば指摘されます。
解決策の1つとして、多くのアジャイルプラクティスを、適用するタイミングごとにシンプルなフェーズに分類し、何をするか、どのような課題を解決できるかなどの観点でまとめた Open Practice Libraryがあります。
個人的には、Open Practice LibraryはよりシンプルなDAという印象で、カオス化したアジャイルに対する課題意識や解決策がよく似ています。シンプルなだけにDAよりも取っ付きやすいです。（DAより"アジャイルっぽい"ですね）
RedHatはアジャイルを導入する際に、Open Practice Libraryを参考にしたそうです。
結局DAのどこが優れているのだろう？
ではDA以外の解決策に比べて、DAのどこが優れているのでしょう？
私は"アジャイルっぽさ"が薄い点だと思います。Disciplinedと自ら名乗っているように、アジャイルフレームワークの中ではマネジメント要素が強い方だと感じます。
セミナーでマーク・ラインズも、「従来のプロジェクトマネジメントとアジャイルのアプローチには、ユニークな部分もあるが共通の部分もある」と述べていました。例えば、DAのリスクマネジメントはPMBOKのリスクガイダンスを織り込んでいるそうです。「ガバナンスはアジャイルでは重要視されていなかった。DAはガバナンスを重要視する」という発言もありました。
DAのマネジメント色の強い性格は、一部の人には敬遠されるかもしれないですが、必要とされる環境はあるように思います。
補足
Disciplined Agile 認定資格について
Disciplined Agile 認定資格(Disciplined Agile Senior Scrum Master)を取得しました。詳細は以下をご覧下さい。
Lost in Translation: The Manager’s Role in Agile #RSGT2020
Regional Scrum Gathering Tokyo 2020に参加して、時間の許す限りセッションを聞いてきました。発表資料は共有されているので、内容の振り返りなどに活用できます。
ただDay2 Keynote "Lost in Translation: The Manager’s Role in Agile（発表者：Michael Sahotaさん）"は資料が見つからなかったため、自分自身の理解をまとめておきます。
- Agileではマネージャーは不要か？マネージャーは全て排除する？
- 具体的にはマネージャーはAgile Transformationにどう取り組むべきか
- Agile Tranformation以降のマネージャーの仕事
- Q＆A
- 補足：Sahotaさん本を読んでみた
Agileではマネージャーは不要か？マネージャーは全て排除する？
Agile Transformationではマネージャーは不要になるという意見があるが、あまりいい考えではない。その理由は以下2つ。
- 仕事がなくなると考えるマネージャーの心理的安全性は失われる。その結果、Agile Transformationに敵対してしまう。変革を目指すならNo one gets left behind！の姿勢が大事。
- ヒエラルキーを急に排除するような急激な変化はうまく行かない。その証拠は、大規模なTeal型組織のケーススタディでは、彼らですらヒエラルキーを持っている点。自律分散型組織はあくまでも最終的な目標であり、いきなり実現できない。
むしろマネージャーやあらゆるリーダーレベルでAgile Transformationを始めるべき。その理由は、リーダーが変われば組織を変えられるから。ボトムアップでは組織の一部にAgile実践者が出来るだけになってしまう。
ただし、リーダーたちは新しいテクニックを身につけるという意識ではなく、世界の捉え方を変えるという姿勢が必要になる。新しい世界の捉え方とはすなわちAgile Mindsetである。Sahotaさんが大切だと思うAgile Manifestoの一節は以下3つ。
- We are uncovering better ways of developing software by doing it and helping others do it.（この一節は常により良い方法を探し続けるという、Culture of Learningの大事さを伝えている）
- Responding to change over following a plan.（変化への適応力が重要である）
- Individuals and interactions over processes and tools.（個人と相互作用が重要である）
具体的にはマネージャーはAgile Transformationにどう取り組むべきか
1. X理論からY理論へ移行する
- X理論・Y理論の解説はこちら
- まずはリーダー自身がX理論からY理論へ考え方を移行すべき。
- メンバーはそれをコピーしていく。やがては組織文化となっていく。
2. 権限を移譲する
Agile Tranformation以降のマネージャーの仕事
- ScrumMaster/ ProductOwner/ Tech Lead/ Org Coachなどが考えられる。
- 何をするにしても"Everyone Needs to Add Value"。価値を付与する仕事でないといけない。
- 急には変われないので、マネージャーに対してもコーチングが必要。
Q＆A
組織変革の際に所謂"The Frozen Middle"という課題は存在するか？（参考リンク）
- 存在しないと思う。トップが変われば、中間層のマネージャーも変わる。中間層 が変わらないのは、トップが本当に変わっていないから。
国ごとにAgile Tranformationへの対応に違いはあるか？
- 各国でリーダーのトレーニングをしたが、国ごとに違いはない。人ごとの違いのほうが大きい。
"No one gets left behind！"であれば決して人を排除してはいけない？
- まずは"No one gets left behind！"の姿勢で会話や教育を進めるべきだ。新しい世界の捉え方や価値について伝える努力をする必要がある。
- ただ、どうしてもその価値観を受け入れないという人はいるだろう。それは良い/悪いではなく、生き方や価値観の問題である。そのような人は自分の価値観に合った環境にいってもらう方がお互いにとって幸せだと思う。
補足：Sahotaさん本を読んでみた
Sahotaさんの本が無料でDownload出来るので読んでみました。
面白かったところ
Agile Transformationとしてカンバンは不十分だが、トロイの木馬あるいはゲートウェイドラッグにはなりうる。カンバンは管理文化との親和性が高いので、既存の管理を行う組織であっても取り入れやすい。しかし、改善のきっかけを与えて、組織の変革のトリガーになるかも。その意味でゲートウェイドラッグだ。
上記の様な記載がありました。（なかなか物騒な記載ですが）
私は大手保険会社系システム子会社のメンバーに対して、アジャイルを取り入れるためのアドバイスしたことがあります。その方はプロジェクトに対しての影響力は持っていましたが、会社の組織標準などには従う必要があり、スクラムをそのまま導入することは難しそうでした。
そこで私は、既存の組織標準の範囲内でカンバンを導入することを勧めました。
導入後は3ヶ月程度しかフォローできませんでしたが、チームメンバーにインタビューをしてもらうと、「このプロセスに無駄があるから変えたい」「不必要な管理の仕事が減った気がして楽しい」などの意見が出たそうです。
メンタリティが変わってきたなという感触があったので、上記の記載は実感と一致しています。
機械学習で住みたい街を探してみる
Courseraで”IBM Data Science Professional Certificate”というコースを受講した。
学んだ内容で身近な課題を解決しようと、機械学習を使って住みたい街を探せないか考えてみた。
Introduction
最近部屋が手狭になってきたこともあり、引っ越しを考えている。しかい、どこに引っ越すべきか今ひとつ決まらない。便利さ、公園、好きな街の近くなど、考えることは色々ある。そこで思いついたのが、都内の駅を付近の環境をもとにしてクラスタリング（分類）すれば、ある程度引っ越し先候補を絞り込めるのではないか、ということ。
今住んでいる場所も気に入っているので、同じクラスター内の別の駅から引っ越し先を選ぶ、ということが出来ればいいなということである。
Data
駅の位置情報
引っ越し候補は東京メトロの駅から選ぶことにした。幸いにも東京メトロ各駅の緯度経度データを提供しているサイトを見つけたので、こちらを利用させてもらう。
東京メトロ - 座標データ - Google Maps JavaScript API入門
駅周辺環境の情報
駅周辺の店舗や施設の情報は、Foursquare APIを利用する。 Foursquare には ExploreというAPIがあり、このAPIは緯度経度を入力すると周囲の施設の情報を返してくれる。ちなみに、FoursquareのAPIは無料でも99,500 Regular Calls / Day使えるので、今回の分析では問題なく使えそうで一安心。
Methodology
以下の分析をJupyter Notebookを使用して実施する。今回はIBM CloudのWatson Studio上でJupyter Notebookを使用した。（Cloud上で分析するので自分のマシンのスペックを気にしないでOK、実行結果のNotebookをGitHubへ公開することも簡単）
- JSON形式で提供されている駅の緯度経度データをDataFrameとして取り込む。
- 緯度経度データを入力として、Foursquare Explore APIから駅周辺の施設のデータを取得する。
- 各駅毎にどのような施設（コンビニやイタリアンレストランなどの施設カテゴリー）がどれくらいの頻度で存在するかを集計する。
- これらの頻度をもとに、クラスタリングの手法であるK-means法を使用して、東京メトロの各駅を6つのカテゴリーに分類する
- 分類結果をmap rendering libraryであるFoliumを使用して地図形式で表示する
Result
以下がクラスタリングされた駅を地図上に表示した結果。
概ね都心から同心円上に駅が分類されているので、それなりに正しい結果に見える。とはいえ、周辺の駅とは異なる分類の駅もちらほらと存在するので、便利な環境だけどやや都心から離れたお得な駅というのが見つかるかもしれない。
分類結果の詳細はGoogle ドキュメントのスプレッドシートに保存してあるので、興味のある方はこちらをご覧ください。
Tokyo Metro stations clustering - Google スプレッドシート
感想
似たような駅をクラスタリングして引っ越し対象駅を絞り込む、ということはそれなりに上手くいった気がする。ただ実際の活用という面でいうと、対象の駅を（東京メトロもうだけでなく）もう少し広げてもよかった。東急、小田急、京王などの路線を含んでいないため、23区西部の住宅街駅が少なくなってしまった。残念。
分析を行ったNotebookはこちら。おかしなコードは指摘してください。。
Coursera ”IBM Data Science Professional Certificate”コースはこちら。
PMI-ACP 受験準備のコツ
以前、PMI-ACPについて合格のポイントをまとめました。
今回は効率的な資格取得のため、知っておいて損はない知識について書いてみたいと思います。あくまで資格取得のための知識で、アジャイルそのものには関係ないですが、受ける以上さくっと合格したいですよね。
以前の記事はこちら↓
受験の前提となる研修
PMI-ACPの受験のためには、アジャイル・プラクティスの分野で21時間以上の研修受講が必要です。
私はScrum Alliance の Certified ScrumMaster 研修などを受けていたので問題ありませんでしたが、場合によっては研修時間が足りないこともあります。アジャイルの研修は受講費用も高く、会社などから補助が出ない場合、自費で受けることが難しいです。
そんな時はMOOCのアジャイルトレーニングを受けるという選択肢があります。実際に私の周囲にもそんな方がいました。
例えばUdemyの以下コースですが、明確に "This course gives you 25 Contact Hours of Agile Practices Education so you can take the PMI-ACP® exam or earn PDUs" と書かれています。費用もそれほどかからないので、良いのではないでしょうか。
参考書の効果的な使い方
以前の記事でお勧めしたように、参考書は"PMI-ACP Exam Prep Second Edition" がお勧めです。
ただしこの参考書はテストで必要な知識を漏れなく載せているため、初めからじっくり読み始めると結構時間がかかります。
ある程度流し読みををしてから章末問題を解いてしまい、不正解だった部分をしっかり読み直すというやり方が効率的かもしれません。
一番効率がいいのは勉強会などに参加することだと思います。
勉強会に参加すると、参考書の内容をまとめた資料を作成することが多いです。例えば輪読形式の勉強会であれば、自分の担当範囲以外は他の参加者がまとめた資料を参照することができます。
すると参考書の要約資料で学習することができ、最初の流し読みの部分を短時間で終えることができます。私自身も勉強会に参加して学習しましたが、参考書を読む時間を大分短縮できたと思います。
勉強会に参加するとモチベーションの維持にも繋がりますしね。
ただもちろん勉強会に参加できる環境にない場合もありますし、一人で学習することは決して不可能ではないです！
無料オンラインテスト
実は参考書"PMI-ACP Exam Prep Second Edition"の購入者は、無料でオンラインテストを受けることができます。問題数も少なく、1回分しかありませんが、試験前に自分の理解度を確かめるためにとても有効です。
しかし参考書をしっかり読まないと、その存在に気付かないことがあります。私の周囲で参考書を購入した方の中にも、気付いていない方がいました。（おすすめしたような流し読みをしていると、ほぼ気付かないかもしれません。）
そこで念のためオンラインテストのリンクを貼っておきます。参考書購入済みの方でしたら、ログインすることが可能です。無料ですから是非活用してください。
Extras | RMC Learning Solutions
