Stories 7話：チームマネジメント（協力会社）

今日はチームメンバーから一つ相談を持ち掛けられました。
その内容は
・開発チームのメンバーのフラストレーションがたまっているので話を聞いてやってほしい
というものでした。

現在、私が携わっているプロジェクトの構成としては

【発注側】
私のいる社内SE部隊

【受注側】
・コンサルティングファーム
・SIer

という形なのですが、この中のSIerで構成されている開発チームが悲鳴を上げているという事でした。

私が加入する前からこのプロジェクトはコミュニケーションロスが多く、
それによって、様々な立場の人がやらなくていい事や
しなくていい苦労をしているというのは聞いていたので、
私ができることであれば何とかしてあげたいとは思っていました。

ただ、開発については私とは別に開発管理者がおり、私が軽々に首を突っ込むこともできない上に、それについて訴えてくる人もいなかった為、具体的に誰が何に苦しんでいるのか把握できなかったのですが、ようやく話が聞けそうでした。

私が話を聞いた相手はSIerの開発チームリーダーですが
今回の話はコンサルティングファームの開発チームに対する要求がひどい
という話でした。

具体的にどう「ひどい」のかというと、
コンサルから流れてくる案件は開発期間が異常に短く、それをリカバリーするために開発チームは土日出勤対応などもしている。こう言った状況が慢性的に続いていて、メンバーも疲弊しているという事です。

ちなみに、コンサルと開発チームの関わり方は以下のような形で
要件定義：コンサル
基本設計：コンサル
開発：SIer
単体テスト：SIer
受入テスト：コンサル
内部結合テスト：コンサル
みたいな形になっていて、コンサルの担当している要件定義、基本設計が
往々にして遅れるという事です。
そして、その遅れに対して何故かSIerが担当している
開発と、単体テストの納期を短くするように言ってくるらしく
それに応えるために、無理な働き方をしているという事です。

開発チームのリーダー曰く、
コンサル部隊は開発経験が乏しく、開発にどれだけ工数がかかるかが全く分かっていない上、仕様も固まらないまま、開発に投げてきたりするので、蓋を開けてみたら全然話が違うという事も多く、相当振り回されているという事です。

これが事実だとしたら困った話です。
開発部隊がダウンしてしまったら、ほぼすべての案件が止まってしまいます。
しかし、ここで私が気になったのは
開発チームの管理者として、我々発注側の人間が開発管理者という肩書で入っていたはずです。
もし、リーダーの言っていることが本当に起きているのであれば
その開発管理者が何も言わないのも不自然です。
上記のような話は、誰が聞いてもおかしい話ですし、何も考えずに開発納期を短縮してしまうと、一般的には品質問題に発展してしまいます。
それをわかっていながら何も言ってないのだとしたら、むしろそこが問題です。

そこの点を詳しく聞いてみると、残念ながら開発管理者はコンサル部隊の言いなりで、SIerの主張はほぼ一蹴されているという事でした。

ここまで聞いて一旦、開発チームリーダーは吐き出すものを吐き出して
ある程度すっきりしたようなので帰ってもらって、
私は念のため、この話を持ってきたメンバーに開発チームリーダーの言っていたことがどれほど信憑性のある話なのかを確認したところ、残念ながら、ほぼ事実で特に訂正は必要ないという事でした。

こういった状態が起こっているのが事実なのであれば
放置しておいていいことはありません、いつかどこかで開発チームがダウンしてしまって
実際困るのは我々という事になってしまいます。

そこで私が今回、対処として考えたのが以下の二つです。
①開発チームに見積依頼を出す際に、基本設計書が完成している事をルール化する
②各案件のスケジュールに関しては、案件担当者（我々）が責任を持つこととする

①に期待したのはコンサル部隊が責任をもって要件を開発チームに伝えるようにさせることです。
現時点では口頭やメールなどで伝え、きちんとした形で要件を伝えないため為、仕様変更が発生しても、言った言わないでもめている間に、締め切りがどんどん迫ってきて、うやむやのまま開発期間は変更されないといったような事態が起きていました。
結果、コンサル部隊も自分たちは困らないので仕様変更を頻発させるという状況になっていたので、わかりやすく「当初、この内容で仕様を決めて伝えました。」という事を明示させることで、しっかりと仕様を固め、形に残すようにして、軽々に仕様変更を起こさせず、またその負担を開発チームに被せるようなことはさせないようにしました。

②の目的は、開発管理者が開発チームを守れていないので、各案件の担当者が
そこのチェックを行い、コンサルが勝手にリスケをかけたりしないように歯止めをさせるものです。

どちらの対策にも共通しているのは
開発管理者、コンサル、ともにその当事者に改善を促すようなアプローチはとっていないという点です。
開発管理者はすでにいい年齢となっているので、現時点で開発チームを守れない人間に、守るように伝えても機能しないと考えました。こういう問題は早く手を打たないと開発チームが「あぁ、あの人に言っても無駄だったか」と失望してしまいます。
すると、開発チームとの信頼関係が築けません。
開発管理者が若ければ、育てるという意味でも注意してもいいのですが、
もう40超えている人間にその労力を使うのは無駄だと判断しました。

そして、コンサルに関しても同様です。
彼らがそういう仕事の仕方をしている以上、それをやめろといったところで
それが彼らの仕事のスタンスですし、開発のことがわからない人間に1から教えてやる暇は私にもありませんし、彼らを育てる義理もありません。
であればルール化してしまって、ごまかそうとしたら嫌でも目立つ状況にしてしまえという事です。

そして、この方針を伝える際に自分の部下に伝えておくこともあります。
今回の件は明らかにコンサルがSIerを見下していることに端を発しています。
相手の都合を考えずに、自分都合で相手に無理を強いるのは最たるものです。
これはコンサルティングファーム＞SIerという謎の思考が
コンサルのメンバーに染みついているからです。
残念ながらコンサルティングファームのメンバーにはこの謎思考に陥っている人が結構多いのですが、これには全く根拠がありませんし、
プロジェクト工程における上流にいる人が下流にいる人より偉い
なんて理屈もありません。
そんなことを言ったら、発注側である我々とは目も合わせられないはずです。

こういう思考が身についてしまうと、プロジェクトマネジメントなんて絶対できませんし
大規模プロジェクトになればなるほど、足を引っ張ります。
なので、プロジェクトの上流だろうが下流だろうが、契約形態がどうだろうが
一緒に仕事をする仲間であるという事を考え、どんな人にでも尊敬の念をもって
何かしら学び取れるところがあるはず
という事を心がけて仕事をしてほしいという事を伝えました。

社内SEとして仕事をしていく上で行く行くは
プロジェクトマネジメント
と
組織マネジメント
のどちらかのプロになるかの選択を迫られる時が来ると思いますが
この観点はどちらの道に進むにせよ必須の考え方なので、常に意識しておいてもらいたいところです。