サイボウズ社内の開発事例で学ぶ、kintoneカスタマイズのチーム開発

「属人化しているkintoneの案件対応をチームで効率よく進めたい」
「kintoneにおけるチーム開発の事例を知りたい」と考えている皆様に向けて、
サイボウズのエンジニアが社内で実際に取り組んだプラグインやカスタマイズ開発事例をもとに、チームで効率的に開発を進めるための開発環境や体制整備について説明します。

Transcript

2. コンセプト • • •
3. 自己紹介 • • • • • • •
4. アジェンダ • • • • • • • • •
5. アジェンダ • • • • • • • • •
6. 部署紹介
7. 所属チームの紹介/CyPNとは
8. 所属チームの紹介/CyPN Portalとは kintone上に構築された ポータルサイト 数十個のカスタマイズや プラグインが適用 されている
9. 所属チームの紹介
10. チーム紹介 開発プロセス /
11. チーム紹介 技術スタック
12. アジェンダ • • • • • • • • •
13. 2023年12月 2024年1月~3月 2024年4月~6月 2024年7月~9月 おおまかなタイムライン チーム活動を本格化させた際に行った活動＞新体制に変わった時に取り組んだこと 課題抽出 業務属人化の解消 コードの保守性/堅牢性の改善活動 開発の標準化 開発の効率化 現状整理 チーム 体制変更 2023年11月
14. 2023年末にチーム体制が大きく変わる 体制変更前 体制変更後 チームの親しみ やすさ お互いをよく知っている お互いをよく知らない チームサイズ 小さい（~5名） 小さい（5~10名） 経験のレベル ほとんどミドル ジュニア、ミドル、シニア等様々 専門性 SEメンバーのみ SEメンバー ＋ 開発メンバー （我々） プロジェクトへ の関与度 兼務型 専任型と兼務型の ハイブリッド チーム活動を本格化させた際に行った活動＞新体制に変わった時に取り組んだこと
15. チーム体制が変わって最初に取り組んだこと 潜在的リスクは何だったのか？ 背景：もともと兼務メンバーが限られたリソー スでCyPN Portal業務に対応しており、メンテナ ンス性改善の活動にリソースを割けなかった 課題②：暗黙知化・属人化した業務の解消 対応方針： 専任メンバーが毎月一定の工数を取り、 優先順位を付けて順次対応 背景：一部の兼務メンバーに業務の比重が偏っ ており、その兼務メンバーがCyPN Portal開発業 務を網羅的に把握している状態だった 対応方針： • 兼務メンバーによる業務マニュアルの明文化 • 専任メンバーが主業務に対応し、暗黙知を獲得する 現状把握 チーム活動を本格化させた際に行った活動＞新体制に変わった時に取り組んだこと
16. チームメンバーの特性・特徴にばらつきがあるのは潜在的リスク 体制変更前 体制変更後 チームの親しみ やすさ お互いをよく知っている お互いをよく知らない チームサイズ 小さい（~5名） 小さい（5~10名） 経験のレベル ほとんどミドル ジュニア、ミドル、シニア等 様々 専門性 SEメンバーのみ SEメンバー ＋ 開発メンバー プロジェクトへ の関与度 兼務型 専任型と兼務型の ハイブリッド 品質の安定化を目的とした開発の標準化を 優先的に進めることに チーム活動を本格化させた際に行った活動＞新体制に変わった時に取り組んだこと
17. 開発の標準化の3つの観点 チームで統一されたコードの書き方 や規則を定める。 開発の標準化 • • チーム活動を本格化させた際に行った活動＞新体制に変わった時に取り組んだこと
18. アジェンダ • • • • • • • • •
19. 開発の標準化の3つの観点 チームで統一されたコードの書き方 や規則を定める。 開発の標準化 • • チーム活動を本格化させた際に行った活動＞コーディング規約を定める
20. • • 改めてコーディング規約とは何か チーム活動を本格化させた際に行った活動＞コーディング規約を定める 出典: Google’s Engineering Practices documentation. 「The Standard of Code Review」. https://google.github.io/eng-practices/review/reviewer/standard.html#principles , (参照 2024-9-25)
21. どうやってコーディング規約を定めたのか チーム活動を本格化させた際に行った活動＞コーディング規約を定める 起案 規約は 妥当？ 文書化 静的解析ツール に設定追加 自動化 できる？ 規約の追加は 見送り Yes Yes No No
22. ESLint JavaScript 補足：静的解析ツールとは チーム活動を本格化させた際に行った活動＞コーディング規約を定める
23. 文書化した規約と静的解析ツールに設定した規約の全体像 個々人の指向 文書化した規約 静的解析ツールに よる規約 自動でチェック 手動でチェック チーム活動を本格化させた際に行った活動＞コーディング規約を定める こっちの規約の量が多い • ESLintによる規約 • TypeScriptによる規約
24. 静的解析ツールにはどんな規約を定めたのか ESLint TypeScript チーム活動を本格化させた際に行った活動＞コーディング規約を定める
25. 文書化した規約はどんなものを定めたのか • default exportではなく named exportを使用する • React.useEffectは外部システムとの連携時 以外は使用しない • React.useStateでは不変データ、propsもしく は既存stateから計算できる情報は管理しない チーム活動を本格化させた際に行った活動＞コーディング規約を定める
26. コーディング規約を定める際に苦戦したこと 定数は大文字の スネークケースで書くことが 意識できてない… 意識せずとも 定数は大文字のスネークケース で書ける チーム活動を本格化させた際に行った活動＞コーディング規約を定める ジュニア層のメンバー シニア層のメンバー
27. コーディング規約に関して得られた知見 1/2 チーム活動を本格化させた際に行った活動＞コーディング規約を定める
28. コーディング規約に関して得られた知見 2/2 チーム活動を本格化させた際に行った活動＞コーディング規約を定める
29. アジェンダ • • • • • • • • •
30. 開発の標準化の3つの観点 チームで統一されたコードの書き方 や規則を定める。 開発の標準化 • • チーム活動を本格化させた際に行った活動＞一部の開発プロセスを標準化する
31. どうやって開発プロセスの標準化を進めたのか 起案 メンバー全員で 議論 数人のメンバー で議論 局所的な トピックか Yes No 例：ディレクトリ構成 例：課題管理ツールを変更する 局所的な意思決定までメンバー全員で決めると、チームの動きが鈍重になる チーム活動を本格化させた際に行った活動＞一部の開発プロセスを標準化する
32. 仕様検討段階における取り組み 仕様検討段階 ツール 開発段階 リリース段階 施策 • コミュニケーション：kintoneアプリ • ドキュメント：confluence • 仕様書テンプレート作成 • 開発プロセスの明示化 • エラー表示時の文言の統一 チーム活動を本格化させた際に行った活動＞一部の開発プロセスを標準化する
33. 開発段階における取り組み 仕様検討段階 ツール 開発段階 リリース段階 施策 • エディタ：Visual Studio Code • コード管理：GitHub • 開発環境：GitHub Codespaces • CIツール：GitHub Actions • 開発環境の設定（拡張機能など）を統一 • ブランチ戦略をGit-Flowモデルに変更 • プラグインテンプレート作成し、 ディレクトリ構成やutils系の処理は プロジェクト間で共通化 • ライブラリのライセンスチェックと 静的解析の自動化 チーム活動を本格化させた際に行った活動＞一部の開発プロセスを標準化する
34. • 補足：GitHub Codespacesとは GitHub Codespaceの インスタンス GitHub Codespace Visual Studio Code ブラウザ チーム活動を本格化させた際に行った活動＞一部の開発プロセスを標準化する
35. 補足：CI （継続的インテグレーション）とは CI サーバー（GitHub Actions等） ビルド テスト 結果 結果を通知 開発者 変更を反映 Gitホスティングサービス（GitHub等） コード変更 トリガー 共有のリポジトリ チーム活動を本格化させた際に行った活動＞一部の開発プロセスを標準化する
36. 開発段階における取り組み 仕様検討段階 ツール 開発段階 リリース段階 施策 • エディタ：Visual Studio Code • コード管理：GitHub • 開発環境：GitHub Codespaces • CIツール：GitHub Actions • 開発環境の設定（拡張機能など）を統一 • ブランチ戦略をGit-Flowモデルに変更 • プラグインテンプレート作成し、 ディレクトリ構成やutils系の処理は プロジェクト間で共通化 • ライブラリのライセンスチェックと 静的解析の自動化 チーム活動を本格化させた際に行った活動＞一部の開発プロセスを標準化する
37. リリース段階における取り組み 仕様検討段階 ツール 開発段階 リリース段階 施策 • コード管理：GitHub • CIツール：GitHub Actions • リリース後の業務の自動化 • バージョン番号の決定 • 各ファイル（manifest.json等）のバージョン更新 • リリースタグ&リリースノート作成 • ビルド成果物をリリースノートに添付 チーム活動を本格化させた際に行った活動＞一部の開発プロセスを標準化する
39. • • 開発プロセスの標準化を進める際に苦戦したこと チーム活動を本格化させた際に行った活動＞一部の開発プロセスを標準化する
40. 開発プロセスの標準化について得られた知見 1/2 チーム活動を本格化させた際に行った活動＞一部の開発プロセスを標準化する
41. • • 開発プロセスの標準化について得られた知見 2/2 プラグイン設定画面 のコード ユーザーが操作する 画面のコード Interface 依存 依存 • プラグイン設定 • 共通で利用する型エイリアス 等 チーム活動を本格化させた際に行った活動＞一部の開発プロセスを標準化する
42. アジェンダ • • • • • • • • •
43. 開発の標準化の3つの観点 チームで統一されたコードの書き方 や規則を定める。 開発の標準化 • • チーム活動を本格化させた際に行った活動＞ライブラリを標準化する
44. どうやって開発ライブラリの標準化を進めたか 起案 却下 承認 数人の専門 メンバーに よる確認 Yes No 全体定例 での確認 Yes No 議論していた際の観点（例）： • GitHubのstar数が多い • メンテナンス頻度が高いか • 工数削減に繋がるか（ビジネスへのインパクト） チーム活動を本格化させた際に行った活動＞ライブラリを標準化する
45. • • 導入したライブラリの紹介 チーム活動を本格化させた際に行った活動＞ライブラリを標準化する
46. アジェンダ • • • • • • • • •
47. 型安全な開発 TypeScript neverthrow JavaScriptに対する 静的型付け Result型で エラーハンドリングを 実現 @kintone/dts-gen kintoneアプリのための 型を生成 TypeScriptは段階的な導入が可能。まずはじめにTypescriptを導入し、 徐々にstrictコンパイラオプションを追加＆TSエコシステムのライブラリを導入することで より型安全な開発を行えるようになる。 チーム活動を本格化させた際に行った活動＞開発効率化に貢献した取り組み
49. CIの仕組みの構築 1/2 チーム活動を本格化させた際に行った活動＞開発効率化に貢献した取り組み
50. CIの仕組みの構築 2/2 チーム活動を本格化させた際に行った活動＞開発効率化に貢献した取り組み
51. アジェンダ • • • • • • • • •
52. 体制変更前と体制変更後のビフォーアフター • • • • • • • / • • • まとめと今後の課題
53. 全体を通して得られた知見 まとめと今後の課題 現在のプロジェクト 次のプロジェクト チームに溜まった知見
54. • 今後の課題 1/2 まとめと今後の課題
55. 今後の課題 2/2 まとめと今後の課題 テスト環境 本番環境 フィールド設定やアクセス権設定等に差異がある
56. アジェンダ • • • • • • • • •
57. 項目 判断基準 チームの親しさ 親しくないほど多くのコントロールが必要 経験レベル 経験年数が少ないほど多くのコントロールが必要 チームサイズ 規模が大きいほど多くのコントロールが必要 プロジェクトの複雑さ 複雑なほど多くのコントロールが必要 プロジェクトの期間 期間が長いほど多くのコントロール量が必要 効果的なチームを作るためのファーストステップ 1/2 効果的なチームを作るためのファーストステップ コントロール（制約・規約の厳しさ）のレベルを決定する5つの要因 出典: Mark Richards, Neal Ford, 「ソフトウェアアーキテクチャの基礎 」. オライリージャパン、2023, 411ページ
58. 項目 現状 チームの親しさ お互いをよく知っている 経験レベル ミドル層～シニア層が多め チームサイズ 少なめ（5名前後） プロジェクトの複雑さ 実現難易度は低めの要件が多い プロジェクトの期間 3か月程 効果的なチームを作るためのファーストステップ 2/2 効果的なチームを作るためのファーストステップ