「小さく始める」ってんで「最小の機能だけとりあえずまず実装する」ってやってるところが多いけど、それって自分が完全なコントロールを持っていて、かつそのサービスが「育たない」ときだけ、なんだよね。
現実問題として、社長に「こんなサービス作りたいんだよね」といわれてちゃちゃーっと最小の機能だけ実装して見せると、十中八九、その社長は「完成した気になってる」。
売り込み始めちゃうんだよね。
で、クライアントがつく。
こんな機能が欲しいと要望があがってきて、新機能追加の圧力がどんどん高まっていく。
その裏で、クライアントアカウントの設定が手作業とか、DBのマイグレーションが手作業とか、ローカルだけで開発できなくて、クラウドのサーバを取り合うとか、クラウドの環境もその場その場で何となく作ってみた、なノリなので開発環境を増やそうとしたらやたら使いづらくなったり。
そこは運用でカバー
できません。
設計も実装もいけてないまま行軍は続き、障害が発生しまくって社長は発狂するし、クライアントは呆れて離れていく、障害対応が続いて鬱になる技術者は増え、どんどん離職していき、そして誰もいなくなった、となる。
「小さく始める」っていっても、全体設計はちゃんとやらなきゃならないし、アカウント追加などの日々の運用の自動化やクラウドの開発環境の複製、自動テスト、ローカルで閉じられる開発環境とかとか、実装開始前に越えておかなきゃならない山はいくつもある。
小さく始めるのは実装だけであって、↑の項目を最低でも見通しを立てなければならないというのは、サービスの開発を含めたライフサイクルを考えたら当たり前のこと。
新機能開発しながら再設計、実装差し替えとか、空を飛びながらエンジンの取り替えするようなもの。工場にいる間にちゃんとしたエンジンを取り付けておけばそんな無茶しなくてすんだのに、って話になる。
それでも取り替えられたら御の字で、取り替えられずに惰性で飛んでいる間にVer2を飛ばさなきゃならないとかいう事になる。
と言ったふうに、「設計などなどは後で考えればいい」とか、「後でリファクタするからとりあえず」とかは、自ら詰まれにいくようなもの。
おいらがヘルプで入る現場、現場、ことごとくそんな感じ。
ましてや、フルで実装したら大変そうだから単純なパターンだけで小さく実装するなんて意味ではない。
ちゃんとフル実装を見通した上で実装しないと、その機能がポシャれば幸いだが、気に入られて「本格的に」となったら、99％詰む。
今の現場、新しい機能が詰みそう……。
同じ間違いを何回繰り返せば学習するんだろう？