CONTENT
こんにちは、東京エンジニアのS.Wです。
今回はアジャイル開発について、基本的なところをまとめてみました。
■アジャイル開発とは
プロジェクトで実装する機能をストーリーという単位で分け、イテレーションという短いスパンでストーリーの開発を繰り返し行っていく。
よく対比として挙げられるウォーターフォールはプロジェクトを長期スケジュールで分析/設計/実装/テストと重量級の開発を進めていく。
しかしこの場合、終盤に仕様変更が発生すると分析工程から変更しなくてはならないため、コスト・リスク共に非常に大きく不可能な場合も多い。これに対応するために登場したのが繰り返し型の開発、そしてアジャイル開発へと進化した。
■アジャイルマニフェスト
アジャイル開発は現場やプロジェクトによってさまざまな形に姿を変えるが、基本的な共通事項として「ソフトウェア開発において何を重視すべきか」が定義されている。
https://agilemanifesto.org/iso/ja/manifesto.html
また、以下のアジャイルソフトウェア開発の原則では、ソフトウェアやシステムの価値を最大化するための具体的な行動指針が示されている。
https://agilemanifesto.org/iso/ja/principles.html
■用語
・ストーリー
顧客の目線で実現したいことを記述したもの。
プロダクトオーナーにより実現したい価値基準に優先順位付けする。
・タスク
ストーリーを実現するための各作業
・イテレーション
短期間で開発を繰り返す開発サイクルの固定の単位。
期間はプロダクトオーナーとチームで決める。通常1週間から長くても1ヵ月。
・スコープ
イテレーション内で開発するストーリーの範囲。
予算・スケジュール・品質は基本的に変えない（変えられない）、変えなきゃいけないときはスコープを変える。
■登場人物と役割
・ステークホルダー(利害関係者)
プロジェクトに資金提供を行うスポンサー。
直接的に開発に携わることは少ないが、プロダクトオーナーに対する発言権を持つ。
・プロダクトオーナー
プロダクトの最終責任者で、プロジェクトのゴールに向かって意思決定を行う。
プロジェクトにつき原則1人。
・開発チーム
ソフトウェアの開発を行うチーム(チームリーダーを含む)。
通常4名～多くても9名で構成する。10人を超えると意思疎通が難しくなる。
自己組織化されたチームであり、計画・管理・実行・コミュニケーションをチーム自身ですべて行い、必要に応じて自分たちで改善していく。
・チームリーダー
開発チームで実施するプロセスがうまく回るように支援するリーダー。
チームリーダーから開発チームメンバーに作業依頼や指示を行うわけではない。メンバーが作業に集中できるよう問い合わせの窓口になったり、合意形成や相互理解をサポートすることによりチームを活性化させ、チームとしての成長を促す。
■アジャイル開発のチームメンバーに求められる人物像・スキル
最も重要なのは、開発者同士の会話により知識・課題を共有し、作業を進めていくためのコミュニケーションスキルが必須。また、アジャイル開発のチームメンバーは、担当するストーリーについて、設計、実装、テストの工程を基本的に1人で行う多能工が必要とされる。
では、経験の浅いエンジニアはアジャイル開発には入れないのかというと、そうではない。経験が浅くてもコミュニケーションでだいたいは解決できるし、そういう進め方を推奨している。
■会議体
・イテレーション計画会議
イテレーション開始前に行う。
プロダクトオーナーを含めた第1部と開発チームだけで行う第2部に分けるとよい。第1部で次のイテレーションで実装するストーリーを選定し、スコープを決め、最終的に何を達成するかというゴールについて合意する。第2部で開発チームでストーリーからタスク一覧を洗い出す。
・スタンドアップミーティング
開発チームで行う朝会。
一人一人が昨日やったこと、今日やること、問題の共有を行う。長くても15分で切り、技術的な課題や進捗の遅れに関する課題などは、スタンドアップミーティング後に個別に行う。
・イテレーションのレビュー会議
イテレーションの最後に開発した製品のレビューを行う。
開発チームがプロダクトオーナーやステークホルダーに対して成果物のデモンストレーション、またはプレゼンテーションを行う。フィードバックをもらうのが目的で、ここで出たものは次回のイテレーション計画会議へフィードバックする。
・開発チームの振り返り
開発チームがイテレーションで実施してきた内容について話し合い、次回以降の進め方について改善していく。基本的にイテレーションの最後に行うが、予期しない問題や課題が発生したときは、適時メンバーを招集して行う。
・イテレーションの振り返り
イテレーションの最後に関係者全員で行う。
イテレーションでのチームでの作業や開発プロセスについて再確認し、全体の改善点がないか話し合う。KPTを利用した問題整理がよく使われる。
■最後に
アジャイル開発のチームはよくラグビーのチームに例えられる。
ラグビーの試合で監督はベンチに入れず観客席にいるため、選手に指示を出すことができない。キャプテンを司令塔として選手が自分達でどう動くか決めている。
アジャイル開発のチームも同じで、チームで話し合い、よいと思ったものは取り入れて反対に効果がなかったりしたプロセスは取りやめるなど、繰り返しプロセスの中で改善していけばよい。重要なのは顧客にとって価値のあるプロダクトを安定して提供し続けることである。
以上です。次回はアジャイル開発で採用される主な開発手法についてまとめていきたいと思います。