「ゾンビスクラムサバイバルガイド: 健全なスクラムへの道」の感想
翻訳者の皆様から献本いただきました。
こんな本です
「スクラムで開発しているけど成果も感じられず、うまくできていない状態」を指してこの本ではゾンビスクラムと読んでいます。ただ決められたやり方を繰り返しているだけの状態を指す表現としてぴったりだと思います。なぜゾンビ化してしまうのかの理由と、ゾンビ化を防ぐためのプラクティスが難易度と効果がセットでいくつも紹介されています。
スクラムを紹介する書籍や資料は数多くあり、プラクティスや背後にある考え方を教えてくれますが、よくあるスクラムの失敗状態から抜け出る方法を扱った書籍はそういえばありません。「ステークホルダーを巻き込まない」「リリースを溜めてしまう」「おかしな状態・問題ををみてみぬふりする」この辺りの問題が丁寧に説明されています。
こんな方におすすめ
スクラムの入門書籍は読んで、組織・現場で実践し、うまくできている気がするけど「こんなもんなのか」と感じているような状態で読むのが一番効果があると思います。 「私たちのスクラムがうまくいってない気がする」となると外部のアジャイルコーチやコミュニティに顔を出して助けてもらうのが良くある定石ですが、私が外部からのコーチとして招かれたらきっとこの本に書いてあることを1年ぐらい指摘し続ける気がします。今所属しているRetty株式会社でアジャイルな開発を広める際もこの書籍の内容を再三社内で言ったなーと思い出しながら読みました。
組織内に複数のスクラムチームがあり、スクラムマスターが複数人いるのであれば、この書籍の内容を輪読するとスクラムマスターとしてのレベルが確実に1段階上がると思われます。
会社でも1冊購入しましたが、献本いただいた分も活用して、社内のスクラム運用レベルを引き上げるのに役立たせていただきます。
個人的にこの本の好きなところ
- 挿絵がかわいい
- 表紙に翻訳者3名の似顔絵があるが似すぎている
2022年1〜3月に社内で共有したアジャイル開発関連の記事
社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。
ノウハウ・知見
フィーチャーファクトリーにならないように注意
有名なMVP図の解説
デュアルトラックアジャイルの実践
フィーチャーフラグの分類
ユニコーン企業の秘密をベースとしたスケーリングの考え方
落合博満に学ぶ
技術負債に立ち向かう前の話
TDDの考察
スクラムチームを生産的にするパターンランゲージ
プロダクトバックログの整理の秘訣
捨てましょう。
30分で分かった気になるチームトポロジー
他社事例
メルカリCAMPシステム
現在はCamp単位でLeSS(Large-Scale Scrum)を入れるように推奨しています。そして必要があればAgileコーチやScrum Masterをアサインしています。
LIFULL
LeSSっぽいけどLeSSと明言してないので何か大きな違いがあるのかも。
GitLabで学んだ最高の働き方
atama+ LeSS事例
Regional Scrum Gathering Tokyo 2022
スライドまとめ
後日公開された動画
いい感じのチームを作る考え方
ChatworkのScrum@Scale事例
永和システムでの学び直し・スキルアップの取り組み
学びのサイクルを繰り返しながら機械学習など新領域を習得してもらうの言われるとすごく良さそうだけどこれまでみたことなかった気がするので新鮮
www2.slideshare.net
プロダクトゴールについて
スプリントゴールについて
Agile Fluencyモデル
RSGT 2022 2日目の基調講演より。うちは今Optimizationかなーと思いながら聞いていました。
プロダクトバックログについて
これは教科書
Yahoo LeSS事例
ブルシットプロダクト
その他
Women in Agileコミュニティ
CircleCIの開発の雰囲気
1つのカードが長くても3日で終わるくらいの大きさで。優先順に並んでて。カードごとに、ゆるめのAC（受け入れ条件）があって、本番デプロイしてる。メンバーはそれぞれ得意分野があるけど、得意分野じゃないカードも取って、得意な人にペアしてもらったり、レビューしてもらったりしてる。そんなの。
— Mitsuyuki Shiiba (@bufferings) 2022年1月25日
リモートペアプロを扱った書籍
リモートペアプロの本があった
— 角 征典／Masanori Kado (@kdmsnr) 2022年3月2日
Practical Remote Pair Programming: Best practices, tips, and techniques for collaborating productively with distributed development teams (English Edition) https://t.co/ujPqI1i5jh via @amazon
「プロダクトバックログが降ってくる」という表現は危険の兆候
プロダクトの価値を最大限にするために、チームがプロダクトバックログを調整するというのが検査と適応なので、「プロダクトバックログが降ってくる」というのは、だいぶ危ない臭いがしますね。
— HARADA Kiro (@haradakiro) 2022年3月3日
速さにはベロシティとアジリティがある
速さには、ベロシティ(まっすぐが速い)とアジリティ(止まったり方向転換が素早い)という要素があって、しばしば対立するんですよね。アクセル全開だとカーブ曲がりきれないので、適切にコントロールする技術が大事かなと。(その車に乗ってない人にとっては関係ないかもですけど)
— Yasunobu Kawaguchi (@kawaguti) 2022年3月7日
MVPには名前をつけておく
MVPには名前をつけておくと良いです。運悪くユーザーを見つけられなくて使われなかったとしても、チームが次のMVPを決めるときの語彙として生き残ります。
— HARADA Kiro (@haradakiro) 2022年3月26日
「Googleのソフトウェアエンジニアリング」の感想
2021年11月末に発売されてからすぐに入手したはずですが、少しずつしか読み進められず、先日ようやく読み終わりました。
25章ある書籍の内容をざっくり分類すると
- トップ層のエンジニアを集め、実業務を通じてGoogleが分析・見出したベストプラクティス
- Googleの規模でないと起こらないであろうスケール問題
- Googleにしかなさそうな謎内製ツール/謎内製ソフトウェアの紹介
かなと思います。
中堅以上のソフトウェアエンジニアなら技術的にも思想的にも面白いと感じるポイントが必ず見つけられ、頭から読み進めずとも気になる章をつまみ食いして読むこともできる面白い書籍です。
以下気になったトピックを順不同で紹介します。
Hyrumの法則が面白い
Hyrumさんはこの書籍の著者で、こんな考えを披露しています。
あるAPIに十分な数のユーザーがいるとき、APIを作った者自身が契約仕様として何を約束しているかは重要ではない。 作られたシステムが持つあらゆる観察可能（observable）な挙動に関して、それに依存するユーザーが出てくるものである。
「要件として合意した」「仕様として明記している」とかに関わらず、暗黙的な挙動に依存した実装になってしまっていることはよくあります。 有名なところだとハッシュの順序問題とか。「OSSライブラリを更新するとテストが通らなくなった」も同種の問題かと思います。
実装だけで起きるのではなく、組織のあらゆるレベル・コミュニケーションでこのような暗黙的な依存が発生するのが、法則としてよくできているなと感じます。
マネジメントについて
・自分が居合わせなかったとしても組織自体がその問題を解けるようにすることも、自分の仕事である
・優れたマネジメントの95%は観察と傾聴で、5%はちょうど正しい場所に決定的に重要な調整を加えることである
GoogleのマネジメントスタイルはGoogle re:Workとしてもまとまっていますが、エッセンスが短くまとまっている上記の書籍表現が気に入りました。 マネージャーとしてチームやメンバーと伴走することも時にあるかもしれませんが、自分がいなくても同じように物事が動くよう仕組みを作るのが一番効果的ですよね。
テストコードの読みやすさ
・テストは後からの付け足しであってはならない。
・テストコード自体のテストはかかれないため、テストコードでは分岐・繰り返しなどの制御構文を使うべきではない。
・なるべくモック使うな
Googleの開発規模・エンジニア数ともなると、不安定なテストが少量でも入ると、他の開発者の時間を奪ったりリリースブロックとなり得たりと与える影響がものすごく大きいことが心に残っています。なので当初からテストをきちんと書くし、テストコード自体も読みやすさを重視するし、なんならモックをなるべく使わずテストすることを考えるそうです。
テストをしっかり書こうとするほどモックの書き方に時間が取られているような気がしていたので、「モックを使いこなすことが必ずしも良いことではない」という意見があることが知れてよかったです。
レビューは設計を議論する場ではない
・コードレビューは、過去に既に行われた設計上の決定について討議するための時間ではない。
・コードレビューは提案されるAPIの設計を紹介するための時間ではない。
コードレビューの目的が事前に擦り合わせられていないと、つい設計方針や実装技巧の議論をしがちではありますが、レビューはそういう時間ではないと一刀両断してくれました。そうですよね。
ドキュメントは読み手を意識して書く
・(ドキュメントは)読者に向けて最適化せよ。
ドキュメント整備について、Googleは他社よりも時間・工数をかけているのだろうと思っていて、書籍を読み終わった今もその認識ですが、それでも完璧ではないと感じているそうです。ドキュメントは「Googleでも一級市民として扱われていない」だとか。
ドキュメント管理は定期的に新しいツールが出てきますが自分の中ではこれといった決定版と受け取ることができず、内容が古びたものを見直し・淘汰できる仕組みが入っているといいのかなーと思ったりしました。
ソフトウェア開発に関する意識の持ち方
コードは債務であり資産ではない。
「技術的負債」という言葉が広く使われるようになったせいか、負債でないなら資産なのだろうと私とかは考えてしまいがちですが、本書では運用・メンテナンスが必要なことから「債務」と表現していました。利用者が使い続けられるように考慮・サポートが必要なことからですが、先に紹介したHyrumの法則にもつながる考え方かと思います。
定期的な再デプロイの強制化
本番環境には半年ごとに再ビルド・再デプロイされなければならない
だそうです。
開発がひと段落したサービスだとライブラリ更新を怠ったり、頻繁に更新されないサービスだとビルド・デプロイの自動化を後回しにしてしまいがちですが、こういうルールを決めておくことで問題を軽減することができそうです。外部環境の変化でいつのまにかデプロイできなくなった/動かなくなったというのも避けやすくできそうです。
Bazel / アーティファクトベースのビルドシステム
モノレポ(全てのコードを1つのリポジトリにまとめて管理する)とセットで導入するビルドシステムとしてよく名前を聞いていましたが、アーティファクトの依存関係を宣言的に定義しておくことでツール側で再ビルドの必要性を正しく判断でき、ビルドに要する時間を短縮できると知り、仕組みにとても感心しました。Bazelについて調べてみると、現実は「Bazel職人」のようなノウハウを蓄えている人が生まれてしまう負の側面もあるようですが、それでも機会があれば一度は触ってみたいなと思うように考えが変わりました。
おわりに
少しずつ読み進めていたため、Twitterに #Googleのソフトウェアエンジニアリングのタグで感想を呟いていましたが、書籍で推奨しているハッシュタグは #swebookjpだということを一番最後に知りました。ぜひ両方のハッシュタグを眺めてみて、書籍を手に取ってみてください。
Regional Scrum Gathering Tokyo 2022に参加してきました #RSGT2022
はじめに
2019年が初回で、通算4回目の参加でした。
- Regional Scrum Gathering Tokyo 2019に参加しました - tuneの日記
- Regional Scrum Gathering Tokyo 2020に参加しました #RSGT2020 - tuneの日記
- Regional Scrum Gathering Tokyo 2021に参加しました #RSGT2021 - tuneの日記
参加者(2019)→スポンサー(2020)→参加者(2021)ときて、今年は登壇機会がいただけ新しい楽しみ方ができました。 登壇に関しては来週あたりに会社のブログで別途書きます。
聞いてきた話など
「録画で後で見れるし、他のオフライン参加者と親交を深めるか」と考えて発表を聞いたのは半分くらいです。 3日目は家族都合 & 会社都合で不参加でした、後日録画で見ます。
Agile Program Management: Scaling Collaboration Across the Organization
「スケールする際にコラボレーションを増やしてスケールしよう」というのはわかる。LeSSだと「ただ話す」とかなのかな?
Software Program Teamはよくわからなかった。コラボレーションを絞る方向の仕組みだと思うけど、でも何かを決める仕組みが時に必要なのは同意。
Leading Skilled Agile Teams: Investing in Team Outcomes with the Agile Fluency® Model
Agile Fluencyの図がなるほどなーと思って聞いていました。 チーム文化を変える→チームスキルを上げる→組織構造を変える→組織文化を変える の中で、自社の今はOptimizeのあたりかなーと思いあたります。 「アジャイルである」領域を広げる際に、気持ちではなく仕組みで工夫する必要があり、とっかかりを試行錯誤していた自分にとってはしっくりきた図でした。
今年の感想
ゴールに関する発表が多い
プロダクトビジョン・プロダクトゴール・スプリントゴールなど、目標やゴールに関する話が多かったし、講演後も議論しているのを良く見かけた気がします。
1チームのスクラム・立ち上げはできるところが増えてきて、LeSS / Scrum@Scale / Spotify Modelなどスケール手法を試すところが出てきて、「複数チームの方向性を束ねて力を引き出すにはゴール設定で認識揃えるのが大事だと考える人たちが増えてきた」とかかなーと思っています。 自社でもプロダクトゴールが明確に作れてなかったり、スプリントゴールをフワッと決めてしまうところがあり、今ひとつしっくりきてない感じがあったので長沢さん・稲野さんの発表を踏まえて試行錯誤します。
建設的な議論をカンファレンス中にやりたい
コロナ禍となり、オンラインカンファレンスになってからテキストチャットで感想を伝えるからか「いい話」のようなコメントが増えたような気がしています。
どんなことを言っても受け止めてもらえる場は大事だけど、議論して課題を見つけていく・考えることはもっとやった方が良いんじゃないかなと感じました。気心の知れたメンバーと個別に行っていたり、自社・自分の現場に持ち帰ってあーでもない・こうでもないと話しているような気がします。 できることなら会期中に「こんな意見もあるんだ」という観点を得てもらうのに見える形でできた方が良いなと。単にDiscordに撒き散らしていると荒らしっぽく攻撃しているように見えちゃうけど、RSGTの参加者ならうまくやれる方法を見出せるような気がしたり。
全体として前進できているかな?
プロダクト・現場を良くするため、知見を持ち寄って協力するギャザリングだと思うので、数年単位で見たら変化が感じられるような場であってほしいなと思うようになりました。もちろん新規参加の裾野は広がり続けるし、うまくいったり・いかなかったりを繰り返しながら螺旋のように改善が進んでいくと思うのですが、全体としてどうなんだろうと。一部の人は成功体験を積んで前進しているけど、個人に紐づいている割合が大きいような気がします。
その意味で伊藤さんの発表は考えさせられるポイントがいろいろあるなと感じました。この講演を聞いた人が次世代の社内アジャイルコーチとして業界全体のレベルを引き上げたり、伊藤さんが新たな視点を経てRSGTに戻ってきたりとか、そんな瞬間に立ち合えるといいなと思っています。
自分の4年前を思い出すとできていることが増え・フェーズが変わってきた実感がありますが、参加者全体で見ると参加者・登壇者が開発・アジャイルコーチに寄りすぎていて、もっとステークホルダー(経営層・幹部層)やプロダクトマネージャーなどが増えると良さそうだし、基調講演の反応が変わってきたりするのかなと思いました。
「モノリスからマイクロサービスへ」を読んで考えたこと
2021年に会社で読書会をし、社外の方とも別途読書会をしたほどの本でしたが、タイミングを逃して感想を書いてなかったので残しておきます。
マイクロサービスに取り組む上での基礎や重要事項が丁寧に説明されている
1章と5章が特に良かったです。
- なぜマイクロサービスに取り組むのか。
- 3つの疑問。1. 達成したいこと、2. 代替案がないか、3. 成功の基準。
- マイクロサービスで守るべきこと
などなど。
3章と4章はテコ入れの界面を見定めて徐々に新しステムに切り替えていくストラングラーパターンをサービス内・DBで行うような似た話が続いており、ここを工夫できればもっと短く上手くまとめられそうなのになと感じました。
書籍全体の印象としてはマイクロサービスを考え始めたぐらいの時期から、実際に進めていて壁にぶつかったあたりまでに読むのが良さそうです。 関係者の知識や思想を揃えるにはいい本でした。マイクロサービスを推進していく上での実践テクニックはそこまでカバーされていません。
モジュラモノリスそんなにいいものだろうか
書籍ではマイクロサービスが一押しというわけではなく、なぜマイクロサービスに取り組むのか・モノリスではダメなのかという話も同じくらい重きを置いて説明されています。 デプロイ単位としてまとまっているが、内部の作りは分けられたモジュラモノリスも書籍で触れられていますが、読書会でもモジュラモノリスに惹かれるメンバーがいました。個人の感想としてはモジュラモノリスはフレームワークの後押しが欠かせないと感じていて、知っている限りだと取り組むのに向いているフレームワークはあまりないかなという印象です。強いて言えばRails Engineなのかな?
自社でも一つ、小さなサービスの寄り合いになっているサービスをモジュラモノリスのように作ってみましたが、内部で知らず知らずのうちに依存関係を持ってしまったことが後日わかり、切り離す判断が遅れていたらもっと結びつきが強くなってただろうなと思います。フレームワークで依存関係を防止できるか検出できるようになってないと厳しい印象です。 モジュラモノリスに取り組んでいるところがあればぜひ話を聞いてみたいなと思いました。
マイクロサービス移行は文化の変革である
自社のマイクロサービス移行は数年かけた計画になっており、早くともあと3〜4年かかるかなという見立てですが、書籍でもマイクロサービス移行は文化を変える必要があり、長い時間がかかるとはっきりと書かれています。 自社の力不足や怠慢で時間がかかっているのではなく、開発文化を変えながら進める必要があるためこれぐらいかかるのが当たり前だという時間軸の認識を揃えられたのが良かったです。
異なるプロダクトに取り組んでいる人同士で話すと違った気づきがある
冒頭で触れた通り社内読書会と社外読書会で2回読みましたが、それぞれ違った気づきがありました。
社内メンバーとの読書会は会社のプロダクトの歴史を踏まえ深く議論することができますが、経験が似ているからか観点は偏りがちで、書籍で意図が汲み取れなかった箇所が社内メンバー全員わからずといったこともありました。
社外メンバーとの読書会では、経験・背景が異なるので、「こういう経験があった」「こういうことかと受け取った」といった話を広く聞くことができ、いろんな視点から本の内容を考えることができました。2022年も何かの本を選んで社外の方と話をすると面白いかも。
他に気になっているマイクロサービス本
会社でマイクロサービス導入を始めた2019年に読んでこれは完走しました。だいぶ前の本ですが、内容が大きく古びていることもなく今でもおすすめかと。
まだ未読ですが、「モノリスからマイクロサービスへ」よりも実践的な内容がカバーされている印象を持っています。
2021年11〜12月に社内で共有したアジャイル開発関連の記事
社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。次回からは3ヶ月に1回のまとめに変えてみます。
- 2020年9〜10月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2020年11〜12月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2021年1〜2月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2021年3〜4月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2021年5〜6月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2021年7〜8月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2021年9〜10月に社内で共有したアジャイル開発関連の記事 - tuneの日記
ノウハウ・知見
ハックマンに学ぶ良いチームの作り方
アジャイルなソフトウェア開発に使えるかもしれないメトリクス
スプリントレビューでコンテキストをきちんと共有する
アリスター・コーバーン再考
話が引き継がれるにつれて変わっていくのあるあるですね。
他社事例
ChatworkのScrum@Scale
開発体制、スケジュール、自己採点の仕組みなどが興味深い
はてな MackerelのLeSS事例
マッハバイト(LIVESENSE)のスクラム導入と廃止
よく見る失敗談で、新天地でスクラム入れようと奮闘する人も何割かは直面することになるものばかりだなーと思いました。
Mobility TechnoglogiesのLeSS事例
その他
Women in Agile Japan
いい取り組みだなー、貢献できることあるかなーと思っている間にDiscord招待リンクが切れてしまっていた><
スクラムマスターの一人相撲
スクラムマスターが気を利かして、熱中しちゃって、いろいろ仕掛けや仕組みを1人で作っちゃうと他の人たちにとっての何かを奪っちゃうことになるかもしれないのよね。さらに悪いことには「そういうのはこの人に任せておけばいい」てなっちゃって昔のJenkinsおじさんみたいな存在になるかもしれない
— yoh nakamura (@yohhatu) 2021年11月8日
顧客に予算を持たせて、何を作るか投票させる
スレッドの情報含めて面白い。
昔@kyon_mm さんから聞いた「バックログのつくるときにステークホルダーにお金を持たせて、どの機能にいくら払えるか、みたいなのを投票してもらって決める」みたいな手法ってどこに載ってるやつなんだっけ…
— Lita (@Lita_mjm) 2021年11月22日
だれか覚えてる人いたら教えてほしいです🙏🙏🙏
アジャイル浸透が頓挫する組織の風土
「なぜアジャイルやるの」かを考え続けると、どういう価値観を持っているかという哲学の話になるので、そこに自分たちなりの答えを出せない組織・チームでは浸透しなかったり、失望して辞めてしまうんだと思う。
— ama-ch (@ama_ch) 2021年11月25日
作り方がわかる人がいないのに決めたがる不思議
作り方がわからない人だけが集まって要件定義するのだけ、是正できれば、だいぶうまくいくのでは？って思うことが多い。っていうか、何かを作る作業の中で、作り方がわからない人だけでやる時点で失敗が近づいてる。それをウォーターフォールのせいにしてほしくない。
— Yasunobu Kawaguchi (@kawaguti) 2021年12月3日
不確実性を人に押し込めるのがアジャイル?
自分は
— ところてん (@tokoroten) 2021年12月21日
不確実性を計画に押し込んで見なかったことにするのがウォーターフォール
不確実性を人間の能力に押し込んで見なかったことにするのがアジャイル
という説明はたまにする https://t.co/BmRkQnSqxO
知的コンバットできていますか？
この記事はAdvent Calendar for upcoming Regional Scrum Gathering Tokyo 2022 Advent Calendar 2021 25日目の記事です。自分がRegional Scrum Gathering Tokyoに初めて参加したのが2019年のこと。2020年は会社でスポンサーでき、2021年は同僚が登壇して、2022年は自分が登壇できることになりました。今所属しているRettyはアジャイルに・大規模スクラム(LeSS)に取り組む会社としてある程度認知いただけるようになった感触がありますが、年初にRSGTでエネルギーを貰えているのが助けになっている気がします。
知的コンバットによりイノベーションを生み出す
※ 注 : RSGT2021での野中先生基調講演動画はRSGT2022開催までの期間限定公開だそうです。
RSGT2021の最終日の基調講演で野中先生から投げかけられた言葉「知的コンバット」。これまで自分が探究していきたいことを「顧客にとって価値のあるプロダクトを、チーム一丸となって協力し、短期間にリリースする開発体制のあり方」と表現していましたが、もっと端的に短く・もっと情熱がこもった言葉を聞くことができ、この1年間自分の頭から離れないキーワードとなりました。
全身全霊で向き合うためには二人、ペアであることが最適です。同時に、双方の目線が上向きや下向きではなく、真っ当に向き合っていることが大事です。それでもそう簡単にはコンセプトは出てきません。「知的コンバット」を何度も繰り返す必要があります。双方が感じた異なる直観を、真剣勝負で何度もぶつけ合いながら、ようやく「こうとしかいえないよね」というコンセプトにつながっていくという感じです。この「共同化」のプロセスがない限り、組織で「知」を生み出す、イノベーションが起こるということはあり得ません。
※ 【野中郁次郎氏対談】第2章 徹底的な対話による「知的コンバット」なくして、イノベーションは生まれないより引用
「プロダクトオーナーが決めたプロダクトバックログの優先順位に従って開発を行う。開発チームは固定期間で区切ったスプリント内でインクリメントを作成し、リリースして得られた学びから次に何をしていくべきかを改めて考える。」こうして不確実なプロダクト開発に挑戦してくのがスクラムですが、真に優れたプロダクトを作る・イノベーションを生み出していくにはもっと真剣に自分たちが取り組む対象に向き合い、議論を戦わせていかなければなりません。
知的コンバットは難しい
「議論が大事だから意見を戦わせよう。職責やロールにこだわらずやっていこう。」と言うのは簡単ですが、実際に起きるのはレベルが低いケンカとトラブルです。 「セールス・企画・開発で納得のいく計画・プロダクトを作りたいのでお互いに意見を伝え合おう」と言うと、率直な意見が攻撃と受け取られ、職責を超えた提言が信頼感の欠如として受け取られてしまいます。「なぜ取り組むのか」「なぜ今なのか」「もっとよい打ち手はないのか」「何を学ぼうとしているのか」、プロダクト開発に真摯に向き合い本質に迫ろうとする問いほど、その山を知らなかったり、登り始めたばかりの当人にとっては致命傷となるマサカリになります。
HRT(Humility, Respect, Trust)を心がけた発言に、ドメインの理解や背景の共有、相手との信頼感を醸成し、人・相手ではなく問題・ゴールに目を向けて話す。ここまで段取りを整えてようやく知的コンバットの入り口に立てそうというのが私の正直な感想です。
RettyのAdventCalendarでプロダクトマネジメント組織で浸透した7つのキーワード(①PMスキル定義・評価制度, ②アウトカム, ③ロードマップ, ④事前検証, ⑤問いを立てる力, ⑥既知と未知, ⑦因果ループ)を野口がまとめてくれていますが、知的コンバットの土台となるこれらを浸透させるだけで1年です。長い道のりです。
知的コンバットの実現に手応えを感じた出来事
知的コンバットと呼べるような議論の成功を目指し、うまくいったりいかなかったりを繰り返しながらの開発でしたが、「知的コンバットとはこう言う状態なのでは?」と手応えを感じたことがありました。その出来事の直前は1ヶ月弱ほど中規模プロジェクトの開発に取り組んでおり、その振り返りで「実はプロジェクトの序盤からうまくいってないもやもやを抱えていて、良くないと思っていました」という告白を複数人から聞いたことがきっかけです。「その時言っておけばもっと違った今があるかもしれないのに」と静かな怒りを覚えたのをとてもよく覚えています。
ふりかえりで「実は自分もあの時そう思ってたんですよ」って発言するのは”その時言っとけよ”って思うし、”みんなで吐き出したいいふりかえりができた”感を生み出すのでかなりギルティなのではないか
— Yuichi TSUNEMATSU (@tunepolo) 2021年12月2日
その次のスプリントではスプリントプランニングにいつも以上の時間と熱量をかけました。「次のスプリントに何を取り組むべきか」「プロダクトオーナーの優先順位に質問はないか」「開発観点で先に取り組むべきことはないのか」「言うならこのタイミングだぞ、終わってから意見の後出しだめだぞ！」「本当に納得したか?」とかなり口すっぱく確認し、そこからチームの動きや成果が大きく改善された気がします。
本当に足りなかったのは熱量なのかも。
この記事を書きながら思い返してみると、タイミングやプロセス、知識の問題もあったかもしれませんが、それ以上に熱量が足りてなかったのかもしれません。 その後のメンバーとの1on1で気持ちを込めたアドバイスを多く送った気がします。
- 相手に言っても聞いてくれないじゃない、聞いてもらえるように言うんだ。
- 聞いてもらえるために「背景を説明する」「費用対効果を説明する」「時には感情を込める」「めげずに何度も言う」など色々試す。
- 「コミュニケーションが足りない」とはどういうことなのか。真の問題から目を背けているのではないか。
- あとでふりかえりをしたらダメだったことが良かったことに出来るわけではない。勇気を出していつでも言うべき。
終わりに
「真剣勝負で意見をぶつけながら、こうとしか言えないコンセプトを作り上げる」を達成した瞬間の楽しさは何ものにも代えられません。 「知的コンバット」の実現に必要な土台は準備は簡単ではありませんが、こうした経験が積める場を作れつつあることがマネージャーとしての今年の成果かと思います。
今日の話は「協働でゴールに向かう"チーム環境"」に関する話ですが、RSGT2022では「高速に石橋を叩いて渡る"開発環境"」の話をします。来年もRSGTでエネルギーを補充し、イノベーションを産む原動力を養っていきましょう。