「UltimateAgileStories 10th Anniversary」

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

day-21は「UltimateAgileStories 10th Anniversary」です。

booth.pm

どんな本

国内のアジャイル系のコミュニティの人達による、同人誌です。
内容はさまざま!!目次を眺めていると、Scrum Festみたいなイベントのタイムテーブルを見ているような感覚になりました。楽しいですね。

見方を変えると、「当たり前なこと」が書いていなくて「好きな人が好き勝手書いている」という感じでもあるので、オタク感というか同人誌っぽさがあり素敵でした!

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

全体的にどういう話か、というのをまとめるのが難しいので、(今の気分で)好きだった話をいくつか。

アジャイル放談

最初の記事。
アジャイル、XPにせよ何にせよ基本的には『物理的に空間を共有し、近い距離で働くこと』を強く推奨しているものが多いと思います。
そんな中で、2020年に出された本誌では「リモートワークどうよ?」といった話を。座談会の書き起こしです。

色々な所に話が飛び火しながら、後半以降の「アジャイルとは何だったのか」「スクラムは、XPは、」なトピックが出てくるとギアが1つ上る感じが。
アジャイルコーチやスクラムマスターたちの「実際にやってみて何が起きたか、どうなったか」という話には、なるほどなぁと感じる部分が多くあります。
(あと単純に皆さんの知識の深さや話題の広さがすげぇ・・)

その中でも、「いきいきとした開発(とアジャイル)」という話があったり、「スクラムほどXPが(「マーケティング」的に)成功しなかったのは。何が違ったのか」とか「でも、ワクワクするのはどっちだ・・・」とか、めちゃくちゃ面白いなーと思いました。

そして角谷さんの↓の講演が見たくなる・・・アーカイブとかあるのだろうか

speakerdeck.com

Fearless Change でやってみる現場改善

Fearless Changeかなり好きな本なのですけど、それを「使う」事に目を向けた話です。
もともとがパターンランゲージの本として書かれているので、個別の「パターン」を取り入れていくだけでなく「組み合わせることで全体を作り上げる」というための機能もしっかり備えているのです。
流れ、組み立て、そうした後に得られるアウトカムを・・・というのは、「うんうん、そうだよねやっぱりそれをやりたいんだもんな」と思いながら読みました。

新任のスクラムマスターが観察すべき5つのこと

私のCSM研修の際のトレーナーであるharadakiroさんの章。
とてもコンパクトなのですが、力強さを感じました。

自分自身として、今は(スクラムチームでもないのだけど)プロジェクトを直接指揮するよりもプロジェクトリーダーの壁打ち*1役のような関わり方が多いです。
で、プロジェクトって生き物だよな〜と思っているので、「まぁ元気そうならどうにかなるんじゃない」という感覚もあり。勝手に立ち上がれる、自分で進める、適度に進んで行ければゴールには着くでしょう!と。 逆に「まだ元気が足りねぇな」ってなると、必死でテコ使ってぐいぐい押したりするわけです。

この章で言っていること、すなわち「観察すべきこと」は全て「○○は元気か」「○○に活気はあるか」で纏められています。
元気があれば何でも出来る。あ、これで冒頭の話・・「そもそも、開発っていきいきとやりたかったはずだよね」的なものにも繋がっていくんですかね。

中動態と感覚統合とアジャイル

書いてある内容が難しい・・・という感じはしつつ、これは深く頷きながら読みつつ「はぁ〜ん」と嘆息しながら読みました。

そこでアジャイルを中動的に捉えることを推奨したいです。自分ごとと して内なる主語としてその過程の中にいる立場で地に足をつけ、成長し ていく姿勢です。そこには「〜する」も「〜される」もありません。そ の状態になるためには自己を見つめ、自由と強制のどちらでもない立ち 位置に「いる」ことが大切になるはずです。プラクティスの実践や学び に高揚することは大事なことですが、今自分たちはどのような過程に「い る」のかに着目することで情熱と冷静の間に身を置くことができるので はないでしょうか。複数の人たちが集まり協働するチームだからこそこ の姿勢が大切だと実感しています。 『UltimateAgileStories 10th Anniversary P111』

「する」でも「される」でもなく、「ある」とでも言うような。 強い意志を持って(ぐいっと自他を押すように)動くでもなく、誰かに命令されてやるでもなく、自然と「次の行動が湧く」という感じなのかな?と捉えています。
で、これってOODA LOOPでいうところの「皮膚感覚」だな、と。

