割れ窓理論 vs スタートアップのプロダクト開発
「割れ窓理論」をふと思い出した
エンジニアという職業からしばらく離れ、今は施設管理をしているなかで施設のクオリティに関する意見をもらった。
それを元に私の考えを整理すると、施設の一つ一つの「モノ」に対するあるべき姿の基準が低かったんじゃないかなって思った。
で、なんで低いんだろうと思って考えていたときに、スタートアップでのプロダクト開発経験がもしかしたらその基準を下げていたのかもしれないと思ってきた。
その基準が下がってしまった理由は何なのかと言うと、おそらく「割れ窓理論」にたどり着きそうってだなってことで、スタートアップのプロダクト開発が「割れ窓理論」とどう向き合っているかを整理して書きます。
プロダクト開発における「割れ窓理論」
「割れ窓理論」とはだいたい以下の内容。
「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」との考え方からこの名がある。
プロダクト開発において、エンジニアがこれを意識しなくてはいけないのは「達人プログラマー」でも言われている。
いわばプロダクトは家と同様で、誰かがちょっとしたルールを無視してコーディングをすると、他の人もそれを見てルールを無視し始め、やがてプロダクトの品質が落ちていく。
そこで最近では、Lintなどでコーディングルールを厳しく敷くことができるので、ある程度強制的に守らせる事ができる。そう、達人じゃなくても品質は守っていけるようになってきている。
ただ、スタートアップのプロダクト開発では、このコーディングルールはどこまで守るべきなのか？を考える必要が出てくる。
スタートアップのプロダクト開発は窓が割れてていい
結論から言うと、スタートアップに限らず、初期のプロダクトにおいては窓が割れてていいと思っている。
理由はスピードが大事だから。
ルールを厳しくしていくと、完成したあとにルール違反で修正したり、思わぬ修正によってロジックを修正することも中には出てくる。
結果、時間がかかり、リリースが遅くなる（ことがある）
なにより、新プロダクトがどれくらい事業インパクトがあるのかを検証しないといけない。これは会社全体からみたビジネスの文脈。
インパクトがなかったらどうするか？
問答無用でそのプロダクトの開発は終了する。
だから、はじめは窓が割れているくらいのプロダクトで十分だと思っている。
「割れ窓理論」は次のフェーズから
じゃあ、いつから「割れ窓理論」を意識し始めるかと言うと、おそらくだけど、開発者の人数が３，４人になってくるくらいから。
２人くらいであれば、お互いのソースをレビューするから、ある程度クオリティやルールなどは擦り合っていると言うか、阿吽の呼吸でどうにかなっていくと思う。
しかし、３人以上になると、お互いにレビューするようなことがなくなり、どんどん認識がずれてきて、最終的にプロダクトに致命的なバグが出始める。
バグが出始めると、「テスト書くようにしよう」とか、「実装後にちゃんとテストしよう」とか、「masterに直接プッシュはやめよう」とか出てくるんじゃないかな。
そこで、徐々にプロダクト開発におけるルールが敷かれていくと思う。
施設の基準について
プロダクト開発とは違い、施設に関しては基準は常に高いほうがいいなと思った。
「プロダクトは動いていること」が価値であり、それに対して施設は「気持ちよく、快適に過ごせること」が価値であるはず。
「気持ちよく、快適に過ごせること」は日々の小さな努力と気配りで向上できるなと思う一方で、「割れ窓理論」視点で言うと、少しでもサボったりすると、そこを中心に基準が下がっていき、気がつけば価値の低い施設になってしまう。
なのでそこは注意した上で、今後の施設を管理していきたい。
最後に宣伝
沖縄でGeekHouse沖縄を運営しております！
エンジニア業務に没頭できるようなディスプレイや書籍などが揃っている宿泊施設になってます！
これから内地は寒くなってきますが、沖縄は年中温かい気候で過ごしやすく、すぐにいっぱいになってしまうのでお問い合わせはお早めに！
この記事が気に入ったらサポートをしてみませんか？