プロダクト開発チームで今年やってみてよかったこと10選

この記事はCrowdWorks Advent Calendar 2017の最終日の記事です。

メリークリスマス！

去年のアドベントカレンダーで、非エンジニア副社長がゼロから歩む テクノロジー企業経営への道という記事を書かせてもらいました。

「もうそれから1年かー！」という感じですが、今年は、この1年でうちがやってみたことで、効果があって組織が成長したなーと自分が感じたことを10個紹介してみたいと思います。

#①考えると人と作る人を分けずにフラットな組織にした

###やったこと：

• プロダクトオーナー制度を取り、プロダクトオーナーとエンジニアとデザイナーがOne Teamになり、開発を行う
• そのチームで日次週次でプランニングと振り返り(KPT)を行い、日々改善する
• そのチーム内の関係性を「フラット」にする
• マネジメント(評価とか)はチーム開発とは基本的に分ける

###よかったこと：

• 「は？いつまでにやるって言ったよね？(対立)」「〇〇日までにやってもらえますか？(お願い)」みたいなあるあるの不毛な議論をなくせる
• よくある企画→エンジニアの上下関係性がなくなり、エンジニアもデザイナーもプロダクトをよくすること＝ユーザー価値を向上することにコミットできる
• 実装上の課題があってもすぐ気づいて、やり方をすぐに変えられる

###ひとこと：
突発的な話や、会社としてどうしてもやらないといけない時はあるものの、日々のプロダクト開発でチーム性を導入し考える人と作る人を分けない組織は、ユーザーへの当事者意識が高まったり開発のスタックに対してすぐに対応できたり、良いことだらけだなーと思います。

#②自由度、自律性の高い組織を作り、変化を推奨した

###やったこと：

• 大きな方針だけ決めて、あとはチームでKPIや施策を設定する
• 施策の承認を事業責任者に取らなくてどんどんリリースしてよいものとする
• 組織ややり方ををあえて毎Q(場合によっては毎月毎週)変化させることをよしとする

###よかったこと：

• 自分達でプロジェクトの回し方を考えて、新しい取り組みをやるようになる(この記事で紹介されてる「ペアプロ」「モブプロ」みたいなのも一例)
• チームの責任が大きくなるので、結果を出すためには皆でよりユーザーのことを考えざるを得なくなる
• ある特定領域の開発やプロジェクトが1人に依存しなくなる
• 自分が想定してるよりプロダクトを改善するための有効なKPIが出てきたりするw

###ひとこと：
大体自分が想定してるものは、経営に紐づいた大きな枠組みのことが多いですが、実際のユーザーを見ている中でこうしたほうがいいのでは？というアイデアは日々出てくるものです。それを一旦責任者の理解するのを待っていることすら、時間の無駄になりかねず、その分ユーザーに価値を届ける時間が遅くなります。もちろん自分が絶対に正しいと思う場合はチームにもコミュニケーションをしますが、それ以上に、チームの自由度を高めて変化を推奨することで得られた果実は多かったと思ってます。(実際それで追うべきKPIが変わることもありました)

↑チームで考案して実行されたモブプロの様子

#③KGI/KPIの意図を全体で理解する取り組みを入れた

###やったこと：

• KGI/KPIの意図を細かく「因数分解」してチームに共有した
• その数字を毎日全員に共有するようにして、チーム朝会で見てもらうようにした
• 1人が全体に説明するのではなく、各チームの責任者がラウンドテーブルで各テーブル(5,6名)を回ってひとつひとつ説明するようにした
• キックオフで、分解が理解できてるかテストをだしてみたw

###よかったこと：

• KGI/KPIが単なる数字ではなく文脈として理解できるようになった
• 少なくとも数字を見る習慣が全体で着いた
• 各チームの責任者が伝えようとするためにやりたいことがよりシャープになった
• 各チームのやりたいこと、やってることがより伝わるようになった

###ひとこと：
KGI/KPIって、規模が大きくなってくればくるほど全体観がわからなくなったり、特に最後のKGIが他人事(経営が言ってることでしょ？)となりやすい気がします。それを少しでも理解してもらうには、ドリルダウンして因数分解することと、それを少数単位で説明する機会を持つことって重要だなと思いました。全社を一体化させるのも、やっぱり「仕掛け」「仕組み」が必要だなーと感じるこの頃です。

