kintoneユーザーの開発者体験向上のためにチームが発足
永田新太郎氏は2018年にサイボウズに新卒入社した。配属はkintoneの開発チーム。なおkintoneとは、開発の知識がなくても業務に合わせたシステムを簡単に開発できるクラウドサービスだ。
永田氏は入社から2020年3月までkintone新規機能開発チームでプログラマをしていた。加えて、2019年10月からはDX開発チームにて、自社製品のDXについてあれこれと模索した。今回の軌跡は後者がメインとなる。
DXということで、デジタルトランスフォーメーションを思い浮かべた方も多いだろう。しかし今回のDXとは開発者体験（Developer eXperience）のこと。また開発者と言っても、サイボウズでkintoneのサービスを開発する開発者ではなく、サイボウズのkintoneを用いて業務システムを開発する開発者を指す。
先述の通り、kintoneは業務システムを開発するためのクラウドサービスであり、プラットフォームだ。多くの機能をGUIで開発できるものの、プログラムを用いて、より高度な機能開発をすることもできる。例えばREST APIでデータベースにあるデータを操作する、データ操作に紐付いたWebhookを送信する、JavaScriptやCSSでUIをカスタマイズするといったことが可能だ。
このkintoneでは有志が開発した非公式な開発用ツールが乱立していた。一部のツールは自社でメンテナンスしていたが、開発の品質や体制が決して十分ではなかった。そこで「Production Readyな公式ツールが必要だ」という声から、正式なツールを開発するチームとしてDX開発チームが発足した。当時のメンバーは永田氏含めてプログラマが3人。
「理想を達成するために役割分担し協働する」チームワークの実践に向けて
チームが発足して半年から1年弱ほどはJavaScript用のREST APIクライアント開発をしていた。現在ではnpmパッケージで@kintone/rest-api-clientが公開されている。また公式に扱うツールを整理し、リリースやメンテナンスを一元化することも進めていった。
一段落すると、今後チームで何に取り組むかがテーマとなった。メンバーで話してみても、対象や方向性がうまく定まらない。何を基準に優先度を判断すればいいのか、チームが最終的に達成したいことは何か（公式ツール開発は手段にすぎない）を決められないのだ。「軸がないので優先度判断ができないという状況に陥りました」と永田氏は言う。
そこで思い出したのが「理想を達成するために役割分担し協働すること」と定められたサイボウズ流のチームワークだ。手段は定まっているけど、理想があやふやだから迷走するのだと永田氏は気づいた。
しかし、DX開発チームにとって「理想のDX」とは何かと議論しても、発散し続けてしまった。例えば「あのツール／あの体験はよかった」「確かに。分かる分かる」と具体的なところでは共感できても、そこで終わってしまう。永田氏の分析では、全員がプログラマで実際の顧客について知見がなく、決め手を見いだせなかったという。そもそも公式ツール開発だけでいいのかという疑問もわいてきた。
そこで「チームに足りないことは何だろう」と考えた。当時の課題はチームの活動目標や開発戦略が決められないことだった。製品機能を含めた検討が必要ではないかという意見も出た。そうして「PM（プロダクト・マネージャ）の役割がいないのでは？」という仮説にたどり着いた。
「PMの役割が足りないならPMを学べばいい」と永田氏は考えた。そこで製品開発のPMに体験入部することにした。サイボウズでは「体験入部」として、他部署の業務を学ぶために期間限定で異動できる制度がある。開発者が営業やマーケティングを体験する、営業が開発を体験するといった経験を通して、知見を広げられるようになっている。
実際の体験入部では現職PMの活動を直に見ながら、一部の仕事を体験してみた。開発戦略の策定業務にも加わった。ここでは製品の全体戦略から重点領域を絞り、その領域の問題を解決するための機能候補を考えるなど、開発戦略のロジックや流れを学んだ。その中で永田氏が重要だと感じたのは問題設定だ。登場人物や場面を想定し、各機能の効果や影響を考え、優先順位や仕様を判断していく。
PM体験からは多くの学びを得た。永田氏は「これをチームに持ち帰り、DX開発チームを最高にしていくぜ」と意気揚々とチームに戻った。
チームの理想は合議だけでは決まらない、大事なのは役割との関係性
ところが永田氏がチームに戻ると、それぞれが効率良く成果を出していたものの、とりとめのない状態になりつつあった。明確な全体方針やとりまとめる役割が不在のまま、それぞれが関心のある活動に取り組んでいたためだ。
永田氏はPM体験で学んだことを生かそうと試みるも、うまくいかなかった。問題設定して話を進めようとしても「それを調べても成果物を出しにくい」と指摘されると答えに窮してしまった。根本的な問題設定に目を向けたいという気持ちと、成果物を出していかなくてはならないという責務の間で板挟みとなってしまった。
そこで今度は「チームを導くことができる理想があるといい」と永田氏は考えた。しかし合議で意見集約することは難しかった。それなら誰かが中心になり理想を決めるのがいいのではないかと考え、関係者と相談していくうちに「それ、永田君がやったらええんとちゃう？」と促された。結果的に2021年4月から、永田氏がチームの理想を言語化する役割を担うことになった。
ここでPM体験で学んだ「製品戦略とのつながり」を生かすことにした。想定ユーザーの視点で課題や解決策を考え、言語化を試みるも……、これも思うようにいかなかった。つまずいてしまったのは役割だ。全体戦略から位置づけを言語化しても、実際にDX開発チームがどこまで担当するのかがつかめなかった。「DX開発チームがツール開発以上の役割をやるべきではないのでは？」「そもそもツール開発の意味づけも未検討だ……」とますます困窮した。
最終的に永田氏は、「そもそも役割が与えられていない状態だから、理想を考えることに窮するのではないか」と考えた。では「やるべきこと」をチームで決めればいいのかというと、チームの役割は製品戦略での優先度によって決まるのが自然なので「自分たちでは決められない」と立ち往生。
再び永田氏はサイボウズ流チームワーク「理想を達成するために役割分担し協働すること」を思い出し、「そうだ、DX開発チームには明確な役割が与えられてない」と気づいた。そこで製品PMに「このチームの役割は何ですか？」と問うことにした。現在はPMやエンジニアリングマネージャーとともに「絶賛議論中！」だそうだ。
永田氏は最後にこう述べた。「理想と役割の関係性は大事だと思いました。チームの役割や範囲が定まっていないと、チームでやりたいことを納得できる形で見つけられません。メンバーの合議で決められればいいのですが、製品が成し遂げたいこととの親和性が判定できないので、問題の範囲を定めたうえで活動しなくてはいけないということを学びました」
