チームが有機的に動き出すことによる影響

システムの仕事はサッカーのようなチームスポーツと似ています。
チームワークが非常に求められる点や
監督にあたるプロジェクトリーダーの資質で成否が大きく変わる部分などです。

どんなに優秀でも1人が2役こなせないということもあり、
チームワークを求められるシーンは多めです。

例えば、炎上プロジェクトをなんとかしようと考えた場合、
スーパープレイヤーを一人投入したぐらいではどうにもならないことがほとんどで
(要因にもよりますが)
監督を変える、もしくはチーム単位でゴッソリ人を入れ替えるなどの荒療治をしないと
解決できないことが大半です。

今回はこのチームワークにおける
会社間の協調性の重要さについて書いてみたいと思います。

ITプロジェクトには様々な立場の人間が集まっているというのは
以前の記事に書いた通りです。

それぞれに立場も思惑もあるというのは記事に書いた通りですが、
そもそもプロジェクトを成功させるために集められているわけですから
心中はどうあれ、プロジェクトを成功させるというのが表向きの共通ゴールではあります。

で、その共通のゴールに向けて
全員の目線を合わせるというのが、非常に大事なのですが
やはりそこはそれぞれの思いがあるために、容易にはいかないというのが実情です。

ちょっと話をイメージしやすくする為に簡単な絵を描いてみました。

ある程度の規模のプロジェクトになると、こういうチーム構成になることが多いのですが、メンバー間の思いよりも、会社間での思惑が前面に出始めると炎上プロジェクトの兆しです。

例えば

・社内SEがコンサルにすべてをゆだねて思考停止し始める
・コンサルが守備範囲をこれ見よがしに線引きし始める
・SIerが品質ではなく、納期のみ考え始める

勿論、それぞれの会社に思惑があるのは当然なのですが
プロジェクトの只中で実際に働いているメンバーからすると、
そこを超越したスタンスで仕事に臨まないと自分の首が締まることになります。

例えば

コンサルであれば、あからさまな線引きをし始めることで、ユーザーから強烈にプレッシャーをかけられ、胃が痛くなるのは現場のメンバーですし、
SIerであれば品質を度外視して、不具合を呼び込んでしまったら、残業を強いられるのは自分たちです。
社内SEにしても、すべてを外部の人に委ねてしまえば、運用が始まった際に困るのは自分たちです。

チームの関係性が良好で持ちつ持たれつが成立していれば、
変な保身に走らなくて済むため、ストレスも少なく済みますし、
そもそもプロジェクトが炎上しないのですが
チーム関係がいったんこじれると、現場にいる個人の思いとは別に会社の考えが前面に出始め
炎上プロジェクトの火に油を注ぐことになります。

そうなると上の図に載っていない人たちから指示が入ってきたりして
余計混乱するようになります。

例えば

コンサルが自社に「あのプロジェクトやばいっす、もうだめかもしれないです。」と報告すると、会社からは「プロジェクトが失敗に終わっても、こっちの瑕疵にならないように線引きしろ。怪しげなタスクは受けるな」というような指示が出るようになり、プロジェクトの成否は二の次になったりしますし、
SIerのメンバーが
「あのコンサル駄目ですわ。開発経験ないから、指示が見当違いだし、要件定義書も無茶苦茶です。」と報告すると
「じゃあ、下手に忖度しないでいいから、間違ってるってわかっててもその通りに作っとけ。そしたら何かあってもコンサルのせいになるから。」
というような指示が出たりするわけです。

私が過去に関わったプロジェクトでもチーム内の人間関係が上記のようになってしまったケースがあります。
この時、上の図で言うと
コンサルのリーダーであるPさんは完全に線引きモードに入っていましたが
メンバーのQさんは年が若いこともあり、まだそのモードに入っておらず、
なんとかしようと、一人気を吐いていました。
そして社内SEのメンバーであるBさんもそんなQさんの様子を見て、
一緒に頑張ろうという気概に燃えていました。
SIerはリーダーもメンバーもBさん、Qさんと足並みがそろっていたのですが
そこに水を差していたのはコンサルのリーダーPさんでした。

プロジェクトを何とかしようと頑張るあまり、コンサルとしての領分を超えて踏み込みすぎてしまうQさんに対して
「踏み込みすぎるな、他社によけないノウハウを与えるな」
と指示をだし、ブレーキを踏んでいた
のですが、
そんなPさんも、その内ユーザーからのプレッシャーに耐えられなくなってしまい、
ある日、体を壊してリタイヤしてしまいました。

PさんはQさんにブレーキを踏んでいた一方、
非常に優秀な人で、FOXシステムに対しても非常に精通しており、
主戦力となっていたので、彼が戦線脱落するのは非常な痛手だという見方が多かったのですが
意外にもQさんが解放され、今までこそこそとやりとりをしていた
Qさん、Bさん、Xさんラインが、おおっぴらに動けることになった結果
チームとして初めて有機的に動き出すことができるようになり、
今までの体制では対応できなかったような案件もそれぞれが、
それぞれの領分をまたいで活動することでスピーディに対応できるようになりました。

このように、エースがいなくなっても
そのエースがいなくなることにより、逆にチームとして機能し始め、
結果的に良いoutputが得られるようになる。
という事は、結構あることで、
特に炎上プロジェクトなどの非常事態には思わぬ副産物として発生し、
プロジェクト自体を救う事さえあります。

プロジェクトが炎上して、監督交代とばかりに新しく入ってきたプロジェクトリーダーが、こういった隠れチームを見つけ出して、
彼らが機能するように邪魔なものを排除する
というやり方を取ることもあるように、どんな優秀なエースよりも、
2番手3番手の人間で構築された「チーム」の方が圧倒的に優秀な結果を出すという事は
システム開発の世界では意外とあるあるだったりします。

コメント

このブログの人気の投稿

Stories 5話:今までの経緯を知らないまま、運用設計をする

社内のコミュニケーションを活性化!グループウェア導入のススメ

ITにどう向き合う?どう向き合ってもらう?