私はこれまで約6つのシステム開発プロジェクトに参画をさせていただきました。
その中で感じた、プロジェクト一般に共通するアンチパターンを書いてみたいと思います。
■リーダーのボトルネック
リーダーに相談したいことがあるにも関わらず、リーダーがずっと会議等に出ずっぱり状態のため、チームメンバからすると何も会話ができず、作業が停止してしまう事象です。
リーダーの最大の仕事は「決める」ことなので、本来であれば、時間に余裕があるくらいでないと、適切な判断ができないものと思います。ところが多くの場合において、リーダーに仕事が集中することが多く、この矛盾点はなかなか解消されていません。
特に人にタスクを振るのが苦手な性格の「いい人」ほどこうなる傾向があると感じています。
■スケジュール、ゴールが明確でない
理由はよくわかりませんが、WBSが決まっていないプロジェクトというのが存在します。
そういうプロジェクトは「前半はぬるま湯、後半が地獄」がお決まりです。
WBSを引いていても、なお遅延が起きるのが世の常なので、引かれていない状態だとほぼ漏れなく遅延する未来が待ち受けています。私もそのようなプロジェクトでお客様に怒られたことがあります。リーダーの方にWBSを引いてください、と言うべきでした。。。
■メンバの進捗遅れの報告が遅い
期日に間に合わないことが濃厚になった時点で連絡すべきところ、遅延が発生してから連絡するパターンです。
状況次第ですが、期限切れタスクが発生すること自体は仕方ないところもあります。
それは工数を見積もった人のミスかもしれないし、仕様変更の影響かもしれないので、作業担当者が一概に悪いわけではありません。しかし、遅延について何も共有がないのは、100%作業担当者の責任となります。
リーダーの人は、メンバの進捗遅延を受けた際、遅れの原因は必ずはっきりさせることと、できればリカバリ方法まで言わせるべきだと思います。
自分から言わない人はそもそも責任感が不足しているか、プロジェクト全体に対しての視野が狭い状態だと思うので、これをそのままにしておくと、次第に「遅延しても問題ない」という雰囲気になんとなくなっていきます。後からその空気感を変えるのは容易ではありません。
■人員の配置ミス、スキルアンマッチ
人員の配置ミスについては、例えば未経験の新卒1人に仕様工程を担当させる、というのがあります。これで仕様の検討漏れや仕様バグが起きない方が不思議だと思います。何を誰に担当させるか、には正解はなくとも、明らかな不正解を選んではいけないと思います。
また、非常によくあるのがBPのスキルアンマッチ。
面談時に「Pythonはコードレビューができるレベル」とか言っていたのに、蓋を開けたら「戻り値が何か理解していない」という、新卒1年目でも唖然とする事例がありました。
これはかなり極端なケースとしても、事前に伝え聞いていたスキルレベルでない、というのは往々にしてあります。
誰かに引き継ぐにしても引継ぎコストがかかるので、これではダブルパンチになってしまいます。
BP面談でのスキル説明はそのまま真に受けない方がいいと思います。
■工数見積もりミス
前提として、工数の見積もりは非常に難しいタスクです。
例えば、私が参画した、とある案件では、詳細設計での記載粒度がかなり高いものだったのですが、その割に工数が短く、残業してなんとか間に合わせました。その後の製造工程は、詳細設計での粒度が高かったためにサクサク進んだのですが、工数は過剰に見積もられており、なんと3週間近くもスケジュールに余裕が生まれました。
よくあるのは、新しい技術に手を出すのに、リスク工数が短いことです。結果として工数が総じて1.5倍という残念な結果になったプロジェクトがありました。優秀とされるリーダーは、工数見積もりで常に余裕を持たせています。まあ、言うのは簡単ですけど。。。すみません。。
■レビューがテキトー
レビュアーは誰でもいいわけではありません。役職やチーム内での立場が上でも、前提となる情報を把握していない人がレビューしても、思うような効果は得られません。
例えば、コードレビューの観点が体裁とロジック指摘のみで、仕様観点での指摘がない、というケースがあります。仕様を一通り把握している人がレビュアーでないと、試験でバグが大量発生して、かなり苦労することになります。
レビューを行った以上、レビュアーにも責任の一端はあるわけですが、これでは辛いですよね。
また、チームの体制としてレビューできる人が不足していて、レビュー密度が低い、という場合もあります。
■仕様が決まらない
外部とのインタフェース仕様がなかなか決まらない/工程が進んでから変更になる、というのは、どこの案件でも似通っています。
もともとインタフェースの部分は認識齟齬などトラブルが起きやすいところで、これは残念ながらそういう宿命を受け入れるしかないと思います。
が、それ以外の部分、自己コントロールできる範囲での決めるべき仕様がいつまで経っても曖昧なままでは、必ずそのしわ寄せが来ます。
■連携不足（サイレント変更）
仕様が変更になったにも関わらず、何も共有がない、というパターンです。
大きな手戻りが発生し、人間関係にも最も悪い影響を与える部類のひとつです。
炎上系案件ほど発生レベルが酷いイメージです。
■拠点間で状況がよくわかっていない
開発拠点が物理的に複数に分散しているプロジェクトというのがあります。
この場合に多いのが、お互いの状況がよくわからないまま進めて、後になって認識齟齬が発覚し炎上する、という事象です。
過去に私が参画した炎上案件では、拠点間MTGが週1でさえ行われておらず、本当にブラックボックス状態でした。
■チケット未更新からの状況把握ができなくなる
余裕があるときはみなチケットを更新するが、稼働が高くなるにつれ更新しない&期限切れが多発する、という傾向があります。そうするとリーダーも状況整理に時間がかかる、という悪循環が始まります。
「忙しいけどみんなチケット更新しましょう」は正論ではありますが、ただ、チケットの発行粒度・記載粒度も大きな要素だと思っていて、細かく記載しているところだと、更新が滞り始めるとずるずると放置される傾向にあります。なので私は細かすぎる粒度はあまり好きではありません。。。
■中途参画者に対する基本的な説明がされていない、テキトー
詳細設計や製造工程で増員をするというのはよくあるパターンで、つまりプロジェクトの途中から入ってくる人を中途参画者と定義します。
一般的に、中途参画者に対する説明って、前提となる情報が欠けていたり、説明側が早口になりがちな傾向があると感じています。
非常によく見受けられるのが、中途参画者に対しての、作業の進め方、ドキュメントの記載ルールや仕様説明がきちんとされないというものです。
「わからないことがあれば質問してください」はその通りですが、その前に最低限の説明は既存メンバからなされるべきだと私は思います。人数の多い案件だと、誰が何を把握しているのか、というレベルからわからないため、質問のハードルが高くなります。
基本的にリーダーに説明の役割がありますが、リーダーが多忙故に対応できていない、という場合がよくあります。悪循環の始まりという感じしかしません。親切な既存メンバが穴埋めするように気づいたところをちょくちょくフォローを入れるくらいになります。
とりわけ、仕様の理解はほぼ全員が何かしらで躓くところなので、時間をとって丁寧に説明すべきだと思います。
このようなところの説明が雑である点が、私が多重下請けでメンバがよく変わるSIer業界で良くないなと感じている点です。
私がもし今後チームリーダーになることができたとしたならば、ここは本気でクリアしたいなと思っています。
■無用な管理層がいてコミュニケーションと品質に悪影響
過去に参画したプロジェクトにおいて、大規模開発で、管理層が3層になっているところがありました。
1次請けのリーダー陣（一番立場が上）、2次請けのリーダー陣、3次請けのリーダー、という感じです。3次請け以降が実際の設計書作成、コーディングを担当、つまり実働部隊でした。私は実働部隊の一員です。
ここで問題なのが2次請けリーダー陣でした。
2次請けのリーダー陣の仕事は、
・実働部隊の成果物のレビュー
・上記レビューしたものを、自らがレビュイーとして1次請けに説明
というものでした（他にもWBS作成、管理などありますが割愛）。
しかし、いずれにおいてもまともに機能していませんでした。そもそも仕様の理解をしていないので体裁面ばかりのレビュー指摘でしたし、したがって1次請けへのレビューも結局実践しておらず、実働部隊が直接行っていました。
申し訳ないのですが、実働部隊の多くの方は、2次請けリーダーがいない方がスムーズに事が進むと感じていました（法的問題は脇に置いておくとして….）。形だけいるという感じで、本当に存在意義がわからなかったんですよね。確かに2次請けリーダー陣の方は性格は良かったものの、仕事ができるという感じでは全くありませんでしたし、突発的に休む日もかなり多かったです。
ただ、私としてはその方個人ではなくて、そもそもプロジェクトとしての体制として問題があると考えていました。2次請けリーダーは2回変更になったので計3人なのですが、3人とも似たような状況になったからです。
一般論として、自分で手を動かさず、人から説明される1回限りのレビューで理解し、それを他人に説明する、ということ自体が非効率な方法ではないでしょうか？2次請けリーダーの方からは仕事をしていて全然楽しそうな雰囲気は感じませんでしたし、私も彼らの立場で仕事は絶対したくないなと感じていました。
ようするに何が言いたいかというと、間に誰かが挟まることで、コミュニケーションがかえって非効率になる、という問題です。直接話した方がよっぽど捗る場合があります。
とりあえず以上になります。