inayamafumitaka’s official diary

4/22技術書典か-03/プロジェクトマネージメント/人材育成・研修/執筆/書評・・・執筆・講演をお受けします。Twitter(@inayamafumitaka)のDMでコンタクトしてください

プロジェクトマネジメント・インタビュー サイボウズ株式会社 天野様

「突撃!隣のプロジェクトマネジメント!!」第3回目は、kintoneでおなじみのサイボウズで開発チームのスクラムマスターをされている天野さんをお迎えして、どのようなプロジェクト運営をしているか、チーミングの特色スクラムマスターのあり方などについてお話いただくくことになりました。
まずは、天野さんについて。

profile

天野祐介さん
 グローバル開発本部 東京第2開発部 kintone開発チーム
 
 開発されているアプリ
  kintone https://kintone.cybozu.co.jp/
 

 
(あ)天野さん
(い)稲山
(も)森實
(り)森
グラフィック 高柳
撮影 野村
 

■天野さんのお仕事について

(い)天野さんのキャリアについて聞かせてください。
(あ)2009年にサイボウズにエンジニアとして新卒入社しました。入社してからずっとkintoneのエンジニアをしています。サイボウズでは1-2年くらいでプロジェクトチームのエンジニアはどこの役割でもやります。自分では、Webのフロントエンドをゴリゴリ書くのがやっていて楽しいと感じていました。それからはフロントエンドエンジニアと名乗って活動していました。
 

f:id:inayamafumitaka:20180316074358j:plain

 
(あ)2015年かな。チームのリーダーたちが昇進したり、組織体制が変わって僕がリーダーになった。そこから役割が変わったとき、チームリーダとしてチームを見たときに開発プロセスがヤバイ感触があったんです。作れば作るほど負債が増え、バグが増える。これはヤバイなと。
 それをどうにかしたいと思って始めたのがスクラムアジャイルサムライを読んでいたのでスクラムやってみよう、と。
(い)いつぐらいですか。
(あ)1年半~2年前くらいからスクラムに取り組み始めました。ここのところはチームにスクラムを導入したり、他のチームにスクラムのコーチに行ったりしていますね。最近では月一くらいのペースで開発サイドだけでなく営業や法務に対してもスクラムを教えています。最近はスクラムマスターアジャイルコーチとしての活動注力をしています。
(い)(スクラムを取りれたのは)最近なんですね。もっと前から取り組んでいる印象がありました。
(あ)そういわれることも多いですね。ホワイトな印象が世間にはあるのですが、そこは自分自身もギャップを感じていました。実は裏で疲弊しながら作っている…。
(い)スクラムの前はウォーターフォールでパッケージ開発をされていたのですか。
(あ)kintoneは3ヶ月サイクルで出荷までをやっています。ウォーターフォールの小さなプロジェクトが年間に4つある、というイメージですね。(3ヶ月で回していたので)不具合を直して頑張ろうとしているときに次のバージョンの見積もりも始まってしまい「次の地獄が始まる…」という感じでした。
(た)3ヶ月での開発は、次第にそうなっていったのですか。
(あ)最初から3ヶ月サイクルでやっていました。だんだん辛くなってきて、末期には間に合わなくて仕様書に書いてない機能は「不具合」として扱っていたこともありました。
 自分がチームリーダになって、リリース判定がどうとか、脆弱性検証はどうとか、エンジニア以外とコミュニケーションを取る必要が出てきて、非効率なやり取りが多いと感じていました。また、人間関係とかも…。
 サイボウズはチームワークを大事にしているけれど、我々のチームワークは酷いものだな、と。そこがキッカケです。サイボウズで働く以上、自分が一番チームワークに自覚的に動いていくべきだと思ったです。
 

スクラムとの出会い

(い)なぜそこでスクラムを。
(あ)何をすればいいかわからなかった。XPアジャイルサムライはエンジニアの一つの教養として読んではいました。だから、スクラムの存在は知っていました。
 良くない現場をどうする、というときに、アジャイルサムライがヒントになるのでは、と思って。
