はじめに
いちばんやさしいアジャイル開発の教本を読んだのでアウトプットする。
今年の4月から組織体制が変わり、プロダクト開発チームではウォーターフォール風味な開発からアジャイル開発に移行しました。
アジャイル開発に関してふわっとした知識しかなかったので読みました。
「なぜアジャイルなのか？」「どうやってやるのか？」など実体験をもとに書かれてあったので読みやすい本でした。
アジャイル開発の世界
- アジャイル開発は、顧客が必要なものにフォーカスして素早くプロダクトを開発する手法
- 不確実性のあるソフトウェア開発においてアジャイル開発の成功率が高い
- 変化の流れが早い現在のビジネス環境と非常に相性が良い⭕️
モノ消費からコト消費へのシフト
- IT技術の進歩によりモノを所有しなくとも必要なサービスを利用できるような環境が実現
- モノが充足し、体験が求められる時代
サブスクリプションの到来
- サブスクリプションビジネスではユーザー体験の向上や機能追加といった継続的なサービス向上が求められる
- より利便性の高いサービスが現れた際に乗り換えられてしまうリスクがある
- ユーザーにとって必要なソフトウェアであり続けるために、リリース後に開発を継続しサービスを向上させていくことが必要
- 同時に「今、市場で求められているソフトウェア」をタイムリーに市場に届けることも求められている
- タイムリーな開発を実現するためには企画と開発が位置が一体となりユーザーにとって価値のあるものを創造していくことが必要
ウォーターフォールの課題
- 動くソフトウェアなしには知り得ない本当の要件を、動くものがない段階で洗い出すことを前提としたウォーターフォールには本当に必要なものから乖離したソフトウェアを作り込んでしまうリスクがある
- 要検定義はあくまで仮説
- 後工程が圧縮されていきやすいという問題
アジャイル開発とは
- 短い期間でリリースし、フィードバックを受け、改善するというサイクルを基本としている
- 本当にやるべきことに集中し、不要なものは作らないという取捨選択を迫られる
- 対話の重視
- 動くソフトウェアの重視
- 「失敗」を「学び」としてポジティブに捉える
- 予定していた期間内に開発が完了しなかった、完了したけど期待した効果が得られなかった、など「この方法ではうまくいかないと判明した」とポジティブに捉える
- アジャイル開発ではスプリントごとに動くソフトウェアが作られ、次のスプリントではそのソフトウェアから得られた気づきを元に要件レベルから見直しが行われる
- ワイワイガヤガヤと要望やリスクを表明しながら、アジャイル方法論を活用して短時間で意思決定できるチームを目指す
アジャイル開発の心構え
- 要求の変更は開発の後期であっても歓迎するスタンス
- ソフトウェア開発は不確実性な状況からスタートする
- 開発を始めて初めてわかることがある
- 「なるはや」タスクであれば、今取り組まないとどのような問題が発生するのか依頼者に確認
- 必要なスキルが不足している時には開発を進める中で成長戦略を織り込み、後発的にスキルを身につけていくことになる
アジャイル開発とカイゼン
- 「カイゼン」（生産現場における作業の見直し）を繰り返す
- カイゼンは「今あるものをより良いものにしていく」という精神に基づいており、より前向きで積極的なもの
- 繰り返し作業が3回以上であれば、継続的インテグレーションの導入で自動化を検討する
アジャイル開発とコード
- 自分以外のエンジニアにとって読みやすいコードになっていること
- アジャイルなチームではコードは個人の所有物ではなくチームのもの
- プロセスにレビューとテストが組み込まれているため、チームにとって可読性が保たれ高品質なコードが出来上がる
- スピードが質を高めるように、質もまたスピードを高める
- 高品質で不具合の少ないソフトウェアはリリース時の手戻りが少なく、結果として高速なリリースが可能となる
スクラム開発
- スクラム開発はアジャイル開発の1つの流派
- スクラム開発では、一定の期間（スプリント）を開発サイクルとしている
- スプリントの長さは1〜2週間
- 1回のスプリントでアウトプットができること
不確実のコーン
- ソフトウェアは不確かなもの
- 開発機関の見積に幅を持たせる
- 頻繁に情報共有を行うなどの仕組みを導入する必要がある
見積もり
- プロダクトがいつ完成するかの着地の予測
- プロダクト開発のコストの計算
計画作り
- 大きな計画作り（リリースプランニング）
- 小さな計画作り（スプリントプランニング）
- その日の計画作り（デイリースクラム）
朝会
- 「朝会」はメンバー全員に対して共有が必要な情報を共有するためのプラクティス
- タスクについての詳細すぎる説明は省く。詳細が必要な場合は関係者と「二次会」に行く
- 同じ時間、同じ場所で毎日行う
- チーム間で前向きなコミュニケーションが取れるようなルールを定めても良い
フィードバック
- フィードバックは利用したユーザーから得られるものに限らない。開発したチーム自身が気がついた学びもフィードバックとして次の計画に織り込まれていく
- ユーザーの声を尊重しながら、そのまま言われた通りに開発するのではなく、その声の裏側にある本当の要望を見極める
振り返り
- 振り返りは1〜2週間の短い間隔で実施する
- 小さな気づきや課題から学習するためには短い期間で振り返る事が望ましい
- 通常はスプリントの最後に行い、作成物のレビューも踏まえて振り返る
コミュニケーション
- 自分が伝えたつもりになったいたことが相手に全然伝わっていない認識の齟齬は日常的に発生する
- 信頼関係が構築されたチームでは情報共有が活発に行われる
- 対話が相互理解を呼び、相互理解が強いチームを作っていく
HRTの原則
- チームワークを発揮するためのは不可欠な原則
- 謙虚さ（他人から学ぶ姿勢）
- 尊敬（相手の意見や行動を尊重する）
- 信頼（仕事を任せる）
ペアプログラミング
- 複雑な業務やはじめてのタスクの場合、1人では何かと不安だったり成果を出せない焦りがあるもの。不安を解消し、生産性と品質を向上させることができる
- 常にレビューし合っている状態を持たらすので、リリースするまでにかかる時間は短くなる
- 基本的に同じレベルのエンジニア同士で行うが、教育目的でベテランと新人が組むこともある
- 書いたコードを知っている人が最低でも2人以上になる、お互いの得意分野を活かしてチームワークを発揮できるといった効果がある
- 実際にやってみると、待ち時間がゼロになる、師匠的ポジションのエンジニアしか知らなかった暗黙知が共有させるなどの効果が現れた。
モブプログラミング
- ペアプログラミングの複数バージョン
- 能力を集結させることによって生産性を向上させるプラクティス
- チーム全員で1つの業務をしているようなもの
- 業務の背景や意図を全員と雑談しながら作業を進められるので、属人化の解消や新人の育成が期待できる
- 全ての業務をモブプロする必要はない。適用分野、参加メンバー、適用範囲、実施時間など、負担にならない範囲で小さく始めていく
- モブプロで不協和音が生まれるのであれば、チームとしては成熟していない証。チームビルディングや心理的安全性を向上させる施策を実施する絶好の機会
Tips
- 一度始めてしまったことを止めるためには大きな労力が必要となる
- アジャイル開発が定着するまでを1年ほどかかる場合もある。根気よく続けていくことが大切
- 完成した機能の6割は使われない
- ユーザーが必要としている機能は、ユーザーが利用してみるまでわからない