はじめに
この記事は CrowdWorks Advent Calendar 2016 25日目の記事です。
クラウドワークス副社長をやっております、成田と申します。アドベントカレンダーのトリということでプレッシャーがすごいです。
私の役割ですが、創業当初はサービスUX改善やWebマーケティング・ビズデブ全体の責任者をやっていて、その後法人セールス部門の立ち上げをやり、現在は副社長 兼 プロダクトマネージャー（PM） 兼 プラットフォーム事業部の事業部長という立ち位置です。PMの周りに4人の優秀なプロダクトオーナー（うち3人がエンジニアバックグラウンド）がいます。
当社は**「働くを通して人々に笑顔を」というミッションに基づき、素晴らしいサービスを生み出し、冒頭の写真のようにユーザーの皆さんに笑顔を届けることを追求していますが、その素晴らしいサービスを生み出す企業文化として「日本を代表するテクノロジー企業を作る」**ことを目指しています。
そこで今回は、非エンジニアとしてここまでやってきた副社長が、テクノロジー企業を作り上げる過程で感じていること、学んできたこと、実際にやってること、その想いと苦悩と希望をまとめてみたいと思っています。
前提：今はプロダクトの時代
よく言われることですが、現代は**「プロダクトの時代」**です。
顧客の情報取得や口コミスピードが飛躍的に上がったため、プロダクトの成否が事業の成否に直結する。つまりプロダクト戦略≒経営戦略ということで、Google、Facebook、Tesla、LINE・・・・あらゆる企業がプロダクトを起点に経営しており、PMは”mini-CEO”と言われるほど、プロダクトの重要性が高まっています。
AmazonのCEOであるジェフ・ベゾスはこの経営環境の変化をこう表現しています。
「古い世界では持てる時間の30％を優れたプロダクトの開発に、70％をそれがどれほど素晴らしいプロダクトか吹聴して回るのに充てていた。それが新たな世界では逆転した」
そしてプロダクトのコア基盤はいうまでもなくエンジニアリングであり、テクノロジーです。
求められるのは、プロダクトドリブン/テクノロジードリブンな組織
プロダクトの根幹がエンジニアリングでありテクノロジーであることを考えると、エンジニアリングパワーが最大限発揮される組織を作ることが近代経営の成功への近道だということになります。
つまり経営は、エンジニアリングの力が最大限に解放されるような事業ビジョンと組織ビジョンとその実現に向けた環境作りをしていく必要があるということです。
プロダクト開発の阻害要因は何か
ではプロダクト開発を加速させるために何をすべきか。私は「阻害要因を取り除くというアプローチ」を採っています。プロダクト開発の阻害要素とは何でしょうか？ここでは以下の4つを挙げたいと思います。
（１）スピードの阻害：「偉い人」の承認がないと前に進めない文化
（２）自由度の阻害：細かい報告や管理文化
（３）自律性の阻害：企画とエンジニアの分離による、「やらされ」文化
（４）柔軟性の阻害：決めた目標に縛られる文化
当社ではこれらの阻害要因にアンチテーゼを提起して、マネジメントを行います。
プロダクト開発の阻害要因に対するアンチテーゼ
（１）「偉い人」の承認を取らない
まず許可や承認を不要にします。「プロダクトオーナー判断」「エンジニア判断」で、相談が必要な場合は相談してもらうことにします。お金が大きくかかるもの以外は承認を不要にしてスピードを上げます。
当社の組織では「許可を求めるな、謝罪せよ」でいこうという話をよくしますが、これは本質を見事に表現している言葉だと思います。
インターネットのサービスは基本的にデータドリブンであり、ユーザーのフィードバックが極めて速い。そのフィードバックを最も早く感知できるのは実際に開発してるエンジニアなはずで、その「現場」にいる人材が現場の声をベースに最速で動ける環境を作ります。
（２）細かな報告なし、TODO管理なし
先ほど言ったように開発チームが自律的に動くことが重要なので、管理することは重要ではありません。むしろ自由度を持たせるように動きます。
当社では「偉い人」が勇気をもって管理を放棄し、自律的に動く組織に舵を取ることを目指します。
ただし、細かく管理しないかわりに、野心的な目標を掲げるようにし、その達成に全力を注ぐことを前提とします。時にハードワークも惜しまず全力を注げるチーム作りは重要です。
（３）企画とエンジニアを分離しない・納得しないことをしない
少々波紋を呼びそうな話ですが、言いたいことは、自律的にチームが回ることを目指すなら、自分達で決めたことを責任をもってやるのが一番、ということです。
企画者とエンジニアが分かれる弊害の本質はここで、企画者とエンジニアが分離されていくと、「言われたことをやる」組織になり、思考停止になりがちで、ユーザーに対する機敏性が失われます。
ソフトウェアもプラットフォームサービスも複雑であり、現代では顧客のフィードバックは極めて早い。だからこそ、自分達でユーザーのフィードバックを聞いて、スピードをもって改善することが求められます。自分達で作り、自分達でどんどん学習して改善していく環境を作るのです。
（４）決めた約束に縛られない、学習と変化にフォーカスする
一般的には「決めたことはやり切る」のが常識ですが、プロダクト開発組織において大事なことは「柔軟な変化」です。
変化を起こす機能、これを当社では**「チェンジ・エージェント」**と呼び、マネジメントの重要要諦としています。
プロダクト開発では、状況は時に異常な速度で変化します。その変化に対応せずに「決まったことだから」ということで変化できない組織は愚かです。
OKR（目標）も、方法論も、もちろん施策も、全部変えていい。変えることを恐れるどころか、むしろ推奨していきます。「決めたことをやり切る」ことではなく、データとユーザーニーズに合わせて自分達を変化させること。**”Learn as fast as possible”**が重要だと考えます。
「プロダクトは戦略に従う」
これまでは組織マネジメントについて話をしてきました。いい組織はいいプロセスを生み出し、いい結果を生み出す可能性を高めます。
ただ組織がどんなによくとも、サービスが成長しなければ意味がありません。プロダクト開発組織のメンバーが幸せになれるかどうかは結局はそのプロダクトが伸びるかにかかってるわけです。
このプロダクトの成長の根幹は、事業ビジョンとプロダクト戦略です。これはあらゆる事業の前提です。
このビジョンと戦略設計がズレたら皆が不幸になるため、経営・PMとしてまずやらなければならないこと（かつ、超難しいこと）はこの意思決定になります。
その戦略が前提にあって、徹底的にチームが自律的に動いて野心的な目標を達成できるように設計すること、その環境を作り、ドライブすることがマネジメントの役割だと思います。
テクノロジー企業に向けた考察
ここまで、マネジメントとプロダクト戦略の話をしました。
ここから最後にかけて、プロダクト開発やテクノロジー企業経営において、自分がぶち当たり、考えてきた論点や疑問、考察について、考えを列挙してみたいと思います。お付き合いくださいw
考察① エンジニアリング組織は「エンジニアに迎合している」のか
エンジニアリング組織を作るのだ！と発信すると、まだまだ、たまにこういう話になることがありそうです。特にエンジニアリングの理解が進んでいない組織から見ると、エンジニアリングが大事だ、といっても、批判的な意見が出るかもしれません。
ただ、この質問に対する答えは、結論、もちろんNoです。
全ての会社組織は何のためにあるか。成果のためです。成果というのはプロダクトの中長期的な成長であり、事業の成長であり、その成果を出すために、エンジニアリングを加速させ、エンジニアが最も力を発揮できる環境を作る必要がある、という話に過ぎません。決して迎合ではありません。
考察② エンジニアはビジネスがわからない（数字にコミットしない）のか
さらなる意見として、エンジニアリングドリブンと話すと、「エンジニアはビジネスがわからない」とか「エンジニアは数字にコミットしない(できない)のでは」という意見もありそうです。
でも結論、そんなことはないと思っています。誰だって自分達で作ったサービスが伸びれば嬉しいわけですから、まず「そんなことはない」という前提に立つことが大事ではないでしょうか。
ただ、エンジニアの中には、「どう見ればいいのか知らない・わからない」ことがあるかもしれません。そして非エンジニアであっても、数字に徹底的にコミットできるわけでもありません。そもそも業績に徹底的にコミットしてビジネスを成功させる能力はエンジニア・非エンジニアの区分とは別次元のものです。
となると、経営としてやるべきことは、エンジニアにおける「やらされ文化」を排除し、コアとなるKPIを戦略的に作り、皆でデータを共有し、どう見ればいいのか、そのデータを基にどう行動すべきか学習できる環境を作ることであり、エンジニアかどうかはあまり関係がありません。
考察③ では逆に非エンジニアはエンジニアリングを学んでいるのか
エンジニアからたまにこんな言葉を耳にします。
「ビジネスサイドはエンジニアにビジネスを理解しろと言うが、エンジニアはビジネスサイドにエンジニアを理解しろと言えない」
確かに従来型の日本企業だと、ビジネスサイドの人材の声が大きくなりがちかもしれません。そして確かに、非エンジニアの中には、SQLも学ばない、コーディングも学ばない、アーキテクチャ設計についても学ばないケースが多いのではないでしょうか。機械学習が重要だ、と言っても線形代数すら勉強していない方もいらっしゃるかもしれません。これではエンジニア・非エンジニアの間に不本意な「分離」が起きてもおかしくありません。
と考えると、経営としてやるべきは、「非エンジニアはエンジニアリングを学べる」「エンジニアもビジネスを学べる」環境を作ることです。その歩み寄りがリスペクトと理解を深めていきます。
クラウドワークスでは、私自身ももちろん学ぶ必要があるのでお金と時間をかけて学ぶし、若手にはお金をかけてエンジニアリングの研修の場を設けます。一方でデータの見方やビジネスについても学びます。お互いの専門性を高め、歩み寄る企業努力が力強い組織を作り出すのではないでしょうか。
考察④ エンジニアPMか、非エンジニアPMか、という二項対立
これもよく比較されますが、もちろんそれぞれよい面と悪い面があります。正直「サービスを伸ばせるならどちらでもいい」というのが私の結論です。
エンジニアPMは仕様の落としどころを見つけたり、自分でデータ分析をゴリゴリ進められたり、実装を考慮したチームコミュニケーションが得意で、一方非エンジニアPMはマーケット感覚があったり、UXや数字への意識が高いことが多いです。
実体験としては、両方の能力をパーフェクトに備えている人はほとんどいません。それぞれ勉強が必要になる。よって組織的には融合していくのがベターじゃないかと思います。いずれにせよ、エンジニアリングとUXとビジネスを学習し、融合させていくことが不可欠です。
考察⑤ 短期的なデリバリーか、中長期の開発効率か、という二項対立
組織が大きくなってくると、この二項対立も大きな問題になると感じます。
当社では今期、CTO主導でコーディングの価値観の転換というものに取り組んでいます。CTOの言葉をそのまま借りますが、「書きやすいコード」から「変更しやすいコード」への転換です。
当社エンジニアリング組織は1年ちょっとで5人→30人超と膨らみ、今後は100人を見据える組織です。とすると自分が書いたものを他の人が読む・書き換える前提でいかに設計するかという観点を経営的に持たないと、中長期の成長を阻害することになりかねません。
実際に当社では過去の設計がボトルネックになって開発速度が格別に落ちる、ということが起きており、それはプロダクトマネジメントの重大な課題です。
一方で、ビジネスを考えると、何とか早く施策をユーザーにデリバリーして、KPIを最速で改善しなければならないことは言うまでもありません。
よって、短期的なデリバリーと中長期の開発効率のトレードオフを嘆くのはナンセンスで、2つの視点を共存させながら歯を食いしばって前に進む開発組織が理想的だと考えます。時に建設的コンフリクトを生みながらバランスを取るのも経営とPMの役割であり、経営の役割。求められるものは幅広く、時に憂鬱です。
考察⑥ 技術戦略はプロダクト戦略であり、経営戦略でもある
プロダクトマネジメントと技術投資も厄介な課題です。
今期当社では、中長期の技術投資として2つの挑戦をしています。
1つはサービス分割（マイクロサービスアーキテクチャへの入り口）。1つは機械学習や自然言語処理などのコア技術の研究開発投資の加速です。
最近感じているのは、これらの技術戦略・技術投資は中長期の開発効率の飛躍的向上を実現するだけでなく、プロダクトに劇的なイノベーションをもたらす可能性を持っていることです。
例えばAmazonでは音声認識技術や動画データ処理、機械学習等々への投資を次々実行し、Amazon Echo、Amazon Polly、Amazon Goなど次々に生み出しミッションの実現に邁進していて、その姿は芸術的ですらあります。
世界レベルで見ればそういう企業がたくさん出てきている中で、いかに技術戦略とプロダクト戦略を紐づけるかは重大な経営課題です。本田宗一郎の言葉を借りれば「哲学なき技術は凶器」にすらなるし、技術戦略なきプロダクトマネジメントも時に浅い議論に終始してしまうからです。
当社の挑戦であるサービス分割やコア技術の研究開発にしても、プロダクトの中長期的発展や、当社のビジョンである働き方革命につながるように、どういうマイルストーンを引いていくかという勘所は極めて重要です。
当社開発部門の責任者の言葉を借りれば、**「技術戦略は経営そのもの」**であり、経営戦略はプロダクト戦略でもあり、技術戦略でもあると考えます。
最後に：経営者自身の成長と挑戦
いよいよ最後に近づいてきました（長くてすみません）。
正直ベースでお話すると、ここまで書いてきたことは自分の専門外の話も多く、一個一個学び、議論して、考えを現在進行形で洗練させているものです。
最近思うのは、その時々に完璧な人はいないわけで、だからこそ「会社」でやる意味があるということ。
そして最も重要なことは**「経営者自身が学習し、成長し、挑戦を繰り返すことだ」**という考えも日に日に高まっています。
FacebookのCEOマーク・ザッカーバーグは、1年の始まりにその年の目標を掲げますが、2016年の目標は、「家庭用の人工知能アシスタントを開発すること」でした。
2016年12月になった今、実際に彼はそれを現実のものとして世に出しました。その行動力と実現する力には感嘆せざるを得ませんが、ここに重要なインサイトがあります。
経営者自身が、世の中がどういう方向に向かうのかを先んじて描き、自社のミッションやビジョンと紐づけて学習し、努力をすること。これこそが彼から学ぶべき重大なるインサイトだと思います。そのひたむきな姿は尊敬にも値するし大いに勉強にもなります。
私も最近は一歩でも優れたエンジニアの考えや世の中の変化を肌身で実感するため、努力を重ねています。2017年には自分もコードを書き、機械学習について知見を深めていきたいと考えていますが、経営者自身が、ザッカーバーグのような好奇心と努力をもって自らを高めていく動きというものが必要ではないかという今日この頃です。ゼロから歩む日本を代表するテクノロジー企業への道は、まさに「終わりなき旅」。毎日0.1%でも改善できるよう、努力を続けていきたいと思います。
これで2016年アドベントカレンダーは終了となります。読んでいただきましてありがとうございました！