おことわり
最初に断っておきますが、私はスクラム開発反対の立場をとっているわけではないです。また、スクラムマスターでもないのでスクラム開発について誤った見解を持っている可能性も大いにあります。
また、これから記載するスクラム開発のペインはあくまでも筆者の独断と偏見に基づいて記載されております。そのため、ペインの原因がスクラム開発ではなく、単にその所属組織の構成員の性質や文化的な要因であることも考えられます。おそらく、スクラム開発でなくても起こり得る問題も多く挙げていると思います。そういった側面も踏まえてご意見あれば忌憚なく反論異論いただければ幸いです。
なぜこの記事を書いたか
チーム内で密なコミュニケーションをとりながら、個人ではなくあくまでもチームとしての成果を重視するスクラム開発の開発フローは、割と個人の活躍と成長機会を奪ってしまい、結果として組織としても開発成果が縮小均衡になってしまうケースがあるのではないかという懸念を持っています。
この投稿ではいくつかの企業でスクラムチーム・非スクラムチームの一員として働いた筆者の実体験を交えつつ、改めてスクラム開発で起こりがちな弊害、、とりわけエンジニア個人の活躍・成長機会という観点で筆者の独断と偏見でまとめてみたいと思います。
何をするにもチーム全体での合意が必要になる
チーム内での協調的なコミュニケーションを大切にすることが多いスクラム開発チームの性質上、受け持ったタスクの設計や実装方針など技術的に意思決定が必要な場面において、アサインされた人が単独で意思決定をすることを厭う雰囲気が生まれがちなように感じます。
行き過ぎた情報同期で作業時間が取れない
チーム内での協調的なコミュニケーションを大切にすることが多いスクラム開発チームの性質上、こまめに随時オンラインで相談することを推奨するケースが多いように思います。それ自体悪いことではありませんが、上述のチーム全体での合意を大切にしがちなことも相まって、チーム全員の作業時間が相談事やモブ作業に取られがちなように感じます。
結局チーム内のボス的メンバーが概ね意思決定してしまう
これ自体はスクラムに限った話ではないですが、意思決定がチーム内での合議制で決まるケースが多いため、必然的に声の大きなメンバーの影響力が高まります。個人に明確に作業や案件を割り振るタイプの進行であればそのような場面は減り、各人が責任を持って意思決定を行いますが、スクラムにおいてはそのような場面は少なくなるでしょう。良し悪しはさておき。
チーム内で異端となったメンバーの逃げ場がない
チーム内でのコミュニケーションが密になりがちなので。チーム内で浮いてしまうとそれだけでかなり居心地が悪くなります。上述の意思決定・情報共有方式により実務にも支障が出やすくなります。１人１プロジェクト方式だと割と緩和されがちなので、優秀だが協調性に乏しいメンバーは割とこちらを好む傾向があると思います。良し悪しはさておき。
チーム内で異端にならないよう個人レベルでの主体的な行動のスケールが小さくなりがち
詳細省略。
モブプロやり過ぎて自分で手を動かす機会がない
モブプロが悪いと悪いと言っているわけでは無いです。モブプロは適切に活用すれば、開発生産性向上・フロー効率性向上・作業の属人性軽減など様々なメリットがあります。
作業が細分化され過ぎてまとまった量の作業を手を動かして行う機会がない
特定の分野の技能を身につけるには、その分野における一定量のタスクを一定の時間をかけて１人でこなしていく経験も必要だと筆者は考えています。が、この作業の進め方はスクラム的にはアンチパターンにされがちで、各開発者は細分化された作業を細々とやることになり、自身の中に開発における一連の体系ができにくい傾向があると感じています。目先のタスク進行って意味では理想的ではありますけどね。
スプリントバックログ以外のタスクをやりにくい
自分に割り当てられたタスクが完了しても、他のスプリントバックログのタスク達の完遂が最優先になるため。自分の仕事終わったら課外作業やったりするのが憚られる風土が生まれがちに感じます。良し悪しはさておき。
グループワーク苦手な人は苦しくなりがち
良し悪しはさておき。
個人の成果が見えにくいので仕事やった感でなんとかするようになる
個人の成果ではなく、あくまでもチームとしての成果へのコミットメントが求められるためです。実際に個人の成果は可視化されないことが多いにも関わらず、会社の評価制度が個人の成果を重んじていたりするため、必然的にやった感をいかに出すかという話に評価ポイントが帰着します。良し悪しはさておき。
納期（ビジネス上の約束）にコミットしなくなる
敬虔なスクラム教信者は厳格な納期から逆算されたスケジュールの遂行に対して嫌悪感を示します。旧来的なウォータフォール開発に対するアンチテーゼと認識されがちなことも相まって、目先の納期達成よりもプログラムの品質であったり、技術的負債を残さないことであったり、エンジニアの稼働を抑えることの優先度が高まります。良し悪しはさておき。もはやスクラム開発のスコープを超えた話かもしれませんが、納期を設けることそれ自体をアンチパターンとする思想も生まれています。しかしながら、このエンジニア組織独自と言っても良い価値観がビジネスサイドの方々と最も相容れないポイントなのかもしれないと筆者は感じています。良し悪しはさておき。
