【技術書まとめ 3 】アジャイルサムライ - 達人開発者への道

本書の紹介

• アジャイルサムライ - 達人開発者への道
• Jonathan Rasmusson (著), 西村 直人 (監訳), 角谷 信太郎 (監訳), 近藤 修平 (翻訳), 角掛 拓未 (翻訳)

TL;DR

⚠️ 社内のアジャイル勉強会でやった内容とかなり重複しています。（その分復習だと思っていただけると 🙏 ）

アジャイルで「あること」は関係ない。
本当に大切なことは、 素晴らしいプロダクトを作ること。プロダクトを通して顧客に価値を届けること。
それを踏まえて読んでいただければと思う。

僕のモチベーション

• テクラボ福岡を強靭なアジャイルチームにしたいという @hane に影響されて
• 知の探求 - サーキュレーションのビジョン・イズムの体現
• 【技術書まとめ】 をシリーズ化していこうという 挑戦 冒険

各章のメモ

第 1 章　ざっくりわかるアジャイル開発

• 「価値ある成果を毎週必ず届ける」ことをお客さん目線で考える上で大切なこと
  • 大きな問題は小さくする
  • 本当に大事なことに集中して、それ以外のことは忘れる
  • ちゃんと動くソフトウェアを届ける
  • フィードバックを求める
  • 必要とあらば進路を変える
  • 成果責任を果たす
• アジャイルな計画づくりがうまくいく理由
  • 最も価値が高いと思うものから小さいスコープで動くソフトウェアに変換し続けていくから
• 「完了の定義」はリリース可能にするためにあらゆる作業を完了していること
• ソフトウェア開発の 3 の真実
  • プロジェクトの開始時点にすべての要求を集めることはできない
  • 集めたところで、要求はどれも必ずといっていいほど変わる
  • やるべきことはいつだって、与えられた時間と資金よりも多い

第 2 章　アジャイルチームのご紹介

• アジャイルチームの特徴
  • きっちりと区別しない役割分担
  • 継続的な開発工程
  • チームで成果責任を果たそうとする態度
• チームをアジャイルにするためのコツ
  • 同じ仕事場で働く（プロジェクトの最初はメンバー全員が集まる）
  • お客さんとの信頼関係を築き、もっと開発に巻き込んでいけるようにしよう
  • チームに任せて信頼し、やり遂げるために必要な権限を与えて自己組織化したチームにしよう
  • 顧客の要望に最初から最後まで答えられる職能横断チーム

第 3 章　みんなをバスに乗せる

• プロジェクトをダメにしないためにやっておくこと
  • チームが状況に合わせて適切な判断を下せるように、ゴールやビジョンの共有、プロジェクトの状況や背景についてチームでよく話し合っておくこと
  • ステークホルダーにプロジェクトを継続するかどうかを決断するための情報を提供すること
• インセプションデッキを作成する
  • 
  • プロジェクトの核心をプロジェクト関係者全員へ手軽に伝えるツール
  • インセプションデッキは出発点でしかないので、妄信せずに改変しよう

4 , 5 章についてはインセプションデッキにどんな課題を作成すべきか、またそれぞれの課題にはどんな効果があるのかと話が展開されていく。

第 4 章　全体像を捉える

• 我々はなぜここにいるのか？
  • 自分自身が理解して腹に落とす
  • 司令官の意図を理解する
• エレベーターピッチを作る
  • プロジェクトの価値が明快になる
  • チームの意識が顧客に向く
  • 核心を捉えることができる
• パッケージデザインを作る
  • プロダクトの効能をブレインストーミングで深く議論できる
• やらないことリストを作る
  • 何がプロジェクトのスコープ内か & 外か視覚化できる
• 「ご近所さん」を探せ
  • 誰がプロジェクトコミュニティに関わっているのかしっかり洗い出しておこう

第 5 章　具現化される

• 技術的な解決案を描く
  • ツールや技術に抱く機体をマネジメントできる
  • 想定しているプロジェクトの境界とスコープを目で見て確認できる
  • リスクを伝えられる
