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

Slide 1

Slide 1 text

カミナシに必要な開発者体験を「サービス」という視点からまとめてみた  株式会社カミナシエンジニアリングマネージャー　　　　　　　　倉澤直弘

Slide 2

Slide 2 text

自己紹介 ● 名前: 倉澤直弘 ● 所属: 株式会社カミナシ ● 役割: エンジニアリングマネージャー ● 経歴: ○ SESとかやってる企業 ○ ECサイト向けにサービスを提供している企業 ○ ニュースアプリの企業 ○ カミナシ (2022年7月〜) ● 今年の4月から初めてマネージャー業を始めました ● 休日は子供と遊んでます

Slide 3

Slide 3 text

はじめに会社紹介

Slide 4

Slide 4 text

会社 & プロダクト紹介日常はITに溢れているのに、仕事場は紙ばかりで非効率。今日も作業現場で働く人たちは、十分に才覚を発揮できていない。そんな3,900万人の埋もれたエネルギーを、私たちが解き放つ。誰もが享受するべき当たり前を、すべての現場の人たちに届けたい。効率的な作業、見事な成果、腕のなる仕事、豊かな人生。これらはきっとつながっているから。ノンデスクワーカーの才能を解き放つ Mission

Slide 5

Slide 5 text

会社 & プロダクト紹介誰でも正しい手順で作業を実行カミナシは、モバイルアプリを使って、現場業務のムダを自動化するサービスです。現場ＤＸプラットフォーム「カミナシ」管理者の代わりに作業をチェックデータから自動で集計・報告書を作成改善活動をサポート

Slide 6

Slide 6 text

はじめにここから本題

Slide 7

Slide 7 text

アジェンダ 1. カミナシにとって開発者体験が良いとは 2. 事例: 問い合わせ対応が多い 3. 事例: リリースの頻度が低い 4. 事例: 技術的負債の解消が進まない 5. まとめ

Slide 8

Slide 8 text

Slide 9

Slide 9 text

カミナシにとって開発者体験が良いとは【カミナシ x hacomono】成長過程のスタートアップに必要な開発者体験について考える本日のイベントタイトルカミナシにとって開発者体験が良いとはどういう状態とはなんだろう?

Slide 10

Slide 10 text

カミナシにとって開発者体験が良いとは "開発者体験"とはエンジニアとしての生産性を高めるための技術、チーム、企業文化等の環境全般を指します。引用: エンジニアが選ぶ「開発者体験が良い」イメージのある企業 https://cto-a.org/news/20230614 開発者体験とは

Slide 11

Slide 11 text

カミナシにとって開発者体験が良いとは開発者体験が「良い」「悪い」とは開発者体験が悪い開発者体験が良いコードが複雑で理解に時間がかかるコードがシンプルで理解しやすいビルドやCIが遅くて待ち時間が多いビルドやCIが早くて待ち時間が発生しないリリース作業が手作業で大仕事だリリースが自動化されていて手間がかからないミーティングや差し込みタスクが多いまとまった時間で開発に集中できる

Slide 12

Slide 12 text

カミナシにとって開発者体験が良いとはなんらかの目的に対してブロッカーが存在すること開発者体験が「悪い」とはなんらかの目的に対してブロッカーが存在しないこと、もしくはその達成を加速させること開発者体験が「良い」とはなんらかの目的?

Slide 13

Slide 13 text

「なんらかの目的」とは前提としてカミナシの話 ● カミナシではエンジニア、PM、デザイナで一つのサービスチームを組成し共に行動しています。 ● サービスチームがオーナーシップを持つのはプロダクト開発ではなくサービス提供です。カミナシにとって開発者体験が良いとは 1 2

Slide 14

Slide 14 text

カミナシにとって開発者体験が良いとは「なんらかの目的」とは「サービス」と「プロダクト」を飲食店で例えると ● プロダクト = 料理 ● サービス = それ以外全て ( 席に案内する、水を出す、メニューを見せる、料理を運ぶ、店を掃除するなど ) 料理だけでお客様に価値を提供できない

Slide 15

Slide 15 text

カミナシにとって開発者体験が良いとは「なんらかの目的」とは弊社 CTO のありがたいお言葉

