記事のサマリー（TL;DR）
- kintone のシステム管理/外部連携チームが「ユーザー解像度向上」を目的にチームビルディングワークショップを実施
- アプリ管理者・システム管理者・.com 共通管理者の3層の権限整理で、開発チームと実際のユーザー操作の間の認識齟齬が判明
- ワークショップ後、仕様検討の会話で「主語をユーザーに置く」コミュニケーションが定着
kintone 活用企業の情シス・システム管理者が知っておくべき開発現場の視点
本記事で紹介されているワークショップは、サイボウズ社内の開発プロセス改善の取り組みですが、その内容は kintone を導入済みの企業にとっても示唆に富みます。kintone のシステム管理機能は、一般ユーザーが日常的に触れる領域ではなく、フィードバックが集まりにくい特性があります。記事中では「アンケート等のフィードバックに頼るには限界がある」と明示されており、開発チーム自身がユーザーの業務文脈を能動的に再構築する必要があると述べられています。
日本企業では kintone を現場主導で拡張するケースと、IT部門が統制しながら運用するケースが混在しており、システム管理者にかかる運用負荷や権限設計の複雑さは組織規模によって大きく異なります。kintone の権限体系（アプリ管理者 / システム管理者 / .com 共通管理者）を正確に理解したうえで、専用の管理 UI や運用ルールを設計することが、安定した kintone 活用につながります。特に、kintone の標準管理画面だけでは情報が見づらいと感じる場面では、権限体系を踏まえた補完的な管理インターフェースの設計が有効な選択肢になります。
詳細
はじめに：課題の背景
サイボウズで kintone のプロダクトエンジニアとして働く kura 氏による本記事は、システム管理/外部連携チームが実施したチームビルディングの一環として行われた、ユーザー理解ワークショップの全体像と成果を紹介するものです。
プロダクトエンジニアの役割はユーザーに届けられる価値を作ることですが、日々の業務は「製品機能の検討と開発」であり、システム管理者の実務そのものに向き合う機会は限られています。加えて、kintone のシステム管理機能は全ユーザーの中でも一部の顧客しか操作しない領域であるため、他機能と比べてフィードバックが少ない構造的な課題があります。
こうした背景から、チームは「システム管理者の徹底的解像度上げワークショップ」と題した取り組みを行いました。
Part0（事前準備）：kintone SIGNPOST によるインプット
ワークショップに先立ち、チームメンバーは kintone が導入企業向けに提供している体系的なガイドコンテンツ「kintone SIGNPOST」を通じて事前学習を行いました。
kintone は自由度の高いクラウドサービスであるため、効果的な活用には一定の「コツ」が必要です。SIGNPOST は、kintone の概念理解から業務アプリ構築、継続運用までを実践ガイド形式でカバーするコンテンツです。
事前インプットのテーマは以下の2点でした。
- kintone の世界観において、kintone システム管理者はどのような役割を期待されているか
- kintone がユーザーに辿ってほしい業務改善とはどのようなものか
製品開発者として機能仕様は熟知しているものの、「ユーザーが kintone にどんな業務改善を期待しているか」というコンセプトレベルの認識を改めて言語化することが、ワークショップ全体の土台となりました。
Part1：システム管理者の責務の再確認
最初のセッションでは、チームのメインターゲットである「管理者」像を掘り下げました。システム管理系の機能開発で関わる管理者には、次の3種類があります。
| 管理者種別 | 責務の範囲 |
|---|---|
| アプリ管理者 | 各 kintone アプリの運用に責任を持つ |
| システム管理者 | kintone 全体の運用に責任を持つ |
| .com 共通管理者 | 契約中のサイボウズ製品全体に共通する運用に責任を持つ |
これら3種の管理者それぞれについて、以下の2観点から具体的な項目を書き出しました。
- それぞれの管理者はどんな責務を持つか
- この責務を果たすため、各管理者は kintone 上でどんな業務を行うか
書き出した後はチームで議論を重ね、「なぜこの責務はこのレイヤーの管理者が持っているのか」「この業務があるならこんな情報も見たいのではないか」といった問いかけを通じて、チーム内の共通認識を固めました。
Part2：顧客特性ごとの運用理解と既存機能の確認
Part1 で管理者像が明確になったところで、kintone アプリの運用という観点から解像度をさらに高めました。
kintone の運用方法は、契約する組織の規模や活用スタイルによって大きく異なります。今回のワークショップでは kintone アプリを大きく以下の2タイプに分類しました。
- 現場主導型：各部門や担当者が自律的にアプリを作成・運用する形態
- 統制重視型：IT部門やシステム管理者が一元管理し、ガバナンスを強く効かせる形態
この2タイプのアプリについて、それぞれの運用上の特性・制約を整理したうえで、「現状リリース済みの機能でどこまで対応できるか」を議論しました。この視点から機能を眺めることで、特定の管理者層にとって想定より恩恵の大きい機能や、逆に現状では手が届きにくい部分も浮かび上がりました。
Part3：運用課題のケーススタディ
3つ目のセッションでは、実際の運用で発生しうる課題を題材にケーススタディを行いました。取り上げたシナリオは以下の2つです。
- kintone アプリの乱立が目立ち、有効活用ができない
- kintone アプリについて、アクセス権を移譲しすぎた
各ケースに対して、「運用前に防止するにはどんな施策が打てるか」「運用中に検知・是正するにはどんな施策が打てるか」を検討しました。
実施形式はモブ形式（1人が kintone を実際に操作して大画面に映し、他の参加者がそれを見ながら案を出す）を採用。既存機能ベースで改善手段を探るうちに「もっとこうだったら見やすいかも」「こうなっていたらより効果的な施策が打てそう」といった、現状機能の外側にあるアイデアも自然に出てきました。
ワークショップで深められた理解と得られたもの
管理者の業務フローへの視点転換
通常の機能開発では、「この機能はどう使われるか」という機能中心の検証になりがちです。しかし今回は、kintone がユーザーに求める役割・責務を切り口として、導入から活用までの業務単位で議論を進めました。その結果、「管理者はどのような要求からどのような施策を行いたいのか」というユーザー側に注目した会話が生まれました。
既存機能と権限カバー範囲の再整理
Part1・Part2 の成果として、「どの管理者がどこまでの権限を持っているか」の再整理ができました。複数の管理者レイヤーを行き来しながら権限の境界を理解しようとすると混同しやすい部分があり、開発チームが持つ機能イメージと実際にユーザーが行える操作の間に認識の齟齬があることも判明しました。普段とは異なる切り口で機能を眺めたことで得られた気づきです。
システム管理領域の改善アイデアの創出
Part3 を通じて、「こんなことができたらより楽に業務改善できそう」「こんな情報が見えたらより運用に役立ちそう」という新たなアイデアも多数生まれました。各アイデアは既存機能への改善案だったり、全く別のアプローチからのものだったりと多様で、仕様書・プロダクトコードを参照しながら議論・検証することで、既存の実装・設計への理解がさらに深まる効果もありました。
日常業務への変化
ワークショップを経て、仕様検討時のコミュニケーションの質が向上しました。具体的には、「このユーザーは〇〇がしたいから、××のようになっていると嬉しそう」というように、主語をユーザーに置いた会話・操作に焦点を当てた議論が増えました。
システム管理者の具体的な業務について土台となる共通認識を形成したことで、チームとして同じ目線で議論できるようになったとのことです。
おわりに：コンセプトに立ち返ることの重要性
プロダクト開発に集中していると、ユーザーが求める価値がどこにあるのかわからなくなったり、実態と開発者の認識がずれてしまったりすることがあります。そんな時には、自分やチームの関わるプロダクトがユーザーに求めている責務・世界観、すなわちコンセプトに立ち返って明文化することが重要だと、本ワークショップを通じて実感できたと kura 氏は締めくくっています。