サイボウズ kintoneチームの「改善」大公開! 新人も巻き込んだスクラム導入の成果とは?

連載「若手エンジニア、どんな活躍してますか?」第4回は「kintone」「cybozu Live」などを運営するサイボウズ編です。「チームワークあふれる社会を創る」を理念として掲げるサイボウズで、若手エンジニアはどんな活躍をしているのか、伺いました。

サイボウズ kintoneチームの「改善」大公開! 新人も巻き込んだスクラム導入の成果とは?

若手エンジニアのための情報メディア「エンジニアHub」。連載「若手エンジニア、どんな活躍してますか?」第4回は「kintone」「cybozu Live」などを運営するサイボウズ編です。「チームワークあふれる社会を創る」を理念として掲げるサイボウズで、若手エンジニアはどんな活躍をしているのでしょう。

取材に応じてくれたのは、若手プログラマの前田浩邦(まえた・ひろくに)さんと、メンター役だった天野祐介(あまの・ゆうすけ)さん。2人が属するkintoneチームでは最近、開発プロセスにスクラム手法を導入しました。スクラムマスターでもある天野さんの思いと、前田さんが体験したチームの劇的な変化とは。

── まずは、自己紹介をお願いします。

前田 グローバル開発本部 kintoneチームで、プログラマとして働いている前田浩邦です。役割としては、なんでもやります。修士卒で、サイボウズに入社し3年目になります。

1前田浩邦さん。2014年新卒入社、現在入社3年目、開発チームで働く。京都大学大学院時代の専門分野は自然言語処理。

──つまりフルスタック?

前田 まあ、そんなところです。

天野 同じくグローバル開発本部で働いている天野祐介です。入社8年目で、kintoneをずっと開発しています。フロントエンドが好きでJS(JavaScript)が好きなプログラマとして活動し、2015年よりチームリーダーになりました。2016年秋からはスクラムマスターとしてチームの継続的改善に取り組んでいます。

2天野祐介さん。入社8年目、PGリーダーから現在はスクラムマスターへ

──ここでスクラムマスターとはどういう役割なのか、説明をお願いできますか?

天野 教科書的には「チームの障害を取り除いて改善サイクルを回す役目」。別の言い方をすると、サイボウズのミッションは「チームワークあふれる社会を創る」ことなので、「開発チームのチームワークを改善していく役割」がスクラムマスターなんだという解釈でやってます。

──スクラムのお話、気になります。のちほどもっと聞かせてください。前田さんは2014年新卒とお聞きしています。まずは、サイボウズに入ろうと思った理由を教えてください。

前田 技術力がありそうな会社で、雰囲気がいい所を探していました。ガツガツしてなくて、のんびりしているところが気に入りました。

──入ってみたら、想像と違っていたりしませんでしたか?

前田 いや、思った通りでした(笑)。インフラからアプリケーションまで手がけている会社はあまりなく、そこも魅力でした。

──先ほど、役割としては「なんでもやる」というお話がありましたが、例えば好きなプログラミング言語はなんですか?

前田 好きな言語は……Common Lispです。これは言わないでおこうと思っていたんだけど。

──たしかにCommon Lispだと先入観を持たれちゃうかもしれませんね。天野さんから見た前田さんはどんな人でした?

天野 京大卒でCommon Lispが好き、と聞いて「変人かもしれない」と思っていましたが(笑)、普通に素直でいい子でしたね。チームで活躍して、コードを書いてくれてます。

先輩プログラマが導入したReact.jsを活用

──最近はどんな技術に取り組んでいますか?

前田 最近取り組んでいたことの一つは全文検索エンジンElasticsearchの導入。全文検索は言語処理に近いので楽しかったですね。もう一つはフロントエンドをReact.jsで一新したことです。React.jsの導入で書きやすく、メンテナンスしやすいコードになってきました。

天野 本人はReact.jsに興奮していました。「これはいい」とか「革命的だ!」とか、そんな事をずっと喋っていました。「急に21世紀になった」とか。

前田 普通に便利だと思いました(笑)。

3

天野 React.jsの導入は自分がスクラムマスターになる前に進めていたのですが、プロダクトに使えるという確信をもった段階で自分の役割が変わり、実際に作るところまでいかなかったのがフロントエンドのエンジニアとして心残りでした。それを前田君が拾って実装に使ってくれた。嬉しかったですね。

前田 導入までは済んでいて、その上に書けばいい段階だったので。React.jsは以前から勉強していたので、「これはチャンスだ」と使うことにしました。天野さんがよく話題にしていたので、追っておこうかなと。

天野 React.jsには以前から興味を持ってくれていましたが、使うように指示をした訳ではなく、自発的に「使います」と言ってきた形です。

前田 それ以前は、Google Closure Libraryを使っていましたが、それに比べるとReact.jsは役割を分担して書けるところがいい。

天野 Closure LibraryはGmailなどGoogleのプロダクトでは現役ですが、世の中的には古くなっています。React.jsだと、(Facebookが開発したアーキテクチャの)Fluxのような概念も組み合わせて使える。制御のための語彙が与えられた状態で開発でき、見通しがとても良くなります。コードも見やすく、再利用もしやすい。

