Slide 1

Slide 1 text

kintone開発を効率化するために チームで試した施策と その結果を大放出! 2025.02.28 1 サイボウズ x SmartHR アジャイル文化醸成への挑戦 ~ 実践と学び ~ サイボウズ株式会社 開発本部 おぐえもん(小倉 且也)

Slide 2

Slide 2 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) この発表について はじめに • サイボウズの主力製品・kintoneのフロントエンド刷新を手がける 私のチームが今までに取り組んできた開発効率化の施策を大放出します! • 良かった点だけでなく、 そうでもなかった点も正直に話します • kintone開発の現場のリアルを赤裸々に披露します! 2

Slide 3

Slide 3 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) 自己紹介① はじめに • サイボウズ株式会社 開発本部 フロントエンドエンジニア • 2022年9月入社/kintoneのフロントエンド刷新に従事 • 2024年からkintoneの主要機能の1つである 「アプリ」機能のUI刷新をリード 3 おぐえもん(小倉 且也) @oguemon_com https://oguemon.com/

Slide 4

Slide 4 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) 自己紹介② はじめに • ↓個人開発で色々作ってるので、みんなみてね! 4 おぐえもん(小倉 且也) @oguemon_com https://oguemon.com/ オススメ!!

Slide 5

Slide 5 text

チームの施策に入る前に、チームのことを紹介します! 5 今回取り上げるチームの概要

Slide 6

Slide 6 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) kintoneって何? チーム概要 • サイボウズの主力製品 • 37,000社が利用(2025年1月時点) • 業務のシステム化や効率化を実現する アプリが「シュシュッと」つくれる ノーコードツール 6

Slide 7

Slide 7 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) kintoneはめっちゃ多機能 チーム概要 7 • これらをはじめ 色んな機能がある グラフ・レポート機能 データベース機能 モバイル・通知機能 コミュニケーション機能 プロセス管理機能 ポータル機能 監査ログ機能 アクセス権 多言語対応 日本語・英語・簡体字・繁体字・ スペイン語・タイ語・ポルトガル語(ブラジル) スレッド機能 検索機能

Slide 8

Slide 8 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) 私のチームがやっていること① チーム概要 8 kintoneの主機能である「アプリ」機能のフロントエンド刷新 • 「アプリ」とは… • 右の画像の機能 • kintoneのメイン • 前ページの赤背景が絡む かなり膨大&複雑な機能

Slide 9

Slide 9 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) 私のチームがやっていること② チーム概要 • kintoneは、開発初期(2010年前後)の フロントエンド実装がレガシー化している • 根幹で採用されている「Google Closure Tools」を使える人がもはや僅少 • →2021年頃から脱レガシー(React化)に着手 • アプリ機能は2024年から着手 • ついでにUI/UXの改善にもトライ 9 kintoneの主機能である「アプリ」機能のフロントエンド刷新

Slide 10

Slide 10 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) メンバー構成(現時点) チーム概要 10 PO 作るものを決める人 PG 実装する人 QA 試験する人 SM スクラムの指導をする人 合計 1 5 3 1 兼務 + + + = 9 アルバイト 業務委託 常時いるのは7 = Product Owner = Programmer = Quality Assurance = Scrum Master PO PG QA SM

Slide 11

Slide 11 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) 発表の元ネタ チーム概要 11 • チームメンバーに集まっていただき、過去の振り返りボードの中から、 主な取り組みをピックアップ&改めて評価してもらいました • 発表内容には、メンバーの見解と私の見解が入り混じってます 毎週積み重ねてきた膨大な振り返り資料 チームメンバーにピックアップしてもらったもの

Slide 12

Slide 12 text

やってみたこと① 12 定例予定の整理

Slide 13

Slide 13 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) 定例予定の整理 やってみたこと① • チームには色んな予定がある。 • 朝会/リファインメント/スプリントレビュー/ 振り返り/プランニング/夕会… • 定例の予定は時間の固定費であり、個人の作業に慢性的な影響を及ぼす 13 定例で開催する予定を最適化

Slide 14

Slide 14 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) 定例予定の整理:やったこと やってみたこと① • 夕会:この1日の進捗を整理 • 朝会:前日の進捗に基づいて この1日にやることを決定 • →夕会を朝会に統合 • どのみち朝会で夕会に近いことをやるから • 勤務時間ベースで考えると、 夕会と朝会の開始時刻は近いから 14 ① 似た予定を統合 朝会 朝会 11:00 月曜日 火曜日 夕会 16:30 夕会 これらを削除

