SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

ボトムアップからのアジャイル開発管理手法の導入

なぜアジャイルの導入は難しいのか? アジャイルとウォーターフォールの目的の違いから考える

ボトムアップからのアジャイル開発管理手法の導入 第1回

  • X ポスト
  • このエントリーをはてなブックマークに追加

ウォーターフォールモデルとアジャイルの大きな違い

 ここで扱いたい違いとは、ウォーターフォールモデルは「前の工程に戻れず」や「大規模開発向け」なモデル、アジャイルは「ユーザの意見を取り入れやすい」モデル、といったものではありません。もっと根本的な違いとして、筆者は以下のような点を考えています。

  • ウォーターフォールモデルとは、「コスト(原価)」を最小化したい場合の考え方
  • アジャイルとは「バリュー(売上)」を最大化したい場合の考え方

 この観点から2つの違いを説明していきます。

どうしてアジャイルは普及しないのか

 開発現場では、仕様変更が要件定義後の工程にかかわらず発生したり、できあがった後に追加要件が生じたりするにも関わらず、どうして、会社や顧客はアジャイルに賛同してくれないのだろうという気持ちがある方もいるはずです。

 アジャイル思想を理解してもらえれば、それが最適だと分かるはずなのにとも思うでしょう。

 しかし、採用していないことにも理由があります。それは、システム開発の大きな目的の1つにコスト軽減があるためです。

 業務委託でのシステム開発において、利益を最大化したいなら「コストの最小化」は確実な方法の1つです。また、業務委託でなく社内開発であっても、システム化の要望自体がコスト部署からであれば「バリューの最大化」よりもコストに向くのは自然です。そういう現場ではアジャイルという考え方が普及しにくいのは仕方がないことだと思います。

 ただし、実際のプロジェクトでは、コストの最小化とバリューの最大化という目的は、同時に存在します。そのため、アジャイルへの期待が生まれてくるのだと思います。

 しかし、アジャイル手法の採用が難しいケースでは、コスト面から生じる制限が非常に大きいため、採用がし難いと感じているのだと思います。

コスト構造からみる違い

 ここで、コスト構造の違いがよく分かるように、ウォーターフォールモデルとアジャイルモデルの違いを考えてみます。例えば、図7のようなウォーターフォールモデルでの開発スケジュールがあったとします。

 話を単純化するために、各工程(1つの四角)は一人だけが対応するものとし、全体の工数は6.5人月かかるものとします。

図7:ウォーターフォールモデルでのスケジュールと行程
図7:ウォーターフォールモデルでのスケジュールと行程

  これを、アジャイルの目的の1つである短いリリースを繰りかえし、短い期間でフィードバック可能なように細かいサイクルで図8のように計画することとします。

図8:細かいサイクルでのスケジュールと行程
図8:細かいサイクルでのスケジュールと行程

  しかし、これでは現実に即さない机上の理論のみで、無理矢理つくったという感じが否めません。そして、現場では図9のように実態が近付いていくはずです。

図9:実際のスケジュールと行程
図9:実際のスケジュールと行程

 このスケジュールの場合には、工数は25人月になります。

 続いて、実際のスケジュールとは異なり、図10のように実際に開発がはじまってから要件変更があるケースを想定します。

図10:開発フェーズで工期が伸びてしまったケース
図10:開発フェーズで工期が伸びてしまったケース

 当初、「業務API開発」と「UI開発」では、期間を2カ月で工数としては3.5人月を見込んでいましたが、こちらが6カ月伸びると、12人月が増えますので、全体として18.5人月かかります(実際には、開発者以外の関係者工数も含む必要がありますが、単純化のために省略しています)。

 このような状態になってしまった場合、多くの方が失敗したプロジェクトと感じるでしょう。しかし、プロジェクトの優先度が価値の最大化よりもコスト最小化のほうが高いならば、プロジェクトの結果としてはアジャイルで行う25人月のプロジェクトよりも良いと言えてしまうのです。

 実際にはこんな単純に比較できませんが、表面上はアジャイル管理はコストがかかるプロジェクトというように見えるはずです。

 また、最小から比べると、大きく予算が膨らむわけですから、予算を出す側の理屈では、できあがる価値の確証がとれないと支出を許容しにくくなります。もともと、作る物をよりフレキシブルにして将来のニーズを導入しやすくするモデルであるにもかかわらず、予算制限の面から見た場合にはウォーターフォールモデルよりも、より将来価値の確実性を高めないと採用しにくいという状況を作ってしまいます。

次のページ
組織と開発管理モデル

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
ボトムアップからのアジャイル開発管理手法の導入連載記事一覧
この記事の著者

WINGSプロジェクト 小林 昌弘(コバヤシ マサヒロ)

WINGSプロジェクトについて>有限会社 WINGSプロジェクトが運営する、テクニカル執筆コミュニティ(代表 山田祥寛...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

山田 祥寛(ヤマダ ヨシヒロ)

静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for Visual Studio and Development Technologies。執筆コミュニティ「WINGSプロジェクト」代表。主な著書に「独習シリーズ(Java・C#・Python・PHP・Ruby・JSP&サーブレットなど)」「速習シリーズ(ASP.NET Core・Vue.js・React・TypeScript・ECMAScript、Laravelなど)」「改訂3版JavaScript本格入門」「これからはじめるReact実践入門」「はじめてのAndroidアプリ開発 Kotlin編 」他、著書多数

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/19632 2024/06/25 11:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング