読者です 読者をやめる 読者になる 読者になる

Yasuo's Notebook

ソフトウェア開発の話題が中心の備忘録です。

アジリティを高める

「要件定義とリリース、テストはウォーターフォール開発で、実際の開発はスクラムに基づいて進める」というところが話題になっていました。

http://itpro.nikkeibp.co.jp/article/COLUMN/20120521/397707/

ここでのテストはおそらくシステムテストのことを指していると思います。
これがアジャイルなのか?というのは別として、アジリティを高めることと、フィードバックについていつも考えていることを書いてみます。

「アジリティ」は高い方が良いですか?という問いには、多くの人が抵抗なくYesと答えるのではないでしょうか?昔のWizardryのようなゲームでキャラクターを作っているときでも、他の能力値が一緒なら「アジリティ」の高いキャラクターを没にする理由はないと思います。(顔が嫌いとかはおいておいて。。昔のゲームには顔もなかったですね^^;)
ソフトウェア開発においてこのアジリティを高めるための有力な手段は「フィードバックを得ること」だと思います。アジャイルのプラクィスの多くがいかにしてフィードバックを得るかに着目しています。一言にフィードバックと言っても「いつ」「誰から」「どんな」と考えていくと様々であることが判ります。例えば、次の図のようになります。

f:id:yasuo99:20120531221635p:plain

現在に比べて、この何れかのフィードバックの間隔、質を向上させることがアジリティの向上に繋がります。
最初に戻って「要件定義とリリース、テストはウォーターフォール開発で、実際の開発はスクラムに基づいて進める」は、このガイドを適用する前と後で誰からのフィードバックを改善しようとしているかがポイントです。おそらく、チームの実装からのフィードバックは大きく改善されるでしょう。ハードウェア担当者や他サブシステムチームからのフィードバックも改善する可能性があります。WFでも、設計結果により要求を見直すことはあります。ただ、その時期が遅くなり調整が難しいということがあります。チームのフィードバックの改善により、調整時期を早めたりや説得力の上がったりする可能性があります。
一方で、顧客、エンドユーザからのフィードバックという観点では、改善は皆無ではありませんが、限定的なものになると思われます。
顧客、エンドユーザからのフィードバックを得るには、継続的なデリバリーなどを検討した方が良いでしょう。このように、フィードバックが及ぶ範囲の限界を意識した上で、反復の範囲を狭めるというのは、必ずしも悪いことではないと思います。やっている人たち自身が自分達のアジリティが高くなったことを実感し、もっとそれを高めていこうと、自分達で考えていくことが意味のあることだと思います。