私は、数年前より感覚統合とアジャイルチームをテーマにして講演やデ ィスカッションを重ねてきました。そこで大切なことは、アジャイルや チームでの活動においては、如何にチームとして感覚統合できるかがプ ロダクトとチームの成長に関係しているのではないかということです。 (中略)
チームの感覚統合とは、「今の状況がわかっている」(固有受容覚)と 「バランスが取れている」(前庭覚)であり、これを土台として姿勢・ 言葉・感情 → 学習・対話・実践へと繋がっていきます。土台がないと 学習・対話・実践したことが定着せず、能動態と受動態の対立構造に陥 ってしまい、本質的な取り組みに注力できなくなるという構図です。 『UltimateAgileStories 10th Anniversary P112』

ミッション(プロダクトビジョン、ワーキングアグリーメント等のValue)による方向付けと、「見えるか」による現状理解の解像度を揃える&十分に情報を流通させ続けることによって、自然と「これが今やるべきことだな」といったタスク感覚が自然と(内発と外発の中間、もしくは融合地点から)湧いてきて、それに違和感もなく動く。気付いたら勝手に体が動いているような、そんなチームはとても強いよなぁと思います。

まとめ

この記事を書くために、改めて目次を読み返していると「あれもこれも面白そうなものがたくさんあるよな〜」と再実感しました。
気が向いた時にパラパラとめくって読みたい本だな、と思います。
あと同シリーズの過去の版も興味あるかもな、読んでみたいな〜

*1:というよりは積極的にティーチング〜コンサルティング寄りのコミュニケーションが多いですが

「Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド」

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

day-20は「Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド」です。

どんな本

スクラムの生みの親である二名による、「ソフトウェアを開発”しない”人に向けて書いた」、なぜスクラムが成果を上げるのか?を説明した本です。
すなわちシニアな管理者や経営者向けの本ですね。これまでに自分が読んだ本だと、アジャイル開発とスクラム スクラム 仕事が4倍速くなる“世界標準”のチーム戦術辺りと対象読者が近いのかなぁ。

これまでの開発プロセスから脱却すべき理由や、スクラムの原理についての説明、そしてプロジェクトレベルでのスクラムの動き方から複数チーム、組織レベルでの変革について取り扱っています。
「現場レベルでのコツ、ガイドライン」みたいな話はスコープ外ですが、「ビジネスに対してどう有効なのか」を集中的に記述しています。

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

ビジネスサイドや管理側から見たスクラム

スクラムについて「実際にやる側としてどう頑張るか」という本はとても多く、役立つものだと思います。が、「そうじゃない人向け」の説明が多くあるのはそんなに多くないかも知れません。自分の見ている範囲が狭いだけな気もするけども。

概要レベルで「スクラムチームは何をしているのか(どういう風に動いているのか)」と、「どうやったら良い・悪いを判断できるのか」をチームの外から知るのには大きな価値があると思います。
そうした話こそ、本書に書かれていることです。

第1部では「経験主義」に主に焦点を当てながら、自己組織化や透明性についても紹介されていました。
この辺りを押さえながら、スクラムでよく使われるメトリクス = ベロシティだったりPBIの数だったり、を知ることでコミュニケーションに役立てていけるはずです。

目のさめるような事例

スクラムをやってどうなったか」という話が実在の企業のエピソードとして所々で紹介されています。
顧客満足度の改善、技術的負債の減少、進捗の透明化と従業員の活性化、etc・・・

中には「Adobe CSの開発にスクラムを導入したら品質が上がった」といった、「あのプロダクトの裏にもそんな話が・・・」という(内容以上に?)ワクワクするものも含まれています。

まとめ

本書が組織内でのレイヤーの高い人に向けて書かれていることもあり、大きな話も扱われています。
スクラムとは」から始まり、導入の拡大、そして「企業の変革」へと話が展開されました。副題にもある通り「組織変革”成功”ガイド」というのが、やはり最終的に目指している地平だと思います。
スクラムを始めてみましょう!」といった本に比べれば、なかなか息の長い話になっていきそうです。実践していって、その「ゴール」にたどり着く・・というには時間がかかりすぎてじれったさもありそうです。
ボリューム自体はそんなに多くない本ですが、今の自分達がどこにいるのか?を分析して比較しながら、タイミングに合わせて必要な所を読んで見るというのも良いかも知れません。

