組織パターンを読んでみて

組織パターン

組織パターンを読んで思ったこと少しまとめ的なことを書いていきます。
下記の書籍を参考にしています。
組織パターン

 

どんな本なのか

ソフトウェア開発における、「人」と「組織」に着目し、どのような組織であれば開発が進むのかが書かれています。

 

用語

本書で出てくる用語でいまいちピンとこない用語があったので、確認しておきます。

パターン

繰り返し現れるものだと考えました。

パターン言語

パターンを一定の順序で組み合わせる規則

下記の記事を参考にしました。
人が作るソフトウェア 〜今組織パターンを読む意味〜

 

組織パターン

組織パターンは下記4つの観点で見ることができます。
それぞれの観点で組織のパターンの考察が書かれており、どんなパターンがうまくいくのか、関連する組織パターンにはどんなものがあるのかが書かれています。
今回は上2つについて書いています。

  1. プロジェクトマネジメント
  2. 組織の漸進的成長
  3. 組織スタイル
  4. 人とコード

 

組織パターン:プロジェクトマネジメント

下記では、自分が気になったパターンと本書に書かれている「パターンのつながり」で多くのパターンに分岐しているものを選択してみました。

信頼で結ばれた共同体

「チーム内の人間が互いに信頼しうことがかかせない」
信頼されているというのは、なにかと感じ取りやすいというか敏感になってしまうことだと思います。
ここで解決策としては、「信頼していることを明示的に表現する行為をしよう」と書かれています。

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

きついスケジュールでも、ゆるいスケジュールでもだめなのが難しいところです。
ここでの解決策は2つあると思います。
一つは、スケジュール(期日)を守った開発者に特別報酬を与えることです。
こんなんあったら、確かに死ぬ気で守りに行く気がするw….
2つ目は、スケジュールを2つ用意しておくことです。
一つは、顧客向けに、もう一つは開発者向けに作っておくのです。
もちろん、開発者向けのスケジュールの方をきつくしておきます。

開発者がプロセスをコントロールする

開発者をプロセスの中心に置くということです。
具体的には「要件の理解」、「アルゴリズムのレビュー」、「実装」、「ユニットテストの実行」が挙げられています。
これ結構普通だと思ってしまうだけど、昔はそうではなかったという捉え方でよいのかな。

ここで注意が必要なのは、開発者に負荷をかけすぎないことです。
バランスが重要になるってことです。

作業は内側に流れる

ステークホルダー(顧客)からエンジニアへと作業が流れるべき
作業がマネージャーから流れるべきではない、という意見です。

マネージャーが中心に作業が割り当てられたりすると、マネージャに負担が集まりすぎてしまいます。

誰か一人を犠牲にする

どんなプロジェクトでも無駄な作業ができしまいます。
チーム外から余計な作業を頼まれることもあるでしょう。

このような作業があると、生産性は落ちてしまいます。
少しだけなら良いのですが、毎日チームにそのような作業が増えると、

そんなときにそのような作業を誰か一人にやってもらうことが効果的だと書かれています。
どこかのタイミングで1日この作業だけ行うとかが一気に片付けられそうで良いですね。

組織はマーケットに従う

マーケットの構造を開発組織に適応させることが重要だと書かれています。
具体的には、下記のように書かれています。

コンウェイの法則では、組織アーキテクチャは同じ形になる。
このアーキテクチャは、マーケットに従わなければいけない。

ここで言うマーケットとは、顧客のことをいっているのだと思います。
顧客のニーズに合わせて、アーキテクチャは作られるべきだし、組織も変わってくべきだということで理解しました。

 

組織パターン:組織の漸進的成長

防火壁

顧客から開発者を守ろうということだと理解しました。
顧客からの連絡で、開発者の手が止まるのあってはなりません。
こういう際に、顧客と開発者の間に割って入る必要があるということですね。

ただ気になるのは、上で上げた開発者がプロセスをコントロールするで、開発者をプロジェクトの中心にした場合に、
どんな感じで開発者を中心に置くかがちょっとわからなくなった….
顧客とのやり取りは、マネージャがーが主にして、開発者は同席するとかを想定しているのかな。
そうすると、急な依頼とかはマネージャーが対応して、マネージャーから開発者に流れるから、開発者がプロセスをコントロールする形式にならなくなる。

うーん…

 

重要だと思ったこと

この本で書かれているパターンの多くは、組織の上の方の人しか実行できなく、自分のような一人の開発者が実行できるのは少ないかもしれないです。
ですが、自分のできることはなにか、組織での自分の位置について考え、実行していくしかないと思いました。
やはり組織、人について考えるのは楽しいですね。

 

参考記事

人が作るソフトウェア 〜今組織パターンを読む意味〜