Backlogで見える化したら 情報共有のその先が見えてきた話

JBUG福岡#22「『伝えたはず』をなくす！Backlogで実践する属人化・情報分散の解消術」での登壇資料です

Transcript

1. Backlogで見える化したら 情報共有のその先が見えてきた話 ホライズンテクノロジー株式会社 VPoE　望月 眞喜
2. ⾃⼰紹介 望⽉ 眞喜 Maki Mochizuki 職業：バックエンドエンジニア / VPoE 所属：ホライズンテクノロジー株式会社 • 2024.3〜 ⼊社 • 2026.1〜 VPoE就任 プライベート 趣味: 愛⽝との散歩 🐶 習い事: 習字、ハウスダンス 受託開発案件中⼼に、テクノロジーを活⽤した 「新規事業の⽴ち上げ⽀援」を⾏っています。 現在はテックリード的な⽴ち位置で案件に⼊りながら、 VPoEとして組織づくりにも挑戦しています 💪
3. 今⽇伝えたいこと 単なる情報共有の効率化ではなく、 「Backlogは組織⽂化を変えるインフラになる」 前提 最初から狙ったことではなく、 結果としてこうなりつつある、ということです。 本⽇の共有内容 具体的な事例や社内の変化の過程を中⼼に共有します。
4. 2年前の社内のリアル ⼊社当時の状況 情報の散在による「カオス」な状態 統⼀ツールがなく、スプレッドシート‧Drive‧Slack‧⼝頭に情報が完全に散在。「あるのに⾒えない」状態でした。 管理不全 置き場所がバラバラで最新情報が不明確 教育コスト オンボーディングに多⼤な労⼒が必要 ⾮標準化 プロジェクトごとにやり⽅が異なり⾮効率 → ⾼い情報探索コストと属⼈化により、⼊社直後にプロジェクトへの合流に⾮常に苦労した状況でした。
6. Backlog導入まで Backlog導⼊の決め⼿ 情報共有基盤 社内の情報を⼀元管理できる基盤を 求めていた 定額制の料⾦体系 ⼈数課⾦ではないため、 受託開発の組織として導⼊しやすい Wiki×課題管理 動的なタスクと静的なWikiが近く 密に紐づく利便性 「タスク管理」と「Wiki」が最も近い距離で紐づくツールだからこそ、情報の探索コストを下げられると期待。 → 導⼊当初の期待：情報を探しやすくしたい、属⼈化を減らしたい
7. Backlog活用事例① 定着のためにやったこと3つ 01 Wikiへの情報整備 プロジェクト情報をキャッチアップしな がら整備 • Wiki機能を積極活⽤（現在はドキュ メント機能へ移⾏） 02 良い課題の書き⽅共有 積極的にノウハウをナレッジ化 • プロジェクト内外で、 良い事例の共有を⾏う 03 知⾒のドキュメント化 プロジェクト横断での知⾒置き場を作成 • 開始時チェックリスト、課題ステー タス管理等の雛形をPMメンバーで 作成
8. 実際のプロジェクト内での Wiki活用の例
9. 良い課題の共有
10. プロジェクト横断でのドキュメント作成 PMメンバーでの情報共有会
11. プロジェクト横断でのドキュメント作成 社内部活の活動記録
12. Backlog活⽤事例② 個⼈的な⼯夫の例 プロジェクト開始時のルーティン プロジェクトが始まると、まずBacklogを整理する習慣をつけた • ドキュメントの集約：プロジェクト概要などをまとめていく（テンプレート活⽤） • 標準化の推進：開発ルール、コミュニケーションガイドラインなど、毎回伝えることをドキュメント化
13. コミュニケーションガイドライン
14. コミュニケーションガイドライン
15. Backlogによってプロジェクト進行がスムーズに 情報共有が当たり前になった  プロジェクト内での 共通認識ができた  オンボーディング しやすくなった  当たり前にドキュメントを 追加してくれる
16. 情報共有だけじゃなかった変化① 情報共有の「その先」にあった価値  変化①： 「良い仕事」の可視化 成果物だけでなく、調査や意思決定の思 考プロセスが⾒えるようになった。  変化②： 「褒めポイント」の増加 ログベースで具体的な称賛が可能にな り、ポジティブなフィードバックが増え た。  変化③： チームの知⾒へ昇華 個⼈の経験が他プロジェクトへ展開され たり、参考にする動きができたり、組織 全体への標準化が進んだ。 プロジェクトを超えた知⾒の共有により、組織的な協働が明らかに促進された！
17. 褒めあえる文化に！ 🎉
18. 調査の過程を残す習慣に
19. 情報共有だけじゃなかった変化 ② あるジュニアエンジニアが劇的に成⻑した話 Before: いきなり作業に着⼿する（コードを書く）と⼿戻りや考 慮もれが多い、思考がブラックボックス化 前提の認識合わせが⼤変でレビューコストもかかる After: Backlog上で「実装⽅針」を整理 ➔ レビュー ➔ 実装の段 階を踏むようにした 結果として圧倒的に⼿戻りが減り、設計の観点が⾝につ いた 何が起きたか： • 判断理由が可視化され、作業前（コードを書く前）に軌道修正が可能に • レビュワーがログベースで具体的に褒め、フィードバックできるようになった 結果： ジュニアエンジニアが驚くほどのスピードで劇的に成⻑ Design Docの取り組みをBacklogのコメントに書くようルール化。徹底することで思考プロセスへのフィードバックが回せるようになった 参考: Design Docのススメ ⸺ 「スムーズなプロジェクト進⾏」を⽀える共通⾔語（SmartHRブログ）
20. まとめ 導⼊当初の期待 • 情報を探しやすくしたい • 属⼈化を減らしたい • 業務を効率化したい 導⼊後2年経っての変化 • プロジェクトの情報はBacklogにある • 課題ベースでタスク管理 • Backlogの課題をうまく使って議論ができる • 思考プロセスや調査過程をドキュメントに残すことの 価値を共通認識として持っている 結論 結果として、「ドキュメントに残す」という作業が「チームで仕事を進める」という意識へつながりつつある Backlogでの情報共有をきっかけにメンバーの働き⽅や意識が確実に変わってきている
21. 情報共有のその先にあったもの まだまだ完成形ではありませんが、社内には今、『背景を残す、判断を残す、学びを残す』という 仕事のプロセスの⾒える化を通じて、お互いをリスペクトし合う価値観、つまり『組織の⽂化』が確実に育ち始めています
22. 情報共有のその先にあったもの まだまだ完成形ではありませんが、社内には今、『背景を残す、判断を残す、学びを残す』という 仕事のプロセスの⾒える化を通じて、お互いをリスペクトし合う価値観、つまり『組織の⽂化』が確実に育ち始めています
23. 今⽇伝えたいこと 単なる情報共有の効率化ではなく、 「Backlogは組織⽂化を変えるインフラになる」