スクラム運用で割と詰んでるっていう話 - サラリーマンSEがサイドFIREを目指すブログ

※本記事は筆者の個人の体験談・見解に基づく情報提供です。特定の企業・個人を批判する意図はありません。

私は現在スクラムマスター(SM)兼開発者(DEV)としてシステム開発に住しています。運用がうまくいかないなぁ悩んでおり日々格闘しています。そんな理論どおりにいかない現場のリアル。SM兼DEVとして、板挟みで悩む日々をそのまま書きました。

アジャイルは「アジャイル宣言」が起源になってますので興味のある方はご覧ください。

TL;DR（要約）

プレイングマネージャーとしてSMとDEVを兼務していると

今はテンプレートを整備しつつ、問いかけと小さな成功体験を積ませることを試しています。

スクラムはアジャイル開発の手法の一つで、少人数チームで役割を分担し、反復的に価値を出していく開発手法です。役割をざっくり表すと：

理論上はDEVが自分たちの運用ルールを決め、必要があればSMにエスカレーションして調整する。この自走がスクラムの肝です。

現在のチームは5人（私含む）で運用しています。

ポイントは私がSMとDEVの両方を兼務していること。つまり“プレイングマネージャー”な状況です。

要求整理、仕様調整、メンバーのフォロー、開発、運用ルールの作成……全部私がやっているため、単純に疲れます。判断力や注意力が鈍ってくるのを実感しています。

経験年数が浅く、消極的なメンバーが多い。意見を求めても言葉に詰まることが多く、結局私が調整しないと進まない。

SMの立場では開発に口出しするのは本来避けるべきですが、私が介入しなければ開発が壊れるのでどうしても手を出してしまう。結果としてメンバーが私の顔色を窺うようになり、自律性を失わせている懸念があります。

経験の浅いメンバーに自信を持たせるには成功体験を積ませるのが重要なのは分かっているが、実際にリリースしてユーザーに使ってもらうまでに時間がかかる。短期的にはモチベーション維持が難しい。

まずはあらゆるテンプレートを用意することを考えています。設計テンプレ、レビュー観点、テストケース、PO向けの説明資料など。現状では私が作るしかないので、残業して整備する日々です。

メンバーに「どうしてこういう設計にしたの？」と問いかけて、自分の言葉で説明させる練習をしています。説明できたら素直に褒める。小さな成功体験の積み重ねが自信につながるはずです。

どこまで介入すべきかは現在も悩み中です。原則は「質問を投げて自分で考えさせる」方向。だが技術的に壊れそうな場合は介入も必要――このバランスを試行錯誤しています。

注意点: 完全に自走できるチームを短期間で作るのは難しいです。まずは“自走の種”を蒔くイメージで、小さな仕組みを続けることが現実的です。

スクラムの教科書どおりに行かないのが現場です。人の成熟度や組織の状況に合わせて、スクラムの形を柔軟に変えていくことが大切だと改めて感じています。今は我慢の時期で、テンプレート整備や問いかけを続けていくつもりです。

将来的にチームに改善の兆しが出てきたら、何となくゆるっと（リアルな数字や事例込みで）経過報告を書いてみます。