昨日のエントリーを書いた後、読み直したら付箋が増えてました。

とはいえ、この本のまとめ文が思いつかず、Amazon の紹介文をのぞいてみても何か違う感じ。
どうやら著者のブログにある

本書「小飼弾の 「仕組み」進化論 」は、プログラマーという、「純粋な仕組み」を作ることを仕事にしている者が、仕組みというものを一体どう考えているのかを、一般書に落とし込んだ一冊ということになります。

この一文が最適っぽいです。

この本の「読んでヨカッタ」は仕組みの暴走と安全性に言及しているところでした。

仕組みはコントロールできなくなると、思いもかけない結果をもたらす

優れた仕組みは「安全性」を高めている

確かに自動車は便利な乗り物である一方で、殺人を犯している（後述の「奴隷」が仕組みの運用を誤ったためだけれども）。
Web という「仕組み」も人の可能性を広げたのは間違い無いけれど、人の邪悪な表象をより明らかにもしました（ちょっと違うか、これは）。
話をそらすと「奴隷」が「仕組み」を使いこなすほど成熟していない、ということもあると思います。
さておき、

あらゆる仕組みは、「テコ」と「奴隷」でできている

そうで、

テコには公式やマニュアルといった目には見えないものも含まれる

という忘れがちなところをフォローしてくれているのもヨカッタです。

マニュアルで仕組みを共有化

これはホント大事。
昨年末に運用ツールとマニュアルを作ってウチの運営スタッフに提供した（これ自体は業務として課せられたものではない）ことで、私の（開発ではない）定期業務が無くなったこともあって、

という感じ。
ただ、「他力」と言い換えているものの、どうして「奴隷」という言葉を使ったのかは分かりませんでした。
プログラマーの三大美徳の

「怠慢」「短気」「傲慢」

のようにあえて悪い意味を持つ言葉を使う理由が見当たらなかったというか。
しかし、やはり気づきというか「おもいだす」も多く、

「設計」という「心」と、「実装」という「体」

この辺は「心」に刻んでおくべき。

真の 20% ルールについては、既出なので、続きでその他の付箋ポイントを挙げて終わっときます。
もう少し後で読み直したら、また何か拾えるかもと思いつつ。

自分に。

まず、自分、そして自分が勤めている会社が行き続けるためには、どれだけの利益を上げる必要があるのかを算出します
現在の自分の仕事がその利益を生み出しているかどうかを計算します
その利益を出すために行っている個々の仕事の時間数を算出します

仕事を定量化する

それぞれの仕事の所要時間と、求められる成果・実際に達成した成果も記入します。

人間の変異は「どれだけの言葉を交わすことができるか」にある

オールドタイプが理解すべきリスク。

時代に合わなくなった仕組みが動き続ける

コピペドリブン開発ってツライんです。

DRY原則（Don't Repeat Yourself）

車輪の再発明

自分の欲しい機能がすでに存在しているかどうかを、まず調べたほうが効果的

余裕大切。

「遊び」には、「楽しむために何かする」という意味も、そして「余裕」という意味もあります。 仕組み作りには、そのどちらの遊びも不可欠です。

この勝負、生き残った方の勝ちだ。

生物にとって重要なのは、「正しいこと」ではなく「生き残って」いること。何が正しいかではなく、生き残ったものが正しいのです。

メール転送が仕事の人とかいりません。

同時に伝える、またメールを同送するなどして無駄な要素を減らせば、もっとすっきりするでしょう

要素が少ないほうが、効率的かつ間違いが少ない

情報共有のためにあえてチーム宛にメールを送ってるんです。

日報用メーリングリストを作り、部署内で日報を共有する

トラブルがあったときには担当者にレポートを書かせて、それをメーリングリストで共有しました。また、業務上の質問を投稿できるメーリングリストも用意し、わかる人間が積極的に回答する体制を整えました。

社内 SNS 貼り付けに。

ゴールが見えていれば、それに向かって自身の行動を調整することができます。ゴールを見せないことは、各人の知能を無駄にすること、意外にこれを理解していない会社は少ないように思います。

リーダーの笑顔は、「義務」です。

アウトソーシングは（中略）よほど安価であるか、よほど信頼性が高くない限り、基本的に凶

「アイデアを出す段階では、どんなアイデアに対してもダメ出しをしない」

あと１ピースがあれば実現できるということろまで、物事を具体化しておき、必要なピースが出てきたら、すかさず拾いにいく。

「作れるものをどれだけ作るか」ではなく「使えるものをどれだけ有効に使うか」

下手なアリはうろうろすることで新しいエサを発見できるチャンスが高まる