• 夜も眠れなくなるような問題は何だろう？
  • プロジェクトの課題を早い段階で明らかにできる
  • 「いや、その理屈はおかしい」と表明するチャンスである
  • 単純に気持ちがスッキリする
• プロジェクトの期間を見極める
  • IT プロジェクトの守備範囲は 6 ヶ月以内
• 何を諦めるのかをはっきりさせる（何かを諦めることは世の常だ）
  • いつでも荒ぶる四天王に対してバランスを取らなければいけない
  • 
• プロジェクトに何がどれだけ必要なのかスポンサーに提示する
  • メンバーそれぞれの役割と必要な費用の概算を出そう

第 6 章　ユーザーストーリーを集める

• 顧客がソフトウェアで実現したいことをユーザーストーリーに書こう
  • 
• 良く書けているユーザーストーリーは INVEST
  • 「独立している（ Independent ）、交渉の余地がある（ Negotiable ）、価値のある（ Valuable ）、見積もれる（ Estimatable ）、テストできる（ Tetable ）」
• ストーリー収集ワークショップを開催しよう
  • 大きく見通しの良い部屋で、図や絵をたくさん描こう
  • 描いた図を元にユーザーストーリーを描いていこう
  • 出来上がったユーザーストーリーを見ながらブレインストーミング
  • 最後に磨きをかける
    • 社内勉強会でワークをやったのが記憶に新しい。思考の整理にとても良いことが経験上分かる 💡

第 7 章　見積もり：当てずっぽうの奥義

見積もりの目的
「ソフトウェアの見積もりの主目的は、プロジェクトの結果を予言することではない。見積もりを行うのは、プロジェクトのターゲットがコントロールによって達成可能な程度に現実的なものかどうかを判断するためである」
ーーー スティーブ・マコネル 『ソフトウェア見積もり - 人月の暗黙知を解き明かす』

• 不確実性コーン
  • 初期段階の見積もりには大きな誤差がある
    • 
• 見積もり技法
  • 三角測量 ( Triangulation ) ：代表的なストーリーをいくつか基準として選出して残りのストーリーを基準になるストーリーとの相対サイズで見積もる方法
  • プランニングポーカー ：開発メンバーで最初に自分で見積もり、それをメンバー同士で見せ合ってチームとして統一した見積もりを出す方法

第 8 章　アジャイルな計画づくり

• スコープを柔軟にしておく
  • 固定された期日 or 中核をなすフィーチャーセットの提供
• 初回の計画作り
  • マスターストーリーリストを作成する
    • MMF ( Minimal Marketable FeatureSet ) 最も価値の高い最小のものを初回リリースとする
  • プロジェクトの規模見極める
  • 優先順位をつける
  • チームのベロシティを見積もる
  • 期日を仮決めする
• 

第 9 章　イテレーションの運営：実現させる

• 価値ある成果を毎週届ける
  • 分析・開発・テストのサイクルを必要な分を必要な分だけこまめに回して行く
• アジャイルなイテレーション
  • 1 ~ 2 週間を 1 つの単位として顧客に対して優先度の高いものからリリースして行く
• 分析と設計：作業の段取りをする
  • 余計な負担をかけることなく適切に、1 つ前のイテレーションの時に分析をする
  • フローチャート、ペルソナというツールを使って分析することで見える化する
• 開発：作業する
  • イテレーション・ゼロ（プロジェクトの最初のイテレーション） で開発の段取りを済ませておく。
    • ソースコードの ver 管理、ビルドの自動化、開発環境やテスト環境の構築、etc..。
• テスト：作業の結果を確認する
  • 「いつでも受入テスト可能」 が望ましい状態
• カンバン
  • ストーリーボードとの違い
    • 仕掛かり（WIP : Work In Progress）にできる上限を設けていること
  • カンバンのメリット
    • イテレーションのプレッシャーから解放される
    • 1 回のイテレーションに収まらない仕事にも取り組める
    • 期待をマネジメントしやすい

第 10 章　アジャイルな意思疎通の作戦