(た)アジャイルサムライすごい。
(あ)エンジニア観点で書かれているので、プログラマとしても読みやすかったです。当時はTDDとかテストを書くフレームワークも整備されていない状態で、どう品質を高めていくかについても興味がありました。
(い)やってみてどうでしたか。
(あ)やるまでが大変でした。そこは頑張ってコミュニケーションから始めて。でも、始めたときはすごく失敗をしました。
(い)会社が始まってからずっとウォーターフォールで開発をされていた。全員スクラムを知らないじゃないですか。まず何をしましたか。
(あ)ざっくり関係者でいくと、プログラマのチーム、上流にプロダクトマネージャが2−3人、QA(品質保証)チームの分担になっています。
 組織として別の人たちが同じプロダクト作りに関わっています。プロダクト作りに関わる別組織の人とのコミュニケーションが良くないと思ったので、一緒にランチをしたり、一緒にミーティングをしたり、「なにか手伝えることはありませんか」という遠回りなコミュニケーションから始めました。
 困ったときに席が離れていて相談しづらいときには、席を丸ごと移動して相談しやすい環境を作るなど、小さな成功体験を続けることで「敵ではない」という認識をもってもらった
 
  「チームとして良いプロダクトを作るために協力しあいたい」
 
 という理想を伝えました。
 

f:id:inayamafumitaka:20180316074316j:plain

 
 kintoneチームとして理想はなにか、を議論できるように関係者を集めて、理想を語る場を作ってきました。目指す場所は皆一緒、という認識を何ヶ月か掛けて作りました。
 そのころ、私がワークショップおじさんになって。付箋を貼ったりとか、最初は恥ずかしかった。ただ、それは後になって「やってよかった」と思っています。
 

■プロダクト開発について

(あ)グループウェアを作っている会社なので、部署横断でSNSで会話したり、という縦割りを超えてコミュニケーションすることに抵抗のない文化があったことも大きいと思います。
(い)企業のカルチャーですか。
(あ)僕のパーソナリティとして「苦手な人でも声を掛けよう」というのあったけど、企業のカルチャーが大きかったですね
(も)1つのプロダクトを作りに行くゴールが同じだから、というベースが合ったことも影響しましたか。
(あ)そうですね。特に、自分が相手を説得する、という感覚だと、相手を負かさないといけないという感覚が人にあると思うんです。以前、技術を導入しようとしたときにそうやって失敗したことがあったので、負かされる人がいると良くないと思いました。そういうことにならないように、解決する問題に同じ方向を向く、ということを意識していこうと思いました。
(も)「問題対私たち」を地でいっている感覚ですね
 

f:id:inayamafumitaka:20180316074214j:plain

 
(い)プロダクトを作るチームは何人くらいですか。
(あ)主に関わっているメンバーはプロダクトマネージャ3名、プログラマー12人、QA6人くらいです。正社員が数人、松山にいるメンバが5-6人でしょうか。
QAの作業計画を立てるメンバーが3人、別途5-6人くらいでやっています。
(い)全体でメンバーで25人くらいですか。
(あ)そうですね。スプリント計画は25人くらいでやっています。別ラインでプログラマが4人のチーム、2人のチームがあります。4人のチームはメンテチーム。障害があったときや、フレームワークを置き換えるときなど粛々とやってくれる屋台骨の重要なチームです。
 12人の方は新規チームで、それ以外のメンテやトラブルをやってくれるのがメンテチーム。メンテチームは足回りを固めることに意義を感じてくれている人たちが入ってくれている。プロダクションが始まるとそこを維持するために、他人のコードを読まなきゃいけない、クオリティもキープしないと。大変ですよね。割り込みがあるなかで、どう計画を達成していくかも大変。
(あ)新規のチームは12人になったので2つに分けているところです。去年は5人だったのですが新規で7名増えてしまった。そこで分割してしまうと経験者が2名しかいなかったので面倒見切れなくなってしまうので、今まで一緒にやっていました。ただ、それはそれでレビューがし辛いという問題もあったので分けようということに。
(い)コアチームの周りに営業などがいると思いますが規模はどのくらいになりますか。
(あ)ビジネスを考えたり、マーケティングを考えたり、という人たちを含めると3桁になるかも。案件をSIする人たちもいます。特定業界向けにkintoneの使い方を考えている人もいます。
 

