書いた内容のまとめです。元ツイートいくつかのツイートがこのスレッドに続いています。皆さんは割れ窓理論の本質がなんであるかご存知でしょうか。私は「軽微な犯罪も徹底的に取り締まること」が「凶悪犯罪を含めた犯罪を抑止できる」という点に集約されるのではないかと思っています。上の文言そのままなんですが。割れ窓理論ゼロ・トレランス政策と限界効用の逓減性ニューヨークではゼロ・トレランス政策として実行され、実際に犯罪現象の成果が現れたそうです。一方で、その政策を実行した都市でもしなかった都市でも犯罪の発生率は同様である、という批判もあるようです。いうことを踏まえて、私は割れ窓理論については懐疑的な立場です。直感的にゼロ・トレランスがダメだな、と思うのは、あらゆる施策の効用には逓減性があるはずだからです。限界効用逓減の法則というのは大学の一般教養でとった経済学史の授業で習ったはずですが、まぁ日頃使わない知識は当然忘れますよね。さんのこの記事を読んでから最近強く意識しています。放出系を習得してから、自分が具現化系だと判明しました。修行をやりなおすべきでしょうか?この記事ではあらゆるスキルには逓減性があり、あるひとつのスキルを伸ばせば伸ばすほど、それより先に伸ばすのはより大変になる、だから必要に応じて別のスキルも伸ばしていこう、といったことが書いてあると私は理解しました。深津さんが本当にそのような意図でそれを書いたかは私にはわかりませんが、少なくともそう考える私が今ここにいるということだけは確かなことだと言えそうです。我思う、ゆえに我あり。して働いているので、ある種のポジショントークです。本質は「計測に基づく継続的な改善」だと考えています。いうのはサイトの信頼性を測る目標値です。しよう、というものです。未満のどこかにするということです。目指してしまうと、そのために必要なコストが無限に膨張するからです。動いているわけではありません。信頼性というのはいずれにせよ無理なので、適切な目標を決めてそこを目指そうというものです。ここにも、限界効用逓減の法則が見えますね。割れ窓というアナロジーソフトウェア開発の文脈において、割れ窓理論の引用はよく見ます。面倒なのでエビデンスは示しません。私はそれを勉強会やカンファレンスの発表やブログ記事等の中で幾度となくそれを見てきた気がする、ということをここで強く主張しますが、それをあなたに押し付けてもしょうがないことです。なんでこんなによく見るのか、というのを考えると、私はこの「割れ窓」というアナロジーがわかりやすくて魅力的だからではないかと考えます。窓が全く割れてない学校と、半分ぐらい割れてる学校とを比較して、夜の校舎窓ガラス壊してまわる上でどちらが心理的障壁が少ないか、を考えると想像しやすいんじゃないでしょうか。真っ白なものは汚したくなるタイプの人にとってはゼロから窓を壊していく方がより大きなカタルシスを得られるはずです。効用が逓減していない最大の状態だから。いえ基本的にはほとんどの人にとっては良識とかそのようなものがボトルネックになると私は信じています。話がそれましたが、例えば部屋を完璧に片付けて、最初の数日は明らかに「散らかしたくない」という力が自分の内面に働いた経験は多くの人にあるのではないでしょうか。どこかで堰を切って、いつの日かほぼ素の状態に収束するんですが。別にそんな経験無くたっていいんです。私はそれをあなたに押し付けません。「まぁ似たようなことは世の中色々あるな」ぐらいの気持ちで読み進めてもいいし読み進めなくてもいい。できないことを求めるのもやめにしよう。割れ窓理論についてここまで読み進めた方にはお分かりだと思いますが、私は別に割れ窓を減らすことについては何も否定していません。徹底的にやるのが間違いだということを言っています。割れ窓理論は徹底的にやることを目指したものである以上、それをソフトウェア開発の文脈で引用するのはミスリーディングではないか、というのがこの記事の主旨です。ソフトウェア開発における割れ窓との付き合い方がどうあるべきかまずは始めてみる割れ窓への対処は、ほとんどの場合において何かした方が良いでしょう。何もしていないというゼロの状態に比べて、ひとつ直した状態は効用が逓減していないので大きな効果があると考えられます。続けてみる実際には、何か新しいことを始める際には、それを始めるコストがかかります。エラーログをどこから追えばいいか、という情報を調べることから始まります。一回わかってしまって、次回以降その知識を使い回せるのなら、そこにかかるコストはゼロということになります。やるなら一つだけ直すのではなく、それを継続した方が良いでしょう。継続はリズムを生みます。ここまでであれば「割れ窓は直せば直すほどお得」ということにも読めてしまいますが、もちろんそうではありません。それでは割れ窓理論の本質である「徹底的に取り締まる」になってしまいます。一回性と覚悟あるときにアプリケーションのエラーログを調べる方法がわかれば、それについての知識は使いまわせても、別の時にはデータベースのログを調べる方法を知る必要があるかもしれません。割れ窓は多様なはずなので、それぞれごとの立ち上げコストがかかります。ある割れ窓に対する初回固有のコストは一回性のものですが、あらゆる割れ窓は連綿として立ち現れ、その度に初回固有のコストを払うことになります。終わりのない一回性の連続の中で日々割れ窓を直していく覚悟が求められます。計測とそのコストですが、人間の覚悟のあり方は人それぞれによって異なるはずですし、多分有限です。そこの覚悟を支え得るものとして、私は計測があると思ってます。「計測に基づく継続的な改善」をやればいいのです。計測にもコストがかかります。割れ窓理論が「徹底的に取り締まる」という結論になってしまったのは、結局のところ計測のコストの問題だったのではと思います。自宅の窓とそれが割れてる数を計測することはできても、スケールを区画、町、都市と広げていくと、どこかで無理になるでしょう。ここにも限界効用の逓減性が見えます。ソフトウェアにとって特徴的なのは、計測のコストが現実の世界に比べればめちゃくちゃ低いことです。一度計測の仕組みを作ってしまえば、その仕組みは自動的に動きます。いった枠組みで考えやすい対象については目標値を決め、計測に応じて必要な分だけ割れ窓を直せば良いことになります。未満のどこかである必要があります。これなら終わりのない一回性の連続を乗り越える勇気も湧いてくるのではないでしょうか。いった枠組みで考えるのが難しい対象についてはどうすれば良いか。妥協としての割れ窓バジェット計測が難しいのであれば、量を固定してしまえば良いのではないでしょうか。隔週で金曜日は通常の業務を原則ストップして、割れ窓を直すことに費やす、といった具合です。いった取り組みを行なっている会社はすでにいくつかあるようです。営業日を割れ窓を直すためにあらかじめ組み込むので、これはある種バジェットです。これはあくまでも計測のコストが高いことに対する妥協であるべきと考えます。いっても上記の企業の取り組みに対して批判しているわけではありません。alu.jp乗り越えられるべき存在としての割れ窓バジェット日々妥協の中に生きているとしても、同じ妥協に妥協してはいけないと考えます。これは善悪の問題ではなく、楽しさの問題として。人間は飽きる生き物なので、そのままではいつか絶対に割れ窓バジェットの運用は止まっていきます。それははだいたい少しずつうやむやに進み、どこかで突然に終わるものです。常にプロセスを改善し続けることだと思います。