• イテレーションでやるべき 4 つのこと
  • ストーリー計画ミーティング
    • What : これから始まるイテレーションで取り組むストーリーの準備が整っていることを全員で確かめる会
  • ショーケース
    • What : チームが成し遂げた成果をお披露目する会
  • イテレーション計画ミーティング
    • What : 次回のイテレーションでチーム全体がコミットメントする作業量を見極める会
  • ミニ振り返り
    • What : 短時間でいいので集中して「もっとうまくやるためにどうすればいいか」話し合う会
    • 
• デイリースタンドアップ
  • 毎日の重要な情報をチーム内で素早く共有することを目的とした会
  • 5 ~ 10 分で立ったままで行う

※ 若干のやり方は違えど、上記のミーティング手法をテクラボ福岡で採用している ✌️

第 11 章　現場の状況を目に見えるようにする

• 現場の状況を目に見えるようにするために張り物を作る
  • ストーリーボード、リリースボード、ベロシティとバーンダウンチャート、インセプションデッキ
• チームの意思を明確にする
  • 「チームの約束（ Working Agreements ）」
  • 「チームが大切にすること（ Shared Values ）」
    • テクラボ全員で議論して定めている https://circu-tech-lab.kibe.la/notes/117 😄
• プロジェクトで使う言葉を共有する
  • 業務では用語の使い方は決まっているのに、開発者が違う解釈をしている
  • 画面に出ている単語と、データベースのカラム名が違うことで変更しにくくなる
  • バグが増えて保守性が落ちる原因になる
• バグを監視する

第 12 章　ユニットテスト：動くことがわかる

• ユニットテストを書いて、自動化しよう
• ユニットテストをたくさん書くメリット
  • 素早いフィードバックを得られる
  • 極めて低コストにリグレッションテストを実行できる
  • デバッグ時間を大幅に削減できる
  • 自信を持ってデプロイできる
• ref. レガシーコード改善ガイド (Object Oriented SELECTION)

第 13 章　リファクタリング：技術的負債の返済

• 技術的負債

  • 行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である。

• リファクタリング

  • 外部からみたソフトウェア全体の振る舞いを変えることなく、少しずつ継続的に設計を改善して行く手順の総称

• 積極果敢に継続してリファクタリングを行うことでソフトウェアの品質を保つ
  • 変数やメソッドの名前変更
  • 変数のインライン化
  • メソッドの抽出
• ref. リファクタリング―プログラムの体質改善テクニック
• 

第 14 章　テスト駆動開発

• テストを先に書く テスト駆動開発（ TDD : Test Driven Development ）
• TDD を順調に進めるためのルール
  1. 失敗するテストを 1 つ書くまでは、新しいコードを一切書かない
  2. 「危なっかしい所」をすべてテストする
• テストファースト
  • 日々のコーディングの複雑さに立ち向かうことができる
  • コードの保守や修正を容易にすることに繋がり、変更に強くなる
• ref. テスト駆動開発入門
• 

第 15 章　継続的インテグレーション：リリースに備える

• 継続的インテグレーションとは？
  • 開発者がソフトウェアに加えた変更を取り込んで、ソフトウェア全体として統合する作業を途切れることなく続けていく取り組み
• どうやって実現するか
  • ビルド、デプロイを自動化する
  • 作業単位を小さくする

まとめ

エンジニアを 1 年ほどやってきてプロジェクトの進め方で結構悩んできた。そこで、アジャイルの勉強会に参加する中でもっと理解しておきたいと思い、本書を読んでみた。

アジャイル開発とは旅そのものであって、目的地じゃないんだ。

と、最後に書いてあるように、アジャイルは単なる手法であり目的ではないということを念頭に置いた上で次の 2 つを意識した開発していきたいと思う。

• 毎週、価値ある成果を顧客に届けられているか？
• たゆまぬ改善のために努力を惜しまず続けているか？

おまけ

最後まで読んでいただきありがとうございます。
意見や指摘等あればコメントいただけると大変嬉しいです。

このシリーズを続けていけたらと思ってます。いいね 👍 やコメントいただけると大変励みになりますのでお願いします。