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

まとめ: 学び 深い理解が鍵 聞くだけでは課題が⾒えない。⾃ら体験し、理解を深めることが重要。 実体験に基づく提案 ⾃らの経験から得られた洞察が、より効果的な解決策につながる。 段階的なプラットフォーム開発 属⼈的な解決から始め、徐々に⼀般化‧抽象化していく。 わからないなら、留学しよう!!