bon now

割れ窓理論をご存知だろうか。こんなやつ。

軽微な犯罪も徹底的に取り締まることで、凶悪犯罪を含めた犯罪を抑止できるとする環境犯罪学上の理論。アメリカの犯罪学者ジョージ・ケリングが考案した。「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」との考え方からこの名がある。
https://ja.wikipedia.org/wiki/%E5%89%B2%E3%82%8C%E7%AA%93%E7%90%86%E8%AB%96

つまりなんかやべー状態が放置されていると、その軟化やべー状態が当たり前になってしまってしまうということである。 ITエンジニアをやってる人ならあるあるネタだと思うけど、例えば実装と差異のあるドキュメント・テストコードや、優先度を見直すことなく放置され続けた優先度「高」のバグ課題。。。これらが割れ窓理論の代表格ではないだろうか。
まぁ割れ窓理論も統計的に賛否のある理論ではあるので正しく理解することは難しい。ただ事実としてヤバい状態が常態化することは稀によくあるのである。 参考: https://togetter.com/li/11144

割れた窓の修復方法

ここからは実際のITで発生しうるプロジェクト管理/プロダクト開発にてどうやってこのあたりの問題に対応していくかを書いてみる。

まずは修復係を作ることだ。仕事化というか仕組み化というか、役割としてそれをするべき人をアサインするのが一番手っ取り早い。これなら誰から指示されなくとも、誰もが無視していてもその人がやってくれる。要は専門の清掃員を雇う感じ。なんかこういう役回りの人だけのJob Descriptionあってもいいんじゃないかって思ってきた。

次に共通基盤チームを作ることだ。別名組織横断とか技術横断チームとか言われる、玉石混交のなんでも屋部隊のことだ。このチームは兼任メンバーになることが多いと思うけれど、10名以上のチームなら1、2名程度は専任がいても良い気がする。これもJob Description作っても良さそう。

XXを作る系に頼らない方法としては自律性に頼るほかない。
これは現在ある職種や役割の中に「他部門との協調を推進すること」みたいなことを組み込めばいい。このあたりはAmazonやNetflixあたりが「自分たちが問題に感じたら勝手にやればいいじゃない」みたいなので体現していた気がする。

こぼれ落ちたボールを拾うのはだれ？

僕の勝手な印象だが、エンジニアの中にも序列ができあがるとこぼれたボールを拾う係として新参者か、リーダーのどっちかになりやすい気がしている。これは多分アンチパターンだ。
こうならないようにするためにはチームメンバーが役割で別れていてそこには役職・裁量の違いはあれども全員がチームとして動き、全員でボール拾いするという意識が重要である。よくアジャイルやスクラムの文章で見かけるチーム 単位の生産性や開発サイクルの単位もここに通ずるはずだ。

あとは偉い人(経営者層とかマネージャー陣)がそれをやるってのも方法として存在する。こっちは全然これで良いと思うんだけど、マネージャーが球拾いをやる場合彼の評価をどうやって定量的にしてあげるかどうかがまあまあ課題になると思っている。なぜならば、球拾いそのものには価値がないからである。(野球やテニスを考えてほしい。ボールボーイやガールがサボれば試合は長引くだろうし結果も変わってしまうだろうが、根本的には選手のスキル・運・調子に左右されるはずだ)
このあたりはアピールの上手さという評価する側としては難しい壁にぶつかる。玉を拾った数を定量評価しても良さそうだけど、奪い合いになるのは本末転倒。いやあ、難しい。

そんなことを考えた今日このごろだった。