怒りを感じた時にできる「ちょっとした」工夫
「最近怒りっぽくなったな〜(アカン)」という自省に基づくポエムです。
事例
皆さん、このような経験はありますか?*1
- 上司から、隣のチームへ書類を提出するよう頼まれた
- 実際に書類を提出してみると、隣のチームから「この書類はなんですか?」と言われた
このような場合、私は即座に「なんですかとは何だ」「何で事情を把握していないんだよ」「バカにしているのか」と考え、怒りを感じがちです。*2
ポイント
上記の事例は、自分の前提と違うことが起きたことが、怒りのきっかけです。
- 上司は、隣のチームへ、私から書類が提出されること教えているはずだ/べきだ
- 隣のチームは、書類が提出されることを知っているはずだ/べきだ
- 隣のチームは、書類が提出されたら受け取るはずだ/べきだ
「〜いるはずだ/べきだ」という言葉が多いですね。
しかし、ちょっと冷静に考え直してみると、上司から隣のチームに話がそもそも届いていない可能性もあり得るんですよね。その場合、隣のチームにとってみては、「書類を出されたけれども何これ?」と反応するのが自然なんですよね。
この種の怒りと付き合う工夫
自分の前提と違うことが起きたら、自分の頭の中にある「〜いるはずだ/べきだ」を探し、それを疑ってみましょう。
- 自分の前提は、勝手な思い込みであることが往々にしてある*3
- 相手も、そもそも困っている可能性がある
- お互いに、共通の問題に直面している可能性がある
その上で、一つ一つお互いの前提を確認し合い、ズレを見つけた上で、一緒に解決策を見つけるようにすると、自分にとっても相手にとってもwin-winになれます。
また、「重要な前提をお互いに共有されていないのでは?」という仮説を立てられると、相手への敵意が減り、問題解決へ意識を向けやすいです。
さいごに
正直、常にこのように振る舞い続けることは、今の私にはまだ難しいところが多いです。
一方で、国籍・バックボーンが異なる人たちとのやりとりの増加、会社・組織のスケールアップ、物事の複雑度の向上など、連絡の行き違いや前提のズレは、昨今どうしても増えがちです。
なので、自分の前提と違う場面に遭遇したら、自分の前提を一旦「脇に置いて」*4、お互いの前提のズレを見つけることに注力すると、怒りよりも知的好奇心を高められ、結果課題を解決しやすくなります。
参考資料
NVC 人と人との関係にいのちを吹き込む法 新版 (日本経済新聞出版)
- 作者:マーシャル・B・ローゼンバーグ,安納献
- 発売日: 2018/04/20
- メディア: Kindle版
- 作者:加藤 一二三
- 発売日: 2019/10/03
- メディア: 単行本
カンファレンスのプロポーザルの書き方!2021
今朝起きてスマホをみたら、しいばさんからこんな通知が届いていました。
たしかに @hageyahhoo さんのプロポーザルはいつも伝わってくる。すごいよなぁ。
— Mitsuyuki Shiiba (@bufferings) 2021年3月13日
Scrum Fest Osaka のプロポーザルを世界最速で眺める https://t.co/yDPIQDRahR
教えていただいた「Shinagawa Agile Talks」で、47:30くらいから、確かに私のセッションプロポーザルの書き方を、参考例の一つとして紹介していただいていました。
「お手本になるプロポーザル」として紹介していただいた例は、こちらになります。
https://confengine.com/conferences/regional-scrum-gathering-tokyo-2021/proposal/14621/tips-of-product-management-for-internal-tools
ちょうど良い機会+需要も多少ありそうですので、私が意識・工夫しているカンファレンスのプロポーザルの書き方のtipsを、以下に簡単にまとめてみました。
1. アウトラインが中心
アウトラインは、プロポーザルを書く際に一番重視している箇所です。
なぜならば、自分を知らない人たちに対して、自分が提供したいトーク・ワークショップのイメージを、最も「いきいきと」伝えられる箇所だからです。
具体的には、以下のような工夫をしています。
- セッションの全体構成を、ツリーで表現する
- ミーティングの前に、参加者にアジェンダを共有することと同じです。
- どのようなトピックを、どのような論理構成で伝えるつもりなのかを明示できるため、プロポーザルの内容をよりクリアにできます。
- プロポーザルが通った際は、これをベースに資料を作れば良いため、時間を節約でき、より良い内容にブラッシュアップし続ける余裕を生み出せます。
- 各トピックの、おおよその時間見積もりを明記する
- 上記のツリー情報を、さらにイメージしやすいものとして伝えやすくなります。
- カンファレンスの運営側に対しても、タイムスケジュールやスタッフの方の仕事量などを把握しやすくするメリットを提供できます。
- プロポーザルが通った際は、資料のページ割り当て量の参考にできます。
- アイデアの伝え方も明記する
- どのタイミングで
- 例:1章の最初に
- どのように伝えるつもりか
- 例:xxxという質問を参加者に出し、アイデアを出してもらう(3分)
- その結果セッションをどうしたいか
- 例:参加者が、xxxという課題をより「自分ごと」として理解しやすくなる
- 例:参加者が、xxxという課題をより「自分ごと」として理解しやすくなる
- どのタイミングで
アウトラインは、そのプロポーザルがReady状態であることを明確に伝えられる箇所です。まずはここを最優先で書きましょう。
2. 「一目」におさめる
関連する情報を、画面をスクロールせずに一目で把握できるよう、常に文量とレイアウトを工夫しています。
Confengneを例にすると、以下の情報を、ブラウザのデフォルトのフォント設定で「ちょうど」1画面内におさまるように記述します。
- タイトル + 概要
- アウトライン
- Learning Outcome + Target Audience + Prerequisites for Attendees
- Links
画面スクロールは、文章を読む際のストレスになり、内容把握の妨げになり得ます。そのため、読者に画面スクロールを強いないことは、プロポーザルの可読性の向上につながります。
3. 「3」を保つ
アイデアや箇条書きなどは、極力3つにするようにします。
これは、とあるコンサルタントの方から教えていただいた、提案の選択肢の数が与える心理的効果を考慮しています。具体的には、
- 2つ:少なすぎて、十分考えていないのでは?という不安感を与えてしまう
- 4つ以上:多すぎて、情報を整理できていないのでは?という不安感を与えてしまう
- 3つ:必要十分に考えて整理されているという安心感を与えられる
このような方法でも、読者に心理的安心感を提供し、プロポーザルへの関心・共感を高められます。
さいごに
上記内容は、些細なことに思われるかも知れませんが、大きな差を生む小さな工夫です。
実は、私の過去のプロポーザルも、内容自体は皆さんとあまり差がありません。それでも私のプロポーザルが採択されたことが多めだったのは、このような「見せ方の工夫」を他者よりも意識して実践していることにあると認識しています。
これ以外にも工夫していることはまだまだありますが、いずれも他者のプロポーザル・資料・発表内容を観察し続け、自身が実験を繰り返して検証して身につけていったものです。
ヒントは、あちこちに転がっています。皆さんもそれらに目を配らせ、自身のプロポーザルのスタイルを確立してみてはいかがでしょうか。
テキストベースでの自身の仕事・時間の管理術
先日、会社の同僚たちとの雑談で、「お互いに日々の業務で工夫している仕事・時間の管理術を紹介し合ったら面白そう」という話になりました。そこで、私がここ7-8年実施している工夫を、以下に簡潔にまとめてみました。一つでも読者の方のプラスになるアイデアがあれば幸いです。
1. SetUp: 一日の業務を始める時
毎朝、以下のルーティンを実施しています。
1) その日の仕事をリストアップする
認識・把握している範囲で良いのでリストアップします。会議など時間が決まっているものは、実施時間も明記します。
2021/03/06 ・部の定例MTG(15:00 - 16:00) ・A機能のPull Requestのレビュー ・B報告書の提出
2) 仕事を実施する順に上から並べ替える
併せて、実施時間が決まっている仕事には、🔴などの一目で分かる印をつけます。
2021/03/06 ・A機能のPull Requestのレビュー ・B報告書の提出 ・🔴部の定例MTG(15:00 - 16:00)
2. Process: 業務中
1) 実施する仕事に印をつける
自分が分かる印で良いので、これから実施する仕事に印をつけます。以下では⭐️を使っています。
2021/03/06 ・⭐️A機能のPull Requestのレビュー ・B報告書の提出 ・🔴部の定例MTG(15:00 - 16:00)
2) 完了した仕事に印をつける
仕事が完了したら、自分が分かる印をつけます。以下では🟢を使っています。
2021/03/06 ・🟢A機能のPull Requestのレビュー ・B報告書の提出 ・🔴部の定例MTG(15:00 - 16:00)
3) 突発的な仕事が来た場合
システムトラブルなど、当初予定していなかった仕事の実施が必要になった場合は、実施順序を考慮した上で仕事のリストに追加します。また、その日に終えられない仕事が出てきた場合は、次の日のタスクに移動します。
2021/03/07 ・B報告書の提出 2021/03/06 ・🟢A機能のPull Requestのレビュー ・⭐️Cシステムのエラーの原因調査 ・🔴部の定例MTG(15:00 - 16:00)
4) 気付き・発見の明記
後日上長や他チームに共有した方が良い情報などが見つかった場合は、その情報をリストに追記します。
2021/03/07 ・B報告書の提出 2021/03/06 ・🟢A機能のPull Requestのレビュー ・🟢Cシステムのエラーの原因調査 ・💡既存のアラート機能では把握できないもの -> Dチームに改善を依頼する ・🔴部の定例MTG(15:00 - 16:00)
3. TearDown: 一日の業務を終える時
最終的に、以下のようになるはずです。
2021/03/06 ・🟢A機能のPull Requestのレビュー ・🟢B報告書の提出 ・🟢部の定例MTG(15:00 - 16:00)
印を全て削除して、一日の業務を終えたサインとします。
2021/03/06 ・A機能のPull Requestのレビュー ・B報告書の提出 ・部の定例MTG(15:00 - 16:00)
4. 一週間・一ヶ月の業務を終える時
終了した仕事のリスト一週間は、そのまま週報にできます。
同じ理屈で、一ヶ月分のリストは、そのまま月報に活用できます。
一連の工夫の動機
- この工夫を始めた当時、とても一日ではこなせない量の業務依頼・メール・会議依頼が毎日届くようになった時期で、何らかの取り組みが急務でした。
- メール・カレンダー・JIRAなど複数の情報ソースが存在していて、かつそれらの行き来が遅くて苦痛だったため、手軽に一箇所で情報を扱える仕組みが個人的に好ましかったです。
- ちょうど当時、Atlassian社のConfluenceの操作方法を業務上急ぎ覚える必要があり、勉強の一環で少しずつ試してみたところ、徐々に上記の仕組みを確立していきました。
個人的に感じているメリット
- JIRA・Trello・付箋などのタスクボードと比較しても、実施が手軽です。
- 仕事に対する心の余裕を生み出せます。
- 現状把握が容易になります。
- 頭の中にだけ情報がある時と比較して、忘れるのでは?という不安感を解消できます。
- 頭の中にだけ情報がある時と比較して、思い出すためのエネルギーを減らせます。
- スケジュールの調整がしやすくなります。
- 仕事が大量に来たとしても、調整箇所を特定しやすくなるため、考える余裕を持てます。
- 会議など、実施時間が決まっている仕事の見落としを減らせます。
- 作業の実施順序や優先順位を考える訓練にもなります。
工夫の背景にあるアイデア
- 仕事のリストを書き出して、終わったものに印をつけるアイデアは、Getting Things Done (GTD)と、Kent BeckのTDDの本からヒントを得ています。
Test Driven Development: By Example (Addison-Wesley Signature Series (Beck))
- 作者:Beck, Kent
- 発売日: 2002/11/08
- メディア: ペーパーバック
- 一日単位での仕事のリストアップと優先順位付けのアイデアは、スクラムのプロダクトバックログおよびスプリントバックログを、個人の作業に応用してみたものです。「個人バックログ」と雑に呼称しても良いかもです。
- 一日の終了時にリストから印を消すアイデアは、スクラムのバーンダウンチャートをヒントに、毎日達成感を感じられるようにしようというのが狙いです。
- テキストベースを続けていることは、レポート作成の効率化も意識しています。また、社外カンファレンスなどでの登壇資料作りのメモとしても活用しています。
おわりに
上記の工夫は、あくまで私が自身の知識・経験の範囲内で、実験を繰り返して有効だと考えて続けているものです。
もっと他に良い方法は、まだまだたくさんあると思います。
もしより良いアイデアをお持ちの方がいらっしゃいましたら、教えていただけるとありがたいです。
自分自身の答え合わせとふりかえりの場だったRSGT2021
2021年の1月6日(水)から8日(金)まで、Regional Scrum Gathering Tokyo 2021(RSGT2021)に参加させていただいていました。
イベントそのものに関するレポートは既に多くの方が書かれているので、私はイチ登壇者としての視点からの個人的体験をまとめてみます。
※他の方のレポートは、こちらから見つけられます。
1. 登壇による「現場での経験」の答え合わせ
学術や理論を整理して話すことに(私よりも)長けた方々が既にたくさんいらっしゃるので、私は「現場での経験」、特にソフトウェア開発の実務での実験・失敗・発見の生々しい話、実践知にフォーカスしてお話させていただくように心がけています。
特に今回は、「SET」(テスト自動化やDevOpsなど、特に技術的アプローチからアジャイルを推進するロール)として社内ツール群を提案・開発・運用し続けた経験をもとに、社内ツール視点でのプロダクトマネジメントについてお話させていただきました。
開発者主体だとどのような行動・失敗をしがちなのかという情報とその克服案を、アジャイルコーチ・アジャイルを実践中の方・アジャイル初心者の方いずれにも提示して、私自身および参加者の双方に考える場を提供しようというのが、私のねらいでした。
その点では、「SETという役割・チーム自体が私たちのプロダクトとも言える」という視点を得られたことが、私的には大きなプラスでした。
2. 「共に苦しんで共感を育むこと」の裏付け
私は昨年のRSGT2020の発表で、「共感・思いやり」に「compassion」という英単語を当て、
- この「compassion」の語源がラテン語の「compatio」であること
- 「compatio」の意味が「共に苦しむ」であること
- 同僚や支援先チームと一緒に問題解決に取り組んで「共に苦しむ」ことで「共感」を育くみ、課題解決を加速させる
という話をさせていただきました。
これと近しい考え方が、クロージングキーノートの野中郁次郎さんの発表にも出てきて、自分自身の気付きと発表内容に裏付けを得られたことが非常に嬉しかったです。
ちなみに、「共感」に「empathy」の英単語を当てていたら、上記の考えには気付きにくかったです。怪我の功名でした。
3. フラクタルな組織「だった」(いろいろな意味で)
私自身、アジャイルコーチになって「多くの観察から自分自身を成長させられてきた」経験とその喜びから、これを他の人や組織にも広げたいと思い振る舞い続けてきました。
また、私自身が数年前に体調を崩したことから、私がいなくても自律的に考え成長し続けられるチームづくりを心がけていました。私がリーダを務めるSETチームは、それを志向し続けています。
加えて、そのような個人・チームは、上位の組織(あるいは会社)を「乗り越えて」価値を提供し続けられる強みがあるとも考えていました。
これらを「フラクタル」という考え方である程度整理できること、一方で適切な言語化を私自身ができていなかったことで周囲に伝え切れていなかったな〜という反省を得られたことが、今回のカンファレンスでの1番の個人的収穫かもしれません。
というわけで、早速こちらをいま読んでいます。
4. 私だからできる「貢献」を
- より「アピールしやすい」プロポーザルの書き方の工夫・アイデアを、数度にわたってDiscordでお話しさせていただきました。今回のカンファレンスで「話をしてみたい!」と思われた方の背中を押せれば嬉しいです。
- 私なりのプレゼン資料の書き方の工夫・アイデアを、数度にわたってDiscordでお話しさせていただきました。長沢さんとは別の視点から、アジャイルコミュニティに9年ほどいる私自身の「秘伝のタレ」を「伝授」しましたです。
- 参加者の多くに、特にスマホアプリのテスト自動化に悩まれている方が多かったので、「お互いにコミュニティ活動を通じて知見を共有し合おう」と提案させていただきました。ちょうど同僚が同じ目的で「てすらぼ」というコミュニティを運営していたので、こちらを紹介させていただきました。続きはここで議論しましょ〜
さいごに
ちょうどコロナ禍の拡大で判断が難しい状況で、このような素晴らしい機会を提供してくださったスタッフの皆さま、参加者の皆さま、応援してくれた同僚のみなさんに感謝です。
また、Among Usを一緒にプレイしてくださった方にも感謝です。(またやりましょ〜!)
中国のカンファレンスで自社プロダクトを英語で発信してきた
2020/12/20(日)に、中国の「TOP 100 Summit 2020」というカンファレンスで、私たちのチームの新プロダクト「Testable Infra」についてお話させていただきました。
こちらが、カンファレンスの情報になります。
同カンファレンスは、プロダクトマネジメント・テスト・DevOps・SREなど、ソフトウェア開発の幅広い領域の事例を100個集め、それらを4日間かけて発表し合うという、なかなか大規模でガチ幻想をかき立てられるものです。
私のセッションの情報はこちらです。
(バナーは上と同じに見えますが、きちんと個別ページにジャンプします)
こちらが、私の発表資料になります。
今回は、登壇の経緯と、登壇に際して工夫した点を、今後海外で英語でプレゼンしたい!という日本の方むけに説明させていただきます。
加えて、今回発表させていただいた「Testable Infra」のポイントを、アジャイル・テスト自動化・Kubernetesのいずれかに興味ある方むけに説明させていただきます。
1. 登壇の経緯
過去に同カンファレンスに登壇したことのある、台湾の同僚からの紹介がきっかけでした。カンファレンス主催者から彼のもとに「スピーカー候補いませんか?」という打診があり、ちょうど登壇予定だったアメリカのAgile2020がキャンセルになって力を持て余していた私に白羽の矢が立ちました。
※ちなみにAgile2020についての詳細はコチラです
今回は、以下の要因が組み合わさって、登壇の機会を得ることができました。
- 私自身、社内外・国内外での登壇経験があること
- カンファレンスでの登壇経験のある、外国籍の同僚が身近にいたこと
- 登壇に関心がある者同士として、「類友」の関係を築けていたこと
2. 登壇に際して工夫した点
今回は、特に以下の3点を工夫しました。
1) 英語のプレゼン動画での反復練習
特にカンファレンスでのプレゼンならではの英語の言い回しのレベルを高めようと、Youtubeなどにあがっているプレゼン動画を何度も観て、そこで気がついた点を反復練習して、自身の発表に取り入れました。加えて、今回の発表はKubernetesの比率が高かったため、KubeCon(Kubernetesのグローバルカンファレンス)の動画を特に観ました。
2) 関連トピックの会話に慣れる
プレゼンだけではなく、関連トピックのカジュアルな会話や語彙にも慣れようと、特にこちらのPodcastを頻繁に聴いていました。
3) 社内で素振り
本番前に、社内の所属部署で「事例紹介」と称して、発表練習をさせてもらいました。素振りなので失敗しても安心ですし、発表経験自体も積めるので、メリットが非常に大きいです。
また、機会をくれた同僚に対して、お礼と準備万端であることの両方を伝える意図も兼ねました。
3. 「Testable Infra」のポイント
ここでは、発表させていただいた「Testable Infra」のポイントを、3つ紹介させていただきます。
1) テストのし辛さを生み出す3つの要素
これまで長年、様々な会社・プロダクトで、「テストがし辛くてバグを見逃して障害を起こしてしまった」事例と向き合ってきました。それらを整理・分析すると、大体次の3つのいずれか/どれもが原因であることが多いです。
- テスト環境:環境自体がない、準備が面倒、環境ごとの差分が大きすぎてテストを信頼できなくなる
- テストデータ:他の人と共有するとテストを壊す/壊される恐れが高い
- 外部システム:準備しづらい、環境ごとの接続設定の変更が面倒
2) 「Immutable Infrastructure」をCloud-nativeに実現
様々な試行錯誤を繰り返した結果、「Immutable Infrastructure」の考え方を、Docker・Kubernetes・Istioなどを組み合わせることで、上記の問題を解決できるのでは?との考えに至り、「Testable Infra」を構築してみました。
具体的には、Pull Requestが作成されたら、それをテストするために必要なDockerコンテナを作成し、それらをテスト用に作成したKubernetesのnamespace上にdeployし、そこに対してE2E Testを実行する仕組みをまず構築しました。
3) 構築・運用の際の工夫
新規の試みだったことから、以下の手法を組み合わせることで、構築・運用をより「効果的」にしました。
- 開発初期からDevOpsの仕組みを構築し、必要な時に最新の動作するソフトウェアを見せられるようにした
- 「Product Discovery」や「Design Sprint」を活用して、仮説設定・検証を繰り返した
- 失敗を学習機会として積極活用し、プロダクト・プロセスの改善につなげた
※「Testable Infra」の概要については、こちらもご覧ください。
さいごに
日本での登壇も工夫する点や面白いことは多いですが、海外で母国語以外で登壇するとなると、その国の文化や言語ならではの言い回しなどにも工夫の余地が出て面白いです。
また、昨今はコロナの影響もあって、「Zoomなどのビデオ会議システムで時差さえ埋められれば国籍を超えて登壇しやすい」という状況でもあります。
コロナには最新の注意を払っていく必要がありますが、一方で新たに生まれた機会は、積極的に利用しても良いと思います。
アジャイルコーチ同士のスクラムガイド雑談会2020
2020年11月18日(水)に、スクラムガイドの最新版がリリースされました。
それを受けまして、アジャイルコーチの中村 洋さんからお声がけいただき、11月23日(月)朝に同ガイドの内容に関する雑談(1 on 1)をさせていただきました。
1時間半を超える熱のこもった内容になりましたので、せっかくですので内容を備忘録として書き出してみました。同ガイドの読み方・解釈方法の1意見として読んでいただければ幸いです。
ちなみに、中村さんは日本語版を、私は英語版を読んだ上での雑談です。その違いも含めて楽しんでいただければ〜
1. スクラムガイドの目的
スクラムの核となるデザインやアイデアを変更したり、要素を省略したり、スクラムのルールに従わなかったりすると、問題が隠蔽され、スクラムの利点が制限される。 (日本語版 1ページ)
- (中村)この「問題が隠蔽され」という点は、スクラムに取り組む理由の一つとして(自分自身がコーチ先のチームなどに)説明することがある。
- (伊藤)この記述を含め、今回のガイドは全体的に透明性・検査・適応とその相関関係とを強調している印象。
2. スクラムの定義
スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである。 (日本語版 4ページ)
- (中村)スクラムマスターの必要性を明記している点が興味深い。単なる会議のファシリテーターとかではないことを強調する必要が出てきたのかも?
- (伊藤)それは確かにありそう。一方で、各ロールとその相関関係を含め、文字通りここで「スクラムの定義」を簡潔にまとめ、全体の見通しを良くしようという著者の強い意図を感じた。
スクラムフレームワークは意図的に不完全なものであり (日本語版 4ページ)
- (中村)「不完全」の解釈が分かれそう。自分は、1) プロダクトバックログの書き方や使用ツールといった、実践方法の詳細を明示していないという意味合いと、2) 仮説設定・検証やマーケティングなど、スクラムの「外側」のプロセスを明記していないことと捉えた。
- (伊藤)自分は、「イノベーションのチャンス」と解釈した。スクラムはフレームワークのベースラインだけの定義にとどめているため、実践時は各ドメイン・プロダクトに合わせた肉付けが必要。そこに各実践者の工夫や、スクラム自体を豊かにする余地があるのだと捉えた。
3. スクラムの理論
「リーン思考」の「リーン」は、「ムダを省き」という記述があるので、「リーンスタートアップ」ではなく「リーンソフトウェア開発」を指すだろう。
4. スクラムの価値基準
スクラムチームのメンバーは、スクラムのイベントや作成物を用いながら、これらの価値基準を学習および探求する。 (日本語版 5ページ)
- (中村)日本だと、(確約・集中・公開・尊敬・勇気といった)価値基準及びそれらの学習・探求の必要性をあまり明言していない印象。
- (伊藤)確かに日本では、これらを明示的に話していないかも。そういえば、Kubernetes Podcast from Googleなどを聞いていると、海外の団体・コミュニティなどでは、これらの重要性を明言していることが多いかも。
- (中村)日本のSIer所属のアジャイルコーチをみていると、こうした発想自体を持っているのか疑問に思うこともある。
- (伊藤)日本のSIerだと、一定期間過ぎたらチームが解散する「プロジェクト」の思考に馴れていることが多くて、中長期的思考を持ちづらいということはあるかも。
5. スクラムチーム
自己管理型であり、誰が何を、いつ、どのように行うかをスクラムチーム内で決定する。 (日本語版 6ページ)
自己「組織化」から自己「管理型」に記述が変更されている。意思決定の責務を、(POを含む)スクラムチームとして持つことを明示したのでは?
スクラムチームは、ステークホルダーとのコラボレーション、検証、保守、運用、実験、研究開発など、プロダクトに関して必要となり得るすべての活動に責任を持つ。 (日本語版 6ページ)
- (中村)「すべての活動」とはどこまでを指すのか?例えば「検証」は、リサーチャーが行うプロダクトの仮説設定・検証を指すのか?
- (伊藤)仮説設定・検証も含めて「すべて」ではないか?ちなみに(会社の)自分のチームでは、大変ではあるがこれらをすべてやっている。
- (中村)「責任を持つ」の記述が重要。他チームなどに助けを求めてでも「活動に責任を持つ」という意味であって、自分たちが実施する責任(=自力でやらなければならない)という意味ではないと思う。
- (伊藤)ですね〜
5.1. 開発者
完成の定義を忠実に守ることにより品質を作り込む。 (日本語版 6ページ)
「完成の定義」という言葉がここに出てくるようになったことは、大きな変化だと思う。プロダクトの「作り込み」を強調する意図があるのかも。
一方で「品質の作り込み」は、スクラムガイドだけでは情報不足。ソフトウェア開発ならば、XP・CI/CD・DevOpsなどを取り入れる必要がある。
5.2. プロダクトオーナー
プロダクトゴールを策定し、明示的に伝える。 (日本語版 7ページ)
- (中村)「プロダクトゴール」を明記するようになったのは、スプリントだけを回して結果プロダクトのゴールを見失いがちになるスクラムチームが多かったからかも?
- (伊藤)それはありそう。書籍『A Scrum Book』でも、プロダクトバックログのインプットとしてのVisionやProduct Roadmapに多くの記述を割いていた。
A Scrum Book: The Spirit of the Game
- 作者:Sutherland, Jeff,Coplien, James O.,Heasman, Lachlan,den Hollander, Mark,Ramos, Cesario Oliveira
- 発売日: 2019/09/03
- メディア: ペーパーバック
5.3. スクラムマスター
スクラムマスターは、スクラムチームと、より大きな組織に奉仕する真のリーダーである。 (日本語版 7ページ)
- (中村)「組織へのリーダーシップ」を明示したことは、大きな変化だと思う。チーム内だけに留まって、本来の価値を発揮していないスクラムマスターが多かったのでは?
- (伊藤)それはありそう。私たちはJames Coplienさんの認定スクラムマスター研修を一緒に受講して、Red Pill、既存の枠組みを外れてでも貢献する重要性を叩き込まれたので、「組織へのリーダーシップ」が当たり前になっている。それを全員が持っているわけではないので、明示には意味があると思う。
6. スクラムイベント
6.1. スプリント
スプリントゴールの達成を危険にさらすような変更はしない。 (日本語版 8ページ)
- (中村)「危険にさらすような変更」には、どのようなものがあるか?
- (伊藤)(考慮不足の)APIの破壊的変更など、スプリント内では対応しきれないようなうっかり追加作業。CI/CDをやっていると予防はできる。やはりスクラムガイドだけでは不足かも?
すでに発生したことだけが、将来を見据えた意思決定に使用できる。 (日本語版 9ページ)
- (中村)一連の文章で言いたいことはなんだろうか?(日本語の文章がやや複雑)
- (伊藤)メトリクスなどの「過去の」実績情報をベースに、経験主義的に行動しましょうという程度の意味では?(英語で読んだから詰まらなかった?)
6.2. スプリントプランニング
キャパシティ (日本語版 10ページ)
- (中村)「キャパシティ」は、時間・日数の意味か?
- (伊藤)Capability、学習の要素なども含む、広い意味での「能力」の意味合いではないか?自分がコーチングをする場合は、これを伸ばすタスクを意図的に追加したりしている。
6.3. デイリースクラム
プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加する。 (日本語版 10ページ)
- (中村)これは、(本来は禁止されているはずの)ロールの兼任をしろという意味なのか?
- (伊藤)帽子の被り直し程度の意味では?デイリースクラムの参加者を開発者に限定している旨の、前段の記述とも符合する。
6.4. スプリントレトロスペクティブ
スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することである。 (日本語版 11ページ)
「効果」は、プロダクトとプロセスの両方を指す。
スクラムチームを迷わせた仮説があれば特定し、その真因を探求する。 (日本語版 11ページ)
「仮説」は、プロダクトとプロセスの両方を指す。
スクラムチームは、自分たちの効果を改善するために最も役立つ変更を特定する。最も影響の大きな改善は、できるだけ早く対処する。 (日本語版 11ページ)
- (中村)「最も」と明記しているのは、改善項目をたくさん実施しても無駄が多いなどの点を指摘している?
- (伊藤)おそらくそう。TOC(Theory of Constraints、制約理論)の、「多くの問題は、少数の原因による」という考え方と同じではないか?
7. スクラムの作成物
プロダクトゴールは、スクラムチームの⻑期的な目標である。次の目標に移る前に、スクラムチームはひとつの目標を達成(または放棄)しなければならない。 (日本語版 12ページ)
- (伊藤)「達成または放棄」とは、プロダクトのPivot(方針変換)のことを指すのではないか?
スプリントゴールはスプリントの唯一の目的である。 (日本語版 12ページ)
- (中村)スプリントゴールは、1つにした方が良いでは?
- (伊藤)同意。もし複数必要になる場合は、ゴール間の優先度設定が重要。
7.1. インクリメント
また、すべてのインクリメントが連携して機能することを保証するために、徹底的に検証する必要がある。 (日本語版 13ページ)
- (中村)「徹底的に」という言葉が興味深い。リグレッションテストの重要性と、技術的プラクティスを軽視する近年の風潮への警鐘の意味合いがあるのでは?
- (伊藤)同意。技術的プラクティスがあって初めて、スクラムガイドが示す「徹底的な検証」ができる。
8. 全体
自分たちのような経験を積んだ実践者にとっては読みやすくなった一方で、初学者にとっては曖昧すぎて読みづらい内容になっているかも?
- 経験のあるコーチが、初学者とペアないしモブを組んで教えることを「前提」としないと辛いかも?
- 一方で、コーチの知識・経験を活かして初学者を導くスキームが想定されているかも
- 聖書と牧師さんの関係が似ているかも
最後に
同じアジャイル実践者でも、積んできた経験の差でこれだけ解釈が割れるのかという驚きと、その解釈の差を共有し合うことでさらに理解を深められる面白さの両方を体感できました。
このような雑談は、是非皆さんにもお勧めしたいです。
機会をくださった中村さんに感謝です!