「エクストリームプログラミング」

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

day-19は「エクストリームプログラミング」です。

どんな本

アジャイル開発とは何だったのか、その原点を再考する新訳
優れた技術力と良好な人間関係をもってしてソフトウェア開発を成功に導く、ケント・ベックによるXP(エクストリームプログラミング)のすべてを集約した> 名著“Extreme Programming Explained: Embrace Change” の新訳版。アジャイル開発の原点を知る、必読の一冊です。
(amazon.co.jpの書籍紹介より)

「Extreme Programming Explained: Embrace Change (English Edition) 2nd」の翻訳で、出版時期は2004年なので「アジャイルソフトウェア開発宣言」後となります。初版は1999年なので、その前ですね。

いずれにせよ、XPの父と呼ばれる1人であるKent Beck本人が、「アジャイル」や「XP」がその概念も言葉も今ほど一般的に普及させる前に書かれた、「XPとは何であるか」という本です。(それもあって、第2版は初版よりも少し「前提」が変わっている感じもありそうです。)
逆に言えば「アジャイル」という言葉を用いずにXPを説明しきっている本であり、実際に本文中に「アジャイル」という単語は基本的に出てきません*1
「既に存在する概念を取り扱った本ではない」という立ち位置だからこそ、読者に対して本質的な説得力を見せつけてくれるような印象を持ちました。

内容としては、「価値」「原則」を全体の4割近くを割いて説明した後に、「主要プラクティス」「導出プラクティス」があり、ここまでが「第1部 XPの探求」。そして「第2部 XPの哲学」として、哲学やルーツ、現在について語られています。

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

XPの価値・原則

第1章の書き出しが「エクストリームプログラミング(XP)はソーシャルチェンジである」から始まっているように、XPは根本的で広大なインパクトをもたらす(or与えようとしている)取り組みだと思います。

では、それは一体なにを目指しているものなのか・・・というのが、まさに「価値」の部分に現れてくるのです。

同じく第1章の最初のページにある文言。

XPとは、自分たちのできることをオープンにして、それを実行に移すことだ。そして、そのことを他の人にも認めたり、期待したりすることだ。「自分は頭がいいんだから、ひとりで上を目指せばいい」などという未熟な思い込みを克服することだ。もっと広い世界で成熟した場所を見つけることだ。ビジネスや仕事も含めたコミュニティーのなかで、自分の居場所を見つけることだ。自己超越のプロセスのことだ。そのプロセスのなかで、開発者として最善を尽くすことだ。ビジネスのためになる優れたコードを書くことだ。

Kent Beck,Cynthia Andres. エクストリームプログラミング (Japanese Edition) (Kindle の位置No.273-278). Kindle 版.

何かをするには、個人であれチームであれ「思考」と「行動」が必要になりますが、その裏には「何が良いと判断するか」「どうしたら上手くいくか」といった、色々な指針があります。
そこで「価値」「原則」「プラクティス」という、ハッキリと違うようで似通った部分もあり、どうにも言葉で説明が難しいような概念が出てきたりもします。

ケントは、ここの違い(=何をもたらすか)をまずは明確にした上で、「価値を明確にすることが重要だ」と言います。
ペアプロ、CI、TDDなどの「プラクティス」もそれぞれ単体で非常にパワフルな効果を発揮します。
しかし、XPはもっと壮大な話だと知りました。
それらを意味づけて統合していくものが「価値」です。

価値を明確にすることが重要だ。価値がなければ、プラクティスはすぐに機械的な作業になってしまう。活動そのものが目的となり、本来の目的や方向性が失われてしまう。プログラマーが欠陥を認めないとすると、それは技術ではなく価値の問題だろう。欠陥そのものは技術の問題かもしれないが、欠陥から学ぼうとしないのは、そのプログラマーが学習や自己改善に価値を置いていないことの表れだ。これでは、プログラム、組織、プログラマーのいずれの利益にもならない。プログラマーがプラクティス(ここでは根本原因分析)を効果的な時期に、正当な理由で実行できることが、価値とプラクティスが結び付いているという意味である。価値はプラクティスに目的をもたらしてくれる。

Kent Beck,Cynthia Andres. エクストリームプログラミング (Japanese Edition) (Kindle の位置No.461-468). Kindle 版.

