開発プロセスにこだわってしまう罠。それよりも組織を変える必要性

 開発プロセスにこだわりすぎて開発がうまく進まなかったという経験があり、一方でその後きたCTOによりCEOを開発会議から外し、開発チーム＋PdM(ビジネス層代表)と開発チームオンリーの会議の2つに分けて会議体を作ったことで見事ビジネスと開発を分けて疎結合にしたということがあり、なるほどと思ったことがある。

それまでは私が開発プロセスを何とかして上手く動かしたかったのだが、全然上手くいかず困ったので記録を残しておきたい。

開発プロセスは大きく分けるとアジャイルとウォーターフォールがある。

ウォーターフォールはSIerなどベンダー企業がユーザー企業から依頼を受けてシステム開発をする際にソフトウェアを工業製品に見立てて、製造業のプロセスをそのまま当てたことで始まったとされている（確かではない）。

それだと上手くいかないよねということで2000年代からアジャイル開発が考案されて、以降、シリコンバレーやWeb業界ではアジャイル開発が主流となっていた。その中でもXP開発やスクラム開発などあり、私が前いたベンチャーではスクラム開発を基に開発を進めていた。

スクラム開発はガチガチにやろうとすると開発が遅くなる。このスクラム開発をガチガチにやろうとし過ぎて、開発者たちからは反感をくらい、経営層の要望を上手く開発に落とし込むこともあまりうまくいかずにとても四苦八苦したと思っている。

ビジネスの要望ばかりを叶えようとしてシステムの重要な要件を満たせていないということがあり、ずっとその会社ではシステムの要件を満たせていなかった。そのため、技術的負債が溜まりに溜まっていた。

システムの重要な要件というのは、運用の自動化やしやすさ、パフォーマンス性、変更容易性、セキュリティ、コスト最適化、スケーラビリティ、信頼性など。

参考：AWS Well-Architected

ベンチャーの経営者はわがままである（『経済評論家の父から息子への手紙』著 山崎元）。

どこのベンチャーも多分そうで、相当ソフトウェア開発に力を入れている企業でなければ（個人的には、例えばLayerＸ、カミナシなど）、多分どんなベンチャーだって経営者は必死で企業を利益を立たせるために開発者にベンチャー精神を要求し、システムは崩壊している。

参考：開発者体験が良いイメージの企業

ビジネスと開発はある意味グラデーションのように仲介を挟まないと直接ビジネス要件を満たそうとしてえらいめにあう。あるいは開発組織が飲まれているのが実際だと思う。

参考：Cultural Capital Theory in Software Engineering

ベンチャー企業に入り開発プロセスを固めようとしても上手くいかず、CTOが入り、社長が会議に入らないようになってから開発が上手く回り始めたことも目にして、開発のプロセスにはこだわらず、組織構造を変える必要があると思った。

開発プロセスをこだわろうとしても多分ほぼ何も整っていないカオスなベンチャーでは無意味で、経営層に対等に話せる立場が必要、もしくは開発者たちが強くビジネスの要望に対してPdM、PMの意識を持って接することが大切だと思った。