SIにおけるアジャイルとかウォーターフォールとか

取材を受けないとブログを書けないのは問題ですが、@ITの「特集：DevOpsで変わる情シスの未来」というのの第5回で「DevOpsというバズワードに流されないために」という話をさせていただいたので紹介を。

特集：DevOpsで変わる情シスの未来（5）：DevOpsというバズワードに流されないために (1/4) - ＠IT

弊社も当然、最初は顧客企業の業務のことをよく知りませんから、会話を軸に業務を理解し、顧客企業との共通理解という土台を構築する作業から入ることになります。従って、そこではアジャイル開発は行いませんし、行うべきではないと考えています。ウォーターフォールで始めて、まずは満点ではなく合格ラインのシステムを作ることで共通理解の土台を固めます。その上でアジャイルに移行してスピーディに改修を進めるといったケースが多いです。

というあたりがポイントかと思います。

「顧客の求めることには永遠にたどり着けない」という現実と「手法としてのプロジェクトマネジメントには明確なゴールが必要」という現実があって、その落としどころとして「小さく繰り返しゴールを定める」というアジャイル開発方法論が生まれました。

これ自体は素晴らしいアイデアですが、一方で「アジャイルでは繰り返し可能な土台があるかというのが成否を分ける」という現実も生まれました。保守フェーズにおいてアジャイルが有効なのは、この土台がしっかりしているためだというのは言うまでもありません。

SIにおいては保守フェーズだけではなくて新規開発もありますから、どうしても土台がない状況がありえます。そういった場合には「共通の土台を作るまでは迷うことなく進める」というのが必要となります。その場合には60点とか80点を取れるようなところまでゴールを定めることが重要であり、そのうえではウォーターフォール的な進め方が効率的です。

繰り返し言っていますが、ウォーターフォールでもアジャイルでも、別に名前なんかどっちでも良くて、

アジャイルやDevOpsを「開発プロセスの話」とか「運用のツールの自動化の話」といったように解釈せず、企画、開発、運用、フィードバックという一連のサイクル加速へのビジネスニーズがある、という背景に目を向け、そのためにDevOpsやアジャイルという手法が大事だと考えることが大切です。手法ばかりを見て矮小化して捉えてしまうことなく、トレンドの裏側にある本質的なことは何かを見据えることで、これらの言葉をあらためて理解できるのではないでしょうか。

ということで、ひとつよろしく。