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

文系プログラマによるTIPSブログ

文系プログラマ脳の私が開発現場で学んだ事やプログラミングのTIPSをまとめています。

メイン担当がいない保守チームの破綻率が高い件

仕事

私は常時4〜6案件程度の保守案件をメイン担当者としてこなしているのですが、上手くいっていない保守チームにとある傾向がある事に気づきました。

それは・・・

メインとなる担当者がいない、コミット率が低い人が複数人集まったチームは破綻しやすい

ということです。

例えばAプロジェクトの保守チームが3人で、以下の構成だとします。

人員 案件掛け持ち数 Aプロジェクトのコミット率 Aプロジェクトの経験年数
Aさん 3 30% 1年未満
Bさん 2 40% 1年未満
Cさん 3 30% 1年未満

このプロジェクトは元々2人だったところ、諸事情で3人になりました。
3人いるので、誰かが休んだり手が離せなくなっても誰かが担当できるので、リスクが分散できる!!となる筈が、このプロジェクトには沢山の波乱が待ち受けていました。

では具体的にどんな事が起きたのか見ていきます。

起きた事

誰も手を挙げない

例えばPMが「このタスクお願い!」と依頼した場合、3人の中で「自分がやります」と手を挙げる人はいませんでした。

誰も意見を言わなくなった

3人いるので、「誰かが意見を言ってくれるだろう」とお互いを牽制しているような状態でした。その影響で、誰も改善策を提示しないまま、プロジェクトが改善されていく事はありませんでした。

デプロイミスが増えた

3人いるので、それぞれが違う部分を担当しています。

デプロイ時は3人の修正を一気にデプロイします。その時、どれをデプロイしたらよいか等の認識が合わない事があり、デプロイミスが起きた。

また、この日はこれをデプロイする、等の認識が合わなくなり、デプロイしてはいけないものもデプロイしてしまう事もありました。

バグが増えた

3人の担当箇所は、単体レベルで見るとバグは無いのですが、結合してみるとバグが発生した!という事がかなりありました。

Aさん「Bさん、ここってこういうデータって来ない筈ですよね?」
Bさん「そこはCさんのデータを連携しているだけなので、Cさんに聞いて下さい。」
Cさん「あれ?そこはAさんがデータを加工するんじゃないんですか?」

こんな感じの3すくみ状態で、しょうもない認識齟齬が多々発生していました。

3人いる事でコミュニケーションコストも上がったのも、こうなった原因の一つです。

仕様の理解度が落ちた

3人がそれぞれフロント・管理画面・バッチと担当しており、1機能を端から端まで理解している人がおらず、仕様理解不足に起因する設計のミス、バグ、手戻りが多々発生していました。

責任感の低下

3人いるので、「誰かが何とかしてくれる」という意識が強かったのでしょう。「ここでトラブルが起きてもBさんかCさんが何とかしてくれる」という3すくみが発生し、結局BさんもCさんもトラブルに対処できませんでした。

当初は分散のつもりで3人にしたが・・・

当初は3人のうち2人風邪で休んだり、他のプロジェクトにかかりきりになってもいいように、3人構成にしました。しかし分散のメリットはほとんど無く、責任感や仕様把握等が平均化されてしまい、狭く薄くしか理解していない担当者が3人できただけでした。

メイン担当者がいる場合

このAプロジェクトはあまりにも気軽にバグを大量発生させるチームになってしまったので、人員が整理され、以下のようになりました。

人員 案件掛け持ち数 Aプロジェクトのコミット率 Aプロジェクトの経験年数
Dさん 2 80% 1年未満
Eさん 5 20% 1年未満

Dさんはコミット率が80%で、Aプロジェクトのメイン担当者です。
Eさんは主にDさんがこなせない分のタスクを補助する役割です。

この構成になってから、前述の問題はほぼ解消されました。

プロジェクトの経験年数と他プロジェクトの掛け持ち数はそれほど重要でなく、コミット率が重要でした。

Dさんは、フロントも管理画面もバッチもDBもインフラも担当します。
担当範囲が広いので、根本的な理解の幅が広くなり、おかしな設計をする事もありません。
自分がメイン担当者であるという自覚もあり、PMや営業からの問いかけに全てDさんが答えます。

Dさんは幅広く理解しているため、徐々に開発効率向上の施策やバグの早期発見の仕組みを組み込む事ができるようになり、実質Dさん1人でもプロジェクトが回ってしまう状態になっています。

バグも少なく、このチームは皆定時に帰宅できるようになっていました。

雑感

Dさんが風邪で休むと結構問題になりますが、Dさんが風邪で休むよりも、3人チームで甘い設計・実装をされる方が問題になるケースの方が多かったように思えます。

他のプロジェクトを見ても、リスクの分散の為にコミット率の低い人を複数集めたところは、大体トラブっています。

一時期派遣社員が3人集まった時がありましたが、恐ろしい程責任感が無くなってしまい、毎日障害を起こし、都度私が障害の対応させられていた程です。

リスクの分散と責任感の分散のバランスは難しいですね。

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

  • 作者: ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン,黒沢 健二,松永 肇一,美谷 広海,祐佳 ヤング
  • 出版社/メーカー: 早川書房
  • 発売日: 2012/01/11
  • メディア: 単行本
  • 購入: 21人 クリック: 325回
  • この商品を含むブログ (35件) を見る
開発チーム革新を成功に導くインパクト・メソッド

開発チーム革新を成功に導くインパクト・メソッド