システムを作る時は限られたリソースがあります。
その中で出来ることを定義するにはこの４つの相関関係をしっかり意識しながら判断をしなければなりません。

スコープ(機能数)
コスト (リソース)
品質
スケジュール

この４つについてはアジャイルサムライの本でも荒ぶる四天王として紹介されています。

どれか一つを固定すれば、どれかが犠牲になります。
どこかを重視すれば、全てをこなすことは出来ません。
沢山の機能、高い品質、早いスケジュールで作ろうと思えば、沢山のエンジニアを集め一気に作るしかなくなります。
その場合はコストが掛かるのは明らかです。
コストを抑えて、スケジュールを早くしたいと考えれば品質が悪くなるか、沢山の機能は作ることはできず、本当に必要な機能を作ることしか出来ません。

品質が犠牲になる場合は、正常に動くことだけでなく、変更に弱かったり、無駄にシステムサーバ費が掛かったり、レスポンスが悪いなど、中長期的な技術的な負債を残すことも含まれます。

SI系の中での開発

今回のSIの開発というものの想定は実際の実装を行う中小のチームや請け負った会社を想定しています。

多くのSIシステムは大規模の中で開発されています。
スケジュールの遅れは他の見えないチームの工程に大きく影響を与えることがあります。
もっと言ってしまえば、影響を与えるかどうかは分からず、開発チームの中で判断できないことが大きいため、アジャイルの中でも柔軟にこなすなかでも、スケジュールを固定されるというのは大きな制限を受けることが多いです。

そして、品質は最低限必要です。
ただ、残念ながら開発会社と運用会社が別なことも多く、高い品質は望めないケースも多いです。
最低限、機能が正常に動くというレベルの最低限の品質になるケースが多そうです。

コストは開発を受注した時に決められてしまいます。金銭的な制限は

スコープはわずかに可能性があります。機能開発を契約した時点では詳細まで決まっていることは少ないです。
難易度の高い仕様や仕様変更、本当に必要な機能を定義していくことが必要です。

その中で、追加というものがあるときには初めてスケジュールとコストに対して交渉出来る余地があるでしょう。

本格的にアジャイルを運用するのはなかなか難しそうです。

それでも、アジャイルのエッセンスは価値があるものであり、小さなプラクティスは取り入れていきましょう。
また、交渉の際はこの４つのバランスを考えながら行動していくべきです。

もし、単純にスケジュールのみを守るように行動すれば、交渉が必要なスケジュール、コスト、スコープを変更することなく、実装したエンジニアだけが知る、品質が犠牲になることが明らかです。

どのようなシステムを作りたいのか？本当に考えてみましょう。

Web系の中での開発

開発チームが開発し、リリース後は運用やメンテナンス、機能追加も同じ開発チームが行われることを想定しています。

スコープ

沢山の機能の要望はビジネスサイドから来ます。
ただ、思いつきも多く、本当に実現したいことより大きな形になっています。
システム側はより簡単で価値のあまり変わらない方法をどんどん提案する必要があります。

スケジュール

また、早く出すというスケジュールは市場次第で価値を数倍違うものにします。
BtoCのサービスでは正月のイベントなどに合わせた開発などもあります。
これを遅らせて２月に完成しても、価値が非常に下がってしまうのは明らかです。
ただ、運用を便利にするためにいつか出来ればよいと言う機能などもあります。
これらを考慮しながら開発をする必要があります。

品質

品質は開発チーム自身が運用するため、ここを手を抜きすぎてしまっては、運用で問題の解消ばかりに時間をとられて、中長期的に新しい機能の開発のスピードを下げてしまうことは明らかです。
技術的負債を生んでもスケジュールを絶対守ったほうが良いのか、これから様々な機能追加のベースとなるような実装で、品質を重視するべき機能なのか、判断しながら開発しましょう。

技術的負債についてはこちらにも私の考えを書いているので、読んでみて下さい。
技術的負債と戦わずにマネジメントする

コスト

開発メンバーの人間的なコストの他に実はサーバ維持費などもコストです。
運用していくと積み上がっていくばかりのことが多いですが、最近はクラウドで開発することも多く、コスト感覚が甘くなっているケースもあります。
数百万円無駄にサーバを構築していると言うケースもあるかもしれません。

コストメンテナンスも定期的に技術的負債の解消と合わせて行うべきでしょう。
月に１回程度、見直したり、技術的負債を解消する活動をすると良いかもしれません。
(私達のチームでは負債解消Dayを設けています)

アジャイルの相性

アジャイルの相性と荒ぶる四天王の関係は深いです。
SI系でもアジャイルの色々な考えやプラクティスは活用できるものがあります。
しかし、契約そのものをアジャイルにカスタマイズ出来るようにならなければ固定要素が多く、本当に柔軟な開発は難しそうです。

この荒ぶる四天王を考慮した、新しい契約の形態を生み出すことがSIの開発を生まれ変わらせることが出来る答えなのかなと最近考えています。

これらの４つを考えながら何を優先するべきかを考えてマネジメントするべきです。
スクラムでいえば、この判断は開発チームが行うべきかプロダクトオーナーが行うべきか微妙なところです。
ただ、アジャイルという概念でいえば、誰かが行うべきです。

型にはまるのではなく、答えに合う形で自分たちのアジャイル開発を探して下さい。