経験と理論、どちらから先に伝えるべきか？
たまたま今日は『リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法』を読んでいたが、紹介されるエピソードや書籍や研究や一々面白くて引き込まれる。
たとえば、ロッククライミングの講師の話、
インストラクターが現われ、全員が正しく安全装置を着用しているか確認しました。全員の準備が整いチェックが済むと、インストラクターは皆の前に立ちました。我々は黙り込み、講義が始まるのを待ちかまえていました。
ところが講義が始まりません。代わりにインストラクターは我々は登り始めるに言ったのです。ただそれだけです。30分間。そうしたら皆ここに戻って来るように、と。
(中略)
30分後、インストラクターが戻ってきて、なんとそれから講義を始め、登り方を説明したのです。その時には、（短い時間とはいえ）いくらか経験を積んでいましたから、その説明に非常に納得がいきました。
先日行われたScrum Fest Osaka 2021の自分も参加させていただいたセッションで、「経験と理論、どちらから伝えるべきか？」という質問が出たけれど、一般的には経験の方が良いようだ。
先輩から教えて頂き、たまに読み返している『研修デザインハンドブック』でも、先に理論を教えるよりも、先に経験(Experience)させ、そこで気づき(Aware)を得て、その後、知識や理論(Theory)を学んでもらう「EATモデル」の方が、効果的な学びに繋がると書かれている。
さて、アジャイルコーチングの現場でも、最近は意図的に先に知識を伝えるのではなく、「あえて失敗させて痛い目にあってもらってから、理論を伝える」機会が段々と増えてきた。
けれども、これはチームメンバーからの信頼を失いかねない劇薬だし、賭けでもある。だから取り返しのつかない失敗ではなく、すぐに取り返せる小さな失敗を対象とすることが多い。あと正直に言えば、自己満足でやっちゃう時もごく稀にある、人間だもの。
ProblemではなくKeepからTryを選ぶこと
現在支援させていただいている、とあるチームは結構難易度が高いことに取り組んでいる、と思う。
詳しくは書けないが、リーダーや上流工程の経験が乏しい若手中心でスクラムチームを結成しているのにも関わらず、先進的なアーキテクチャに加え、Atomic Designを採用し、ユーザーストーリーマッピングをし、といった具合に。
なので、はじめの内は、チームで合意形成しながら進めることにも、ユーザーストーリーマッピングすることにも相当戸惑って混乱している様子が伺えた。
そして、スクラムを初めて1ヶ月位経ち、今日のスプリントレトロスペクティブでKPTをした。
チームで合意形成しながら進めることに慣れてきた、ユーザーストーリーマッピングに慣れてきた。
多くのKeepが挙がっている。
けど、チームはKeepの共有を手早く済ませると、こちらも沢山挙がっているProblemからアクションを考えることに移っていった。
「喉元過ぎれば暑さを忘れる」
僕たちは、できることになったことを、当たり前のこととして流し、軽く扱いがちだ。
自分に照らしていえば、娘が生まれたことも、アジャイルコーチになったことも、少しの間は奇跡のように嬉しいことだったのに、1ヶ月も経つとすぐに日常になり、挙げ句の果てには愚痴まで言うようになる。
だから、今日のレトロスペクティブでは、以下の事だけをフィードバックした。
「君たちはすごい事をしたので、もっとお祝いしようよ！」
森一樹さんの『ふりかえり読本 場作り編～ふりかえるその前に～』には、「ふりかえりにおいても、起こってしまった間違いに対して、どのようにプロセスを直していけば失敗を防げるのか、を考えることはとても大事です。ただ、もっと大事なのは、「成功をより高める、継続させる」ためのアイデアを出すことです。」とある。
頭では同意するのだけど、自分はそのようにコーチングできていなかった。なぜならば自分自身が物事をネガティブに捉えがちだからだ。
けれど、今日のレトロスペクティブを見ていて、やはり森さんの言う通りだと強く思うようになった。
できるようになったことを祝福するチームと、できるようになったことを流して次の課題に取り掛かるチーム。チームの比較は人間同士の比較と同じくらい無意味だけど、その後成長するのは前者のチームなはず。少なくとも前者のチームは幸福だ。(もちろん、できるようになったことを祝福し、次の課題に取り掛かるチームがベストなんだろうけど)
けれど、チーム云々の前に、自分自身がそれを実践できるようになりたい。
そして、チームがKPTをやっている時には、次のアクションはKeepから選んでみませんか？ ともさりげなく提案したい。
2021年に僕がアジャイルコーチとして気をつけたい6つのコト
- 1. 「It depends(時と場合によるね)」とお茶を濁さない
- 2. 「ウォーターフォール」脳を捨てる
- 3.「コーチング」だけで乗り切ろうとしない
- 4. 「チェンジ・エージェント」気取りをやめる
- 5. なるべく「コード」を読む
- 6. とにかく「ポジティブ」に居続ける
- おわりに
今回は、今年をふりかえりつつ、「2021年に僕がアジャイルコーチとして気をつけたい6つのコト」を挙げたいと思います。
1. 「It depends(時と場合によるね)」とお茶を濁さない
経験を重ねるほど、企業形態やチームの成熟度やプロダクトの性質など、アジャイルチームが置かれた状況は多種多様であるため、一つの課題に対する万能な解決策がないこと(「銀の弾などない」)をしみじみと実感するようになる。
そのため、クライアントや知人からアジャイルに関する相談される時に「It depends」と言っていた時があった。
「It depends」......何だかカッコいいし、何だか深いことを言っていそうだ。
しかし、そこに問題を解決しようという能動的なパッションはない。
来年は「It depends」とお茶を濁さず、「銀の弾などない」と知りつつ、状況を見極め、状況に応じた最適解を、現場と一緒に考えてもがき続けたい。
2. 「ウォーターフォール」脳を捨てる
よく、アジャイルはプラクティスではなくマインドセットだと言われるが、果たしてアジャイルコーチは完璧にアジャイルなマインドセットが身についているのだろうか?
......答えは、ワークショップの運営で見極められます。
かつて僕はワークショップのタイムスケジュールを5分単位で考えてきて、途中でトラブルや計算違いがあっても、最初のスケジュールを必死に守り通そうとしていた。
一方、先輩コーチ陣は最初に計画したタイムスケジュールを臨機応変に変えており、そもそもタイムスケジュールすら無い方もいた。
来年からは、ワークショップに限らず、全てのシーンにおいて、最初の計画を経験から臨機応変に変更できるように心がけたい。
3.「コーチング」だけで乗り切ろうとしない
「答えは相手の中にある」「対話を重ねて一緒に答えを模索する」といったコーチングの姿勢はとてもかっこいいし、有効に思える。
かくいう僕も、一方的に教えるだけのティーチングよりコーチングの方がずっと魅力的に思え、今年は数ヶ月に渡るセミナーも受講した。
そして、新規クライアントに対して「答えは相手の中にある」という姿勢で臨んだ。
......結果は、もちろんボロボロになった。
そもそも、多くの場合、クライアントに従来の開発手法とは異なる思想、価値観、そしてプラクティスを身につけてもらうのがアジャイルコーチに与えられるミッションである。
そんな中、はじめから「答えはあなたの中にある」とコーチング的に問いかけても、従来の価値観に基づく返答がなされ、訂正と軌道修正に追われるだけである。
というわけで最初はティーチングからはじめ、慣れてきたらコーチング的なアプローチを取るのが良いと今は考えている。
(そもそもティーチングとコーチングに優劣はなく、両者とも重要なツールだ)
4. 「チェンジ・エージェント」気取りをやめる
今年はアジャイルコーチにとってクライアント(依頼主)との期待値調整こそ重要なことはないと感じた一年だった。
けれども、クライアントの期待値が曖昧だったり、また、クライアントの意図が現場に伝わっておらずケースも多く、何から支援して良いかわからないケースも多い。
......組織の課題は明白だ。
......有効な手段も分かっている。
そうした中、業を煮やした僕は、つい、クライアントの期待値を明確化する前に「こうしましょう」とチェンジ・エージェント(=組織における変革の仕掛け人)になろうとしたことがあった。
しかし、部外者がチェンジ・エージェントになろうとした代償は大きい。
結果的に「この人が代わりに考えてくれる」とコーチに依存するマインドセットが生まれ、クライアントの協力は得られず、状況が悪化しただけだった。
来年は僕一人で出しゃばらず、クライアントの期待を明確にすることから、支援を始めたい。
5. なるべく「コード」を読む
アジャイル導入においてはプロセスと同じように技術が重要である。
どんなにチームの雰囲気が良くとも、スクラムプロセスが完璧に実施できていても、肝心の設計やコード品質が悪かったり、CI/CD環境が無かったり、十分なテストコードが用意されていないことには砂上の楼閣に等しい。
そうしたチームは、数週間後か数ヶ月後か、スパゲッティコードとの壮絶な闘いに追われ、定期的なリリースどころではなくなってしまう。
そして、上記の問題を検出するには、メンバーからのヒアリングや観察だけでは不十分で、実際にコードを読んでみるしかない。
現場によって言語が異なるため一筋縄ではいかないが、来年はきちんとコードを読むということも意識したい。
6. とにかく「ポジティブ」に居続ける
大企業や従来型企業を支援すると、クライアントから我が社の「深い闇」を打ち明けられることがある。
深い闇が経営層のこともあれば、マネージメントのこともあり、組織体制のこともあり、ビジネスモデルのこともある。大袈裟に言えば、エンタープライズアジャイルとは、そうした「深い闇」との闘いなのだ。
そうした中、クライアントと付き合いが長くなればなるほど、こちらまで相手に共鳴してしまい、「深い闇」が本当の深い闇に、動かしがたい障害に思えることがある。
とはいえ、その闇に飲み込まれ、「ミイラとりがミイラになって」はいけない。
来年は相手に共感しつつも、とにかく一人でポジティブに居続け、相手と一緒に深い闇から脱出する方法を探し続けたい。
そもそも深い闇は見方を変えれば「高い壁」であり、「高ければ高い壁の方が 登った時気持ちいいもんな(Mr.Children)」なのである。
日本企業をビルドトラップの底無し沼から救うために!!(『プロダクトマネジメント』を読んで)
はじめに
大企業や、従来型企業でスクラムを推進する方々からよく聞く悩みだ。
この状況でも、初めのうちは、チームプレーによる仕事スタイルの転換やふりかえりなど、開発チームに楽しい日々が訪れる。
けれども、残念ながらそんな楽しい日々は長く続かない。
ユーザーや機能の背景が見えないまま、機能リリースを急かされている内に、だんだんと「自分達は檻の中で必死に走り続けるハムスターじゃないか!?」と思えてくるからだ。
そして何より悲惨なのは、誰も使わない機能が、リリースされ続けることにある。
プロダクトビジョンを自分で決めたいと言い続けていますが、許可されていません。マネージャーは私にソリューションを渡し続けます。何か別のことを提案するたびに、拒否されます。スクラムを始めたとき、スクラムチームは自律的であるべきと言われました。現状はまったく自律的ではありません。(『プロダクトマネジメント』より引用)
『プロダクトマネジメント』について
今回取り上げる『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』は、この問題の構造と、実際にどのように仕事のやり方を変えるべきかが、極めて明快に示されている本である。
プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
- 作者:Melissa Perri
- 発売日: 2020/10/26
- メディア: 単行本（ソフトカバー）
著者によれば、「はじめに」で触れた問題は、組織がビルドトラップに陥った結果だという。
そしてビルドトラップとは、以下の状況のことだ。
ビルドトラップとは、組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まっている状況のことです。実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状況です。
ビルドトラップは、軽快な言葉の響きに反して、実際には多くの組織がどっぷりと漬かっている底無し沼のような状況を指す。
そしてそれは最悪の場合、組織全体の崩壊までに追い込む「死に至る病」なのだ。
ビルドトラップに陥る原因
本書で最も印象的だったのは、組織がビルドトラップに陥る原因がこれ以上ないほど明確に描かれていることだ。
著者によれば、組織がビルドトラップに陥る原因は以下のようなものがある。*2
- マインドセット: 経営層のビジョン、戦略の不在。組織全体のプロダクトリリースの目的化
- 組織構造: 企画部門とビジネス部門の縦割り化。「ラボ」という名の予算や権限の不十分な譲渡
- 予算編成: 年次計画に基づき、使い切らなければならない予算
- 報酬制度: 従業員の成果指標は、リリースした機能数
- 人材: プロダクトマネージャーのスキルセットの認識やトレーニング不足
- 文化: 失敗が許されない、「心理的安全性」が低い文化
私の言葉で言い換えれば、要するに、「不確実な顧客に向き合う」よりも、「プロダクトや機能をリリースする」ことに組織の目的を限定させた方が、あらゆる意味で圧倒的に楽なのだ。
前者より後者の方が、組織編成も、マネージメントも、オペレーションのマニュアル化も、人事評価も、圧倒的にやりやすいだけではなく、組織全体として「一生懸命頑張っている」という心理的充足感も得られやすい。
一方、前者は、組織編成やマニュアル化もやりづらいだけではなく、不確実で気まぐれな顧客の声に絶えず向き合う結果、「ある日突然仕事がなくなる」という不安にも晒されやすくなる。
『みんなでアジャイル』に引用されている、心理学者のヴァージニア・サティアの言葉は象徴的だ。
ほとんどの人は、不確実性の悲惨さよりも、不幸の確かさを好む
みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
- 作者:Matt LeMay
- 発売日: 2020/03/19
- メディア: 単行本（ソフトカバー）
どう仕事を変えていくべきか
著者は、マーケットリーという架空の会社のコーチングを通して、戦略やビジョンの策定からプロダクトマネージャーの役割の定義、プロダクトマネジメントプロセスの導入に至るまで、どのように組織がビルドトラップから抜け出し「プロダクト主導組織」に変革していくかを本書で丁寧に記述している。
詳しい内容は本書に直接あたっていただくとして、ここでは印象に残ったことと感想を挙げてみたい。
プロダクトマネージャーの役割
本書では「悪いプロダクトマネージャーの典型」として、顧客からの要望をただ聞いて伝えるだけの「ウェイター」、スティーブ・ジョブスよろしく一方的にチームに自分のビジョンを押しつける「ミニCEO」が挙げられている。
どのタイプも一緒に働いたことがあるため、該当の章は苦笑しながら読んでいた。
プロダクトマネジメントは高度に専門的なスキルだが、多くの人にとって学ぶ機会はなく、それゆえトレーニングの必要がある、という著者の主張には、100%共感だ。
プロダクトマネジメントプロセス
本書の素晴らしい所は、顧客への早期検証による学習の重要性や様々な方法が紹介されている一方で、学習をスキップすべきケースも併せて紹介していることだ。
ECサイトの購入ページが良い例です。ほかのEC企業向けにこの機能を売り込むつもりがないなら、ここですべての時間を費やすべきではありません。このソリューションに関してはすでに多くの実験が行われていて、それを活用すればいいのです。
今まで『リーン・スタートアップ』片手にあらゆることを顧客相手に検証したがり、他社製品を「パクる」ことに対して後めたさを覚えるプロダクトマネージャーと数多く出会ってきたが、これからは本書を勧めてみたいと思う。*3
どうやって、経営層やビジネス部門をアジャイル開発に巻き込むか?
さて、「はじめに」の悩みに戻れば、組織がビルドトラップから抜け出すためには、経営層やビジネス部門を巻き込まなければならないのは明白です。
本書では、CTOが問題を認識し、組織の全面的な変革を決意することから始まりますが、実際には、一番難しいのがここではないかと感じています。
どうやって、経営層やビジネス部門をアジャイル開発に巻き込むか?
ここからは、本書で示されるヒントや、私なりの経験則を伝えて、ブログを終わりたいと思います。
「アウトカム(成果)に着目したコミュニケーション」
まず、明日から私たち現場がすぐに出来ることとして、本書の「アウトカムに着目したコミュニケーション」はかなり有効だと感じています。
スプリントレビューをはじめ、あらゆる場面でビジネス部門に、アウトカムに着目したコミュニケーションを仕掛けていくこと。
具体的には、たとえば以下のような質問をしていくのが効果的だと感じます。
「これは本当に顧客が使うのでしょうか?」
「誰を対象とした機能でしょうか?」
「こないだリリースした機能は、どれくらい利用されていますか?」
ビジネス部門の方は(本来は)このような話題に興味があるため、乗っかってくれる確率は高いです。*4
日本の大企業や従来型企業では「役員」を攻める
私は日本企業がビルドトラップに陥る原因の一つとして、ビジネス部門と開発部門の分離が大きいと考えています。
しかし、両部門の部長にいくらビルドトラップを訴えても、与えられたノルマをこなすことに精一杯な彼/彼女らにその声を響かせることは難しい。
攻めるべきは「役員クラス」です。
具体的には、以下のような解決策が考えられます。
- 仕事で成果を積み重ね、「信頼貯金」を貯める
- 役員やマネージャーにアジャイル開発のトレーニングを実施する
- 役員にアポイントメントを取り、現状の問題と解決策をプレゼンする
- 上記のためにコンサルタントやアジャイルコーチを雇う
とはいえ 、「それが出来たら苦労しないよ.....」という声が聞こえてきそうです。
確かに、上記を現場が実行するのは、なかなかは難しいのが現実。
そのため、現時点でのベストな解決策は、役員に本書を読んでもらう事ではないでしょうか。
さぁ......勇気を振り絞って役員に本書を渡してみましょう!!
おわりに
企業がビルドトラップから抜け出すためには、現場だけではなく経営層やマネージャーが本書を読むことが極めて重要だと思います。
それくらい素晴らしい本でした!
日本企業がビルドトラップから抜け出すために、アジャイル開発の効果を最大化するために、是非ご一読してご自分の会社の経営層にも是非オススメしてみてください!
本書を頂いたRyuzeeさん、そして最後までお読みいただき、ありがとうございました!!
*1:特に断りがなければ、本ブログの引用はすべて『プロダクトマネジメント』から
*2:これは、組織がビルドトラップに陥る原因が無数の網目のように張り巡らせれており、大企業や従来型企業以外のスタートアップ等の企業も、組織拡大等のちょっとしたきっかけであっという間にビルドトラップに陥る事を示している
*3:文脈が違うので一概に比較できないものの、過去のベストプラクティスや資産等の活用は、エンジニアの方が遥かに進んでいると感じている
*4:組織を変えることについては、『Fearless Change』も参照
atama plusの大規模スクラム(LeSS)リモートイベント見学レポート【後編】
前回、atama plusの大規模スクラム(LeSS)イベントについて客観的に書きましたが、後編では個人的な感想やご提案をお伝えします。
norihiko-saito-1219.hatenablog.com
ステキ❤️と思ったこと
- チーム間の積極的な助け合い
- UXリサーチ結果やユーザーフィードバックの積極的な共有
- メンバーの課題形成/解決能力の高さ
チーム間の積極的な助け合い
チーム数が多い組織では、チームメンバーの意識がチーム内に閉じ、チーム間の情報共有や連携が薄れる傾向(いわゆる「サイロ化」)がよく見られますが、atama plusでは積極的にチーム間で助け合っていました。
スプリントプランニングでは、大変なプロダクトバックログを担当することになったチームに、「本人達のチームは大丈夫なのか!?」とこちらが心配になる位、他チームのメンバーが積極的にトラベラー*1として他のチームに協力する様子が印象に残りました。
これは、UXリサーチやユーザーフィードバックの共有等の一つ一つの工夫により、メンバーの意識をチームだけではなく絶えず「ユーザーやプロダクト全体」に向かわせている努力の賜物だと感じます。
UXリサーチ結果やユーザーフィードバックの積極的な共有
今回、スクラムイベントだけではなく、atama＋のユーザーの一人である塾の運営者へのインタビュー結果を共有するワークショップ(教室長ワークショップ)に参加することができました。
印象的だったのは、単なる共有にとどまらず、「新たに学んだことは何か?」「認識を深められた点は何か?」とチーム全員でインタビュー結果を基にディスカッションしていた事。
このように、UXリサーチ結果やユーザーフィードバックを組織全体に対し深いレベルで共有している現場はまだまだ少ないのではと感じました。
(もし)atama plusのスクラムマスターだったらplusしたいこと
最後に、ほんっんとおおおおおに、余計なお世話ですが、もし僕がatama plusのスクラムマスターだったらplusしたいことを書いてレポートを終わりにしたいと思います。
僕がatama plusにplusしたいことは「キャンプファイヤー」(ゆるさ、余裕、遊び)です!
今まで書いてきた通り、atama plusでは経営、ビジネス部門、開発部門が一丸となって大規模スクラムを真摯に実践し、プロダクトの成長とユーザーに向き合っていました。メンバー1人1人の課題解決能力も極めて高めです。
......ですので、あまり言う事ないのですが強いて気になった点を挙げれば、論理的判断や効率性を優先するあまり、合意形成が浅いままミーティングを終えたと感じられたケースが何度かあったことです(e.g. 時間切れになったオーバーオールレトロスペクティブ。自分たちが話したいことよりも時間の都合から「主催者の意図に沿った意見をまとめる」傾向が見られた教室長ワークショップ等)。
atama plusでは(たぶん)やるべきことや課題が山積しており、またスクラムのタイムボックスの観点からも会議や仕事の効率化の追求は非常に重要です。一方、個人的には経営、ビジネス部門、エンジニア、UXデザイナー、QAに至る多種多様なメンバーが協業する際、些細な認識のズレの積み重ねが、大きな問題に繋がることを経験してきました。
そこで、たまには時間をたっぷり取って、個人個人の深い所に繋がるような交流の機会を作ることが、結果的により強靭な組織に繋がるのではというのが僕の意見です*2。
色々書きましたが、そういった理由で、キャンプファイヤーをオススメしました!
いつか、焚き火を囲んで皆さんとゆっくりお話しする機会があれば嬉しいです!
おわりに
今回は前後編でatama plusの大規模スクラム見学レポートを書きました。
アジャイルコーチとして普段支援している大企業の対極にあるatama plusのようなスタートアップをじっくり見学できたのは、貴重な体験であり、本当にありがたい機会でした。
スタートアップというと華やかな印象があるかもしれませんが、僕が見たatama plusのメンバーは「大規模スクラム(LeSS)の学習」「アジェンダの準備」「一つ一つ課題に向き合い丁寧に解決する姿勢」等の地道な事を積み重ねており、その姿勢はエンタープライズアジャイルを目指す僕達も学ぶべき事が多いと感じています。
またスクラムマスターの河口さんによるとatama plusでは、創業当時より、プロダクトディスカバリーとプロダクトデリバリーを組み合わせた「デュアルトラックアジャイル」へ取り組んでおり、今回導入した「LeSS」との組み合わせた新しい開発手法を模索しているとのことです。
atama plusでは見学も調整できるということなので、大規模スクラムに興味がある方は、是非 kawakin さんにご相談してみてください!
最後までお読みいただき、ありがとうございました!
*1:トラベラーについては、こちらを参照。 less.works
*2:もちろん、こんなこと僕に言われるまでもなく、もう既にいろいろやっていると思いますが!!
atama plusの大規模スクラム(LeSS)リモートイベント見学レポート【前編】
以前から大規模スクラム(LeSS)の書籍を繰り返し読み、コミュニティに参加し...と大規模スクラムの理論を学んできましたが、「理論は素晴らしいけど、現実で上手くいくのだろうか？」とどこかで感じてもいました。
そんな折、認定LeSS実践者研修で知り合い、大規模スクラムを実際に導入したatama plusのスクラムマスター河口さんから、「良ければウチの現場を見学しない？」と言葉を掛けていただき、ようやくこの目で大規模スクラムを見学することができました!
今回は、前編と後編に分けて、見学レポートをお届けします。
前編ではスクラムイベントの流れや、atama plusが独自にplusしている工夫を書いていきます。*1
- こんな方にオススメ
- atama plusと組織構成
- 大規模スクラムとは?
- 見学したスクラムイベント
- スプリントプランニング
- 複数チームPBR(複数チームプロダクトバックログリファインメント)
- オーバーオールレトロスペクティブ
- atama plusがplusしている工夫
atama plusと組織構成
atama plusとは中高生向け一人一人に最適な学習カリキュラムをAIが生成する「atama ＋」というサービスを開発運営する会社です。
「atama＋」は開発者、UI/UXデザイナー、QAで構成された5〜6人からなる4チームが大規模スクラムでプロダクトを開発しています。
専任スクラムマスターは2名で、それぞれ2チームずつ担当しています。
詳しくは以下をご参照ください。
大規模スクラムとは?
大規模スクラムとは2〜8チーム向けの大規模アジャイルフレームワークです。
1つのプロダクトバックログを1人のプロダクトオーナーが管理するというスクラムのコンセプトを踏襲しながら、複数チームが連携しながらプロダクトバックログアイテム(以下、PBI)を優先順に実現します。
詳しくは以下をご参照ください。
見学したスクラムイベント
- スプリントプランニング
- 複数チームプロダクトバックログリファイメント(以下、複数チームPBR)
- オーバーオールレトロスペクティブ
- レトロスペクティブ
- デイリースクラム
- 教室長ワークショップ(「atama ＋」のユーザーインタビュー結果をチームメンバーに共有するためのワークショップ)
atama plusのスクラムイベントはリモートに移行しており、Zoom、Googleスプレッドシート、Jira、Miro等が利用されていました。
今回は、大規模スクラムでとりわけ特徴的なイベントである、スプリントプランニング、複数チームPBR、オーバーオールレトロスペクティブについて書いてきます。
スプリントプランニング
最初にご紹介するのはスプリントプランニングです。
大規模スクラムでのスプリントプランニングの特徴は、1チームスクラムの流れに加えて、チーム間で調整しながらチームが担当するPBIを決定することです。
参照：https://less.works/img/framework/sprint-planning.jp.png
スプリントプランニングイベントはZoomで実施され、POおよび全チームメンバーが参加します。
テーマ(プロダクトバックログをまとめるビジネステーマ)はMiro上の付箋で、プロダクトバックログはJiraで管理されていました。
スプリントプランニング第1部の流れ(1h)
- テーマと優先順位についてPOが説明
- 新しく作成されたPBIの概要/ビジネス背景をPOが説明
- 次スプリントで実現したいPBIをPOが説明
- 各チームメンバー同士で話し合いながら、チームが担当するPBIを決定
複数チームPBR(複数チームプロダクトバックログリファインメント)
大規模スクラムで最も運営が難しいイベントが複数チームPBRかもしれません。
大規模スクラムでは全チームが全てのPBIを担当する可能性があるので、スプリント開始前に全チームが全てのPBIを把握している必要があります。
しかし、全チームの全メンバーが全てのPBIについてリファインメントに参加するのは効率的ではありません。そこで、複数チームPBRではPBIごとにチームから代表者を割り当て、複数のPBIを並行してリファインメントを実施します。
参照：https://less.works/img/framework/product-backlog-refinement.jp.png
リファインメント前日までに、リーディングチームが仕様の叩き台をGoogleドキュメントにまとめます。当日はドキュメントを共同編集しながらZoom上でリファインメントを実施していました。*2
オーバーオールレトロスペクティブ
チームでは解決が難しい、組織的な課題を解決するためのイベントがオーバーオールレトロスペクティブです。
参照：https://less.works/img/framework/xsprint-review-retrospective.png.pagespeed.ic.4qxk6ndBIS.webp
atama plusではチームのレトロスペクティブで、チームで解決できる課題と組織的な課題を切り分け、組織的課題をオーバーオールレトロスペクティブの議題に追加していました。
また、課題だけではなく、組織に「ただ共有したいこと」をオーバーオールレトロスペクティブの議題に追加するケースもありました。
atama plusではオーバーオールレトロスペクティブは全員が参加するのではなく、参加したい人が参加する形式。オブザーバー参加もOKです。私が見た際には、組織的課題を提起した方が積極的に参加する傾向にありました。
ちなみにatama plus代表の稲田さんもこのイベントは毎回参加されています。
Miroで付箋を利用しながら、Zoom上で議論していました。
イベントの流れ(1h)
- 参加者が持ち寄った組織課題を共有する
- 参加者の投票により組織課題の優先順位を決定する
- 解決策についてタイムボックスに区切り討論する(いわゆる「リーンコーヒー」に近い)
atama plusがplusしている工夫
今回のブログの終わりに、atama plusがスクラム運営に独自にplusしている工夫を一部挙げます。
- PBI担当決めの効率化のため、各チームが担当したいPBIをスプリント前に事前に表明している(「お気持ち表明」と呼ばれています)
- スクラムイベント運営コミュニティがあり、スクラムマスター以外のコミュニティメンバーがZoomのブレイクアウトルームの管理などのイベント運営をサポートしている
- レトロスペクティブやデイリースクラム等のチームのイベントはスクラムマスター以外のメンバーがファシリテートしている
- レトロスペクティブの最後にメンバー全員でレトロスペクティブ自体のふりかえりを実施し、レトロスペクティブのやり方を毎回改善している
- チームメンバーが、ビジネス的な事情を鑑みつつも「このPBIは取れない」と調整する機会がある
- 大規模スクラムの原則を組織に浸透させるために、スクラムマスターがイベントの冒頭で「調整と統合」などのキーワードを繰り返し伝えている
またスクラムマスターの河口さんによるとatama plusでは、創業当時より、プロダクトディスカバリーとプロダクトデリバリーを組み合わせた「デュアルトラックアジャイル」へ取り組んでおり、今回導入した「LeSS」との組み合わせた新しい開発手法を模索しているとのことでした。
また、atama plusでは見学も調整できるという事なので、大規模スクラムや「デュアルトラックアジャイル」に興味がある方は、是非河口さんにご相談してみてください!
後編では、僭越ながら、atama plusのスクラム運営の強みと弱みについて書く予定です。
最後までお読みいただき、ありがとうございました!
そして父になる......!?
6月5日、第一子が生まれた。
妻は42歳で、僕は36歳だった。
結婚した時点で妻が38歳。
僕を含め、家族の誰もが、子供を授かれることを期待していなかった。
「子供が欲しいか?」と聞かれると、正直あまり深く考えていなかった。
ただ、妻が子供を望んでいたので、僕も欲しいと答えていた。
どのみち、何もイメージができていなかったのです。生まれたその瞬間、ではなく、里帰り出産から妻が帰ってきた7月までは。
ただ、漠然した予感がずっと心の中に鳴り響いていた。
「僕が未成熟なのに、夫婦だけでも手一杯なのに、子育てできるのか?」
「このご時世に子供を産んで、子供を幸せにできるのか?」
この予感は、思いの外、すぐ的中することになる。
今回はこの予感がどう的中し、現在、どう立ち直りつつあるかという事を男性側の視点から書いてゆきたい。
崩壊の4ステップ
- 削られる体力
- 削られるメンタル
- 低下する仕事のクオリティ
- 育児の悩みを相談しづらい男性
1. 削られる体力
まず、正直とても恥ずかしいのですが、共働きにも関わらず、禄に家事をしてこなかったのです。
代わりに毎晩のようにオンライン・アジャイル・コミュニティに参加していた。めっちゃ楽しかった。
ただ、やってきたのは過酷な現実だ。
娘は四六時中、泣き喚いている。
泣き止むには授乳しかない。
流石の僕でもこれは家事をしなければマズい、と気づいた。
そこで慣れないながら、掃除、食事の準備、買物、子供の入浴、ミルクあげ、おむつ替え等をするようになった。
慣れない家事と、育児、そして夜泣きによる睡眠不足で、どんどん体力が削られていった。
2. 削られるメンタル
こちらも情けないのですが、僕は精神的にも妻に完全に依存していた。
具体的にはうまくいかないことや愚痴を逐一妻に吐き出していた。
辛いのは泣いている娘だけじゃない、僕も辛い。
そこで、必死に娘をあやす妻に話しかけてみた。
「ねえねえ、今ちょっと話聞ける?」
「そんな余裕ない! 見てわからない!?」
......当然だ。
そして僕はこう見えてプライドが高く、妻以外にあまり相談できなかった。
3. 低下する仕事のクオリティ
周りの父親はみな子育てをこなしながら、仕事でも易々と成果を挙げているように見える。
また、育児で仕事量が減ったと思われたくなかった。
何しろ少人数のチームだ、周りに迷惑を掛けるのも辛かった。
そこで、バカだったとしか言いようがないけど、普段よりたくさんの仕事を任せて欲しいとチームに掛け合った。
結果、どの仕事も中途半端になり、日に日にクオリティは低下していった。
今までは残業や土日出勤で密かにカバーして何とか取り繕ってきたけど、業務時間外は育児で手一杯だ。今回はその手は使えない。
結果、一人で担当すると宣言したのに、最後にはチームメンバーに様々なサポートをお願いする結果になってしまった。
4. 育児の悩みを相談しづらい男性
「なんでこんなに胸が重苦しいのだろう......」
7月から9月に掛けて、ずっとこんな気分が続いた。
この原因が育児による環境変化と気づいたのは、9月に入ってからだった。
育児に悩む女性の記事やツイートは良く見かけるが、男性の記事はほとんど無い。
そして、隣には、僕より何百倍も苦しむ妻がいる。
「男が弱音を吐いちゃいけない」という風潮に知らず知らずに僕もハマり、相談することすら出来ずにいた。
3ヶ月での気づき
色々と書いてきたが、この3ヶ月で気づいたことを一言でいえば、
「余裕がなければ、育児はできない」
さらにいえば、
「自分が幸せでなければ、人を幸せにできない」
という平凡なことだ。
けれど、皮肉なことに、育児とは参加者の余裕がなくなっていくゲームなのだ。
そんな中で、余裕を確保するために、今取り組んでいることは以下の2点だ。
- 周りの人に状況を打ち明け、協力をお願いする
- 仕事を効率化する
1. 周りの人に状況を打ち明け、協力をお願いする
どうしようもなくなってから、僕は上司に、同僚に、アジャイル・コミュニティの仲間に、悩みを打ち明けた。
みなさん暖かく、手を差し伸べてくれた。
もちろん、ただ単に仕事を丸投げすることではなく、自分が出来る事を見極め、キッチリやりきることは必要だ。
ただ、今回は上司も同僚も協力をしていただいて、本当にありがたく思っている。
そして、仲間にも本当に助けられた。
2. 仕事を効率化する
そして、余裕を作るために、仕事の効率化を進めたいと思っています。
ここはまだ取り組んでいる最中なので、何か良いアイディアあれば是非教えてください!
僕が10分でも余裕ができれば、その間、娘が抱っこでき、娘にべったりな妻にもわずかに余裕ができる。
結果、こうした方が周りが幸せになる、という事を今は確信している。
最後に「自分が幸せになる」ということについて
様々悩んだ僕がこの3ヶ月で結論したことは、自分が幸せになる、ということは「自分の持っている事を認める」ということに尽きると思った。
よく、水が半分入っているコップを見て「半分も入っている」「半分しか入っていない」というが、そこであくまでも「半分も入ってる、ラッキー!」と言い張るのだ。
- 水が半分以下になっても、「水が入ってる、ラッキー!」
- 水が無くなっても、「コップがある、ラッキー!」
- コップが砕け散っても、「破片が綺麗、ラッキー!」
- 失敗に成功した!
なので、この先何があっても、心の中で号泣していても「ラッキー!」と言い続けたいと思っています。
娘のために、周りのために、僕自身のために。
今日はバラバラと書いてきました。
拙い経験ですが、父親の方、これからお子さんを出産する方、誰かのお役に立てれば幸いです。
最後までお読み下さり、ありがとうございます!
