いいチームなのにがんばりがうまく噛み合わない　誰にも嫌な思いをさせずにチームが前に進むための選択

「スクラムをやっている」とは「前に進むための選択をしている」ということ

椎葉光行氏：ついに始まりましたね、スクラムフェス大阪。全国で、長崎も青森もいて、オンライン開催だし。いろいろなコミュニティもいっぱい参加しているし、名前のとおりスクラムなお祭りという感じですね。僕は今は緊張していますがすごく楽しみにしています。

今年も光栄なことに声をかけていただいて、自分もちょっと心の準備できたのでがんばっていこうかなと思っています。

家族も、今日応援してくれてて、今そーっと娘が玄関を開けて帰ってきました。（笑）。娘たちからは「パパ、発表がんばってね」と言ってもらっているんですが「発表の前はぜんぜん遊んでくれていないけど、がんばってて偉いよ」と上から言われたんで、来週からはいっぱい遊ぼうかなと思っています（笑）。

じゃあ始めていきましょうかね。「みなさんスクラムやっていますか？」やっている人もいるだろうし、あまりやっていないという人もいるだろうし、今からの人もいるだろうし、あとはもうスクラムを超越しちゃいましたという人も中にはいるのかな（笑）。何人か思い浮かぶけど。

僕はいつもこの答えに悩んでいたんですよね。というのも、この10年間いくつかのチームでスクラムをやってきたんですが、きちんとできたことがないんですよね。ウォーターフォールの中で一部スクラムでやっていたりとか、うちの会社はデザイナーチームやQAチームが別の部署なので、チームだけでは完結できなかったり。だから実はきちんとしたスクラムをやったことがないんです。

でも、今日はせっかくのキーノートなので、もう「スクラムやってるよ」と言ってしまっていいかなと思っています。今後はそう言っていこうと思います。怒られたら考えます（笑）。

ただ僕も、スクラムっぽければなんでもスクラムと言っていいとは思っていないんですよ。じゃあどこに自分の中の基準があるんだろうと考えてみると、ウォーターフォールの中でやっていようと、職能横断チームになっていなかろうと、スクラムをやろうとしていて、前に進むための選択をそのチームがし続けているんだったら、もうそれはスクラムをやっていると言ってしまっていいんじゃないかなと僕は考えています。

今日はこの「前に進むための選択」について見ていきましょう。

がんばりがうまく噛み合っていない開発チームをサポート

椎葉と言います。Javaが好きなウェブアプリケーションアーキテクトです。2010年から楽天で働いているので、もう10年超えちゃいました。前半5年はテックリードとして、主に新規サービスの立ち上げとか、立ち上がったサービスの運用とか、改善とかをしていました。その中で、ちょっといいものが作れたらいいなと、スクラムを勉強して実践してきました。

後半5年は働き方をちょっと変えて、経験やスキルを活かして部署内のいろいろなチームに入っていって、そのチームのエンジニアたちと一緒に手を動かしながら、内側からチームを改善していく活動をしています。

アーキテクチャを一緒に考えたり、コンテナ化したり、そういったエンジニアリング的なサポートをする時もあれば、開発プロセスを整えたり、組織開発とか育成についてマネージャーと一緒に考えたりと、チーム作りのサポートをする時もあります。

では「前に進むための選択」とは具体的にどういう感じなのというところですが、2020年からサポートしているチームがちょうどいい例なので紹介します。

2020年7月からサポートしているので、ちょうど1年間一緒にやってきたチームです。最初はそのチームのマネージャーからの、こういう相談でした。

「エンジニアのスキルアップのために力を貸してほしい」と。「サービスをこれからどんどん伸ばしていきたいんだけど、システムはこれまで急いで作ってきたこともあって課題がたくさんある。だからエンジニアたちのスキルをアップして、自走できるチームにしていきたい。そのために、自分たちでも改善しようとがんばっているんだけど、なかなかうまくいかない」

ということでサポートすることになって、しばらくボーッとそのチームを眺めていました。

と言っても、その時すでにリモートワークだったので、「Zoom」や「Teams」を眺めていたという感じです。2週間ぐらい眺めてたのかな。

眺めている中で、こんな感じで開発を進めていることがわかりました。

プロジェクトが並行でいくつか走っていて、プロデューサーがエンジニアたちに個別でタスクをアサインしている。この機能はAさんが一番詳しいからAさん、この機能はBさん、みたいに。エンジニアたちはそれぞれ別々にやっているので、開発が終わったらプルリクエストを出して、それをテックリードとエンジニア出身のマネージャーがレビューしている。

だけどプルリクエストすごく大きいし、指摘することもいっぱいあるし、それでぜんぜんレビューが終わらなくて遅れちゃうから残業でカバーします、みたいな声が聞こえてくる状態でした。

それで、「そっか」と思って、そのマネージャーに伝えたのが「いいチームですね」です。嫌味ではないんですよ（笑）。見ていて気づいたのは、マネージャーを含めて全員が、この状況をなんとかしたいと全力でがんばっているという姿です。

ただ、それをうまく噛み合わせられないでいるというだけでした。だから、そのがんばりがうまく噛み合うように仕組みを整えてあげれば大丈夫ですよと伝えました。

1年間をかけてメンバー全員が自走できるチームになった

ここから1年をかけていろいろやってきて、今はこんな状態になっています。全員が「今は何するべきか」と考えて自走しているし、スキルアップのための仕組みも、開発プロセスに組み込まれています。そのおかげで、システムの課題を解決していく道筋も少し見えてきて、結果として、みんなのがんばりがサービスを伸ばしていくことにつながり始めています。ね、いいチームでしょ？

