初心者でも分かるアジャイル(Agile)の基礎

今回の内容としては、アジャイル(Agile)開発、開発の中で一番多く採用されているスクラム(Scrum)開発フレームワークとツールなどの共有になります。

Project(プロジェクト)

プロジェクトとは以下の図の通りに、明確に定義された目標を達成するための計画、遂行するための管理環境です。

アジャイル開発とは

アジャイル（Agile）とは、『素早い』『機敏な』『頭の回転が早い』という意味です。
アジャイル開発は、システムやソフトウェア開発における手法のひとつで、大きな単位でシステムを区切るのではなく、小単位でテストや実装を繰り返していく開発方法で、「作りながら考えましょう」というやり方です。

アジャイル開発の歴史

プロジェクト管理方法は第二次世界大戦中に作成された管理プロセスだと言われています。
1940年代にはプロジェクト管理方法論「waterfall(ウォーターフォール)」の基礎が作成されました。
ウォーターフォール開発では、開発現場でよく用いられる手法で、開発手順を1つずつ確認しながら工程を進めていく手法のことです。開発を各工程に分けて進めますが、次のフェーズに進んでしまうと後戻りができない手法でもあります。『要件・仕様』から『デザイン』『開発』『統合』『テスト』『リリース』までのぞれぞれの工程毎に決められた技術者が担当して滝のような上から下へ流れるような形です。

2001年、ソフトウェア及びプロジェクトの専門家グループがアジャイルマニフェストを作成してこれがアジャイルという共通意識になりました。
以下のグラフはStandishグループのレポートからアジャイルとウォーターフォールの成功確率の報告になります。（参考：アジャイルの成功確率はウォーターフォールの３倍）

このグラフを見ると、Successfulの割合がウォーターフォールの14%に対してアジャイルでは42%と３倍になっています。従来のプロジェクトは成功しているが、スコープの肥大化に直面し、お金と時間の無駄が生じている。そのため新しい管理プロセスの作成が必要になり、アジャイルの出番になったと思われます。

アジャイル開発はウォーターフォール開発と違い、上の画像のように大きな単位でシステムを区切るのではなく、小さな単位で実装とテストを繰り返し、開発を進めていく手法のため、規模が大きいプロジェクトで、よく使われています。アジャイル型開発では、開発メンバーがシステムにおける優先度に順位をつけ、短い期間での納品を目指して動きます。システムの優先順位を決めるためにミーティングを毎日行い、チーム内でスムーズに連携をとる「スクラム」という手法が主に取られます。

アジャイル開発の12の原則

以下の主な特徴を理解した上でアジャイル開発を行うと、より効率的になると思います。

• 顧客満足
  • 早期かつ継続的に納品することを優先して顧客を満足させること
  • 開発のあらゆる段階で変更を歓迎すること
  • 動作中のソフトウェアを頻繁に納品すること
• 品質
  • 動くソフトウェアこそが進歩で最も重要視されること
  • 技術的に優れた柔軟性と拡張性がある設計になるよう注意すること
  • シンプルさを求め、無駄なく作れる量を最大限にすることが本質であること
• チームワーク
  • ビジネス側と開発者は日々一緒に働くこと
  • 意欲に満ちた人々でプロジェクトを構成し信頼すること
  • もっとも効果的なFace to Faceで話をすること
• プロジェクト管理
  • 持続可能で一定のペースを継続的に維持できるようにすること
  • 最良のアーキテクチャ・要求・設計のために、自己組織的なチーム作りをすること
  • チームが更に効率を高めることができるかを定期的に振り返り、やり方を最適にするよう調整していくこと

アジャイル開発を選択する理由

ウォーターフォールは必要条件は上にあってリソースと時間が下で三角形になっています。
例えば、アマゾンECサイトのようなものを作りたい時、必要な条件は決まっていますが、リソースと時間が決まってないため、終わりが曖昧になり、開発が伸びる可能がある。
アジャイルはリソースと時間が決まってるので、アマゾンECサイトのようなものを作りたい時、全ての機能を含めないことであれば、お客様と相談して優先順位が高い機能だけを実装します。無駄な機能を実装しないため、顧客満足度を達成出来ます。

