事業で勝つためのマネジメントとは。エンジニア組織づくりの裏側を一休伊藤氏とスタフェス柄沢氏に聞いてみた
2022年1月27日、ファインディ株式会社が主催するイベント「CTOが語るエンジニア組織づくり最前線vol.3」がオンラインにて開催されました。
ファインディでは、エンジニア組織支援クラウド「Findy Teams」をリリースし、エンジニア組織づくりや生産性の可視化を通じたパフォーマンスの最大化支援に取り組んでいます。
その一環として、本イベントではエンジニア組織が急拡大中の企業でマネジメントの最前線に立つCTOの方をお招きし、パネルディスカッション形式で課題や具体的な取り組みについて語っていただきます。
今回ご登壇いただいたのは、株式会社一休の伊藤直也さんと、スターフェスティバル株式会社の柄沢聡太郎さん。エンジニア組織の構造やその背景、人数規模による苦労や面白さ、2021年の振り返りなどのテーマのほか、参加者からの質問にもお答えいただきました。
目次
登壇者プロフィール
株式会社一休 伊藤 直也[@naoya_ito]
青山学院大学大学院博士課程前期修了後、新卒でニフティ株式会社に入社し、ブログサービス「ココログ」を開発。その後、株式会社はてなの取締役CTOに就き、はてなブックマークの開発などを主導した。フリーランスでの活動などを経て、2016年4月、一休の執行役員CTOに就任。
スターフェスティバル株式会社 柄沢 聡太郎[@sotarok]
中央大学大学院卒業後、ソフトウェアエンジニアとしてグリー株式会社に入社。その後2011年株式会社クロコスを共同創業、2012年にヤフー株式会社へ売却。2015年より株式会社メルカリで執行役員CTO及びVP of Engineeringとして技術領域全般を統括し、エンジニア組織20人規模から数百人規模、そしてプロダクトの急成長に貢献。2020年2月よりスターフェスティバル株式会社に執行役員CTOとして参画、同年9月より取締役就任。
登壇者の自己紹介からスタート。3人の共通点とは…？
佐藤： 本日の「CTOが語るエンジニア組織づくり最前線vol.3」では、一休の伊藤さんとスターフェスティバルの柄沢さんをお迎えしております。よろしくお願いします。
伊藤さん： さっそくチャット欄に、デジタル庁CTOの藤本さんから「めっちゃ楽しみです！」とコメントが（笑）。一応皆さんに説明しておくと、藤本さんは我々3人の元上司です。
佐藤： ちょっと緊張しますけど（笑）、良いイベントにできるよう進行させていただきます。まずはお二人の自己紹介をお願いします。
伊藤さん： 一休でCTOをしております、伊藤です。2016年4月から一休にいるので、6年くらいCTOをやっています。よろしくお願いします。
柄沢さん： 柄沢です。CTOとしては何社か経験しており、直近はスターフェスティバルという会社でCTOをしています。
スターフェスティバルは、「ごちクル」という会議弁当などをデリバリーするプラットホームを展開していて、それに付随するいろいろなビジネスをやっている会社です。2年前くらい前にジョインして、プロダクトを用いてどうやってスケールしていくかという課題に取り組んでいる途中です。よろしくお願いします。
佐藤： 僕からも簡単に自己紹介させていただきます。ファインディでCTOをしている佐藤と申します。僕は2013年に新卒でグリーに入社して、2016年にファインディを立ち上げました。内定者の時に、伊藤さんから「うちしかないでしょ」と言われてグリーに入社しました（笑）。
伊藤さん： まったく覚えてない（笑）。入社した時には、僕はもういなかったですよね。すみません(笑)
佐藤： そうですそうです。「伊藤さんは？」と聞いたら、「もう退職されました」って（笑）。柄沢さんも、いろんなコミットは残ってるけど、姿は見たことがないみたいな。
柄沢さん： 時期は被ってないですよね。
佐藤： 被ってないです。伝説の人みたいな感じだったので、今日は楽しみにしてきました。ということで、さっそくパネルディスカッションに移っていきたいと思います。
15人と60人、それぞれの規模でのエンジニア組織構成は？
佐藤： 現在のエンジニア組織の構成と、どういった背景でその構成にされているのかについてです。柄沢さんからお願いします。
柄沢さん： スタフェスは、今エンジニアが15人くらいなのですが、会社自体はもう13期目と結構長いんですね。CTOも何人か変わってきた中で、自分がジョインしました。
結論から言うと、今はプロジェクト体制をつくっています。いわゆるマトリックス構想の組織です。エンジニアと非エンジニアの職種の人が、それぞれの評価ラインに則った組織に属しているのですが、それとは別で目的に応じたプロジェクトチームを構築しています。
プロジェクトチームにはオーナーがいて、そこにエンジニアやプロダクトマネージャー、直近1年はセールスやオペレーションなど、非開発系職種も含めて1チームになっています。その中で目標や予算、タスクを決めたりしていて、プロダクトが関わっているもので3〜4チーム、関わっていないものも含めると5〜6チームあります。
佐藤： 例えばエンジニアで集まった方が効率が良いとか、そういう話もあったりすると思うのですが、プロジェクト単位のチームをつくられたのは、どんな背景があったのでしょうか？
柄沢さん： もともと会社自体が、プロダクトドリブンというよりは、事業ドリブンで起こっているんですよね。社長が非エンジニアなので、ビジネスをつくるという感じで始まっています。領域も飲食や配送なので、プロダクトをつくってローンチすれば自然と立ち上がっていくという話でもありません。
なので、自分がジョインした当初は、事業部がやるべきことを決めて、当時ウェブ統括と呼ばれていたプロダクト開発の部署が、それを受けてモノをつくるという、悪く言えば社内外注組織のような構造になっていたんですね。
エンジニアからすると、なぜやるのかよくわからないタスクをこなしていく構造になりやすく、開発する中で起きている問題も、やるべきことにフィードバックしづらい。やるべきことを決める人たちと一緒にやらないと、「なぜつくるのか」と「どうやってつくるのか」を合わせて考えられないわけです。
であれば、目的を主軸において、やるべきことを決める人と、どうやるかを決めて実行する人たちを集めた方が、モチベーションも上がるし、クオリティもスピードも上がるだろうと考えました。そういう構造にして2年くらい。徐々に変化していって、うまくまわり始めて1年くらいという感じですかね。
佐藤： 徐々にうまく、プロダクトのことを皆で考えていく組織に変わっていっているのは良いですね。それでは、続いて伊藤さん。現在、一休はどのような組織になっているのでしょうか？
伊藤さん： スタフェスさんと比較すると、一休の方が一回り大きいです。今エンジニアが、デザイナーも含めると60人くらいの組織規模です。開発組織の規模感を仮に15人、50人、次が100人くらいに分類するとすれば、その間の50人くらいの会社ですね。中規模ぐらい、というレベルでしょうか。
その組織内のチーム単位は、スタフェスさんと近く、5〜7人のチームがたくさんあって、基本は1つのチームの中にPMとデザイナーとエンジニアが一緒になっています。「エンジニア組織」や「デザイナー組織」のような機能型の組織ではなくて、職能横断型の組織ですね。一休には、ホテル予約とレストラン予約という2つの大きな事業がありますが、それぞれに同じ考え方のチームが2つずつあります。
チームの切り口については、柄沢さんはプロジェクト単位とおっしゃっていましたが、一休の場合は少し違って、ドメイン領域で区切っています。ホテル予約の事業であれば、ユーザーがホテルを検索して決めるところまでのドメインと、ホテルを決めて予約する以降のドメインに境界が存在していると考えていて、そこでチームを区切っています。
例えば予約以前のチームは、検索であるとか、ホテルのページをいかに魅力的に仕上げるかという、ユーザーエンゲージメント寄りの開発をします。予約以降のチームは、決済や精算といった業務寄りの世界で、ユーザーエンゲージメントというよりは、きちんと業務が運用できることに重きをおいて開発する感じです。レストラン予約事業の方も、同じ構造になっています。
そして、ここからは少し特殊だと思うんですけど、これらのドメインに沿ったチームとは別に、技術的な支援をするチームと、データサイエンスの領域を扱うチームがあります。彼らは、前述のドメインに沿ったチームに対して新しいアーキテクチャや、難易度の高い技術問題の解決･･･例えば画像認識や検索アルゴリズムを提供したりする･･･つまり、プロダクト側のチームの支援を行っています。これらのチームはエンジニアだけで構成されています。
柄沢さん： ドメインに対して、横断的に存在しているイメージですかね。ドメインが縦で、技術支援が横みたいな。
伊藤さん： そうですそうです。
佐藤： そういった横断的な技術支援チームというのは、どういった背景から作られたんですか？
伊藤さん： 自然にそうなっていった、というのが実態としては近いですね。最初はスタフェスさんと一緒で、事業部と開発部という大きな部があって、事業部から開発を依頼される形だったんです。これだとやはり社内なのに受発注関係みたいになっちゃうので、良くないねという話になりました。そこから、デザイナーやPMも一緒の小さなチームにしていって、チームがチーム単独で開発できるようにしたという経緯があります。
一方で、一休は20年以上の会社なので、技術的にレガシーな部分も当時たくさんあって、そこを入れ替えていかなければいけない。となると、その人たちとは違う時間軸で、レガシー改善をしていく人たちがいた方がいいよねとなりました。オンプレのインフラを、クラウドに移していくインフラチームのプロジェクトがその原型で、そこからだんだんとアプリケーションレイヤーの技術刷新までみるようになっていった、という流れです。
結果的に昨今は、その人たちが新しい技術基盤をある程度整えてから、プロダクトを作っているチームに輸出していく、あるいは一緒になって導入を支援するような形になりました。データサイエンスのチームも同じように立ち上がって、今の形に落ち着いているという感じです。
佐藤： 面白いですね。2社とも同じような、プロジェクトやドメインという単位でやりつつも、だんだん規模が大きくなってくると、横断的にやっていくチームが生まれてきたりと、全社的に技術プロジェクトをうまく作っていっているのかなと感じました。
2人が感じてきた、人数規模や事業ドメインによる違いとは？
佐藤： それでは、2つ目の質問に移ります。お二方ともフェーズが異なる会社でのCTOをご経験されていると思いますが、人数規模による苦労や面白さがあれば教えてください。伊藤さんからお願いします。
伊藤さん： 小さな会社と大きな会社どちらも経験があるんですが、小さな会社の方が、あまり意識していなくてもオーナーシップが生まれやすいと思うんですよ。
自分たちが作っているサービスの細部や一緒に働いている人たちを認識しやすい規模感なので、一生懸命マネジメントしなくても、サービスに対してオーナーシップを持たずに開発する人はあまり出てこない。一方で、大きな会社になると、そこを意識的にマネジメントしていかないと、オーナーシップの欠如が起こりやすいという実感があります。
一休で開発部が受託のような形になっていた時に、まさにそういうオーナーシップの欠如が起きたんですね。端的に言うと、なぜこれをやっているのかわからないとか、システム開発の役割分端において自分の領域がどこからどこまでなのかわからないとか、そういう状況が生まれてしまった。
こういう状況を放置していると、だんだんと「うまくいっていないのは自分のせいじゃない。」と他責になってくるんですよ。何を、なぜやるかの決め事に自分は関与していないんからそういう思考になるのも当然ですよね。その人がやるべき領域を明確にして、自分で意思決定している状態に持っていかないと、うまくいかなかった時に言い訳できてしまう。大きな組織ほど、コントロールしていないとすぐにそうなってしまう印象です。
佐藤： お互いに「それはそっちの領域でしょ？」という感じで、誰もやらないみたいなことも起きそうですよね。逆に、領域を明確にすることによって、「ここまでは責任を持つから、お互いに頑張ろう」という、団結した空気も作りやすくなるのかなと感じました。
伊藤さん： そうですね。10人くらいの時は、組織を1つにまとめる方向でマネジメントするんですよ。一体感があった方が、コミュニケーションコストも下がるしオーナーシップも生まれやすい。でも、50人の規模で1つにまとめようとすると、各々からみたときにゴールが遠くなってしまうためむしろオーナーシップの欠如が生まれてしまう。
なので、敢えて領域を分けて「この領域は君が責任を持ってね」とはっきりさせないと、オーナーシップが生まれない。その領域については基本的に１つのチームだけが責任をもつ。複数のチームが同じ領域を担当すると責任が曖昧になる。こういうことをはっきりさせていきました。そこの境目が、15人の組織と50人の組織との間にあるなという印象です。
佐藤： 続いて、柄沢さんはいかがですか？
柄沢さん： 技術や人数規模とは、少し違った軸からの話になりますが、会社により、インターネットのプロダクトで完結したりしなかったりと、一言でプロダクト開発と言ってもその業種や業界、事業のドメインは全く異なりますよね。
宿泊や飲食もそうだと思いますが、その業界にいるのはインターネットに詳しい人ばかりではないですよね。でも、例えばメルカリだったら、ユーザーはスマホを使い慣れているような人が多い。自分も、ここまでそういった対象とするお客様のリテラシーも、まったく違う中で開発組織を任されてやってきました。
会社の経営層の成り立ちによっても、全然使える言語が違います。もともとプロダクト開発をしていた人が経営陣にいれば、エンジニアの話はスッと伝わりますが、そうでない会社もある。これは良い悪いという話ではなく、どういう視点で何を見て仕事をしているか、そこに集まる人たちの視点の違いなんですよね。
そういう経験をしてきた中で最近思うのは、世の中には「こうやったら上手くいった」という組織の取り組み事例がいろいろありますが、事業ドメインだったり、関わっている人たちの属性やリテラシーだったり、いろんなものに依存して、うまくいったりいかなかったりするんですよね。
自分のメルカリでの成功体験も他社から聞いた事例も、単なるケーススタディでしかない。そのまま当てはめられるわけではないから、この会社でうまくやるにはどうしたらいいのか、日々一生懸命考えながらやってるんですよね。それが面白いなと思っています。
そういうフェーズや業界の違う会社に複数関わって、知識や経験として自分の中に蓄積したものを、レゴみたいに組み合わせて当てはめていくのが、自分の血肉になる感じがしています。やればやるほど、いろんなパターンに対応できるようになってくるので、経験を重ねるごとに見える世界が変わってきているなと感じます。
このイベントに参加されている方も、いろいろな事業や業界の方がいると思います。自分の会社に当てはまる部分と当てはまらない部分が絶対にあるので、「あの会社がやっていたからこれが正解だ」ではなくて、課題が共通している部分を試してみたり、やってみてダメだったら戻してみたり、自社に当てはめながらトライアンドエラーしてみるといいのかなと思います。
チーム間の連動や複数部署の連携について質疑応答
佐藤： いくつかチャット欄でご質問をいただいているので、お答えしていければと思います。まずは、「スタフェスさんのプロジェクトは、どれくらいの時間軸になるのでしょうか？」というご質問です。
柄沢さん： プロジェクトは終わりを決めずに進めています。中には例えば「軽減税率対応プロジェクト」のように、期限のある法令対応や急を要するものなど、達成したらほとんど完結するような終わりのあるものもありますが、例えば「ごちクル」というサービスを成長させるということには、基本的には終わりがないわけですよね。
プロジェクトにおけるミッションや目的には、なるべく普遍的で大きなものを置いています。会社のミッションを一段階、その事業ドメインに対して分解したものというイメージですね。そうすると基本的に終わりがない、長期的なプロジェクトになるという形です。
佐藤： 続いてのご質問です。「事業ドメインに合わせてチームを細分化していくと、そのチーム単体での機能開発はうまくいく一方で、チームが連動しないとユーザー価値を作れない中間部分の機能開発が、なかなかうまくいかない問題があると感じています。連動しやすくする工夫、もしくは連動せずともうまく開発するような工夫はされていますか？」とのことです。伊藤さんいかがでしょうか？
伊藤さん： そうですね。これすごく良い質問だなと思っていて、たしかに先ほどお話しした組織構造だけだと、おそらくサイロ化が起きるんですよ。
対して僕たちは、プロジェクトの起案をトップダウンですることも多いんです。それほど大きくない会社なので、各チームのPMと役員が週1くらい必ずミーティングをしていて、そこでロードマップのすり合わせをしています。
普段はチームが独立して動けるタスクが多いので、横断的なプロジェクトは発生しないんですが、それこそGo To トラベルとか、時々すごく大きな話が出てくる。そうすると、当然1つのチームでやれるものではないから、事業責任者や僕が指揮をとってロードマップを描いて役割分担したり、そういう上流の調整をして3～4チームを連動させるマネジメントをしたりします。
サイロ化してしまったチームが、ボトムアップでこういう横断での役割分端が必要な大きなプロジェクトを成功させるのはなかなか難しいだろうなと考えていて、そのためにも常時トップダウン / ボトムアップいずれのアプローチでも取れるように、役員とチームとで調整をし続けている感じです。
佐藤： そういった時に、何か課題になるようなことはありますか？
伊藤さん： 今のところはうまくいっていますね。あと、スタフェスさんでは基本的に長期的なプロジェクトになっているという話がありましたけど、役割をコロコロ変えていると、オーナーシップが生まれないため、一休でもそのあたり、チーム構造や仕事の文脈を維持することは大事にしています。
なるべく普遍的なドメインでチームをつくることで、そのチームを長く存続させる。ドメインの捉え方がよくないと、事業がやりたいことに対してチーム構造が合わないのでチームを変えたり、仕事の文脈を変えたりということが頻発するようになってしまいます。なので、どういうドメインでチームを作るかは慎重に考えています。交流のために時々人を入れ替えたりすることはありますが、チーム構造自体は長く変わらず、基本的には同じ文脈の仕事に同じ人をなるべく長くアサインします。結果、個々人の熟練度が上がってきます。
個々人の熟練度が上がってくると大きなプロジェクトがあった時にも、どこまでは自分のチームで収めて、どこからチームを超えてコラボレーションしなければいけないか、経験的にわかってくるのでトップダウンで役割分端を指示する場合も比較的大きめの指示で問題なく実行できるんですよね。5年前だったらそんなにうまくできなくて、もっとトップからのマイクロマネジメントが必要だったかもしれないなとは思います。
佐藤： もう1つ似たようなご質問をいただいていまして、「複数の部署をまたがって進める時に、プロジェクトにおけるモチベーションや優先度が異なるために、どうしてもスピードや意思決定が遅くなってしまいます」ということですが、一休さんでも近い課題はありますか？
伊藤さん： あまりそういうのはないですが、意識的にやっていることとしては、先のことを早い段階で整理したり話したりするようにしています。
開発チームが今やっていることの3ヶ月先や半年先のロードマップを常に描いていて、「これが終わったら、次はこれをやる必要がある」というのを常時見える化するようにしています。見える化といっても別に大袈裟な仕組みがあるわけではなくて、半年ぐらいのプロジェクト線表が常に更新されている、という程度のことです。でも、これによってチームメンバーからみても、今までやっていたことと全然違う話が突然振ってくるとか、次にやることを知らずに仕事している、といったことはあまり起きないですね。ステークホルダとも少し先のロードマップをベースに会話できるので、彼らからみても安心感があるようです。
ただし、ロードマップはドメイン文脈ごとにちゃんと整理する。ただタスクが並んでいるだけの散漫なものではそれを見たときに開発者もステークホルダも理解できませんから。フォーカスする領域をはっきりさせて「ここから3か月、半年はこういうことに力を入れていくんだな」というのが分かるロードマップになっていることが大事です。
先のドメインの選択についてもそうですが、中長期でみたときに、そこにいる人たちが納得感を持って仕事に取り組めるかどうかには、こういう仕事領域やロードマップのデザインが割と重要だと考えています。「入ってきたタスクをとりあえず手が空いている人に振る」みたいな雑なマネジメントにならないようには気をつけていますね。PM には、この辺りの演出能力は求められると思います。
佐藤： 柄沢さんは、いかがでしょうか？
柄沢さん： 複数の部署で皆が同じ方向を向いて進むことの大事さは、伊藤さんから今お話いただいた通りで、もう1つ、これは小さい会社だとすごく難しいんですけど、兼任をなるべくしない。複数のプロジェクトにまたがって所属している人を、なるべく作らないことですね。
と、いいつつも、実際には弊社にも兼任を解ききれない部分も多くあり、社内から槍が飛んできそうですが（笑）。ここは採用して解決していくべき問題の1つなんですが、プロジェクトの目的意識をしっかり持っている状態にするという意味で、なるべく兼任させないことは大事だと考えています。
伊藤さん： それは大事ですね。
佐藤： 能力が高い方だったとしても、兼任すると全体としてのパフォーマンスが上がりきらないというのは想像できますよね。弊社でも、なるべく兼任を減らしていくために、委譲したり採用したりして、うまく役割分担していこうとしています。
伊藤さん： あと、そもそも論なんですが「これをやりましょう」と言われた時に「やりたくないです」と脊髄反射で言うのは良くないよねというのを、会社のカルチャーとして構築しているんですよ。やりたいやりたくないじゃなくて「やるべきこと」だったら、やるのがプロフェッショナルだよねって。こういうマインドの醸成は日頃の会話からの蓄積になるので、一朝一夕のことではないんですけど。トップダウンでプロジェクトを進める時に、「それは無理です」とか呼吸を合わせられないと辛いですからね。 そういうことを日常的に、常識として実践していく･･･自分がそういう姿勢を取ることも含めて、意外と大事だと思います。
佐藤： 弊社もバリューの一番最初に「前向き」というのを置いていて、絶対にクソコードと言わないようにしているんです。伸び代と言い換えるようにして、「伸び代しかないですね！」みたいなやり取りをしています（笑）。
コロナ禍の苦労が続いた2021年、2社が取り組んだことは？
佐藤： 次の質問に移りたいと思います。去年の振り返りで、2021年のエンジニア組織で大変だったことや、それに対して具体的に取り組んだことについて。柄沢さん、いかがでしょうか？
柄沢さん： いやぁ、大変だったことしかないんですけど（笑）。というのも、僕たちは主なお客さんが法人なので、会議弁当だったり締め会のケータリングといった需要がコロナの影響でめっきり減ってしまって、会社自体が大変だったんですね。
受託組織から抜け出しているという話をしてきましたけど、実際のところはお客さんと繋がりのある事業開発やセールスの部署が、新しい需要を掘り出してきて、売上を上げて会社を支えてくれているんです。
自分としてはプロダクトを中心に、テクノロジーによってスケールする組織を作っていかなきゃいけない。つまり、人手で頑張って年5～10％の成長を目指すより、スケールする組織で100～120％の成長を目指すのが自分のミッションなんですけど、そういう自分の理想と、実態として今の売上を支えている部分のジレンマに、すごく悩まされました。
でも、結局のところ、会社がきちんとランウェイを確保できた上では、採用して組織を強くして、プロダクトによって営業や事業開発のメンバーの活動を支えられる後ろ盾をつくっていかなければならないなと。ダメなところをリアーキテクチャしたりリファクタリングしたりして、自分たちが事業貢献できるプロダクトをつくっていくしかない。そこに地道に取り組んでいる、まだまだ過程という感じですね。
伊藤さん： 僕たちは実は事業としては順調で、コロナの逆境の中でも実は成長しています。ただ、開発に関して言えば Go To トラベルは実は大変だったんです。感染状況も日々予想外の動きを見せますし、それに応じて観光庁から昨日まで指示されていた内容が突然変わるみたいなことが毎日のように起こる感じで。状況が状況だけに朝令暮改が起こるのはわかってはいますが、それを常時キャッチアップしながら実装していく開発業務はなかなかハードでした。
だけど、一休にとってGo To トラベルはチャンスだったので、大変ながらも頑張って、結果的にいろいろ良かったことがあって。これはFindyのインタビュー記事でも話しているんですけど、チームで力を合わせないと絶対に無理な状況だったので、今まであまりうまくいっていなかったチームが噛み合っていったんです。これは結構意外でしたね。
佐藤： 忙しすぎるとハレーションを生んでしまうイメージもありますが、そこで逆に一致団結して強い組織に変わっていけるのは意外ですね。
伊藤さん： もちろんストレスもあったので多少ピリピリはしてましたよ。一方で、そういう局面だからこそ遠慮して話すべきことを話さずにやっていたら、より状況がきつくなることは皆わかっていたから、建前抜きで合理的にコミュニケーションするようになったのはすごく大きかったですね。
その後、Yahoo!トラベルと一休のシステムを全面統合するという、これもなかなか大きなプロジェクトを去年やったんですけど、Go To トラベルの経験がすごく活きました。チームビルディングもそうですが、今のチーム構成ならどこからどこまでをトップダウンで整理しておけば各チームが独立して動けるかを、僕自身もよくわかっていたんですね。
なので、プロジェクトが始まる前に、僕の方でいろいろと上流で整理しておいて、「はいどうぞ」と渡したら、そこからはスムーズに物事が進んで良い感じに終わったんですよ。どちらのプロジェクトも大変だったんですけど、ハードなことに取り組んだ結果組織の練度が一段階上がったような感覚があって、とても良かったなと思います。
意識するのは、“目的をぶらさないこと”と“コンテキスト共有”
佐藤： 次の質問は、チームマネジメントで意識していることについてです。また、リモートワークによって変わったこと、変わらなかったことがあれば教えてください。では、伊藤さんからお願いします。
伊藤さん： これは明確にあって、組織を変えたり新しいテクノロジーを導入したりする時に、目的をぶらさないということを意識しています。
ひとつエピソードというか失敗例をお話すると、会社やチームが大きくなるにつれて、開発チームのマネジメントコストが上がってきたから、ミドルマネジメントのリーダーを増やそうと思った時期がありました。その時に、リーダーにしたい人の数がその時点でのチームの数より多かったから、その人のためにチームを増やそうと考えたんです。
でも、そのことを役員会でレポートしたら、CEO から「それはダメだよ直也さん。チームというのは、お客様に価値を提供する活動のために存在するものなんだから。リーダーのためにチームをつくるなんて、ご法度だよ」と指摘されたんですね。
僕はそれを聞いてハッとしました。先ほど話していたような、チームをドメインで切っている話だとか、そういうことをすっかり忘れていたんですよ。改めて、チームや組織をどういう目的で構成するのか再認識したんですが、こういうことは日々強く意識しておかないと、つい忘れてしまうんですよね。
新しいテクノロジーを導入する時も、いろいろあるんだけれども、最終的には開発が速くならなければいけない。速くなるというのも、実装が速ければいいわけではなくて、顧客への価値提供が速くなり、かつ最大化できなければいけない。それを忘れないようにするのが大事かなと思います。
佐藤： 続いて、柄沢さんはいかがでしょうか。
柄沢さん： リモートワークによって変わったことって、プロダクト開発においてはあまりない……というか、僕がジョインして1ヶ月でコロナ禍に突入しているんです。なので、ジョインしてからほぼリモートだったので、自分自身は大きく変わったことはないんですけど。当初の2年前を思い返すと、一定の混乱はありましたね。
ただ、自分がジョインしてから、ツールの移行や、ちゃんと議事録を残すように改めて伝えたり、意識して変えてきた部分はあります。プライベートチャンネルを作るには、必ず理由をつけるとか。あとは、昔あった議事録を作ったらすぐにシェアする「すぐシェア」という文化を復活させて、ミーティング後に必ず議事録とサマリを決まったチャンネルに流すとか。
そういう工夫をすることによって、雑なコミュニケーションによって、オフラインで何かしらの意思決定がされていて、「いつの間にか決まってる」みたいなことが少し減ったんじゃないかと思います。
あとは、自分自身が気をつけているのは、チームに意思決定を伝える場面で、必ずコンテキストを共有すること。ミーティングだけでは伝わらないなら、別の伝え方もしようということで、「CTO Radio」という社内ポッドキャストを月1～2で昼に30分くらいやっていて、これまでに15回くらい収録しました。
例えば、採用する時も「何人採用します」という数字だけを落とすのではなくて、僕らは1～2年後に、どんな体制で何を実現できるようになりたいから、こういうチーム構成にしたい。そのために今、この部分でエンジニアが何人くらい足りてないから採用します、という感じで。そういうコンテキストをきちんと伝えていく努力を意識してやっているところです。
佐藤： オフラインだと、隣にチームがいるからやり取りしやすかったですけど、リモートだと「どういう経路で決まったのかよくわからないけど、やらなきゃいけない」みたいなことが出てきやすいですよね。さまざまな取り組みでコミュニケーションのパスを増やすのは、すごく素敵だなと思いました。
横断系チームのミッション、UX関連の目標はどう設定する？
佐藤： それでは、チャット欄でまたいくつか質問を頂いていますので、回答していければと思います。1つ目は、伊藤さんに向けてのご質問で、「横断的なチームのミッションは、どのように設定していますか？ 横断系チームはワークさせるのが結構難しいと思うので」とのことです。
伊藤さん： これは結果的にですが、ミッションはあまり設定してないです。横断系の技術支援チームは僕の直下のチームで、データサイエンスチームはCEO直下のチームなので、役員がハンドリングしているから比較的やっていることが経営に直結しますね。なので「これが終わったら、次はこれをやらなきゃいけないよね」という、やることベースで認識合わせをしています。
佐藤： 続いて、柄沢さんへのご質問で「UX関連の目標を決めるのに苦労しているのですが、どういったものが最適だとお考えでしょうか？ 弊社ではNPSを置いているのですが、あまり機能していません」とのことです。
柄沢さん： これは難しいですね。NPS（ネットプロモータースコア）というのは、「この商品やサービスを知人や同僚にどれぐらい勧めたいですか？」という質問で測る指標のことです。これは自分の経験が浅いのかもしれないですが、NPSがうまくいった事例をあまり知らなくて。UX関連の目標を決めるのは難しいですよね。
佐藤： 弊社でも、そこは課題ですね。
伊藤さん： 一休では決めていないです。形式的なKPIは置いてない。もちろんコンバージョンレートとかそういう一般的な数値は見ていますが、それを上げればOKということにはなっていないです。
柄沢さん： そうなんですよね。そういう定量的な数字を決めると、ハックができてしまう。つまり、本質的にユーザーに届ける価値を毀損して、その数字を上げることができてしまうんですよね。
少しふんわりした回答になってしまうんですが、チームの目的には定性的な「最高の◯◯体験」みたいなものを置くのが良いかなと思っていて。中間的な指標として数字の目標を置いているけれども、それを達成するために設定されたタスクは、きちんとその数字を達成しつつ、「最高の◯◯体験」を実現できるかが常にチェックされるという形ですね。
KPIを上位概念に置くとうまくいかないと思うので、上位概念に大きく定性的な目標があって、それを分解した定量的な目標があって、タスクがあるという構造にしておくと、目線がズレないような気がしています。
一休・スターフェスティバル社の採用情報はこちら
■株式会社一休
■スターフェスティバル株式会社
