スポンサーリンク

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

Photo by Headway on Unsplash

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

スポンサーリンク

受発注 = 上下関係なので

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

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

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

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

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

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

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

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

などが起きてしまう。

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

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

タイトルとURLをコピーしました