↑実際のキックオフで責任者が他チームに方針を説明する様子

#④「アソシエイト プロダクトオーナー(APO)」という職種を作って育成体制を作った

###やったこと：

• 非エンジニアでプロダクトオーナーを目指したい人を「アソシエイトプロダクトオーナー(APO)」と命名して育成枠を作った
• APOは全員TechCampとかTechアカデミーみたいなプログラム学習教室で1~2か月受講してもらい、基礎を学んでもらった
• エンジニア兼プロダクトオーナーの育成担当がついてデータ抽出・分析や要件定義など、半年1年かけて伴走してみた

###よかったこと：

• プロダクトオーナーへのキャリアの道筋が育成体制含めて少しずつできてきた
• 非エンジニアがエンジニアリングやデザインを学ぶ文化ができ、クリエイターへのリスペクトが高まった
• 実際にAPOからプロダクトオーナー(PO)になった人が出た

###ひとこと：
クラウドワークスに限らずプロダクトオーナーとかプロダクトマネージャーを目指す人は多いとは思うのですが、なかなか歴史の浅い職種でもありキャリアの道筋がなかったりすると思います。また、企画は企画、エンジニアはエンジニア、と日本だとなりがちななので、その分断も課題という会社もあると思います。そういう意味ではアソシエイトプロダクトオーナーという職種を作って育成体制を作ったのは意義があったなーと感じます。

#⑤非エンジニアもSQLを覚えたりウェブアプリケーションの最低限の仕組みを学んでみた

###やったこと：

• ユーザーサポートやマーケのメンバーもSQLを覚えた
• セールスチームでリスト作成したいときも簡単なスクレイピングは運用メンバーがやるようになった
• セールスやユーサポの管理表もGoogle App Scriptとかで作るようになった

###よかったこと：

• エンジニアが本来やるべきエンジニアリングに集中できるようになった
• チームでの分析のスピードがあがった
• プロダクトオーナー、デザイナーとエンジニアのコミュニケーションコストが下がった

###ひとこと：
やっぱり基本的な共通言語を持てていると、できることが広がってスピードが上がるのがいいなと思います。それぞれのやるべきことをやる、「自分ができることはできる限り自分でやる」っていう風土ができてくると、一人ひとりの学習意欲も高まって成長余地が生まれるなーと感じています。

#⑥ユーザーサポートやセールスやマーケティングとエンジニアを一体化した

###やったこと：

• ユーザーサポートやセールスチームにエンジニアが入るようにした
• プランニングや開発をそのチームでやってもらうようにした
• どうやったら力技ではなくプロダクトとしてスケールさせられるかを一緒に考えた

###よかったこと：

• 仕組み化すべきところをしっかり仕組み化できた(管理画面化とか)
• ユーザーサポートやマーケティングで開発すべきことが進んだ(あとで説明する機械学習を使った違反案件の撲滅とか、新規ユーザー獲得施策など)
• セールスとプロダクト開発を連動して考えられるようになった(最初人力、からの、プロダクトへの落とし込みをチーム全体で考えるようになった)

###ひとこと：
ユーザーサポートとかって、ともすると下火になりがちですが、クラウドワークスでは超重要視してます。ユーザーの声を一番聞ける場所であることと、そもそもユーザー対応のSL(サービスレベル)が下がるとユーザー満足度が下がってサービス品質が落ちてしまうからです。だからこそエンジニアが一緒になって開発・改善できる体制が重要だと思ってやってみました。また、セールスとかも、ともすると力技で色々解決しがち。でも最終的にスケールさせるにはプロダクトに落とし込む力が重要だと思っていて、それを少しでも前進させられるような組織体制にしたいと思って、混合チームを作ってみました。これもよかったです。

↑ユーサポとエンジニアのチーム。グッドコンビネーションです。

#⑦技術戦略を明確にし、プロダクトの価値向上に活かした＆中長期の開発力向上に向けてトライした


技術戦略はCTOの弓山(通称 ゆみー)のブログでも書かせてもらいましたが、この1年で色々進みました。

###やったこと：

