なんでもアジャイル適応を追求するのではなく、プロダクトに合わせた適切なプロセス設計力が必要かな
アジャイル開発がSIビジネスと相性が悪い本当の理由：ITソリューション塾：ITmedia オルタナティブ・ブログ
保守開発が「なんとなくアジャイル」になってる事例を見てるので、単にフォーカス分割しづらい案件が一括請負としてまわってきてるだけかな。下手にアジャイルっていうとリリース間際に要件変更言うお客いるだろうし
まあ、SIerは基本要件をお客が持っているわけで、自分でコントロールできる場面はあまりないわけで。まあ、交渉力のあるベンダなら可能でしょうが、お客との力関係が弱い場合はなかなかうまくいかないでしょう。
となれば、フォーカス分割が困難な案件を多々相手にしなければならない場合、アジャイル型開発を相手にするのは困難であり、むしろウォーターフォール型開発や、従来のプロトタイプ／スパイラルモデル型の開発の方が上手くいく場合が多いと実感しているんですね。
実際、保守開発のような小規模要件多量開発型の運用では、至って自然にアジャイル開発を導入可能であり、また、力を発揮できる場面を多々認識しております。
まあ、アジャイル開発をSIビジネスと相性が悪いと認識するのは、「どのようなプロダクト開発をイメージしているのか」という個人のイメージの持ち方に落ち着くのじゃあないかなと思われます。
ウォーターフォール開発が再評価されたアメリカ
似たような話を前の記事で書いたような気がしますが、アメリカではオフショアが2000年前後より増加してきてます。
この時、ウォーターフォール開発が再評価された、という話を聞いたことがあります。
※もう昔なことなので出典は失念。
1990年代にアジャイル開発が産声をあげ、広まったその後、オフショア拡大によりウォーターフォールへの回帰があったわけです。
上記図は、アメリカでのグローバルなウォーターフォールの例です。
小規模プロダクト(例えば、プログラムの一式)ごとに仕様ぎめ、設計／開発、テストといった形の工程を分割し、アメリカ→インド→EUと言った形で、ウォーターフォールの工程を分散して実施する、という方式になります。
この方式の素晴らしいところは、時差を利用することで、常に各拠点はオンタイムで開発が行えることとなります。
つまり、実質24時間3交代制で開発しているみたいなもんですね。
このように、ウォーターフォール開発でも時にアジャイル以上の高速開発を実現できていたりするわけです。
こういう、グローバルな発想ができるのがアメリカの強いところだろうなあ。。。
ほんとうに必要なのは「プロセス設計力」
さて、上記のような形でウォーターフォール開発も再評価＋進歩している例を挙げてみたのですが、これをもってウォーターフォール開発が優れていると言いたいわけじゃあないです。
現に、アメリカでも自社プロダクトや時差なしニアショア開発では、アジャイルを利用する例も多い。ベンダでも、アジャイルを利用している例もある。
反面、上記のようなウォーターフォール手法を利用することで、高い生産性を発揮することも確か。
重要な事は、契約など顧客との関係、チームメンバーの特性、対象とするプロダクト、業務ドメイン、コストやスピードなど、様々な要因により求められる開発チームのスタイルは異なるわけで、その状況次第でアジャイルとの相性が良くもなれば悪くもなるというのが実情。
受託開発も一要因ですが、それが全てではないと思います。
なので、ウォーターフォールがよい、アジャイルじゃなきゃダメだ、みたいな単純化された考えに陥るのではなく、現在の状況から、ウォーターフォールが良いか、アジャイルが良いか、はたまたハイブリッドが良いか、適切な見極めをすることが必要でしょう。
つまり、自分がどういったプロセスを踏むべきか、きちんと創りだすことができるプロセス設計力が必要かな。
まとめ
まあ、色々書きましたが、結局のところ「今、自分は何を作っているのか」という視点にたつことが重要じゃあないかなと。
元の記事にある
って取り組みが微妙なのは同意なんですけどね。
以上