ウォーターフォールとアジャイルの違い

顧客がアジャイルを選択する理由

開発チームがアジャイルを選択する理由

管理者がアジャイルを選択する理由

幹部がアジャイルを選択する理由

アジャイル開発のフレームワーク

アジャイル開発のフレームワークで良く使われるのは「Scrum（スクラム）」フレームワークになります。
他にも色々ありますが、別々で使うことあれば、組み合わせて使うこともあります。

Scrum（スクラム）

スクラムでは、1週間から4週間のサイクルでソフトウェアを作りながら開発を進めます。以下の図は、スクラムによる開発の流れを示したものです。図中の用語の意味は、以下の通りです。

• プロダクトバックログ： 開発対象のソフトウェアに対する要求のバックログ
• スプリント： 1週間から4週間サイクルの反復
• スプリントミーティング： スプリントの開発目標（スプリント目標）とスプリントバックログを設定するミーティング
• スプリントバックログ： スプリント目標の達成に必要なタスクのリスト
• デイリースクラム： 日毎の進捗確認ミーティング
• 実行可能なプロダクトのインクリメント： スプリントの結果として作成される実行可能なソフトウェア
• スプリント・レビュー：　顧客を見せたり、プロジェクトオーナーを見せたりしフィードバックを貰う
• スプリントレトロスペクティブ：　反省会（KPT）を行う

このスプリントをぐるぐる回していくのがスクラムです。

Lean（リーン）

時間やリソースの無駄がないジャストインタイムプロセスであり、「必要なものを必要な時に必要なだけ」供給します。Leanはスクラムとよく似ているし、同じことを繰り返す製造業界に対し、スクラムは常に変化していくソフトウェア業界と考えても良いです。

Kanban（かんばん）

視覚化することで何を実行しいるかを把握し、途中で割り込みがあっても把握できます。
かんばんは別で使うよりもスクラムで合わせて視覚化するやり方です。

Extreme Programming（XP_エクストリームプログラミング）

• チーム全体の計画　−　すべてのメンバーが計画に参加
• コーディングスタンデード開発　−　コーディング標準で一貫性を維持する
• ペアプログラミング　−　２人で作業する
• コードのリファクタリング　−　設計を頻繁に改善して効率を改善する
• シンプルなデザイン　−　シンプルなデザインの方が費用対効果が高い
• 小規模リリース　−　顧客に頻繁に機能を提供しフィードバックを受け取る

スクラム ＋ XP

このフレームワークは多くの企業さんが使われてます。スプリントで開発しているとき、ペアプログラミングで開発をして品質を高める。スクラムとXPは別ものではなく一緒に合わせて使うフレームワークになります。

スクラム ＋ Kanban(Scrumban)

このフレームワークも同じでスプリントで開発しているとき、かんばんがあれば誰がなんのタスクを実施しているかを確認しやすいので一目で確認出来ます。Scrumbanも一緒に合わせて使うフレームワークになります。

Hybrid

要件定義とシステムテスト・リリースだけを残し、開発をアジャイルで行う。

スクラムの理想的な開発環境とツール

物理的環境

• 一緒に働く
• 可能であれば、プロジェクトルームやポッドを準備
• スペースが限れている場所は、キューブから分断パネルを削除
• モビリティ（可動性）、ワイヤレスパップトップ
• 使用ツール：ホワイトボード、掲示板、マーカー、付箋
• 仕事に注意が散漫するものを取り除く

コミュニケーション方法

• Face to Faceで毎日スクラム会議に参加する
• チームメンバーやプロダクトオーナーとコミュニケーションを取る この目的としては、以下の内容を明らかにすることです
• 目標
• 優先順位
• 作業完了
• 完了する必要がある作業

コミュニケーションツール

最近リモートワークで仕事している方も多いので、ハイテク通信が必要になります。