• AI(あえて機械学習ではなく人工知能)、DDD(ドメイン駆動設計)、SRE(Site Reliability Engineering)を技術戦略として明確にした
• 機械学習はすぐに成果に出なくていいと割り切り、色々トライする時間を作った
• 結果として、機械学習を使ってサイトに掲載される違反案件の多くを自動抽出、停止することに成功した(記事はこちらです)
• それらを論文にまとめ、学会でも発表した
• ドメイン駆動設計に挑戦しようと決め、開発言語としてScalaを採用し、実際に実装を進めた
• SREチームが発足。バッチサーバーの再構築やマイクロサービス基盤となるAPI認証の第一弾をリリースした

###よかったこと：

• テクノロジーへの投資とプロダクトの本質的な改善を紐づけることができた
• エンジニア一人ひとりの技術力向上とプロダクトの価値向上を紐づけることができた
• 短期的な改善を確固たるものとしながら中長期のプラットフォーム戦略に活きる投資をスタートできた

###ひとこと：
去年のアドベントカレンダーでも、「技術戦略は経営戦略」とも書かせてもらいましたが、広義の人工知能を会社の方針として位置付け、IRもさせてもらっている中で、プロダクトに少なからず実装でき、ユーザー価値向上につなげることができたのは本当に良かったと思っています。ひとえにメンバーの力のおかげなのですが、こういった技術戦略とプロダクト戦略の連動の一手を作れたのはこの1年の収穫なので、来年はもう一段二段進めていきたいと思っています。

#⑧デザイン戦略を作り、ユーザーエクスペリエンス向上につなげるプロセスを構築した

###やったこと：

• UXデザイングループを作って、プロダクト横断のデザイン組織を作った
• 「人間中心設計」をコンセプトに、デザインガイドライン策定など組織全体のデザイン力を高めるプロジェクトを進めた
• UXデザイナーという職種を作り、ユーザーインタビュー、ペルソナ定義、カスタマージャーニーマップの策定をプロダクト開発の重要プロセスに組み込んだ

###よかったこと：

• 「UXデザイン」をより体系化することで、開発プロセスの中にユーザーの声を本質的に組み込むことができた
• プロダクト開発におけるデザインの位置づけを明確にできた
• ユーザーの声をそのまま取り入れるのだけでなく、ユーザーの声を聞き、インサイトに変え、それを基に本当の課題解決を行う素地ができた

###ひとこと：
デザイン＝ビジュアルデザイン、UIみたいな局所的な話ではなく、UX全体にデザイナーがかかわることを「新しい当たり前」にできたのは大きな一歩でした。特にユーザーの声を聞き、その裏側にあるインサイトを読み、ユーザーが本当に欲しいものを代わりに発明するというプロセスの第一歩に立てたのはプロダクト開発における重要なポイントだなと感じています。

#⑨デザインと開発を一体化させ、UXのコンセプトを開発初期段階から組み入れた

###やったこと：

• 開発チームにエンジニアだけでなくデザイナーが必ず入る
• ユーザーインタビューをデザイナーが設計し、エンジニアも参加する
• 開発する前にペルソナ策定やカスタマージャーニーマップ定義を構築し、チーム全体で共有・議論し、決める
• 開発しながら常にその原点に立ち返る

###よかったこと：

• 全員でターゲットユーザーとそのカスタマージャーニーを意識できるので、ゴールについてのコミュニケーションコストが下がる
• どう開発するかで迷った時も羅針盤となり、スピードが落ちない
• エンジニアもデザイナーもプロダクトオーナーはゴールは「ユーザーに価値を届けることである」という前提に立てる
• 実際にそれでユーザー行動の最終成果であるKPIも改善した

###ひとこと：
デザイナーというと、作るものが確定した段階でビジュアルを整える人として入ることも多いですが、クラウドワークスではユーザー体験の根幹を作る人としてチームをリードし、プロダクトオーナーやエンジニアとコミュニケーションを取っていきます。それはそもそもUXデザイングループがユーザーインタビューやカスタマージャーニーマップ策定やデザインガイドラインという根幹を作ってきたことが大きいのですが、その価値をエンジニアも感じられるレベルになってきて、実際に数字も上がってきているので、とてもよい動きでこれからも伸ばしていきたいと思ってます。

↑プロダクトオーナーとエンジニアとデザイナーが共通のカスタマージャーニーマップを見て議論している様子

#⑩経営者も組織も新しいことを学習する習慣を作った

###やったこと：

