Murga

個人的に言いたいコト・主張・気持ち。

割れ窓理論

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

割れ窓理論。割れた窓を放置していると、大きな犯罪、無秩序な環境が生まれる、という言葉。

  1. 建物の窓が壊れているのを放置すると、それが「誰も当該地域に対し関心を払っていない」というサインとなり、犯罪を起こしやすい環境を作り出す。
  2. ゴミのポイ捨てなどの軽犯罪が起きるようになる。
  3. 住民のモラルが低下して、地域の振興、安全確保に協力しなくなる。それがさらに環境を悪化させる。
  4. 凶悪犯罪を含めた犯罪が多発するようになる。

最初はただ窓が割れていただけなのに、「あの窓割れてるし、ココでは綺麗にしてる必要もねえよな」というモラルの低下が、ゴミのポイ捨てから窃盗を生み出すということだ。


同様のことは職場やシステム開発にもいえる。

  • オフィス全体が乱雑としている環境では、資料の出来も「こんなもんでいいや」と投げやりになる
  • 汚いコードが放置されているシステムを改修するのなら、自分のコードもこの程度でいいだろうと思う

いずれも、「そうなってもらっては困る」ことなのに、「でもオフィスが汚いのはこういう理由で…」とか、「このコードは忙しくて仕方なく…」とか、言い訳する。それが原因になってるんだって言ってるのに。

過去に言い訳しても何も良くならねえんだよ。ダメなもんはダメなんだ。今直せ。

ソフトウェアの「割れた窓」、つまり「悪い設計」「間違った意志決定」「悪いコード」を放置してはいけません。
ソフトウェアをごく短期間で腐敗させることになります。
「割れた窓」が何枚かあるだけで、「残りのすべてのコードもガラクタなんだから、自分も適当に作業してしまえ」という考え方が忍び込みやすくなるのです。

割れ窓を直す

窓を割るような奴は、やがて割った窓から泥棒に入り、ひいては人殺しをするような極悪人になる。だから、窓を割るような器物損壊をしている内に、殺してしまえ

自分の作った歌の中で「盗んだバイクで走り出す」「学校のガラス窓全部割る」などと書いている尾崎豊は、犯罪教唆をしており、割れ窓理論に従えばこれも死刑である。というか、尾崎は晩年ヤクに手を出しており、もはや言い逃れできない。一説によると尾崎の死因は割れ窓理論の信奉者達による暗殺ではなかったかと言われている。尾崎は膨大な信者がいるが、これらの信者も犯罪者の卵ということになる。割れ窓理論に準拠すれば、彼らも粛清しなければならないことになる。一体何人の人間が地球上から抹殺されるのであろう。

一挙手一投足が粛清の根拠となり、常に怯えて生活してゆかなければならない。それでも良い、という人だけが、割れ窓理論を賛美し、割れ窓理論に基づいた法治を是認するべきである。

アンサイクロペディアからの引用は極端だが、割れ窓理論を知って、「最初に窓を割るようなヤツを許すな」という考えに至るのは自然な考えだろう。

ここで大事なのは、「一切の窓を割られないようにしよう」、つまりどんなに軽微なものでも一切のルール違反をさせないようにしよう、という考え方で施策をとるのは、大抵失敗する、ということだ。

窓を割られないように予め取り締まると、窓を割ることに怯えて皆何もしなくなる。

ダメなことはダメだと周知することは必要だが、割ってしまった人を厳しく処罰するのではなく、窓が割られたらすぐ直す・窓を割られていない状態を保つことが先決だ。

「ココにポイ捨てをするな!」と厳しく取り締まり、そこを無人の土地にすれば、ポイ捨てはなくなるが、ポイ捨て以外のものも全てなくなる。そうではなく、ゴミがない状態を保ち、ポイ捨てする人を目立つようにすれば良い。そうすれば自然とポイ捨てしている人は皆の目に止まり、そういった人間は皆から自然と淘汰されていく。処罰するのは、それでもポイ捨てを続ける肝の据わった奴だけで良い。

「割れた窓」をそのままにせず、発見と同時にすべて修復します
逆にコードが清潔で美しく保たれている場合、開発者はそれを汚さないよう細心の注意を払うことになります。
コードを汚してしまう最初の人間にはなりたくないと思うからです。

参考

カーゴ・カルト・プログラミング

