なぜ、この記事を書いたのか
自社サービス/受託案件/客先常駐SESという状況下でWF開発していくうちに
WFのよくないところが目に付くようになってきた
そのため、WF以外の開発手法も経験したいと考え、少し行動を起こしてみた
「開発手法はWF」と決められた状況下で色々な理由で活気を失っているエンジニアの方、
限られた環境であっても、自分たちができる行動を起こすことで自身やチームに変化の兆しが見えるかもしれない
っということでWFで開発しながら不確実性を乗りこなすことを目指した話を記事にしてみました
どうやって実現するか
ある新規立ち上げプロジェクト(開発手法はWF)において、
客先常駐SESで不確実性を乗りこなすチームを作る
何をやったか（ここを詳細執筆予定）
- プロセス設計と計画をした
- 心理的安全性の向上を目指した
- スケジュール管理、進捗管理をした
- リソースマネジメントをした
- バッファマネジメントをした
プロジェクトにおける自分の立ち位置
プロセス設計、チームビルディング、進捗管理、リソース管理、課題管理
上記以外は
要件/仕様はSlerの方やメンバーに頼った
技術面は技術が高いメンバーに頼った
工程とチームメンバー推移
基本設計～運用保守
基本設計：5人
詳細設計：8人
製造：10人＋オフショア
単体試験：10人＋オフショア
結合試験(非機能試験)：10人超え
受入試験：：10人超え
リリース：3人
初期流動：3人
運用保守：1人
プロジェクト全体では最大30名ぐらいになった(ニアショア含めると50名近く)
大きく2つの機能でチームは分割し、そのうちの１チームに適用
3名からスタートして、製造工程では10名までチームまで膨らむ
ニアショアとの製造/試験の依頼、質疑応答、進捗管理も行う
そのうち、うちの会社のメンバーは
新規開発未経験レベル(保守経験や簡単なバグ対応はあり)が5,6人
開発未経験レベルが2,3人
環境
エンドユーザー
┗ Sler
┣ うちの会社(うちの会社の協力会社含む)
┣ 他の協力会社
┗ ニアショア
Sler常駐のため、使用できるツールが制限されている
→特にタスク管理やチャットツールNGが痛かった
結果的に
困ったことを共有しながら前進する自他ともに認めざるを得ないチームになった
自チームはリリース後、予想外や想定外の大きな問題は出なかった(品質面で結果が出た)
ただし、もう一つのチームへはアプローチが足りず、
結果的にプロジェクト全体に影響が出てしまった
一方でこのような取組みによる結果の差異が明確に見えたことがとても大きかった
「開発手法はWF」と決められた状況下で色々な理由で活気を失っているエンジニアの方、
限られた環境であっても、自分たちができる行動を起こすことで自身やチームに変化の兆しが見えるかもしれない
自分にできることから、自分たちでできること、
そして、可能な範囲で少しずつ行動すること
今後も取り組みたいと思います
最後に「この取り組みによる結果」を認識している状況で、同じ状況になったら、どうするか
適用したチームが軌道に乗っている状態のときに
適用しなかったチームへリソースをシフトを検討する
技術面の属人化という面ではなく、管理面の属人化をなくすというイメージ