• プロダクトマネジメントやスクラム勉強会など参加を推奨して必要に応じて予算をとった
• デザイナーがRuby on Railsプログラミング、フロンドエンドエンジニアリングの講座に行くようになった
• 自分自身も投資してRailsでのアプリケーション開発やってみた、自然言語処理や機械学習、深層学習の基礎講座に参加した(WebCampにいったり、アイデミーという機械学習の学習サイトで家庭教師をやってみたり、友人の企業の社長にお願いして深層学習の社内勉強会に参加させてもらいました)

###よかったこと：

• 組織全体で新しいことをやろう、学ぼう、成長しようという意欲が高まった
• それぞれの「できること」が広がり「やりたいこと」に費やせる時間が増えるようになった
• 新しいことを勉強すると自分自身の非力さも理解でき、チームへのリスペクトと期待がさらに増す
• 新しい技術でできることとできないことの区別が少なからずつくようになり、次の技術戦略に活かしせるようになる

###ひとこと：
エンジニアリングはエンジニアリングのプロがやるのが効果的ではあるものの、それ以外の業務をしっかり区別することは重要で、それぞれの領域に少しずつ職種を超えて浸食していくことで共有知が増え、無駄なコミュニケーションコストはなくなります。また、たまにありがちな「ディープラーニングが話題らしい！うちもディープラーニングだ！」みたいな話はかなり減るかなとは思いますw

↑は引用画像です。引用先はこちらです。

・・・・
こう見ると色々変化してきたなーと思うのですが、自分が何よりよかったと思っているのは、これらのことは自分が「こうやろう！」と言ってスタートしてるわけではないんです。

チームの意見を聞いて、各マネージャーやプロダクトオーナーと話していく中で、やるべきだと思うことを取捨選択していったらこうなった、あるいは、場合によっては勝手にことが進んで、勝手に成長してたこともたくさんありますw(実はそっちの方が多かったりするのは内緒です)

もちろん、会社全体の戦略を意思決定すること、大きな方針を伝えることは、必須だし、やる必要があると思います。ただ、その中でどれだけチームが考えられる組織を作ろうと思ってやってきたことで、チームからいいアイデアが出てきたということかなと思ってます。そして、いいアイデアに対してはそのアイデアが結果を出せるように支援することが大事だと自分は考えてます。それをやったことで、少しずつチームが変化して、新しい取り組みが出てきて、次のステージに上がってきた。これをどこまで維持して、大胆な発展につなげられるかが、これからのポイントです。

来年は技術戦略をより尖らせて、特に機械学習周りでレコメンドエンジン開発、仕事投稿の自動化、仕事内容に応じた最適な単価提示など、どんどん次のレベルに飛躍させていきたいです。また、ドメイン駆動設計もマイクロサービスも始まったばかりで、ドメイン駆動設計で開発された機能の本リリースは来年になります。これを継続して組織的な開発力向上につなげていきたいと思います(30名が100名になっても開発スピードを上げられるようにしたいです)。来年はCDN化にもトライしたいという方針もできてきてますし、セキュリティ周りの強化も進めていく予定です。楽しみです。

また、デザインの基礎は出てきたので、それをプロダクトに反映させて、クラウドワークスの体験が変わったな～と言えるレベルのプロダクトを出したいと思います。今年はデザイナー対エンジニアが1対7~8くらいの比率でしたが、来年は理想と言われる1対4程度になる予定で、着々と準備は進んでいます。チームも増強してプロダクトを変えていくので、自分も楽しみです。

また、いいことばかり書きましたが、実際にはマネジメントでミスもあったり、まだ各チーム変化しただけで成果にはつながってなかったり、機械学習も最初は失敗の連続だったり(実は今もw)、今回のアドベントカレンダーでも一部書かせてもらいましたが過去の技術的負債やレガシーUIで苦しんでいたり、もちろん色々課題だらけです。そこらへんの観点も機会を見てまとめてみたいと思います。が、何より、前進してることが重要！w と思いますので、参考になればと思い書かせてもらいました～

今年はこんなところで以上となります。来年もまた色んな仕掛けをやっていきます。まだまだ日本を代表するテック企業には道半ばですが、地道にチャレンジを続けてどんどん進化していきたいと思います。

今年もアドベントカレンダーを読んでいただいてありがとうございました～！良いお年を～！