「価値」を咀嚼し、それをプログラマや開発チームの世界に落とし込んだ「原則」、その実装としての「プラクティス」。「価値」を中心に、どれかに偏りすぎることなく抑えていくことが、開発活動にエネルギーを与えてくれる感じがしました。

また、価値は時代が変わっても変化しにくいもので、プラクティスは技術の進化によって陳腐化(当たり前化)したり不要化したりもするのかな?という気もします。

XPについて触れる

XPは、マインド・チーム・技術プラクティス・コミュニケーション・計画・・・と、非常に多岐に渡って話をしています。
スクラムほど普及しなかった」という言説も見かけますが、その理由としては「大きすぎてとっつきにくい」という性質にもあるのかな?と思います。
(反面、スクラムはとても小さくまとまっていると思います。なので「やってみた」とは言いやすい。理論、価値基準をしっかりと理解しそこから実践につながらなければ・・という点では同じことが言えると思いますが。)

訳者あとがきにある説明にも、グッとくるものがあります。

すでにXPのプラクティスを実施しているのであれば、「私のチームはエクストリームですか?」と聞きたくなるかもしれない(第21章参照)。ここがXPの難しいところであり、魅力でもあるのだが、XPが提唱する「価値、原則、プラクティス」は、絶対に守らなければいけない「決まりごと」ではない。したがって、何も考えずに、本書に書かれたとおりに機械的にプラクティスを実施していては、XPとはいえないのである。それはむしろケント・ベックが否定する「計画立案と実行作業の分離」に近い(第18章参照)。XPの本来のあり方とは、「価値、原則、プラクティス」のそれぞれを言葉にして、場合によっては利用者であるあなた自身が自分の言葉を生み出しながら、利用することに他ならない。

Kent Beck,Cynthia Andres. エクストリームプログラミング (Japanese Edition) (Kindle の位置No.3445-3452). Kindle 版.

というわけで、「どういうやり方がXPなのか」は、多くのプラクティスが内包されて入るものの「これがXPだ」と言いにくいのだと思います。
逆に、テストファーストプログラミングや継続的インテグレーションリファクタリングなどの非常に多くの個別的なプラクティスについては、多くのチームで取り入れられているのではないでしょうか。もはやXPよりも有名になっているものすらあるかも知れません。

自分自身、なんか「良い開発のやり方」を知るたびに「XPのプラクティスの1つに数えられているものだ」と言われるような経験を幾度となくしていました。
XPってなんなんだ・・・・それを、やっと雰囲気をつかめた気がします。

多くのアジャイルの本がXPを貴重としている感じがあるのも、頷けるような気がしました。完成度というか網羅性みたいなものが凄いんだな、と・・・

まとめ

スクラムに最初に触れた当初は、XPといえばTDDやCI/CDとかでしょ?技術的プラクティスを補うものだよね、なんてイメージを持っていました。
それが、少し勉強をし始めると、「なんだかアジャイルの人たちの間ではXPって大人気だな、最終的にはXPに至りそうな雰囲気すらあるな」と感じ始めます。
そうした時に覚える「何があるんだろう、不思議だなー」という感情に答えてくれる1冊でした。

アジャイルが〜とか、ましてXPが〜なんて関係なく、現代のプログラミングを仕事にしている人にはひとまず読んでみる価値がある1冊なのでは・・・とすら思います。
やはり、様々なパターン・ランゲージと同様に「経験的に導かれた上手くいくプラクティス、それを全体性を持ってまとめあげた体系ないし集合」という側面がXPにもあります。前者を掻い摘んで見るだけでも言いし、「道標」として後者について = 価値や原則について触れてみることには大きな意義があると思うのです。

で、初手としては多少ボリューミーな感じもあるかもしれませんが、ここまで丁寧に描かれた本で読みやすくまとまっているとなれば、「ちょっと頑張って読んで見る」くらいには値する本なのではないかな・・
実際、個人的にはボリュームとしても難易度としても苦痛に感じるところも無く、楽しく読み進めることが出来ました。

特に「価値」「原則」のあたりは、折に触れて読み返してみたいなぁという気もします。

*1:Kindle for macで単語検索をかけた感じだと・・・。もしかしたら見落としているかも。とはいえ、本書のスタンスを理解する上ではクリティカルな見落としや誤解でも無い気がする

「スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス」

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

day-19は「スクラム実践入門 ── 成果を生み出すアジャイル開発プロセス」です。

