こんにちは。kintone開発チームでWebエンジニアとして活動している植村です！
kintone開発チームでは、現在kintoneの開発領域ごとにサブチームが存在しています。 今回の記事では、その中で、kintoneのアプリエディタにオーナーシップを持つアプリ設定チームについて紹介したいと思います。
アプリ設定チームは何を作るチームか
アプリ設定チームはその名の通り、kintoneのアプリエディタをより良くすることに責任を持つチームです。 現在kintone開発チームは領域ごとのチーム体制をとっており、自分達のチームはアプリの設定領域を担っています。
kintoneアプリを作成したことのある方にはお馴染みかもしれませんが、アプリのフィールドを変更したり、通知の設定を行ったりする際に目にする、こちらの画面が主な開発対象です （これらをkintone開発チームではアプリエディタと呼んでいます）
このチームは、kintoneアプリを作成する際に、いかに早く作れるか、躓くことなく作れるか...といったことに関心を持ち、よりよいアプリエディタを提供するためにアイデアの探求から開発までを一貫しておこなっています。
元々kintone開発チームでは、探求と開発は別々のチーム体制で行われてきましたが、 次で紹介する背景により、新たに職能横断型のチームにて裁量を持って取り組むようになりました。
チーム発足の背景とチーム構成
kintoneは歴史も長く開発規模も大きい一方で、アーキテクチャや開発体制はモノリシックな構造となっています。
特にkintone開発チームは、全ての領域にまたがったモノリシックなソースコードを対象に開発する必要がありました。 もちろんモノリシックなアーキテクチャ・開発体制にもメリットはありますが、kintoneの開発を加速させる上で、認知負荷の高さやチーム人数が多いことによる、意思決定コストの高さが組織の中で無視できない足枷となってきました。
そこでそういった課題を解決すべく、チームトポロジーの逆コンウェイの戦略をベースに、チームを領域で分割するプロジェクトが発足しました。
アプリ設定チームは、そのプロジェクトの中で最初に領域分割され、立ち上がった開発チームとなります🔥
チーム構成
アプリ設定チームは、以下の体制で活動しています。
（ここからは、リファインメントやバックログなど、スクラムに登場する用語が度々出てきます）
| 職種 | 役割 |
|---|---|
| PM (1名) | プロダクトのゴールに責任を持ち、ゴールに向けてバックログの管理やその優先度付けなども行なう |
| スクラムマスター (1名) | チームの活動を円滑に進めることに責任を持ち、各スクラムイベントの進行や、チーム活動を阻害するインペディメントリストの管理なども行う |
| PG (3名) | バックログアイテム（PBI）の実装、アプリ設定領域のアーキテクチャに責任を持つ |
| QA (2名) | PBIのテストの設計・実施などの品質保証活動を担う |
| ライター (1名) | リリースした機能のヘルプや、kintone内で使われる文言決定に責任を持つ |
| ローカライズ (1名) | kintone内で使われる文言の英語・中国語などの翻訳に責任を持つ |
特徴としては、PMやライターも同じチームに属しており、職能横断型のチームになっています。
そのため、朝会や振り返りなどのスクラムイベントも一緒に行なっており、自分達のチーム内で新機能の探求から開発まで、一気通貫して行うことのできる体制となっています（もちろん、他の領域とのコラボレーション等必要なこともあります）
また、開発の進め方としても、アジャイルコーチやテックリードにも要所でサポートいただき、日々スクラムに則って開発を行なっています。他にも、後で紹介するディスカバリー活動では、デザインチームの方も参加し、一緒にアイデアの探求なども行なっています。
サイボウズではこういったサポートが充実しているため、非常に心強く感じています🙏
このチームでどんな活動をしているか
ではここから、このアプリ設定チームが普段、どのような活動をしているかについて簡単に触れたいと思います。 主に、このチームの活動は二つの大きな活動の枠に分類されます。
- ディスカバリー活動
- デリバリー活動
ディスカバリー活動
ディスカバリーでは、PMやスクラムマスターをはじめ、デザインチームの方なども巻き込んで「次にどんな機能を作ればよいか」分析・探求します。 分析のソースとしては、お客様からの問い合わせ・要望、CSへのヒアリング、ユーザーアンケート、UTなど、多岐にわたる情報源や手法を活用し整理します。
これらの情報をヒントに、次に開発すべき対象を絞っていきます。ある程度何を開発するかの枠組みが決まってくると、「ユーザーストーリー」という形で、 ユーザーにとってどういった価値があるのかを記述する文章の形式に落とし込みます。
[例]フォーム設定で、テーブルを丸ごと削除できる
<役割：kintone アプリ管理者> として、 私は <目的：フォームの作成や変更をするとき、テーブルも丸ごと削除> したい。 なぜなら <利益：テーブル内フィールドを１つ１つ削除する手間をかけずに済み、元々やっていた、フォーム設計の検討や試行錯誤に時間を使える> からだ。
これが開発バックログの候補となります。
候補が出来上がると、その内容をチーム全員で洗練します。これをリファインメントと呼んでいます。
リファインメントでは、作成されたバックログの候補に対して、本当に必要な機能なのか、もっと良い実現方法はないか、等々、職能横断で熱く議論します。
その過程を経て全員が納得する形に洗練された後、その開発にかかる規模を見積り、開発対象の「Readyな」バックログアイテム（PBI）が出来上がります💪
デリバリー活動
デリバリー活動では、ReadyになったPBIを一つずつ、開発していきます。
開発についてはkintone開発チームはモブプログラミングを採用しており、例えば、PGは1日の決まった時間（10:00-16:00）で3人集まって実装を進めています。
仕様やデザインで気になることがあれば、PMやデザイナー、QAと臨機応変にZoomで打ち合わせを行います。
また、新機能などで新たに画面文言が必要になった場合、ライターが並行して文言を作成します。文言ができると、次はローカライズ担当が各言語に翻訳を行います。
こうやって各職能がコラボレーションしながら、PBIが完成に近づいていきます。PGが実装を終えたら、PMが想定したユーザーストーリーが満たせているかを確認し、最後にQAがテストを行います。
テストはQA主体で設計しますが、自動化するもの、手動で行うものに関して適宜PGとも連携しつつ最終的なテスト項目に落とし込みます。
そして全てのテストが終わればリリース可能なPBIとなります🎉
最後はライター主体でヘルプやリリースノートなども完成させ、世の中にリリースします。
リリースした機能がTwitterなどで反響があると、チーム一丸となって開発した甲斐があって、非常に嬉しいですね。
まとめ
今回はチーム活動の概要を紹介しましたが、ディスカバリー・デリバリー活動とも、本来かなりボリュームのある話なので、別途記事にできたら良いなと思っています！
