サイボウズが開発・提供しているビジネスアプリクラウド『kintone』が、右肩上がりの成長を続けている。

2016年3月には契約社数が4000社を突破し、対前年で倍以上の売上を記録。クラウドベースで多様な業務アプリを構築できる点や、カスタマイズ開発の容易さ、そして基幹業務システムとの連携問題をAPIによって解消している点などが、人気の要因となっている。

この好調を支えているのが、10数名の『kintone』開発チーム。別途設けられたQAチームからのフィードバックや、社内のドッグフーディング（製品を開発者自身がユーザとして日常的に使うこと）で出てきた意見を愚直に取り入れ続けることで、製品の利便性と品質向上に務めてきた。

2011年の提供開始から約5年が経ち、開発チームの面々は社内異動や昇進などで様変わりしている。さらに近年は、導入社数増を背景にチームの規模も拡大中。それでも機能開発と改善作業のスピードをゆるめず進めていくには、エンジニア全員がプロダクトオーナー然として動かなければならない。

ともすれば組織の“成長痛”に陥ってしまうような状況を、彼らはどのように乗り越えてきたのか。これまで、そして現在注力している点を聞くと、3つの特徴が浮かび上がってきた。

社を挙げて新しいワークスタイルを試行錯誤しているサイボウズの中でも、とりわけ自律的な製品開発ができているという『kintone』開発陣の取り組みを紹介しよう。

【1】全員をフルスタックエンジニアに育てる開発文化

本題に触れる前に、まずは『kintone』開発のベーシックな環境について説明しておこう。

・GitHub Enterpriseでコードを管理

・リリース頻度は大体3カ月に一度

こうした環境下、『kintone』開発チームでは特にメンバーの担当領域を決めず、機能・要件ごとに【仕様検討】と【実装担当】のチームを柔軟に組みながら開発を進めている。必然的に全員がフルスタックエンジニアであることが求められるが、あえてそうしている理由をチームリーダーの1人である天野祐介氏はこう話す。

「全員でいろんな部分を触って知識共有しておくことが、結果的にプロダクトの改善スピードを高めるからです。当然、フルスタックエンジニアになるための努力を個々人にだけ追わせるわけにはいきませんから、開発はピアレビューを前提に、多くても3名程度で同じ要件を担当しながら知識を継承しています」

また、メンバーのフルスタック化に一役買っているのが、リリース前に社内で行っている2段階のドッグフーディングだ。

第一弾は開発チーム内で、第二弾は社内全体で行うというドッグフーディングは、品質チェックの意味合いもさることながら、誰でも自由にプロダクトへの意見が言える風土を作り上げる一助となっている。もちろん、新機能開発や改善作業を行う、またはその音頭を取るのは、意見を言ったエンジニアになる。

そうすることで、縦割り組織で起こりがちな「決定は偉い人がする」、「担当範囲外のことには口出しをしない」風土にはならず、エンジニアとしてもプロダクト全体への理解が自然と深まるのだ。2012年に新卒で入社以来、ずっと『kintone』開発に携わってきた小林大輔氏はこう言う。

「皆がプロダクトについて意見する風土は、チームのDNAみたいなものです。社長の青野（青野慶久氏）も、よく『サイボウズのことを酒場で愚痴るのは卑怯だ』と話しています。多様性は尊重した上で、1人1人が責任を持って自分の意見を発信する空気感が、エンジニアの自立を促していると思います」（小林氏）

【2】KPT→改善のサイクルを早める工夫

次にチームとして重要視してきた事柄が、改善活動の恒常化だ。

プロダクトをより良いものにしていく上で、こまめな改善は技術的負債を抱えないためにも必要不可欠なものである。それに加えて、『kintone』チームの場合はメンバーにオーナーシップをもってもらう上でも改善活動が一役買っているようだ。

一般的なプロダクト開発の現場では、顧客の要望に応えることや新機能のリリースを重要視するあまり、改善活動が後回しにされがちだ。この負のスパイラルに陥らないために、彼らは

・改善活動はいつやってもいいと明文化

・月イチで「KAIZEN DAY」を設けて機能開発以外の作業に取り組む

などを行ってきた。中途入社でチームリーダーの1人となった長谷川淳氏は、『kintone』チームが持つ“改善熱”の高さをこう証言する。

「直近で行ったチーム合宿も、『全員が自由に改善活動を行う』というテーマで実施しました。僕らはKAIZEN合宿と呼んでいます。これは、現場から『月イチのKAIZEN DAYだけでは足りない！』という要望があったため行いました。そのくらい、チーム全員で品質向上に注力しているという証だと思います」（長谷川氏）

加えて、プロトタイピングで作った機能についても前述のドッグフーディングで広く意見を募るようにしているという。これも、エンジニア個々人のオーナーシップを高めるきっかけになっている。

【3】チーム全体の発信力を高める取り組み

ここまでの情報で、『kintone』はエンジニア主導でプロダクト開発を進める理想的な環境のように思う人も多いかもしれない。だが、ほとんどの企業組織がそうであるように、こうした特徴は常に完璧な状態で機能しているわけではない。

彼らが今、課題と感じているのは、冒頭で記した社内異動や昇進によるチームメンバーの入れ替わりと、事業の成長に伴うメンバー増の合わせ技で、「現場から意見が出にくくなってきた」（天野氏）こと。

同氏いわく、「10人以上のチームになると、それまでのやり方が機能しなくなる」そうだ。

この問題を解消するためにも、リーダーである天野氏や長谷川氏が率先してチームの内外で情報発信をしていくように腐心しているという。いわゆる背中を見せる行為といえる。

「最近は、僕が『ワークショップおじさん』になってチーム皆で意見交換をする場を作ったり、全社員が集まる場になっているラウンジで『kintone』チームの取り組みを発表したりしています。地道に続けている改善活動について、『改善はプログラマーの趣味じゃないんだ』と理解してもらうためにプレゼンしたり（笑）。そうすることで、意見を言うことで何かが変わるという意識を広めたいんです」（天野氏）

「チーム内での情報共有についても、最近は3～4人単位のサブチームでKPTをやっていから全体の振り返りに臨むようにする、月イチで部長と1on1をして個人の課題もKPTで振り返るようにするなどで、現場から意見が出やすいようにやり方を工夫しています」（長谷川氏）

一連の取り組みで目指すのは、風通しの良い仲良しチームを作ることではない。本質的には、全員が「本当にユーザーへ価値を提供できているのかを全員で考えて動く組織」（天野氏）にすることだ。

『kintone』のように、大企業から小規模チームまで、かつ幅広い領域での業務利用を前提としたエンタープライズ向け製品は、ステークホルダーの多さもあってプロダクトマネジメントが非常に難しい。プロダクトマネジャーや営業担当者から言われたことをこなすだけの指示待ちチームでは、到底事業の成長を支えていけない。

だからこそ、「皆が自立して動き、意見し、改善していく」（小林氏）というベーシックな部分を維持していかなければならないと3人は話す。

【1】から【3】それぞれの取り組みを個別に見れば、すでに行っている開発チームは多々あるが、3つを関連させながらチーム全体をHackしていくやり方は、彼らに見習うところが多いはずだ。

取材・文／伊藤健吾（編集部）　撮影／桑原美樹