３年ほど前、全国にチェーン展開している小売店の基幹システムの開発プロジェクトが発足しました。そのプロジェクトにＳＥとして担当することになったのが始まりである。
このプロジェクトは当初５名体制でスタートしました。そして、ピーク時には２０名近くのエンジニアが投入され、開発期間も３年を要する大規模なものでした。私は、そこでバッチ系のＳＥリーダーとして携わる事になりました。そこで私が体験した事、気づいた事を論じていきたいと思います。
１．大きく分断された開発体制
このプロジェクトの当初は、５名体制で同じ開発場所で作業を行っていました。ところが、プロジェクトが進むにあたってメンバーが増え今の場所での開発作業が困難になってきました。本来なら、プロジェクト開始前からメンバーが増えた時の開発場所の手配をすべきところでした。ところが、課題として気づいてはいたものの実際に行動を起こすまでにはいたりませんでした。
そこで、今後の開発体制をどうするべきかを話し合った結果、大きく２つに分断することとなりました。１つは、ＷＥＢを中心として画面系の開発チーム、もう一つは夜間更新、集配信を中心としたバッチ系の開発チームとする事になりました。既存の場所には、バッチ系チームが残り、画面系のチームは、そこから電車で３０分ぐらい離れた場所で開発を行うこととなりました。そして、それぞれのチームにプロジェクトマネージャ（以下、ＰＭとする）を配置して、進めて行くことになりました。
分断後当初は、問題なくやっていたのですが、時間が経過するとともにチーム間のコミニケーション量低下、理念の違い、一体感の欠如が生まれていました。
ある時、要件変更が発生し共通のデータ仕様を変更せざるをえない状況となりました。そこで事件が発生しました。互いのチームが保身に走り、自分のチームが有利になるような変更案を提案するようになりました。本来であれば、プロジェクト全体からの視点に立って最適な選択をするべきであるが、チーム間での信頼関係の無さがこのような結果になってしまった。結局、バッチ系のチームが折れる形となって事態は収拾することになった。もちろん、Win-Loseの関係では、互いの関係が改善されるわけでもなく、より一層関係に深い溝ができる事となった。
なぜ、こうような事態になってしまったのか。順に考察することにした。
<1> ＰＭのコミニケーション力不足
まず、それぞれのＰＭのコミニケーション力不足が考えられる。メールや電話等でのコミニュケーションはあったものの、場当たり的でその量は多いとは言えなかった。まず何よりも、互いの事を理解しようという気持ちが欠けていたのが、一番の問題だった。本来であれば、互いに協力関係を築いてプロジェクトを推進していかなければならないのであるが、自己の利益を追求してしまい対立関係に陥ってしまった。
<2>プロジェクトメンバー全員がオーバーワーク稼動
続いて考えられるのは、無理な短納期要望を受けて、プロジェクトメンバー全員がオーバーワークであった。もちろん、お客様からは厳しい低コスト要望があり、ぎりぎりの人数でやらざる得ない状況にあった。メンバーには、過労による疲労感、ストレスがまんえいしていた。そんな状況で、全体を思う心の余裕がなく自己の利益のみしか考えられない状況に陥っていたのであった。
やはり、分散型開発を行う場合は、しっかりとしたコミニケーション計画をプロジェクト内で規定して、理念を共通化させ、信頼関係を構築していく事が重要ではないかと感じます。そして、利害関係が対立した時はどちらが、Win-Loseになるのではなくて、互いがWin-Winになる別の案を模索するべきだと考えます。その為にもメンバーには、全体の利益が個別の利益に繋がることを理念として共有化させることが重要ではないのだろうか。よって、メンバーの精神状態を常に正常な状態に保つ為にも、無理な残業や過度なスケジュールを引いて追い込むのは、やめるべきなのである。
２．長期化する内部進捗ミーティング
このプロジェクトを管理している一人のＰＭは、１日２回の進捗ミーティングをプロジェクト内で行う。業務が開始して１時間後と定時終了後に行うのが日課になっているのであった。このミーティングは、システム開発メンバー全員で行い、その日の進捗状況、遅れや問題点を報告するものであった。形式としては、一人ずつ順番に報告していく形を取っていくものであった。その報告に対して、ＰＭが一人ずつにアドバイスをして問題を解決していく形をとっていた。この手法は、問題点をプロジェクトメンバー全員で情報共有ができ、全員で問題解決をしていく姿勢にしてチームの団結力を高める効果を狙うものであった。
ところが、報告するメンバーが１０人程度いるので、長時間、拘束されるミーティングになってしまった。まず、進捗報告の準備に３０分程度かける。そして、１回のミーティングが平均３０分くらいなのだが、長くなると１時間、２時間と行われる時がある。ひどい時は、１日の半分が進捗ミーティングをしている時があった。特に、スケジュールの遅れや問題が複雑化する程、議論が長期化する傾向にあった。これの弊害として、問題のなかったメンバーやスケジュールの遅れのなかったメンバーまで、この進捗ミーティングが原因で遅れることになってしまった。まさに本末転倒な事態になってしまったのである。
理想の進捗管理とは、「誰もが容易に進捗状況を可視化することができること。問題点があれば情報は皆で共有すること。問題解決は、最小限の利害関係者で解決するようにして、早期に情報公開をすること。」、と私は考えます。前段で紹介した事例のような、定期的に皆を集めてミーティングする事は大事だが、それが頻繁になると本来やるべき作業にも影響が出てくるのは当然である。その為にも、進捗管理を工夫して効果的で時間の掛からないものにするべきだと考えます。
＜最後に＞
分散されたプロジェクトのその後・・・
このプロジェクトは、納品機能をいくつかに分け段階的にリリースをすることになっていました。１段目のリリースは、多少のトラブルはあったものの無事に終えました。そのタイミングでメンバーが減少し、再び分散された開発体制が統合されることになりました。その後、ＰＭ体制も一本化されてチーム間で失った信頼関係も取り戻すようになりました。それは、指揮系統が統一されたのと、プロジェクトが収束することによって残業時間も減り、スケジュールにも余裕が出てきたことがあり、チーム内にもゆとりができた事が大きな要因だったのかと感じる。今までは、分断されたことによってチーム連携（コミニケーション）する工数が発生して、その連携によるトラブルも多発していた。それが、解消されただけでも開発工数の削減に繋がりスケジュールにも余裕が出てきたのであった。やはり、お金を掛けて無理してでも「ワンフロア」で開発体制を構築することが、開発工数の削減に繋がるのではないかと感じました。
ITコーディネータ 森木 康太
