DaisukeのITメモ

一人前になる為に。

Agileとは

目次

概要

従来の（レガシーな）開発手法であるウォーターフォールに代り台頭している、デジタルな開発手法Agile開発 について纏めてみた。

Agileとは

VUCAの時代の中で、目的を達成し、その成果を最大化する為の考え方,概念。
ソフトウェアの開発方法論というよりは、ビジネスの作り方らしい。

Agile台頭の理由

下記のように、ウォーターフォールの開発手法と現在のビジネス環境にギャップが生じているため。
ウォーターフォールでは対応できない様なビジネスが増えてきた。

ウォーターフォールとは

ウォーターフォール開発は名前の通り、水が下に向かって流れ落ちていくように、要件定義,外部設計,内部設計といった各工程を手戻りしないよう進めていく。
最初に全ての要求を集め、開発スコープを明確に定義し、その為に必要な期間,人員などのコストを見積もり、開発工程が終わった際に初めて大きな成果物をドカンと完成させるビックバン型の開発手法。
簡単に言うと、最初に行き先を1点に決めて、そこに向かってめちゃ大股1歩で進む（途中で方向転換不可）スタイル。
そのため、求められる要件がコロコロ変わったり、ビジネス効果の見通しがつき辛いといった特性のビジネスには向いていない。

  • メリット：
    • システムのゴールや各工程の成果物が明確で、進捗状況が把握しやすいことが挙げられる。
  • デメリット：
    • 全工程が完了して初めて、システムの動作を確認でき、ユーザーからのFBが得られる。
      • 例えば、要件定義の大前提が誤ったまま開発を進め、テスト工程になどでそれに気付いた場合、それまでの全工程が無駄になってしまい、0から作り直しという事も有るため、手戻りのダメージが大きい。
      • システム利用者の意見を、要件定義や設計工程の段階で全て洗い出す必要が有る。

一方で、現在のビジネス環境は

世の中がVUCAの時代を迎えている事で、企業の方針や取り巻く状況もどんどん変化が速くなり、予測できない未来が次々に訪れている。
スピード感が必要な事業や、Try＆Errorを繰り返しながら進んでいく領域では、WhatやHowが最初に完全にfixしている必要があるウォーターフォール開発では対応しきれなくなってきた。
VUCAについては下記記事を参照。 daisukeinoue.hatenablog.com

Agileの順応性

一方、Agileでは、「事前に全ての事を正確に予測し、計画する事はできない。」という事を前提としているため、期間や人員だけを決定,固定し、その範囲内で大事な要求（重要なモノ,リスクが高いモノ）から順にプロダクトを作成する。
また、それを短期間のサイクルで何度も繰り返す事で、動くモノを短期間で素早くリリースしFBを取り込み続けるスモールスタート型の開発手法。
簡単に言うと、最初に行き先を決め切らず方向性だけ決めて、そこに向かってめちゃ小股で何歩も刻みながら進む（途中で方向転換可能）スタイル。
そのため、求められる要件がコロコロ変わったり、ビジネス効果の見通しがつき辛いといった特性のビジネスに向いている。

ビュッフェを例にした簡単な説明

ウォーターフォールの場合

全ての料理に対して、どの順番でどの食事をどの量で取って来て食べるかを最初に綿密に計画し、全料理食べ終わるまで計画を変更せず（FBを取り入れない）、何が有っても（気分が悪くなったり、食べたく無いモノが有っても）計画に従って食事を終える。
→　最終的な満足度は高くないかもしれない。

Agileの場合

まずは重要そうな（自分が大好きな）料理だけを取って来て食べて、その後も気分や食べたくなったモノを優先的に、少量ずつ細かい頻度で料理を取って来て食べるを繰り返す。
→　料理を取り直す度に常にFB（その時の状況）を取り入れて最善の料理を取り食べているので、最終的な満足度は高いはず。

鬼ごっこを例にした簡単な説明

ウォーターフォールの場合

鬼の位置を低い頻度で確認しながら逃げる。
→　鬼の位置を把握していない（FBを得られない）間は、最適な軌道修正を行えないので、鬼に捕まりやすい（成果が出ない）。Agilityが低いと言える。

Agileの場合