Slide 16

Slide 16 text

カミナシにとって開発者体験が良いとは「なんらかの目的」とは「なんらかの目的」に対してブロッカーが存在しないこと、もしくはその達成を加速させること (再掲) 開発者体験が「良い」とはカミナシのサービスチームに所属する開発者はサービスを提供することが責務であるため、「お客様へサービスを提供すること」を「なんらかの目的」とします。「なんらかの目的」とは

Slide 17

Slide 17 text

カミナシにとって開発者体験が良いとはサービス提供プロダクト開発お客様へのサービス提供に対してブロッカーが存在しないこと、もしくはサービス提供を加速させることカミナシにとって開発者体験が良いとはプロダクト開発だけではなく、サービス提供全体を考えるのが大事

Slide 18

Slide 18 text

アジェンダここからは開発者体験を向上させるための具体的な事例を紹介します

Slide 19

Slide 19 text

Slide 20

Slide 20 text

事例: 問い合わせ対応が多い ● エンジニアへの差し込みタスクが多く生産性が悪化 ● お客様に対してスピーディーな解決が提供できていない ● 問い合わせの窓口のCSチームとエンジニア間のコミュニケーションコスト増加課題 (サービス提供へのブロッカー) 不具合や、お客様自身で対応できないデータの修正依頼などに関するお客様からの問い合わせが多かった。起きていたこと

Slide 21

Slide 21 text

事例: 問い合わせ対応が多い対応策① 全部マネージャがさばく対応策② オンコール体制の整備対応策③ 社内向け管理画面の作成太古の昔 2022年夏ごろ 2022年秋ごろマネージャーのみだと持続可能性がない & ボールがこぼれる可能性があるため、問い合わせ担当を回した。サポートチーム内で調査、対応を行える機能を持った管理画面を作成した。問い合わせ対応をマネージャーが一手に引き受け、メンバーへの差し込みを減らした。

Slide 22

Slide 22 text

事例: 問い合わせ対応が多い ● サポートチーム内で問い合わせを完結できることが増えた ● その結果、サービスチームへの差し込みが減少 ● CS チームとサービスチーム間のコミュニケーションのコストの低下 ● お客様への対応速度もアップ (管理画面で対応できるものにおいて) 社内向け管理画面の結果

Slide 23

Slide 23 text

事例: 問い合わせ対応が多い ● 問い合わせ対応も「サービス」の一部なので、その体験をチーム外も含めて整理していくことが大事 ● チーム内だけでなんとかしようとすると効果は限定的になってしまう可能性がある ● お客様へは直接提供しない機能、プロダクトを作ることによって「サービス」を改善できることがあり、これを手段として持っておくことは重要学び

Slide 24

Slide 24 text

Slide 25

Slide 25 text

事例: リリースの頻度が低い ● カミナシのお客様の特性もあり、説明、周知を考えてリリース日を週 2回に固定している ● リリースの1週間前に何をリリースするかCSチームに連携している (予定が変わることは許容されています) 現状

Slide 26

Slide 26 text

事例: リリースの頻度が低い ● 開発サイクルがリリース日に引っ張られて遅くなる ● リリースが大きくなりがちで問題が発生した場合の対応の難易度が上がるサービスチーム内の課題 (サービス提供へのブロッカー) ● CSチーム ○ 事前にお客様に伝えたい ○ 事前に機能について確認したい ● セールス、マーケティング、広報 ○ 使える情報があれば使いたい ● それに対して、サービスチーム内ではリリース情報の共有がうまく行っていなかったサービスチーム外の要望 (サービス提供に必要なこと)

Slide 27

Slide 27 text

事例: リリースの頻度が低いレベル内容例伝える対象例伝える時期例 0 顧客から認識できない修正なしなし 1 特定の顧客に軽微な影響がある修正 CS、サポートリリース時 2 全ての既存顧客に影響があるもの CS、サポート、PMM リリース1週間前 3 新規開拓に利用可能 CS、サポート、PMM、セールスリリース4週間前 4 マーケティングに利用可能 CS、サポート、PMM、セールス、マーケ、広報リリース6週間前 ※表の内容は例です ● リリースレベルを設定し、適切な人に、適切な時期に適切な内容で伝える ● 事前に伝える必要のないものはリリースを自由にする対応策

