ここ数年で経験したマネジメントで一番効果を発揮したのはスター型だった。
と言う事で、いつものように僕の独断と偏見で僕の行った効果的なマネジメントについて語っていこうと思う。
ここ数年で行ったのが、以下である。
・Ruby on Rails2で既存システムのリプレースを行った。
その際に既存システムと新しいシステムで同じものを作ってみて工数を比べたところ約６倍のコストダウンが見られた。
それくらいの低コストでものを作ると言うマネジメントを行った。
・上記のシステムをRuby on Rails3に引き上げた。
上記のシステムはテーブル数１３０以上でプログラムファイル数は１０００を超える巨大プロジェクトだった。
これをRails3に持っていくためフレームワーク部分を作り直し、テーブル構成以外（ルーティングも変更した）全てを作り直した。これが大体三ヶ月。（僕自身の調査は計６ヶ月で、プロジェクトとしては３ヶ月で作り直し。）
※他にも掛け持ちマネジメントや新規プロジェクト立ち上げのマネジメントも行ったが、目立った成果も無いので割愛する。（すなわち、僕も全てが上手く行ったわけではない。）
その時に行ったのがスター型マネジメントである。
スター型マネジメントとは僕が勝手に作った造語なので、他言する時には注意して使ってください（笑
一般的にアジャイルのスタイルでは、みんなの意見を尊重してみんなでわいわい決めていくイメージがあるが僕は全てマネジャーが決めると言う独裁的な方法を取った。
お客さんと開発メンバーが参加する週に一度の打ち合わせはXPの様に行うが、基本的な決定事項は全て僕が握った。
このように書くと本当に独裁的なイメージがあるが、実際は誰かが舵を完全に握ると言うのは心理的には安定をもたらしやすい。なぜなら全てを僕が決めると言う事は、責任は全て僕にあるから安心して仕事をして欲しいと言う事の裏返しだからである。
（人は本当の自由を得てしまうより、ある程度の束縛を求めるのである。）
なので、仕事の仕方は以下のようになった。
・仕事のサイクルは一週間
仕事は金曜日に始まり、金曜日終わると言うサイクルが出来た。
なので、金曜日に次週のタスクを伝えて月曜日から実際の設計＋コーディングに入る。
そして水曜日までにタスクを終わらせ、木曜日にコードレビューが入る。
金曜日は実際に作ったものがお客様の想定通りであるかをチェックするMTGを行って、次週のタスクをみんなに振り分ける。
・調整タスクを僕が持つようにする
前回の記事に書いたようにタスクを早く終わらせるものも入れば、小さいところで手こずっている人も出てくる。なので、早く終わった人には僕の持っているタスクを分け与えて、終わらなさそうな部分は僕が対応する。
また、影響度が大きく難しいタスクは僕が対応する。
こうする事で、全体の計画を僕がハンドリング出来るようになる。（前回の記事に書いたように、僕自身のタスクの見積は一番精度が高いからである。）
※僕が難しいタスクを持つ事で、メンバーは僕の持つ難しいタスクにチャレンジしたがる場合もあり上手く回る。
・障害対応も僕が行う。
出来るだけメンバーに負担をかけないように、イレギュラーな対応は僕が行うようにする。これによって障害によって計画が狂う事が少なくなる。
ただし、二つの理由で他の人が行う場合もある。
１.僕よりもメンバーの方が明らかに早く対応出来る場合
２.他の人がやった方がモチベーションが上がる場合
１番は自明の理で、作った人が対応した方が明らかに早い場合があるためそれに僕が甘えるケースがある。
２番はその人が出した障害でプロとして最後まで責任を持ちたいと言うケースや、興味のあるプログラムで対応したいと言うケースがあるのでその場合はメンバーに任せるようにする。
・コードレビューはみんなで指摘するが、最後の決断は僕が行う。
各メンバーのコードをチェックする場合は粒度を統一する為にも、僕が修正可否を判断する。また、コードの指針がずれている場合は最初からやり直させる場合もある。
また、近い処理を行っている人が居る場合は出来るだけコードも近くする。（もし概念が同じ場合は、共通メソッドやクラスを作成して処理を纏めてもらう。）
※コードレビューはシステムの出来に一番貢献するものなので、やってないプロジェクトはプロとして恥ずべきと思っても良いレベルである。また、いまいち効果がでないのは指針を決めれる人が誰もいないかシステムが一人歩きしている場合である。それはやり方を変えるか、プロとして恥ずかしいシステムを作っていると思って諦めよう。
・実装に迷った場合は僕が指針を出す。
実装方法が複数あってお客様に確認したい場合には金曜日のMTGまでは暫定的な対応を行う事になる。その時に僕はこのシステムがどのように使われるかを想像して、ある理由を付けて暫定的な方針を示す。（ある理由と言うのは「お客さんはこういう使い方をすると入力ミスが減るはずなので」と言うような、作っている人が納得出来る理由である。）
ただし、手戻りが明らかに大きい場合に限ってはお客様に確認する。
大体ではあるが、このような仕事の仕方になった。
見て分かる通り、とにかく僕（マネジャー）が要になって舵をきっている。
この方法の一番の利点であり欠点であるのは、マネジャーの力量によって生産性が大きく変わる事である。僕が無能であればどんどん変なものが出来て行き、プロジェクトは頓挫していく。一方で僕が優秀であればメンバーの生産性はどんどん上がっていく。（僕のやり方に慣れてくるのと、指針に統一感があるため使い回しできるプログラムが増えていくのだ。）
あと、この方法を行う為には僕に大変な負担がかかる上に僕が保有すべき知識は半端無いものとなる。なので、万人向けのマネジメントではない。
しかし、この方法が生産性を６倍にも引き上げた事も事実である。（おかげで僕はお客様とメンバーの信頼を勝ち取った。）
もし、腕に自信がある方は是非このマネジメントをやってみる事を進める。
恐ろしく疲れるが、やり遂げた時には自分のスキルが数段レベルアップしている事だろう。
と言う事で、この凄腕マネジャーをしていたTownSoftへシステムの依頼を是非お願いします！
Twitterも宜しくお願い致します！
syou007
と言う事で、いつものように僕の独断と偏見で僕の行った効果的なマネジメントについて語っていこうと思う。
ここ数年で行ったのが、以下である。
・Ruby on Rails2で既存システムのリプレースを行った。
その際に既存システムと新しいシステムで同じものを作ってみて工数を比べたところ約６倍のコストダウンが見られた。
それくらいの低コストでものを作ると言うマネジメントを行った。
・上記のシステムをRuby on Rails3に引き上げた。
上記のシステムはテーブル数１３０以上でプログラムファイル数は１０００を超える巨大プロジェクトだった。
これをRails3に持っていくためフレームワーク部分を作り直し、テーブル構成以外（ルーティングも変更した）全てを作り直した。これが大体三ヶ月。（僕自身の調査は計６ヶ月で、プロジェクトとしては３ヶ月で作り直し。）
※他にも掛け持ちマネジメントや新規プロジェクト立ち上げのマネジメントも行ったが、目立った成果も無いので割愛する。（すなわち、僕も全てが上手く行ったわけではない。）
その時に行ったのがスター型マネジメントである。
スター型マネジメントとは僕が勝手に作った造語なので、他言する時には注意して使ってください（笑
一般的にアジャイルのスタイルでは、みんなの意見を尊重してみんなでわいわい決めていくイメージがあるが僕は全てマネジャーが決めると言う独裁的な方法を取った。
お客さんと開発メンバーが参加する週に一度の打ち合わせはXPの様に行うが、基本的な決定事項は全て僕が握った。
このように書くと本当に独裁的なイメージがあるが、実際は誰かが舵を完全に握ると言うのは心理的には安定をもたらしやすい。なぜなら全てを僕が決めると言う事は、責任は全て僕にあるから安心して仕事をして欲しいと言う事の裏返しだからである。
（人は本当の自由を得てしまうより、ある程度の束縛を求めるのである。）
なので、仕事の仕方は以下のようになった。
・仕事のサイクルは一週間
仕事は金曜日に始まり、金曜日終わると言うサイクルが出来た。
なので、金曜日に次週のタスクを伝えて月曜日から実際の設計＋コーディングに入る。
そして水曜日までにタスクを終わらせ、木曜日にコードレビューが入る。
金曜日は実際に作ったものがお客様の想定通りであるかをチェックするMTGを行って、次週のタスクをみんなに振り分ける。
・調整タスクを僕が持つようにする
前回の記事に書いたようにタスクを早く終わらせるものも入れば、小さいところで手こずっている人も出てくる。なので、早く終わった人には僕の持っているタスクを分け与えて、終わらなさそうな部分は僕が対応する。
また、影響度が大きく難しいタスクは僕が対応する。
こうする事で、全体の計画を僕がハンドリング出来るようになる。（前回の記事に書いたように、僕自身のタスクの見積は一番精度が高いからである。）
※僕が難しいタスクを持つ事で、メンバーは僕の持つ難しいタスクにチャレンジしたがる場合もあり上手く回る。
・障害対応も僕が行う。
出来るだけメンバーに負担をかけないように、イレギュラーな対応は僕が行うようにする。これによって障害によって計画が狂う事が少なくなる。
ただし、二つの理由で他の人が行う場合もある。
１.僕よりもメンバーの方が明らかに早く対応出来る場合
２.他の人がやった方がモチベーションが上がる場合
１番は自明の理で、作った人が対応した方が明らかに早い場合があるためそれに僕が甘えるケースがある。
２番はその人が出した障害でプロとして最後まで責任を持ちたいと言うケースや、興味のあるプログラムで対応したいと言うケースがあるのでその場合はメンバーに任せるようにする。
・コードレビューはみんなで指摘するが、最後の決断は僕が行う。
各メンバーのコードをチェックする場合は粒度を統一する為にも、僕が修正可否を判断する。また、コードの指針がずれている場合は最初からやり直させる場合もある。
また、近い処理を行っている人が居る場合は出来るだけコードも近くする。（もし概念が同じ場合は、共通メソッドやクラスを作成して処理を纏めてもらう。）
※コードレビューはシステムの出来に一番貢献するものなので、やってないプロジェクトはプロとして恥ずべきと思っても良いレベルである。また、いまいち効果がでないのは指針を決めれる人が誰もいないかシステムが一人歩きしている場合である。それはやり方を変えるか、プロとして恥ずかしいシステムを作っていると思って諦めよう。
・実装に迷った場合は僕が指針を出す。
実装方法が複数あってお客様に確認したい場合には金曜日のMTGまでは暫定的な対応を行う事になる。その時に僕はこのシステムがどのように使われるかを想像して、ある理由を付けて暫定的な方針を示す。（ある理由と言うのは「お客さんはこういう使い方をすると入力ミスが減るはずなので」と言うような、作っている人が納得出来る理由である。）
ただし、手戻りが明らかに大きい場合に限ってはお客様に確認する。
大体ではあるが、このような仕事の仕方になった。
見て分かる通り、とにかく僕（マネジャー）が要になって舵をきっている。
この方法の一番の利点であり欠点であるのは、マネジャーの力量によって生産性が大きく変わる事である。僕が無能であればどんどん変なものが出来て行き、プロジェクトは頓挫していく。一方で僕が優秀であればメンバーの生産性はどんどん上がっていく。（僕のやり方に慣れてくるのと、指針に統一感があるため使い回しできるプログラムが増えていくのだ。）
あと、この方法を行う為には僕に大変な負担がかかる上に僕が保有すべき知識は半端無いものとなる。なので、万人向けのマネジメントではない。
しかし、この方法が生産性を６倍にも引き上げた事も事実である。（おかげで僕はお客様とメンバーの信頼を勝ち取った。）
もし、腕に自信がある方は是非このマネジメントをやってみる事を進める。
恐ろしく疲れるが、やり遂げた時には自分のスキルが数段レベルアップしている事だろう。
と言う事で、この凄腕マネジャーをしていたTownSoftへシステムの依頼を是非お願いします！
Twitterも宜しくお願い致します！
syou007