導入「される」側から語るスクラム

morihirok

なんの偶然か、ここ最近私が参加した３つのソフトウェア開発チーム全てでスクラムを採用している、もしくはチームリーダーが「スクラムしよう」と言い始め採用されるという状況でした。圧倒的なスクラム採用率です。

スクラムの話といえばどうチームに導入していったかという視点で語られることが多いと思っているのですが、私のようにいわば受動的な立場でスクラムに参加することになった場合はどう取り組めばよいかという話もあるインターネットだと良いなと思ったので、スクラムしてみた結果私はこう思いました、という話をします。

スクラムは管理者のための手法ではない

まずはじめにスクラム初体験だったころの私が勘違いしていたことですが、スクラムはチームリーダーだったりマネージャーだったりといった立場の人が私たちチームメンバーを管理するための手法ではないです。
ここを見誤るとスクラムで行われる作業や会議、成果物が形骸化してしまい成果が上がらなくなってしまいます。

スクラムはチームメンバー全員が一丸となって課題を解決し成長していくためのフレームワークで、私が実際に取り組んでみた体感ではRuby on RailsとかReactみたいなフレームワークと同レイヤーに存在するものだと感じました。
例えばRuby on Railsは素早くWebアプリケーションを開発できるフレームワークですが、じゃあチームリーダーが「今日からRailsで開発するぞ！」と言ったら今日から素早くWebアプリケーションを開発できるようになるかと言われれば、そういうわけではありません。
チーム全員がフレームワークを継続的に学習し、チームの詳しい人に教えてもらい、時には社外から技術顧問を招いて見てもらうなどしてチームが成熟しはじめてフレームワークの力が発揮できるものです。

スクラムも同様に「今日からスクラムやるぞ！」ですぐに成果が出るものではなく、チーム全員でスクラムを学習しその理解を深めていくことで次第に成果が上がってくるものだと感じました。
使用しているフレームワークをメンバーが理解していなければ成果が上がりにくいし、良くない方向に成果物が向かいやすいということは理解していただけると思いますが、それはスクラムでも同じことが起きます。

私たちもスクラムを学び実践する

ということで、チームでスクラムが採用された以上導入される私たちはスクラムをしっかり学ぶ必要があると感じました。

幸いなことに私たちはインターネット上に無料で公開されている資料を読むことができます。まずはこれらに目を通してみるのがよさそうです。

また、スクラムに関する良書も多数あります。特に下のふたつは読みやすくおすすめできます。

さらに、私たちは現場のコードをより良くするように、スクラムもより良くしていかなければならないと感じました。
チームが抱えている課題や、上手く機能していないと感じるスクラムイベントはないか、またそれはどうやったら解決できそうか、考えて提案し実践し反省する、このループをスクラムでは繰り返していく必要があります。

コードを良くするのはチームリーダだけの仕事ではないのと同様に、スクラムを良くしていくのもチームリーダーだけではなく、私たちの仕事でもあると思いました。

そのためには、スクラムについて継続的に学び、それを現場のスクラムに適用できないか模索していくことが大切です。
参加しているプロジェクトの言語やフレームワークについて業務内外を通じて理解を深めていくのと同様に、スクラムについても学んで行く必要があると思っています。

頑張ってもうまくいかないこともある

これだけ頑張ってもスクラムがうまくいく保証はないです。（実際にうまく行かなかった体験があります）
これもRailsとかReactみたいなフレームワークでも同様に起きる現象だと思っていて、例えばこういったフレームワークは各現場・プロジェクトに最適化されているわけではないので、解決したい課題とフレームワークが微妙にマッチせず開発がうまくいかないなあと感じる瞬間はどなたにもあると思います。

こういった課題感を適切に解決していくモチベーションがチーム全体にないと開発プロジェクトは成功しませんし、それはスクラムも同様なのかなと思っています。

RailsとかReactみたいなフレームワークを使用していると、勉強会とかに行ってそこで会った人と現場ならではの課題感と対策を共有してそれを自分が所属しているプロジェクトに持ち帰って適用してみる、といった営みをすると思うんですが、スクラムも同様の営みをやっていく必要があるのかなと思っています。

スクラムは簡単じゃない

ここまでで「あれ、なんかスクラムってめっちゃ負荷高くない？」という印象を持った方もいらっしゃると思います。
そう思った方は私と握手案件で、私もスクラムは負荷が高いフレームワークだという実感があります。

ただ、私が調べた限りだと不確実性が高いプロジェクトの運用にあたってスクラムの代替になるようなフレームワークは存在していないようです。
また、スクラムを採用しなくても、どのみちチーム開発を行うにあたっては難しいコミュニケーションを効率よく行わなければならないと感じています。
なので、「スクラムがめっちゃ負荷高い」というよりはそもそも「チームで開発するのがめっちゃ負荷高い」なのかなと思っています。

とはいえ、チームで戦わなければ解決できない課題が多数存在するのが現実です。
色々体験した結果、スクラムは適切に採用できればしっかりチームの課題を解決し、チーム全体の実力を底上げできるフレームワークなんだなという実感があるので、採用された場合はチャンスとばかりにしっかりスクラムの考え方を身につけてしまうのがよいのかなと思います。

ついでに以下に今私がいるチームのリーダー @katsumata_ryo さんが Rails Developer Meetup 2019 で登壇したときの資料を置くことで、チームメンバーとしてスクラムが成功した実感の証明とさせてもらえれば幸いです。

導入「される」側の心構えとかノウハウとか、エンジニアリングマネージャーじゃなくても行きやすいスクラムの勉強会とか、まだまだわからないことが多いのでぜひ情報交換していきましょう。

この記事が気に入ったらサポートをしてみませんか？