• ビデオ会議（Zoom）
• インスタントメーセージング（Slack）
• ドキュメント・ファイル共有（GoogleDrive）
• 情報ラジエーター(Jira、Trello)
  • スプリント固定のかんばんボード、ホワイトボード、及びプロジェクトや製品の詳細を表示するその他ディスプレイ

※新しいツールは毎年出て来るため、必要に応じて検討するのも必要かと思います。検討するときはサンプル動画を確認後に決定することを、お勧めします。

スクラムの役割

役割は以下のように２つのチームで別けられます。

プロジェクト・チーム

アジャイルメンター

メンターの方は毎回必要ではなく、初めにアジャイルを導入したときだけ必要になります。

ステークホルダー（利害関係者）

自社サービスの場合は社長もしくは代理部長などになります。
外注サービスの場合は外注先の顧客がステークホルダーになります。

スクラム・チーム

スクラム・チームには、３つの役割（ロール）があります。この役割が非常に重要でプロダクトオーナー、開発チーム、スクラムマスターという３つの役割です。この３つをすべて含めて、スクラムチームと呼びます。

プロダクトオーナー(Product Owner/PO)

プロダクトバックログを管理し、優先順位を決めるプロジェクトの責任者です。具体的には、ビジネス、顧客、市場の要件を把握した後、それに応じて開発チームが行う作業の優先順位を決めることが主な仕事です。有能なプロダクト所有者は以下のことを行います。

• プロダクトバックログの作成と管理を行う。
• 業務部門およびチームと緊密に連携し、全員がプロダクトバックログの作業項目を理解できるよう徹底する。
• 次にデリバリーする機能に関して明確なガイダンスをチームに与えます。
• デリバリー頻度が高くなりやすいプロダクトのリリース時期を決定します。

プロダクトオーナーのワークフロー

• 監督
  • ビジネス、顧客、市場の要件把握してプロダクト・バックログを作成し優先順位を決める。
• 参加
  • スプリント・プランニングで開発チームとスクラムマスターと一緒にMTGして期間とスプリント・バックログを決めます。
• 質問に答える
  • スプリントが始まっても開発者の様々な質問に答えます。
• 出席
  • 毎日行うデイリー・スクラムにも出席して進捗確認や質問に答えます。
• 機能をレビュー
  • スプリントが終わった際に期待した機能かをレビューします。
• 参加・レビュー
  • 自分のチームのスプリント・レビューのときだけではなく、他チームのスプリント・レビューにも参加し、自分チームに対して影響があるかを確認して、レビューを行います。
• 参加
  • スプリントレトロスペクティブ（反省会）にも参加してKPTを確認します。
• その他
  • 製品ビジョンの為、顧客と打ち合わせを行うなど、次のバックログを検討します。
  • プロジェクト（期間と希望）によってプロダクトオーナーが複数スクラムチームを担当する場合もあります。
  • 大きいプロジェクトでは、複数のプロダクトオーナーがあり、様々なプロジェクトの共有会を行う。

開発チーム(Development Team/Team)

プロダクトバックログをスプリント内でどのように実現するかについての責任を持地ます。もっとも効果的なスクラムチームとは、緊密であり、同じ場所にいて、通常、4～6人のメンバーで構成されています。チームメンバーは、さまざまなスキルを持ち（エンジニア、デザイナー、プログラマー、QAなど）が存在します。スクラムチームは各スプリントの計画を推進します。チームは過去のベロシティを参考にして、そのイテレーションで完了できる作業量を予測します。イテレーションの長さを固定しておくと、開発チームは見積もりとデリバリープロセスに関して重要なフィードバックを得ることができます。この結果、予測精度が次第に高まります。

開発チームのワークフロー

開発チームのスキル

T字型スキルが良いと言われてます。１つのしっかりとした軸（機能分野、専門分野）があり、かつ幅広い知識もある人材なので、コアエリアの外で働くことが可能になります。例えば、プログラマーなのにデザインが出来、テストまで任せらるなど、、、、