どんな本

スクラムの入門的な本で、内容としてはスクラムガイドにある内容の解説 + "how"の部分の肉付け、という感じでしょうか。
レベル感としては「スクラムの基礎的な学習はした、チームで使い始めた(検討している)」くらいの位置かな?と思います。
対象としては、スクラムマスター、スクラムチームのメンバー(PO+開発者)、組織にスクラ導入を考えているマネージャーとかそういう感じが。

ただし、これ1冊で「しっかりと型が身につく」というほど指導的な内容ではなく、どちらかというと「学習した内容を復習しよう」〜「より”現場的”な話や事例に触れてみよう」な印象です。

網羅している範囲としては「スクラムの基礎的な知識」と「スクラムと組み合わせて(=スクラムガイドには載っていない)使いやすいプラクティス」「実際に導入した企業でのチーム事例」「よくある問題と対応」のパートに分かれます。

特徴的なのは、日本国内のWeb企業に務める方々の執筆であり、事例についても「GMOペパボ」「mixi」「DeNA」と馴染み深い企業が並びます。
(自分が手にとった本が偏っているのもありますが)今まで、スクラムアジャイルについての書籍は翻訳本が多かったので、新鮮さを感じました。

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

色々な現場の導入・運用事例の話はおもしろい

カンファレンスでの発表や雑誌記事などでも多く見られますが、やはり「導入してみた」「そのきっかけは」「難しかった所、上手く行かなかった所、工夫した所」というエピソードは読んでいておもしろいですよね。

とりわけ、本書は「どう導入するか」にやや力点が置かれているような印象があり、実際に事例3つのうち2つは副題に「導入」という単語が入っており、複数の章に分けて取り扱われている「よくある問題」のうち1章は「スクラム導入時によくある問題と解決策」です。

従来型の開発管理からアジャイル/スクラムへの移行には、とても「未知の壁」が多く立ちはだかります。
実践の当事者である著者たちが「こういうので困ったんだよね・・」という感覚が、良い意味で透けて見えるようでした。

自然な日本語で文量もコンパクト

執筆陣は日本国内で働く現役のメンバーであり、出版も2015年(第1版)・2019年(第2版)と比較的最近の本であることから、文章が読みやすいような気がします。
個人的には、「翻訳本は文体が読みにくい・頭に入ってきにくい」といった抵抗感はあまりないのですが、周りの人からはそういう声もチラホラと聞くことがあるので、本を読む上での1つの障害になったりするのかな?とも思います。で、この本についてはその懸念はなさそうだ、と。

また、文量も図表や見出しの装飾も十分にある上での200ページ強と、テーマの広さからいえばコンパクトに纏まっていると思います。
「WEB +DB PRESS Plusシリーズ」に対する信頼感もある─

これらの要素が揃うと、手に取りやすい・他の人にも薦めやすいものになっていくなぁと感じました。

まとめ

タイトル通り「実践入門」としての位置づけを目指した本だったな、という印象です。

内容の目新しさはあるか・新しく得られた知識があるか?というと・・・
例えば「エッセンシャル・スクラム」「スクラム現場ガイド」「アジャイルサムライ」「アジャイルな見積りと計画づくり」辺りを読了済みであれば、すでに十分に抑えられているかもなぁとは正直に思いました。それに、そうした方が深さも増すし実践しやすくなると思います。

・・・が、それって一体トータル何頁分を読むことになるんだ??という話があり。
あくまで「(実践)入門」として、次の学びに繋げやすいし「とりあえず現場でやってみるか!」となりやすい本である所に意義があると感じます。
(そういう意味では、参考書籍のリストとかあればメッチャ良かったなぁ)

重くなくて接しやすい1冊と言えるのではないでしょうか〜

「ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方」

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

day-18は「ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方」です。

どんな本

最初に読んだ当時、このブログでも言及しています。

daisuki.nichiyoubi.land

「どのように、ミッションオリエンテッドで一枚岩な組織を作るか」「どう維持するか」という話が展開されています。
発売当初、「ユニコーン企業はスクラムをやっていない」というキャッチーなセリフが出回って(独り歩き?)いた印象も強く、また「エンタープライズ企業のアジャイルチームと(Spotifyモデルの)スクワッドは何が違うのか」という風に対比したりなど、「アジャイルの本ではないし、価値を共有しないものだ」とも思われるかも知れませんが。
しかし、実際には「顧客、インパクト、学習」を非常に重視しており、また「ミッションコマンドを実現する・パワー・トゥ・ザ・エッジを備えるために、アイデンティティの擁立と自律的な組織を育む」というデザインを説いており、重視している価値観や哲学はアジャイル系の話と非常に近しい・・・というか、アジャイルソフトウェア開発をやる人にとっても大きな意味のある一冊だな、という感想です。

