はじめに
経歴を簡単に紹介させていただく
大手事業会社で営業を約3年経験
その後、IT部門に移動し最初の半年間はウォーターフォール型の開発で主にテスト領域を担当
半年間経過し、なぜか年間予算1億円規模のスクラムマスターを任される
半年間経過し、アウトプットをし始める ←now
スクラムとは
短期間で小さな成果を出し続けるフレームワークの1つ
アジャイルという概念を開発に落とし込む手法である
弊社でのスクラム
PJT化しておらず特定領域に対し、年間予算内で継続開発を行う
当初は3名程度で開発を行う小規模部隊であったが、現在は開発6~7名まで増えている
会社単位
弊社での問題点
スクラムはチームワークを重要視しているため、MTG(イベント)が多い
人数が多いとMTG時間が伸び、全体的な生産性が下がっている。生産性低下が問題である
また、本来固定メンバでスクラムを実現すべきだが、メンバの入れ替えが多く発生している
問題を引き起こす要因
事業要望が、スクラムで対応できる規模感ではなくなっている
スクラムをある領域特化で設けた結果、スクラムという集団に属人化してしまった
その改修を行うためにはスクラムで対応する必要があり、結果として規模が大きくなっている
また、内製エンジニアが少ない環境のため、外部委託で賄っているのも問題である
個人の意見だが、見ていると外部委託のメンバには下記傾向がある印象である
下記傾向がある上で、開発を外部に依存している＋顧客インパクトが大きいシステムのため、切り替えて内製開発を進めるのが難しい
一次請け：元々能力値が高い人が、様々な場所で経験するためにSierを選ぶ
→長期的に同じ環境に留まりたいという思考が薄い
→弊社はその上で大手✖若手が多いため、数年で抜けてしまう
二次請け：給料や環境問題、一次請への憧れから早期で抜けることがある
→前提として長期就業ではなく、安くても経験！の可能性が高い
解決手段はあるのか
①外部委託=悪ではないので、上手く付き合っていく
悪ではないが、コストのデメリットが大きく、離脱リスクもある
開発規模を小さくし、内製化を進める
or 内製チームを並行作成し、規模を小さくしたら内製化を進める
→小規模な案件は内製チームに切り出し、知見を溜めていく
②徐々に内製化を進める
コスト面でのメリットが大きい。内製化=離脱しないではない
③一気に内製化に切り替える
コスト面でのメリットが超大きい。内製化=離脱しないではない
スクラム単位
デイリースクラム
15分程度で実施できており問題なし
昨日何をし、本日はどのタスクに対して、どこまで対応するのか明確にできている
スプリントレビュー
親睦を深める時間として1時間所用している
スクラムでは必要な時間だが、業務に還元できていない
話しやすい関係を作り、業務で発言しやすくすることが目標でもある、、、
意見を言い合う場で、間違える前提で自身が先陣切って会話することが重要
他人ではなく、まずは自身の心理的安全確保→自身がもっと発言する→周囲がもっと発言する
上記スパイラルを作れるよう、自身がもっと話して、もっと発言することを意識する
スプリントリファインメント
タスク整理の場となっている
司会をローテーションしても良いのでは❓
スプリントレビューほどは大事な話しないし、開発内に閉じた会話が多い
意思決定の場でもないし、司会をローテさせても良いと思う
まとめ
雰囲気は良いため、自身で苦労はしていない
ただ、どうしても事業会社-一次請け-二次請けの関係性が邪魔になる
自身がもっと会話し、間違ってでも発言し、発言しやすい雰囲気を作るしかない！
まずはそこ。理想的なスクラムマスターの姿ではないが、
チームワークを重要視する！という意味では、スクラムのあるべき姿を推進できるのでは❓