大規模システム開発
大規模の定義ですが、人によってその規模間の感じ方は異なると思います。
システム開発は、ある程度、規模が大きくなると、携わる開発者の数も増え、きちんとプロジェクト内のルールを決めなければ統制が取れなくなり、要件定義書や基本設計書などのドキュメントも正しく作成しければ品質の管理ができなくなります。いわゆるプロジェクトマネージメントを厳密に行わなければ成り立たない程度の規模をここでは「大規模システム開発」と定義します。
個人的には、2000万円以上の案件は、プロジェクトマネージメントを厳密に実施すべきだと感じています。
それ以下だと、少数でも精鋭技術者が揃えば、力業で成し遂げることも可能だと思います。
小さなソフトウエア会社は、人材派遣ばかりやっていたり、下請けとして開発の一部だけを請け負っていたりして、経験が十分でなく、一括での受注は難しい場合が多いと思います。
そのような場合、受注できる上限の受注金額は1000万円だったり、500万円だったりします。
プロジェクトマネージャによっても、管理できる規模は異なります。2000万円が限界だったり3000万円が限界だったり1000万円が限界だったり人により力量は異なります。上司や営業はプロジェクトマネージャの力量を図り、キャパを超えている場合は、補助輪を付けるなどして大きな失敗にならない様、気を付ける必要があります。
アジャイル開発とウォーターフォール開発について
開発方法としては大きくは「アジャイル開発」と「ウォーターフォール開発」があります。
個人的には両者の欠点を補う「ハイブリット型開発」を用いています。
次に「アジャイル開発」「ウォーターフォール開発」「ハイブリット型開発」について説明していきます。
アジャイル開発とは
アジャイル開発では、計画段階で厳密な仕様を決めません。なぜなら「開発途中に仕様変更があること」を前提とするからです。
アジャイル開発では、イテレーションと呼ばれる短い開発期間単位（約2週間）で「要求の決定」「実装」「テスト」「修正」「リリース」を実施します。この小さなサイクルを何度も回しながらシステムを構築していきます。
アジャイル開発は設計とプログラミングを何度か行き来し、トライアンドエラーで改良していく手法です。
作るものが明確になっていないモノや、時代の変化が早く、常に変化に迅速に対応しなければならない場合には有効だと思います。
アジャイル開発のメリット・ディメリット
（メリット）
- 早い段階で顧客が実際の画面や機能を試すことができ、仕様の間違いや要求漏れに気づくことができます。
- 開発の途中での要求の変更に柔軟に対応しやすいです。
- 反復ごとに開発／提供するため、より速いスピードでの提供が可能です。
- 反復ごとに機能の出来栄えを確認できるため、さらなる品質向上や顧客満足度向上が期待できます
（ディメリット）
- 終わり無くイテレーションを繰り返す可能性がありプロジェクトのスケジュール管理がしづらいです。
- 厳密な仕様を決めていないため、プロジェクトの方向性がブレやすくなります。
- テストやフィードバックで変更・追加を加えていくことで、当初の予算を大幅に超過してしまう可能性があります。
- メンバーのスキルとしては、役割分担しても良いですが「要求の決定」「実装」「テスト」「修正」「リリース」が全てこなせなくてはなりません（個のスキルが高くなければなりたちません）
ウォーターフォール開発とは
ウォーターフォール開発とは「要件定義」「基本設計」「詳細設計」「開発・単体テスト」「結合テスト」「システムテスト」と工程を区切って進める方法です。
要件定義や設計に要求ミスや漏れがあった場合や、開発途中で要求に変更があった場合、別途追加費用や開発期間が発生する可能性があります。
システムのリプレースなど、すでに作るべき機能が明確に決まっている場合はアジャイル開発よりも、ウォーターフォール開発が向いています。
ウォーターフォール開発のメリット・ディメリット
（メリット）
- 初期の段階で計画や予算を確定しやくなります。
- プロジェクトの全体の建付けを初期の段階で行うので方針がぶれにくくなります。
- それぞれ工程ごとに必要なスキルの要員を割り当てることができます。
- 工程ごとの品質管理ルールを決めやすくなります。
（ディメリット）
- 要件変更・仕様変更に柔軟に対応できません
- 途中に要件変更・仕様変更が発生すると大幅なコスト増となります。
- 初期の段階で要件の網羅性を完璧にすることは困難です。
ハイブリット型開発
ハイブリット型開発とは、ウォーターフォール開発の欠点をアジャイル的な手法で補うものです。
工程としては「要件定義」「基本設計」「開発・単体テスト」「結合テスト」「システムテスト」と定義しますが、「要件定義」で画面のモックアックを作成し（小さなプレ開発）、業務フローに従いウォークスルーレビューを行い（疑似体験）、顧客と開発者の間でなるべくギャップを無くします。また「要件定義」の段階では、機能概要仕様（どこまでの機能が作成されるのか）を作成し顧客との間でレビューを実施します。「基本設計」の段階でも同様に、基本設計仕様書（具体的にどういった機能が実装されるのか）を作成し顧客との間でレビューを繰り返します。「開発・単体テスト」「内部結合テスト」を終わった段階で、できた機能から順番に顧客に公開し、操作間・機能上の認識違いが無いかをレビューを繰り返します。「外部結合テスト」「システムテスト」が終了したら、顧客側で受入テストを実施します。
ハイブリット型開発では、各工程毎に顧客の認識・イメージとのギャップを埋めるために、まめにレビューを繰り返します。開発途中で要件変更・仕様変更が発生した場合、軽微な場合はついでに修正して進めますが、大きな変更はもう一本仕様変更に対応するスケジュール（「要件定義」「基本設計」「開発・単体テスト」「結合テスト」「システムテスト」）を作成して別途見積を行い同じサイクルで実施します。
大規模システム開発におけるスコープ管理と予算管理について
アジャイル開発は、当初厳密に計画や要件を決めない為、方向性がぶれやすい事を説明しました。
またイテレーションを永遠に続けるとシステムはどんどんブラッシュアップされ顧客満足度は上がりますが、プロジェクトがいつまでたっても終わらなくなります。
一方、ウォーターフォール開発は初期の段階で要件の網羅性を完璧にすることは困難で、プロジェクト途中の要件変更・仕様変更はコスト追加・スケジュールの延長につながることを説明しました。
いづれにしても、要件が正確に定義できていない状態で進めていくとアジャイル開発でもウォーターフォール開発でも予算やスケジュールの見直しが必要となります。
いかに初期の段階で要件や仕様を最終盤に近づけることができるかがポイントです。
ハイブリット型開発もリードする技術者のスキルによりプロジェクトの成功が左右されます。
ヒヤリング力や要件整理スキルや業務知識や技術スキルなど多岐にわたって高度のスキルを求められます。
大規模システム開発におけるスコープ管理と予算管理がうまくコントロールできるか否かは、リードする技術者のスキルにかかっていると言っても良いでしょう。
システム開発は欲張りすぎると失敗します
プロジェクトの途中で、「実はこれもあったらいい」というwantの要件がたくさん出るものです。たいていは無くても業務は回ります。プロジェクトにおいて予算やスケジュールはmustの要件です。「あったらいいね」のwantの要件はどんどん切り捨てていかなければ、プロジェクトは破綻してしまいます。要件定義は「要件を拾う」のではなく「要件を切る」といった感覚の方が良いと思います。パレートの法則によると2割を実現すると8割の効果が得られます。本当に必要な要件に絞ることを心がけましょう。
Follow me!
コメント