スクラム開発浸透の立役者。新参者2名は何をした！？

開発組織について、「あれが課題なんじゃないか？」「こうすれば解決できるのでは？」といった話をよくしますね。ざっくばらんな会話を通し、良いアイデアをもらったり、私の考えがずれていないかを壁打ちしたり。そんな感じです。

私も壁にぶつかったときに色々と小松さんに相談しています。非常に信頼していて、やや込み入った話題でもオブラートに包まずに会話できるのは助かります。小松さんは私にない視点を持っているので、考え方が参考になります。

同じチームではありませんでしたが、お互いの関心事が似ているんです。社外の勉強会に一緒に出かけたり、二人で社内でアジャイル開発の勉強会を開いたりしました。コロナ禍の前は他のメンバーも含めてよく飲みに行っていて、業務外の話もしていましたね。

お互いにマネジメント側の立場ということもあり、メンバーに関するデリケートな悩みが尽きないのですが、そうした時間を経て、互いを信頼して相談できる間柄になれたと感じています。

教科書的な答えは「スクラムというフレームワークの理解と実践を促す人」ですが、私は「組織が変化するきっかけをつくる人」だと解釈しています。組織がポジティブに変わるための“種火”としての役割です。

いえ、前の会社ではそもそもチーム開発を行なっていませんでした。

カオナビに入社して、フロントエンドエンジニアとして大きなプロジェクトの開発をしていたときに、ある違和感を覚え始めたんです。一人ひとりのメンバーは優秀なのに、なぜかカチッとはまっていないというか……。もっと全体のパフォーマンスを上げるうまいやり方があるのではないかと思っていました。

そんな中、入社して半年ぐらい経った頃に読んだ『カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで』という本に感銘を受けました。そこには、どうすればプロジェクトがうまく回るのかが書いてあって、目が覚めたような気持ちになったんです。

「この本に書かれていることを試したら、チームは変わるかもしれない。ぜひ試したい！」と思い、特に誰かに断るわけでもなく、チームリーダー的な役割をするようになりました。

はい、自主的に、しれっと始めました（笑）。そのチームではすでに、スクラム開発をしていましたが、形骸化してしまっていて。本来の目的や目指す姿に照らせば、むしろ非効率な形になっていたので、「まずはこれを試そう」「これはカイゼンしよう」というように地道に進めていきました。

もちろん、はじめの頃は自分の開発業務と並行してやっていました。ですが、理想を言えば「スクラムマスターは、スクラム開発体制の構築に全力コミットすべき」だという考えも持っていたので、周りにも相談し、次第にシフトさせていきました。

小松さんは2020年春ごろには正式にスクラムマスターになり、実装するよりもチームビルディングやプロジェクトマネジメントの仕事をすることが多くなっていました。フロントエンドエンジニアとしての実力も高かったので、小松さんが開発業務から抜けるのが現場としては悩ましかったと思います。それでも今になって振り返ると、カオナビというプロダクト開発全体のレベルアップにつながる動きになりましたし、それが本人の希望でもあったわけなので、中長期的な視点で見た全体最適だったのだと感じています。

スクラムマスターとなった小松さんと相談しながら、私が開発リーダーを務めた「パルスサーベイ機能を追加するプロジェクト」で導入を進めました。パルスサーベイとは、従業員に対する定期的な簡易アンケートを基に、組織や個人の状態変化を可視化できるようにする取り組みのことで、現在多くの企業が取り入れ始めました。タレントマネジメントシステム『カオナビ』の提供価値を大きくするために、できる限り早く実装したい機能の一つでした。

私が入った時点で最初のリリース分の開発はほぼ完了していました。しかし、企画されたものとはまだ距離があったため、引き続き開発を行う方針が固まったという状況の中で、その開発リーダーを任されることに。チーム内での信頼値づくりと、スピーディーな開発の両立が期待され、簡単なミッションではないと感じました。

それでも試行錯誤しながら、メンバーも巻き込んで仮説を持ってスクラム開発に取り組んだおかげで、チーム開発は早々に軌道に乗ったんです。4カ月ほど手直しを進め、予定に遅れることなく何とかリリースに漕ぎ着けることができました。

そうです。まだ入社して1~2カ月だったので驚きましたが、ありがたいチャンスだと感じました。実装の方針を決めたり、ピンチになった時に踏ん張る姿勢は求められましたね。

本人は何でもなかったように言っていますが、プロジェクトの中では誰かに決めてもらわないと進まない場面があったと思うので、尾張部さんはそういった場面で力を発揮していたんじゃないかな。

そう思います。入社してすぐに頭角を現していました。実は以前、当社ではGitのbranchの運用が最適化されていない状態があったのですが、さまざまな理由があって誰も改善できずにいたんです。

でも、尾張部さんはあるミーティングでその問題に気づくと、次のミーティングには自作の資料を持ってきて、現在のやり方のデメリットと目指すべき理想形をズバッと指摘していました。

勇気がある人だなと思いました（笑）。普段から思い切りのいい尾張部さんがプロジェクトに加わってくれたのは、チームにとってラッキーだったと思います。

私も小松さんと一緒で、カオナビに来るまではチーム開発の経験がなかったので、「スクラムとは何か？」という初歩的な部分から本で勉強して、小松さんと相談しながら実践していきました。