開発チームの構成

• Face to Faceの対面コミュニケーション
  • コロケーション理想的
  • 電話会議システム
• 適切なチーム規模
  • 小さすぎても大きすぎても非効率になる
  • より大きな開発チームが必要な場合は、複数のスクラムチームを作成する ※マルチタスクは効果がありますが、タスクが2つ以上になると良くないので、ご注意ください。

スクラムマスター(Scrum Master/SM)

スクラムチームが健全にスクラムを実施できていること、スクラムが適さない仕事、開発において、スクラム以外の手法を提案する責任を持ちます。有能なスクラムマスターは、チームが行っている作業を深く理解し、チームが透明性とデリバリーフローを最適化できるよう支援します。スクラムマスターは、主任ファシリテーターとしてスプリント計画、スタンドアップ、スプリントレビュー、スプリントの振り返りに必要なリソース (要員と物流の両方) のスケジュールを決定します。開発チームへの妨害を防ぐ（例えば、急な割り込み作業がスクラムチーム外から飛び込んできた場合などはそれを防ぐ）

スクラムマスターのワークフロー

価値と理念

• 尊敬
  • チーム全体がすべての成果と失敗に対して責任を負う
  • すべてのチームメンバーには、意思決定に関与する権利がある
• オープンマインド
  • 他の人の意見を受け入れる
  • 全員が関与し、共有情報にアクセス出来ることを確認する
• コミットメント
  • すべてのメンバーは、スプリントの目標のみに集中出来る必要がある
  • チーム全体でスプリントの目標を達成する責任がある

アジャイル・スクラムプロジェクト管理ツール

「プロジェクト管理ツール」は、タスク管理や工程管理など様々な機能を持ち合わせて、メッセージ管理やスケジュールの共有なども簡単に行えるため、チームで仕事をする上でも大きな味方となります。「プロジェクト管理ツール」を適切に用いることによって、仕事を円滑に進め、より効率的な働き方を実現することができます。

プロジェクト管理ツールの正しい選び方

全般的に、導入の際に気を付けるべき点を5つに分けてみます。

• 機能（タスク管理、ガントチャート、カレンダー、ツール、チャットなど）

  • ニーズを定義する。その管理ツールでいったい何が出来るかということです。

• クラウド型かインストール型なのか
  最近のアプリケーションは、クラウド型とインストール型の2つに分けられます。管理データをクラウドで保存するのか、あるいは自分のパソコンなどを使って保存するのかの違いです。その辺をリサーチして自社と合うツールを選ぶことをお勧めします。

• 導入費用

  • 管理ツールの多くは、制限された機能を使える無料版と、ツールの全ての機能を利用できる有料版に分かれていることが多いです。また、同時接続人数などによって、プランが異なっていることもあります。そのため、無料プランで試してみてから有料プランをうまく組み合わせることで、対応できることもあります。YouTubeなどの紹介動画を見てから決めても良さそうです。

• 対応言語

  • インターネットでは、地政学的な言語の壁はなくなりつつあります。そのため、海外で作成されたアプリケーションでも翻訳機能を使って、他の言語でも利用できるといったことがありえます。誤訳などが少ない、日本人が作ったアプリケーションを利用していくことをお勧めします。

• インターフェース

  • インターフェースは、そのままその人のユーザビリティに繋がる問題です。そのため、これといったお勧めというのは難しいといえます。 まず、ITエンジニアの方とのやり取りが多くなるプロジェクトでは、タスク管理とスケジュール管理の自由度や記入欄が多いものをお勧めします。 リモートワークが多い環境では、メッセージ機能やチャット機能が見やすく、スケジュールの記入もリアルタイムで反映されるといったツールがお勧めです。 他社の人が参加しているようなプロジェクトの場合、今まで話し合ったことや決まったことが手戻りしては問題なので、決まったことをいつでも確認できるような仕組みを持つツールがお勧めです。

アジャイル管理ツール

