アジャイル開発時におけるプロジェクトの進め方
アジャイル開発とは？
アジャイル（Agile）とは、直訳すると「素早い」「機敏な」「頭の回転が速い」という意味です。
アジャイル開発は、システムやソフトウェア開発におけるプロジェクト開発手法のひとつで、大きな単位でシステムを区切ることなく、小単位で実装とテストを繰り返して開発を進めていきます。
従来の開発手法に比べて開発期間が短縮されるため、アジャイル（素早い）と呼ばれています。
2001年に、当時軽量のソフトウェア開発を提唱していた17名の技術者やプログラマーが米国ユタ州に集まり、開発手法の重要な部分について統合することを議論しました。
それをまとめたものが「アジャイルソフトウェア開発宣言」です。
アジャイルソフトウェア開発宣言は、ソフトウェア開発とそれに基づく12の原則を定義しており、2017年現在もアジャイル開発の公式文書として広く知られています。
従来のソフトウェア開発は、ウォーターフォールモデルによる開発が主流でした。ウォーターフォール開発は、最初に全体の機能設計・計画を決定し、この計画に従って開発・実装していく手法です。
機械製造や造船業、ソフトウェア開発などさまざまな開発に応用できる手法として、広く活用されています。
・アジャイル開発（アジャイルソフトウェア開発）は、現在主流になっているシステムやソフトウェアの開発手法の1つで、『計画→設計→実装→テスト』といった開発工程を機能単位の小さいサイクルで繰り返すのが最大の特徴です。
・仕様変更に強く、プロダクトの価値を最大化することに重点を置いた開発手法
・サービスインまでの時間を短縮できることが名前の由来（アジャイル＝素早い）
sprint :
開発期間イテレーションとか呼んだりもする。
1サイクルは水曜日から開始し、1週後の水曜日までとする
KPT :
運用の振り返りをsprint終了日の水曜日に実施する
UserStory :
ユーザーができるという観点で書かれたissue。
いわゆるINVESTを満たすように注意。開発初期でのメインのタスクリスト
estimate :
ストーリーポイントとも呼ばれる、相対的な見積もり。
S,M,Lの３つ。MがSの３倍のような相関関係というわけではない
Backlog :
プロダクトへ対する実施リスト。
機能だけでなくCIや環境も含む
Daily scrum :
スクラム。毎日やります。
Velocity:
1sprintでこなせたUserStoryのサイズと数
スプリント開始後
1day
一番ダレやすい日でもあるので、dailyScrumでは明日のscrumまでに何をやるのかを各自コミットして引き締めをする
2day
Mサイズ以下のものは開発完了してマージされ始める
3day
開発評価環境で動かし始める。
conflict起きて動かなかったりするので、環境を安定させるのを優先
ここらへんからPOの実機レビューが始まっていく
4day
最後の追い込み。着地させるために機能のドロップも視野に入れる
5day
POの最終実機レビュー
velocityまとめる
KPG振り返りする
次イテレーションでやるUserStory,Backlogを決める
アジャイル開発とウォーターフォール開発の違い
ウォーターフォール開発は、要件定義から設計、開発、実装、テスト、運用までの各工程を段階的に完了させていくシステムやソフトウェアの古典的な開発手法。
要件定義や全体の機能設計を固めてから開発に着手するため、実際に開発が始まるまでに時間がかかる傾向があります。
その一方で、進行計画に余裕を持たせるケースが多く、予算が立てやすい・チームメンバーのアサイン計画が立てやすいといった特徴があります。
開発途中での仕様変更や追加対応が困難なこと。
アジャイル手法の基本のステップ
①取り組むテーマ（範囲）の決定
アジャイル開発を導入すべきテーマを決定します。またテーマごとに自社の事業への貢献インパクトを分析し、その評価に準じて取り組むテーマの優先順位づけを行います。
取り組むテーマの優先順位付けが終わったら、優先順位の高いテーマから開発に着手します。
②チームビルディング
プロジェクトに携わるメンバーを集め、チームビルディングを行います。
クライアント企業など、他社のメンバーがチームに入ることもあります。
③全体スケジュールの作成
プロジェクトを短いスパン（1〜4週間程度）のスケジュールで実施できる範囲に切り分け、リスト化します。
④イテレーション（短いスパンの開発）
短い期間の間に定められたテーマに合わせて要件を定義し、設計、実装、テスト、リリース、ユーザーからのフィードバックをもとにした改善というサイクルを繰り返します。
⑤次に取り組むべきテーマの検討
実施した開発や最初の優先順位の検討内容を踏まえ、次に実施する開発のテーマを検討します。
アジャイル開発の種類
手法① スクラム
スクラム開発は、アジャイル開発の中でも有名な手法で、開発を進めるためのフレームワークを指します。
スクラムとはラグビーで肩を組んでチーム一丸となってぶつかり合うフォーメーションのことで、その名の通り、チーム間のコミュニケーションを重視している点が特徴です。
スクラム開発ではメンバー自身がイテレーションごとの計画を立案し、設計・実装を進行。
イテレーション毎に開発の進捗状況や制作物の動作を検査するため、チーム内のコミュニケーションが非常に重要になります。
進め方朝会について
世間一般に言われている朝会の目的は以下のような物があると思います。
作業進捗の確認
作業予定の確認
問題点の確認
目的、何を達成したいか
大きく分けて3つあったよ。
情報共有をするのが目的
問題発見解決をするのが目的
一日のリズムを作るのが目的
各流派の典型例
共通部分
15分以内、または概ね15分
話す内容は、昨日やったこと、今日やること、課題・心配事項
議論・深掘りはしない⇒すぐ解決しないことは別体でやる
非難しない
情報共有派
大体朝に開催する
司会持ち回り＆全員強制発言
ちょっとした雑談も話す
問題解決派
朝・昼・夕、開催タイミングはPM次第
問題が多いときは朝夕2回
司会はPM
昨日やったこと、今日やることは、成果物ベースで報告する
遅延がある場合はその理由も報告する
リズム派
必ず朝に開催する
9時とか10時とか決まった時間に開催
毎回同じ場所で開催
延期は極力しない
司会は持ち回り＆全員強制発言
大きな声でテンポ良く
手法② エクストリーム・プログラミング（XP）
エクストリーム・プログラミング（Extreme Programming）はXPとも略され、事前に立てた計画よりも途中変更などの柔軟性を重視する手法です。
開発チームでは「コミュニケーション」「シンプル」「フィードバック」「勇気」の4つの価値を共有することを推進しており、中でも「勇気」は、開発途中の仕様変更や設計の変更に立ち向かう勇気を指しています。
初期の計画よりも技術面を重視しているため、プログラマー中心の開発手法といえます。
事前の計画よりも仕様・要件の途中変更への柔軟な対応を重視した手法で、4つの価値（コミュニケーション／シンプル／フィードバック／勇気）をチーム内で共有することが特徴です。
①コミュニケーション
ステークホルダー間のコミュニケーションを重視する
②シンプル
設計は必要最低限に止める
③フィードバック
頻繁にテストを行い、フィードバックを重視する
④勇気
仕様変更や設計変更に立ち向かう勇気を持つ
手法③ ユーザー機能駆動開発（FDD）
ユーザー機能駆動開発（Feature Driven Development）は、実際に動作するソフトウェアを適切な間隔で繰り返す手法で実際に動作する機能を開発するには、ユーザー側のビジネスの見える化を行います。
そのため、事前にビジネスモデリングを実施する必要があります。
ユーザー機能駆動開発（Feature Driven Development）は、顧客にとっての機能価値（feature）を重視した開発手法。
ユーザーのビジネスを見える化して必要な機能を洗い出し、適切な間隔で反復的にソフトウェアの開発を繰り返すのが特徴です。
アジャイル開発の関連用語
関連用語① ユーザーストーリー
「ユーザーが実現したいこと」「ユーザーにとって価値があること」（意図・要求）を簡潔にまとめた文章です。
例えば、『ユーザーが気になる商品をお気に入り登録できる』のように、「誰が」「何を」「どうする」のかを端的に記したもの。
付箋紙などに書き出してユーザーストーリー・マッピングを作ることで、開発からフィードバックまでの要素をサイクルを回す際の手がかりとして活用します。
関連用語② イテレーション（スプリント）
イテレーション（iteration）とは「反復・繰り返し」という意味。
短期間で反復しながら効率的に開発を進めるアジャイル開発の1サイクルを単位にしたものです。
アジャイル開発の手法の1つであるスクラム開発では「スプリント（Sprint）」と呼ばれますが、意味は一緒です。
開発手法によって呼び方は変わりますが、いずれも開発期間の単位を表していると認識しておきましょう。
イテレーションの期間は一般的に1〜2週間程度で、イテレーション毎に機能をリリースします。
期間の設定は開発チームによって変化するので注意しましょう。
関連用語③ ベロシティ
開発チームが1回のイテレーション内に完了できたユーザーストーリー（要求）の規模の合計値をベロシティと言います。
つまり、チームの開発量を表したもので進捗状況を計る目安になります。
同一チームかつ同一期間で実施するようなケースでなければ、通常ベロシティの量は不透明。
そのためイテレーションを回しながら実数値を計測し、開発の終盤には正確な見通しが出せるように環境を整えていきます。
関連用語④ プロダクトオーナー
プロダクトオーナー「PO」とはそのプロダクトの責任者です。顧客のニーズをもとにプロダクトバックログを作成し管理を行います。
プロダクトバックログを常に最新の状態に管理し、プロダクトにおける最終決定権を持つ人です。
関連用語⑤ スプリントバックログ
スプリントバックログとはスプリントプランニングで計画されたスプリントで実施するタスクのリストです。
関連用語⑥ プロダクトバックログ
プロダクトバックログとは、計画や要件に基づき必要な機能・要求・改善点をリスト化したものです。
開発中は常にメンテナンスされ、優先度も定期的に更新されます。
関連用語⑦ 振り返り（レトロスペクティブ）
レトロスペクティブ（振り返り）はチームの問題点や良かったことをチーム全員が本音で話し合い、今後の改善点や継続して行う事項について整理し、計画を作成するイベントです。
関連用語⑧ リリース計画
アジャイル開発を行う場合、初めに「いつまでにどの機能をリリースできるか」というプロジェクト全体を管理するためのリリース計画を立てます。
リリース計画では下記の項目を決定します。
ただし、計画段階から仕様・要求を厳密に決めるウォーターフォール開発とは異なり、アジャイル開発のリリース計画は非常に流動的です。
そのために、イテレーションを繰り返す過程でベロシティをしっかり測定。チームのパフォーマンスに合わせてリリース計画を更新し、徐々に精度を上げていきます。
アジャイル開発のメリット・デメリット
●メリット
アジャイル開発のメリットは、不具合が発覚した際に戻る工数が少ないことです。
従来のウォーターフォール開発の場合には、最初に決定した設計・計画を重視するため、トラブルの発生箇所によっては戻る工数が大きく、時間やコストが膨大に膨らむ可能性がありました。
しかし、アジャイル開発の場合は、小さな単位で計画から設計、実装、テストを繰り返しているため、テストで問題が発生してもひとつイテレーション内を戻る分の工数で済みます。
また、計画段階で綿密な仕様を決めないため、開発途中でユーザーとコミュニケーションを取りながらフィードバックを行い、確認をしながら進められます。
仕様変更や追加に対応可能なので、ユーザーのニーズに最大限応えることができ、高い満足度が得られる点もメリットでしょう。
●デメリット
計画段階で厳密な仕様を決めていないため、開発の方向性がブレやすいというデメリットがあります。
さらに良くしようと改善を繰り返し、テストやフィードバックで変更・追加を加えていくことで、当初の計画からズレてしまうことが理由です。
また、ウォーターフォール開発の場合は、最初に指標となる機能設計と併せて、開発スケジュールを決めます。
あらかじめスケジュールを設定しておくことで現状の進捗度を把握することが可能になります。
しかし、アジャイル開発では計画を詳細に立案しないため、スケジュールや進捗具合が把握しにくくコントロールが難しくなります。
チームごとに小単位で開発を繰り返すため、全体を把握しきれずに、気付いたら納期に間に合わないということも起こりえます。