あらすじ
チーム・組織にプラクティスを導入し、根付かせるために！
116の手法を一冊にまとめた“実践”の手引き
チームでのアジャイル開発には、開発技術やツールなどの「技術プラクティス」の活用が重要です。
プラクティスはそれぞれの目的や役割を意識することで効果を発揮します。しかし、目まぐるしく状況が変化する開発では、当初の目的を忘れて、プラクティスに取り組むこと自体が目的化してしまうチームも少なくありません。
本書は、チーム・組織でアジャイル開発に取り組んできた著者が、プラクティスの効果的な選択・活用のしかたについて、自らの実践経験に基づいてまとめたガイドブックです。
架空の開発現場を舞台にしたマンガとともに、チーム開発の様々なシーンで役立てられるプラクティスを、幅広くかつわかりやすく解説しています。開発現場に備えておけば、特定のプラクティスについて知りたい、開発の段階に合わせたプラクティスを探したい、といった場面で、必要な項目を調べる辞書として役立てることができるでしょう。プラクティスの導入や実践について、試行錯誤を重ねている開発者におすすめの一冊です。
●本書で取り上げる開発のシーン
実装方針の検討、タスクの分解、ブランチ戦略の検討、コミット、コードレビュー、複数人での共同作業、テスト、運用を見据えたソースコードの整備、CI/CD、デプロイ、リリース、モニタリング、関係者間の認識合わせ、チーム内外との連携
…など、数々の場面で役立つプラクティスを幅広く収録！
●こんな課題を感じている方におすすめ
・アジャイル開発を取り入れてみたものの、効果を感じられずにいる
・状況に合わせたプラクティスの選択、導入のやり方がわからない
・プラクティスを実践しているが、その取り組みが適切なのか、確証を持てない
●アジャイル実践者たちによるコラムを収録！
・グラデーションで考える12年間のアジャイル実践 （きょん）
・ペアプログラミングの効果と影響 （やっとむ（安井力））
・開発と運用、分けて考えていませんか？―ダッシュボードのその先へ― （河野通宗）
・インフラ構築を自動化しよう （吉羽龍太郎）
・Logging as API contract （牛尾剛）
・開発項目をコンパクトに保つには、クリーンなコード（大谷和紀）
・テスト駆動開発ではTODOリストがテストよりも先 （大谷和紀）
・チームで1つずつ終わらせよう （椎葉光行）
・チームに命を吹き込むゴール設定 （天野祐介）
・AIフレンドリーなドキュメントを書こう （服部佑樹）
・技術的負債―問題発見までの時間とリスクをビジネス側に説明する（川口恭伸）
※本電子書籍は同名出版物を底本として作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。
感情タグBEST3
Posted by ブクログ
実践ベースで書かれているのが何より良かった。具体的なプラクティスがいくつもありすぐに取り入れられるものも多かったです。事あるごとに見返したいと思う本でした！
Posted by ブクログ
本書のユニークな点として、gitの各種コマンドやgitを使ったブランチ戦略についてかなり丁寧に記述されていることが挙げられる。
アジャイル開発に取り組むチームの練度が上がりデプロイ頻度が上昇するとき、このブランチ戦略やテスト周りで問題が起こりやすい。その壁を乗り越えるためのヒントがあるというだけで、現場にとってどれだけありがたいことか。
Posted by ブクログ
先に紹介した「アジャイルの『ライトウィング』と『レフトウィング』」では、ライトウィングを「高速に石橋を叩いて渡る」と表現しています(※1-2)。「動いているシステムを壊さずに、高速に、着実に、製品をインクリメント (※1-3) していく」 ことが、アジャイル開発で達成したい状態です。大きな変更を一度に実現しようとしても、うまくいかないことは読者のみなさんも経験からわかるのではないでしょうか。この制約を踏まえて達成したい状態を実現するには、プロダクトが変化することを受け入れ、その変化の過程で開発の生産性やプロダクトの品質が落ちないようにする必要があります。そのために重要なのが「早く気がつく」 「小さい単位で完成させる」「継続的に見直す」の3つであり、それぞれを具現化するために一つ一つのプラクティスを実践していきます。
関係者を集め、ゴールやスコープを揃える
関係者を揃える/ゴールを揃える/スコープを揃える
多くの人が絡む作業をはじめる際は、最初の認識合わせが重要です。実装が完了し、テストを行い、デモを見せる段階になって初めて、作っていたものが期待と違うものになっていたとわかるのは誰もが避けたいことです。こうした事態を避けるには、関係者を早い段階から巻き込み、プロダクトに対して継続的にフィードバックを得られるようにすることが必要です。
一方で、多くの関係者を集めればよいというわけでもありません。さまざまな立場からパラパラに要望や要求が突きつけられることで、開発は簡単に迷走し、せっかくの時間や人を浪費することになります。筆者はそのような現場をいくつも見てきました。
多くの人が関わるプロジェクトで、円滑な進行をするために、認識合わせは以下の順に進めていくとよいでしょう(図5-1)。
1. 適切な関係者を揃える
開発者と異なる立場や役割の人は、これから開発するプロダクトのゴールや要件について、異なる情報や期待を持っているかもしれません。関係者が全員揃う前の段階で、いろいろな決定を下してしまうと、手戻りが発生するリスクが大きくなります。関係者の範囲は広く多様です。開発中に直接やりとりする役割もあれば、開発が終わってから動き出す役割もあります。開発の成果物をユーザーとして利用する人や、開発に直接関与しなくとも、リソースや情報を提供してくれる人も関係者です。関係書をきちんと洗い出せていなかった結果、後から物言いがついて開発が遅延または失敗するというのは残念ながらよく聞く話です。将来的に関わる人々を含めて、プロダクト開発でやりとりする関係者はしっかり探しておきましょう。図5-2は適切な関係者を挙げた一例です。
その人が関係者にあたるのかを見極めるためには、「今度こんな機能を開発するんですけど、関係や影響するところはありそうですか?」と尋ねてみましょう。話を急に振られたとしても、関係者であれば少し考えた後に、気づいた点を答えてくれるでしょう。短い質問であれば相手の時間をさほど取らないので、声をかけられて迷惑に感じる人は少ないはずです。後から関係者だったことが判明して手戻りが発生してしまうリスクを考えれば、早くに声をかけたほうがよい判断といえるでしょう。
関係者に該当していても、当人が持っている興味には幅があります。単にプロダクトに興味がある人もいれば、自分の仕事に直接関係や影響がある人もいます。また開開に対してどの程度の権限や影響力を持っているのかも異なります。それぞれが持つ開発との関係性を整理するのは大変ですが、「興味の高低」と「権限/影響力の高低」 の2軸で関係者を分類するだけでも、気にかけるべきことや適したコミュニケーション手段が整理できます(図5-3)。
筆者が調べた限りで最も古い出典は 「Strategies for Assessing and Managing Organizational Stakeholders」 5-1 です。その他にも、「ステークホルダー分類」 で調べると細部が異なるバリエーションがいくつか見つかります。
2. ゴールの認識を揃える
関係者への声かけが終わったら、次はゴールの認識を揃えていきます。ここでいうゴールとは、関係者全員がプロダクトを通して実現したいことを指します。集まった関係者は「置かれている状況」「持っている前提知識」「解決したい課題」がそれぞれ異なっている状態です(図5-4)。まずはお互いの理解や考え方を話し、共有することから始めましょう。
気をつけるべきなのは、プロダクトを通して最終的に何を実現したいのかをきちんと確認できているかどうかです。関係者の話を聞くことで、開発でやるべきことは明確になっていきます。しかし、やるべきことをすべて達成しても狙っていたゴールに辿り着かない場合があります。例えばECサイトで「ユーザーにまとめ買いを促したい」と考えた際、その理由は複数考えられます。他にも「一人当たりの売上を上げたい」「送料の負担を抑えたい」「定期購入を促したい」といった目標は異なる立場の人たちから出てくるであろうゴールです。まとめ買いを促すことが達成できても、プロダクトを通して実現したかったことが達成できていなければ意味がありません。ゴール認識を揃えておかなければ、開発する内容が適切かどうかを判断できません。関係書の話がゴール (What) ではなく、解決手段 (How) に向いているとこういった問題が起きやすくなります。また、成功の指標や基準は決まっていても解決手段がゴールに結びついていない、という場合もあります。先に揃えるべきはゴールであって、 解決の手段やスケジュール/スコープではありません。関係者から話を一通り聞き終わった後、その先に何を成し遂げたいのかを聞くようにしましょう。
プロダクトとしての理想のゴールを話そうとすると、抽象的でフワッとしたものになりがちです。例えば「すべてのユーザーが満足してくれるストレスのない購入体験」はまさに理想のECですが、その実現手段はいろいろと考えられます。理想のゴールの手前にある「一人当たりの売上を10%上げたい」「送料の負担を10%抑えたい」「6ヶ月間の定期購入比率を5%上げたい」といった、具体的なゴールを1つ選んだほうが、やるべきことを明確にでき、続くスコープの議論が進めやすくなります。
事業戦略や長期的な方向性についても、わかっている限りで話しておきましょう。事業の方向性はシステムの設計に大きな影響を与えます。将来の計画について話し合う中で、設計に影響する要素や懸念事項がちっとも議論されない場合、適切な設計が行えていない可能性が高いです。ただし、可能性の段階ですべての詳細を詰めることは困難であり、予想が外れることもあります。それでも、事業戦略や方向性についてあらかじめ話し合っておけば、実際にプロジェクトが進行してから問題が起きたとしても、議論の概略を元に対処できます。将来のプロジェクトの成功につながる大切なステップとして取り組みましょう。
3. スコープの認識を揃える
関係者が集まり向かうべきゴールの認識が揃ったら、どの時期に何を達成したいのか、プロダクトに必要な機能やそのためのユーザーストーリーを洗い出し、開発するスコープの認識を揃えます(図5-5)。
まずはやるべきことの洗い出しからです。考えていること、頭に思い浮かんだことはすべて共有しましょう。「これは担当外のことだから言わなくて大丈夫」と考えるのはよくありません。後になって実は必要だったと判明することがないよう、些細な事項でも検討する必要はないか確認しましょう。
やるべき項目を洗い出したら、緊急度や重要度を考慮して優先順位をつけます。同じ順位の項目ができないように、順序を定めます。優先順位がないと「すべて緊急である」「すべて重要である」と判断されてしまったときに、最初のリリースに含めたいユーザーストーリーが大きく膨れてしまい、スコープを小さくする議論ができなくなります。こうなるとスコープが大きいためにリリースまでの期間が長くなり、短くリリースして学びを得ていくというアジャイル開発の目標から遠ざかってしまいます。一方で最初のリリースは単に早ければよいというわけでもなく、プロダクトに求められる当たり前の品質や必須の機能も考慮する必要があります。そのためスコープはよく話し合い、「必ずやる」項目以外に「できればやりたい」「余裕があればやりたい」といった濃淡をつけることが大切です。機能やユーザーストーリーが決まれば、 実現するためにどの程度の手間が必要になりそうか、作業の規模を見積もれるようになります。チームがイテレーションごとにどれくらいの量をこなせそうか、過去の実横から推定します。過去の実績を持っていない新しいチームの場合、一定の時間、実際に作業をしてみて、進捗を計ってみましょう。作業の規模は当初の想定や希望と離れているかもしれません。初回のリリース時期を優先するのであれば、スコープに含まれるユーザーストーリーを見直して減らす必要があります。スコープを見直すときに何を重視するのか意識できるようにしましょう。
またスコープには、すべての機能やユーザーストーリーを含めるべきだと言われがちです。しかし、それはシステムが当たり前に使えるようになった未来を想像しているからこその認識でしょう。例えば最初はデータも少なく、検索や絞り込み機能は必要ないかもしれません。もしくはそもそも機能自体が必要ないこともあります。まず機能が必要となる前提条件を考え、開発側から関係者へ都度確認を取りましょう。スコープは少しでも小さく、明確なものに絞ることが重要です。スコープは適切な大きさに抑えられていても、ゴールの達成に寄与しないものが含まれているかもしれません。適切なスコープ設定は難しく、丁寧に議論を積み重ねる必要があります。どんなステップを経て達成していくか、順序の入れ替えが可能な箇所はどこになりそうか、 いつどんな協力が必要になりそうかなど、お互いが協力できるように納得がいくまで話し合いましょう。認識や考え方の差はすぐに埋まらないため、継続して議論していくことが必要です。
大きめの開発はDesign Docで目線を合わせる
Design Doc
「Design Doc」 とは開発を始める前に、開発の背景/目的/設計/代替案を整理するドキュメント手法です。ドキュメントを元に関係者と共有/議論することで、取り組みを明確化し、手戻りを減らすことを目的としています。Googleで取り組みが始まり、現在では多くの技術企業に取り入れられています。Design Docは設計書や仕様書というよりも議事録に近い位置づけで、何度も議論して修正しながら作り上げていくことを重視しています。この手法は、ソースコードを書き始める前のコードレビューのような役割も担っています。
Design Doc は、開発するものを十分に検討/詳細化できますが、一方で忙しくても読み通せるぐらいの短さにまとめる必要があります。重要な事項を書くことに絞り、詳細なことは書きすぎないことが重要です。すべての開発で事前に用意する必要はありません。筆者は数ヶ月以上かかる開発、いくつか実現案が考えられる開発、技術的/ドメイン的に新規で不慣れな開発に取り組む際、1~2週間程度の時間をかけて用意しています。
Design Doc の項目には規定はありませんが、そもそも「比較的形式ばらないドキュメント」という立ち位置です。項目が多ければよい、分量が書いてあればよいとするのではなく、自分たちの開発で何を明確に残しておかなければならないかを議論し、取捨選択してください。仕様書や設計書などのドキュメントでは記載される機会が少ない一方で、Design Doc では意味があるとされる項目に「目標でないこと」と 「代替案」があります。開発が長期化するとやることがぶれてきてしまいますが、はじめに目標としないことを明示しておくと、スコープが広がることを抑制できます。 また検討した際に考慮した代替案が記載してあると、開発時にどこまで考慮して意思決定したのかを推し量ることができ、意思決定の参考にも設計スキルの教育にも役立 ちます。
[Design Doc に含める項目]
・概要
・背景
・対象範囲
・目標
・目標でないこと
・解決策/技術アーキテクチャ
・システムコンテキスト図
・API
・データストレージ
・代替案
・マイルストーン
・懸念事項
・ログ
・セキュリティ
・オブザーバビリティ
・参考文献
"Four Keys Metrics”でチームのパフォーマンスを測る
Four Keys Metrics
デリバリーのパフォーマンスを測るメトリクスとして「Four Keys Metrics」があります。これはGoogle Cloud の DevOps Research and Assessment チームが研究から導いたもので、「Accelerate State of DevOps Report」という毎年公開される調査レポート 6-5 や 『Lean と DevOps の科学 [Accelerate] テクノロジーの戦略的活用が組織変革を加速する』 66 で紹介されています。Four Keys Metrics の項目は次の4つです。
1. リードタイム: コードコミットから本番環境稼働までに要する時間
2. デプロイの頻度: 本番環境へのリリースの頻度
3.平均修復時間:本番環境で障害が復旧するのに要する時間の平均
4. 変更失敗率:リリースが原因で本番環境に障害が発生する割合