──いわゆるモダンな開発になる?

天野 そうですね。新しい技術には受け入れられるだけの理由があって、そこは追いかけていく考え方です。

イノベーションのための「隙間」を作る

──新技術に取り組む背景には、枯れた技術を使うアプローチだけだと元気が出ないという側面もあったりしますか?

天野 それはありますね。古い技術のままではモチベーションが向上しない。

それに新しい技術に取り組める余力は必要だと思っています。見積もった工数をタスクとして隙間なく100%詰め込むと、もう新しい取り組みを入れる余地はなくなってしまう。そこで7~8割に留めておく。

この余力の部分を「イノベーションの隙間」と呼ぶことにしています。そこを使って改善したり、新技術を評価して導入したりします。変化に対する柔軟性を、計画やチームに組み入れておく。

──隙間がないと柔軟性もないですよね。React.jsは、どんな進め方で導入したのですか?

天野 自分はミーハーで新しいもの好きなので、「これ、入れちゃいました!」みたいなタイプです。React.js導入のときはアーキテクチャの変化が大きく、半年かけて探求して「これでいける」と確信したのですが、他のメンバーとの状況共有が足りず、本格的に使ってもらえるまでに至らなかった。きちんと説明してチームに影響を与えることができなかったという反省があります。

今は「このタスクをやってほしい」と指示をすることは一切ありません。何かを改善したいなら「どうチームをサポートするか」に集中しています。

スクラム導入前は、チームの利害が対立しがちだった

──天野さんは現在スクラムマスターとして活動しています。マネージャーでもプログラマでもない立場から、チームを支援する立場ですが、だとすると「指示せずサポートする」という動き方も役割に沿っているということですね。どういう考えでスクラムマスターになったのですか?

天野 自分がプログラマとしてリーダーになった頃には、複数のチームがそれぞれ要件や仕様書を受け渡す形で仕事を進めていました。PM(プロダクトマネージャー)が次期バージョンの要件一覧を持ってきて「工数を見積もってください」と。

──すると別会社みたいなノリになっちゃう。

天野 そうなんです。例えば、機能をもっと作り込みたいけど、QA(品質保証)からは「開発期間が伸びると品質が下がるから、それ以上作らないでください」と言ってくる。

4

──計画した開発期間が一定だと、開発期間が伸びるとQAの期間が削られちゃうからですね。

天野 製品を良くしていきたいという目的を共有しているのに、チーム同士で利害相反みたいな関係になっちゃうのは理想とは違う。そこを改善するにはどうするか。チームワークの本や開発プロセスの本を読んで考えて、その結果、スクラムを実践することが効果的との結論に至りました。

──その過程でどんなことを考えましたか?

天野 「自分がPMになろう」と思ったこともありますが、それよりみんながそれぞれの役割を果たして、チームとしてきちんと機能するようにすることが大事だと、そう思いました。

以前から、ペアプログラミングとかXPのようなアジャイル開発のプラクティスを取り入れたいとは思っていて。継続的デリバリーの輪講をやったりしていました。当時の自分としては、『アジャイルサムライ』に書かれているように文化的側面でチームをもっと強化できると考えました。

──スクラムマスターになるということは、プログラマの立場から離れるということですよね。そこは悩まなかったんですか?

天野 そうですね、チームの成果を最大化するには、自分がそっち側(スクラムマスター)に行った方がいいなと。プログラマとして活動していた時期にも「自分がフロントエンドをやった方がプロダクトが良くなるな」という思いでやっていましたから。

──その頃のことは、前田さんの目にはどう映ってましたか?

前田 スクラムを始めたのは2016年の10~11月頃でしたが、最初の頃は、単純に「カンバンに付箋がいっぱいあるな」という感じでした。導入直後は「残業は増えて大変だけど楽しいね」みたいな状態でした。今は「やりやすくなった」と感じています。

4

天野 最初のスプリント(開発のサイクルを回す1単位)は“爆死”したよね。残業しまくったあげく終わらない。

今は3ヶ月月単位でリリースして、その中で2週間単位のスプリントが5~6回ある。今(取材日は2月上旬)はバージョンで2回目のスプリント3周目にあたりますが、前回のバージョンで知見がたまり改善されています。アウトプットも、ベロシティ(スプリントで処理した要求)で2~3倍、品質も高い。

最初は大変だったというのは、改善できる問題点がたくさん見つかったということもあるし、スクラムについてチームに十分に説明できていなかったこともありました。そこで、チームのみんなでスクラムのトレーニングを受けることもしました。

──ベロシティが2~3倍ということは、生産性が2~3倍と考えていいでしょうか?

天野 はい。なので数字を見て内心興奮しています(笑)。

──普通に考えて、生産性2~3倍はすごい成果ですよね。いずれ詳しく発表してほしいです!

スクラム導入で「発言する」チームに

──スクラム導入で、現場はどう変化したんでしょうか。

エンジニアHubに会員登録すると
続きをお読みいただけます(無料)。
登録のメリット
  • すべての過去記事を読める
  • 過去のウェビナー動画を
    視聴できる
  • 企業やエージェントから
    スカウトが届く