システム設計の謎を解く 強いSEになるための機能設計と入出力設計の極意

システム設計の謎を解く 強いSEになるための機能設計と入出力設計の極意

カーゴ・カルト・プログラミング。

実際の目的には役に立たないコードやプログラム構造を儀式的に含めておくプログラミングのスタイル

 

カーゴ・カルトという語句は、元々は第二次世界大戦後の南太平洋で見られた先住民の宗教に由来している。これらの人々は、戦時中素晴らしい積荷をもたらしてくれた神のような飛行機を呼び出そうと、一心不乱に精巧な飛行機の模型や滑走路を作り上げた

 

転じて、背景にある仕組みを理解せずに行動を過剰に(そしてその多くは無意味に)繰り返し実施すること

もっと平たくいうと、「○○するためのおまじない」などといって無秩序に放り込まれる (実際は無意味な) コピペコードだったり、誰かの勘違いから広まった不必要な処理を真似して増殖していったり。

/**
 * 引数の HogeDto の更新日時を書き換えて UPDATE 処理を行う
 * 
 * @param hogeDto 更新対象の DTO
 */
private updateHoge(HogeDto hogeDto) {
  // HogeDto の初期化
  HogeDto newHogeDto = new HogeDto();
  // 引数を取り込む
  newHogeDto = hogeDto;
  
  // 更新日時の変更
  newHogeDto.updated_at = new Date();
  // UPDATE する
  boolean updateResult = HogeDao.update(newHogeDto);
  
  return updateResult;
}

前職で見ていた泣きたくなるコードを真似してみた。こんな書き方をするなら、「HogeDto の初期化」で生成された new HogeDto() には何の意味があるのだ?


カーゴ・カルトなコードが生まれる現場では、カーゴ・カルトな設計書も生まれがちだ。大抵はプロジェクト全体に「無意味な慣習を守らせる宗教」が蔓延していることが、カーゴ・カルトの原因だからだ。

例えば、本当はある一部の条件下で、前後の文脈が揃って初めて必要になった対処法を、「全ての場面でやらないといけない初期処理」とみなして取り入れてしまったり。前述の new HogeDto() は、自分が実際にコードレビューで「初期化を必ずしてください」とツッコまれたものなのだが、恐らくレビュアーの知見の中では、それが必ず必要なものになってしまっているようである。以前に何か代入忘れなどでぬるぽでも引き起こしたのだろう。

しかしこうやって無意味な慣習が蔓延していると、「いやいや、次の行で同じ変数に代入してるし、最初の初期化いらんでしょ」という反論もする気がなくなる。もしくはその反論が理解されず「とにかくそうしろ!結果は正しく動いてるんだから!」と怒られたりする。こうなると「もうこの現場は適当でいいや」とモチベーションが下がる。

もしくは知識が少ないメンバであれば、その指摘をよく考えもせずただただ鵜呑みにして「どうやらそうするのが良いらしい、自分も守ろう、皆も守ろうね」と、新たな布教者になってしまうのだ。

厄介ごとを避けようという方針は困ったものだ。なぜなら、言語をマスターするにはその言語のすべてを知らなければならないし、恐れたり逃げたりすることは知識を得ることの妨げになるのだから

「知らないままでいいや」と思うことが間違いなのだ。どれだけ面倒でも情報量が多くても、全てを知らなくてはならないのだ。大体それで金もらってんだろ適当な働き方すんなボケ。


以下の記事では、「OJT とカーゴ・カルト」という視点でも検証している。

つまり、OJT により引き継がれる「現場の知識」とやらは、無意味なノウハウや間違ったやり方が多分に含まれているよ、ということ。教える側が既に体系的に学習した内容ではなく、現場の場当たり的な「実践知識」をベースにして話をするので、皆のインプットがそれだけだと、代を引き継ぐうちに知識はどんどん劣化していく。

この劣化のスピードは、少なくとも現場にいる当人にはなかなか認識しづらいゆっくりとしたもので、本人が常に危機意識を持っていないとなかなか変えることはできない。なにせ「その場では何とかなっている」からだ。そうこうしているうちに、効果のない呪文にまみれたコードの中で、さらに効果のない呪文を唱え続ける事態に遭う。

だからこそ、世界のオープンソースを見たりして勉強し続ける必要がある。

小さなステージで満足しないで、広い世界に目を向けていけ。

参考