プラクティスは手段でしかない--アジャイル開発の本質を再考する - (page 2)

吉原庄三郎 (ウルシステムズ)

2015-09-28 07:00

 だからこそ、作り手は作っているモノが顧客の希望を満たしているか早い段階で確認する。マイホームを建てる時、建築家は模型を作って施主と完成イメージをすり合わせる。着工後も工事途中の建物を見せて希望を満たしていることを確認してもらう。

 こうした取り組みはウォーターフォールでも行われてきた。実際にプロトタイプを開発したり、画面のモックアップを作成したりして発注者と開発者との間で完成イメージを共有しようと努めてきた。

 しかし、限界があったことも事実だ。大規模なシステムの詳細なイメージをプロトタイプで共有しきることは難しい。ウォーターフォールの開発期間は年単位であることも珍しくない。仮に正しくプロトタイプでイメージを共有できたとしても、開発期間中にビジネス環境が変化してシステムの要件が変わる可能性がある。

 アジャイル開発はこうした課題を解決するために編み出されたものだ。アジャイル開発では、超短期間に実際に動くソフトウェアを見せて顧客のフィードバックを得る。超短期間とはおおむね数週間を指し、2週間が理想的であると言われている。顧客が仕様を提示して、2週間後に実物が完成するのであれば仕様の認識齟齬による手戻りは極小化できる。

 ウォーターフォールではどうやっても達成できないほどの超短期間で動くソフトウェアをリリースし続けること。開発とフィードバックのサイクルを限りなく短くすること。それにより、ビジネス変化に素早く対応すること。それがアジャイル開発の目指すところだ。

 現在、アジャイル開発はバズワードになってしまっているが、本質的には受注生産に古くから潜在している問題を極めて合理的に解決するための手法なのである(受注生産というと外製を連想するかもしれないが、内製においても業務部門と情報システム部門の関係において仕様の食い違いの問題は存在している)。

 超短期リリースを実現するための手段として考案されたのが各種のアジャイルプラクティスである。アジャイルプラクティスは今でも新しいものが次々と登場している。しかし、あくまでプラクティスは手段。それらが何を目指しているのかを把握することなしには、真価を発揮することはできないと肝に銘じておきたい。

 次回は、アジャイル開発を支える重要概念である「自己組織化」について解説する。

吉原庄三郎(よしはら・しょうざぶろう)
ウルシステムズ 主席コンサルタント、アジャイル推進室
ウルシステムズでITグランドデザイン、プログラムマネジメント、開発運用プロセスデザイン、上流工程のコンサルティングを提供している。
著書に「はじめての設計をやり抜くための本」(翔泳社)がある。

ZDNET Japan 記事を毎朝メールでまとめ読み(登録無料)

ZDNET Japan クイックポール

マイナンバーカードの利用状況を教えてください

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]