都度編成のチームはギャンブルすぎる

プロジェクトで開発チームを編成して立ち上げ、改めてメンバの顔を見渡すと、一体どれくらいこれまでのプロジェクトで一緒に働いたことがあるメンバがいるだろうか。

プライムのSierだとプロジェクトの規模によるがリーダクラスが数人程度で、顔見知りだったとしても同じプロジェクトで活動したことがあるなんてないケースの方が多いのではないか。まだN次受けのSESの方が、案件ごとにプロジェクトルームにリソースとして供出されるので同じ組織のエンジニアがチャンクに纏められるのでいつもの仲間と同じプロジェクトをいくつも経験しているのかもしれない。

そうした寄せ集め的なプロジェクトチームでは、プロジェクトとしての形式知は集めにくく、個々のエンジニアの経験知として積み重ねられていくが、そうした経験知はエンジニアの中に収まったまま世に出てくることはない。

そうしたプロジェクトチームでは、所謂、統制型か調整型のリーダシップが発揮され、結果的にコマンド＆コントロールがなされる。

プロジェクトの形態をとっていることも、そのプロジェクトが終了すればチームは解散することがわかっているとプロジェクトを終了させることが目的に擦り変わることままあり、言われた通りにしておけばいいという受け身での関与が蔓延する。

保守、維持管理が計画され、開発したチームから残されることが判明しているとしてもそのチームに残るとは限らず、そうしたエンジニアは開発案件しか入れないとする組織であれば焼畑農法的なビジネスを繰り返すのでエンジニアのプロフェッショナリズムは発揮されることはない。

コマンド＆コントロールといえば軍隊組織を容易に想像することができるが、次の文献を読む限りそうした印象は誤ったものかもしれない。

われわれの指揮の哲学はまた、暗黙的に意思疎通する人間の能力を活用しなければならない。暗黙的コミュニケーションーーお互いを理解し合い、言葉の使用をよくわった重要なものだけにとどめ、あるいはさらにお互いの考えていることを察し合うことのほうが、コミュニケーションの手段としては、詳しい明示的な指令を使うよりもっと速くて効果的であると信じる。（『ウォーファイティング』243頁）
引用　知的機動力の本質　野中郁次郎

これまで、経験知は形式知に、明示的なコミュニケーションを図ったほうが良いと思っていた。これは組織内でチームを都度編成していることを暗黙にしていたから前提のズレがあるかもしれない。

そう言えば、アジャイル開発チームのメンバを入れ替えない方がいいというのは、入れ替えてしまったり、チームを解散させてしまうとそれまでチーム内で醸成していたコンテクストが下がってしまったり、リセットされてしまうためだが、速く効果的な活動を求める切り口であれば指揮命令よりハイコンテクストである方が合理的だからであろう。

ビジネス形態が違うとチーム編成の方針も変わるし、チームに求める価値観も変わってくる。

ただ、そうした速く効率的なチームであっても人員の更新は避けられないが一定のサイクルであればサイクルに応じたレベルで期待はできるだろう。都度編成はギャンブルでしかない。