「More Effective Agile ~“ソフトウェアリーダー"になるための28の道標」

この記事は 「ひとりでアジャイルo0h① Advent Calendar 2021」のday-13です。 adventar.org

day-13は「More Effective Agile ~“ソフトウェアリーダー"になるための28の道標」です。

どんな本

アジャイルをやりたい」という組織が世の中に多くいるのはわかったが、「ただプラクティスを真似するだけではうまく行かないのはなぜか?」という所に意識を向けながら、現場でどのように効果を上げるか?について書かれた本です。

「概念」と「実践」の軸で言えば実践寄り、「入門」「活用」「応用・発展」でいえば「活用」みたいな温度感だと感じました。
教科書よりは参考書。「問題の解き方」が解説されている感じ。
アジャイルとほ」を読者に提供するものではなく、主眼をおいているのはタイトルの通り「効果的なアジャイル」ないし「アジャイルの本来の(本質的な意味での)効果を上げる」という部分。
また、エッジの効いたプラクティスや理論を扱うものではなく、世の中で広く取り入れられて効果を上げたものについて話をしています。そういう意味では、とてもベーシックで、ある種の「地味」さすらあるかも知れません。

本書は、うまくいくことが実証されているプラクティスに焦点を合わせている。アジャイル開発の歴史は、1人か2人の熱心なアジャイルファンによってひと握りの組織でうまく利用されていたものの、普遍的に有効なことが結局認められたなかったアイデアでいっぱいだ。本書では、そうした用途の限られたプラクティスをあれこれ説明しない。

1.3 他のアジャイル本との違い(P6)

アジャイルの本」と題してはいますが、内容としてはおおよそスクラムの本だと思って良いのではないかな?という感想です。

一部の説明について「むー、そうだろうか・・?」と個人的には完全に同意はしかねる記述も見受けられたものの、「うまくいかないアジャイル(スクラム)」の罠!みたいなところを抑えており、面白く読めました。
対応に必要な態度、観察眼を与えてくれるかも知れません。

アジャイルソフトウェア開発を導入してみたものの、いまいちしっくりこない・うまく行っていない気がする」といった現場リーダーに読んでみてもらいたい気がします*1

お気に入りポイントかいつまみ

考え方のベースとしてクネビンフレームワークを据えている

「なぜアジャイル(が必要)か」という説明をする時に、よく出てくる横文字や略文字としては「VUCA」「OODAループ「クネビンフレームワーク」があると思います。
もっとも網羅的に「なぜ」を説明しているのはクネビンフレームワークなのではないでしょうか。

第3章が「複雑さと不確実さという課題に対処する」というテーマを設定しており、ここで「背景となる基礎理論」「今日の時代背景の解説」が為されます。
他の本でよくあるのは、ここで「背景」を説明したあと、「もう状況はわかったね?」と言わんばかりにそれらの概念が登場しないような構成です。
本書では、全体を通じて「煩雑」「複雑」という概念を用いた状況なり課題の整理を行うなど、説明の筋を通しているような印象を受けます。

f:id:o0h:20211214024022p:plain
索引を見るとその雰囲気が伝わってきませんか

何で実践的 → アンチパターンの指摘が豊富

「more effective」を題する本であって、「どう活かすか」に焦点を当てた内容です。
では、その「うまくいくやり方」はどのように表現されているか?というと、「活用できるtips」だけではなく「こうなってはいけない、要注意」「こうした課題に対処していく必要がある」という観点での指南が多く含まれている事も要因だと感じます。

例えば「モノリシックなデータベースを避ける」「テストカバレッジの基準を必要以上に振りかざさない」「(計測は重要だが)計測やその数値が目的になってはいけない」など。

全体を通じてアジャイル(スクラム、XP)・DevOps・リーンのプラクティスやコンセプトを幅広く扱っていますが、「うまくいくために」「失敗しないために」の両方の観点が意識的に提供されているように感じました。

各章末にまとめとして「検査と適応」のチェックリストがあるのが良かった

副題(28の道標)にある通り、項目立てて「必要なこと」を紹介する構成となっています。
それで、各章の末尾には「推奨リーダーシップアクション」として、「その章の内容をしっかり実践して、組織を導くためには」というポイントが紹介されています。
このポイントが、「検査」「適応」に区分けて簡潔にまとめられているのです。

これは、本書を通読した後にリマインダとして使える箇条書きになっていると思います。
そして「検査」「適応」という概念は、アジャイルの勉強をしている人にとっては非常にしっくり来るものですよね。これは個人的に良いな〜と感じた点です!

「検査」は、自身の行動や感覚だったり環境において起きていることについての観察項目を指摘します。
「適応」は、自他にある事象が立ち現れた際にどうするべきか、推奨される行動・心構えについて指摘するものです。

こうしたインクリメンタルによって「more effective」を目指せ、というメッセージ性を感じます。

まとめ

リーダーやスクラムマスターが自分1人で読んでも、あるいは「もっと良くなれそうじゃない?」と感じ始めたチームで読書会をしても面白いかもな、と感じた1冊でした。 比較的に幅広く扱っている割にはコンパクトに纏められている気もしており、また、各章および巻末に参考文献も豊富に示されていることから、「ざざっと読んで全体感を抑えつつ、特に今の自分のチームに足りていないと感じるところがあったら、勉強を深めてみる」という使い方が良いのかな?とも思います。

*1:本書の言葉によれば、対象読者としてCxOレベルの人も想定している様子

「アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き」

この記事は 「ひとりでアジャイルo0h② Advent Calendar 2021」のday-12です。 adventar.org

今日から5日間は「レトロスペクティブ祭り」です。
day-12は「アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き」です。

どんな本

(・・・全く本筋と関係ないのですが、これを忘れていて「訳者ふりかえり」を開いた時に笑ってしまった)

「ふりかえり」に関する本です! タイトルの通り、1冊の中でふりかえりに利用できるアクティビティが豊富に紹介されているのですが、「どうしてふりかえりを行うのか」「どのように効果的なふりかえりが実現できるのか」について語られた本です。

自分は、初めてこの本を読んだ時に「なるほど、こうやって組み立てるものなのか」と感銘を受けました。
それまで「ふりかえりをやりましょう」と言われると「KPTをやる時間」と思っていたのですが・・他のアクティビティの引き出しが無かったことも然ることながら、「ふりかえりの時間」と「KPTをやる」の主従関係が逆だったように感じます。
確かにそれがメインコンテンツであっても良いと思うのですが、それだけを実施するのでは不完全であり効果は半減するな、と。
もっと総合的・立体的に「ふりかえり」を扱う必要性があると感じました。

そうした「土台」を理解した上で、本書の約半分ほどを占める「ふりかえりのために使えるアクティビティのカタログ」に触れていきます。

最近は「プロセスを改善しても金にはならない、しかしプロセスを改善しなければ金を生めない」なんて気持ちで過ごしている日々です。
この本は、単なる「ふりかえり技法」ではなく「チームの状態を引き上げるために必要な手立て」と呼ぶのにふさわしいと感じます。
副題にある「強いチームを育てる」に偽りなしです。

お気に入りポイントかいつまみ

「ふりかえり」だけでなく、効果的なミーティングのファシリテーションに通ずる

具体的なアクティビティの紹介が始まるのが第4章ですが、それに先行する第1−3章では「振り返りミーティングの進め方・全体設計」を解説しています。
どういう流れで進めるか?何を見てチームに合わせた構成を行えばいいか?ファシリテーターとして何をすればいいか?といった事が書かれています。
例えば「3.4 あなたの管理」「3.5 次のレベルへ」などは、プロフェッショナル・ファシリテーターにも通ずるような内容でした。

