挑戦の「場」を組織的に設計する！挑戦と成長を加速させるミニプロジェクト制度の実践

挑戦の「場」を組織的に設計する！ 挑戦と成長を加速させるミニプロジェクト制 度の実践 2026.03.10 1

使用フォントについて 自己紹介 • sakito(@__sakito__) • サイボウズ株式会社 • プロダクトデザイン部 マネージャー • プロダクトエンジニア(フロントエンド) マネージャー • みんなのデザイン室リーダー • さいきんは開発組織のAI推進はじめました 2

サイボウズの変化 2022 売上高 (百万円) 30,000 単体売上高 グループ売上高 kintone 連結売上高 100億突破 連結営業利益 25,000 10,000 5,000 （百万円） 2002-2003 1997 創業 2011 パートナービジネス開始 クラウドビジネス転換 Garoonリリース メールワイズリリース kintoneをリリース 6,000 5,000 2017- 20,000 15,000 営業利益 kintone成長 4,000 3,000 2,000 サイボウズ Office リリース 1,000 0 0 創業期 販売網開拓期・M&A期 クラウド転換期 kintone成長期 https://cybozu.co.jp/company/ir/meeting/pdf/2412_01.pdf 3

• https://cybozu.co.jp/company/ir/meeting/pdf/2412_01.pdf

サイボウズの組織 4

数字から見るサイボウズの変化 5

数字から見るサイボウズの変化 6

主力製品 開発の知識がなくても 業務に合わせたシステムを かんたんに作成できる クラウドサービス 7

kintoneの現在地 15年の進化 多くのお客様 広がるエコシステム 2011年のリリース以降、常に進化し続けています 国内外の40000社以上でkintoneを導入していただき 業務基盤・データ基盤として活用していただいています オフィシャルパートナー社数は500社を超え、 連携サービスは400以上あり、クラウド売上の6割以上が間販です ※エコシステム：企業間のパートナーシップやアライアンスによって収益を生み出すビジネスモデルのこと 8

kintoneの開発組織 ※ 人数は2026年1月現在 kintoneプラットフォーム副本部 約190人 エンジニアリング部 プロダクトマネジメント部 プロダクトデザイン部 約140人 販売管理システム プラットフォーム サブドメインクラス kintoneアプリ 開発部 エンジニアリング部 管理開発部 開発部 15人 21人 16人 48人 共通横断開発部 32人 開発者向けサービス kintone Design 基盤開発部 System 8人 サービスプラット サブドメインクラス kintoneシステム ナビゲーション エンドユーザー向け フォーム 管理サービス 管理サービス開発 サービス開発 開発 AI機能基盤開発 ライティング モバイル開発 リサーチ ダッシュボード開発 kintoneアプリ 管理サービス開発 kintoneアプリ サービス開発 kintoneアプリ 基盤開発 ローカライズ 9

でかくね？ 10

組織が大きいとなにがおきるか • 組織図の分割、職能ラベルを設ける必要がでてくる • チームが明確に定義されるので、個人が出せる影響もチームの中に閉じがち • チームの範囲外に、なにかやりたいことがあっても誰に頼めばいいのかわからない • 結果的に「挑戦がしづらい」という風にまとめられがち • 特に入社したばかりの人はやったこともないことをできるようにはならない • 新卒入社だと尚更 • マネージャーが言うまで動きづらい • マネージャーが全部決めるのむり！！！ • 挑戦が起きづらいのは、失敗もしづらい 11

救いたい 12

ミニプロジェクトをはじめた • 「プロジェクト」ではなく、あえて「ミニプロジェクト」 • 「プロジェクト」という言葉を聞くと、多くの人は大きな成果を出さなければならない印象がある • 組織の中で「やってみよう」という文化を作りたい • 「ミニ」をつけて心理的ハードルを下げるたかった • 「小さくてもいい、やってみることが大事」 13

14

ミニプロジェクトのはじまり • 何もないところから「さあやろう」と言っても人は動かない • まずマネージャー自身がミニプロジェクトを実践し、2週間で終わりの目処を立てて遂行 • 実際に動いている姿、どんな成果で良いのかを示したかった • メンバーに渡しやすい、やりやすい状態にするにはやるのがはやい！ • 最初のPJは「フロントエンドドキュメント再開発」でした • ドキュメントスペースを再整理し、情報資産を棚卸することを目的に • ミニプロジェクトにするほどでもないが、あえてミニプロジェクトとして立ち上げ 15

