7月9日（水）にTeamGeek 読書会@札幌 -8を開催しました。
今回は第5章「組織的操作の技法」前半。
「理想と現実」のところまでで時間いっぱいとなり、「組織を操作する」からは次回に持ち越しです。
（10ページも進みませんでした）
個人的には前章の「有害な人に対処する」方がディスカッションが長くなるかと思っていたのですが、今回の方が多くの話が出てきました。
組織に対する思いや悩みは、共通部分が多いからかもしれない。
有意義な時間だったと思います。
理想
リスクを取ること
積極的にリスクを取ることで、攻めの姿勢になり、大きな仕事ができる。
リスクを取らないければ失敗はしないけれど大きな成功も少ない。
積極的にリスクを取ろう（責任範囲を広げよう）、という話。
Agile Japan 2014の基調講演の「失敗は無駄」というキーワードも絡めて「良い失敗とは何か」という話をしました。
本書に出ている飛行機の例え（飛行機を乗り過ごしたことがない人は空港に早く着きすぎる）から、大きな成功を手に入れる前段階で、「早いうちに失敗しておいて、対応方法を学んでおく」というのが重要なのかな、と考えました。
一度飛行機を乗り過ごしたり、タクシーに忘れ物をしたり、振込を忘れたり、財布を落としたり….という経験を積むと、次の失敗への準備ができるようになると思います。必要以上に恐れなくなるというか。
必要以上に恐れなくなることによって、「ここまでは大丈夫」という範囲が広がり、結果的に大きなものを手に入れられるのかもしれない。
質問をする・期待することを伝える
理想的な組織の特徴として挙げられたこの2つ。
特に「質問をすることが出来なくなる」ことはとても危険だと思っています。
普段の質問に気兼ねしてしまわないか？という点はもちろん、”手強い質問”をする人がいなくなる・言い出せる空気じゃなくなると、組織として衰退化していく。
コミュニケーションをとりすぎている人はいない
この言葉にはハッとさせられました。
ただし「コミュニケーションをたくさんとる = 必要以上にみんなの時間を奪う」ではないというところは気をつけないといけないですね。
現実
多くの会社はエンジニアリングの会社ではない。
エンジニアはビジネスゴールを達成する手段なのだ。
全ての人がそうではないけれど、我々はエンジニアでもあり、会社員でもあります。
会社は社員を組織としてまとめなければいけません。
ある一定以上の人数になった組織にはルールが必要です。
そこで導入される指揮統制とエンジニアとしての状態とに摩擦が生じることがままある。
本書を読んで「日本だけじゃないんだ」ということを知れたのはとても大きいです。
悪い組織の例（5.3.3の著者の言い回しには熱がこもっている）は「読んでいて辛いね…」という声が多かった。
- ビジネスのために従業員を犠牲にできる経営者に交代させられる
- 非現実的な納期と能力の低い技術者で納期通りに完了させなければいけない
- 数百ドルのハードウェアを購入すればすぐに終わるところを何週間かかけて書き直す
- 奴隷のように扱って会社の経営に口を挟ませない
- バグの受け渡しに厳格な指揮統制とルール
（バグを発見し、隣の部署に報告し、そのバグにどう対応するかの打ち合わせが開かれるのまでに10日！） - 権力闘争に巻き込まれ異動できない
- 1週間に書いたコード行数で生産性を計測する
- プロダクトの数や品質ではなく開催・参加したミーティングの数で成功を評価
過去を振り返れば思い当たることはゼロではない。
それでも、その組織の中で良いプロダクトを作り出すチームもあるし、全てが直接的なダメージにならないように振る舞うこともできると思う。
対立ばかりしていても仕方ないのだよなあ。
次回は「組織を操作する」。組織の中でうまく動けるようなヒントについて学びたいと思います。
ということで次回は8月6日（水）です。
TeamGeek 読書会@札幌 -9
気がついたメモ
P121 6行目仕事を効果的に進め「る」ため