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