最初に
この記事はスプリント開発を否定しているわけではないことをご承知いただければと思います。
自分の立ち位置
委託開発で、スクラム開発をやることになった
そのうえで、委託メンバーのスキル不足や仕様考慮が懸念されること＋今後委託元の会社でどうやってやっていくかを考えるうえでのブレインとして参画
スクラムマスターは外部のコンサル会社さんでかなりスクラムについては詳しい方
委託元・社内メンバーは、ウォーターフォールしかやってこなかった。
社内でもスプリント開発がいい場面があるけど、どうやって社内としてやっていくか（人件費との兼ね合いもふくめ）考える必要があったので改良案を検討
→検討中未実施なのでコメントなどでご意見をいただけると助かります。（こういったことで困ったこともあるからなども募集中）
随時改定予定
スプリント開発を1.5か月やって感じたこと＆いわれたこと
・知識が多い優秀な開発目線ではやりやすいことが多い
・知識差でやることが異常に増える
・開発未経験者へのやりとりが難しい（受託開発だと難しいところはオブラートに包めた）
・スクラムマスターが現場の阻害になることがある（柔軟なスクラムマスターだと変わる？）
→意図していることはわかるし、重要性もわかるけど・・・
・委託メンバーが多くアウトプットが出せないことがまれにあり、なにやってるの？と言われる
・個々人の予実管理ができず評価がしずらい
・打ち合わせが多い
・長期的に見た課題ができらない（現在のことに集中してしまう）
根本における問題点・解決可能か？
・メンバーの知識不足・向上心（相補問題）
→解決可能かもしれないし、解決できないかもしれない
→私目線は各々で解決してほしいが強制はできない（職業エンジニアとして考えると強制するとパワハラ等にも該当する）
・予実管理ができない
→ストーリーポイントの曖昧さを回避すれば実現可能
・アウトプットがない
→想定外の事象が発生しても現在のアウトプットをレビューで出すことを義務づける（誰にでもわかるように記載する）
・長期的な課題が解決できない
→POがストーリマップを作成して、課題を出すためのスプリント期間を設けるべき）
・打ち合わせが多い
→打ち合わせを減らす
スプリント開発で提唱されている打ち合わせが本当に必要か考える妄信しない
じゃあなぜそうなるか（個人的見解）
スプリント開発が少人数でプロフェッショナルなチームであるべきことが提唱されいているから
→正直、日本ではマッチしずらい（コスト面で非常に大きな負担がかかる）
利益追求を考えると非効率なことが多い
提唱するスプリント開発の手法
流れとして
スプリントプランニング→スプリントレビュー→レトロスペクティブ
を繰り返すことは変更しない
ただし、上記の時間短縮や実行タイミング等を見直す
※ストーリーポイントについて
曖昧さを排除する、例えば、時間で出す、日数で出すなど、あいまいな記載方法をしない
→曖昧だとエンジニア以外のメンバーが理解できないため
スプリント期間が2週間の場合で想定
1週目～2週目
開始時：スプリントプランニング（1時間）
ここでは必ずメンバーがチケットの内容を確認し、質問事項を列挙しておく
POは開始以前に確認が取れるように次のスプリントのチケットを列挙されているようにする。
10分以上、同様の事象で議論した場合、基本的には次のスプリントに乗せる（それまでに議論する）
→今スプリントで行う場合には、そのチケットに到達するまで該当メンバーで議論をすます
終了時：スプリントレビュー（30分）
ここでは必ずメンバーが事前に話す内容を決めておく＋アウトプット資料を作る
レビュー参加者も事前に確認をしておく
議論が発生し10分以上続いた場合、別の機会を設ける
3週目～4週目
開始時：スプリントプランニング（1時間）
終了時：スプリントレビュー（15分）
＋レトロスペクティブ
レトロスペクティブでは、事前にKeep、Proplemを出しておく
この場やることは、Tryとそれをいつまでにやるかを決める。
各メンバーの考え方について
スプリント開発をする上では、大きな問題になるスキル等の問題については
強制ができないことも考慮して、考えないことがよいと思う
ただし、POやリーダークラスが率先して歩み寄る努力をすること
歩み寄る努力とは、アプローチを変えて説明したり、あいつらはエンジニアじゃないからで説明しない
ではなく、最低限概要がわかる状態にしておくことが重要（これがないと決定もできない、上に報告もできないとなってしまう）
個人的に聞きたいことみんなどう思ってるのか？知りたいこと？
スプリントマスターの重要性＋具体的に何をしているのか？
個人的には見るタイミング等がなくわかっていないことが多い
素人目線で見たときには皆がスプリント開発の流れを理解してはまったら不要になってしまうように見えてしまう
→やってる人などいたら知りたいです。
まとめると
アジャイル開発もなんでもそうだがしっかりとカスタマイズ、見直しをして各文化や働き方に合ったやり方を考えていくべきだと思っている。
妄信は、目を曇らせるのでいろいろな意見を聞いて様々なパターンを出していくべきだと感じたのでこんな記事をかきました。
最後に
最初にも記載したがこの記事はスプリント開発を否定しているわけではないことをご承知いただければと思います。
あくまで妄信をする気ではない、スプリント開発を主軸に新たな手法も考えていくべきだと思い、まとめました。
私のチームでやっているやり方が間違っていることもあると思うのでご指摘・ご意見、同じ課題をもっていて皆さんで変えて変わったことなどあれば忌憚のないご意見を頂ければと思います。
しっかりまとめて切れていないと思いますが、そういった点も改善しつつまとめていこうと思うのでご意見や追記してほしいことなどあれば、ご指摘ください。
上記の方法などでやってみたうえでの問題点や課題点などが出てきたら、追記または、記事として起こしなおします。