若手エンジニアのための情報メディア「エンジニアHub」。連載「若手エンジニア、どんな活躍してますか？」第4回は「kintone」「cybozu Live」などを運営するサイボウズ編です。「チームワークあふれる社会を創る」を理念として掲げるサイボウズで、若手エンジニアはどんな活躍をしているのでしょう。
取材に応じてくれたのは、若手プログラマの前田浩邦（まえた・ひろくに）さんと、メンター役だった天野祐介（あまの・ゆうすけ）さん。2人が属するkintoneチームでは最近、開発プロセスにスクラム手法を導入しました。スクラムマスターでもある天野さんの思いと、前田さんが体験したチームの劇的な変化とは。
── まずは、自己紹介をお願いします。
前田 グローバル開発本部 kintoneチームで、プログラマとして働いている前田浩邦です。役割としては、なんでもやります。修士卒で、サイボウズに入社し3年目になります。
前田浩邦さん。2014年新卒入社、現在入社3年目、開発チームで働く。京都大学大学院時代の専門分野は自然言語処理。
──つまりフルスタック？
前田 まあ、そんなところです。
天野 同じくグローバル開発本部で働いている天野祐介です。入社8年目で、kintoneをずっと開発しています。フロントエンドが好きでJS（JavaScript）が好きなプログラマとして活動し、2015年よりチームリーダーになりました。2016年秋からはスクラムマスターとしてチームの継続的改善に取り組んでいます。
天野祐介さん。入社8年目、PGリーダーから現在はスクラムマスターへ
──ここでスクラムマスターとはどういう役割なのか、説明をお願いできますか？
天野 教科書的には「チームの障害を取り除いて改善サイクルを回す役目」。別の言い方をすると、サイボウズのミッションは「チームワークあふれる社会を創る」ことなので、「開発チームのチームワークを改善していく役割」がスクラムマスターなんだという解釈でやってます。
──スクラムのお話、気になります。のちほどもっと聞かせてください。前田さんは2014年新卒とお聞きしています。まずは、サイボウズに入ろうと思った理由を教えてください。
前田 技術力がありそうな会社で、雰囲気がいい所を探していました。ガツガツしてなくて、のんびりしているところが気に入りました。
──入ってみたら、想像と違っていたりしませんでしたか？
前田 いや、思った通りでした（笑）。インフラからアプリケーションまで手がけている会社はあまりなく、そこも魅力でした。
──先ほど、役割としては「なんでもやる」というお話がありましたが、例えば好きなプログラミング言語はなんですか？
前田 好きな言語は……Common Lispです。これは言わないでおこうと思っていたんだけど。
──たしかにCommon Lispだと先入観を持たれちゃうかもしれませんね。天野さんから見た前田さんはどんな人でした？
天野 京大卒でCommon Lispが好き、と聞いて「変人かもしれない」と思っていましたが（笑）、普通に素直でいい子でしたね。チームで活躍して、コードを書いてくれてます。
先輩プログラマが導入した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倍はすごい成果ですよね。いずれ詳しく発表してほしいです！
スクラム導入で「発言する」チームに
──スクラム導入で、現場はどう変化したんでしょうか。
前田 今までより一体感が増した感じです。スクラム導入前は、完全にウォータフォール型で、要件ごとに仕様担当とプログラマが付いて、まず仕様書を作っていた。今は全員が全員の要件を見ている。自分が担当する要件以外もいろいろな要件を見て、「ここはこうした方がいい」「ここはやめた方がいい」と発言する場合もあります。
スクラム自体に「改善していくこと」が組み込まれているので、意見を言いやすい。振り返りも、去年の今頃に比べてずっと現実的になった。「こんなに変わるもんなんだ」と思います。
天野 スクラムマスターになる半年ほど前に「僕はワークショップおじさんになります」と言って、チーム内でコミュニケーションを活性化させる取り組みをしていたんですが、それがだんだん実を結んできたと感じます。
去年の今頃だと、KPT（Keep、Problem、Tryの3要素に分けて振り返る手法）のP（Problem、改善すべき要素）がなかなか登録されなかった。今は書かれている。チームに信頼関係ができあがってきた。
──問題点を口に出して言うと、改善されていくという経験をチームが学習してきた感じですか？
天野 以前は、慢性的な無力感が若干あって。そこは大きく改善されました。
もともとサイボウズは改善の意識は高く、月に1日、エンジニアが改善活動をする「KAIZEN DAY」がありました。CI（継続的インテグレーション）を導入したり、技術的な探求をしたり、リファクタリングをしたり。でも月1日だと、稼働日が20日としてその5％しかないから、やりきれない気持ちもあった。
今は、チームをもっと余力がある状態で回せているので、新たに「改善枠」を作りました。今まで「KAIZEN DAY」でやっていたことをそこでやってます。継続的改善ができるようになって、これは嬉しかった。
──改善枠というのは、他とは明示的に区別しているんですか？
天野 スプリントで「すること」を示すカンバンに付箋が貼ってあるんですが、その中で「終わっているけど直したい」奴とか、「テストを追加したい」奴などを、今まで「その他」という枠に入れていた。それを「KAIZEN」に書き換えた（笑）。
──名前が重要なんですね。
天野 「その他」だと雑務、雑事みたいな印象があるけど、「KAIZEN」だとポジティブです。
「波風を立てていい組織」で、自分の「改善」ポイントも探る
──開発チームは一カ所に集まっているのですか。それとも分散していますか。
天野 開発チームとQAのチームが、東京、大阪、松山に分散しています。
──するとリモートワークへの取り組みも？
天野 スクラムはリモートワークは難しいとも言われていますが、サイボウズとしてはやりたい。例えば朝会をテレビ会議システムのある部屋でやってます。
──前田さんにお聞きしたいのですが、こうした変化の後で、自分自身の働き方の変化はありましたか？
前田 以前は周囲に合わせて「こうやっとけばいいんだな」と流れ作業をしていたところがありました。今は開発のやり方が大きく変わったので、自分の意見を言わないと取り残されちゃう。
天野 リーダーとして見てきた印象では、前田君はここ1〜2年で成長したと思います。スクラムへの取り組みもその一つだけど、自分がどういう状態を理想と考えるのかを、徐々に言えるようになってきた。大事な変化です。
──波風を立てていい、という風土になった？
天野 波風は立てたい。自分からもみんなからも。そうすると、いいチームになる。
ワークショップ活動をしていて「意見はないですか？」と聞いて意見が出ないとき、それは「問題がない」ということではありません。問題を指摘するのに抵抗がある段階ということです。
そこで「この紙に1人5分で意見を書いてください」といって紙を渡し、書いたものを貼り出してみんなで読めるようにする。車座になって順番に感想を聞いていく。
前田 以前は、仕様をPMが書いて、それをプログラマが設計して実装して終わり。それが仕事だと思い込んでいたんですけど。スクラムを導入して、PMから仕様書が来る前提が取り払われて、仕様段階から意見を言うようになりました。
天野 以前のチームではポテンシャルを活かし切れていない感じがあった。開発チームはみんな普通に優秀で、それなのに、なぜこれだけしかできないのかと。
前田 今、個人的には「これだけしかできなかったのか」と思いながらやってます。スクラムだと自分ができたことが可視化されちゃう。そこで、ある意味がっかりする。
──成果が自己イメージより低い場合、自分の中では改善の余地があるということなんですね。
先輩として「部屋の中の象に気がつける人」になりたい
──エンジニアのキャリアという観点での質問ですが、入社3年目の前田さんは、これからの自分の成長についてどんなイメージを持ってますか？
前田 大学院時代の専門が自然言語処理なので、関連した技術が活かせるキャリアがいいなと思っています。最近のElasticsearch導入でも、ログを取って仮説を検証することを繰り返し、そちらの技術を活かせたかなと。
──AIとか機械学習のようなバズワード化したキーワードははあえて使わない説明ですね。でも、実はすごく近い分野ですよね。
前田 インテリジェントな機能があった方がユーザーは広がります。ユーザーに使ってもらえるのでデータも手元にある。これを元に実用的な方向で改善していきたいですね。
──最後に天野さん、これからメンターになるような先輩エンジニアに向けて、アドバイスを一言お願いします。
天野 自分が気をつけているのは、考える余地を残してあげること。指示をしない。答えを提示する話をするより、問題に対して共感して、一緒に改善案を考えるようにしています。
あとは、「仕事の進め方ってこういうもんなんだ」という枠を取り払いたい。「部屋の中の象に気がつける人」（誰もが見えているのに指摘しにくい問題点を指摘できる人の例え）になりたいですね。
──ありがとうございました。
取材：星暁雄=ITジャーナリスト／写真：赤司聡