Practical_Tips_for_Using_Confluence__Jira__and_Findy_Team__Right_Now.pdf

2024-09-26: #67 ACE Tokyo MeetUp Findy Team + とJiraで実現する開発生産性可視化の事例＆海外イベント(Team'24)ふりかえり
での登壇資料です

Transcript

1. 1 【#67 ACE Tokyo MeetUp】 今から使える、 Confluence/Jira/Findy Team+ の活用ヒント 粟田 啓介 2024-09-26: #67 ACE Tokyo MeetUp Findy Team + とJiraで実現する開発生産性可視化の事例＆海外イベント(Team'24)ふりかえり
2. 2 自己紹介 mysql > SELECT * FROM me \G ********* 1. row ********* name: 粟田 啓介 nickname: あわっち X(twitter): @_awache role: DBRE(,CCoE) favorite: MySQL 1 rows in set (0.00 sec)
3. 3 KINTO テクノロジーズ株式会社 (KTC) について 2021年04月設立 2019年01月設立
4. 4 KTC における DBRE の立ち位置 エンジニア組織： 24グループ 社内のエンジニアの数： 約 350名 アプリケーション開発組織 • KINTO サービス開発 • グローバル ID 基盤開発 • バックオフィスシステム開発 • モバイルアプリ開発, etc. 横断組織 (プラットフォーム 部) • Platform Engineering • SRE (Embedded SRE) • MSP (24*365 保守運用) • DBRE • Cloud Infrastructure • QA プラットフォーム部 プラットフォームG Platform Engineering SRE DBRE G MSP Cloud Infrastructure G アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 ・・・ QA G
5. 5 KTC DBRE のツール・サービスカタログ一覧 ツール・サービスカタログ 種別 できること どうゆう時に使う？ Aurora 3.0 移行 DBRE 提供サービス DBRE チームが Aurora 2 系から 3 系への DB 移行を実施。そ の他移行に伴う事前調査の実施など、手厚く伴走 Aurora クラスタを 3 系にバージョンアップしたい時 Aurora マイナーバージョンアップ通知 DBRE 提供サービス Aurora のバージョンアップが必要なタイミングで通知（現状は DBRE チームの方で自動検知後、slack で手動連絡） 必要なタイミングで通知されるので気にしなくてOK DBRESlackApps (SlowQueryDigest) Slack App 特定の期間内に発行された DB のスロークエリログを集計し、 解析しやすい形式でファイル出力できる スロークエリログを解析したい時 PowerPole Slack App 一定期間だけ有効な個人専用の踏み台サーバーの構築を Slack から実施できる 承認制で、申請から承認、結果の通知まで Slack で完結 承認制でセキュアな踏み台サーバー運用の仕組みを導入し たい時 PowerPole Tools コマンドラインツール PowerPole で立ち上げた踏み台サーバー上で、DB に関する各 種オペレーションを自動で実施 • DB ユーザー新規作成＆SecretsManager への登録 • DB のマイナーバージョンアップ実施 • DB ユーザーを新規作成したい時 • DB のマイナーバージョンアップを実施したい時 DB Catalog (shenron) DB 情報のカタログ ER 図やスキーマ定義の情報など、様々な情報を確認できる • ER 図を確認したい時 • スキーマを確認したい時 • DB のデータサイズを確認したい時 • DB に関する推奨の修正事項を確認したい時 DBStatsCollector モニタリングツール performance_schema などの DB 内部情報を定期的に S3 に収集し、Athena から SQL ベースで事後調査できる DB ロック競合起因のタイムアウトエラーの原因を調査した い時 Aurora DB PasswordRotation セキュリティソリューション DB ユーザーの定期的なパスワードローテーションを自動化できる GISS に記載されている、DB のシークレットローテーションの 要件に簡単に準拠したい時 生成 AI を活用したスキーマレビュー スキーマレビューツール PR 時に .sql が含まれていた場合、その DDL を CI によって 自動レビューを行うツール 新規でテーブルを構築する際に DBRE の設定したガイドラ インに沿った形で作成したい場合 Database に対するツール提供やオペレーションサポートなどを提供
6. Confluence / Jira / Findy Team+ 6 DBRE を支える管理ツール ◼ ドキュメント管理: Confluence ◼ 自分たちにとって最も重要なものは Confluence に書かれた Handbook ◼ タスク管理: Jira ◼ そのスプリントで自分たちが何をアウトプットするのかを把握 ◼ チームコンディション管理: Findy Team+ ◼ チームとしての活動を定量的に把握、継続的な改善を実施
7. Confluence 活用 01
8. DBRE にとって最も重要なものは Handbook という文化 8 Confluence ◼ DBRE Handbook は ◼ DBRE がどうあるべきか ◼ 未来に向けてどう成長・貢献していくかを示す「生きたドキュメント」 ◼ メンバー全員が参照し、意義を再認識できるリソース ◼ 急速に変化する技術や組織の要求 ◼ 常に一歩先を見据え、プロアクティブなアプローチが必要 ◼ 現在のベストプラクティスだけではなく、未来のビジョンと貢献の道筋を描くことが重要 開発生産性を語る前に、私たち DBRE がなぜ存在するのか、 その意義と目的を明確にすることが不可欠
9. DBRE がどうありたいか、を明確に示した Handbook 9 Confluence ◼ Top Page
10. DBRE がどうありたいか、を明確に示した Handbook 10 Confluence ◼ 3年戦略
11. DBRE がどうありたいか、を明確に示した Handbook 11 Confluence ◼ 採用 Interview
12. DBRE がどうありたいか、を明確に示した Handbook 12 Confluence ◼ Onboarding
13. DBRE がどうありたいか、を明確に示した Handbook 13 Confluence ◼ Working Agreements
14. 14 Confluence ◼ プロジェクトを円滑に進めるためのテンプレートを準備する ◼ テンプレートには誰がみても何を書けば良いのか明確にわかるように「プレースホルダーテキスト」を活用 開発生産性を上げるためのポイント①
15. 15 Confluence ◼ 同じことは何度も書かない ◼ インクルードを駆使して Single Source of Truth を意識する 開発生産性を上げるためのポイント② トップページ 子ページ
16. 16 Confluence ◼ “Handbook” とは願い ◼ マネージャーがそのメンバーに望む自分たちのあり方の理想を形にしたものであるべき ◼ どんなこともオープンに ◼ 誰がみてもわかりやすく ◼ 自分たちの活動に対して一つの羅針盤としての役割を持つ ◼ このように設計することで自然とチーム作りの土台ができる ◼ もちろん最初は大変ではある、が、その時間をかける価値はある 開発生産性を上げるためのポイント③ “法”とは願い! 国家がその国民に望む人間のあり方の理想を形にしたものだ！ 〜 キングダム 46巻より 〜
17. Jira 活用 02
18. 18 Jira ◼ タスクの意義を明確にする ◼ そのタスクがなぜ重要かを把握するように設計 ◼ タスクの進め方を可視化 ◼ 具体的にどのように進行するのかを明確にする ◼ 各個人の貢献を評価 ◼ ポイントでタスクの負荷や貢献度を定量化 Jira の役割と重要性
19. 19 Jira ◼ EPIC → Task → Sub Task 構成 ◼ EPIC ◼ 大きな目標やプロジェクト全体の枠組みの定義 ◼ チームの長期目標や大規模な機能開発を表す ◼ ex) データベースのバージョンアップ、新システム開発 ◼ Task ◼ EPIC を成し遂げるための具体的な活動や作業項目 ◼ 特定の目的に向けた明確なアクション含む ◼ ex) ソフトウェアの特定の機能開発 ◼ Sub Task ◼ Task をさらに細かい作業に分割 ◼ ここのステップや小規模なタスクに細分化して管理 ◼ ex) テスト環境のセットアップ、ドキュメント更新、〇〇機能のXX部分の開発 KTC DBRE の Jira 設計
20. 20 Jira ◼ Jira に WHY と WHAT を記載することを躊躇わない ◼ なぜそれをやるのか、何をするとそれが実現できるのかを全員で合意 ◼ 担当者が迷わず進められる 開発生産性を上げるためのポイント① EPIC Task
21. 21 Jira ◼ Sub Task は長くとも1日で終わる範囲まで分解する ◼ 進んでいる感触を常態化する ◼ 自分だけでできなくても仲間を頼れる ◼ 止まっている要因やポイントをすぐに話せる とは言え。。。 自分たちも完璧にできているとは言えない むしろ雑になりがちなので精度を上げていくことが課題 開発生産性を上げるためのポイント②
22. 22 Jira ◼ 自力でできないことはチケットを分ける ◼ いつまでも進まないチケットができてしまう ◼ 他力が入ることは別チケット化する ◼ ex) AWS 環境構築依頼 承認プロセス 他チーム調整 開発生産性を上げるためのポイント③
23. Findy Team+ 03
24. 開発プロセスを可視化 24 Findy Team+ ◼ Four Keys やサイクルタイムなどを GitHub(等) のデータから自動的に可視化 ◼ 自力で計りづらいチームアクティビティの状態を いい感じ に出力してくれる
25. Findy Team+ の活用 25 Findy Team+ ◼ 自分たちのアウトプットの平常を知る ◼ KTC DBRE はプロダクト開発の部署とは異なる特性を持っている ◼ 開発以外にも様々なタスクをこなしている ◼ プロダクト開発部署トラブルサポート ◼ AWS 新機能検証 ◼ Aurora バージョンアップ など ◼ 新規プロダクトの開発を行う確率が圧倒的に高い ◼ インセプションデッキの作成 ◼ アーキテクチャ設計 ◼ AWS 環境構築 ◼ これらがセットになっている ◼ つまり純粋なコーディングの時間よりもその他の時間に費やす時間が非常に多い
26. 開発生産性を上げるためのポイント① 26 Findy Team+ ◼ 純粋に数字だけを見るのではなく背後にある何か、を見極める必要がある
27. 開発生産性を上げるためのポイント① 27 Findy Team+ ◼ 純粋に数字だけを見るのではなく背後にある何か、を見極める必要がある 新規プロダクトの コーディング期間 リリース後の改善改修等 によるデプロイ頻度向上 DB 系イベント参加やトラブル対応、 新機能検証等が重なった時期 新規メンバー参入に伴い デプロイ頻度(率)の低下 新規メンバーオンボーディン グ完了により平常運転に
28. 開発生産性を上げるためのポイント① 28 Findy Team+ ◼ 純粋に数字だけを見るのではなく背後にある何か、を見極める必要がある ◼ PR を出したら必ずレビューをしてくれる人がいる ◼ レビューをするためにはコンテキストスイッチが必要ということを意識する ◼ 自分の作業を止めてレビューをしてくれる人がいるからアウトプットできる ◼ チームとしてのアウトプットを前提に人を見ることが重要 ◼ 誰かの PR 数が低いから悪い、のではなく、チーム全体でどれだけの PR がデプロイされたか、そしてそれに関わってくれた人がどだけいるのか を俯瞰して捉える
29. 29 Findy Team+ ◼ チーム目標設定を効果的に使う ◼ Findy Team +には目標設定ができる機能がある ◼ 会社内ではなく「世の中から見た自分たち」という視点で設定できる 開発生産性を上げるためのポイント②
30. 30 Findy Team+ ◼ 小さな改善を積み上げる ◼ チームふりかえりβ機能 ◼ 開発だけでなく、チーム全体でやれる小さな改善を積み上げる ◼ 自分たちが気持ちよく活動できる組織を構築する 開発生産性を上げるためのポイント③
31. 自分たちが大事にしていること 04
32. 自分たちの課題に合わせたツールの使い方をする 32 あるものをあるように使うこと ◼ 自分たちの課題をどのように解決できるかを考えてそのツールを活用することが重要 ◼ ツールに合わせて自分たちが変わろうとはしない ◼ ツールの仕様を受け入れた上でそれをどのように活用したら自分たちの課題を解決できるか、を考える ◼ どれだけ頑張っても提供されている以上のことはできない ◼ そこに頑張って工数を割くよりも、その仕様通りに工夫して使うことの方が生産性もポータビリティも高い ◼ そのツールがサービスダウンになったとしても待てば良い ◼ 基本的にそのツールが落ちたから仕事ができないわけでもないので慌てず騒がず自分の仕事をする ◼ どうしてもそのツールの復旧を待たなければいけなければ、コーヒー飲んで休めばいい
33. まとめ 05
34. Confluence / Jira / Findy Team+ 34 DBRE を支える管理ツール ◼ ドキュメント管理: Confluence ◼ 自分たちにとって最も重要なものは Confluence に書かれた Handbook ◼ タスク管理: Jira ◼ そのスプリントで自分たちが何をアウトプットするのかを把握 ◼ チームコンディション管理: Findy Team+ ◼ チームとしての活動を定量的に把握、継続的な改善を実施
35. 35 開発生産性を高めるポイント Confluence ◼ プロジェクトを円滑に進めるためのテンプレートを準備する ◼ テンプレートには誰がみても何を書けば良いのか明確にわかるように「プレースホルダーテキスト」を活用 ◼ 同じことは何度も書かない ◼ インクルードを駆使して Single Source of Truth を意識する ◼ “Handbook” とは願い ◼ マネージャーがそのメンバーに望む自分たちのあり方の理想を形にしたものであるべき
36. 36 開発生産性を高めるポイント Jira ◼ Jira に WHY と WHAT を記載することを躊躇わない ◼ なぜそれをやるのか、何をするとそれが実現できるのかを全員で合意 ◼ 担当者が迷わず進められる ◼ Sub Task は長くとも1日で終わる範囲まで分解する ◼ 進んでいる感触を常態化する ◼ 自分だけでできなくても仲間を頼れる ◼ 止まっている要因やポイントをすぐに話せる ◼ 自力でできないことはチケットを分ける ◼ いつまでも進まないチケットができてしまう ◼ 他力が入ることは別チケット化する
37. 37 開発生産性を高めるポイント Findy Team+ ◼ 純粋に数字だけを見るのではなく背後にある何か、を見極める必要がある ◼ チーム目標設定を効果的に使う ◼ Findy Team +には目標設定ができる機能がある ◼ 会社内ではなく「世の中から見た自分たち」という視点で設定できる ◼ 小さな改善を積み上げる ◼ チームふりかえりβ機能 ◼ 開発だけでなく、チーム全体でやれる小さな改善を積み上げる ◼ 自分たちが気持ちよく活動できる組織を構築する
38. 自分たちの課題に合わせたツールの使い方をする 38 あるものをあるように使うこと ◼ 自分たちの課題をどのように解決できるかを考えてそのツールを活用することが重要 ◼ ツールに合わせて自分たちが変わろうとはしない ◼ ツールの仕様を受け入れた上でそれをどのように活用したら自分たちの課題を解決できるか、を考える ◼ どれだけ頑張っても提供されている以上のことはできない ◼ そこに頑張って工数を割くよりも、その仕様通りに工夫して使うことの方が生産性もポータビリティも高い ◼ そのツールがサービスダウンになったとしても待てば良い ◼ 基本的にそのツールが落ちたから仕事ができないわけでもないので慌てず騒がず自分の仕事をする ◼ どうしてもそのツールの復旧を待たなければいけなければ、コーヒー飲んで休めばいい
39. Help Us Shape the Future ! KINTO テクノロジーズでは DBRE を始め、様々な職種で仲間を募集しています！ 少しでも興味がありましたらお気軽にご連絡ください
40. 40 mysql > SELECT ‘Questions’ FROM you;
41. 41 mysql > SELECT ‘Thank you’ FROM me;
42. THANK YOU!