期待からはじめる
今年は「今の仕事にワクワクしていません」という声をメンバーから聞く機会が増え、考えこむ機会が増えました。ワクワクとは何だろう・・・
新しい技術を取り入れること、新しい領域に取り組むこと、プロダクトや事業を大きく成長させること。さまざまなことが考えられます。 一方でその時の市場環境や事業環境を踏まえると、いつでも誰にでもワクワクする仕事は用意できないのではないか、そう考えている自分がいました。 でも「ワクワクしない」気持ちは、本当にそれらの要因から来ているのでしょうか?
数ヶ月に渡って悩んでいたある時、私が一緒に働くメンバーは「誰かの役に立つプロダクトを開発すること」がやりたくて集まってきていることをふと思い出しました。 採用面接で、中長期のキャリアを考える面談で、飲み会やふとした雑談で、何度も話し何度も聞いた話です。 そこに気がついてからは「誰かの役に立つと感じられるプロダクトが開発できていない」と問題を捉え直しました。 ユーザーにとっての利用価値や、事業戦略における重要性を噛み砕いて細かく説明することも考えました。しかし求められていることはこれでは無さそうだと考え、実行に移してはいません。 ワクワクを引き出すには、もっとメンバーの根源的な要求に応える必要があるはずです。
最終的に取った打ち手はすごくシンプルで「抽象度が高いまま課題をチーム/メンバーに与える」ことを意識して増やしました。 仕事の難易度は上がり、課題の理解や分解のためユーザーに接する機会が増え、企画・デザイン・開発といった職責の枠を超えて協力する必要が出てきます。 「難しい仕事をお願いしていることは認識しているつもりです。でもこれが会社のため・事業のため・皆さんのためになると考えてお願いしています。」メンバーが壁に当たっている時、意識して何度も口にして伝えました。
マネジメントキャリアを長く積むほど、「このぐらいの難易度が良いだろう」と無意識のうちに手加減ができてしまいます。段取りを整えてあげたり、大きな仕事の一部を切り出して与えたり、できるレベルの仕事に調整することはマネージャーが自然と身につけるスキルの1つです。でも、もっと期待をしてあげるべきなのではないでしょうか? コントロールできる範疇での挑戦から得られる学びに、ワクワクややりがいを感じてもらえるとは思えません。
今のメンバーといつまでも一緒に働けることはないでしょう。別れの時に「もっと色々挑戦したかった」と言われることはとても悲しいことです。誰の何のために仕事の難易度をセーブしていたのかと。 「相手に期待する」という当たり前のことから始める必要がある、これが私にとっての今年いちばんの学びでした。
この記事はEngineering Manager Advent Calendar 2日目の記事でした。
「スクラムの拡張による組織づくり」を読んで #だいすくらむ本
著者の粕谷さんから献本を頂戴しました。この記事を公開した2023年8月22日時点では発売されておらず、2023年8月26日発売予定です。
こんな書籍です
スクラムのスケーリング手法の1つであるScrum@Scaleについて、粕谷さんがChatwork社で取り組んだ経験・得られた知見を盛り込み書かれた書籍です。スクラムのスケーリング手法はLeSS(Large Scale Scrum)やSAFeがありますが、Scrum@Scaleは公式ガイドと認定研修以外であまり知ることができず、私もドキュメントには目を通したことがあるものの、どういう場面で向いているのかとかどう導入したら良いのかはさっぱりわからない状態でした。本書ではスクラムのスケーリングに向き合う覚悟から、スクラムの基本的なおさらい、Scrum@Scaleそのもの、具体的な導入の進め方まで触れられており、Scrum@Scaleに興味を持った人・導入推進を考えている人にオススメの1冊です。
ここが好き
全7章から構成される書籍ですが、私は1章と3章が特にお気に入りです。
1章はスクラムのスケーリングについて扱っています。スクラムのスケーリングは「やってはダメだ」とよく言われますが、なぜダメなのか、どういう時にスケーリングせざるを得ないのか、その時の前提条件や気をつけるポイントがどこか というのは熟達したアジャイルコーチやスクラムマスター、何らかのスクラムスケーリングフレームワークを導入し難しさを経験した人に話を聞くしか無い状態でした。本書は書籍の最初の1章できちんと落とし穴を説明してくれています。最終的にScrum@Scaleを採用するかどうかに関わらず、スクラムのスケーリングを考えている方にはこの1章を読むだけで価値があります。
また3章は架空のゲーム開発を題材として、Scrum@Scaleでの開発の流れが紹介されています。Scrum@Scaleではスクラムチームの代表者によるメタスクラムやそれに伴う追加のスクラムイベントが定義されていますが、どのイベントでどのような粒度のことを話すのかについてはガイドでは触れられていません。この章を読むことで各種イベントで扱うことが具体的に想起でき、書籍の後半で紹介される事項の理解にも役立ちます。早い段階でScrum@Scaleでの開発が追体験できるコンテンツが用意されているのは書籍構成の良いところだと思います。
こんな方におすすめ
これまでスクラムのスケーリングを考える場合、ネットで情報を探し、LeSSやScrum@Scaleを知り、公式感(Scrum Inc.)に心惹かれるものの、Scrum@Scaleの有償研修に参加するまでは踏ん切りがつかず、悩む人がそれなりにいたのでは無いかと思います。これからはこの書籍でScrum@Scaleをより深く理解し、その上で自信を持ってScrum@Scaleの有償研修に参加し、自組織で推進する際に悩みにぶつかったらこの書籍の6章(現場へどのように導入していくか)および7章(Chatworkへの導入事例の紹介)を参考により深く課題に向き合える、そんな書籍に仕上がっているかと思います。
チームではじめる「アジャイルプラクティス」実践の第一歩 CodeZine Night #3
こんなイベントでした
2023/8/4にCodeZineさん主催の勉強会に登壇し、書籍「アジャイルプラクティスガイドブック」で紹介したプラクティスを実際の事例を交えて紹介させていただきました。 30分の講演のほか、監修の川口さん・松元さんを交えてのQ&Aでは多くの質問をいただけました。多くの参加者に興味を持っていただけたイベントにできたのではないかと思います。
いただいた質問への回答
事前にいただいた分を含め22の質問をいただき、勉強会のQ&A時間では8つを取り上げることができました。 せっかくいただいた質問ですので、この場で22の質問にあらためて回答させていただきます。 当日の触れた内容全てをカバーできていませんがそこはご容赦ください。
Q1 : リファインメントの粒度はどこまでやればいいのでしょうか？
A : リファインメントの段階では実際にスプリントで着手するか決まっていないと思います。ですので時間を長くかけたり、詳細に入り込みすぎることは避け「実装に着手できそう。細かな細部は詰める必要はあるが、おおまかな実現方針は開発チームが見通せている」ぐらいがちょうど良いかと思っています。
タイミングよくryuzeeさんがバックログリファインメントに関する詳細な記事を公開していました。こちらも参考になるかと
Q2 : トップが生半可系でマスターを置いてないので効率が全く上がりません。どうしたらいいでしょうか。
A : マスター = スクラムマスターと解釈し、スクラムがうまくできていないと受け取りました。スクラムはフレームワークとして規定されたイベントや役割が相互に影響しあい、開発チームやプロセスにある問題を炙り出すように設計されたフレームワークだと思います。まずは教科書通りに進め、見つかる問題に愚直に対処していくことをお勧めします。効率(≒チームのデリバリー or 生産性?)が上がらない要因は、トップの理解不足や経験のあるスクラムマスターの不在では無いと私は考えます。経験豊富なスクラムマスターがいればうまく行く確率をあげることができるかもしれませんが、スクラムマスター・プロダクトオーナー・開発チームおよびステークホルダー含めての「スクラムの成熟度」ですので、1箇所強いメンバーを入れるだけでうまく行くことはないでしょう。
Q3 : 開発メンバーのアジャイルマインドの理解度の少なさに困っています。
A : 「XXX(人の名前が入る)はアジャイルがわかっていない」というのは私も聞いたことがありますが、何を指して言っているのでしょうね。「アジャイル」と包み隠さず、どんな開発をしていきたいのか自分たちの言葉で話せると相互理解の一歩目になるかもしれません。
川口さんの「非アジャイルマニフェスト」はアジャイルを考える出発地点として個人的に好きでよく引用しています。
Q4 : アジャイルになりたい人とそうでない人がいることに悩んでいます。
A : そういうもの(なりたい人もそうでない人もいる)だと思います。多くの会社や現場は「アジャイル開発がやりたくて選ばれている」わけではありません。「やりたいことや実現したいことを達成するためにアジャイルと呼ばれるやり方が比較的よさそう。それが組織やチームの決まりだから従っている」という人が一定数います。でも彼らもアジャイルに批判的だったり勉強しないわけでも無いです。「アジャイルになりたい人」以外は必ずしも敵ではありません。
Q5 : TDD、ペアプロ、CI/CDのエンジニアリングのプラクティスをどう適用していけばいいでしょうか。
A : 練習しながら1つずつ導入していくしか無いと思います。最初から上手にはできません。また練習ばっかりしていても現場で使っていかないと上達しません。
Q6 : うまく行かない状態になったときにプラクティスを導入してみるとおっしゃっていましたが、困ったことが顕在化しないと導入しても効果は出ないのでしょうか？
A : プラクティスの実施を忘れてしまうとか・大変なのでやめようという話が出てきた時、やめる方向に引っ張られやすいと思います。プラクティス実践を辞めた時に何が起きるのか、チームで共通認識が持てていないとそうなるでしょう。
Q7 : チームの中は整備できつつあるが、チームの外がそうはいかず限界を感じています。
A : 個人でアジャイル伝道師として渡り歩くのは大変です。チームが本当にうまく回っている(楽しそう、生き生きしている、成果が出ている など)のであれば、チームの外から秘訣を学ぼうと声をかけてくるのではないでしょうか? 手が届きやすい自チームに目を向けつつ、「整備できつつある」が主観だけでなく客観でもそう受け取ってもらえるように注力することをお勧めします。
Q8 : アジャイルの経験がないメンバー・組織職にメリットを伝え、現プロジェクトで採用してもらうことに課題を感じています。
A : 「アジャイルでやりたいです。アジャイルとはこういうものです。」という論法で説得すると2重の説明が必要です。アジャイルとは言わず「こういう進め方が向いていると考えているのでやりたいです」と自分の言葉で説明・説得することをお勧めします。
Q9 : 1スプリント1週間でアジャイル開発をしています。WFであれば単体テスト、結合テスト、シナリオテストとありますが、1週間の中で、テストをどこまですべきか悩んでいます。
収まりきれなかった質問の続き・・・
現在はある程度のテストはCIとして自動テストを組み込んでいますが、 仕様変更があった場合、実コードよりもテストコードの修正工数が多くなり、本末転倒といった感じです。 ユーザストーリーをできるだけ細かい粒度にしていくといったような工夫が必要なのでしょうか？
A : テストコードの修正も1スプリント内で取り組むべきことです。機能開発や修正の工数だけをみてスプリントで取り組むスコープを決めているのであれば、テストやデリバリーに必要な作業まで含めて考えるべきです。機能開発や修正の大きさと、影響範囲・テスト対象の広さは必ずしも比例しません。
Q10 : 途中参加のプロジェクトにはどうプラクティスを導入していけばいいでしょうか？
A : 「新規に始めるプロジェクトなら段取りよくプラクティスが導入していける」ではないと考えます。新規でも途中参加でも、チームが一番困っているところに目を向けて、プラクティスを導入して課題を解消していきましょう。
Q11 : アジャイル開発の知識だけで止まっていて、最新のアジャイルを理解していない人がとても多いことに課題を感じています。
A : 「最新のアジャイル」を私も知りたいですw。「知識ばかり集めていて現場で実践している人が少ない」という課題であれば、あまり気にしなくても良いのではないでしょうか。現場で実践を繰り返し、うまくやれている人が増えてきたら、それをみて実践する人が増えるはずだと考えています。
Q12 : 自動テストを書く文化がなかなか根付きません。どうしたらいいでしょうか。
A : なかなか根付かないものです。根気強く取り組みましょう。自分の経験で思い当たる気をつけるべきポイントは「対象を全部テストすることを優先して、工数をたくさん使ってしまうことを避ける」です。バグが起きては困る・失敗すると大きな問題になるところをテストして、自動テストでバグ・問題を見つけられて助かった経験を増やしていきましょう。自動テスト導入に前向きな人が増えてくれるはずです。
Q13 : WIP制限を最初に作るのはフロー効率を優先して進めるスクラムでは大事だと思います。ただ、気がついたらリソース効率優先になってしまっています。個人が思想を理解していないとこっそりやるみたいな状態になってしまい健全な状態になりません。どのようにするにがよいでしょうか？
A : スプリントの最後に「色々なことに取り組んで、チームは頑張ってくれたけど、デリバリーは出来てないから成果は0だよね」とバッサリ切ったりします。デリバリーできてないことをチームが問題視するのであれば、次のスプリントからは仕掛かりを減らし、一つでも出し切ろうと意識が変わるはずです。
Q14 : スコープと納期の両方大事という幻想をお持ちのお客様に対して、よしなにどう説得すればいいのでしょうか・・・？
A : コストをかけてもらいましょう。
Q15 : タスク分割すると、どうしてもタスク間で依存関係、前後の順番関係がでてきてしまうものがあります。こういった依存関係のあるタスクをどのように管理したらうまくいくのでしょうか？
A : スプリントプランニングで依存関係や順番関係を整理・議論できていますか？ここに困るチームは話していないことが多いと感じています。「考えずに進めていたら依存関係にハマってしまい、今振り返れば計画の時点で気がつけたはずなのに‥」というパターンです。
Q16 : プランニングにおける見積もりはどのように行ったら良いでしょうか？基準を決めたほうが良いでしょうか？
A : 工数や期日の絶対見積もりではなく、開発規模の相対見積もりをしましょう。
Q17 : 「PBI はユーザーに価値があることを担保したうえでスプリント（１週間）内にできる単位で分割する」という定義で運用したいと考えていますが、開発チーム力が低く、１週間でユーザーに価値あるものがなかなか提供できません。
収まりきれなかった質問の続き・・・
ただし、PBI を 1 週間以内に終わらせるレベルまで分割しようとすると、ユーザーに価値がなく、レビューで何を見せればいいのか、、、となります。 また、細かい粒度にしようとすると、リファインメントに時間がかかりすぎ、開発時間が減っていったり、開発者のストレスが溜まっていきます。 こういう状態ではどういったアクションから改善していけばいいでしょうか？
A1 : 「ユーザーに価値があるもの(WF的なゴールが分かっている完成系)」を意識しすぎているかもしれません。何か不確実なことがあって、ユーザーに使ってもらい学びを得たいからアジャイルに進めるのだと思います。減らしたい・学びたいことから考えるとPBIのいい粒度が見直せるかもしれません。
A2 : 開発チームが1週間のスプリントでインクリメントを作り切る力がないことを認めて受け入れて、2週間スプリントに変えることが考えられます。
Q18 : TDDは基本的に開発手法で、テストとして扱うにはテスト技法の理解が必要と考えているのですが、周囲の理解が得られにくいです。どのような伝え方をすると納得してもらえるでしょうか？
A : テスト自動化と、テストファーストと、テスト駆動開発の違いを話すことからではないでしょうか？書籍でも触れている箇所です。
Q19 : 大企業では、開発はアジャイルだが、製品出荷は従来通りの品質監査を受けなければならないケースがあります。その際に、アジャイル開発の特性を活かした効率的な品質監査を進めるための何か工夫があれば、アドバイスください。
A1 : 他部門の品質監査担当の方と仲良くなりましょう。製品出荷までの日数を縮めるためにどんな協力がお互いできるのか話しましょう。
A2 : 開発・テストが終わってもリリースまでに必要な作業が残っていることはよくあります。ドキュメントの更新・関係部門への連絡・全社QA部門による承認など、これら「未完了作業(Undoneワーク)」を認識し、少しずつスプリントに取り込んでいくことを検討しましょう。
Q20 : 品質向上と開発スピード向上を目的にアジャイル開発を導入して半年経ちましたが、成果を感じません。メンバーのアジャイル理解度の問題を感じています。アジャイル開発を導入してどれくらいの期間で定着してくる物でしょうか?
A : 新しいやり方がうまくハマった場合、1スプリント内に成果を感じられます。根気強く継続すればブレイクスルーが訪れるものではなく、チームの取り組みが上手く噛み合っていない要因が必ずどこかにあります。メンバーのアジャイル理解度(の低さ)では無いと思います。メンバーに開発でうまくできてないと思うことを素直に話してもらうことから始める必要があります。
Q21 : スキルマップを試しています。属人化が見えて、チームとしてここの属人化を解消すると決めるところまでは来ましたが、スキルレベルの低いメンバが、一人でやりたがったり、隠れてやっていたりして行動が伴わない状態です。タイミング早すぎたのでしょうか。スキルマップやる前はそうした行動は見られなかったのですが。
A : スキルマップをたくさん埋めることが良いことだと誤解している節があります。1人で自走できる領域を増やすのが大事だと使い方を再確認しましょう。
Q22 : 生産性を求めれることがあるが、何を提示すべきか？ また、Scrumチームの成熟度を測るよいやり方を知りたい。
A : 書籍では4 Keysを紹介しましたが、結局のところ「ステークホルダーが開発チームのデリバリーに納得しているか」が1番の指標だと考えています。数値上どんなにハイパフォーマンスな成果が出ていても、ステークホルダーがビジネス成果に結びついていないと感じているのであれば何か間違った方向に突き進んでいる可能性が高いです。
スプリント期間中にバックログアイテムを消化し切ったらどうする？PBLの上から取る？ #SDNonline
はじめに
Scrum Developers Night! Online #14に参加し、タイトルの議論をしました。勉強会運営の方でざっくりまとめていただいていますが、アジャイルプラクティスガイドブックでこの辺りは書かなかったなと思ったので、勉強会で話したことをまとめておきます。
安直にバックログアイテムを追加で取るのは反対
「バックログはいつも優先順位で並び替えられているのだから、手が空いたなら上から着手すればいいじゃない」と考えていた時期もありましたが、今は反対派です。 なぜなら「バックログアイテムをたくさん消化できることがよいこと」な雰囲気がチームで醸成されやすくなるからです。 たくさん開発し、たくさん機能をリリースして、それをチームで喜んでいると「自分たちは成果が出せている・プロダクトに貢献している」と感じさせてしまうでしょう。
また「スプリントレビューを通じた学びを踏まえてバックログの優先順位を見直すはず」です。 そこを考慮せず「バックログアイテムが上から順に着手されていれば大丈夫だ」とプロダクトオーナーが考えているのであれば、アジャイルではなくウォーターフォールなやりきり型の開発になっている気がします。
バックログアイテムを追加で取る選択肢そのものは否定しませんが、都度チームで考えて判断してもらうのが良いかと思います。プロダクトの状態・技術面の課題・開発環境の整備・スプリントゴールやプロダクトゴールの達成状況を鑑みて、バックログアイテムを追加で取ることが最適なのであればそれは良いと考えます。また以下のような作業も候補に入れておくと良いでしょう。
- ドキュメントの整備
- CI/CDの整備や改善
- いらない機能やコードを消す
- 今後取り入れたい技術の検証や勉強
- 次のスプリントでやりそうなことの事前調査
勉強会では「チームがやりたいことを別途用意しておき(バックログの下に積んでおく、バックログとは別にリストを用意するなど)、手が空いたら着手する」という話がありましたが、バックログが優先順位で並んでいない・関係者含めて議論できていないということでもあるので、これも良くないかなと考えています。
スプリントプランニングのやり方がおかしい?
予定していたよりも早く開発が進み、手が空くこと自体は確率的に起き得ます。 ただ頻繁に手が余るチームを見ていると「スプリントプランニングを真剣にやっていないのかな?」と思うところはあります。
スプリントプランニングではチームのベロシティを鑑みて、次のスプリントで対応できる分のバックログアイテムをバックログの上から順に取ります。進め方を議論したり、実装方針を確認したり、タスク分解を行うでしょう。皆さんのチームはこのタイミングで分解されたタスクを見直し「スプリント期間内に収まるか」を確認していますか? 収まらないなら計画を見直すか、取ったストーリーをバックログに戻す必要があります。逆に時間が十分に余りそうなら追加でバックログアイテムを取ることを検討してください。ベロシティやストーリーポイントはあくまでスプリントプランニングで取れる分量の目安なので、タスク分解や詳細な進め方がわかった段階で適切な分量だったか見直します。
スプリントプランニングは真剣にやりましょう。
スプリントゴールを達成できる率は50%くらいになるのが適切なのでは
「スプリントでできそうなことを毎回ギリギリまで攻めたなら達成率は50%になるはずだ」とRSGT2020の基調講演でジェームズ・コプリエンさんが話していました。「作業バッファを隠し持ち、毎回達成できるようにするのが良いことなのだ」という考えをチームが持ってないか、それが良いことなのかすり合わせることがこの問題の解決につながるのかもしれません。
クリエーションラインさん主催の「アジャイルプラクティスガイドブック」ABD読書会に参加してきました
こんなイベントでした
2023/7/11にクリエーションラインさん主催の勉強会 CLMeetup の企画として、Active Book Dialog読書会に参加してきました。書籍発売日が7月20日なので参加者全員が読んだことがない状態です。刊行前のゲラを入手して行うというなんともアグレッシブなイベント！ 無茶そうな企画も勢いで通してしまうクリエーションラインさんのこういうところ好きです。
またこのイベントはオフラインのABD会だけでなく、オンライン枠もあり、監修の川口さん・松元さんとクリエーションラインのJ.K.さんが「著者・監修者のぐっときたプラクティス」をラジオ的に紹介してくださいました。この様子はYouTubeで公開されています。
監修のラジオを聞いての感想
動画のネタバレを少しすると、まず川口さんの推しプラクティスが「ログ(およびダッシュボード・運用)」でした。プロダクトはリリースしてからが本番と分かっていても、ついつい後回しにしがちです。書籍ではコラムを11篇寄稿いただきましたが、マイクロソフトでAzure・クラウドサービスの開発に携わる牛尾さん・河野さんが寄稿してくれたログ・ダッシュボードでした。コラムのテーマをこちらから指定したわけではないので、本当に大事だと考えていて伝えたかったことなのだと受け取っています。
また松元さんの推しプラクティスは「コードの共同所有」でした。昔話が語られていましたが、昔はコードを簡単に共有する術がなく、エンジニアごとに担当するソースコード(モジュール)があり、それぞれが独自のバージョン(ブランチ)を持っているのが不思議でない状態でした。Subversionが登場し、GitHub/GitLabが登場し、開発基盤としてのコードの共同所有は今では当たり前になりました。それでも意識として担当コードを作ってしまうことがあるかもしれませんので、書籍を読んだ人がコードの共同所有の理解を深めてくれると嬉しいです。
スクラムフェス大阪(栃木トラック)で「技術プラクティスの整理に1年半向き合ってわかったこと」を話してきました #scrumosaka
はじめに
4年連続でスクラムフェス大阪に採択いただき、今月20日に出版される書籍の執筆舞台裏を話してきました。
スクラムフェス大阪は全国各地の地域コミュニティがトラックオーナーとなり、たくさんのプロポーザルからドラフト制で登壇者を選ぶなかなか異色なカンファレンスです。今回は栃木トラックでの講演でした。
昨年まではオンラインが主体でしたが、栃木トラックではオフラインで集まれる会議室を用意しようというアイデアが早くから出ていました。結果的に宇都宮駅すぐの施設「ライトキューブ宇都宮」の貸し会議室をお借りし、登壇者・運営者・聴講者全員で20名ほどで集まることができました。全員と話せるぐらいの程よい人数で、1日通して皆が同じ話を現地で聞くことができ、昼ごはんも夜ご飯もご一緒できるというのはオフラインならではの楽しさだと思います。
宇都宮は都心からも新幹線でアクセスしやすく、前泊も日帰りも選べる選択肢の広さが良いと思います。
7/11はCL Meetupでお会いしましょう
書籍関連の次のイベントは7/11(火)のCL Meetupです。クリエーションラインさんの勉強会で、書籍の発売前 にABD(≒Active Book Dialog、皆で手分けして書籍の一部をまとめて共有し、短時間で全体を把握するワークショップ)で書籍を読もうというなんとも前のめりな企画です。ABDは秋葉原会場での参加者限定ですが、イベントはハイブリッド対応になっており、オフライン組が本を読んでまとめている間、オンラインのZoom参加者には自分と監修の川口さん・松元さんの3人で「推しプラクティス」を紹介します。さらに申込特典として、翔泳社の直販ECサイトSEshop で利用いただける割引クーポンを出版社からプレゼントいただけるそうなので、書籍を予約した方も、興味を持っている方も、都合が合いましたらぜひご参加ください。
アジャイルプラクティスガイドブックが7月20日に発売されます #agileprag
昨年から執筆を進めていたアジャイルプラクティスガイドブック (#agileprag) が7月20日に出版されます。
どんな人に向けた書籍か
Regional Scrum Gathering Tokyo 2022の登壇をきっかけにお声がけいただき、アジャイル開発に取り組む上で取り入れるとよい技術プラクティスやノウハウを濃縮し、ぎゅっと閉じ込めました。現職のRetty・および前職での経験を踏まえ、116ものプラクティスを紹介しています。
アジャイル開発に取り組む上での技術プラクティスの知見は書籍・ブログ・カンファレンスや講演・口伝・各現場での工夫など多数ありますが、まとまった形で体型立ててキャッチアップすることが難しいと感じていました。この書籍はそんな課題を感じてる方に向けたものです。
豪華コラムを 10編 11編収録
現場寄りの開発知見をより盛り込めるよう、アジャイル開発を実践している方にお願いし、11編のコラムを寄稿いただきました。Amazonの書影は10編になっていますがその後増えて11が正解です。 書籍が無かったら読むことができなかったであろう多彩なコラムが読め、私が一番喜んでおります。
- グラデーションで考える12年間のアジャイル実践 （きょんさん）
- ペアプログラミングの効果と影響 （やっとむ（安井力）さん）
- 開発と運用、分けて考えていませんか？―ダッシュボードのその先へ― （河野通宗さん）
- インフラ構築を自動化しよう （吉羽龍太郎さん）
- Logging as API contract （牛尾剛さん）
- 開発項目をコンパクトに保つには、クリーンなコード（大谷和紀さん）
- テスト駆動開発ではTODOリストがテストよりも先 （大谷和紀さん）
- チームで1つずつ終わらせよう （椎葉光行さん）
- チームに命を吹き込むゴール設定 （天野祐介さん）
- AIフレンドリーなドキュメントを書こう （服部佑樹さん）
- 技術的負債―問題発見までの時間とリスクをビジネス側に説明する（川口恭伸さん）
監修・レビュアー・編集の皆様のおかげで読みやすい書籍にできました
本書は川口 恭伸さん、松元 健さんのお二人に監修いただきました。また昨年末は多くの方にレビュー協力をいただきました。書籍内容はもちろんのこと、プラクティス導入の背景や狙いを段階を追って説明できているか、見解の偏った主張や説得力の薄い箇所がないか、アジャイルコミュニティの過去の経緯や蓄積を押さえられているか、書籍としての読みやすさなど多くの助言をいただき、書籍のクオリティを引き上げていただけました。
小田中育生さん、藤原大さん、大金慧さん、石毛琴恵さん、粕谷大輔さん、守田憲司さん、岩瀬義昌さん、粉川貴至さん、森田和則さん、伊藤潤平さん、山口鉄平さん、半谷充生さん、飯田意己さん、今給黎隆さん、木本悠斗さん、渡辺涼太さん、小迫明弘さん、池田直弥さん、今井貴明さん、皆様本当にありがとうございました。
常松さん渾身の #agileprag 、わたしもレビュワーとして参加してます。
— いきいきいくお (@dora_e_m) 2023年5月21日
よくこんなに集めたな！という錚々たる顔ぶれのレビュワーによるレビューで強度を増した一冊、発刊がとても楽しみ。 https://t.co/OjEC8f0ID1
↑レビューに参加いただいた小田中さんのツイート。私自身もレビューアーからのコメントが書籍の内容よりためになるのでは(!?)と思いながら手を入れていました。
また書籍の各章・項の冒頭には漫画を挿入しました。開発現場で起こりそうなよくある事例と合わせて読み進めてもらうことで、自分の現場で推進・実践していくイメージが湧きやすく仕上がっています。
書籍の目次
Amazonに章立てが出ていますが、出版社のページではもう一段階細かい目次が確認できます。
第1章 アジャイルな開発を支えるプラクティス 1.1 プラクティスの実践 1.2 高速に石橋を叩いて渡る 1.3 広く知られたアジャイル開発手法とプラクティス 1.4 プラクティス理解に役立つ考え方 第2章 「実装」で活用できるプラクティス 2.1 実装方針 2.2 ブランチ戦略 2.3 コミット 2.4 コードレビュー 2.5 協働作業 2.6 テスト 2.7 長期的な開発／運用ができるソースコード 第3章 「CI/CD」で活用できるプラクティス 3.1 継続的インテグレーション 3.2 継続的デリバリー 3.3 継続的テスト 第4章 「運用」で活用できるプラクティス 4.1 デプロイ／リリース 4.2 モニタリング 4.3 ドキュメント 第5章 「認識合わせ」で活用できるプラクティス 5.1 関係者との認識合わせ 5.2 開発内での認識合わせ 5.3 計画の継続的な見直し 第6章 「チーム連携」で活用できるプラクティス 6.1 チームの基本単位 6.2 属人化の解消 6.3 パフォーマンスの測定 6.4 円滑なコミュニケーションのアイデア 6.5 意識を揃えるワークショップ
章・項の中でさまざまなプラクティスを紹介しています。
本書で取り上げる開発のシーン 実装方針の検討、タスクの分解、ブランチ戦略の検討、コミット、コードレビュー、複数人での共同作業、テスト、運用を見据えたソースコードの整備、CI/CD、デプロイ、リリース、モニタリング、関係者間の認識合わせ、チーム内外との連携
