カミナシに必要な開発者体験を「サービス」という視点 からまとめてみた / The developer experience required by Kaminashi is viewed as a “service” I tried to summarize it from

2023/12/07：
【カミナシ x hacomono】成長過程のスタートアップに必要な開発者体験について考える
https://hacomono.connpass.com/event/299306/

カミナシに必要な開発者体験を「サービス」という視点 からまとめてみた

倉澤 直弘
EM

Transcript

1. カミナシに必要な開発者体験を「サービス」という視点 からまとめてみた
 株式会社カミナシ エンジニアリングマネージャー 　　　 　　　　　 倉澤 直弘
2. 自己紹介 • 名前: 倉澤 直弘 • 所属: 株式会社カミナシ • 役割: エンジニアリングマネージャー • 経歴: ◦ SESとかやってる企業 ◦ ECサイト向けにサービスを提供している企業 ◦ ニュースアプリの企業 ◦ カミナシ (2022年7月〜) • 今年の4月から初めてマネージャー業を始めました • 休日は子供と遊んでます
3. はじめに 会社紹介
4. 会社 & プロダクト紹介 日常はITに溢れているのに、仕事場は紙ばかりで非効率。 今日も作業現場で働く人たちは、十分に才覚を発揮できていない。 そんな3,900万人の埋もれたエネルギーを、私たちが解き放つ。 誰もが享受するべき当たり前を、すべての現場の人たちに届けたい。 効率的な作業、見事な成果、腕のなる仕事、豊かな人生。 これらはきっとつながっているから。 ノンデスクワーカーの 才能を解き放つ Mission
5. 会社 & プロダクト紹介 誰でも正しい手順で作業を実行 カミナシは、モバイルアプリを使って、 現場業務のムダを自動化するサービスです。 現場ＤＸプラットフォーム「カミナシ」 管理者の代わりに作業をチェック データから自動で集計・報告書を作成 改善活動をサポート
6. はじめに ここから本題
7. アジェンダ 1. カミナシにとって開発者体験が良いとは 2. 事例: 問い合わせ対応が多い 3. 事例: リリースの頻度が低い 4. 事例: 技術的負債の解消が進まない 5. まとめ
8. アジェンダ 1. カミナシにとって開発者体験が良いとは 2. 事例: 問い合わせ対応が多い 3. 事例: リリースの頻度が低い 4. 事例: 技術的負債の解消が進まない 5. まとめ
9. カミナシにとって開発者体験が良いとは 【カミナシ x hacomono】 成長過程のスタートアップに必要な開発者体験について考える 本日のイベントタイトル カミナシにとって開発者体験 が良いとはどういう状態とは なんだろう?
10. カミナシにとって開発者体験が良いとは "開発者体験"とはエンジニアとしての生産性を高めるための技術、チー ム、企業文化等の環境全般を指します。 引用: エンジニアが選ぶ「開発者体験が良い」イメージのある企業 https://cto-a.org/news/20230614 開発者体験とは
11. カミナシにとって開発者体験が良いとは 開発者体験が「良い」「悪い」とは 開発者体験が悪い 開発者体験が良い コードが複雑で理解に時間がかかる コードがシンプルで理解しやすい ビルドやCIが遅くて待ち時間が多い ビルドやCIが早くて待ち時間が発生しない リリース作業が手作業で大仕事だ リリースが自動化されていて手間がかから ない ミーティングや差し込みタスクが多い まとまった時間で開発に集中できる
12. カミナシにとって開発者体験が良いとは なんらかの目的に対してブロッカーが存在すること 開発者体験が「悪い」とは なんらかの目的に対してブロッカーが存在しないこと、もしくはその達成 を加速させること 開発者体験が「良い」とは なんらかの目的?
13. 「なんらかの目的」とは 前提としてカミナシの話 • カミナシではエンジニア、PM、デザイナで一つのサービスチームを 組成し共に行動しています。 • サービスチームがオーナーシップを持つのはプロダクト開発ではなく サービス提供です。 カミナシにとって開発者体験が良いとは 1 2
14. カミナシにとって開発者体験が良いとは 「なんらかの目的」とは 「サービス」と「プロダクト」を飲食店で例えると • プロダクト = 料理 • サービス = それ以外全て ( 席に案内する、水を出す、メニューを見せる、料理を 運ぶ、店を掃除するなど ) 料理だけでお客様に価値を提 供できない
15. カミナシにとって開発者体験が良いとは 「なんらかの目的」とは 弊社 CTO のありがたいお言葉
16. カミナシにとって開発者体験が良いとは 「なんらかの目的」とは 「なんらかの目的」に対してブロッカーが存在しないこと、もしくはその 達成を加速させること (再掲) 開発者体験が「良い」とは カミナシのサービスチームに所属する開発者はサービスを提供することが責 務であるため、「お客様へサービスを提供すること」を「なんらかの目的」 とします。 「なんらかの目的」とは
17. カミナシにとって開発者体験が良いとは サービス提供 プロダクト 開発 お客様へのサービス提供に対してブロッカーが存在しないこと、もしくは サービス提供を加速させること カミナシにとって開発者体験が良いとは プロダクト開発だけではなく、 サービス提供全体を考えるのが大事
18. アジェンダ ここからは開発者体験を向上させるための 具体的な事例を紹介します
19. アジェンダ 1. カミナシにとって開発者体験が良いとは 2. 事例: 問い合わせ対応が多い 3. 事例: リリースの頻度が低い 4. 事例: 技術的負債の解消が進まない 5. まとめ
20. 事例: 問い合わせ対応が多い • エンジニアへの差し込みタスクが多く生産性が悪化 • お客様に対してスピーディーな解決が提供できていない • 問い合わせの窓口のCSチームとエンジニア間のコミュニケーションコスト増加 課題 (サービス提供へのブロッカー) 不具合や、お客様自身で対応できないデータの修正依頼などに関するお客様からの 問い合わせが多かった。 起きていたこと
21. 事例: 問い合わせ対応が多い 対応策① 全部マネージャがさばく 対応策② オンコール体制の整備 対応策③ 社内向け管理画面の作成 太古の昔 2022年夏ごろ 2022年秋ごろ マネージャーのみだと持 続可能性がない & ボール がこぼれる可能性がある ため、問い合わせ担当を 回した。 サポートチーム内で調 査、対応を行える機能を 持った管理画面を作成し た。 問い合わせ対応をマネー ジャーが一手に引き受 け、メンバーへの差し込 みを減らした。
22. 事例: 問い合わせ対応が多い • サポートチーム内で問い合わせを完結できることが増えた • その結果、サービスチームへの差し込みが減少 • CS チームとサービスチーム間のコミュニケーションのコストの低下 • お客様への対応速度もアップ (管理画面で対応できるものにおいて) 社内向け管理画面の結果
23. 事例: 問い合わせ対応が多い • 問い合わせ対応も「サービス」の一部なので、その体験をチーム外 も含めて整理していくことが大事 • チーム内だけでなんとかしようとすると効果は限定的になってしま う可能性がある • お客様へは直接提供しない機能、プロダクトを作ることによって 「サービス」を改善できることがあり、これを手段として持ってお くことは重要 学び
24. アジェンダ 1. カミナシにとって開発者体験が良いとは 2. 事例: 問い合わせ対応が多い 3. 事例: リリースの頻度が低い 4. 事例: 技術的負債の解消が進まない 5. まとめ
25. 事例: リリースの頻度が低い • カミナシのお客様の特性もあり、説明、周知を考えてリリース日を週 2回に固定している • リリースの1週間前に何をリリースするかCSチームに連携している (予定が変わることは許容されています) 現状
26. 事例: リリースの頻度が低い • 開発サイクルがリリース日に引っ張られて遅くなる • リリースが大きくなりがちで問題が発生した場合の対応の難易度が上がる サービスチーム内の課題 (サービス提供へのブロッカー) • CSチーム ◦ 事前にお客様に伝えたい ◦ 事前に機能について確認したい • セールス、マーケティング、広報 ◦ 使える情報があれば使いたい • それに対して、サービスチーム内ではリリース情報の共有がうまく行っていな かった サービスチーム外の要望 (サービス提供に必要なこと)
27. 事例: リリースの頻度が低い レベル 内容例 伝える対象例 伝える時期例 0 顧客から認識できない修正 なし なし 1 特定の顧客に軽微な影響がある 修正 CS、サポート リリース時 2 全ての既存顧客に影響があるも の CS、サポート、PMM リリース1週間前 3 新規開拓に利用可能 CS、サポート、PMM、セールス リリース4週間前 4 マーケティングに利用可能 CS、サポート、PMM、セールス、マーケ、広報 リリース6週間前 ※表の内容は例です • リリースレベルを設定し、適切な人に、適切な時期に適切な内容で伝える • 事前に伝える必要のないものはリリースを自由にする 対応策
28. 事例: リリースの頻度が低い • 適切に情報を届けることもサービスの一部であり、オーナーシップを持つ必 要がある • 自分たちの課題だけでなく、ステークホルダーの課題へをも目を向けること で物事を進めやすくなる • チームで自律的に行動したい場合は、チーム外へプロアクティブに情報を共 有する必要がある ※ちなみに、この運用はちょうど始めたところで結果はまだ出ていません。 学び
29. アジェンダ 1. カミナシにとって開発者体験が良いとは 2. 事例: 問い合わせ対応が多い 3. 事例: リリースの頻度が低い 4. 事例: 技術的負債の解消が進まない 5. まとめ
30. 事例: 技術的負債の解消が進まない • 技術的負債がたくさんあるが対応が進まない ◦ コードの質、DB設計、アーキテクチャ、インフラの課題など様々 • 理由) 機能開発や不具合修正と比較して優先順位をあげられなかった 何が起こっていたか • 機能開発や不具合修正のスピードが落ちる • 問い合わせの調査に時間がかかる • 不具合の数が増える • 結果としてサービスの質や提供速度が落ちていた 起きた課題 (サービス提供へのブロッカー)
31. 事例: 技術的負債の解消が進まない 対応策① 機能開発をストップ 対応策② 50%ルール 対応策③ チーム分割 2022年5月~6月 2022年7月~ 2022年秋ごろ 機能開発を完全にストッ プして負債解消の期間を 取った。 開発リソースの50%を負 債解消に当てるルールを 作る。 結局、機能開発などに 引っ張られうまく運用で きず。 負債解消チームと機能開 発チームに分けた。 人数の増加や、重要な新 機能開発のプロジェクト が始まったことも理由。 2023年4月までの一時的 な分け方。
32. 事例: 技術的負債の解消が進まない 対応策④ 内部品質改善スプリント 対応策⑤ やっていきの会 2023年4月~ 2022年7月ごろ〜 技術領域ごとに有志メン バーが集まり課題の整理 と対応を行うようになっ た。ボトムアップ的に始 まった活動。 現在はフロント、API、 DBに分かれている。 チーム横断で活動する場 になっている。 負債解消チームを通常の サービスチームに戻す上 で作ったルール。 3週間通常のスプリントを 回した後に、1週間内部品 質改善のタスクのみ行う スプリントを実施する。
33. 事例: 技術的負債の解消が進まない • 内部品質改善スプリントによって、負債解消と機能開発が一つのチームで同 時に進むようになった • 一方で、内部品質改善スプリントでは一部をのぞいて個人ごとに単発のタス クをこなすことが多く、大きめの課題が当初は進んでいなかった • しかし、やっていきの会によって各領域ごとに課題を整理することで方向性 を決めて大きめの課題に着手できつつある • ただし、月に1週間のペースでは進捗は限定的 結果
34. • 内部品質改善スプリントではあえてエンジニアのみに閉じて、PM への説明責 任をスキップして対応にあたれるようにしていた。 • やっていきの会で課題が整理され出したこともあり、今後は PM も含めて サービスチーム全体で負債解消について会話し、可能なら通常スプリントで 対応することも含めより良い方法を模索していく 事例: 技術的負債の解消が進まない これからの話
35. • 内部品質も「サービス」の一部であり、内部品質が低下することでお客様へ のサービス提供の質、スピードに影響が出る • PM だけでタスクの優先順位を決めたり、エンジニアだけが内部品質を気にし たりでは効果は限定的になってしまう • PM は内部品質に理解を示す必要があるし、エンジニアはPMに対して説明す る責任がある • 全てはより良いサービス提供のために 事例: 技術的負債の解消が進まない 学び
36. アジェンダ 1. カミナシにとって開発者体験が良いとは 2. 事例: 問い合わせ対応が多い 3. 事例: リリースの頻度が低い 4. 事例: 技術的負債の解消が進まない 5. まとめ
37. • 私の考えるカミナシにおける開発者体験がいい状態は「お客様へのサービス 提供に対してブロッカーが存在しないこと、もしくはサービス提供を加速さ せること」 • プロダクト開発に閉じずに、サービス提供に視野を広げることでより良い体 験を作れるはず まとめ まとめ サービス提供 プロダクト 開発 これが大事
38. おわり We are hiring !! カミナシ Entrance book エンジニア
39. おわり ご清聴ありがとうございました！