どれくらい成功しているのか？
ソフトウェアプロジェクトの約7割は失敗だそうだ。失敗と言っても、期間や予算の超過だったり、要求を満たしていなかったりと理由は様々。
ここで疑問。
んじゃ約3割は成功したとして、その後の保守とか機能拡張ってどの程度成功してるんだろ？
チーム体制の変化
って何でこんな事思うかというと、最近のお仕事状況。
当初作った面々が徐々に抜けて、段々と第二世代、第三世代の人に権限・責任が移っていく。それとは別に、今まで同じ場所で働いていた人が離れた地に移っていく(=分散開発になる)。また、ルーチンワーク(だけって訳でも無いが・・・)やってくれる人として派遣さんを雇ういう話もでてる。
つまり、今までコードとノリと文化を理解し、後ろを向けば3分で話が決まる状況から段々とそう簡単にはいかないチーム状況に移り変わりつつある。
チームを取り巻く状況の変化
また環境においても、製品のバリエーションが増えステークホルダーも今以上に増大して、それを捌くのにもマンパワーが割かれるとか、方々から要求が降ってくるとかが考えられる。
そんな状況に変化すると言う事は、徒手空拳でやってきたものから、システマティックなプロセスやマネジメントに移行し始める時期なのかな〜と思う。
どう移行していけば良いか？
んで、最初の話に戻る。最高のメンバ集めました!最高の環境を整えました!プロジェクト成功して納期どおりに作成しました!、んでその後の体制ってどうなんだろう？
会社的にそんな状況をずっと維持してくれるわけでもなく、少しずつ最高のメンバを別のプロジェクトにあてがうわけで、残った人達・後を引き継いだ人達の保守や機能拡張ってどれほど上手くいっているのか、と。
技術職やってるとそんな事考えるの('A`)マンドクセと思うが、プロジェクトの設計・実装なんて3割位の時間で[*1]、例えばテストの方が断然工数が上だ。じゃあ、テストを外部の人に任せるとかすると、3分で話し合って決めて実行していた内容をもっと形式的に仕様書にするとかテスト戦略とかテストに対応する仕様を今まで以上に厳密に書くとか、設計仕様書書いてからいなくなろうよ(愚痴)、とか何だか考える事が膨大になってしまう。
また、BTSやWikiやタスクカード等、様々な角度から検討できるだけの情報がリポジトリにあるのに、それが分析できる状況に無いのも辛い。バグの原因を見て、コミュニケーションエラーなのか実装のミス(=スキルが低い)のか仕様書がタコなのかとかが分かると、チームのパフォーマンスを上げる事も出来るんじゃないかな〜とか思ったりしてるのだが、手が回らない・・・。
と、なんか上手い方法無いかな〜と思案中なのです。
蛇足
な〜んて、最近危機感持ったりする事がしばしば。
「俺、知らね」と逃げられればいいが、今期抜けてった人達が昔自分達が作ったものに引き戻されるのを見てると、その言葉も通用しなさそうだし、何よりそんな言葉を吐いてしまう低級に成り果てるのは嫌だしな〜。
んで、何でこんな事書いたかというと、最近課せられる(チームリーダーをすっ飛ばして上から直接自分に飛んできていると思われる)役割を考えると、隣の部署と交流だって言われて、突然異動させられるんじゃないかと思ったりしてきたので、人が変わっても磐石な体制って何かな〜とか思いを適当に馳せてみた。自分のペアリーダーがその被害にあったし・・・。
*1:設計・実装を軽く見ている訳ではないです、念のため。