書名の通り「アジャイル開発を実践している職場におけるレトロスペクティブの場をデザインする」という想定で作られている本なのですが、これは決してふりかえりミーティングだけに閉じた話ではないな、と感じます。
いかに生産的な時間にするか?どうチームの主体性を引き出すか?の話です。

この辺りがあるから、「単なるアクティビティの解説本ではないな」と本書の価値を1次元高めているように感じられたのです。

多様なふりかえりアクティビティ

言うまでもなく、本書には多量の「ふりかえりに使えるアクティビティ」が紹介されています。
アジャイル関連の本やスクラム関連の本では、「レトロスペクティブはなぜ必要か」「例えばどういうものが出来るといいか」を紹介しているものもありますが、決してアクティビティのバリエーションが多くありません。あるいは、種々のアクティビティが相対化されない事によって「どこが肝なのか」というメッセージが弱まってしまっているものもあります。

そうした意味で、この「レトロスペクティブ専門本」はとても頼りになります。
パラパラとめくりながら、気に入ったものを教科書的なカタログとして真似してみることが出来ます。
(実際に、自分もこの本を通読するより前に何度も「摘み食い」して活用していました)

ただ、「たくさんの数がある」「それぞれに少なすぎない分量の解説が加えられている」ことは、それ以上の価値があると思うのです。
こうした大量で質の安定したインプットを得られることで、読者の頭の中で「カクテル」が出来るようになるのではないでしょうか。
すなわち、これらをそのまま使うに留まらず、チームの観察に基づいてアクティビティをアレンジしたり、あるいはオリジナルの手法を編みだせるようになると思います。

どんなに良いアクティビティでも、ふりかえりのような知的生産活動においては「マンネリ化」が敵として立ちはだかります。
その点、多角的な「ふりかえり眼」をやしなっておけば、必要性があって効果的なものをいつでも提供できるようになるのではないか、と。

まとめ

自分の中で、本書は「実践への即効性が極めて高かった1冊」です。
ふりかえりは、ともすれば「ただ何となくやって終わった」「特に生産的な価値を感じられなかった」といった結果に至りがちです。
・・・「チームで喋ってみる」ことの効果はそれだけでも相応に高いと思うのですが、やはり参加者の実感、主観による「価値」は看過できませんので。
・・・ちなみに、「誰も積極的に発言しない」「発言する人が偏る」といった問題への対処、「ふりかえり自体をどうカイゼンするか?」も本書の中に解説されております。

他方で、ふりかえりという活動は、不安定だけどしっかりやった時にはユニークで大きな効果を生み出し得るものだと思っています。

ミーティングのファシリテーションをする人、プロセス改善や組織改善に興味のある人、スクラムチームで活動をしている人には必読なのではないでしょうか。

「Fearless Change」

この記事は 「ひとりでアジャイルo0h① Advent Calendar 2021」のday-12です。 adventar.org

day-12は「Fearless Change」です。

どんな本

副題には「アジャイルに効く アイデアを組織に広めるための48のパターン」と付いています。
「Fearless」とは「(変化していくこと・受け入れることを)恐れない」というニュアンスでしょうか。そうした形で「アイデアを広げる」ためのパターン、つまり「押し付けたり、恐怖によって駆り立てるのではなく、手を組みながらポジティブに変容を起こしていくには?」というのが本書のテーマになります。
アジャイル」とは付いていますが、それを標榜する組織やチームでなくても非常に有用な1冊だと断言できます。

扱っているのは組織の話、つまり「人と人」や「意思決定、フロー」の話・・・ピープルウェア風に言えば「社会学」の話になるかと思います。
そこに焦点を当てたパターンを共有していく、というもの。この「パターン」はパターン・ランゲージのパターンですね。

組織に新しいアイディアを広める(変化をもたらす)というのは、大変なことです。抵抗にあったり、人々の無関心を動かせなかったり。動き出したと思ったら状況が思わぬ方向に変化したり、勢いが失われたり。形になったかな?と思ったら、形式だけが出歩いてるような「やらされているだけで誰も乗り気じゃない」とか。
一筋縄ではいきません。

本書は、「ランゲージ」としての Patterns for Introducing New Ideas 、すなわち個々のパターンが総体として何を目指しているのか?どんなことをもたらし得るのか?について語る第1部と、変革の事例をパターンの観点から紹介した第2部(パターン32: 体験談の共有、ですね)、そしてパターン・ランゲージの「単語」となる各パターンのカタログである第3部からなります。

お気に入りポイントかいつまみ

それぞれのパターンが「人間的」であること

「恐れのない」というタイトルから分かる通り、組織の中にいる人達の「感情」に向き合っている本です。
人々の意思決定は決して合理的でも論理的でもない、というところからスタートしています。
なので「正論」「きれいな理想」だけでは、個人も組織も動かない。だから変革が難しい!!

そうした前提を抱えながら、どう取り組んでいくか・・・?というヒントになるの本書です。

第1章に引用されている言葉も目を引きます。

「事実とは便利なものだ。感情が正しいと決めたことに、正気で取り組めるようにしてくれる。」 P8

正に本書の根底にあるスタンスはこの表現に集約されているようなもので、「どうやったら受け入れてもらえるか、あるいは何が拒絶を和らげるのか」という処方箋をパターンとして取り扱っています。

納得感のある話、トークンとしての利用法

本書を一通り読んでみた時に、驚くほど「目新しい知識のインストールはない」ように感じました!
「パターン」とは、そもそも「名前のついて広く認められたパターンがあって、そこから行動が生まれる」ものではなく「頻出する課題と解放について、整理して名前をつけたもの」のはずです。
そういう意味では、自分が過去に実行した取り組みや考えてみた・意識したことが「ここに書いてある」というのは、この本の出来の良さを証明していると思うのです。
もっと言ってしまえば、「実際にそうすることで効果があるな」という納得感がしっかり得られました。それらが構造化され、「コンテキスト」「フォース」「結果」まで付与されている・・ということは、今後は「何となく知ってた」ことを、より適切で迅速に取り出すことが出来るようになるのだと感じます。

パターンの42に「トークン」が紹介されています。

要約 新しいアイデアを人の記憶に活かし続けるために、伝えた話題に紐付けられるトークンを渡そう。 P246

自分にとっては、正にこの本が「トークン」として機能しそうだな、と思いました。
引き出しの中に何があるかな・・・?を、パターン一覧やこの本の目次を見るだけで即座に思い出せるのです。

また、これは少し余談ですが、パターン名が直感的なのも良かったですw
(「組織パターン」とかは、少し比喩性が強く感じられて中身が思い出しにくいようなものも多かったので・・・)

段階に応じて適用する方法を考えている

そのままパターン名として設定されていますが、「イノベーター」「アーリーマジョリティー」というような概念が出てきます。
そこから分かる通り、「最初にやり始めた頃から、どうやって全体へ波及させていくか?」という観点が大事にされているのです。

付録Bには、「序盤の活動に関わるパターン」「中盤移行の活動に関わるパターン」というグルーピングもなされています。

今、どうやって動けば人々に受け入れてもらえそうか・・?というのを客観視し、適応的に動いていくためのヒントになりそうです。

個人的に(今の気分で)お気に入りのパターン

パターンのチートシートが、監訳者であるkawagutiさんの手によって公開されています。

kawaguti.hateblo.jp