具体的に、今どんなふうに開発しているかをちょっとだけ紹介すると、並行プロジェクトはやめて一本化しました。タスクをエンジニアに個別アサインするのもやめて、どう開発するかは、エンジニアたち自身で決めるようにしました。ロールはプロダクトオーナーが2人いて、スクラムマスターも2人いて、テックリードがいて、エンジニアがいるというかたちです。

スクラムマスターの2人体制は今回初めてやったんですけど、けっこうおもしろいです。

毎日けっこう状況が変わるサービスなので、朝はデイリースクラムで全員で集まって「昨日こういうことがあった」「システム側でこんな話があった」みたいな話をして、今の状況を確認したら「じゃあ今日は何しようかな」とみんなで再計画します。

そのあと、エンジニアたちはその計画に合わせて「それなら今日はペア（プログラミング）でいこうか」とか「ちょっと難しいから、全員でモブプロ（モブプログラミング）やろうか」みたいな話をして作業を始めます。

プルリクエストが出る時には、もうすでに細かい指摘がペアの中で終わっているし、そもそも内容は、テックリード含めて全員で認識を揃えているので、レビューが出たら、あとは細かいミスがないかなと見るだけで、マネージャーもコードレビューしなくてもよくなりましたし、クオリティも上がりました。

そんなふうに毎日開発を進めています。今日はこれ以上細かい話には踏み込まないので、このあたりに興味ある方はあとで声をかけてください。

サポートミッションの1つは「誰にも嫌な思いをさせない」こと

こんなふうに、彼らはこの1年で開発の進め方をまったく変えてしまいました。でもこれは、ある日突然スパっと変わったわけじゃないんですよね。最初の状態からちょっとずつちょっとずつ「今、自分たちに何ができるんだっけ」と考えて選んできたんです。

並行プロジェクトをやめることを選んで「じゃあ他のプロジェクトはどうしたらいいんだろう」と全員で悩んで「エンジニアのタスクを細かく管理しないほうがいいよね」「だったらどうやって進捗を見せていこう」と悩んで……そんなふうに、悩みながら選択を繰り返して前に進み続けた結果、今この状態になっています。

彼らの中にあるのは、サービスをよくしたいという共通の目標で、それに向かって今も毎日前に進むために「ここを変えていこう」「これはもっとよくできる」という選択をし続けています。

ぜんぜんきちんとしたスクラムにはなっていないんですが、それでも別にいいかなと思うし、これ自体はもうスクラムだなと思いながら見ています。

実は、今回彼らのサポートをするにあたって、自分の中に今までとは違うミッションが1つあったんです。それは「誰にも嫌な思いをさせない」です。

これまでは、やり方変える時には、嫌な思いもしょうがないかなと思っていましたし、実際変えていく時に、嫌な思いさせてたなと思います。でも、それって本当にそうなのかなと。嫌な思いをさせずにできるんじゃないかなと、このサポートに入る前ぐらいに考え始めていて、それをこの1年間考えながら実践してきました。

みんなからの共有でうまくできたんじゃないかなと思いました。いろいろなコメントがもらえたし、定期的にある部署の満足度アンケートの数字もすごく上がったのでよかったです。

これ、めっちゃうれしかったので、このスライドを残り30分見続けるんでも、僕はぜんぜんいいんですけど、進みますかね（笑）。

誰も嫌な思いをしない変化のために「相手に期待をしない」

では、この誰も嫌な思いをしない変化のために、僕がどういうことを考えて実践してきたかをお話ししていきたいと思います。

スクラムはシンプルで、やろうと思えば小学生でもできるし、むしろ子どもたちのほうが上手にできるんじゃないかなと思います。だけど、僕らはいっぱい勉強してるのに仕事でやろうとすると、急に難しい。それはなんでだろうなと考えると、変化が求められるからですね。

この変化が難しい。スクラムは、それをやれば成功を約束してくれるわけでも、問題を解決してくれるわけでもなくて、自分たちの現状をテーブルに乗せて聞いてくるんですよね。「今のあなたたちは、こうですよ」「このままだとうまくいかないけど、どうするんですか」と、けっこう早い段階で持ってきます。

その現状は、これまでのやり方に最適化されているんです。プロジェクトの進め方も、組織のかたちも、それから人の考え方も。だから前に進もうと思うと、これまでのやり方に向き合って変えていく必要がある。これが難しいなと思います。

現状を変えると言っても、いったい何から手をつければいいんだろうとなるんですが、ゆっくり考えてみると自分にできることは、単純に目の前の誰か1人の行動を変えることです。

誰か1人の行動を変えていって、一人ひとりの変化がやがてチームや組織の変化につながっていくのかなと思います。ただそうは言ってもぜんぜん思ったとおりにはいかないんですよね（笑）。

実際に僕も、1歩前進しては壁にぶつかって、もう1歩進んだら振り出しに戻ってみたいな繰り返しでした。ぜんぜん協力してくれない人がいたり、マネージャーには「スクラムはやらなくていい」って言われたり。自分が抜けたあとに、チームが元の開発スタイルに戻っていたこともありました。

その当時の僕は、こういう気持ちだったんです。「なんでわかってくれないんだろう」「この会社でスクラムなんて無理なんじゃないか」「そもそも自分のやっていることって、結局無駄なんじゃないかな」と思っていました。

でも、今はぜんぜんそんなふうに考えないんですよね。今でも思ったとおりにいかないことはたくさんあるんですが、そういう時でも単に「そっかー」って（笑）。「それはおもしろいな」となります。

（次回へつづく）