サイバーエージェントは、自律的な組織づくりと Asana の導入でアメブロの進化を促進

株式会社サイバーエージェント プロダクトマネージャー 樋口 一裕 氏

サイバーエージェントは、1998年に設立されたインターネット企業で、連結社員数は5,000人近くにのぼります(2019年3月現在）。私が属するメディア管轄の「Ameba」は、350名ほどのメンバーで運営しており、そのうち、国内最大規模のブログサービス「アメブロ」は80名ほどのチームです。私はそこでプロダクトマネージャーを努めています。

イノベーションを起こせる仕組み作りは必須

アメブロは、今年で15年目になり、利用者は月間2,500万人に達し多くの人に愛され使われています。また同時に、長い歴史がある故に、サービスの仕組みやシステムが大規模でレガシーになってしまっている側面もあります。これは Ameba の課題の一つで、メンテナンスとアップデートを並行して進め、少しずつサービスを新しいものに差し替えていく必要があります。ブログという形には固執しすぎずに、イノベーションを起こす必要があるのです。しかし、新しいものを生み出そうとする意欲を、自然発生的に起こすのは簡単ではありません。だからこそ、イノベーションを起こせる仕組み作りは必須です。

そこで、半年前、アメーバブログのプロダクト開発部のプロダクトマネージャーになった際に、まずはプロダクト開発部の組織変更をしました。その際に、組織をサポートするツールとして、Asana を本格導入しました。

プロダクトマネージャー を新設、サービスの変化を生み出せる組織へ

当時、アメブロにはプロダクトマネージャーは不在で、事業責任者がプロダクトに対しても責任を持っていました。結果として、ユーザーが欲しがっている機能の提供や改善、それを実現するための手法の採用などが取り入れられてなかったように感じました。 そこで、新たにプロダクトマネージャーをおいて、ユーザーの行動の変化を捉えて次の施策につなげられるアクショナブルな指標である KPI をもたせました。売上などの結果指標である KGIを見ている事業責任者との役割分担を明確にし、チーム内でフラットにおき、ユーザーの行動やサービス自体の変化を生み出せるように組織を変更しました。

チームの自律性をサポートする Asana

また全体を、一つのことにフォーカスした目標を持った 6〜10名程度のいくつかのスモールチームにわけました。チームによって参加する職種は異なりますが、プロダクトマネージャー、事業責任者、エンジニア、デザイナー数名で構成されています。各チームが裁量をもち、自由に進められる環境を目指しました。これを機能させる為にも、明確な役割分担は必須です。あとは各チームが責任を持って自由にアクションを推し進め目標であるKPIやKGI を達成すればいいようにしました。私ともう一名、事業責任者がフラットな位置関係で、各チームの成果を最大化できるように取りまとめています このようなチームに自律性を与える組織のコンセプトにも Asana は合っていました。またエンジニアと非エンジニアが一緒にチームを作っているため、誰でも分かりやすい UI であることも重要でした。

もともと、私が Asana を使い始めたのは、この直前の新規事業だった「REQU」を担当している時でした。当時は、別のプロジェクト管理ツールを導入していましたが、複雑だったり機能が多くて分かりづらいなど課題がありました。例えば、ワークフローの整備です。かんばん方式でやるにしても、ワークフローが動かしづらかったのです。またツールの使い方を変えたいと思っても、契約自体を変更する必要がある場合もあり、チームだけでコントロールしきれない問題が発生していました。そこで、Asana を試してみました

そして、Asana は

• かんばん式でもリスト式 でも、どちらも簡単に選択できる

• UI/UX が考え抜かれている

• 非エンジニアにもストレスなく使えるように設計されている

• 機能が多すぎて分からなくなる問題も Asana なら解決できる

と感じ、使い始めることにしました。もちろん、Facebook のエンジニアが開発したツールということも知っていて、そうであれば開発には使い勝手が良いはずだと感じたのも事実です。

バックログ管理は自由にリストアップ、実施するものをかんばんボードへ移動

今の部署での Asana の使い方はさまざまですが、代表的な例を挙げると CRE (Customer Reliability Engineering) チームのバックログ管理があります。お客様の満足度をどのように向上していくかがこのチームの目標で、KPIは、例えば、お客様の課題を解決するアイデアを今期で5つ以上達成するなどです。

バックログ管理は、全てオープンにリストアップして、スプリントでやるものだけをかんばんに持っていく管理方法を取っています。誰でもリスト式の Asana 上のプロジェクトである「バックログ」に案を入れることができます。カスタマーサクセス（CS）からきたユーザーの要望だったり、または自分たちで気付いた点などを入れていきます。そして「バックログ」の中から、実施すると決めたものをかんばん式の Asana 上のプロジェクトである「スプリントボード」へ移動させます。これをチームでトリアージ（優先順位付け）して各週の方針を決めていきます。

チーム編成と Asana で、バグや改善案に漏れ無く対応するプロセスを構築

以前は、プロダクトチームとカスタマーサクセスの連携は理想的な状態とは言えませんでした。カスタマーサクセスから上がってきたバグや機能改善案が放置される場合もありました。お客様への返答が放置されることはありませんが、きちんと調査した後の抜本的な解決方法ではないため、バグとしては残る場合がありました。バグや改善案に漏れ無く対応する体制とプロセスがありませんでした。

そこで、新しく CRE チームを作り、カスタマーサクセスとエンジニアが同じチームで一気通貫でやれるようにしました。さらに、見落としがないプロセスも Asana と共に新たに構築しました。バグの対応要否は、必ず毎日の打ち合わせで調査してチーム全員が Asana を見ながらトリアージを実施しています。Asana 画面で、リストをトリアージの前と後に分け一目瞭然にし、対応漏れを防いでいます。ビジュアル的にも理解しやすい管理が Asana で可能になりました。そして、対応すると決めたものは、担当者をアサインして期日を設定し管理してます。

このように Asana は、CRE チームの課題解決やチーム内のプロセスにおいて、無くてはならないツールです。 ”

Asana 以前のバグ管理は、Slack に上がったものなどを Google スプレッドシートに書き出してやり取りをしていました。レビューも毎日ではなく週単位で、一時間ほど実施していました。これをバグ調査も含めて毎日30分に変えることで、バグも溜まることがなくなり、放置も起こらなくなりました。

また、社内ツールの役割も明確にしました。Slack はコミュニケーション、Asana はタスク・プロジェクト管理、Github はソースコード周りです。小さな issue の場合は Asana にあげずに Github で完結させる場合もあります。esa というドキュメント管理に、Goodle Docs や Slide、そしてレポート系は Tableau や Google Data Studio を使っています。組織編成をして役割を明確にすると同時に、使うツールの目的や役割も整理しました。

この半年は、組織のデザインに時間を使ってきましたが、そこには Asana があり、組織が上手く機能するためのライフラインになってくれています。

この試みはこれからも続きます。様々な最新の組織デザインを学びつつ、今後も自分の組織をアップデートしていきたいです。 私の今の目標は、世の中が速いサイクルで進んでいく中、Amaba も同じ速度で進化し変わり続けることです。Ameba をより多くのユーザーにお使いいただき愛していただけるように、しっかり進化し続けていきます。

2019年3月