Slide 28

Slide 28 text

事例: リリースの頻度が低い ● 適切に情報を届けることもサービスの一部であり、オーナーシップを持つ必要がある ● 自分たちの課題だけでなく、ステークホルダーの課題へをも目を向けることで物事を進めやすくなる ● チームで自律的に行動したい場合は、チーム外へプロアクティブに情報を共有する必要がある ※ちなみに、この運用はちょうど始めたところで結果はまだ出ていません。学び

Slide 29

Slide 29 text

Slide 30

Slide 30 text

事例: 技術的負債の解消が進まない ● 技術的負債がたくさんあるが対応が進まない ○ コードの質、DB設計、アーキテクチャ、インフラの課題など様々 ● 理由) 機能開発や不具合修正と比較して優先順位をあげられなかった何が起こっていたか ● 機能開発や不具合修正のスピードが落ちる ● 問い合わせの調査に時間がかかる ● 不具合の数が増える ● 結果としてサービスの質や提供速度が落ちていた起きた課題 (サービス提供へのブロッカー)

Slide 31

Slide 31 text

事例: 技術的負債の解消が進まない対応策① 機能開発をストップ対応策② 50%ルール対応策③ チーム分割 2022年5月~6月 2022年7月~ 2022年秋ごろ機能開発を完全にストップして負債解消の期間を取った。開発リソースの50%を負債解消に当てるルールを作る。結局、機能開発などに引っ張られうまく運用できず。負債解消チームと機能開発チームに分けた。人数の増加や、重要な新機能開発のプロジェクトが始まったことも理由。 2023年4月までの一時的な分け方。

Slide 32

Slide 32 text

事例: 技術的負債の解消が進まない対応策④ 内部品質改善スプリント対応策⑤ やっていきの会 2023年4月~ 2022年7月ごろ〜技術領域ごとに有志メンバーが集まり課題の整理と対応を行うようになった。ボトムアップ的に始まった活動。現在はフロント、API、 DBに分かれている。チーム横断で活動する場になっている。負債解消チームを通常のサービスチームに戻す上で作ったルール。 3週間通常のスプリントを回した後に、1週間内部品質改善のタスクのみ行うスプリントを実施する。

Slide 33

Slide 33 text

事例: 技術的負債の解消が進まない ● 内部品質改善スプリントによって、負債解消と機能開発が一つのチームで同時に進むようになった ● 一方で、内部品質改善スプリントでは一部をのぞいて個人ごとに単発のタスクをこなすことが多く、大きめの課題が当初は進んでいなかった ● しかし、やっていきの会によって各領域ごとに課題を整理することで方向性を決めて大きめの課題に着手できつつある ● ただし、月に1週間のペースでは進捗は限定的結果

Slide 34

Slide 34 text

● 内部品質改善スプリントではあえてエンジニアのみに閉じて、PM への説明責任をスキップして対応にあたれるようにしていた。 ● やっていきの会で課題が整理され出したこともあり、今後は PM も含めてサービスチーム全体で負債解消について会話し、可能なら通常スプリントで対応することも含めより良い方法を模索していく事例: 技術的負債の解消が進まないこれからの話

Slide 35

Slide 35 text

● 内部品質も「サービス」の一部であり、内部品質が低下することでお客様へのサービス提供の質、スピードに影響が出る ● PM だけでタスクの優先順位を決めたり、エンジニアだけが内部品質を気にしたりでは効果は限定的になってしまう ● PM は内部品質に理解を示す必要があるし、エンジニアはPMに対して説明する責任がある ● 全てはより良いサービス提供のために事例: 技術的負債の解消が進まない学び

Slide 36

Slide 36 text

Slide 37

Slide 37 text

● 私の考えるカミナシにおける開発者体験がいい状態は「お客様へのサービス提供に対してブロッカーが存在しないこと、もしくはサービス提供を加速させること」 ● プロダクト開発に閉じずに、サービス提供に視野を広げることでより良い体験を作れるはずまとめまとめサービス提供プロダクト開発これが大事