頑張らないように頑張る。

努力と怠惰の狭間

「アジャイルサムライ―達人開発者への道―」を読んだのでまとめた。

いつ買ったか定かではない積読状態だった「アジャイルサムライ」にようやく手を付けたので、内容をまとめておく。

なお、本書はオーム社より出版されている。

shop.ohmsha.co.jp



⚔はじめに(まとめ方について)

本書は、以下の章立てとなっている。


本記事では、章立てごとにまとめる事はせず、一般的な業務の流れに沿ってまとめていく。
また、部分部分に個人的見解も記載しているため、ご容赦いただきたい。



⚔はじめに(重要な宣言・原則について)

本書の最終章である『第VI部 付録』に、以下2つが記載されている。

上記2つは、以下のサイトが元となっている。

agilemanifesto.org


これらはアジャイル開発において重要な事項なので、本記事では最初に記載しておく。

アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
 プロセスやツールよりも個人と対話を、
 包括的なドキュメントよりも動くソフトウェアを、
 契約交渉よりも顧客との協調を、
 計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

アジャイルソフトウェア開発の12の原則

  1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
  2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
  3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
  4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
  5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
  6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
  7. 動くソフトウェアこそが進捗の最も重要な尺度です。
  8. アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
  9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
  10. シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
  11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
  12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。


⚔前提

念頭に置くべき「3つの真実」と「6つの大切な事」

アジャイルに限らず、ソフトウェア開発には3つの真実が存在する。

  • プロジェクトの開始時点にすべての要求を集める事はできない
  • 集めたところで、要求はどれも必ずといっていいほど変わる
  • やるべき事はいつだって、与えられた時間と資金よりも多い


アジャイルに限らず、ソフトウェア開発で大事なのは「定期的に届ける事」であり、そのためには6つの大切な事を意識する必要がある。

  • 大きな問題は小さくする
  • 本当に大事なことに集中して、それ以外の事は忘れる
  • ちゃんと動くソフトウェアを届ける
  • フィードバックを求める
  • 必要とあらば進路を変える
  • 成果責任を果たす

アジャイルに向いている人間

アジャイルプロジェクトは、チームで成果責任を果たすため、個人個人の明確な役割分担を要していない。
つまり、「誰が何の役割なのか」という事はどうでもよく、「その役割によって果たされる仕事」の方が重要。
つまり、どんな帽子(役割)でも柔軟に被れる人は、アジャイルに向いている。


役割とは、以下の通り。(これらの帽子を柔軟に被れる人が向いてる)

  • 顧客
  • 開発チーム
  • アナリスト
  • プログラマ
  • テスター
  • プロジェクトマネージャ
  • UXデザイナ など


なお、これを満たすには個人個人の「自己組織化」が必要であり、自己組織化には「成果責任」「権限委譲」が必要となる。



アジャイルプロジェクト開始前にすべき事

①ユーザーストーリーの収集

顧客が欲しいものを引き出すには、文書に頼り過ぎるとよくない。
(言葉というのは誤解が生じやすいし、顧客の欲しいモノより仕様に合わせて作る事になったりする)


情報を伝える最も効果的・効率的な方法は面と向かって話す事なので、ワークショップを開いてユーザストーリーを収集する。

Step1. 「ストーリ収集ワークショップ」を開催

チームメンバー総動員で、ペルソナやフローチャートなどを用いつつ、フィーチャを幅広く集める
(※収集が目的なので、詳細な部分に立ち入り過ぎないように注意。)

Step2. ユーザストーリーを「INVEST」に従って作成
  • I: Independent(独立している)
  • N: Negotiable(交渉可能である)
  • V: Valuable(価値がある)
  • E: Estimatable(見積もり可能である)
  • S: Small(小さい)
  • T: Testable(テスト可能である)
