アジャイル開発の初心者が読む記事

アジャイル開発とは

フィードバックから改善を繰り返し行い、ユーザーが本当に求めるソフトウェアにスピード感をもって進化させ続ける開発手法のこと。

なぜアジャイル開発なのか？

2000年代以前の売り切り型のビジネスモデルの目的はリリースであったため、ウォーターフォール開発が有効と考えられていたが、昨今では、サブスクリプションモデルが一般的となり、リリース後も開発を継続し、サービス価値を向上させ続けることができるアジャイル開発が有効とされている。
また、開発着手時に全ての要件が決まっていなくても、開発に着手することができ、途中成果物を確認しながら本当に必要な機能を持ったソフトウェアを少しずつ作り上げることができる。
開発当初に予測していなかった市場の変化や要求の変化に柔軟に対応することができるため、アジャイル開発が昨今広く採用されている。

アジャイル開発のメリット

• 開発着手時に全ての要件が決まっていなくても、開発に着手することができる。
• 不要な機能を省いた本当に必要なソフトウェアを作ることができる。
  ソフトウェアの開発では欲しい機能と必要な機能は異なる場合が多く、一完成したソフトウェアの機能のうち、6割は使用されないと言われている。
• 開発が一本化されることにより、会社間の引継ぎや書類の承認フロー、情報伝達時の伝言ゲームを省略することができる。
• 机上の空論ではなく、実際に動くものを作ることで、より正確に機能の過不足や品質を確認することができる。
  これにより、作り直しになるリスクを回避できる。
• 定期的なリリースを行うため、フィードバックや、開発中の気づきを製品に反映できる。

アジャイル開発の特徴

• 事前に全てを正確に予測し、計画することはできない、かつ変化することを前提としているため、不確実性が高く、様々な要因で変更が発生するソフトウェア開発に向いている。
• 仕様の合意形成は動くソフトウェアで行い、目的が曖昧な仕様書を作成しない。
  ただし、ソフトウェアの動作だけでは仕様が理解できない・網羅的に確認することが難しいものは仕様書を作成する。
• 仕様書は効率化のために、ソフトウェアが完成に近づき、仕様がまとまったタイミングで書いてもよい。

アジャイル開発のサイクル

• 開発
  常にタスクに優先度を付け、優先度の高いものからの開発に着手する。
• フィードバック
  ユーザーや開発者の気づきをヒアリングする。
• タスク・計画の見直し
  フィードバックを踏まえて次に開発するタスクを検討する。
  →PDCAサイクルを回し、継続的により良い状態を目指す。

アジャイル開発の原則

• 開発の後期であっても要求の変更は許容できる・許容する。
• 短い時間間隔でリリースする。
• ユーザーや発注者・顧客と開発者が協力して開発を行う。
• 無駄な機能がない、シンプルなソフトウェアを作る。
• 自主性を持った自己組織化されたチームを目指して開発を進める。
• 定期的に振り返りを行い、タスクやリソースを最適化する。
• 失敗も学びとしてポジティブに受け入れ、改善に役立てる。

アジャイル開発の種類

• スクラム
• エクストリーム・プログラミング（XP）
• ユーザー機能駆動開発（FDD）
• カンバン

アジャイル開発のテクニック

タスク管理

• 本当に必要な機能の機能の取捨選択を行う。
  無駄な機能は開発・テスト・保守・運用コストがかかるため削除する。
  リリース後に機能削減するハードルは高いので、不要な機能はリリース前に削減する。
  ※YAGNI：実際に必要となる機能以外は実装しないという原則。
  ※KISS:シンプルな設計が成功へとつながるという原則。
• バリューストリームマッピングを用いて無駄なプロセスを洗い出す。
  ※開発からリリースまでの工程を可視化し、その工程ごとに問題点を洗い出す手法。

ソフトウェア設計

• 変更を前提とした開発手法のため、ソフトウェアは変更を前提とした作りにしておく。

プロジェクト運用

• 雑談を行うことで、思いがけないアイデアや気づきを得ることができるので、メンバーがリラックスできる場を提供する。
• MVP(Minimum Viable Product)つまり、価値検証することのできる最小限の機能を持ったソフトウェアを開発することで、認識のズレの有無の確認及び、起動修正を早期に行う。
• タスク管理による開発を行うことで、本来の開発の目的を見失いやすい性質があるため、ユーザー行動フロー（ユーザーの使用シナリオ）を作ることで、本来の目的を見失わないようにできる。

テスト

• スプリント毎にテストを実施するため、テストは自動化可能できるようにする。

リーダーの役割

• メンバー牽引するのではなく、メンバーを支援するサーバントリーダーとなる。
  ※サーバントリーダー：奉仕することでメンバーを導いていくタイプのリーダー
• 自走できるチームを組織化する。
• 声を掛け合える雰囲気を作り、意見を出し合えるようにする。

メンバーの役割

• 共通のビジョンを掲げ、自走してスキルの取得やトラブルの対応への判断、情報共有を行う。
• ネガティブな情報も積極的に共有する。
• 職能横断が要求されるため、複数のスキルを保有する必要がある。

割り込みタスクの対応

スプリントの途中で発見したバグ・追加要望・進行中タスクに関連するバックログのタスクについて、
その場で即対応するのではなく、スプリントバックログのタスクと重要度を比較し、スプリントバックログのタスクより優先度が低ければ、プロダクトバックログに追加し、次回以降のスプリントで対応する。

契約形態はどうするか

準委任契約と請負契約で検討する場合、アジャイル開発では要件が定まっていない・将来的に変更されることが多い。
そこで、成果物の完成を期待する請負契約ではリスクが高くなるため、完成義務がなく、業務に対して責任を負う契約形態の準委任契約の方が適している。

アジャイルの用語

ふりかえり

ふりかえりの手法であるKPTに基づいて、ホワイトボード等に「よかったこと」「課題」「試したいこと」を洗い出す。長期間ふりかえりを実施しないと、挙げる内容を忘れてしまうので、スプリント毎に実施するのが望ましい。

タスク

作業の単位で、大きくなるものは最大1日程度まで分解する。
各タスクを管理する際は、「いつまでに誰が何をするか」の情報も管理する。

タスクボード・カンバン

停滞・遅延しているタスクが無いかを確認するための見える化のためのツール。
ホワイトボード＋付箋紙のようなもので、「未着手」「対応中」「完了」の３段階でタスクを管理する。
３段階に拘らず、段階を増やしてもよい。例：「待機中」等

朝会

昨日の実績、本日の予定、困っていることを毎日共有する。

プランニングポーカー

複数のメンバーで各タスクの見積もり量を見立てたカードを出し合い、工数を見積もる方法。
値がそろうまで、繰り返しカードを出し合い、そろわなければ、その値を提示した理由を説明する。

ペアプログラミング

二人で同じ画面を見ながら実装を行うこと。レビューの時間を削減することができることや、集中力が上がり作業効率を上げることができ、ベテランエンジニアの暗黙知も共有することができる。
結果的に二人で同じ作業をしているからと言って生産性には影響があまり出ず、前述のメリットも教授することができる。
※モブプログラミング：更に複数の人数でプログラミングを実施する。

継続的インテグレーション

テストやビルドを自動化し、常にリリースが可能な状態にすることで、操作ミスを抑制することができる。
また頻繁にビルドを行うことで、バグが発生した場合の対応時間を削減することも可能である。
統合に利用するソースコードはGitなどのバージョン管理システムを利用する。

テスト駆動開発

プロダクトコードをテストするためのコードを作成し、コードチェックする開発手法で、頻繁にリリースを行う場合はテストの工数を大幅に抑えることができる。