(言いたいこととしては、「時限的なプロジェクトによる開発」への批判であり、決して「アジャイル」への否定はする必要はないんじゃないかな〜とは個人的に思ったりしました。)

そして、「文量も多くなく、文章も平易で、挿絵の雰囲気も楽しい」というのも、本書をオススメしやすい嬉しい本たらしめています。

また、余談ですが、こういう繋がりも知ってみると何だか面白いなぁと思うのです。

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

どうやって「やるべきこと」をやりながら「やらなきゃいけないこと」を補うか

本書が翻訳された時点で「SpotifyはもうSpotifyモデルを使っていない」という話が出回っていました。
訳者あとがきでも、『「Spotifyモデル」はそれ以後も変化していったようです。」として言及されています。

では、一体何なのか?というと、まずは「ミッションを隅々まで浸透させて、自律的に動けるように組織する」ことが最上段の戦略として存在し。
そして、「自律的にミッションを達成できるように、価値に基づいた強い連帯」と「能力差やサイロ化による不活性を防ぐための支援の形態」があるぞということだと思いました。
前者が「やるべきこと」だとして、後者はある意味での必要悪、「やらなきゃいけないこと」なのかなと。
また、どこに流動性をもたせるか、どういう単位での括りを作るか?については、もはや「枝葉」に位置するものでしかないような気がするのです。それよりも、「骨格」となるのは、やはりミッションや信頼といった部分なのかな、と。

そういった意味で、個人的には本書中で特に重要なのは「3章まで」「5章」「9章」であって、それらの総まとめが「10章」なのかな?なんて感じています。

ちなみに、SpotifyモデルはCAL-1研修でも取り上げられていました。

まとめ

訳者あとがきが公開されており、これを読むだけでも雰囲気をかなり感じられるのではないかと思います。

scrapbox.io

また、かなり話題になった本(で読みやすい)でもあるので、ネット上に色々なレビューが投稿されています。楽しいですね。

これを読んで「もっとスタートアップみたいに振る舞う」には、何をどこから始めていけるのだろう・・・というのが我々読者にとっての大きな宿題であるように感じています。
(もちろん、「形だけ真似するな」と散々書かれているのに「組織構造を模倣しよう」なんて愚策は打ちませんよね)

良い組織を作る、このくらいの「柔軟で縛りが少なくて複雑」な感じのする組織形態に耐えうるような企業文化の根を張らせる、そのためにまずはマインドを育む、始めるのはごく一部のリーダーシップを持つ人から・・・・・と組み立てて考えていくと、「今からできること・やるべきこと」がゼロではないはず。

「スクラム現場ガイド スクラムを始めてみたけどうまくいかない時に読む本」

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

day-18は「スクラム現場ガイド スクラムを始めてみたけどうまくいかない時に読む本」です。

どんな本

「理解は簡単だが実践は困難」と言われるスクラムの、「始めてはみたものの実際にコレどーすんのよ」みたいな話を、よい広さと深さでまとめてくれている素晴らしい1冊・・といった印象です。
序文としてジェフ・サザーランドが寄稿しているなど、その時点で凄い信頼できそうだなーと思います。

あなたが始めたばかりならば、ミッチの本が役に立つだろう。あなたがいま苦労しているところなら、本書はもっと役に立つ。すでに良い結果を出しているなら、ミッチの助けでさらに素晴らしい結果を出せる。改善は決して終わることはなく、ミッチの洞察は真に有用だ。
『序文 P19』

アジャイルとは価値創造と卓越のための終わりなき旅であり、その道を「2,3歩ほど歩みだした」人にとって最も意味を持つ本なのかなと。

まえがきにある「対象読者」によれば

スクラムアジャイルを始めようと思っていたり、まさに始めたところだったり、1年くらいやってきて道に迷ったように感じているなら、本書はあなたのためにある。僕はは公式には、新たにプロジェクトを始めて6ヶ月から18ヶ月の12ヶ月の間にいる企業が対象だとしている。
『まえがき P21』

