開発と営業のコミュニケーションを円滑にする社内リリースノートのすすめ

こんにちは、 CARTA 技術広報 のしゅーぞー (ShuzoN__)です。

営業チームと開発チームが分離しており「営業チームから見てエンジニアが何をやっているの」か分からない課題、ありませんか?

かつてその課題に向き合ったエンジニア、かぬーさん(kanufy)にその取り組みとアプローチについて聞いていきます。

まとめ

  • 「営業チームから見て開発チームが何をやっているのか」分からず心理的な距離感の遠さがあった
  • エンジニアが営業チーム向けの機能リリースノートを書くと 「開発チームの仕事」が目に見えるようになった
  • 継続的に続けると感謝される上に振り返りにも使えるし、結果的に良いことしかなかった

自己紹介

かぬーさん

しゅーぞー: かぬーさん、自己紹介からお願いします。

かぬー: はい。株式会社サポーターズ(以下、サポーターズ)のエンジニアをやっています、かぬーです。主にフロントサイドを担当していて、たまにAPIの開発もやっています。

しゅーぞー: 今日はかぬーさんが取り組んでいる、サポーターズの社内向けリリースノート「かぬー通信」について聞いていきます。よろしくおねがいします。

かぬー: よろしくおねがいします。

社内向けリリースノート「かぬー通信」とは

しゅーぞー: 早速ですが、「かぬー通信」について聞いてみたいと思います。「かぬー通信」とはなんですか?

かぬー: 「かぬー通信」はユーザから見て「目に見えて使える機能」に限定した社内向けのリリースノート です。言い換えれば非エンジニア用のリリースノートですね。 一般的にリリースノートと聞くと「リリースバージョンごとの変更・修正差分」の全てをまとめたものを想像しますよね。かぬー通信では「目に見える機能」しか扱いません。

社内向けリリースノート「かぬー通信」の例

ポリシーは「ユーザから見えて使える機能だけを書く」こと

しゅーぞー: 「ユーザから見て目に見えて使える機能に限定した」とはどういうことですか?

かぬー: 例えば、API追加やリファクタリング、ライブラリのアップデートのようにユーザからすると見えず使えない機能の追加、変更はリリースノートに載せないようにしています。 これらは載せてもビジネスサイド、ユーザから見て直接使えるものではないためノイズになると判断しています。ですから、かぬー通信に乗せるものは「ユーザから見えて使える機能」に限定しています。

書き方としては以下3つを書く感じですね。

  • 新機能
  • 修正・変更
  • 最近の近況

社内向けリリースノート「かぬー通信」のメリット・デメリット

しゅーぞー: 「かぬー通信」のメリット・デメリットを教えて下さい。

メリット

かぬー: メリットは以下のとおりです。 正直やってみてメリットしかなかったです。

  • 開発チームの仕事が目に見えるようになる
  • 要望の着手や改善対応に営業チームが気付ける
  • 他チームのための機能追加であっても、便利だと認知されるとサポーターズ内全体に利用が広がる
  • 開発チーム振り返りや事業部のマネージャー定例に利用できる

かぬー: 実際にやってみると 「新しい機能や改善を知れるから助かっている!ありがとう!」と言われることが多い です。それが続けるモチベーションになっていますね。

しゅーぞー: 「助かっている」とは具体的にはどのような声がありましたか?

かぬー: 例えば以下のように色んな声がありますね。

  • 「開発要望を挙げた機能が進んだのか進んでないのかわかる」
  • 「あの機能作ってくれたんだ、嬉しい」
  • 「便利な機能みたいなのを作ったときにすぐ"かぬー通信"によって分かるから使ってみよう」

かぬー: エンジニアとしても作りっぱなしで使ってもらえなかったら意味がない ので使ってもらえるように啓蒙活動の意味もあるかもしれないです。

デメリット

しゅーぞー: 「かぬー通信」のデメリットを教えてください。

かぬー: あまりないんですが手間がかかることですかね...? 今はチームの中でも私がまとめています。私がいない時は、たまにメンバーがまとめてくれたりもしています。


どうして社内向けリリースノート「かぬー通信」を始めたのか

しゅーぞー: 「かぬー通信」を始めた理由を教えてください。

かぬー: 2019年当時、営業チームから向けられる"何をやってるか分からない"心理的な距離感の遠さを解消するためにやりはじめました。 「もう少しうまく開発チームがやっていることを伝えられるといいな」と思って最初は趣味感覚で始めたものです。

しゅーぞー: 心理的な距離感の遠さがあったんですね。

かぬー: あった気がしますね。

外注システムから内製化システムへの変遷

かぬー: 当時のサポーターズは外注システム(以下、レガシー)から内製化システム(以下、NEXT)への移行期でした。 私がサポーターズに着任したときはレガシーをメインに利用していて、ちょうどNEXTの内製化プロジェクトが開始したタイミングでした。

当時の話は、書籍『事業をエンジニアリングする技術者たち 』の「第5章 サポーターズ ― 事業の成長を止めない手段としてのシステム刷新」にも載っています。

営業チームと開発チームのオフィスが離れていた

かぬー: しかも、営業チームと開発チームが別のオフィスで働いている状態でした。 COVID-19禍前にもかかわらず、コミュニケーションはほとんどオンラインでした。つまり、営業チームと開発チームの間でコミュニケーションが分断しやすい物理的制約があったんですよね。

しゅーぞー: なるほど。営業チームと開発チームが物理的に離れていた。

かぬー: そう。なので 「物理的に離れている上に長期プロジェクトで目に見える成果がない。営業からすると開発チームは何をやっているのか分からない」状態 でした。

しゅーぞー: 私も同時期にサポーターズの営業チームにいたので体感を持って話せますが、確かに開発チームが何をしているかあまりわかりませんでしたね。

初期のかぬー通信

かぬー: そう。2019年1月にNEXTのファーストリリースが終わった後から「かぬー通信」をはじめました。最初は特にメンションをつけずSlackに投稿していたのですが、 営業チームから「これは大事だから@channel」をつけてと言われ今でもつけています。 かれこれ3年ちょっと続いていて自分でも驚きです。

自動化しようとは思わなかった?

しゅーぞー: 「かぬー通信」書くの大変そうですよね。自動化は考えなかったんですか?

かぬー: 自動化は無理じゃないかな、と思ってやっていません。私が書くから価値があると思ってます。 例えば「誰々が困ってたのを教えてくれたから直しといたよ」とかそういう温かみのあるメッセージに価値があると思っています。

かぬー: もちろんGitHubのPull Requestタイトルをフィルタして出すことも出来るだろうけど、やろうとは思わないですね。

しゅーぞー: なるほど。今日はありがとうございました。

かぬー: ありがとうございました。