量子暗号の研究者から、サイボウズにエンジニアとして入社

もともとは量子暗号の専攻で博士課程を修了し、大学で研究職についていました。

研究はやりがいも意義もあったのですが、10年、20年先の技術ですぐに世の中の役に立つものでもないので…。すぐに世の中で使われるものを作りたい、という思いが、次第に増していきました。

ずっと続けてきた研究に一区切りがついたことで転職を決め、32歳でサイボウズに入社しました。実際のソフトウェア開発経験はほとんどなかったので、エンジニアとしては、半分ポテンシャル採用という形でしたね。

入社はちょうどkintoneのリリースの頃で、入社後はずっとkintoneの開発に携わり、今年で6年目です。6年前の最初のリリースから、試行錯誤を繰り返し、開発体制を作り上げてきました。

現在のkintoneの開発チームは、さらに複数のサブチームに分かれています。現在は、3人いるチームリーダーのうちの1人として、開発半分、マネジメントや調整半分で仕事をしています。

チームをさらに分割し、約3ヶ月ごとに組み替える

複数あるサブチームも、固定的なものではありません。弊社では、1人ひとりが幅広く担当できるように、短期間で組み替えられるチームに属することにしています。

kintoneチームでは、3ヶ月ごとにチーム替えと席替えを行っています。年4回、3ヶ月ごとにリリースするという開発サイクルにしていて、それに合わせてチームも変えています。

そのようにして作られた各チームが、「この3ヶ月はデザイン系をやろう」というように、担当を決めて動いていきます。私の現在のチームは東京2名、大阪2名のメンバーで、API開発に注力しています。

※リモートワークについてお伺いした記事はこちらです。

お客様のことを考慮したリリースサイクルに

3ヶ月という開発のサイクルは、試行錯誤をしながら徐々に固まってきたものです。kintoneは業務用のシステムなので、UIや操作に変更があるとお客様の業務に影響が出るため、あまり頻繁に変更してほしくない、という要望がお客様からありました。

ただ、私たちとしては、より便利になるような機能を追加していきたいですよね。このふたつの意見の間を取り、3ヶ月に1度、変更点をまとめてリリースする方式にしました。

さらに、更新の影響が大きそうなお客様については、事前にそのお客様に更新後の環境を用意し、実際に触ってもらうことで、移行をできる限りスムーズにする工夫もしています。

実際の開発は1ヶ月。ドッグフーティングを繰り返し、品質を向上

業務システムであるkintoneに不具合があると、お客様の業務に支障が出てしまうため、弊社では品質にとても力を入れています。

具体的には、開発サイクルの3ヶ月のうち実際に新機能の開発を行うのは1ヶ月で、残りの2ヶ月はさまざまなテストや不具合の改修に充てています。

1ヶ月で新機能の開発が一通り終わると、まず開発メンバーが自分たちの業務に使っているkintoneをアップデートし、ドッグフーティング(※開発者自身がユーザーとして サービスを日常的に使い、問題点をチェックすること)を行います。

開発メンバーがドッグフーティングする環境は、1ヶ月の新機能開発がひと通り終わった段階ではなく、新機能開発中も含めて常に最新版を使うように自動で更新しています。更新するタイミングは、1日1回とかではなく、製品コードが更新（新機能がマージ）されたタイミングです。

それと並行して、品質保証のメンバー（QAチーム）が1ヶ月ほどかけて、手動でさまざまなテストを実施します。そうして最低限の品質が保証された段階で、次は全社のkintoneがアップデートされ、全社員によるドッグフーティングを行います。

そこで見つかった不具合や改善要望をプロダクトマネージャー（PM）が吸い上げて、必要な部分を改修します。このプロセスを経て、ようやく実際のリリースを迎えます。

ただ、社内の改善要望がすべて反映されるわけではありません。弊社はkintone上でアプリを作成し、そこでチャットのような仕組みを作って、社内の要望を吸い上げています。そしてPMは出てくる要望の中から、現実のお客様にも必要なものだけをピックアップするように気をつけています。

振り返りは「スパンをより短く」「メンバーはより少なく」

チーム内でのコミュニケーションも工夫していて、毎日の朝会だけでなく、2週間に1度の開発メンバー全体での振り返りも実施しています。