目次を見ると、スクラムを実際にやっている(やり始めて少し経った)人にとっては「そうそう、まさにそれ!難しかったり上手くチームでやれてないんだ・・・」というツボを刺激してくれそうな感じが伝わるのではないでしょうか。サポートページから確認できます。
ただ、始めようとしている・本当に始めたばかりの段階にある時は、この前に2,3冊くらいはスクラムに関連する書籍を読んだりすると良いのかなーとも。網羅的ではあるものの体系的ではなく、自身の経験と照らし合わせながら読む事で深みが増す本だと思うからです。

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

実践的であること

タイトルに「現場」とある通り、「こうやって対処すれば良いのだな」というヒントをたくさん得ることが出来ます。
もちろん、スクラムの実践については「理論や背景を理解し、自身のコンテキストに合わせて自分で考える」ことは欠かせませんが。

例えば「PJのはじめに見積もりを出さなければいけない」とか言った時に、ベロシティはどう扱えばいいか?
それに対しては、「過去のデータを使う」「わからないなりに見積もる」「様子を見る」という3つのアイディアを挙げています。
基本的には「様子を見る」を推しつつ、ただし現実には「2〜3スプリントやってみないと全体の規模と消化時期が分からない」とも言えない場面もあるはずです。そうした事情を考慮して、本書では「過去の〜」「わからないなりに〜」という”ありそうな手法”についても、注意点を指摘しながらそれぞれどうやるか?を説明しています。

ベロシティについていえば、「平均を出しつつ、(チーム外の)人には幅を持たせて伝える」といったやり方も、現実的なアドバイスだなぁと感じました。

こうした「理想と現実」をバランス良く扱っているなぁというのが、本書の所々で見受けられました。

プロジェクトの運用中に起こる諸問題

プロジェクトは生き物であるため、素朴に「開発」だけをしている訳にも行かず・・・生産性やチームに難しい影響を与える場面が多々あるかと思います。
スクラム(やアジャイルの「タイムボックス」と「イテレーション」)は、臨機応変さを提供しますが、それは「価値出力への驚異」に対する適応であって「生産性への驚異」には、認めざるを得ないような視点も別の観点もあるわけです。

そうしたトピックも、この「実践的」では取り扱われています。

主観でピックアップして例を上げれば、

  • (コミュニケーションを流暢に行うための)チームのコアタイム
  • 欠陥の扱い方(スプリントへの組み込み方)
  • サステインドエンジニアリング
  • 生産的なデイリースタンドアップのための観点、テクニック
  • 新しいチームメンバー(・・・については、「どういう問題が起こるか」を論じてはいるものの「対処の方法」に関しては軽く触れられる程度ですが)

などなど。
ともすれば、学び始めた人にとっては「え、スクラムってこういう対応方法でも良いのか・・?」とドキドキしてしまうような提案も含まれていますが、逆に言えば「ここまで(純粋な理想から外れても)やって大丈夫なのか」という安心材料になる気もします。

まとめ

チームのコーチとしてのスクラムマスターは、本書の内容を一通り理解しておくことで、観察眼を磨いたり活用可能なワークアラウンドを蓄えることが出来るような気がします。
それと同時に、この本はスクラムマスター以外のチームで読んでみるのもとても面白いだろうな、とも感じます。全員が知っておく価値があるように思うからです。

やはり「やってみると色々と考えたり決めなければいけないことが多い・・・」のが(フレームワークとしての)スクラムかと思うので、こうした「現場のお悩み」に寄り添ってくれる本は、手元に1冊あると嬉しいものです。

「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」

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

day-17は「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」です。

どんな本

この本は以前にも読後感想記を上げています。

daisuki.nichiyoubi.land

2020年に読んだ本の中で個人的ベスト3に入るような良書だと思っており、「とても読みやすくて、刺さって、自分の中にある”理想”が研ぎ澄まされる」みたいな印象を受けました。あと、ページ数が少ないという点でも凄い。他人に薦めてぇ〜〜ってなる1冊です。

この本は直接的に「アジャイルになろう!」なんて扱ったものではありませんが、「顧客に価値を届けよう」というのは正にアジャイルが手に入れたかった「結果」そのものであり、「答えを最初に決めず、仮説を持って実験をして常に最適を目指し続ける」というのはリーン思考やアジャイルの精神性そのものであるように感じました。

