目次
◆講演について
◇はじめに
◇アジャイルをスケールアップさせるにはどうしたらよいのか？
◇今日もって帰ってもらいたいヒント
◆我々がやっているプロセス : Conversation
◇Conversationの流れ
◇Conversationのポイント
- 仕事についての学び
- 仕事をブレークダウン
- 優先順位付けされたバックログ
- チーム構築
- 価値を届ける
◆導入の事例 : マネージャへ
◇概要
◇ゲストスピーカー
◇作業のブレークダウン
◇優先順位付け
◇フィーチャーチーム
◇その他やったこと
◆導入の事例 : チームへ
◇質問を集める
◇キックオフミーティング
◇キックオフミーティングから学んだこと
- 透明性
- 何ではなく何故
- 引き継ぎ
◇まとめ
◆質疑応答
ノート
◆講演について
◇はじめに
組織がアジャイルになっていくプロセスを考えたとき、アジャイル的なやり方・慣行を行ってアジャイルにしていく場合が多いと思います。
しかし、アジャイル的なやり方・慣行は非常に沢山あります。
「1つの会社をアジャイル化するぞ！」というときにはそれだけの考えが必要であるということです。
「これを大企業でやった場合どうなるか？」という事例を今日は見せます。
◇アジャイルをスケールアップさせるにはどうしたらよいのか？
一度に全てやるのではなく、少しずつやるのがよいでしょう。
"Concept to cash"（すぐに何かを出して認証してもらう）という言葉があります。
"Window of change"（変化で生じる差）という言葉があります。
一度にやるわけではありませんが、変化をきちんと見せていくことが大事です。
変化はスケーラブルでなければいけません。
メンバーはそれに合わせて動けないといけません。
◇今日もって帰ってもらいたいヒント
シングルバックログを作りましょう。会社・ビジネスユニット・チームで使える単一のバックログです。
チームメンバーがころころ変わらないようにしましょう。同じチームで違う仕事に入っていくということです。
安定したチームが存在し、その中にある障壁をマネージャが解決していく、というやり方にしましょう。
また、スケーラブルでなければいけないということを考慮した場合、ミニマルなプラクティス、慣行を決めなければいけなません。
そして、これは忘れてはいけないことですが …
チームはいつもアジャイルでないといけません。
意思決定はチームがしなければいけません
（ここでいうチームには百人単位のビジネスユニットなども含みます）。
◆我々がやっていること : Conversation
◇Conversationの流れ
1. まず、作業そのものが入ってきます
2. study demand and need
それについて学習・勉強します
3. work breakdown
細かく分けます。作る側・発注側それぞれに分かるようにしながら作業を進めていきます
4. work prioritisation
優先順位を決めます。まずは一番価値があって時間がかからないもの。それから、その次を考えます
・一番優先順位が高いものは？
・その次にしなければいけないことは？
5. work distribution
次は取り決め。どのチームが成果物を持ってくるかを決めます
6. taem construct
取り決めがはっきりしたら、どのようなスキルセットを持つ人材が必要かを考えて人を集めます
7. doing the work
実際にやります
8. poissible vakue delivered
検証し、最初に戻ります
◇Conversationのポイント
・仕事についての学び
どのような作業が入ってくるかを知っておきましょう。
これが分からないと、そのたびに「あれを変えないと！」とばたばたして効率がよくないのです。
例えば、どんなことをしてほしいという要求をボードに貼り付けておきましょう。そうやって誰が見ても一目瞭然になります。
・仕事をブレークダウン
どんなに細かいものに分割しても、それはカスタマーに何らかの価値があるものでなければいけません。
一番最初は情報がないかもしれません。でも作業をしていくうちに明らかになっていきます。
見切り発車でも始めることがポイントです。
何度も何度も確認することができるので、何か全てが集まるまで待つよりリスクは全然少ないのです。
・優先順位付けされたバックログ
バックログ項目が小さくなっていることがポイントです。
優先順位つけのための共通のメソッドを決め、優先順位別に作業をソートします。
このとき、ベースラインが何かということを把握しておきましょう。
そうすれば、ベースラインを超えたか下回ったかを図ることができます。
・チーム構築
我々が作りたいのはフィーチャーチームであって、コンポーネントチームではありません。
フィーチャーチームは様々なものを取り入れて作業できます。
コンポーネントチームには特定のことしかできないという弱点があります。
フィーチャーチームなら会社全体が何かを学んでいることになります。
なお、作業によってはスペシャリストをプラスアルファとして加える必要があるかもしれません。
・価値を届ける
成果物を少しずつ顧客にわたし、どのような価値が実現できているか検証しましょう。
どのようになされたか、どのようなアジャイルの慣行が使われたか。
それから、デプロイやリリースがどのようになされたか（継続的なデプロイやリリース）。
最後に、提供したものがお客の望むものだったかを検証します。
◆導入の事例 : マネージャへ
◇概要
9人で5日間のワークショップを行い、『Conversation』について話し合いました。
まず講義。そのあとにはハンズオン。昼食時間にゲストスピーカー（過去に研修を受けた人）を呼びました。
◇ゲストスピーカー
ゲストスピーカーを呼んだことは重要でした。
参加者にはアジャイルへの温度差・経験の差があったからです。
さらに、実際の作業がどのように行われているかの理解についても個人差がありました。
ゲストスピーカーの時間は、何を達成したいのかを共有するためのよい時間になりました。
◇作業のブレークダウン
お客様によって異なる入ってくる作業を細かく分割しました(Work Break Down)。
この作業を更に細かくするにはどうしたらよいでしょうか？
受け入れ基準（許可）のレベル（Acceptance criteria)が何なのかは、1つの基準になります。
また、「どこからお金が入ってきているのか？」というのは優先順位付けとは切っても切り離せません。
もっとも予算を出してくれた部門はそれだけのバリューを受け取ることができます。
お金を出したのが２０％なら、もらえるリターンも20%ということです。
ただ、"お金に関係ない重要なもの"でやっていくことが重要なので、このモデル自体は将来的には変わるかもしれません。
ポートフォリオをざっくりとみるため、それぞれフィボナッチで見積もりました。最終的な見積もりはチームが行います。
◇優先順位付け
WSJF(Weighted shortest job first = 重要で時間がかからないものから)というのがあり、これを導入しました。
非常に短い会話をして、意見ではなく価値に基づいて優先順位付けをしました。
◇フィーチャーチーム
ここが最も難しい部分だといっても過言ではありません。
どのような人材、スキルセットを持った人物をチームに入れるか …これはマネージャのスキルも求められてけっこう難しいのです。
予算の関係で人を入れられないこともあります。
また、バリューという観点から見た場合、縦型の組織ではないと対応できないということも分かっています。
できるだけ多くの作業を、それが大きくても受け入れられるようなチームを作ろうと思いました。
最も希少な人材をまず振り分けてから、チーム構成を行いました。
チーム構成の際にはアジャイル的なプラクティスも入れました。
◇その他やったこと
Practice-lead（プラクティショナーみたいなもの？）というのを作り、学んだことを他のチームでも共有できるようにしました。
次のプロジェクトでも活用できるように、情報共有を行ったのです。
また、ワークショップ受講者たちの気持ちも計測しました。
「実現可能に思えるか否か」というのを視覚的なチャートで示せるようにし、毎日の研修開始前に調査しました。
初日は「いまひとつ」というのが多かったのですが、だんだん「できる」と思う人が増えています。
そのあと6週間かけて、やろうと決めたことを詳細化しました。
その後、やろうと決めたことについて、4時間のキックオフセッションをやると決めました。
キックオフセッションでは150人（パートナー・ベンダーなど全ての関係者）全員を集めて、やろうと決めたことを説明するのです。
◆導入の事例 : チームへ
◇質問を集める
キックオフに至るまでの時間、マネージャたちはがありとあらゆるものをカベに貼り付けました。
そして、その内容について質問を集めました。
◇キックオフミーティング
このミーティングの開催理由は2つあります。
・これから何が起きるかを教える
・150人という大きい規模のチームにおける懸念について聞く
なぜチェンジが必要なのか、というところから話が始まりました。
「今の状態で変わらなければ、業務に迅速に対応できない」「間違った成果物を届けている」ということについて合意に達し、「だからチェンジが必要だ」という話になりました。
次に150人にフィーチャーチームの説明をし、チームへの振り分けをしました。
それからチームビルディングのための演習をしました。
その後、各々のチーム10分ずつをマネージャが回りました。各チームはそれぞれ違った事柄についてマネージャと話をしていました。
最後はビールを飲んで、CIOのメッセージフィードを受け取りました。
◇キックオフミーティングから学んだこと
このキックオフから3つのことを学びました。
・透明性
全員が学び、何が起きているかわかることはとても大事です。
・"何"ではなく"何故"
マネージャは、誰が何をするかについては説明していましたが、何故については説明していませんでした。
だから、月曜日にマネージャはそれぞれに配属理由を説明して回らないといけませんでした。
・引き継ぎ
既に何かを手がけていて、誰かに引継ぎをしなければいけない人達は苦労していました。
→最後の2つの問題は、1日で解決しました。それだけチームの結びつきが強かったということです。
◇イテレーション1
次のことを2週間の課題としてやってもらいました。
・最初のフィーチャについてディスカバリーセッション（何が争点になるかの話合い）。
・チームに名前を付けてもらいました。
・仕事の進め方についてプランニングをしてもらいました。
・いっしょに食事に行ってもらうなど、何か楽しいことをしてもらいました。
・チームで許されることなどのグラウンドルールを決めてもらいました（ユニークな社会的契約）。
それから、その中で何を学んだかを振り返りしてもらいました。
最後にはショウケースを行いました。
顧客に『何をやったか』と『これから何をするか』を見てもらったのです。
他のチームに『何をやった』ということを発表する機会も設けました。
（ここでショウケースの写真を見せる）
fuzzyに見えるかも知れませんが …我々はこれを劇的な透過性(Hyper transparency)と呼んでいます。
◇まとめ
いわゆるアジャイル的なやり方もありますが、これだけ大きなスケールで変えるやり方もある、ということです。
◆質疑応答
Q.
たくさんのマネージャをワークショップに呼ぶよう仕向けるにはどうすればよいか？
A.
シニアマネジメントのコミットメントがあってこそ始めて実現できることではないでしょうか。
意思決定する権限が無い中間管理職(Frozen middle)からやるのは難しいのではないのではないかと考えます。
ただ、アジャイルはFrozen middleも一般の人達もやりたいと思っています。
Q.
アジャイルプロセスに積極的ではないメンバをチームに入れるべきか？
A.
大きい会社なら中にはアジャイルをやりたくない人もいるでしょう。
ただ、最初はためらっていたとしても、アジャイルのやり方で大きな成果を上げることができることがわかれば、彼らの考えはどんどん変わります。
Q.
リリース毎ににワークショップを開催したか？
A.
ワークショップはリリース毎に2時間行いました。
アジャイルでは毎日合ってミーティングを行います。
それからスプリント毎にも振り返りを行います。
そこまでやって、意識がすりあっているため、2時間で終わります。
Q.
どのくらいの期間、そのチームにかかわっていたか？
会社全体に広げるときにはチーム毎にコンサルティングしたか？
それとも途中からは社内でやってもらったのか？
A.
基本的には組織が自律するまでがゴールです。
大きい会社にはマネージャや偉い人達がたくさんいます。
9人で5日間のワークショップは彼らを呼んでたくさん行いました。
組織がアジャイルに慣れて普及していけば、フォローしなくてもうまくいけると思います。
我々は企業がアジャイルになれるインフラを提供しています。
企業毎のアジャイルでやれるようになってくれればいいと思います。
Gary O'Brien様, ThoughtWorks Inc.様, 株式会社テクノロジックアート様ありがとうございました。
0 件のコメント:
コメントを投稿