読者です 読者をやめる 読者になる 読者になる

futoase

よろしくお願いします。

組織パターンを読み終えて

雑記 読書

やっと読み終えた。

組織パターン (Object Oriented SELECTION)

組織パターン (Object Oriented SELECTION)

組織パターン。先週(2/3)に読み終えた。
読んでいる間にそうだねそうだね、と思えるような内容が沢山でてきた。

組織パターンのA. 要約的パトレットを
見返すことで読んできた内容を見返せる。
適当に摘んで振り返ってみたい。
勝手な感想をつけたりする。

4.1.2 スケジュールを小分けにする

内向けと外向けのスケジュール予定はずらしておく、という内容だ。
未知のことをやるんであれば自分たちが出来そうな間隔+50%なスケジュールを
外に対して言えばいいのかなとか思ったりした。

4.1.3 ぐずぐずするな

あれこれ用意してるんだったら
コミットできるものからコミットしろという内容だ。
そりゃそうだな。

4.2.12 目的の統一

プロダクトメンバーの作業における
目的を統一するという。当たり前か。
自分たちが何のためにどの目的を達成しようとしているのか、
何がゴールなのか。誰に求められているか、か。

4.2.20 常に誰かが進捗させる

何かが進んでなければ停滞感が出てしまうので
プロダクトメンバーの士気が下がるという。
そりゃそうだな。何か進めるよう、小さい作業でも良いので
こなしていけるほうが良さそうだ。

5.1.20 冷水器

組織が分断された状態にならないように
非公式で且つお互いが集まりやすい場所を用意しようということだ。
近いものでは喫煙部屋があるか。
ようはまあ情報共有だな。

5.2.6 極秘の商談部屋

力のある人達だけで目標を決めてしまおうというものだ。
他の人達には決定したものだけを伝える。
意思決定までのフローは表に出さない。
良いと思う。必要な時があるので。

5.2.13 コードの所有権

ひどい状況が無い限りは、
ライブラリのメンテナにコミットを任せようというもの。
大規模なシステムを作ってる場合、
通信部分やらストレージとのやりとりやら
描画やら色々とあるが、まあ横断的に且つ人がバラバラな状態で
対応するのは混乱をきたすので普通だと思う。

組織パターンを読んだ後

読んだ後に自分に取り込めるものはなにか、
参考にできるものはなにか。そして現状の問題と対応付けした場合
どういう流れで対策を取るのか。
常に考えるようになった。プログラミングしてる時にも。
仕事をしてる時にも。なんとなく新宿から秋葉原に向かう電車の中でも。

何が大切なんだろう。仕事が大切というわけじゃないが、
モノを作るのはどこを大切にするべきなのだろう。
するべきなのかも思い込みなのかも?

という考えが巡って毎日頭がいたい。

結局

他にもいろいろあるのだが、取り上げてるときりがない。
組織パターンは読んだほうがよい。

Copyright (c) 2013-2015 Keiji Matsuzaki