小規模プロジェクトにおけるメンバリスクを認識することの大切さ

waterfallとagiliとたった一つの違い - 室長のひとりごちで書いた“メンバのスキル、コンピテンシに依存するリスク”の補足を少し書こうと思う。

人はばらつく
waterfallだろうがagiliだろうが、仕事ならそれなりの熱意をもって取り組んでほしいと思うのだけれど、人の関心は人それぞれであって関心や意欲によってアウトプットがばらつく。
大規模なプロジェクトなら、人数の母数が10人、100人単位になるので、

　(出来る人＋普通の人＋できない人)/3=1

と、アウトプットに対する係数を“1”にしてしまえる。
それぞれ長いフェーズというバッファでリカバリも暗黙のコンテンジェンシとして織り込めるし、(賢いリーダなら)織り込むのだけれど。

計算式が成り立たない
ところが、小さい規模のプロジェクトになると、人数の母数が10人未満になるので、その計算式が成り立たなくなる。
意欲に満ちた人でアウトプットを期待できればよいが、できない人が混ざった瞬間、リスクを抱えることになる。
新人は意欲に満ちているけれど、アウトプットは...だし、経験を積んでいるけれど...という人もいる。
人に存するから、これはwaterfallでもagiliでも変わらない。

いや、agiliの方がフェーズのタイムスパンが短い分、インパクトが大きい。
このようなメンバがいることが分かった時点での考えられるリスクは何があるだろうか。

技術スキルが期待値より低いため、アウトプットの品質を満たさない

リカバリのため、余計なコストが必要になる

将来の品質低下を生むバグを混入する

リリースが間に合わない

このようなリスクが顕在化していくと、face2faceのコミュニケーションも悪化することは容易く想像できるし、プロジェクトルームの雰囲気はギクシャクするだろう。

与えられたリソースで組織を回すのがマネージャ
とはいっても、希望する人でプロジェクトメンバを構成できることは、“ありえない”。
そんなことをしていたら、プロジェクトは組織で1つしか実行できなくなる。
マネージャは、自分に与えられるメンバは、givenだとしなければ組織が成り立たない。
それだけではデスマ突入確実になるので、キーパーソンは必ず押さえなければならないけれど、やっぱりキーパーソン以外は多少フィルタをかけるとしてもgivenになることはリスクとして織り込むしかない。
織り込んだ時点で、リスクは識別しているのだから、リスクはマネジメントできる。
これはラインマネージャばかりではなく、プロジェクトマネージャも同じだ。

じゃあどうするのよ
プロジェクトメンバが5人いれば5人それぞれ、9人いれば9人それぞれ、意欲もコンピテンシも違う。
それぞれのメンバの意欲もコンピテンシの違いは、“個性”として認識して受け入れたうえで、アジャイル宣言の背後にある原則とプロジェクトの憲章を“毎日”刷り込みをする他ない。
個性があって、それぞれ違うなら体で覚えてもらうのが一番だと思う。
わたしたちのプロジェクトは、“意欲に満ちた人々を集めたプロジェクト”で構成していると信じられるように。