はてブロ@ama_ch

https://twitter.com/ama_ch

僕がスクラムマスターになった訳

こんにちは。Regional Scrum Gathering Tokyo Advent Calendar 2018 2日目です。前日は@miholovesqさんの8回目のRegional Scrum Gathering Tokyoでした。

僕はサイボウズで2年ほど前にスクラムを導入し、それ以降スクラムマスターとして活動しています。ありがたいことに最近身の回りで「スクラムマスターに興味がある」という言葉をよく聞くようになりました。ですが、同時に「どうすれば良いのか」という声もよく聞きます。
人に「こうすると良いですよ」と言えるほど実績も経験もありませんが、スクラムマスターに興味がある、今後やってみたいという方のために、僕はこうしたよという例を紹介したいと思います。あとRSGT2019で話したいと思っていることも少しだけ紹介します。

今までやったこと

サイボウズに2009年に新卒でプログラマとして入社し、ずっとkintone開発チームでkintoneを開発していました。配属当時は先輩が全員バリバリ開発していて、何のスキルもなかった自分には全員雲の上の存在に見えたことをよく覚えています。自分は何もできない無力な存在なのだから、せめて必死に食らいつこうという気持ちで日々コードを書いていました。

サイボウズのWebアプリケーションエンジニアはサーバサイドもフロントエンドも両方書くのが普通だったのですが、どちらの経験もなかった僕は「両方は無理だな」と早々に悟りました。一方で自分はJavaScriptを駆使したUIの実装に興味が強く、当時はまだあまり例がなかった大規模なWebアプリケーションのフロントエンド設計や、壊れやすいJSをどうテストで保護するか、次々と出てくるツール群とどう付き合うかといった点には情熱を持つことができました。チーム内にフロントエンドを探求するメンバーがあまりいなかったこともあり、「フロントエンドエンジニアとしてチームに貢献する」という方向性を持つことで、なんとか自分の小さな居場所を作ることができたと思っています。

この頃の開発体制は完全にウォーターフォールでした。エンジニアとして生き残ることに必死だった僕はプロセスやチーム運営を意識する余裕はほとんどありませんでしたが、なんとなく組織や企画メンバーに対して反骨意識を持っていました。かといって何か具体的なアクションを起こす訳でもなく、こういう組織の話はリーダーが戦うものだとどこか他人事のように思っていました。

スクラムマスターになった理由

2015年に組織再編があり、当時のチームリーダーがマネージャーになりました。自分は空いたポジションの後釜に収まる形でリーダーになりました。

リーダーになって変わったことは、プロダクト開発に関わる他部署とのやり取りが増えたことでした。日々沢山の会議に出席し、進捗はどうか、締切には間に合うのか、終わらないから調整させてくれ、不具合が大量に出た、ヤバイやつだけ直そう、次の開発要件を見積もってくれ、展示会の説明要員を出してくれ、...そんなことを延々議論していました。

何よりも問題だと思ったのは、こういった議論をいくら繰り返してもちっともプロダクトが良くならないということです。ユーザーの役に立つプロダクトを作るためのチームが、納期を優先して機能を削り、要求が曖昧だ、品質が低いなどと言い争っているのです。肝心のプロダクトそのものに関する話題はほとんど上りません。「チームワークあふれる社会を創る」という理念を掲げる企業の内情としてはあまりにもお粗末だと思いました。

この問題意識がきっかけとなり、スクラムを導入する活動が始まりました。このあたりは前回のRSGT2018でお話ししましたので、よろしければ資料をご覧ください。

www.slideshare.net

エンジニアをやめるという恐怖

自分の役割を変えるということについて、もう少し掘り下げます。

それまで自分はプログラマとしてコードを書いていたので、現場で価値を生むエンジニアこそ最も価値が高い存在だという考えを持っていました*1。コードを書かない自分には何の価値もない。無能なマネージャーになるくらいなら、生涯エンジニアとしてユーザーの役に立つプロダクトを作り続けたい。そんな価値観なので、エンジニアをやめてスクラムマスターになるということは、ある意味では無職になることよりも恐ろしいことでした。