鬼の位置を高い頻度で確認しながら逃げる。
→　鬼の位置をほぼ常に把握しており（FBを得ている）、常に最適な軌道修正を行えるので、鬼から逃げやすい（成果を出しやすい）。Agilityが高いと言える。

思想

下記の様な思想から成り立っている。

  • 関係者は目的達成の為に互いに協力し合いながら進める。
  • 一度に纏めて作るのではなく、小さな単位で少しずつ作成し動くモノを早い段階から届け、ユーザーやステークホルダーからの評価,FBを繰り返し得る事で、作っているモノ自体や計画を調整し、成果を最大化する。

思想の根底

上記の思想は、下記の考えが根底に有る。

  • ソフトウェアを作成する目的は、作成自体ではなく、その先に有る、成果をあげる事（あげ続ける事）。
  • 成果とは、ユーザーやお客様の課題を解決したり、お金を稼ぐ事。
  • よって、何の為に作るか（why）を常に明確にしつつ、現在作成しているモノが本当に成果を実現できているのかをこまめに確認しながら進めていく必要が有る。
  • その過程で、当初作ろうと思っていたモノよりも良いアイディアが出てくればそれを受け入れ、作るモノを変えていく事で、成果の最大化を図る。

実現手法

Agileを実現する為の手法には例えば下記の様なモノが有る。

Agile向きの案件とは

現代の全てのビジネスがAgileに向いているというわけではない。
ビジネスの特性から、採用すべき開発手法を見極める必要が有る。

Agile向きの案件例

Agile向きの案件特性としては大きく下記の2つ。

  • Delivery（俊敏性）重要視の案件
    ある時点まで、もしくは、なるべく早くリリースする事でビジネス効果が最大化される様な案件。例えば下記の様な案件。
    • 法律緩和,強化への対応。
    • 競合他者との競争。
    • トレンドへの急速な対応。
  • 即応性重要視の案件
    事前にビジネス効果の見通しがつかない、もしくは、要求がコロコロ変わる様な案件。例えば下記の様な案件。
    • 新規事業。
    • 先進技術活用。

WF向きの案件例

WF向きの案件の特性としては大きく下記の2つ。

  • 確実性重要視の案件
    元から要求が明確で、変更対応も求められない様な案件。
  • QCD平準性重要視の案件
    求める要求を、なるべく安く、決められた期間で確実に作りたい様な案件。

【おまけ】Agile案件に適した契約形態

  • 下記理由より、納品物に対してお金を頂く請負契約よりも、提供した稼働時間に対してお金を頂くSES（準委任契約）の方が適していると考えられる。
    • Agileの性質上、事前に成果物を明確に定義できないため。
    • WF特有の包括的なDocやプロセスを、Agileでは一部省略しながら進めるため、Doc納品が必須な契約は向いていない。
  • SESと請負のハイブリッドにする場合は、MVP（必ず実現すると決まっているコア機能）に対してだけ請負契約とし、他稼働についてはSESとするというパターンが考えられる。

WF特有の包括的なDocやプロセスをAgileで省ける理由

  • 純粋にAgilityを高める為。
  • 下記理由により、WFとAgileでDocの重要性に差が有るため。
    • WF：
      • 工程が分断されている事が多く、体制や人も分断される事が多いため、工程を跨いだ仕様情報の橋渡しの生命線をDocが担う事になるため。
      • 事前に成果物が明確になっていたり、品質を求められる事が多いため、請負契約の場合が多く、Docも納品物として定められている場合が多いため。
    • Agile：
      • WFと違い、工程が分断されていない事と、Scrumメンバが機能横断的（どのプロセス・工程も実行できる）なため、工程を跨いだ仕様情報の橋渡しがDocでなくても成立する。
      • SES契約の場合は、Docは納品対象でないため。

所感

  • Agile案件の契約形態における制限など有るのか、有るならどのようなモノなのか気になった。
    • →　有識者である先輩からFB頂いたので、上記に追記済み。
  • Agileが向いている案件,向いていない案件を判断する考え方も気になるので、今後の学習課題とする。
    • →　有識者である先輩からFB頂いたので、上記に追記済み。
  • AgileとDevOpsの関係性を明確に理解できていないので、今後DevOpsについても自己学習したい。

参考文献

なぜアジャイル開発？ウォーターフォール開発からの脱却 | Qbook

/* -----codeの行番号----- */