どんな本だったか?何を得たのか?をより濃くふりかえってみるために、48のパターンの中から”今の気分で”お気に入りなものをいくつか列挙してみます。

  • 1 エヴァンジェリスト
    • 「Fearless Change」の最も原初にあるパターンだ、という風に言及されています。
    • まずは自分自身が、新しいアイディアに胸を躍らせ熱狂する!それがいかに素晴らしいものであるか、情熱を持って他人に伝える!!!
    • 長い道のり、まずはそういう風にスタートさせていかねば・・・と感じました
  • 2 小さな成功
    • エヴァンジェリスト」である自分は、多少は長くなっても良いと思うです。
    • ただ、2人称・3人称のアイディアになってきた時に、そこにいる人達はどうか・・・?と考えると、「辛抱強く待つ」だけでは熱が冷めてしまうかも知れません
    • まずは「わかりやすい結果を残す」とうのも大事、そういう視点は意識していかないとなーと
  • 3 ステップ・バイ・ステップ / 34 ちょうど十分
    • 「小さな成功」とも関わりますが、急進的すぎる試みは着地させにくいものですよね
    • 大事にしたいアイディアだからこそ、歩調を合わせて進めるようにしないとなーと
    • 求めてない所に突っ込んでもたぶん実らない
  • 22 種を巻く / 23 適切な時期
    • まさに「CAL-1」で言われたことだなーと
  • 26 テイラーメイド
    • 他者に賛同者になってもらうには、綺麗事や理性的な話だけでなく「あなたにとっても、素晴らしいことだって分かるでしょ?」って言う共有をしないとですよね
    • 「わからせる」ではなくて「感じさせる」みたいな雰囲気を感じました
    • 心から乗っかってくれる他人こそ1番強いと思うので、自分の好きなアイディアに「乗せる」のも丁寧にやっていきたい
  • 40 成功の匂い
    • これもCAL-1で解説されていた事に通じるな〜と感じていて、何かというと「面白そうに・楽しそうにやってたら、隣りにいた人も興味を持ち始めて覗きに来る」みたいなやつ
    • (Culture Bubbleの話です
    • まぁ命名的に「理を感じると、(アーリーマジョリティなどの人でも)やってくる」という話な気はするのですが、もっと踏み込んで「自分たちが、いかに良い匂いを演出していけるか?」も大事になりそうだな、と思った次第
    • あと、「解決方法」の中に書かれている「彼らの質問から学ぼう」という態度も凄い大事にしたいなって思ったのです
  • 47 お試し期間
    • この本を読む前に、まさに「ちょっと破壊的で抵抗を食らいそうだな?」って思ったアイディアについて「まずh2ヵ月って期限を設けた上で実験的に取り組んでみたい」と交渉をしたことがありまして。
    • その結果・・だけではないのですが(パターンの観点から見ると、凄い色々と仕掛けている動きになるなーとふりかえって思う)、「まぁ2ヵ月ならやってみるのが良いんじゃない』という声を実際にもらえたので、自身の体験として「最初から明確に時限や終了条件を示しておく」ことの価値は感じます
  • 46 恐れは無用
    • 心が折れそうになったらココに立ち返りたい
    • 「他人は変えられないが、自分の行動は変えられる」に通ずるものを感じて、そう信じた上で「エヴァンジェリスト」として、聞く耳を持って、常に自分と他人に一生懸命に取り組むようにしたな〜と・・
    • 「恐れ」の多くは、未知とか不安からくるものなので、対話大事。相手を尊重する。

まとめ

読みやすい・わかりやすい本でした。
見る人によっては「あたり前のことしか書いてない」とか思うのかも知れませんが(だって「根回し」とかパターンとして取り上げられているんですよ!)、遥かにそれより大きな価値のある1冊で、周りの人にもじわじわと薦めたいなぁ・・・と感じます。

これを見て「新しい動き方をしよう」ってなるよりかは、今の自分の置かれている状況や抱えているものを自省して、何が足りないか?もっと出来ることはないか?を棚卸しする際に手元においておきたいなって感じます。

「みんなでアジャイル」「チーム・ジャーニー」あたりと一緒に読んでも面白いかも。

認定アジャイルリーダーシップ Iを受けた

この記事は 「ひとりでアジャイルo0h② Advent Calendar 2021」のday-11です。 adventar.org

day-11は、書籍の紹介の代わりに、参加した研修の話です。 今年の10月に認定アジャイルリーダーシップ I(CAL1)を受けてみたので、それについて「ひとりでアジャイルスクラム以外編〜」カレンダーの1篇としてふりかえってみたいと思います。

www.jp.agilergo.com

f:id:o0h:20220211164133j:plain f:id:o0h:20220211164142j:plain

※ 自分が受講した開催回のリンクではありませんが、アギレルゴの研修だったよーという意味合いのリンク。

受けてどうだったの

非常に考えさせられる研修で、いくつも「大事にしたいな」と思えるエッセンスを受け取りました。 全く新しい概念、根底から価値観を覆される体験・・・というものこそ無かったものの、それでも「改めて考え直したい」「重く受け止めたい」という考え方が多数ありました。
なので、もっともっと勉強も実践も内省も続けていかなければならないし、また自身の視野だったり興味関心の分野も少し広がったかな、と思います。

「ここに答えがある」という期待よりも「しっかりと一歩を踏み出したい」という期待からの受講だったので、「学ぶためのヒントがある・源泉となる」事が非常に有難いです。期待に沿うものでした。

これで、自分はCAL-E/CAL-Oのライセンスを取得したことになります。

どうして受けたの

「認定アジャイルリーダーシップ」なるものを知ったのは、 #scrumosaka の発表がきっかけでした。 このイベント自体が「せっかくCSMもとったし、スクラムとかアジャイルに興味を持ち始めたから、覗いてみよう〜〜」と思って参加したもの。
そこで、なんとなく見てみたセッションが「全く知らない世界だな」「面白そうかもなー」というものでして。

(録画が上がったら改めて観たいなー)

恐らく、「自分がチームを持ってスクラムをやる」以上に「組織全体を方向づける、よい方向に連れて行く」ことが現在の自分の仕事におけるミッションになりそうな気がしています。
急に広範囲へのチェンジ・エージェントに挑むような・・・・

そこで「リーダーシップとは」については興味分野となります。
とはいえ、CSM研修も受けたばっかだし、流石になぁ・・・・とか感じながら逡巡していたのですが、別の文脈で大きめな自己投資を決定したタイミングがあったので「こっち行くなら当然CAL-1も行くよな!?」となり。エイヤっと申し込んで振り込んだ次第です。

社内でマネージャーへの転身を打診された直後でもあり、「自分はマネジメントやリーダーシップというものを(アジャイルの文脈以外でも)武器として磨いていく必要がある」と感じたのも、エイヤっを後押しした要因にあります。

いずれにせよ、CSM研修とその後に別に受けたコースの体験から、くした研修は「たったの数日間や数十時間でも、自分だけで辿り着けるより遥かに濃く・高い地点に辿り着けるものなんだな」という事を理解していました。
なので、「恐らく学んだ方が良いであろう分野・方向性」について「費用さえどうにかしたら、しっかりと受けられるチャンスがある」となれば、学びたい気持ちに素直に従ってしまおう・・と。

ここで、「どうやって周囲を高いレベルにつれていけるか」「自分自身を影響を与えられる人材に引き上げられるか」のヒントや取っ掛かりをつかめればいいな、と期待してのものです。

当日に得たもの

中心的なテーマは「変革型リーダーシップ」でした。
ハイパフォーマンスな組織を築くためのリーダーシップ、となります。

講師のサホタ氏の会社で「アジャイル変革するための鍵」の資料を配布しているので、ここで概要はつかめるかも知れません。

shift314.com

文化が大事

研修タイトルは「アジャイルリーダーシップ」とありますが、実際には「文化とリーダーシップ」の研修であったといえます。
文化とは何か?どういう力を持つのか?be agileのための「よい文化」とは?

そういった点を論じていきます。

文化こそが進化と成長のキーである、と。
文化とは「何を感じて、何を話しているか」を決定するものなので、もし話している言葉が違えば「バベルの塔のように、目標に到達できずに崩壊してしまう」と。
ハイパフォーマンスな組織を実現するのは、それに見合った組織文化。

氷山モデルで「水面下にある大きなものは文化であり、目に見えない。目に見える戦略や先述というものは、氷山の一角に過ぎない」といった、印象的な表現も用いられていました。
アジャイルマニフェストで「プロセスよりも人を」とあるが、プロセスというのは正に「戦術」のことであって、人そのものがなすのが「文化」。
あのマニフェストに共感し、アジャイルを実践していくのであれば、文化に目を向けることからは逃れられないはず・・という理屈になります。

ハイパフォーマンスな文化を持つと生まれてくるのが、自己完結型・自律的な組織です。
なぜ「自律」が許されるか?といえば、全員が「同じように判断できる」し、それをお互いが信頼できているから。
「何を喋り、どう考えるか」が揃っているから、組織はその状態に行けるチャンスを手にします。

「生産プロセスの一部の歯車」のように扱う指揮統制型の組織でもないし、「支援してあげる・支援される」という関係性で成り立つ家族のような組織でもないし、自律的な組織は「皆が平等に考え、お互いに敬意を払って接する」という大人同士である必要があります*1

良い文化があると何がもたらされるか?継続的な進化、臨機応変でしなやかな意思決定と実践が、その答えの1つです。

失敗例として、「文化がないところに形だけ取り入れる」というパターンがあります。
(例: 「アジャイルをやる」のと「アジャイルになる」の差。価値観の共有をなくしてアジャイルラクティスだけを取り入れても、形骸化し空中分解する。寧ろ「押しつけ」によるストレスが、従業員のモチベーションを下げてパフォーマンスの低下をもたらす)

総じて、「組織の進化」は「文化の進化」であり、もっといえば「そこにいる人達を進化させる」ことがアジャイルリーダーシップに求められる事になります。

徹底的な傾聴

”レーザーリスニング” という概念で紹介されていました。
この研修において、リーダーシップは「ティーチング」「指揮統制」よりも「相手を大人として扱う」ことを重視しています。
そのために必要なことは、相手の存在を肯定し受容することです。

そのためのプラクティスとして「レーザーリスニング」です。

「相手の方へ、レーザービームのように視線を向けて、その中に置きていること・感じていることを聴き取る」というもの。
自身の価値判断や「教育」「フィードバック」は後回しで、とにかく全神経を「聴き取ること」に集中させます。

相手が「聴いてくれている」「私を見てくれている」と感じることで、(心理的)安全性がもたらされるし、「自分で考えること」への許可をもらっているように考え始めます。

更に、他人だけでなく自分に対しても「何が起き、どう感じているか」を聴いていく事も重要であると。
自分自身への観察をなくしては、「リーダーとしてどういう影響を与えているか」「どんな振る舞いをしている(見られている)か」に気づくことが出来ません。
自分を「正しく」保つことは大事です。 「自分自身を聴く」ことが必要になります。

これについては、瞑想のようなアクティブティを通じてマインドフルネスの獲得をすることで「聴けるようになる」という話でした。
瞑想とは、「自分の皮膚が何かを感じている、という事自体を感じる」ようなメタ認知のトレーニングでもあります。
「蒸し暑い・不愉快だ」「蒸し暑いという感情が湧いている」みたいな。

そして、「なぜ成功を手に入れられないのか?」について考える時に、自分の不足している部分 = 「リーダーシップの限界(を迎えている部分)」はどこか?を問い、認識していく必要があります。

まずは自分から / 忍耐を持って進める

文化とは「押し付けて形になるものではない」と説明されています。
「文化の芽が育つ土壌が整うのを待ち、その時が来たら種を巻きに行こう」という説明は、自分にとってはこの研修全体を通じても最も価値のあるものの1つであるように感じました。
「Calling」の考え方や、U理論で言う「プレゼンシング」に近い部分もあるのかな?と感じました。
機が熟した、準備ができた時に「一歩を踏み込む」ことができる、というのはとても感じます。

自分自身の体験として、職場において「レトロスペクティブ/ふりかえりをもっとやっていけると良いんじゃないかな〜」という気がして、実践的な知識の共有を働きかけた(勉強会の企画など)ことがありました。が、鳴かず飛ばずと言ってもいいくらいに反応が得られずに消滅しています。
そこから数ヵ月して、ふと気づくと色々なプロジェクトでも色々な形式でのふりかえりワークが行われるようになっていました。
これもまた、「土壌が整って、だから芽が出てきた」という一環なのかな?と思っています。

なので、リーダーは「芽が育ちそうな土壌があるか?を、歩き回りながらしっかりと観察して、良いタイミングに種を蒔く」必要があります。

では、どうやって土壌をつくるか・・?
まずは「自分からやってみる」というのが大事です。
「良いものだからやってみよう」なんて押し付けたり売り込んだりするのではなく、周りのニーズやインサイトに応える形で(例えば自分のチームなど、小さい範囲で)「こういうやり方をしてみよう」という取り組みをしてみる。
ある意味では、「他人にとっても良いものだと信じているから与える」のではなく「自分自身が良いと信じているから行う」に近いものですかね。
有名なムーブメントの起こし方に通ずるものを感じます。
人や文化も、自然と同じで、「自分のペースで成長していく」ものです。もし強引な接し方をすれば、それは折れて失われてしまいかねません。

それで、もし「価値のある」「しっくり来る」ものだったのであれば、じわじわとチーム外にも評判が届くようになる・・・と。

Culture Bubbleという考え方が紹介されていて、これがとても興味深く感じると同時に重要なものであると思いました。
これについては記事があるので、リンクを貼っておきます。

shift314.com

さて、これらを達成するリーダーに重要な素質・態度は何か?・・・それが「忍耐」だ、と。

研修を終えて

研修最終日のメモに、こんな事を書いています。

f:id:o0h:20211211181614p:plain

色々な組織理論、心構えについて教わりました。
それらを総合して「では、自分がどうしていくか?どんな行動を選択するか?」について考えると、「謙虚に、忍耐強さをもって取り組む」という回答になります。
謙虚さとは、「自分をしっかり客観視すること」「周囲の状況や他者、そのコンテキストを尊重し尊敬すること」だという解釈です。
そして、忍耐強さは謙虚さから生まれるものだと思うのです。「俺のほうが正しい」となった時点で、教育したり支配したいという誘惑に負けます。それよりも、相手自身という個を受容し肯定することで、「きっと良い方向に向かうはずだ」と信じられるようになるのではないか、と。進行や到着がわかっているのなら、少しくらいは気長に待てるようになります。

CSM研修以上に、その場ですぐに「わかった・掴んだ、正解を見つけた!」とはなりにくく抽象的な内容だったように感じます。
それでも、多くの非常に重要な示唆をいただけたように思いました。その内のいくつかは、今時点での理解レベルで「とにかく実践してみるか」と思えるものです。

今後も、定期的にor折を見て、研修資料を読み返したりノートを開いてみたいなーと思いました。
CAL-2も受けてみたいな〜英語が分からないのは本当に機会損失だなぁ。。

*1:この辺り、特に「成功例」としての参考情報として「ティール組織」の書籍を紹介していました。それと同時に、ティール組織(書籍)については、「形式ばかりに着目しているから、説明としては不足・ミスリーディングだ」と指摘しています

認定スクラムマスター研修を受けた

この記事は 「ひとりでアジャイルo0h① Advent Calendar 2021」のday-11です。 adventar.org

day-11は、書籍の紹介の代わりに、参加した研修の話です。
今年の3月に認定スクラムマスター研修を受けてみたので、それについて「ひとりでアジャイルスクラム編〜」カレンダーの1篇としてふりかえってみたいと思います。

f:id:o0h:20220211164025j:plain

受けてどうだったの

楽しかったです!
自分の中で何かを「掴んだ」ような手応えもあったし、それ以上に「これから学んでいく上で、どういう部分を大事にしていきたいか」を受け取れたように思います。
勿論、決して長くはない研修なので「ここに答えがある!」「受けただけで全てが変わる!!」というものではないですが、しっかりと「やっていくぞ〜」という気持ちにはなれたかと思います。

研修というと「コンテンツ、形式知」について「何が得られるか」に意識がいきがちかと思います。自分もそうでした。
ですが、やはり「場」の価値も計り知れないのではないかと。半分以上は「参加型」な研修になるので、寧ろ「そこで何が起きているか、どういうことを経験できるか」から得たものが大きいようにも思っています。

相応の費用がかかるので「コスパはどうなの・・?」というのには一概には答えにくいですが、自分としては「買わない後悔より買った後悔」で動いてみて良かったなーと言い切れます。
実際、後悔はなくて「とてもよかったな〜」という気持ち。

(ちなみに、何となく「会社の費用or一部負担で受けてそうだな」って感じの人が多かったです。直接聞いたわけではないですが。同じグループになったのは大企業さんの人が多かった印象)

どうして受けたの

スクラムと言えば、前々職で「POいるし、2週間毎にプランニングしているし、ベロシティも測ってるし、レトロスペクティブもやっているよ」という経験をしていました。
その当時が「スクラム」なるものがあるらしい、と知った初めての場です。

とはいえ、(今思えば)スプリントレビューもなければスクラムマスターもいない状態でしたし、「スクラムをやっています」っていうには遠い感じでした。

その後、昨年末から今の職場で「新しくプロジェクトをやってみる」「初めてのプロジェクトリーダー」を任されることになり。

中期的な計画を立ててそれに付き従う?・・・要件もわからん、そもそも自分がドメイン知識もない、メンバーの実力もわからん、これで「計画」「見積もり」をして「工程を組む」なんて出来ないだろ・・・
であれば「少しずつ進めていく」しかない。
あ、アジャイルか?
ん〜、そしたら何となくスクラムは勉強すれば動かせるかも・・・?

という流れで、勉強をし始めてみました。
1週間で複数冊の書籍を買ったり摘み食いして読んだり・・を繰り返しながら、なる早で藻掻いていた感じ。
結局「スクラム風の何か」を採用して動かすことになり、ここで一定の手応えを感じつつ興味を持ちます。面白いなーと。
そうなると「ちゃんと勉強したい」という気持ちが湧いてきます。
また、「どうにかして健全で真っ当に開発できる組織を作りたい」と考え続けていた時期なので、「今後、(自分の立場で言えば)アジャイルっぽい動きを増やしたり、社内をそっちに寄せていく可能性もあるのかも?」とも思えてきました。そうすると、「オフィシャルに自身の知識・思考を証明できる」という後ろ盾になる材料もほしいな、と。

以前の職場で、同じチームにはならなかったものの「認定スクラムマスター」な同僚が居たことを思い出します。
当時は「えぇ、20万も支払って資格とかとるもんなの・・?全くわからん・・・・」と思っていたのですが、今なら「ここで支払っても、恐らく仕事で十分に取り返せる。職場が変わる/変える余地が存分にあるし、今後、キャリアを精査される場面に出くわしたとしても”そういう方面も行ける・興味がある”っていうのはプラス材料にできるだろう」という風に感じました。

・・・費用面、「本当に意味があるのかな?」という懸念、そしてClena Agileを読んだばかりでしたので少なからず悩んだのですが。

それに、自分はこれまでの人生において何らかの資格をとったり検定を受けたことが無く、研修も会社の費用で1度受けたくらいなので、「それが何になるのか」はイメージできていませんでした。高いし。

Clean Agileの第6賞には「認定資格」という節があり、"今あるアジャイルの認定資格は、完全なるジョークであり、完全にバカげたものである。認定資格を真剣に受け止めてはいけない。" "認定資格が意味するのは、数日間の研修お金を払ったこと(と研修に出席したこと)だけだ。”と痛烈な批判がなされていますw

それで、結論としては

  • 「ちゃんと学び始める」ための一歩になれば
    • このたった数日で完成するものはなくても、自分自身が「腹をくくる」までは行けるはず
  • 少なくとも今の環境で身の回りに「自信を持ってスクラムを実践している」ような人はいない
    • 本物の思考に触れてみたい
  • 社内で暗黙的に「アジャイル/スクラムに詳しい人」になるよりは、権威付けをしておいた方が効率が良さそう
    • なので、一応は形式的にも認定を持っておきたい

を期待する価値として定義しました。

どこの研修を受けよう?

早々にCSMに絞ったのですが、公開研修を提供している企業にはいくつか有名所があると思います。時期的に、どの会社もオンライン開催になっていたので地域や日程は大きな問題になりにくいです。

Odd-e、アギレルゴコンサルティング、アトラクタの3社が有名なのかな・・・・と悩んだのですが、ちょうど良い時期に↓のニュースが流れてきます。

www.attractor.co.jp

これに安心感を得て、アトラクタが一歩リード、ほぼ確だな〜と。
・・・で、もう少し調べてみると、メンバーが自分にとって「豪華!!」だという事が分かりました。
直近1年で読んだ中でトップレベルに良かった「プロダクトマネジメント」の翻訳者、それと並ぶか超えるかくらいに良かった「エラスティックリーダーシップ」の寄稿者、めちゃくちゃ刺さった「レガシーコードからの脱却」「みんなでアジャイル」の翻訳も・・・
ドリームメンバーみたいな状態だなって気がしてしまったので、コチラにお世話になろうと思った次第です。

当日に得たもの

座学とワークショップな3日間でした。
初日にグループに分けられて、同じメンバーでワークショップに取り組んでいきます。
自分以外に開発者はおらず、なんとなく「ビジネスよりのメンバーとプロダクト開発っぽい話をするのって久しぶりだな」と感じましたし、もっと言えば「どう開発するか?以外の部分が話題の中心となる」という経験は初めてかも知れなくて、新鮮な気がしました。 ワークショップは、スクラムの流れを一通り体験しながら、(コードを描いたりデザインをしたりはないものの)1つの「プロダクトを作ってみる」という内容です。
プランニング、プロダクトのスライス、優先度ぎめ、スプリントでインクリメントを作り上げ、そしてスプリントレビュー = プロダクトへのフィードバックも。そのあとにレトロスペクティブですね。 リファインメントして、次のスプリント。

実際に技術要素を用いて市場に出すものを作る!!というのとは程遠いとも言えるかも知れませんが、1つ1つに「なるほど、そういう事なのか」と思わせるようなエッセンスが散りばめられていました。
座学、ワークショップ、講評とQ&Aという知識と経験のI/Oが揃っていることで、どんどんと理解が深化していくような体験です。

(余談ですが、グループごとにSlackのチャンネルが用意されて「そこを自由に使っていいよ」という設定だったのですが、自分のグループは講師陣に「どのチームよりも、本当にプロダクトを作るような雰囲気のやりとりがされていた。スタートアップ企業みたいな」と言われたのは何となく嬉しかったです。)

短い時間・・「1スプリント○○分」という、極めて切り詰めたタイムテーブルを用いた架空の設定でも、実際に「チームがこういう風に進化していくのか」というのを感じられました。
特に、最初のスプリントはどのチームも「時間が足りない」といって居たのが、その次のスプリント最後のレビューでは「ちゃんと製品へのフィードバックをもらえる」ところまで形になっていたりとか。

自分のグループなど、最初のスプリントレビュー後にはプロダクトバックログをひっくり返すレベルで「何をしなければいけないか」を組み直す事態になった(というかチームに提案した)のですが、それでちゃんと「コアバリューが見えた、チームの目線が揃った」というのは新鮮な体験でした。
「何を提供したいのか」ができると、チーム内からもブレイクするーとなるアイディアも出てきやすくなるし、レビュー時にもステークホルダーに対する「ここを観て欲しい、評価して欲しい」というポイントがシャープになります。
というのを実際に体験できました。濃ゆい時間。

学んだこと

自分がもっとも腑に落ちた・大事にしたいと思ったのは、「スクラム(反復と漸進)はフィードバック駆動」という観点です。(こんな言い方をしていたわけではない気がする)。
勉強したての頃、印象深いのは「デイリースクラム」と「レトロスペクティブ」な気がしています。
しかし、価値を実現するための重要要素として「スプリントレビュー」があるぞ、と。

スクラムマスターの仕事は「デモまで連れて行く」「外に引っ張り出していく」「そのために抵抗や誘惑に抗う」ということであり、それが出来なければ「フィードバックを得られない」から。 そして、「次のスプリントが楽しみだという状態を作る」と。

チーム作りや技術課題へのしなやかな対応もとても大事で、不可欠なものですが、自分にとっての「スクラムは何をしなければいけないか」の優先順位が変わった!と思えるくらいの衝撃でした。

研修内容について事細かに触れるわけにはいかないので、ざっくりとはしますが、とにかく「1番重要と思える学び」についてはこの点だと思うのです。

研修を終えて

やはり「スクラムマスターになった」・・・というわけには行かず、あくまで「最初の1歩を踏み出した」くらいのもんだと思いますが。
ポケモン(初代)でいえば、マサラタウンを出て1番道路に入りましたくらいの。
ただ、「スクラムを学び始めた人になった」とは胸を張って言えると思うのです。

これまで資格や認定、研修などには縁のなかった人生ですが。
物凄い濃密で上質なインプットをもらえたと思っており、「なるほどこれが世の人々は知っていた、研修のすごさ・・!」とも思いました。
その後に「金を払って勉強をすること」へのハードルが下がった、積極性がかなりましたので、そういう意味でも自分にとって非常に意義のある経験となりました。

研修の最後に、トレーナーのharadakiroさんが言っていた 「(偉大なるスクラムマスターになるための)スクラムマスターとしての自分のバックログ」は常にメンテしていってほしい
という言葉は、これからも折に触れて思い出すようにしていきたいなーと思っています。

「Scrumban: And Other Essays on Kanban Systems for Lean Software Development」

この記事は 「ひとりでアジャイルo0h② Advent Calendar 2021」のday-10です。 adventar.org

day-2は「Scrumban: And Other Essays on Kanban Systems for Lean Software Development」です。
12/3から始まった「リーン/カンバン祭り」が、本日で最終日です。

どんな本

スクラムに、よりリーンな実践を取り入れる」という事を志向したスクラムバン(Scrumban = Scrum + Kanban)という考え方があります。
本書はそんなスクラムバンについて書かれた本です。

スクラムの欠点を補完する」というよりかは、「アジャイルを超えてリーンに進む」ために「スクラムをカンバン色にしていく」ようなものであるように感じました。
ただし、ここでいう「欠点」というのは、スクラムが「絶妙なバランスを取って保護していた」部分のガードレールを取っ払うような印象も受けます。

スクラムとカンバンの、あるいはアジャイルとリーンの「どっちがいいか」は課題やチームによるし、「二者択一的な意思決定を迫られる」ものではなくて「適切な塩梅を見つけること」がリーダーないしマスターに求められることだと思います。
※ 本書中では「アジャイルとリーン」は別物であるように扱われているので、この記事中でも別物として扱います。*1なお、著者の主張のウエイトは「(可能であれば)アジャイルを超えてリーンに進め」であるかのように感じています。

スクラムバンについての情報をいくつか貼っておきます。

↓本書の著者による記事
www.agilealliance.org

スクラム、カンバン、スクラムバンの比較 blog.gurock.com

スクラムバンに対する批判 www.infoq.com

スクラムバンではなく、「スクラムにカンバンを融合した」考え方 medium.com

自分自身が本書を読んだきっかけは、新しいプロジェクトに取り組む際に「スクラムをしっかりやるには能力やリソースが足りない、明らかにScrum-butになるが何かプラクティスで補完する事は可能なのだろうか?」と探求して「スクラムバン」という概念に出会ったからでした。
うまく扱えるレベルまで紹介している情報がWeb上で見つけられなかったので、原典っぽい本を買ってみよう〜と思った次第です。

全体的に、「リーンについてもカンバンについてもスクラムについても理解している」というレベル感にある読者を想定しているような感じです。
実際、著者の表現を紹介すると

"I’ve been getting into a lot of detail about how to apply Lean ideas to software development. Perhaps I sometimes take it for granted that we understand why we should apply them."

Ladas, Corey. Scrumban: Essays on Kanban Systems for Lean Software Development . Modus Cooperandi Press. Kindle 版.

と書かれています。(しかも70%強ほど読み進んだところでw)

お気に入りポイントかいつまみ

プロジェクトマネジメントにおける「バッファ」の考え方

「リソース効率(最適)」「フロー効率(最適)」については、「This is Lean」で詳しく扱われていてわかりやすかったです。
スクラムは・・というか本書の立場にたてば「アジャイルでは」ということになりますが、仕事量をタイムボックスで管理しています。
「一定期間に行える仕事量を(経験的に)算出して、そこに見合うプロダクトバックログをスプリントに組み込め」です。

プロジェクトマネジメントにおけるバッファとは、「計画を実行するために/進捗をブロックさせないために、理想的なI/Oに対してInputを増やすかOutputを減らして(妥協させて)、余裕をもたせるもの」です。
例えば、タイムボックスを用いてイテレーションを行っている場合は、時間辺りの創出価値が生産性なので、「仕事量を減らす」ことで時間にバッファをもたせます。
リソース効率ベースの場合は、作業リソースの使用率が生産性なので、「投入する機材や人員を増やす」ことでリソースにバッファをもたせます。 リーン思考の場合は、スループットが生産性なので、「仕事の無駄を減らす、フローを最適化する(止まっている仕事をなくす)」ことが是であり、例えば「在庫を減らす」という取り組みが行われますから、バッファをもたせるというのは「在庫を持つ(止まっている仕事を増やす)」ことになります。

本書を読んでいて「なるほど!」と思ったのは、カンバンにおけるバッファを持つとは、すなわち「作業フローに流せる(="ready"な)タスクを増やす」ことである、という点です。 極端に言えば、「よく見積もられて、詳細な仕様定義をもって完全にタスク分割が済まされたバックログがある」のは「無駄」という訳です。 この無駄を極限まで抑えて、かつ「ストップ」が発生しないようにする・・というのがカンバンの目指す理想状態*2です。 そのためには「在庫ゼロ」「WIP=1」が最も良い状態です。
ある意味、「ただし摩擦係数はゼロとする」とか「自宅から学校までの2kmを時速5kmで全く立ち止まること無く歩くタカシ君」みたいなものでしょうか。

"However, controlling the size of the buffers is still very important. The ideal buffer size is 0, because all buffers are waste, but if a buffer is necessary for synchronization, then the ideal size is 1. If the buffer size grows much bigger than one, then you might consider adjusting downward the WIP limit of the upstream state instead. Remember that the only goal of the kanban buffer is to create the appearance of instant availability downstream."

Ladas, Corey. Scrumban: Essays on Kanban Systems for Lean Software Development . Modus Cooperandi Press. Kindle 版.

「1個流し」についての言及はこちら

"In pull scheduling, One Piece Flow is the ideal result. A Value Stream identifies all of the processing steps that are applied to component materials in order to make the desired product. "

Ladas, Corey. Scrumban: Essays on Kanban Systems for Lean Software Development. Modus Cooperandi Press. Kindle 版.

ここから「スクラムの欠点」が説明されており、「10日後に必要になるバックログを、なぜ今の時点で用意しなければならないのか?それは在庫を抱えるのに等しい」という事になります。
在庫を抱えた時点で過剰在庫・破棄リスクが発生します。タイムボックス駆動での活動は、「明日の要求変更に応えられない」可能性があるのです*3。極限までリーンを実践しようとすれば「正しくない」のです。
刺激的な観点ではあるな・・・・と感じました。

カンバンのデイリースタンドアップ

XP・スクラムと同様にデイリーミーティングは実施可能なのですが、その中身がスクラムのデイリースクラムとは異なるようです。

  • デイリースクラム: メンバーが、スプリントゴールの達成の阻害要因になっていることをチームに共有する
  • カンバンのデイリースタンドアップ: ブロックされているものがある人がチームに共有する

大きく違うのは「期間が固定されたイテレーションがない」ことで「短期的なゴール」がないから、協働の仕方が変わるという面があると思います。
また、明確に「スクラムマスター」や「プロダクトオーナー」も置かない(決まりになっていない)ので、各々が自主的に自分の課題を取り扱うことを求められます(スクラムだと、スクラムマスターが補助したりします)。 また、カンバンにおいては全てがオンデマンドで行われるため、「止まっている・止めているものがあれば当事者同士で解決すればいい」「動かせるものがあればどのタイミングでも任意に動かしていい」という前提から「定期的な打ち合わせが、よりミニマム(無駄を削ぎ落とした)ものになる」ようになります。

・・・といっても、スクラムであろうと「自分たちでタスクを持っていい」し「手が空いたら翌朝を待たずに次に行っていい」だと思うので、やろうと思えば逸脱しない範囲内でも十分ににたやり方は出来る気もしますが。目的が「ゴールに行ける確からしさを高める」ではなくなるので、その点は明確に違いそうですね。

スクラムバンとは何か / スクラムチームがどう取り入れるか

コレが本書で得たいと思って期待していた部分。

スクラムバンは「徐々にリーンに移行していく」ことを目指して考えられているような雰囲気です。
その段階を「スクラムと互換性を持ちながらやるフェーズ」「スクラムから離れるフェーズ」に区分けしています。

前提として、本書が想定しているスクラム

  • スプリントプランニング時に、タスクをメンバーにアサインしている
  • タスクの管理(進捗のビジュアライズ)は、インデックスカードをホワイトボード上に貼って(=カンバンボード)管理している
    • to do / in progress / done
  • デイリースクラムは全員が喋るようにしている(”3つの質問”みたいなものを想定していそう)

他方で、カンバン/リーンなプロジェクトの肝は

  • フロー最適化
    • 在庫ゼロ、WIPの制限
  • プル駆動でのタスクフロ

あたり。

スクラムは「集中」と「学習効果を向上する・経験主義」のために固定されたタイムボックスを武器としますが、もはや「1ヵ月や1週間であっても、その間は在庫を持たなければいけない」というところを気にしているような雰囲気です。

"Once you’ve broken up the timebox, you can start to get leaner about the construction of the backlog. Agility implies an ability to respond to demand. The backlog should reflect the current understanding of business circumstances as often as possible. In other words, the backlog should be event-driven. Timeboxed backlog planning is just that, where the event is a timer, and once we see it that way, we can imagine other sorts of events that allow us to respond more quickly to emerging priorities. Since our system already demonstrates pull and flow, that increased responsiveness should come at no cost to our current efficiency."

Ladas, Corey. Scrumban: Essays on Kanban Systems for Lean Software Development . Modus Cooperandi Press. Kindle 版.

まずは最初のフェーズに進む

A problem with the basic index-card task board is that there is nothing to prevent you from accumulating a big pile of work in process. Time-boxing, by its nature, sets a bound on how much WIP that can be, but it can still allow much more than would be desirable. If a kanban is a token that represents a work request, and our task board can still get out of control, then what is the problem here? The problem is that a kanban is more than just a work request on a card, and putting sticky notes on a whiteboard is not enough to implement a pull system.

Ladas, Corey. Scrumban: Essays on Kanban Systems for Lean Software Development . Modus Cooperandi Press. Kindle 版.

とのことなので、この辺の「気になる所」を直していきます。

The simple approach is to start with Scrum-like iterations and iteration planning process, and begin to add pull features to the team’s internal process.

Ladas, Corey. Scrumban: Essays on Kanban Systems for Lean Software Development . Modus Cooperandi Press. Kindle 版.

これならすぐに出来るよね、ということで紹介しているテクニックが

  1. WIPの制限を設ける
    • これは「ブロックされている人」がWIPにあるものを助けに行く、というのを促す
      • これによってスループットを挙げる
      • ペアプロを含めたスウォーミングの実践や、タスクの更なる細分化ができるかな?
      • ※「WIPの制限」で「ユーザーストーリー(=顧客に提供できる価値の実装)」を制限して、その構成要素である「タスク」は同時に扱って良いんじゃない?って考え方は「カンバン仕事術」に
  2. タスクのアサインを遅延させる
    • (デイリースクラム等で)作業者が着手可能になった時点で、to doの最上部にあるタスクにサインアップする

ここまでで「プルシステム」を完成させ、更に「継続的改善を促すための強化」を提案しています

  1. レーンの分割: WIPを→分析/設計/実装に
    • WIP制限をかけている以上、「どこでブロックが発生するのか(ボトルネックの探索)」は不可欠になる
    • 「着手済み」だけだと、見える化の仕組みであるカンバンが提供してくれる情報が少ない
    • 工程を細分化することで、チームのウィークポイントや協働の促進を実装する
    • 障害点が自動的に顕在化してくる、という意味での「自働化」の要素とも言える
    • 更に、分割された各レーンにそれぞれ別個の制限数を設けることが可能
      • 肩書の少ないクロスファンクショナルチームが前提であるが、比較優位が働くようにアサイン・タスクの交換が進む方が全体効率が実現するので

こうして、「スクラムにリーンのワークフローを取り入れる」ことが可能になりました。

次のフェーズ: スクラムバン

いよいよスクラムのルールを逸脱します。
・・・といっても、チーム構成等は変わらない(変わらなくてもカンバンが実践できる)ので、可変要素は「アーティファクト」「イベント」のみです。

大きく言うと「スプリント」の概念が外れます。その結果、「スプリントプランニング」の中身が変わり、「スプリントレビュー」が無くなります。

ざっくりとまとめると、以下のようになるのでしょうか

  • 「スプリント」をやめて、いつでも「ユーザーが欲しい物に取り組める」ようにしろ
  • 「計画」「見積もり」のコストが高すぎる、やめろ
    • 「次にやるべきもの」にだけ集中していればいいから、計画はいらない
    • 「一定期間に入る量」を考えなくて良いのだから「1つ1つの大きさ」を考えるコストをなくして、その分は「価値生産」に振リ分ける
    • 定期的なプランニングミーティングは行ってもいいが、「これからの計画を作る」ものではなく「在庫が不足しているものを補う」ためのものになる
  • 「バーンダウン」や「ベロシティ」はやめろ
    • 「バーンダウン」や「リードタイム」は結果であり、チームのヘルスを測るなら「サイクルタイム」の方に意味を感じるようになるはず
    • サイクルタイムを用いれば、WIPの制限数や必要なバッファ、バックログをレディにすべきタイミングの最適化に利用できる

まとめ

アジャイルと言えばスクラムになってしまった」というのは「Clean Agile」でも指摘されており、また、なんとなく「最終的にはXPに向かう」「スクラムは入門に最適で、守破離を経てbe agileを進化させていくもの」なんて言説も見かけたりします。
そうした意味で、「アジャイルのその先」「スクラムを超える」という地平はどこかにはあるんだろうな、と感じます。

スクラムは「軽量」なフレームワークでありつつ守るべきものからしっかりと守ってくれているような価値がしっかりあります。どういったコンテキストにおいてどういう課題を解決しているのか?は、スクラムガイドよりも寧ろ「組織パターン」等を読むことで感じられる部分もあるかも知れません。
それゆえ、易きに流れる・・という判断は避けたいものですが、確かに「カンバン」ないし「スクラムバン」も面白そうなものを感じるのは確かです。

チームや隣接するステークホルダーのObserveから始めて、対話をしながら「何が必要か」と「次のステップ」を見極めながら組織を導ける人になってみたいものです。

という訳で、リーン/カンバン祭りはここまで!

*1:個人的には「発端や課題意識、主として扱う領域が異なる。が、アプローチや見いだされるプラクティスについては共通性も多いので、”厳密な違い”は実践においてそこまで気にする必要はないのでは?くらいの感覚でおります。今現在は。

*2:本書では、IFR: Ideal Final Resultという概念が紹介されていました https://www.slideshare.net/princesa.guacamole/ideal-final-result-presentation/4

*3:「スプリントの中止」をする権限をプロダクトオーナーが持つことについては、スクラムガイドでも言及されていますね

「今すぐ実践! カンバンによるアジャイルプロジェクトマネジメント」

この記事は 「ひとりでアジャイルo0h② Advent Calendar 2021」のday-9です。 adventar.org

day-9は「今すぐ実践! カンバンによるアジャイルプロジェクトマネジメント」です。

どんな本

「現場でカンバンをどう使っていけばいいですか?」について説明する本です。
取り扱う内容をカンバン(プロジェクトマネジメント)に絞って、コンパクトにまとめ上げています。
(類似のテーマを扱う「カンバン仕事術」が310ページ超あるのに対して、本書は150ページ弱となっています)

「〜に絞って」と言っているのは、例えば「リーンなチームを作る」「アジャイルのプラクティスを現場に導入する」という題材の本には、「不確実性に対処する必要がある、その意義とは・・・」「安全で自律的なチームを作るためには・・・」といった、ビジネスやチームのコンテキストを補うように「周辺の話題」も扱われているものが多いです。
本書では、そうした話題だったり、あるいは「哲学」よりの話は抑制されているのかな〜と感じました。その分だけ、プラクティスよりの話の濃度が高いです。

とにかく「現場にどう導入するか」に集中をしている本であり、例えるなら「マニュアル」や「ガイド」といった感覚で付き合えるようなものだと感じます。
その内容は指示的であり、「どうすればいいか?」という迷いを誘発させずに、極端な言い方をすれば「表面的に乗ってみる」ことすら可能だと思います。それを可能にしているのは、「心底理解させる」のに距離を置くべき所で距離を置き、その代わりに端的で密度の高い文章・説明を実現している点だと思います。実用書としての側面が目立ちます。

他方で、「こうした疑問が出るだろうな」という部分は先回りして答えてくれています。
多くの章で「チェックリスト」「大雑把なQ&A」が掲載されていることなどは、そうした性質をよく顕しているものだと感じます。

お気に入りポイントかいつまみ

「カンバンってどうやるんだろう」が一通り分かる

いわゆる「タスク一覧の視覚化ツール」としてのカンバンボードではなく、プロジェクトマネジメント手法としてのカンバンとは・・・?というのは、この1冊で大凡つかめるのではないかと思います。
少なくとも、自分自身がプロジェクトをデザインする側ではなく、カンバンを利用しているチームの一員になる!という場面にあるメンバーロールにとっては、この本を一通り舐めてみると「完全に理解」できるのでは、と思います。
(※根本的に「今のチームに最適な方法は何か?」を模索して結論を出す必要があるリーダーに対しては、個人的にはカンバン仕事術の方を推したいです。その上で、「大雑把なQ&A」「トラブルシューティング」「チェックリスト」+第8-9章に目を通してみる、というのは効果的かも知れません)

大雑把なQ&A、トラブルシューティング

本文の説明を(文量的な意味で)軽量化している反面で、「困りそうな部分」をピンポイントで補うようなフォローが手厚いです。

例えば、「第2章カンバンのクイックスタートガイド」は全体でP7〜P26というボリュームなのですが、「2.6 トラブルシューティング」にP18〜P25を割いています。
その内容は以下のようなものです。

  • 問題1: 中間ステップの作業項目がすべて完了しているためにブロックされる
  • 問題2: 1つ前のステップに完了している作業項目がないためにブロックされる
  • 問題3: ある作業項目のせいでステップに通常よりも時間がかかっている
  • 問題4: 絶えずブロックされる
  • 問題5: チームの外部からの入力を待っている作業項目がブロックされる
  • 問題6: バグがチームに影響を与えている
  • 問題7: 作業項目に設計作業が必要である
  • 問題8: 重要なレビュー、デモ、カンファレンスが迫っている
  • 問題9: 新しい作業、計画の変更、要件の更新
  • 問題10: 多忙なチームメンバーに作業項目を割り当てる必要がある
  • 問題11: 一度に複数の作業項目を担当したがるチームメンバーがいる
  • 問題12: ツールや自動化を改善する時間が取れない
  • 問題13: チームに新しいメンバーが参加する
  • 問題14: デイリースタンドアップミーティングで設計について話し合っている時間が長い
  • 問題15: デイリースタンドアップミーティングに参加できないチームメンバーが居る
  • 問題16: チームがプロセスの細かい部分に気を取られすぎている

他の管理手法からの移行について言及されている

個人的に「この本を特徴づけている内容だな」と最初に感じたのは、「第4章 ウォーターフォールからの適応」「第5章 スクラムからの進化」という章が設けられている点です。
とりわけ、スクラムの難しさや「守破離」の次のステップを目指している人にとっては、第5章のテーマは目を引くものなのではないでしょうか。

個人的な理解として、カンバンの方がスクラムより進歩的なものだと感じています。
それは「ルールが少ない」からです。ただし、スクラムにあるルールは「何を成し遂げたいか」「それに対してどういう罠に陥りやすいか」という観点でデザインされたガードレールだとも考えています。すなわち、そこを外れて自由度が上がりすぎることで失敗のリスクも高まるはずです。

いずれにせよ「プロセスやツールより対話を」重視するのが基本姿勢だと思いますので、「ちょっと気になったからどうなるか試してみる、その上で結果を測定してみる」のもアリでしょう。
その際にも、こうした「移行ガイド」があるのは有難いことです。

「どういう点が共通なのか、どういう点は考え方を改める必要があるのか」という説明をしており、含まれる内容としては「役割と用語のマッピング」「イベントの進化」等です。
もちろん「カンバンとは」といった話や「スクラムガイド」の内容を咀嚼して、自分なりに両者の繋がりを作る事は可能かと思いますが、「比較をすることを主目的として書かれた説明」というのは腑に落ちます。

また、「スクラムで守られていたがカンバンで失われる(失われそうで不安になる)点」については、「大雑把なQ&A」で拾われます。
例えば「スクラムマスターがいなくなる」事で(組織パターンで言う)防火壁が失われる点はどうか?定期的なフィードバックを顧客から取り入れることで適応的・漸進的な開発を実現していたが、タイムボックスがなくなるとどうなるのか?など。

まとめ

スクラムやカンバンについては「やさしい本」がたくさんあるので、そうしたものに比べると本書は少し「お硬い」ような印象を受けるかも知れません。また、「背景・理念」と「方針・方法」の比重が後者に寄っている(印象がある)ので、少し統制的で指示的な内容にも感じられそうです。

その辺りも踏まえつつ、文量がコンパクトによくまとまっており、タイトルの通り「今すぐ実践!」を実現していると思います。
マニュアル的な雰囲気の本だな、というのが個人的な感想です。