承認してもらって進める、みたいなプロセスが必須だとなかなかウォーターフォールから離れられないですよね。
この先も数年は開発方式が変わらない予感がするディレクターの小宮です。

開発手法として「アジャイル」で進めることがアメリカなどでは当たり前になっていますが、国内に目を戻すと割合は逆転しているようです。
大手の制作会社でも、受託案件をアジャイルで開発しているよという企業はなかなか耳にしません。

アジャイルの手法はアプリやWeb開発では非常に理にかなったものだと思いますが、なかなか浸透する様子が無く…
そもそもなんでアジャイルにしないの？という理由を大きく3つにまとめてみました。

理由１：アジャイルをよく知らない

だいたいの理由がこれです。
開発会社だけでなく、発注元の担当者様にもご協力をいただかないと実現が難しい手法なため、そもそもアジャイルという手法を認識していないと体制を構築する段階でつまづいてしまいます。
いつまでにリリースしたいという期限がある中で、アジャイルっていうのはこーいう仕組みで〜なんて勉強している時間の猶予は無さそうです。
プロジェクトのオーナー様も開発パートナーも、全体が共通認識を持っていないとまだまだ実現が難しいです。

理由２：アジャイルでの成功事例がない

次いで多いのがこの理由です。
知識として開発手法を知ってはいても、実際にやってみたことがないために踏みとどまる。
ウォーターフォールは長年採用され続けてきた手法であり、フローも明確ですので別の開発手法に乗り換えるのは相当な決断となると思います。

過去の成功体験にとらわれ続けていると時代の変化に乗り遅れる。
なんて言われたりしますが、それでもやっぱり「失敗したら…」みたいなのが脳裏をよぎりますよね。

理由３：ウォーターフォールでも明確な問題が発生していない

別に問題が起きていないのだから乗り換える必要が無い、というのが乗り換えない最後の砦と言えます。
業務プロセスを変更するのはかなりのパワーを必要とします。

明確なリスクが発生しているワケでもないのに慣れ親しんだ手法を変えるなんて、むしろそっちのほうがリスクですよね。
変えてみて、失敗したら嫌だし。

まとめ

よく知らないし、やったことないし、いま困ってない。
なので今までのやり方を変えるのは難しいというのが、特に承認プロセスの多い企業様では課題のようです。

速攻で開発してストアに公開して、競合他社よりもなんとかして先にシェアを確保していこう。
なんていうことをどんな企業も考えるとは思うんですが、それこそまさにアジャイルの出番だったりします。
どこかのタイミングではぜひ取り入れて欲しいですが、国内的に大きく変わるのはまだ少し先の未来のように感じます。