Slide 15

Slide 15 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) 朝会 リファインメント 定例予定の整理:やったこと やってみたこと① • 定例の予定が色んな時間帯に散らばっていた • →特定の時間帯に集約 • ある予定が早く終われば次の予定に移れるから • 予定忘れを防げるから 15 ② 予定の時間帯を集約 朝会 リファインメント 11:00 16:00 火曜日 水曜日 リフ 振り返り 14:00 15:00 スプリント レビュー プランニング リファインメント リフ これらを移動

Slide 16

Slide 16 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) 全体朝会 定例予定の整理:やったこと やってみたこと① • アプリ領域のチームは担当範囲の広さゆえ、 組織に階層構造があった • 各階層で朝会があった • →チーム朝会以外の朝会を解消 • 月日が流れる中で チーム外と同期的に連携すべき事項が 毎日あるわけでなくなったから 16 ③ 意義が乏しくなった予定の解消 全体朝会 11:00 月曜日 火曜日 これらを解消 親チーム朝会 親チーム朝会 親 チーム朝会 チーム朝会 チ 11:05頃 11:10頃

Slide 17

Slide 17 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) 定例予定の整理:結果と学び やってみたこと① • 定例予定の時間対効果が良くなった • 必要と考えられる予定だけが高密度で行われる • 作業に集中しやすくなった • 個人作業に充てられる「まとまった時間」が手に入った • 最適化の中で失われたものを寂しく思う声が出た • アイスブレイクコーナー (Good & New)と、 チーム外メンバーと定期的に会う機会がなくなった 17 結果 学び • まとまった時間の存在はメンバー満足度が高い • 定例予定の削減には断捨離の覚悟が必要

Slide 18

Slide 18 text

やってみたこと② 18 開発プロセスの改善

Slide 19

Slide 19 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) 開発プロセスの改善 やってみたこと② • 一般的な開発プロセスと同じく、タスクは次のサイクルで進む • 着手→実装(PG*担当)→テスト(QA*担当)→受入確認(PO*担当)→完了 • 開発行為そのものなので、開発の効率化に直接的な影響を及ぼす 19 着手→完了の時間を短くするための工夫を凝らす = Product Owner = Programmer = Quality Assurance *PO PG QA

Slide 20

Slide 20 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) 開発プロセスの改善:やったこと やってみたこと② • ひとつのタスクで、結合テストの実装と 仕様書の更新をあわせてやっていた • →両者を別タスクに分けて後に回す • フロントエンド刷新の実装は 今すぐリリースされるわけでなく 即時性は不要だから 20 ① 後に回せるものを後に回す 備忘のため 後に回したものには ラベルをつけて管理

Slide 21

Slide 21 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) 開発プロセスの改善:やったこと やってみたこと② • サイボウズでは、自社クラウド基盤を用いて 開発環境の作成/破棄が自由にできる • 受入確認に際して、受入確認のための 新たな開発環境と受入条件に関係する”アプリ”を 事前に用意するのが通例だった • →手動テストで使った環境を受入確認で流用 • 同様の準備のための二度手間を回避するため 21 ② 使い回せるものを使い回す

Slide 22

Slide 22 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) 開発プロセスの改善:やったこと やってみたこと② • 仕様書の編集では、フロントエンド刷新後の仕様ページを 設けて、実装した見た目と挙動を一通り書いていた • →現行仕様ページの末端に刷新前後の差分のみ追記 • 1から全部書く労力の大きさが課題になったから • 刷新前後で仕様が大きく変わる箇所は 割と限られていることが 実装を進める中で判ってきたから 22 ③ 減らせるものを減らす こんな感じの章を追記

Slide 23

Slide 23 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) 開発プロセスの改善:結果と学び やってみたこと② • プログラミングとドキュメンテーションの 頻繁なスイッチングが軽減してタスクを進めやすくなった • 浮いた作業分だけ所要時間が削減した • タスクがスプリント内で回りやすくなった • 後回しにしたタスクの管理が必要になった 23 結果 学び • プログラミングとドキュメンテーションのタスク分割は メンバー満足度が高い • タスクの後回しは忘れられるリスクと隣り合わせ