f:id:inayamafumitaka:20180316074039j:plain

 
(た)組織の変更は柔軟ですか。
(あ)開発系の組織は若い人が重要なポジションにいるので柔軟さが出てきたな、というイメージがあります。
(い)天野さんの役割は。
(あ)マネージャとしての権限はないです。kintoneはチームとしては大きいので、リーダが3人。
プログラマの中に3人。僕はそのうちの1人です。1on1などある程度役割は委譲されていますが、評価したり、給与出したりという部分はリーダではなくマネージャの役割です。
 最近スクラムを始めて、リーダというのもいらないよね、とう風潮になってきています。
 

■チームの価値観について

(い)コレは大事、というポリシーはありますか。
)プロダクトを良い物にするんだ、という意識は妥協したくないと思っています。スクラムを始めたときも、プロダクトをとにかく良くしたいという思いがありました。自分のプロダクトはバグだらけではなく、最高でなくてはならないし、いがみ合っていてはダメです。
 そういった意味でサイボウズの中では成果を求めると言う点では厳しい面があります。
(い)チームのメンバーとの価値観はあっていますか。
(あ)価値観は合っているとは思います。ただ、確認しているかというと意識的には活動していません。サイボウズには、仕事Barいう制度があり、飲み食いしながら仕事をしてもいい制度があります。それを頻繁に使って、直近のふりかえりや「こういうようにしたい」というのを語る、というのをやっています。
(も)コミュニケーションが価値観を近づけることに繋がっていますか。それとも似た価値観を持っている人を集めているのですか。
(あ)そこに共感してくれそうな人をメンバーに入れています。入ってくれたら、何に向かっていけるかを近づけていきます。透明性のあるコミュニケーションが大事だよ、とか。
 去年新人が入った後の仕事Barで、HRTの原則を話したり、など。
(い)チームの中での暗黙のルールや目指すものを定期的にインストールしていないと流されてしまいがちですよね
(あ)社内のkintoneをtwitterのように使っていて、仕事をしながらつぶやいています。あと、社内にポエムを良く書いています(笑)。
 日報に書くこと、つぶやきやfacebookに書くときなど、会議で発言していない人がいれば「発言できない空気にしているのが悪い」とか「相手を尊重することが大事だよ」とか「ミーティング中にPCを見ていると良くないよ」とか内職をさせてしまう会議の進め方に問題があるよねとか。
思っていても、なかなか言えないことを三者の視点のように言っています。
 

f:id:inayamafumitaka:20180316073944j:plain

 
(あ)ミーティング中にPCを見るな、だと否定される気になりますがポエムだと個人攻撃ではなく「読みたい人は読んでね」という柔らかい感じになるので定期的に発信しています。
(た)文化的に直接指導する感覚がありますか。それとも、誰も言わない雰囲気がありますか。
(あ)良くないことを昔は黙っている空気がありました。目立って対立するのではなく、柔らかく当たっていくコミュニケーションを取る風潮かと。鋭く議論を戦わせてもいいのでは、と思うこともあります。
(た)関係性の成熟度も影響があるかもしれません。
(あ)個人の好みもあり、激しい議論が好きではないのかも。
 

■これからについて

(い)個人のコミュニケーションもハード<ソフトだというのが分かりました。スクラムでリーダシップが突出した人がいなくなっていく。それは組織として考えたときに、天野さんとしては次どうしていこうと考えていますか。次世代を育てるということを考えたことは。
(あ)あまり考えたことはありません。スクラムマスターやりたい、という人にはコーチングという形でお手伝いをしています。チーム内の役割として、自分はなくなりたいと考えています。自分に依存する状態をすぐに無くしたい。
 その点では、良く休むし、席も意識的に外したり、ということもしています。自然と天野がいないから朝会ファシリテートしよう、と自分がないなりにしてくれています。居ないことが普通になれば、誰かがやってくれる。
 自分のチームではスクラムを2-3チームで上手く回れるようにしたいと思っているが、それが終わったらスクラムマスターは抜けて別の役割をしたいと思っています。
 

