【開発】アプリ開発の終盤に炎上してしまうよくある流れについて
開発序盤では和やかなのに終盤は鬼気迫る感じになってしまう、そんな開発の序盤・中盤・終盤のあれこれをざっくりと書いてみるそんな投稿です。今回はスマートフォンアプリの一例を紹介になります。
目次
序盤
「僕・私の考えた最高のゲーム」を作るためチーム編成や技術的な検証を必要とするフェーズ。比較的ゆっくりした時が流れる。検証時間もきちんと取れることが多い。終始和やかなムードで、とりあえず２、3人で進める。それこそお互いに「ええやんこれ」みたいな、遠くから見ると「良さそうな組織」に見える。企業紹介に写真はもしかして、この時期に撮影されたものなのではと疑いたくなる。この時点で仕様書の様なものはまず無い。なんとなくのイメージだけ。
中盤
初期の検証などを経て、仕様が徐々に固まりだす。草案の様な仕様書が上がる。これを出来ていると言ってよいものかは、また別の話。プログラマは検証結果を元に量産体制へ向けて、ツールやら何やら作成していたりする。量産体制になりつつあるため、人が少し増えたりする。
終盤
リリース3か月前に突如、仕様変更の話が湧く。そう、本当にどこからともなく湧く。変更内容を例えるなら「10階建てのビルを建設中なのに50階建てに変更、まぁ階数が変わるだけでしょ」みたいな。結構大げさでも無くて、元の形を留めていないレベルに発展することがあります。
そんな事態に困惑するプログラマをよそに、 プロデューサーやプランナーは盛り上がっている。彼らの脳内ではそれはそれは素晴らしい夢が広がっているのでしょう。広がっているのはどこで括るかの区別もつかない風呂敷だけ。仕様変更に対する工数の再見積もりは行われず、残された期間も短いため突貫工事による対応を迫られる。
ある日突然、天からの声が降り注ぎ「人を増やせばどうにかなる」という頭数理論であれよあれよと人が増える。増えた人は当然状況を把握していないため、元々のメンバーに様々なコストが発生する。少なくとも管理者1名の作業は止まる。突然入った人がヒーローならばこれもアリだが、そんなことは稀である。場合によっては嫌気がさし辞めてしまう人も現れる。気づけば毎月現場から人が数名ずつ減っていく状況が生まれ、残されていく現場。生き残りをかけた死闘なんて言い方をすると格好良いかもしれませんが、ただの消化試合。
まとめ
再見積もりの大切さを確かめる良い機会になりました。一点、突っ込みを入れるなら、そもそも人が読めるドキュメント(草案)も無いままプロジェクトが進行しているのは何故なのか？。偉い人の視点からしてみれば「なんでもいいから早く結果を出せ」なのでしょうけれど、最後には痛い思いをするのは自らということに気づいた方が良いですね。