ミニプロジェクトのフォーマット - DACI • Atlassian Team PlaybookにあるDACIフレームワークを参考に作成 • https://www.atlassian.com/ja/team-playbook/plays/daci https://www.atlassi an.com/ja/teamplaybook/plays/dac i?tab D A C I Driver Approver Contributors Informed 推進役 承認者 貢献者 報告先 利害関係者を集め、必要な情報 をすべて収集し、意思決定の範 囲を定義し、合意された日まで に意思決定が下されるようにす る責任者 意思決定を行う1人の担当者。 受動的役割ではなく、積極的に 意思決定を行う 主題分野の知識を持ち、提案が できる人。発言権はあるが投票 権はない 決定によって仕事に影響が出る 可能性があり、意思決定が下さ れた後に知らせるべき人。発言 権も投票権もない 16

• https://www.atlassian.com/ja/team-playbook/plays/daci
• https://www.atlassi

Driver（推進役）の責任 D 利害関係者の集結 意思決定に必要な関係者を特定し、プロセスに巻き込む 情報収集 Driver 意思決定に必要なすべての情報とデータを収集・整理する 推進役 スコープの定義 意思決定の範囲と制約条件を明確に設定する 期限の管理 合意された期日までに意思決定が下されるよう、プロセスを管理・推進する 17

Approver（承認者）の特徴 A Approverは必ず1名だが、ミニプロジェクトでは複数名に変更 本来は複数のApproverは責任の分散を招き、意思決定を曖昧にするが、フィードバックを多くもらうために変更 能動的な意思決定 Approver 受動的な役割ではなく、積極的に考え判断を下す 承認者 最終責任の所在 意思決定の結果に対して最終的な説明責任を持つ 明確な判断 提案に対してYes / No / 条件付き承認などを明確に伝える 18

Contributors（貢献者）の特徴 C ✓ 発言権あり ✗ 投票権なし ・専門知識の提供 ・最終決定には参加しない ・提案・アドバイス ・拒否権は持たない ・懸念点の指摘 ・承認の役割ではない Contributors 貢献者 ・代替案の提示 19

Informed（報告先）の特徴 I 意思決定後に通知される 意思決定のプロセスには参加せず、決定が下された後に結果を知らされます。 影響を受ける関係者 Informed その意思決定によって業務や役割に影響が生じる可能性がある人 報告先 発言権・投票権なし プロセスへの関与はなく、決定に対して意見や拒否権を持たない 適切なタイミングで通知 決定後、速やかに通知し、業務への影響に備えられるようにする 20

Informed（報告先）の特徴 役割 主な責任 発言権 投票権 人数 参加タイミング D Driver プロセス推進・情報収集・期限管理 ✓ − 1名 全期間 最終意思決定 ✓ ✓ 複数可 全期間 専門知識の提供・提案 ✓ ✗ 複数可 決定前 決定結果の受領・業務への反映 ✗ ✗ 複数可 決定後 A Approver C Contributors I Informed 21

ミニプロジェクトの成果 • エンジニア向けオンボーディング改善 • 開発に必要な知識、実装などをキャッチアップでき る実践トレーニングの整備 • 環境構築刷新PJ • 開発環境の抜本的見直しをおこない、メンテコスト と準備コストを減らす • Cybozu Baseline PJ • 製品のサポートするブラウザのバージョンを一元化 する仕組みの見直し • 取り組みの発信がweb.devへの掲載も • https://web.dev/case-studies/cybozubaseline?hl=ja 22

• https://web.dev/case-studies/cybozu-

やったことは、経験学習（Experiential Learning）の場づくりだった • 「経験するだけ」では学びにならない、経験学習（Experiential Learning） という学習理論がある。 • 振り返り・概念化・実践のサイクルを回すことで、経験が学びへと変わり、行動が変わる。 4 3 2 1 Concrete Experience Reflective Observation Abstract Conceptualization Active Experimentation 具体的経験 内省的観察 抽象的概念化 能動的実験 実際の体験・出来事に 正面から向き合う 体験をさまざまな 観点から振り返る 振り返りから 法則・理論を導く 理論を新しい状況で 試し、次の経験へ ↺ 経験→振り返り→概念化→実践 のサイクルを繰り返すことで学びが定着する • 今回のミニプロジェクトはこのサイクルを取り組む手段だった • 業務の中にこの仕組みをうまく入れていく試行錯誤もEMの醍醐味 23

24

©️ Cybozu, Inc. 25