f:id:inayamafumitaka:20180316073902j:plain

 

 イベントで居なくなるということも多いですが、有給を月2回、年間100%取るようにしています。リーダが取るとメンバーが有給を取りやすくなったり、リーダが早く帰るとメンバーも早く帰りやすなったりするので
(た)スクラムマスターは必要だから自分が担ったのですか。それとも、ミッションやライフワークのどちらでしょうか。
(あ)プロダクトを良くしたいからスクラムをやるスクラムをやるにはスクラムマスターが必要。だったら、やるなら僕、というロジックです。
(た)それは天野さん自身が責任感が強いからですか。
(あ)まずは自分がやる。自分の責任でやるから好きにやる。結果、クビになるならいい、という気持ちでやっています。Team Geekという本の中に、「正しいことをしてクビになるのを待とう」というフレーズがありそれが良いなと思っています。やるべきことをやって結果が出ればいい。それで他社に行っても問題ないと思っています。自律した状態は持っていたいので、会社に雇用されているという状況をなくしてもいいのではと思うこともあります。
(も)自分が独立したときに同じ金額で発注してもらえるかを考えよう、という考え方に近いですね。組織は職能で分かれています。小さいチームから大きなチームまで、プロダクトを作ると言うことは「儲ける」ということに繋がらないといけない。開発チームであれ、市場価値にコミットしないといけない。SIerだとモノを作ることが仕事になってしまうと、価値観が欠落しやすいのですが、チームにそれを意識させる仕掛けをしていますか。
(あ)僕も課題だと思っています。エンジニアに数字に貢献したと感じさせることは難しいです。ビジネスのPMがいて、顧客の意見を集めたりビジネス側からフィードバックしてくれる人がいる。その人から市場の中でプロダクトの売り上げやユーザーの伸びなどを共有してくれる場を活用しています。エンジニアは数字を出すのではなく、PMが正しい数字を出すために取り組む、という感覚かもしれませんが
 

f:id:inayamafumitaka:20180316073708j:plain

 
(い)次世代の方に話を戻すと、マネージャPMは人気がないと言われています。数字にコミットしているので、ちょっと失敗すると叩かれてしまう。そうした中でスクラムマスターをやってみたいという人が出てくるのはすごいな、と思います。サイボウズには何かあるのでしょうか。
(あ)サイボウズの文化があるのかもしれません。最近は、入社前の学生でもスクラムマスターをやりたいという人もいます。面談前にスクラムマスターをやりたいと言ってくれる人もいます。
 スクラムマスターはチームワークをカイゼンする人です。サイボウズチームワークあふれ社会を創る」というミッションがあります。サイボウズの理念に共感しているのかもしれませんね
 
(い)自社のプロダクトを持っていることがバックグラウンドとして強く寄与しているように感じます
(あ)よく言われます。
(た)プロダクトがあることでフォーカスしやす自社の事業に誇りを持つことに繋がっていると。
(も)みんなに同じ目的のある愛が芽生えるのですね
(あ)価値判断がなくて仲良くなると、誰も決定をしなくなります。大きい目的があって、健全な衝突があって、向かっていくための規律があって、その規律をもたらすのもスクラムマスターの大事な役割かと。
 

■コミュニティについて

(り)社外コミュニティで講演しているときのモチベーションは。
(あ)自分が苦労したことは、他人も同じだと思っています。オープンソースにコミットしているのと近いかもしれません。ちょっとでも返していくのが必要かな、と。
 結局プロダクトが作りたいのだと思います。それがやりたくて今までやって来たのがある。最近はコミュニティにも出ていて色々と話をさせていただく機会は多いですが、ことさら注目されるようなことはやっている意識はありません。必要だと思ってやっているだけ、という気持ちです。
(い)天野さんの普通はみんなの普通じゃないのかもしれません。そのギャップがみんなから興味を惹きつけている。そこが光って見えている。
(あ)そこを含めてサイボウズに興味を持ってくれる人がいれば嬉しいです。是非サイボウズに転職していただければと思います。
 

f:id:inayamafumitaka:20180316073625j:plain