開発チームへのディープダイブで見えてきた顧客＝開発者の本当の課題/sre-next-2024-link-and-motivation

SRE NEXT 2024 IN TOKYO

リンクアンドモチベーション登壇資料（2024/08/04）

『開発チームへのディープダイブで見えてきた顧客＝開発者の本当の課題』

##srenext #リンモチ
=============================================
【イベント情報】
■イベントページ
https://sre-next.dev/2024/

【株式会社リンクアンドモチベーション】
■お問い合わせ
　engineer_pr@lmi.ne.jp
■テックブログ
　https://link-and-motivation.hatenablog.com/
=============================================

Transcript

1. 開発チームへの ディープダイブで⾒えてきた 顧客 = 開発者 の本当の課題 株式会社リンクアンドモチベーション 伊藤遼
2. 伊藤 遼 @haruka_odenkun 所属: 株式会社リンクアンドモチベーション 趣味: 旅⾏ 簡単な経歴: 2019年 新卒⼊社 モチベーションクラウドをはじめとした ⾃社サービス開発に関わる 2023年よりイネーブリングチーム
3. チーム体制 チームの役割 ⾃社サービスを横串で⽀える ミッション 開発⽣産性向上への取り組み
4. ある⽇... 「新規プロダクト今年で10個作りたいから、作れるようにしといて」 「ん？え？」 新規サービス開発を⾏うPoCチームの⽣産性向上を⾏うことに
5. 課題ヒアリング① 「今何に困ってますか？」 「社内で少し触ってもらおうと思ってるんだけど、なんか不安」 課題が曖昧で、出てこない
6. 課題ヒアリング② 「今何に困ってますか？」 「ライブラリのアップデートとメールも送れるようにしたいし、Feature Flagとかあっ たら便利でいいな。あ、Linter/Formatterも⼊れたいし、あ、エラー通知も.....」 本当に解くべき課題がわからない
7. こんなことありませんか...?? そもそも、開発チームとの距離がある ƹ 最近あのチームと話したかな... ダッシュボードやメトリクスだけから課題を出す ƹ ここが課題じゃーん!! アンケートやヒアリングで課題をわかった気になる ƹ なるほど、これ困ってるんだな!!
8. 外から⾒聞きするだけでは重要な課題はわからない ヒアリングの限界 ヒアリングだけでは 本当に重要な課題がわからない 解決策の不確実性 課題が不明確だと 解決策も不確実になる PoCチームの特性 特にPoCを⾏っているチームは 取り組む課題の移り変わりが早い 無駄な開発のリスク 使われないものを作ってしまうかも 中に⼊り込まないと解くべき課題は⾒えてこない
9. 当時の私の振り返りメモ
10. 深く潜り込んで解像度をあげる 物理的に近くにいく オフィスにいるときは近くの席に 朝会や振り返り、プランニングに参加 実際の開発のタスクを持つ 機能実装のタスクをもらう 1開発者として振る舞う 開発チームの⼀員として経験することで課題の解像度をあげる
11. ディープダイブすることで⾊々⾒えてきた チームの置かれている状況 開発プロセスの全貌 顧客やステークホルダー ⽬標とその道筋の把握 直⾯している/しそうな課題 直近で困っている課題 これからぶつかりそうな課題 それらの課題を解決した時のインパクト ⾃分が直⾯した課題を集めて整理する
12. 課題解決に向けて ⾃分がオンボーディングしながら道を整える 属⼈的に解決する 必要なものをテンプレートとして提供する
13. ⾃分がオンボーディングしながら課題を解決する 実際にやったこと リポジトリの整理 不要になったコードの削除 ⼿順書の作成 ローカル開発の⼿順を記載 スタイルの設定 Linter/Formatterを定義 まずは⾃分が開発し始めるときに困ったことを解決し、整えていく
14. 属⼈的に解決する 実際にやったこと 検証環境の構築 Streamlit Community Cloud からECS on Fargateにサクッ と構築 データストアの⽤意 Google Sheetsから DynamoDBへ移⾏ 社内⽤ 認証/認可の仕組み 社内のGoogle Workspaceと OpenID Connectを利⽤ ⼿動で良いので重要な課題に着⼿していく
15. 必要なものをテンプレートとして提供する 実際にやったこと SDKとecspressoを利⽤し た検証環境構築フロー ぽちぽちすれば社内公開可能 な環境が構築 よく使うコマンドを記した Makefile 開発作業の効率化をサポート テンプレートGitHubリポ ジトリ これらを盛り込んだリポジト リを提供 ニーズを捉えられたら、整えて再利⽤可能な形にしていく
16. さらに... 多様なフレームワークに対応 Streamlit (Python) だけでなくNext.jsでもアプリを作れるように 効率的で中央集権な管理 テンプレートの管理をTerraformに移⾏しまとめて管理しやすいように 機能の拡張 エラー監視 (Sentry) やメール機能 (SendGrid) なども簡単に利⽤できるように テンプレートを徐々に進化させていく
17. ざっくり最終的なイメージ…
18. まとめ: 課題 課題認識の不⾜ 開発チーム内で課題が⼗分に共有されておら ず、全体像の把握が不⾜していた 優先順位づけの困難 多くの課題が存在し、限られた経営資源の中で 優先順位づけが難しかった PoCチームの変化への追随 チームを取り巻く環境の変化が激しく、そのス ピードに開発環境が追いつけていなかった 開発環境の属⼈化 開発環境の構築や運⽤が個⼈に依存しており、 チーム全体での共有が不⾜していた
19. まとめ: ⼊り込んで解決する ⾃分がオンボーディングしながら道を整える 属⼈的に解決する 必要なものをテンプレートとして提供する
20. まとめ: 学び 深い理解が鍵 聞くだけでは課題が⾒えない。⾃ら体験し、理解を深めることが重要。 実体験に基づく提案 ⾃らの経験から得られた洞察が、より効果的な解決策につながる。 段階的なプラットフォーム開発 属⼈的な解決から始め、徐々に⼀般化‧抽象化していく。 わからないなら、留学しよう!!