IT業界の開発フロー
ウォーターフローvsアジャイル
私はこの論調が嫌いです。
どちらも一長一短で、比べるべき対象ではないからです。
お疲れ様です。
今日はIT業界の開発フローについて書きたいと思います。
ここでの開発は、業務アプリケーションとします。インフラや非機能系の要件は固まっている状態で話をします。
業務アプリケーションを作る目的は、作業効率の向上や誤りを防ぐなど様々でしょう。
こんなふうに出来たらいいなぁ、いや、こうあるべきだ！と色々揉めるのですが、最終的には使用するユーザーの使い勝手や業務都合により要件は固まってゆきます。
従来の開発フローとして今もなお様々なプロジェクトで実施されているウォーターフォール型開発は、要件が覆らなければ素晴らしい手法だと考えます。
要望を汲み取って、要件をしっかり整理して、要件漏れが無いよう出来上がりの製品に反映することが目的なのですから、素晴らしいに、決まっています。
ただし、全ての開発においてこれを適用してしまうとコストがどうしても掛かります。
また、現代ではトレンドやニーズの流れが圧倒的に早いので、作り終えた時には既にブームは終わっているなんてこともざらに出てくるでしょう。
ウォーターフォール型の開発手法における最大のデメリットは、やり直しが効かないことです。
上流工程で決められた要件が覆れば、下流の作業は全てやり直しとなります。
上流でしっかり要件を固めて、覆る要件が少なければやり直しコストは軽減(ゼロも目指せます)できます。
やり直しのコストも全てひっくるめて見積もりをしなければならないので、見えないリスクが沢山潜んでいることになります。
それに対してアジャイル開発とは、要望をキッチリ設計書に落とし込む前に試作機を作り、出来上がりのイメージをユーザーと共有しながら進める方法です。
この開発手法に向いているのは画面やユーザーエクスペリエンス系です。
操作の感触を確かめてもらい、認識齟齬を無くすことが主眼です。
アジャイル開発に設計書は不要などという方がいらっしゃりますが、それは嘘です。
開発したことがない人が勝手に謳っているだけだと考えてください。
(誰とは言いませんよ、誰とは。)
画面上の見た目などは不要かも知れませんが、ロジックやデータフロー、ERなどは絶対必要です。イベント処理もそう。
設計書はユーザー用には百歩譲って不要かもしれませんが、開発する上でも、エンハンスしてゆく上でも作成は必須。メンテナンスも必要でしょう。
一概に、どちらが良いかという議論は不毛で、適材適所で合う開発手法を取り入れるべきでしょう。
昔ながらの開発標準や、規約は今の時代では無用の長物で、常に新しい手法を組み入れるべきです。
私が独断でアジャイルとウォーターフォールで振り分けた開発対象を記します。
→EC、HP、キャンペーン、PRなど早さを求められるウェブサイト開発
業務アプリケーションもユーザーが操作するような画面は向いている。
パブリッククラウドを利用したサービス全般は向いている。
(業務ロジック、ERは別)
→バッチ処理。業務ロジック(特に計算まわり)
システム間連携など、関係者が増えるもの(ネットワーク構成やデータフローを検討しなくてはならないもの)
ジョブ等で連動してデータを作り込む処理など。
最後に。
開発手法はそれぞれ合う形でカスタマイズすることが重要です。
メリットを活かしつつ、デメリットを顕在化させない仕組みづくりをつさすることで、より良い開発サイクルを回すことが可能です。
では、今日はこの辺で。
明日は要件が固まらないのはなぜ？
を綴ります。