「この場合どうやったらうまくいくと思う？」とか、「自分のチームではこんな感じだけど、そっちはどうやってる？」とか。お互いにスクラムの実践は初めての経験だったので、相談し合える相手がいたのは良かったです。

本で学んだ教科書的な知識をそのまま当てはめるのではなく、自分のチーム向けにローカライズして、カイゼンを繰り返してきました。この手順をしっかり意識して進めてきたからこそ少しずつでも前に進んだのだと思います。

「この取り組みには何の価値があるのだろう？」と考えながら、本に書いてある内容を自分なりに解釈して、自組織にとって最適な方法を考えて試してみる。一般的な知識を得るだけではなく、チームを観察した上で施策に落とし込んでアクションすることを大切にしてきました。

そういえば、小松さんはあまり深刻な雰囲気になることはなかったですね。僕らが向き合ってきた組織課題は結構重いものだったのですが、「しんどいわ〜」と言いながらも、楽しそうでしたよね？

確かに、「やらなきゃいけない」というよりは、チームがどう変わるかを楽しみにしていた部分はあるかもしれない（笑）。

そもそも「実験」みたいなことが好きなんです。例えば会話するときでも、「今この人にこう話したら、こう返ってくるだろうな」と仮説を立ててから喋り出しますね。そうして相手の反応を見て、予想通りだったり、予想外だったり、といったことを楽しんでいます。

そうだと思っています。私が諸事情で数カ月間チームを抜けたたときも、メンバー全員が自走していたのを知ったときは、かなり嬉しかったですね。最終的にはスクラムマスターやリーダーがいなくてもチームが回る、というのが理想ですから。効果が出ているのかなと感じました。

開発をしていた頃は、「自分の成果＝自分のアウトプット」でしたが、マネージャーになってからは「他人の成果も、自分が関わった成果だ」と感じるようになり、幅が広がりました。もちろん全てが私の力だとは思っていませんが、過去のプロジェクトの経験を様々なシーンで適切に活用することでも、成果に貢献できるのだと感じています。

私も開発者だった頃は、自分がエンジニアとして出せる成果の大きさに限界があると思っていました。でも、チームリーダーやスクラムマスターをやってみると、自分のアクションの影響が少なくともチーム内の7～8人には伝わりますし、そのやり方が組織のスタンダードになれば会社全体にもポジティブな影響を与えられる。すごく広がっていくんです。その点で、非常にやりがいを感じています。

スクラム開発をやり始めた頃は、僕らはかなりマイノリティで。ホワイトボードを持ち出して振返りをしている僕らを見て、他のメンバーたちは「あのチームは何をやっているんだろう？」というような雰囲気だったんじゃないかなと。

でも今、社内を見渡してみると、ほとんどのチームがスクラム開発をベースにしています。しかも以前に比べると「このままのやり方でいいのか？」「今より良くするにはどうしたらいいんだろう？」といった会話が聞こえてくるようになりました。それはすごくいい変化だと思います。

スクラムの実践について小松さんに相談にくるリーダーは増えましたよね。

確かに、リーダークラスの人から相談を受ける機会は増えました。先日はチームリーダーになったばかりの人から「スクラムを取り入れてみたけどうまくいかなくて、どうすればいいのかわからない。客観的に見て僕らってどうですか？」と聞かれましたね。まだ入社して1年半ぐらいのメンバーでしたが、チームとしての成果を考えてくれるメンバーが出てきたのは一つの成果だと思います。

小松さんは半年ほど前から私のグループのスクラムマスターもやってくれていて、しっかりプロジェクトを立て直してくれました。小松さんは以前のプロジェクトでのスクラム実践に苦労した経験を活かし、多くのチームへそれを還元することによってリーダーたちの信頼を得ている。これはすごい成果を出しているなと感じます。

パルスサーベイのプロジェクトの後、エンジニアのマネージャーや、あるプロダクトのオーナーなど、引き続きリーダーとしての仕事を任せてもらえるようになりました。

その中で思うのは、マネージャーになったからには、組織レベルの向上に貢献したいということ。心の底から「良いプロダクトをつくりたい」と思っているエンジニアが、活躍できる場をつくりたい。自社プロダクトに限らず、広くHR Tech領域に関して開発メンバーの知識レベルも高めつつ、組織課題を解決していきたいと思います。

先日、海外のある著名なスクラムマスターの勉強会で面白い話を聞いたんです。「スクラムマスターには4つのステップがある。最初はチームにとっての良きスクラムマスターとなる。その次は組織にとって、その次は会社全体にとって、最後は社会にとっての良きスクラムマスターを目指す」と。

私は去年、「チームにとっての良きスクラムマスター」のステップで挑戦して実績を残しましたが、「組織にとっての良きスクラムマスター」はまだこれから。良い変化を生み出すきっかけを組織を横断してつくっていきたいです。

私がそれを聞いて思い浮かんだのは、株式会社Odd-e Japan代表の江端一将さんです。江端さんはスクラムマスターの資格取得に必要なCSM研修の講師で、あのとき得たものが今も活きているのを感じています。こんな風に誰かにポジティブな影響を与え続けられるように、私もスクラムマスターとしてのキャリアを極めていきたいと思います。