Webサービスの提供を軸に事業を複数展開する株式会社はてなの「はてなブログMedia」チームでは、セールス、ディレクター、エンジニアの部署間でのプロジェクト管理にBacklogが活用されています。 事業の成長とともに複雑さを増していく案件やチーム開発を支える「仕組み」をプロジェクト管理ツールのBacklogで構築したい、という目的のもと、部署ごとに異なっていたツールをBacklogに一本化しました。 セールスで定量化しづらい「顧客の温度感」をBacklogで5段階に可視化したことで、ビジネス事業部と開発事業部のコミュニケーションを促進し「問い合わせ管理の効率化」を実現したと語る「はてなブログMedia」プロデューサーに、Backlog導入の決め手と、チーム間の業務改善やコミュニケーションについてお話をお伺いしました。 ■プロフィール 株式会社はてな サービス・システム開発本部プロデューサー 磯和太郎(いそわ・たろう)さん
導入目的 | ■ 事業の成長とともに複雑さを増していく案件やチーム開発を支える「仕組み」をプロジェクト管理ツールのBacklogで構築したい |
課題 |
■ セールスはグループウェアやExcel、エンジニアはGitHub、と部署ごとにツールが異なり、情報も一元管理できていない ■ 案件やチームメンバーの増加によって、既存のプロジェクト管理形態ではコミュニケーションストレスが発生している ■ メールでは顧客からの問い合わせを社内共有するときに必要な情報が抜けており「こういう情報もほしい」という部署間のコミュニケーションリレーが頻発していた |
効果 |
■ Backlogでツールを一元管理できたことで、セールス、ディレクター、エンジニアの間で「部署をまたいで進捗を追う必要のある情報はBacklogを検索すれば確認できるよね」という状態ができた ■ ビジネスチームが持っている、優先度だけでは表現しきれない肌感を「顧客の温度感」として5段階レベルで設定できる仕組みを作り、エンジニアへの情報共有を円滑にした ■ 問い合わせに関する全ての情報をBacklog上で検索でき、部署間での情報確認のためのコミュニケーションが半減した |
業種 | Webサービス開発 / 運営 |
Backlogを利用している職種 | セールス、ディレクター、エンジニア |
利用規模 | 20アカウント |
目次
「はてな」のコンテンツマーケティングサービスをBacklogが支える
はてな様の事業と企業向けオウンドメディアCMS「はてなブログMedia」について教えてください。
株式会社はてなは、『「知る」「つながる」「表現する」で新しい体験を提供し、人の生活を豊かにする』というミッションのもと、Webサービスの開発と運営をしています。 ユーザーがテキストや画像などのコンテンツを発信・拡散できるプラットフォームを提供する「コンテンツプラットフォームサービス」、企業の良質なコンテンツ発信を通したマーケティング活動を支援する「コンテンツマーケティングサービス」、個人向けWebサービスの提供を通して培った技術やノウハウを企業にソリューションとして展開する「テクノロジーソリューションサービス」の3分野において、UGC(User Generated Contents=ユーザー生成コンテンツ)事業を展開しています。 そのなかで私がプロデューサーを担当する「はてなブログMedia」は、弊社が運営しているBtoCサービス「はてなブログ」をベースに、企業のオウンドメディアで活用いただけるように開発したCMSです。コンテンツマーケティングやオウンドメディアマーケティングを実施するための機能を追加して、企業が情報発信しやすいように開発しています。
はてなブログMediaのセールスは「売って終わらない」ことが特長ですね。一般的にイメージされている「受注がゴール」のセールスとの違いについて教えてください。
そもそもコンテンツマーケティング自体が「単純にものを売って終わり」という商材にはなりづらいですよね。もちろんSaaSサービスなので、受注がゴールな部分もありますが、お客様の課題を解決するためには「xxアカウントでいくらになります」で終わり、というやり方は通用しないんですよね。 はてなの営業部は、コンテンツマーケティングのプロフェッショナルとして、お客様の課題を解決するために、新規営業から企画提案、運用支援など、オウンドメディアに関する幅広いサービスを提供しています。CMSや広告枠の受注をゴールせずに、お客様へのはてなのブログMediaの導入〜公開~運用まですべての行程に関与できることが特長です。
一般的なセールス、というよりも「カスタマーサクセス 」的な動き方がしっくりきますね。
そうですね。私は「サービス開発側のプロデューサー」なのですが、カスタマーサクセス的な動きをすることも多いです。一方で「ビジネス開発側の責任者(営業部長)」もいるので、お互いにどうやって役割を分担していくのかは半期に一度見直しをかけています。 はてなのセールス全体で優先しているのは「お客様が契約前・後でちゃんと相談ができる体制」です。一般の営業職から見ると範囲が広いことをやっているので、カスタマーサクセス的な動きに見えるかもしれません。 そのため、お客様とは問い合わせをベースにして密に接するのですが、問い合わせの回答範囲が広く、回答に日数を要する質問をいただくこともあります。セールスだけでは判断できない、ディレクターとエンジニアが確認しないと回答できない難易度の高い技術的な質問を頂くこともあるので、そうしたコミュニケーションのパス回しを円滑にするために、Backlogを導入しました。
はてなブログMediaの成長とともに複雑さを増す案件やチーム開発を支える「部署をまたげるツール」が必要だった
Backlogを導入したきっかけについて教えてください。
私たちのチームでBacklogを導入することになったきっかけは、「はてなブログMedia」の成長とともに複雑さを増していく案件や増えていくメンバーに、既存のツールや仕組みでは十分に対応しきれなくなったことが理由です。 そこで「プロジェクト管理ツール」の導入を決め、複数のツールをチーム内で検証した結果、Backlogを導入すると決めました。現在では、はてなブログMediaに関わるセールスやエンジニアを含めた20人規模でBacklogを利用しています。
他のツールと比較してBacklogの決め手はなんでしたか?
Backlogの決め手はセールス、ディレクター、エンジニアなどいろいろな職種の人が同じレベルで使えるツールだったことです。 Backlogを導入する前は、エンジニアチームとビジネスチームの共通ツールが存在していませんでした。具体的には、エンジニアはGitHub、セールスチームはグループウェアやスプレッドシートなど、使用するツールが統一されていなかったのです。案件数が増えて既存のツールの仕組みだとコミュニケーションや業務管理が立ち行かなくなりました。 そこで「はてなブログMediaのサービス開発を部署の垣根を超えて共同で管理できるツールはなんだろう?」と考えBacklogを選びました。GitHubではセールスチームにとって使い勝手がよくない、かといってスプレッドシートやExcelでは事業部での管理にあまり向いていない、というのが理由です。
定量化しづらい「顧客の温度感」をBacklogで5段階の仕組み化し、セールスとエンジニアのコミュニケーションを促進
Backlog導入後、効果をどのように実感されていますか?
セールスとディレクター、エンジニアの間で起きていた、ミスコミュニケーションやストレスが軽減されました。以前は、セールスがお客様から直接聞いた機能実装や要望など、温度感が高いものはエンジニアに口頭で説明しなければなりませんでしたが、Backlogを導入したことで「温度感」を可視化する仕組みができ、コミュニケーションが円滑になりました。
Backlogを使った温度感の可視化はどう取り組まれているのですか?
ディレクターやセールスが持っている温度感・期日・優先度など、定量化できない「顧客の温度感」を5段階レベルで設定できる仕組みをBacklogの課題に作り、エンジニアに伝達できるようにしています。
詳細を説明すると、Backlogの課題に表示される項目をカスタマイズできるカスタム属性で「顧客の温度感」という項目をエンジニアに頼んで自社でカスタマイズしてもらいました。 他にも、備忘録としてお客様から「そういえばこういう機能いつか実装してほしいな」という今すぐじゃない要望も優先度を低くして、エンジニアに伝達できるようになりました。
Backlogのカスタム属性を使いこなされていますね。温度感という定量化しづらい項目を可視化したことで、部署間のコミュニケーションに変化はありましたか?
はい。部署ごとに導入していたツールをBacklogに一元化でき「部署をまたいで進捗を追う必要のある情報はBacklogを検索すれば確認できるよね」という状態を作れるようになりました。 以前は「スプレッドシートで検索して、なかったらメールで検索する」というような手間がよくありましたが、業務を進めていく過程で過去の案件の確認をしたいときに、検索すればすぐに参照できるようになりました。
セールス、エンジニア、ディレクター、誰が読んでも内容を理解できる「問い合わせ管理の効率化」を実現
Backlogで情報共有の仕組み化ができたことで、問い合わせ管理の進め方に変化があったのですね。
そうですね。他にも、セールスがお客様からもらった問い合わせをディレクターやエンジニアに一目でわかるように共有できる仕組みも作れました。 お客様からの問い合わせは [営業関連] [問い合わせ] [不具合処理] [解約] の4種類に分けられ、以前のメールやスプレッドシートで管理していたときは簡単なテンプレートを使用して効率化を図っていましたが、ディレクターからセールスに「こういう情報も欲しい」という追加の情報請求が頻繁に起きていました。
Backlog導入後、問い合わせの情報管理はどのように効率化されましたか?
Backlogの「種別」を活用することで、問い合わせの種類にあわせた定型文が使用でき、誰が読んでもタスクの内容を理解できるようになりました。 加えて、他の情報と共にメールの本文もBacklogに転載してもらうなど、運用を工夫することで、メールの転送などに頼っていた場合に比べて、体感としては負荷は半減しているのに加え、異動などで社内の担当者が変わった場合も過去の経緯を把握しやすくなりました。
情報の一元管理・ガントチャート機能により見積もりの精度が向上。休止していた新規案件が再開できるように
Backlogを導入して予想外の効果はありましたか?
Backlogのガントチャートを見積もりで活用するようになったことで、それまで引き受けが難しかったタイプの案件も受け付けられる仕組みが整いました。 一例に、CMSのデザインカスタマイズの案件があります。お客様からたびたびカスタマイズのご要望をいただいていたのですが、デザインの提案から実装までの進行管理の際に、社内だけでなくパートナー会社とのやり取りも含めて考える必要があり、その情報整理の仕組みが準備できていなかった、という課題がありました。そのため同時並行で複数の案件を進行する場合の難易度が高く、案件の受注を控えていた時期があったのです。 しかし、Backlogでデザインの提案から実装までざっくりのスケジュールをガントチャートで簡単に自動生成できるようになり、期日を可視化できるようになりました。
今後Backlogを活用していきたい!という展望はありますでしょうか?
はてなブログMediaチームでは、Backlogを導入したことで、お客様からの問い合わせをしっかりと管理できるようになりました。今後はお客様からの要望をもとにしたプロダクト改善のためのロードマップ作りなど、プロダクト開発でもBacklogを活用していきたいです。