この記事の対象
今年読んだ本の中でなかなか良かった「業務システム開発モダナイゼーションガイド」という本の学びまとめた物なので、以下の方であれば時間の無駄にならないと思います。
・SIerに勤務経験がある
・ウォーターフォールからアジャイルに変更を強制されているけれど、今いち違いも良さも分からない。
開発スタイルの基礎となるV字型モデル
良くネット上で議論されているウォーターフォールとアジャイルですが、概ねアジャイルの方が好意的な意見が寄せられている様に思います。
しかし、ウォーターフォールもアジャイルも「ひとつの機能開発」に着目した場合、考え方及び進め方に大きな違いはありません。
どちらもV字型モデルに沿ってプロジェクトが進み、両開発スタイルの大きな違いは複数の機能を同時並行して開発する際の進め方です。
ウォーターフォール(計画型プロセス)とアジャイル(適応型プロセス)
ウォーターフォールとは?
複数の機能を同時に開発する際、各工程はそれぞれ同期をとりながら進めます。
一度は以下の様な図を見た事があると思います。
アジャイル
ウォーターフォールに対しアジャイルでは、各機能ごとに同期をとりません。
機能に優先順位をつけて、ガシガシ生産していきます。
管理工数 VS 変更工数
ウォーターフォールの場合、何百・何千の機能があろうとRD・BD・DD・開発・UT・IT・STが区切られるタイミングで一度進捗が同期されるため、足並みが揃えやすくプロジェクト進捗管理がしやすいです。しかし、各機能担当に求められる力は与えられた仕事をこなすプロフェッショナル性よりも全体最適に近い、視野の広さが求められるので、出来る若者が消耗しやすいのかなと感じます。
一方アジャイルの場合、各機能ごとに優先順位をつけ、短いスパンでRD・BD・DD・開発・UT・IT・STを何回も回します。こうする事により、IT現場でありがちな立ち上げ時から実際に開発が始まるまでの間に発生したライブラリアップデートに柔軟に対応しやすくなります。しかし、小さな組織がたくさん増える事による管理工数の煩雑化に加え、プロジェクトの目的・ゴールが見えなくなってしまうため誰のための開発なのかが見えにくくなってしまいます。こういったアジャイルの問題を解決するにはDevOpsチームが行う定期的な効果測定やデジタルマーケティングチームからの論理的なフィードバックが不可欠となるため、旧来の組織からはコストハウスに見えがちな役割をしっかり拡充する必要があります。
SoR型システム開発とSoE型システム開発
アジャイル向きのプロジェクト、ウォーターフォール向きのプロジェクトという悩みを見かけますが、大きく以下を理解すれば混乱は少なくなると思います。
SoR(System of Record):事実を記録していくためのシステム
→エンタープライズ・基幹系であり、金融勘定系システムの様な物であり、ウォータフォールが向いている。
SoE(System of Engagement):お客様との関係をよくするシステム
→フロントエンド寄りのシステムであり、Webサイトやゲームアプリの様な物であり、アジャイルが向いている。
簡単な両者比較図
SoR型システム | SoE型システム | |
---|---|---|
定義 | 事実を正確に記録することがミッション | お客様との関係を強化する事がミッション |
システム種別 | B2B,B2E | B2C |
重視ポイント | 安定性重視 | 先進性重視 |
実装特性 | 低難易度×多機能 | 高難易度×小機能 |
変更頻度 | あまり変更しない | 頻繁な変更が発生する可能性がある |
ビジネスモデル | ROI重視 | ハイリスク・ハイリターン |
案件開始前の心がまえ | 入念な予測を行った上で実施される | どうなるか分からないがあたりを探索しながら進む業務 |
V字型モデルの問題点
そもそもの話で、V字型モデルにも問題があります。
それは、後工程の予測・推定が十分にできていないと、正しい段階的詳細化が行えないという事です。
これに関する詳しい説明は後続の章でしっかり説明されているので、次回以降かけて記載します。