受注先からみたアジャイル開発とスクラム

少し前に、発注元からみたアジャイル開発を書いたが、今回は受注先から見たアジャイル開発を紹介しようと思う。「受発注でアジャイル開発とかスクラムとか難しいでしょー」と思うかもしれないけど、「そんなことない」かもしれない。

受発注 ＝ 上下関係なので

基本的に受発注の関係は上下関係だと思う。「お客様のパートナーとして」とうたう開発会社は多いが、そりゃほとんどが嘘だ。だいぶよくはなってきたのだろうけど、残念ながら、まだそういう世界になっていない。たぶん、しばらくはまだならない。

ただ、アジャイル開発やスクラムを取り入れて、開発の生産性だけを高めることはできる。

それがいいかどうかは人それぞれの解釈に任せればいいと思う。たいていの人は「そんなのスクラムじゃない！」と言うかもしれないが、んなこたーわかっていて、いやそれでもやっぱり開発効率上げたいじゃん！という意識は尊重すべきだろう。

開発だけのアジャイル開発とスクラム

一番わかりやすいのが、開発だけに閉じてアジャイル開発を進めたり、スクラムを組む方法だろう。

定期的なリズムでインクリメンタル・イテレーティブに開発とリリースを繰り返し、スプリントレビューやふりかえりを活用してプロダクトとチームを高めていく。これはできる。

これだけでも十分頑張っていると思うが、発注元を巻き込んでできないことで、「よりアジャイルに」なれない。たとえば

• 発注元の課題や問題がコントロール不可能
• 発注側が規律を守らずリズムが崩れる
  スプリントレビューが動作確認になってしまう

などが起きてしまう。

それってアジャイルなの？スクラムなの？というはなしでも書いたが、基本的にプロジェクト制で期限や予算の上限があるから、スプリントがほとんど機能しないケースもある。スプリントレビューという名の下の進捗確認定例会議とかね。

ただ、発注元がアジャイル・スクラムを希望するケースも増えてきているようなので、とりあえず開発側が先にそのスピードを高めておけば、時間とともに今の問題はなくなるかもしれない。