• JIRA (https://www.atlassian.com/software/jira)
• Monday (https://monday.com/lang/ja/)
• Smartsheet (https://www.smartsheet.com/)
• Trello (https://trello.com/)
• Clarizen (https://www.clarizen.com/)
• Aha! (https://www.aha.io/)

モック作成ツール

• Adobe XD (https://www.adobe.com/products/xd.html)
• MEDIAMODIFIER (https://mediamodifier.com/mockups/all)
• SmartMockups (https://smartmockups.com/mockups)
• Placeit (https://placeit.net/)
• MockupsJar (https://mockupsjar.com/)
• MockFlow (https://www.mockflow.com/)
• Figma (https://www.figma.com/)

ダイアグラム作成ツール

• Visual Paradigm (https://www.visual-paradigm.com/)
• StarUML (https://staruml.io/)
• Altova (https://www.altova.com/)
• Draw.io (https://www.diagrams.net/)

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

メリット

• 文書作成を最小限にできる
  • 対面のコミュニケーションによる意思疎通と、実際に動くソフトウェアを進行管理の尺度とすることで、作成される文書量を減らせます。
• 従来の開発手法と比較して、納期を短縮できる
  • 詳細な仕様や進行計画などの上流工程、文書作成の工数を削減できます。
• 手戻りする工数が少ない
  • 開発対象を最小化しているため、不具合が発生した際の手戻りが少なくなります。
• 顧客満足を得やすい
  • 仕様変更や機能追加に柔軟に対応でき、開発途中でも顧客のニーズを取り入れやすくなります。

デメリット

• プロジェクトの方向性がブレやすい
  • 詳細な仕様を決めずに着手するため、顧客ニーズに応えて改善を繰り返し、追加・変更が重なって当初の計画から大幅に変わってしまうことがあります。
• 納期遅れが生じやすい
  • チーム単位で「開発～リリース」の工程を反復するため、全体像としてのスケジュールや進捗状況が把握できなくなり、納期に間に合わなくなるケースがあります。これも初期に厳密な進行スケジュールを設定しないことが進行管理の難しさにつながります。

アジャイル開発で失敗しないコツ

アジャイル開発を行う際に失敗しないコツを4点ご紹介します。

• アジャイルが組織に向いているか確認する
  • アジャイル開発において目的がうやむやになってしまっては後々に問題が発生します。要件が組織（ユーザー）のためになるのか、費用対効果が見込めるのかなど、しっかりと確認する必要があります。
• アジャイル開発の導入を急ぎすぎない
  • アジャイル開発は、開発途中の仕様変更にも柔軟に対応できるのが大きなメリットです。しかし要望を多く取り入れ、都度変更が起こるようでは、開発チームの負担も相当なものとなります。そのため、アジャイル開発において要件の導入を急ぎすぎないことが大切です。
• 開発前にしっかりと企画を詰めておく
  • アジャイル開発は、詳細を決めなくても柔軟に開発を進めることができます。しかし、思いつくまま開発を進めても、結果的にそれが組織に向いているのかどうかをしっかりと精査する必要があります。そのため、企画だけはしっかりと詰めておくことが大切です。
• 意思疎通のためのドキュメントを作る
  • 開発にあたって、打ち合わせ内容はしっかりとドキュメント化しておく必要があります。これは、何か問題が起きたときに「言った言わない」といったことが起きないようにするためです。ユーザーとのコミュニケーションをしっかりとって、意思の疎通をすることはアジャイル開発においては必要不可欠と言えます。

まとめ

アジャイル開発はスピード重視でありながら、品質にも配慮しているため、現代においての最適なソフトウェア開発形態といえます。
修正に対して柔軟に対応できる点が評価されていますが、開発側とクライアントのコミュニケーションも大切で、改善点やフィードバックなど、しっかりと話し合いの場を設ける必要があります。
この点に注意することで、最適なシステムが仕上がることは間違いないと思います。

今回は自分がUdemyで学んだ「現役シリコンバレーエンジニアが教えるアジャイル開発」をメモとして説明しました。