justInCaseTechnologiesで働くエンジニアメンバーのキャリアに迫るインタビュー企画。
今回はバックエンドエンジニアとスクラムマスターを兼務する矢部が登場。後輩スクラムマスターの橋本（正しくは橋の異体字）がスクラムマスターの役割や、やりがいについてインタビューしました。jicTechだからこそ目指せる自分らしいキャリアについて、胸に秘めた思いを語ります。
プロフィール
矢部秀行 Software Engineer
2011年からSIerにて金融系システムの開発や保守・運用に従事。2021年justInCaseTechnologiesに入社。バックエンド開発を主軸にSaaS型保険システムjoinsureの開発/運用を務める。
橋本隆也 Software Engineer
2017年からパッケージベンダーにてECパッケージの開発やカスタマイズに従事。
2023年にjustInCaseTechnologiesに入社し、バックエンド開発を主軸にSaaS型保険システムjoinsureの開発/運用を務める。
スクラムマスターの役割とは
橋本：これまでのご経歴と現在の業務について教えてください。
矢部：前職では開発メンバーとスクラムマスターを兼務していましたが、最後の方ではスクラムマスター専任というかたちで働いていました。JICTには社会人10年目ぐらいで入社しました。入社当初から開発メンバーとスクラムマスターを兼務する働き方で、今年で約３年になります。
橋本：エンジニアにとって、スクラムを始める時って、それまでとやり方が大きく変わって戸惑う部分があると思うのですが、そのあたり、矢部さんはどう学んできたのか教えてください。
矢部：スクラムについては、前職で当時のスクラムマスターに教えてもらいました。まずはスクラムのイベントに参加して、スクラムについての知識を吸収しつつ、気になったことがあれば自分で調べたり、スクラムマスターに相談したりしてスクラムについて学んできました。その他、会社のサポートを受けて、外部のスクラムマスター研修に参加したこともあります。
橋本：現在担当しているスクラムチームのメンバー構成や主な業務について教えてください。
矢部：現在はフロントエンドエンジニアが1人とバックエンドエンジニアが2人、そこに他部署と兼務のエンジニアが1人で、合計4人のチームです。私はその中でスクラムマスターとバックエンドエンジニアを兼務しています。
橋本：スクラムマスターとしての主な役割はどのようなものですか。
矢部：各イベントでスクラムとしての方向性や位置づけを確認したり、メンバーからの質問に答えたりといったことくらいで、スクラムマスターとしての業務はそこまで多くできていないというのが正直なところです。各イベントの進行についても輪番制でやっています。本来であれば進行は私が1人でやった方が良いのかもしれませんが、輪番制にすることで、チームの状況を客観的に見る機会が得られ、改善点が見つかったりすることもあります。
スクラムは効率の悪い手法？
橋本：ありがとうございます。ちなみに、スクラムマスターとして、これまでに直面した壁や、それを乗り越えた方法があれば教えてください。
矢部：実のところ、まだそこまで手ごわい壁に当たるほどにはスクラムマスターとしてしっかり動けていないのかなと思っています。というのも、「スクラムマスターウェイ（スクラムマスターへの道）」という考え方の中で、スクラムマスターには3段階あると定義されていて、自分のチームの改善に取り組むのがレベル１、レベル2になると複数のチームの関係性を考えられるようになり、レベル３になると組織全体を見られるようになる、とされています。自分はまだレベル1か、2に足をかけられるかどうかぐらいで、自分のチームの中だけ見ていることが多いので、そこまでの壁に当たったという経験はありません。ただ、あえて挙げるなら「スクラムって本当に意味があるのか」というスクラム懐疑派のエンジニアは一定いて、そういう人に「スクラムでやっていこう」という気持ちになってもらうところには一定の難しさを感じています。否定的な意見を持っている人には「スクラムではこういう意図でこういうことやっていて、こういうメリットがありますよ」ということを納得してもらえるまで説明するようにしています。
橋本：デイリースクラムもありますし、振り返りだったり、スプリント後にもいろんなイベントがあるので、人によっては、スクラムは会議ばかり多くて効率が悪いのではないかという意見もあったりしますよね。
矢部：そういう意見に対して、最初の頃は「スクラムの効率は悪くない」という言い方をしていましたが、いろんな人の意見を聞いた結果、最近では「会議に業務の20％程度の時間を費やしているので、確かに効率は悪いかもしれないけれど、話し合いを通して本当に必要なことがクリアになるので、結果的に価値のあることだけに集中できるという意味で効果がある」と伝えるようにしています。確かに会議の時間を作業に振り向ければ作業は進みますが、作業自体に意味が無ければその労力がもったいないので、対話をして確認した上で、意味があることをちゃんとやる、というスクラムの考え方をできるだけ丁寧に伝えるようにしていますね。
橋本：単に作業量を求めるというよりは、真に会社が求める価値あるものを実現する手法がアジャイルスクラムですからね。
対話を生むために
橋本：スクラムマスターにはチーム内外の対話を促進させるという重要な役割が課されていますが、個人的にはそこが難しいと感じています。対話に関して取り組んでいることや、気をつけていることはありますか。
矢部：そうですね。そういう意味では、スクラムイベント自体が対話を促進する仕組みになっていると感じています。スクラムイベントでは、レビューで成果を机上に乗せることで、成果に対するフィードバックがあり、自然と対話が生まれます。また、スプリントプランニングの際に、プランニングポーカー（ユーザーストーリーの完了に必要な工数を見積もる手法）をするわけですが、プランニングポーカーも人によって数字がずれている可能性があるのでそこをすり合わせるために会話しましょうということになる。対話を生む仕組みはスクラムの中にあるので、私としてはその仕組みに乗って、メンバーが話しやすい雰囲気をつくることを意識しています。会議の中で「うーん」って唸っている人がいたら「何かお手伝いできることありますか」って話題を振るとか、そういう感じですね。
橋本：話しやすい雰囲気を作ろうと思っても、なかなか話してくれないメンバーっていると思うのですが、そういう人にあえて話かけてみたり、何かしら矢部さんからアプローチしているという感じですか。
矢部：そうですね。私も熱中するとついつい自分が喋ってしまうんですけど、ちょっと客観的に見えている時にはあまり脈絡なく話を振ったりすることもあります。話をすることで、その人が得意な領域が分かってきますよね。例えばフォームが得意な人は、フォームの話の時にはいろいろと話をしてくれるし、バックエンドの得意な人はバックエンドの話の時に話してくれる、といった感じです。一方で、なかなかしゃべらない人には、「これってどう思いますか？」とか、「自分も理解が追いついてないんですけど、（あなたは）どうですか？」といった形で話を振るようにしています。
橋本：メンバーの様子を常に気にしているんですね。自分からはしゃべらないけど、振られたら結構しゃべってくれる人とか、その人の個性もありますよね。
矢部：そうですね。なので、人によって、ミーティング中に話せなかった場合でも、ミーティング終わった後に「さっきの話、どう思いましたか？」と訊いたり、その後チャットで意見を聞いたりとか、いろんな聞き方があるかなと思います。
橋本：私も、話しやすい開けた会議を設定したいと日ごろから考えているんですけど、やっぱりどうしても話す人に偏りが出てしまうので、議事進行については課題だと感じています。
矢部：私もそのあたりはまだまだ実力不足だと思います。
振り返りでは「気持ち」も付箋に
橋本：コミュニケーションの話が出たので、チームの成長を促進するために、何かアプローチしていることがあれば教えていただきたいです。
矢部：自分が兼務していることもあって、実際に開発がどうなっているかが分かりやすいので、振り返りの場を使って「ここはこうなった方がいいと思う」といった意見を出すっていうことは結構よくやっています。気になっているけど、面と向かって言うと角が立ってしまいそうなときは、振り返りの場で付箋として貼って、他のメンバーがリアクションしてくれたらそれについて話すといったように、振り返りの場を活用することが多いですね。
橋本：現在は1週間単位でスプリントを行っていますが、私のチームではあまり意見が出なくなってしまうことがあります。そのあたりはどのように工夫されているのでしょうか？
矢部：そうですね、私たちのチームは比較的出る方かなと思います。KPT法（行動や結果を「Keep」「Problem」「Try」の3つの観点から整理して活動を振り返るフレームワーク）でいうところのKeep（成果が出ていて継続すること）が出ないことはあるんですけど、Problem（解決すべき課題）は色々出ています。数が少ない時もありますが、少ないなりに、その1つとか2つが結構重要な話だったりして、そこから話が膨らんで、結局振り返りの時間ぎりぎりまで話し合うことになる、みたいなことが多いです。
橋本：私たちのチームではKeepの方がむしろ出やすい印象です。「ここが良かったよ」という話は結構しています。Problemもみんな1つくらいは付箋が書けるんですけど、大体メンバーで共通した内容だったりしますし、数としてもそんなに出なくて。しかも、以前にも課題になっていたものが出てくることもあるので、純粋に新しいものがどんどん出てくるわけではないというのが実情です。
矢部：数が出る理由として、私のチームでは「気持ち」も付箋として書く、というのもあるかもしれません。「これが大変だった！」という心情の吐露もありますし、一方で「この時、●●さんが助けてくれてすごく助かった」など、感謝の言葉も貼るようにしていて、それは以前からあったんですけど、私もそういうことを率先して貼るようにしてきたこともあってか、メンバーがそれぞれ気持ちを発信してくれるようになりました。例えば、「▲▲が大変だった」というコメントがあったときには、「どうしてそこまで大変になってしまったのか」や、「それを解決するためにはチームとしてどうしたら良いか」といった話をするようにしています。単に事実だけではないからこそ、数がそれなりに出ているということはあるかもしれません。
橋本：一枚の付箋から問題を連想して話を膨らませているんですね。
矢部：それと、前回話せなかったことを再度持ち込むこともＯＫにしています。これについては、むしろ私が率先して持っていきますね。「この話、前回は話せなかったけど、やっぱり話したいな」と思ったりするので。毎回出ていて解決していない課題などは、それだけ重要度が高いテーマとして扱ったりもしています。
橋本：ありがとうございます。ちなみに、Problemに対するアクションは実践できていますか。
矢部：これまでは振り返りでTryのアクションを書いても実践できていないことが多かったので、Tryに挙げたものをNotionのデータベースに書き写して、毎回思い出すようにしました。その結果、今は少しできるようになったかなという感じです。
橋本：振り返りの中でアクションしきれなかったものをNotionで再確認しているんですね。そうなると、振り返りは結構ボリュームがありますね。
矢部：振り返りは40分ぐらいですが、毎回「そろそろ時間だからここまでにしましょう」みたいな感じで付箋を全部は見られないことも多いです。基本的には得票数が多いものから見ていきますが、全てを確認できないときは「どうしても話したいものがあれば最後1分で話しましょう」ということで取り上げます。それでも流しちゃう付箋も結構多いです。逆に橋本さんのチームはそういった見返りの時間をどれぐらい取ってますか。
橋本：振り返りは1時間としています。事前に付箋を書いてもらうのではなくて、1時間の中でKeepとProblemを書いてもらっているんですけど、約10分書く時間を設けて、それぞれ最低1枚は書くようにしています。先ほどお話したとおり、「こういうところが良かったよ」っていう感じで、各メンバーの良いところを伝えていくみたいなことが多いです。KeepもProblemも書き終わった後、みんなで読み合わせをします。一通り読み合わせて、その中で得票数が多かったもののリアクションを見ていくという流れでやっています。読み合わせに結構時間を使っていて、アクションを深掘りする前に時間が来てしまうこともあったりしますね。それでも、1つ1つ読み上げることでみんなの認識が揃うことや、直接的に感謝の気持ちを伝えられるのが良いところかなと思ってやっています。ただ、Problemが少ないのが課題です。
矢部：私のチームでは、KeepからTryを出すといった動きがあまりできていないのが悩みです。せっかく「●●さんが良かった」というKeepが出ているのであれば、そういう取り組みをチームの仕組みにする動きができたら理想的だと思いますが、どうしてもProblemの方に目が行ってしまって、Keepに対するアクションができていません。ただ、Keepがたくさん出るので、会そのものは楽しい雰囲気になるんですけどね。
橋本：会話が盛り上がるということも、1つのチームビルディングですよね。私のチームでは、Problemをデータベース化することができていなくて、Figmaに貼り付けたまま、なかなか過去の付箋を振り返るってことがないので、そこは改善したいと思います。
矢部：単純に1週間ごとではなく、1か月の振り返りとかやってもいいかもしれないですね。「これずっと言ってるよね」っていう付箋だけを見る回とか、ちょっと振り返りの手法を変えてみたら面白いかもしれませんね。
スクラムマスターならではのやりがい
橋本：では、改めて、スクラムマスターとしてやりがいを感じる瞬間はどんな時でしょうか。
矢部：さっきもちらっと、「スクラムでやる意味あるの？」って思っている人への対応について話をしたんですけど、私のチームでは実際にスクラム否定派だった人がある時から「このチームに入ったことで、スクラムっていいなって思うようになりました」って言ってくれるようになって、やはりそういう言葉を聞くと、丁寧に説明した甲斐があったなと思います。やりたくないものやっていても楽しくないじゃないですか。だから、そういうポジティブな変化はすごくありがたいです。あとは、「良いチームだね」って褒めてもらえたときも嬉しいです。自分だけでなく、チーム全員が頑張った結果を評価していただけたときに、自分がそこに貢献できたのかなって思えると、やっぱりやってよかったなって思いますね。ちなみに橋本さんは、スクラムマスターになって、やりがいって感じるところってどういうところですか。
橋本：最初のプランニングでスプリントのゴールを決めていくんですけど、 以前は結構終わりらないまま次のスプリントに進んでしまうことがあったんですね。私がスクラムマスターになってから、進捗を管理する人を立てるようにしたことで、チームのメンバーの間にスケジュール通りやり切ろうという雰囲気が生まれて、ストーリーがスプリントで終わるようになってきています。これ自体は私の功績ではなく、進捗を管理してくれているメンバーの功績ですが、デイリースクラムでもチームとしての進捗に対する意識の高まりを感じますし、実際にストーリー通りにゴールできた時には、大きな達成感があります。まだ100％達成できているわけではありませんが、スプリントが順調に進むようになってきたので、少しずつですが、改善が進んでいると思います。スプリント毎に改善点を見つけて、少しずつでも進化させていきたいです。矢部さんにもう一つ聞いてみたかったのは、先ほど、スクラム否定派の方のモチベーションを高めることができたというお話がありましたが、そういう時にはどういう姿勢で向き合っているのでしょうか。
矢部：私は、「これをやることによってこういう効果があるんですよ」という風に、できるだけ一つ一つの行動の理由を丁寧に話すようにしています。姿勢という意味では、「とにかくこれをやれ」というスタンスではなく、「ちょっと一緒にやってみませんか」という感じで話すようにしています。
橋本：無理やりやらせたとしても、それでチームが良い方向に向かうとは思えませんしね。
矢部：対話をする上では、信頼してもらうことも大事だと思います。「この人がそう言うならとりあえずやってみようかな」と思ってもらえるような関係性を築いた上で「こういう理由で、こういうことをやると効果が出るはずなのでやってみませんか」というアプローチができると理想的かなと。
橋本：信頼を得るために気にかけていることってありますか。
矢部：嘘をつかないことですね。それと、思い込みでものを言わないように気を付けています。そのほかに、「自分の考え」と「世間一般で言われていること」、このあたりについてもできるだけ区別して発言するようにしています。とにかく相手に対して誠実でありたいという気持ちが強いです。誠実な態度を貫いていれば、周囲の人もこちらの話を聞いてくれると思うので。
橋本： 大切なことですね。世間一般の考えと自分の考えを区別するって簡単じゃないと思いますが、事前にさまざまな情報をキャッチアップして自分なりに調べた上での発言だからこそ響くものがあるのでしょうね。
矢部：もちろん質問されても答えが分からない時もありますが、そういう時は、「分からないので調べておきます」って正直に言っちゃいます。
橋本：それもまた「誠実な姿勢」ですね。
スクラムマスターを目指す人へのメッセージ
橋本：では最後に、スクラムマスターというキャリアに興味のある人に対して、アドバイスをお願いします。
矢部：スクラムマスターにとって、チームの変化は面白さでもあり、やりがいでもあると思います。チームのメンバーと一緒に改善に取り組んだ結果、半年前に比べてチームに大きな変化が生まれていたり、改善のスピードが加速していることには大きなやりがいを感じます。チームの変化自体はスクラムマスターでなくても感じられますが、やはりスクラムマスターはそういった変化を促す立場なので、変化をより敏感に感じられると思います。開発者とスクラムマスターを兼務していると、どうしてもスクラムマスターの優先順位が落ちやすいんですけど、それでもイベントの時にちょっと話をするだけで、自分も含めてチーム全体で進化できたりするので、そういう変化を促せるというのが1番の醍醐味です。エンジニアがソースコードに興味があるのと同じように、チームの成長に興味を持つのがスクラムマスターだと私自身は思っています。チームを良くすることに達成感や喜びを感じられる人はスクラムマスターに向いているんじゃないでしょうか。
橋本：私もそんな経験ができるように頑張りたいと思います。
矢部：一緒に頑張りましょう。
株式会社justInCaseでは一緒に働く仲間を募集しています。
ご興味がある方はぜひ、採用ページよりお気軽にご応募ください！