という訳で、ちょっとアジャイルスクラムを齧ってみた今の自分から、この本はどんな意味を持っているのか?をまとめてみようと思います。

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

アウトカムに焦点を当て、実験マインドを取り入れる

これは、4章「プロダクト主導組織」での「○○主導」を類型化する中で、プロダクト主導組織について触れた節にある表現です。
本書の最も主要なテーマの1つであると同時に、個人的にもかなり刺激を受けた考え方でした。

そして、これは「動くソフトウェアを」「計画に従うことよりも変化への対応を」「価値のあるソフトウェアを早く継続的に」「フィードバック(XP)」「検査と適応(スクラム)」といった、アジャイルマインドとでも呼ぶべき重要な態度と同じ地平を見据えていると感じます。

本書の副題である「ビルドトラップ」が、「価値から逸脱した開発活動」や「柔軟性を欠いた硬直的なリリース計画」の先に陥る状況だとして、「顧客の方を向いて、必要なことをやっていこう」というのは偉大な処方箋となります。

そして、そんな「プロダクト主導組織とはどういう在り方か」「何が必要で、どう作るか」が本書で説明される話題でもあるのです。

既知/未知のマトリックス

「プロダクト開発は不確実性に満ちている」とし、それに対応するために「学習」が挙げられていますが、では何から学んでいけばいいのか?
状況を紐解いて進むべき方向(学ぶべき課題)を整理する、というための考え方として「未知・既知」を組み合わせたマトリックスが紹介されています。

「既知の既知」「既知の未知」「未知の既知」「未知の未知」という4象限で、情報を整理しようと試みるものです。 プロダクトマネジメントは、それらの「未知」との向き合い方が非常に重要になります。リソースをどう活かし、課題をどう解くか?に直結するからです。

この考え方・整理の仕方は、「プロダクトをどう作るか」という枠組みをこえて、今の自分がプロジェクトや組織だったり、あるいは自分自身がやるべきことを考える上で、非常に重視する考え方のフレームワークとなりました。
実際に、これをベースとしたフレームワークを、チームの形成期においてアイデンティティ強化のためのワークとして扱ってみたり、ファシリテーションをする際に情報の整理のための観点として利用したりしています。パワフルなツールだな、と感じました。

スクラム(など)との組み合わせ

スクラムは時折、勘違いされて期待されすぎている・・というように感じることがあります。
乱暴に言えば、「どうやってうまく協働するか」というフレームワークとして、スクラムガイドで説明されている内容は主に組織面をクローズアップしている”だけ”のはずが、「良いものが作れて、価値が最大化される」ところまで期待を背負い込まされてしまっているような、そんな違和感です。

価値のあるものを作りましょう、とは言うものの価値の求め方を教えてはいない。品質を上げましょう、とはいうものの品質の上げ方を教えてはいない。といったような。
そのシンプルさと汎用性が強みで魅力だと感じるのですが、それ1本で「完璧」なはずではないのです。

プロダクト開発を「プロダクト(やプロダクトビジョン)」「技術」「チーム」の3本柱から成るものとして捉えるなら、スクラムは「チーム」の話だと言うのが、個人的にはしっくりきます*1

それに対して、本書は「プロダクト」の側面を語ったものです。 「ウケるサービスの作り方」ではないけど。
プロダクトを考える、それを組織レベルでやるには?という。

(プロダクトを測定する)良い指標、戦略・戦術の策定と展開、プロダクトマネージャーのキャリア(階層と責任)、オペレーション・・といった内容です。

まとめ

アジャイルの本」で補いきれない部分を、しかし志を共にしながら描いてくれている!!という気持ちになる1冊です。
実現するには相当にレベルが高いとも思います。が、始めなければ進まないはずです。
理想的な組織状態に至るまでの大まかな道筋を与えてくれる良書だなと。

・・・この記事を書くにあたって、パラパラとページを捲りながら軽く読み返していたのですが、直近で抱えている個人的なモヤモヤに刺さりすぎてヤベェなってなりましたアドベント終わったら1回ちゃんと読もう!

*1:ただ、例えば「チームビルディングのためのパターン」とでもいうような、具体的な話を扱っている訳ではありませんが。「どこにでも適用できる」といった最大公約的な話をしており、チームによって「足りないものを補う」「細かい所を作り込む」という創意工夫は要求されます