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

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

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

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

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

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

天野　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（品質保証）からは「開発期間が伸びると品質が下がるから、それ以上作らないでください」と言ってくる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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