Step3. モレなくダブりなくストーリーを収集できればOK(MECE


インセプションデッキ

ストーリーの収集はできたが、ソフトウェア開発を進めていると往々にして様々な問題にぶつかる。
そのため、起こりうる問題を事前に明確化したり、プロジェクト開始後の認識齟齬をなくす必要がある。
そのため、インセプションデッキを用いて、10個の手ごわい課題をクリアにしておく。

10個のうち、全体を捉える5個

何故作らねばならないのかを明確にしないまま着手すべきではないし、そんなソフトウェアは作られるべきではない。
そのため、要件の全体感を捉えるために、インセプションデッキのうち以下5つの課題をクリアにする。

  • 我々は何故ここにいるのか
  • エレベーターピッチを作る
  • パッケージデザインをする
  • やらないことリストを作る
  • 「ご近所さん」を探せ

10個のうち、具現化させる5個

プロジェクトには荒ぶる四天王が付きまとう。(時間、予算、品質、スコープ)
そのため、起こりうる問題やリスク・期間やスコープなどを明確にした上で顧客に具体を提示するために、インセプションデッキのうち以下5つの課題をクリアにする。

  • 技術的な解決案を描く
  • リスクを検討する
  • プロジェクトの期間を見極める
  • 諦めるべきものをはっきりさせる
  • プロジェクトに何がどれだけ必要なのかをスポンサーに提示する


③見積もり

ストーリーも収集できたし、課題もクリアになったので、あとは見積りをするだけ。
しかし、前もって正確に見積もる事は不可能。(結局は荒ぶる四天王が付きまとってくるため)
なので、単位は「日数」ではなく「ポイント」としておく。
そして、ストーリー同士を相対的に比較しながら、チームのベロシティを計測し、見積もる。


アジャイルな見積には、以下の手法を用いるとよい。

  • 三角測量
  • プランニングポーカー


※ストーリー同士の相対比較でしかないし、プロジェクト開始前でチームのベロシティも定かではないので、当てずっぽうである事を肝に銘じておく。
※あくまでも予定は予定なので、スコープや予算は柔軟にしておいて、現実に沿って計画は変えればいい。
 プロジェクトを進めていくうちに、
  思ったより早くできそうなら、スコープを増やしたり、期日を早めたりすればいいし、
  思ったより遅くなりそうあら、スコープを減らしたり、期日を遅めたりすればいい。



アジャイルプロジェクトを回そう

⓪そもそも「アジャイルを回す」とは(概念編)

よく色んなところで「アジャイルを回す」というが、そもそも「回す」とは何なのか。


ざっくり言うと、アジャイルは以下のような感じで「回す」。

  1. イテレーションを定める(1,2週間~1,2ヶ月)
  2. イテレーション内で実施するユーザストーリーを定める
  3. 定めたユーザストーリーを分析・開発・試験して機能化する
  4. 機能化したユーザストーリーを顧客に見てもらい、フィードバックを貰う
  5. Step1~Step4を繰り返す


すなわち、「特定のユーザストーリーを、特定の期間内に機能化し、顧客に見せる」というサイクルを回す事を、「アジャイルを回す」と言う。


①計画を立てる(分解編)

アジャイルを回すために、1つのプロジェクトを複数のイテレーションに分解する必要がある。
そして、各イテレーション内には複数のユーザストーリーが存在する。
なので、イテレーションの分解については、以下のように行う。

  • ユーザストーリーのうち、優先度・重要度の高いモノを先に実施する
    • 優先度・重要度は顧客が定める
    • 核となる機能を先に実施した方が、プロジェクトの後半でスコープ調整などしやすくなる
  • 見積りで用いたユーザーストーリーの「ポイント」の総数が、各イテレーションで同等になるようにする
    • 例えば、各イテレーション内で「30pt」を目指すように、「5+10+15」「5+5+5+5+10」のように組んでいく


イテレーションを回す前に(準備編)

イテレーションが組めたので、早速開発に着手しよう!
・・・とはならない。


開発環境や開発規約の整備を、イテレーションを回す前に実施する必要がある。
これを「イテレーションゼロ」と呼ぶ。


イテレーションゼロでは、以下のような事を行う。

  • ツールのセットアップ
  • リポジトリの用意
  • 開発環境・本番環境準備
  • テスト・ビルドの自動化環境準備 など


イテレーションを回す前に(会議編)

今度こそイテレーションが回せるようになったので回そう!
・・・まだならない。


イテレーションを健康的に回すために、4つの会議体を設けておく。
(期待をマネジメントし、フィードバックを得る機会を設けるため)


4つの他に「デイリースタンドアップ」を設けてもよいが、少人数のプロジェクトで常に近くにいるのであれば、別に必須ではない。


イテレーションを回す(実行編)

会議体も設けたし、いよいよイテレーションを回そう!


イテレーション内では、③の会議も含めて、以下を実施する。

  1. ストーリー計画ミーティング
  2. 開発&試験
  3. ビルド
    • できるだけ小さい単位でソフトウェアの変更を取込み、統合する
    • できるだけ自動化する(ビルドエージェントを使ってもいいし、フレームワークを使ってもいいし、独自バッチを仕込んでもいい)
  4. ショーケース
    • 顧客に成果を見てもらい、フィードバックを受ける
    • 完成してなくてもありのままの姿を見せる。未完成品は次回のイテレーションに持ち越す。
  5. ミニふりかえり
    • 「うまくやれたこと」と「どうやったらうまくできるか」を話す(犯人探しなどは無意味無価値なのでしない)
  6. イテレーション計画ミーティング



アジャイルプロジェクトを可視化しよう

①状況を可視化

プロジェクトの進捗状況や変更状況を可視化するために、以下のような「ビジュアルワークスペース」を設ける

インセプションデッキ

業務目的や問題意識の可視化

リリースボード

未完了のストーリーと完了したストーリーの可視化
(ストーリーの変更や追加も分かるようにしておく)

ストーリーボード

現在のイテレーションで取組んでいるフィーチャの可視化
(変更や追加したストーリーの状況も分かるようにしておく)

ベロシティ

チームがフィーチャを届けている速度の可視化
(変更や追加があった場合の速度差も分かるようにしておく)

バーンダウンチャート/バーンアップチャート

いつ頃完了できそうかの見込みの可視化、および、変更の可視化
(ストーリーの変更や追加も分かるようにしておく)

パーキングロット

会議体などで浮上した話題などの可視化
(スコープ外のストーリーがいつ追加・変更されたか分かるようにしておく)


②意思疎通を可視化

チームの約束

「私たちはチームとしてこうやって作業したい」という宣言を文字にしたもの。

    • 午前9時から午後4時までがコアタイム
    • デイリースタンドアップは午前10時開始
    • 毎週火曜日午前11時からデモ開始
    • 顧客は午後1時から午後3時までは時間を割いてくれる
チームが大事にすること

過去の失敗経験から来る教訓的なものや感覚的なもの。

    • 割れ窓を放置しない
    • 異論は認める
    • フィードバックを求める
    • 我を張らない
用語(業界用語など)

顧客の業界用語を共通言語都市、関数名だとか変数名だとか各種文書だとかを書かないと、保守性に欠けるシステムになるため、順次吸い上げてまとめておく。



⚔最後に

僕は実際アジャイルでプロジェクトを回した事がないけど、非常に理解が深まった。

ウォーターフォールのプロジェクトにおいても似たような概念を持ち込む事はできそうなので、今後システム開発のプロジェクトに参画する際には、師範に倣ってプロジェクトを回していきたいと思う。

https://shop19-makeshop.akamaized.net/shopimages/ohmsha/0000000019012.gif