しかも、スクラムマスターがやることを調べてみると、ファシリテーションコーチングといった言葉が並んでいます。エンジニアの自分は一生無縁だと思っていたようなことに取り組む必要もありそうなのです。うまくできるだろうか。コードを書かなくなる不安と相まって、強い葛藤を感じました。

改めて自分がやりたいことに耳を傾けてみました。自分が最もワクワクすることは、「ユーザーの役に立つ良いプロダクトを作りたい」ということでした。

良いプロダクトを作る方法

今までの自分の中では、「良いプロダクトを作る方法は、良いコードを書くこと」という前提を持っていました。しかし直面していた問題は、自分が良いコードを書いても、プロダクトが良くならない*2というものでした。前提が成り立っていないのです。なんということでしょう!

では、良いプロダクトを作るために不足しているものは何でしょうか。良いコードは必要だと思います。ただ、コードは成果物です。つまり、コードはプロダクトと同等の成果物なので、「良いプロダクト=良いコード」となります。「良いプロダクトを作る方法は、良いコードを書くこと」という表現は、「良いプロダクトを作る方法は、良いプロダクトを作ることだ」と言ってることと違いがありません。

これまでと少し見方が変わり、良いプロダクト(コード)を生み出すことができるプロセスが必要なのだという考えに至りました。良いプロセスを備えた良いチームを作れば、良いプロダクトを作ることができる。僕は、良いチームを作ることでプロダクトを作ることができるということに気がつきました。

スクラムマスターは、プロセスにリーダーシップを発揮する役割そのものです。良いプロダクトを作るためにスクラムマスターになる。今では自然にそう考えられるようになりました。

僕にとってのRSGT

いくら心構えをしたところで、実際にスクラムマスターをやってみると無限に疑問が湧いてきます。

  • このやり方で合ってるのか?
  • さっきの受け答えはスクラムとして正しいのか?
  • チームの問題をどう議論すれば良いのか?

今まで社内で誰もやっていなかった役割なので、社内で答えを探すこともできません。解決策として、元々エンジニアコミュニティに出入りしていたので「コミュニティの力を借りる」という発想はすぐに出てきました。

しかし僕がスクラムを始めたのは2016年と遅めで、コミュニティを探してみるとどれがアクティブで初心者も歓迎しているのかがよく分かりませんでした。そんな時に参加したプロダクトオーナー祭り2016でやっとむさんと伊藤さんの講演を聞き、RSGTの存在を知りました。

その後RSGT2017に参加し、こんなにスクラムについて深く学び語り合える場があるのかと衝撃を受けました。実際にコーチズクリニックを利用させていただき、当時の悩みに対する大きなヒントをいただきました。そして、自分がRSGTから得た学びを少しでも還元して誰かの役に立ててもらいたいと思うようになりました。

RSGT2019で話すこと(宣伝)

導入期を乗り越えた自分たち(kintone開発チーム)が、

  • スクラムを導入したは良いけど、まだ加速しきれていない気がする
  • チームが壊れないようスケールさせるにはどうすれば?

といった問題意識のもと、取り組んできた試行錯誤の過程と学びを共有したいと思います。去年スクラムを始めるまでに焦点を当てた「スクラム導入編」でしたが、今回はスクラムをきちんと機能させるための取り組みに焦点を当てた「スクラム実践編」と位置付けています。

セッションプロポーザルはこちらです。

confengine.com

みなさまのご参加をお待ちしております!
なお、サイボウズでスポンサーブースも出展します。ブースには自分や実際の開発チームメンバーもいますので、気軽にお立ち寄りください。サイボウズスクラム事情をたっぷりご紹介します。

おわり

ありがとうございました。明日は川口さんの「RSGTのセッション採択はどのように決まるのか」です。お楽しみに!

*1:今でもその考えは変わっていませんが、自分が別の役割を担うことに納得できています

*2:自分が良いコードを書くための努力が計画やプロセスによって妨げられる、という感覚の方が近いかも