以前は開発サイクルに合わせて、3ヶ月ごとに振り返りを行っていました。しかし、3ヶ月前のことはもう「自分ごと」ではなくなってしまいますし、振り返りの反映も遅くなってしまうので、2週間ごとに行うようになりました。

振り返りのメンバーも、以前はチーム全体の15名で実施していました。しかし、その人数になると、発言できないメンバーが出てきます。そのため、現在は4人ほどのチームで振り返りを行い、その内容を全体に共有するという2段階方式に変わりました。

要するに、「期間はより短く」、「メンバーはより少なく」することで、振り返りの密度を高めているんです。

振り返りの「KPT」には、普段からの記録が大事

振り返りの手法もいろいろと試したのですが、今はKPTを使っています。このまま維持したい良かった点（Keep）、改善するべき問題点（Problem）、次の期間にチャレンジしたいこと（Try）の観点で振り返りを行うという方法です。

KPTを行う上で、普段から何か「気づき」があれば、kintone上にメモをしておく文化を作っていることもポイントだと思います。

そうすることで、当日になって「よし振り返るぞ！」と身構える必要もないですし、振り返りのミーティングに必要以上の時間がかかることもありません。

朝会や振り返りミーティング以外にも、開発部の部長と1ヶ月に1回、1対1で話す機会もあります。そこは振り返りやフィードバックをするだけでなく、1人ひとりの今後やりたいことを吸い上げる機会にもなっています。

これも最初は半期に1回でしたが、早くフィードバックしてすぐに改善していけるよう、スパンがどんどん短くなり、今では月に1回実施しています。

QAチームも含めた全チームが、開発の上流から関わる

12人ほどのエンジニアの他に、製品の方向性を決めるPMが2人、デザインチームが3人、品質保証（QA）が16名といったメンバーが、開発に関わっています。それら4つのチームが毎週ミーティングを行い、開発の上流から全チームが関与するようなプロセスを構築しています。

もちろん、それぞれのチームに役割分担はあります。PMの役割は「どのようなユーザーに、どのような価値を提供するか」を決定することです。

すると、次に開発チームが、「その価値をどのような機能で実現するか」を考えます。ここでデザインチームも「その機能にとって最適なデザインとは何か」を考えます。

QAチームも、テストを行うだけでなく、この段階から役割があります。考えられた機能に抜け漏れがないか、セキュリティ的に問題がないか、既存の機能との間に整合性が取れているか、などをチェックしていきます。

立場の違いによる対立を乗り越える鍵は「共通言語」をつくること

この4つのチームは、立場や目指すものの違いから、どうしても対立しやすいんです。

それを防ぐために重要なのは、「共通の言語で語れるようにすること」だと思います。チームごとに、同じ言葉でもイメージする内容が違うので、議論をしてもうまく噛み合わないことが多いんですよ。

共通の言語や認識を作るため、チームをまたいだ勉強会なども開催しています。分かりやすいところでは、「自動テストとは?」というテーマで勉強会をしました。

それ以外にも、開発の方向性全体について合意を形成するための勉強会もあり、そこではインパクトマッピングという手法を使い始めています。インパクトマッピングの見た目はマインドマップに似ていて、中心に「ユーザー数を何%増やしたい」といった目標を書きます。

▼インパクトマッピングのイメージ図

そこから、枝葉を分けていきます。この目標を達成するためには、どのようなユーザーに、どういう行動をとって欲しくて、そのためにはどうすればいいかといったことを整理していきます。

このように全てをひとつの図の上に表現することで、優先順位などを整理しやすくなります。なにをすべきか明確になることで、みんなが納得して開発を進めやすくなってきましたね。

この「みんなが納得している」という点がとても大事で、納得しないまま、「やれと言われたからやる」というのでは、どうしてもモチベーションが上がりません。結果として、全体にとってもマイナスです。

試行錯誤を繰り返して、よりよいチームワークの実現を目指す

こうして作り上げてきた開発体制も、実際はいまでも試行錯誤の最中です。他の会社さんでどうやっているのかも知りたいですし、他のチームの方が上手くいっているなと思うところも多いです。

弊社は「世界中のチームワークを向上させる」ということを、ひとつのミッションとしています。なので、今後ともいろいろと試行錯誤をしながら、自分たち自身のチームワークも向上させていきたいと考えています。（了）