サービスを開発していると、大量の「あそこ直しときたいけど優先度高いのあるから後回しだな」という作業に追われることがありませんか？デザイン面では微妙なレイアウトのズレとか、表記の揺れとか、プログラムの面では実用上問題ない些細なバグがとか、そういうものが後回しにされる。
すべての社会人は、新人の時に「優先度の高いタスクを先にしろ」と教えられたし、それを実行しているはず。ところがWebサービスの開発では、それが結果として大きな問題を作り出してしまいます。
一見して、優先度の低い問題であっても、対処しなくてはいけないことがあるのです！
「割れ窓理論」ってなに？
1990年代のニューヨークでは、犯罪発生率は劇的に下がりました。重大犯罪がこの期間アメリカ全土で28%減少したのに対し、ニューヨークは56%以上も減少したのです。この短い間に、ニューヨークの犯罪発生率は、なぜこれ程に大きく落ち込んだのでしょう？
ニューヨーク市警が相当厳しい取り締まりを行ったのでしょうか？違います。地下鉄のラクガキを除去したり「割れた窓」を直したりして街を綺麗にしたのです。それが、街全体の安全に繋がり、犯罪が減少したのです。
建物の窓ガラスが割れたまま放置すると、住民もゴミを捨てるようになり、治安が悪化し、より重大な犯罪が発生してしまう。この「割れ窓理論」は、アメリカの犯罪学者ジョージ・ケリング氏が提唱し、ニューヨークの犯罪発生率の低減に大きく貢献しました。
軽犯罪は許してはいけません。新たな軽犯罪を許すことになり、結果として殺人レベルの重犯罪を生み出すことになるのです。
サービス作りにも割れ窓理論を！！
ピクシブのサービス「pixiv FANBOX」では、この割れ窓を防ぐ仕組み作りにチームで力をいれて取り組んでいます。
チームでは、タスク管理ツールにTrelloを活用しています。そしてこのTrelloには「割れ窓リスト」と呼ばれるタスクがあり、軽犯罪な問題が列挙されています。
これを、週1回「割れ窓デー」という会を設け、対策をしていきます。具体的には、こんなことをやっています。
1. 全員で30分ほどサービスに触れて割れ窓やバグを探す
メンバー全員が、今やっている作業をやめます。実際に触ってみて、仕様の面、機能の面でおかしいところを探します。割れ窓探しです。
2. 現状判明している割れ窓タスクが妥当かどうか議論する
割れ窓が見つかっても、割れ窓自体に優先度を与えなくてはいけません。今なおすべき割れ窓なのかどうかを議論し、なおすべきかどうかを議論します。
3. チームメンバー全員で集中的にタスクを片付ける
なおすべき窓が決定したら、全員で集中して直します。ここも、メンバー全員で実施します。
割れ窓をなくすとどうなるのか？
割れ窓デーは丸一日を費やすことになるので、重要なタスクをさばくリソースが減ってしまいます。しかし、減った分を補うだけの十分なメリットもありました。
- 小さな問題が積み重なって引き起こされる「全体的なクオリティ低下」という重犯罪はなくなった。
- 割れ窓のない状態で開発に関わるため、チームメンバー間でサービスの正しい状態が共有され続ける状態になった。
- 開発作業時に、デザイン崩れや些細なバグといった軽犯罪に踊らされることがなくなり、「どのような仕様が良いか」「どうすればユーザーは喜ぶか」といった、自分たちがやるべきクリエイティブな活動に集中できるようになった。
実際に、些細なバグに踊らされていたエンジニアも、割れ窓のない世界では「このボタンの色、おかしくないですか？」と、自分の領域以外の課題にも目が行き届くようになりました。特に、新規開発中やリリース直後あたりは、些細なタスクを多く抱えてしまいがちです。こういう時こそ、割れ窓に注意しなくてはいけません！
ピクシブでは、放置されがちな小さな問題を「割れ窓」と呼んでいます。エンジニアたちを些細な問題に頭を使うことから解放することができる「割れ窓理論」、あなたのチームでも試してみてはいかがでしょうか？