Slide 24

Slide 24 text

やってみたこと③ 24 その他いろいろ

Slide 25

Slide 25 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) その他いろいろ:やったこと やってみたこと③ • Slackでタスクに関する投稿(連絡・メモ書き)をする際 は、チームのチャンネルを使用 • →これに加え、単一スレッドで完結させるルールにする • スレッドを使わないと情報が散らばり 連続した投稿の検索性が下がるから 25 Slackの「1タスク1スレッド」ルール 完了するまでピン留め チャンネルに投稿するのは自由 • タスクの詳細な状況を追いやすくなった • ピン留め機能により実施中のタスクのスレッドに アクセスしやすくなった 結果

Slide 26

Slide 26 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) その他いろいろ:やったこと やってみたこと③ • タスク管理にGitHubのProjectを使用 • →ステータス管理の部分をZenHubに移行 • 進捗や所要時間の可視化機能が強力で 今後の改善に活かせる可能性を感じたから 26 タスク管理で を活用 こんな感じの画面がたくさん! • タスク単位でパフォーマンスを記録・可視化するので 結構前にやったタスクのことも振り返り時に反省しやすくなった 結果 学び • 可視化以外の機能は発展途上の部分がある点に注意が必要 zenhub: https://www.zenhub.com/

Slide 27

Slide 27 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) その他いろいろ:やったこと やってみたこと③ • 常勤のPG*が6人になり、チーム内のコミュニケーションと タスクの並行数が増加し、状況が複雑化していた • →チームを担当機能で二分割 • 分割後の人数が「ピザ2枚ルール」に適合し 高い生産性が期待できるから • 分割の切り口を着手する機能とすることで、 コードの競合が回避できると考えられるから 27 チームを二分割 Aチーム Bチーム 分割後の 人数 PG3人 & QA1人 PG3人 & QA1人 機能 レコードの 絞り込み機能 左以外全て 合同でやる 定例予定 プランニングの最初と最後/ リファインメント 別々でやる 定例予定 朝会/プランニングの中盤/ 振り返り 当時のメンバーを真っ二つ! = Programmer = Quality Assurance *PG QA

Slide 28

Slide 28 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) その他いろいろ:結果と学び やってみたこと③ • 人数減に伴い定例予定の所要時間が減った • 見るべき範囲が狭まり自チームの状況を追いやすくなった • チーム間で必要なコミュニケーション量は大きく変わらなかった • リリース単位や開発計画、コード全体のオーナーシップは共有だから • 分割直後にメンバーのチーム異動が重なり両チームが過疎化した • → 上の結果を評価した上で、1ヶ月後に再度統合した 28 結果 学び • チーム分割で全体の効率を高めるには、 分割したチームの共有物をいかに小さくするかがキモになる

Slide 29

Slide 29 text

29 総括

Slide 30

Slide 30 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) 色々やってみて学んだ主なこと 総括 • 減らす系の施策は葛藤が生じがちだが大体は減らしてもOK • 問題意識が芽生えてから復活を検討するので遅くない • 改善活動はすぐに解に辿り着くわけでない • ある施策をすると別の問題が浮上して、今度はそれに対応して…という形で 穴を塞いでいくことになる • 取るべき施策はチームを取り巻く状況次第でガラリと変わりうる • メンバーの変更/メンバーの成長/チーム内外の方針などが変われば 今の施策は陳腐化する可能性がある 30 常に現状を俯瞰しながら妥当性を吟味して、 時には大胆な手を打ちながら、地道に改善に取り組み続けることが必要

Slide 31

Slide 31 text

kintone開発を効率化するためにチームで試した施策とその結果を大放出! - おぐえもん(小倉 且也) まとめ 総括 • この半年以上の中で、定例予定/プロセス改善/その他あらゆるところに大 小の改善施策を取り込んでみた • 上手く行ったことがあれば、新たな問題が出たもの、 期待したほどでもなかったものがあった • 色々学んだ • 減らす系の施策は迷ったとしても大抵減らして困らない • 改善活動はすぐに解に辿り着くわけでない • 取るべき施策はチームを取り巻く状況次第でガラリと変わりうる • 常に現状を俯瞰しながら妥当性を吟味して、 時には大胆な手を打ちながら、地道に改善に取り組み続けることが必要 31

Slide 32

Slide 32 text

©️ Cybozu, Inc. 32