はじめに
アジャイルサムライという本がすごく良いと聞きまして、読み始めました！
意識が足りていなかったなと思うことや、意識を改なければいけないなと思うことがたくさん書いてあったので、まずは１章だけまとめてみました！
お客さんにとって価値のある成果をとどけるためには本当に大事なことって何だっけ？
→ 動くソフトウェアを定期的に届けることである
上記を実現するために必要なことってなんでしょうか？というのがざっくりわかります。
価値のある成果を“毎週”届ける
お客さんの立場に立つと…
信頼に足ると判断するチームはどっちでしょうか？
- 実施計画書や大量の製品文書、作業報告書を納品してくれるチーム
- 重要な機能を実装してテスト済みのソフトウェアとして毎週必ず届けてくれるチーム
“価値のある成果を毎週届けるという観点“でお客さんの視点で考えてみると、開発チームとして何を大事にしなければならないか見えてくる。 そのために必要6つのことを下記にまとめました。
“毎週届ける”ために必要な６つのこと
-
大きな問題を小さくする
価値を届けるには1週間では短い！そんな短い時間で何もかも終わらせるのは無理！
→だからこそ、成果を上げるには小さくシンプルにして扱いやすくしなければならない。- 大きすぎる要件は１週間では到底終わらない。
- 機能を「ストーリー」という小さな単位に分割し、必ず１週間で完了できるサイズにする。
- こうすることで「見積もりミス → 終わらない → 品質低下」という悪循環を断ち切れる。
-
本当に大事なことに集中し、それ以外は捨てる
色んな成果物を納品してきたけどお客さんの視点で考えると実は価値のないものばかりの可能性もある。
ドキュメントも実施計画書も必要だが、これはあくまで動くソフトウェアを保管するもの。- ドキュメントや計画書は必要だが、その目的は「動くソフトウェアを保管・共有すること」。
- 価値につながらない作業は思い切って削ぎ落とし、チームのエネルギーをコアに注ぐ。
-
ちゃんと動くソフトウェアを届ける
届けたものは動かないといけない。テストはもっとこまめにたくさんテストする。
日々のテストだけは捨てたらいけない、おろそかにしたらだめ。テストをする習慣を守る責任は開発者自身にある。- 納品物が動かなければ価値ゼロ。
- 単体テストから結合テスト、E2Eテストまで、テストを習慣化し、品質を担保する責任は開発者にある。
-
フィードバックをもとめる
お客さんに定期的に尋ねないで、どうやって狙い通りに進んでいることを確かめるのでしょうか?
フィードバックは運転に例えると行く手を照らすヘッドライト 夜中や霧の中を運転するなら
道に迷わないためには絶対欠かせない。- 顧客の声を定期的に取り込み、進捗と狙いがずれていないか確認する。
-
必要とあらば進路を変える
先週重要だったことが、今週はどうでもよくなったりする。
計画にただ従うのではなく、大きな変化に耐えられるように、計画を乱すような現実に遭遇したら
計画を変えるる。現実を変えない。
- ビジネスや市場は常に変化する。
- 先週重要だった要件が今週は不要になることもあるため、計画に固執せず迅速に軌道修正する。
6 . 成果責任を果たす
価値のある成果を毎週とどけることをお客さんにコミットメントして、資金の使い道を示すことができたら、成果責任を果たしたと言ってよい。[成果責任を果たす]は一言で言えるが実現するにはやらなければいけないことがたくさんある。
- 「毎週動くソフトウェアを届ける」というコミットメントを守り、顧客の投資に対する説明責任を全うする。
- 仕事の質・スケジュール・期待値管理・資金管理、すべてに責任を持つ覚悟が必要。
アジャイルな計画づくりがうまくいく理由
アジャイルなプロジェクトの計画づくりは、予定が立て込んでいる週末とかわらない。
TODOリストやタスクを “マスターストーリーリスト“とか “ユーザーストーリー“という。
-
マスターストーリーリスト：顧客が実現したい機能を並べたプロジェクトのTODOリスト(顧客がソフトウェアで実現したいと思うfeature)
-
イテレーション（反復期間）
アジャイルプロジェクトで具体的に成果を上げるためのエンジン- 長さ：1～2週間
- 目的：価値の高いストーリーから順に「動くソフトウェア」に仕上げ、必ずリリース
イテレーションの長さは１〜２週間にしておく。この期間をつかって、顧客が価値の高いと
思うものから順番に動くソフトウェアに変換していく。
-
ベロシティ
- 1イテレーションで完了できるストーリー量を実測し、自チームのキャパシティを把握
- 継続的に振り返り、無理のない約束をする
- 万一オーバーしそうなら、あらかじめスコープを調整できる余地を残しておく
これを実測することで自分たちの仕事量を計測できる。継続すれば、工数の予測など自分たちの仕事量を判断しやすくなる。自分たちの限界を超えた成果を上げることを顧客にコミットメントしてしまうことも避けられる。もし限界以上になったら、成果とみなすスコープを変えられるように柔軟にしておく。計画を変える。現実にそぐわなくなったら計画を変える。
顧客にとって価値の高い機能を小さな単位で素早く届け、そこで得たフィードバックをもとに計画を柔軟に修正できるというのが、上手く行く理由となる
アジャイルの３原則
-
継続的な価値提供
- 動くソフトウェアを短いサイクルでリリースし、顧客に早く価値を届ける。
- 毎週／毎イテレーションの成果物が、顧客の投資に対する最大の証明となる。
-
変化への対応を歓迎する
- 要件や環境の変化を「問題」ではなく「より良い成果を生むチャンス」として捉える。
- 計画に縛られず、変化に合わせて優先順位やスコープを柔軟に再設定する。
-
協調とコミュニケーション
- 開発チームと顧客（ビジネス担当者）が継続的に対話し、共通の目標に向かって協力する。
- 顧客の現場に近い場所で開発を進め、曖昧さを減らして早期にフィードバックを得る。
これらを守ることで
- 顧客にとっての価値を最大化
- チームの幸福度と生産性を両立
- プロジェクト全体の成功確率を飛躍的に高める
という、アジャイルが本来目指す状態を実現できる。
１章を読んで、再度意識を改め直して、顧客へ価値を届けられるよう開発していかなければ！と思いました！
参考文献
Rasmusson, Jonathan. 2011. *アジャイルサムライ――達人開発者への道*. 西村直人, 角谷信太郎, 近藤修平, 角掛拓未 訳. 東京：オーム社.
株式会社シンシアでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。
※ シンシアにおける働き方の様子はこちら
https://www.wantedly.com/companies/xincere-inc/stories
弊社には年間100人程度の実務未経験の方に応募いただき、技術面接を実施しております。
この記事が少しでも学びになったという方は、ぜひ wantedly のストーリーもご覧いただけるととても嬉しいです！