開発とビジネスの境界線。エンジニアはビジネスとどう関わっていくべきか〜Qiita Engineer Summit 2021レポート③
2021年7月21日、エンジニアとして活動している方を対象にしたオンライントークセッション「Qiita Engineer Summit 2021」が開催されました。これは、“This is Engineering”をコンセプトにしたもので、参加企業各社が考え、取り組むエンジニアリングについて語っていだだく場です。
Qiita Engineer Summit 2021 特設サイト
セッション第三弾では、「開発とビジネスの境界線」というテーマでセッションが設けられました。エンジニアの担う役割が日々広がっているからこそ、開発組織としてビジネスとどう関わっていくのか。本セッションでは、株式会社カカクコム、LINE Growth Technology株式会社、WED株式会社の3社の実際の開発現場の取り組みを語っていただきました。
登壇者情報
目次
登壇者自己紹介
－－まずは皆様の自己紹介をお願いします。
京和：カカクコムに入ったのはちょうど2年前でして、今年7月に執行役員になりました。前職はクックパッドという会社でエンジニアとして入社しましたが、色々あって子会社の経営やプロダクトにコミットメントしていました。その前がカカクコムで、いわゆる出戻り組になります。当時の食べログはサービス開始からまだ2年程度で、システムもWindows/ASPベースだったのですが、それをLinux/Railsベースにフルリプレイスするなど、エンジニアとして事業の飛躍に貢献してきた経緯があります。
寺田：LINE Growth Technologyで、主にフードデリバリーサービスのプロジェクトマネージャーをやっています。入社して1年半ほどでして、それ以前はSIerで7年ほど、SAPなどのERPパッケージ導入などをやっていました。前職以前はプロジェクトリードを中心にやってきましたが、LINEではよりものづくりに近い位置で働いています。
丹：2018年に、まだ代表とデザイナーしかいない時に、1人目のエンジニアとしてWEDに入社しました。メインプロダクトをリリースするにあたって、テックリードを担当しています。ちなみに前職は、エウレカで3年ほどエンジニアをやっていました。
エンジニアはビジネスにどう関わっていくべきなのか？
－－次に、各社エンジニアにどこまでビジネスに携わってもらうのかについて、会社としての仕組みなどを教えてください。
京和：食べログではエンジニアが110名ほどいて、組織全体では500〜600名ほどになります。会社全体の組織としては職能型で構成されており、システムを扱う本部がある他に、ビジネスの本部や営業の本部など、縦割り型の組織構造になっています。
組織が大きくなるにつれてエンジニアがビジネスに携わるという点で距離感が出てきてしまっていたので、今はマトリクス型組織の横串組織を作ることにチャレンジしています。
具体的には、職能をまたがる横串の小さなプロジェクトチームを組んで、そこでそれぞれミッションやKPIをもち、エンジニアもビジネスに積極的に関われるような組織づくりに取り組んでいます。
－－WEDではいかがでしょうか？またスタートアップの場合は事情が異なりそうですね。
丹：まずエンジニアの人数で言うと、僕らは5人でやっていて、その中でレシート買取アプリ「ONE」と売上管理ソフトウェア「Zero」という2つのプロダクトを開発しています。
ONEに関しては、これまでは業務提携が多かったので、エンジニアも積極的に入っていき、ビジネスサイドと一緒になってクライアントと機能を作り込んでいくところをやってきました。またアプリ内で広告も配信していまして、アドネットワークのKPIをエンジニアが追っていることもあるので、エンジニアメンバーが広告のプロジェクトをもっている形にもなります。
－－ビジネスに関わるどころではなく、エンジニアがビジネスをドライブさせている感覚ですかね。
丹：スタートアップでは、施策が事業に直結しているので、密接に関わっていますね。
－－なるほど。LINE Growth Technologyでは、今の2社と比べて違うところなどはありますか？
寺田：弊社は、エンジニア組織の規模的には80名程度なので、2つの組織の間くらいなのですが、少し特殊な役割があると思っています。
といいますのも、当社では「Growth開発」と呼んでいる、各サービスを運営していく中で発生する人的業務をシステム化していく役割がメインであります。サービスの利益をいかに上げていくかと言う観点からは少し遠いものの、一方でサービス全体を知らないことにはバックオフィス業務の課題も見つけられないので、ある程度ビジネスについての理解を深く持たないとエンジニアとして力を発揮できないと感じています。要するに弊社では、お金が直接発生しない領域で、エンジニアがビジネスを意識する必要がある形になっています。
エンジニアが追うべきKPI/事業数値
－－各社それぞれの役割で数値目標があるとのことですが、エンジニアが追うべきKPIや事業数値はどのようなものがあるのでしょうか？ものを作ってから事業に反映されるまでにタイムラグがあると思うのですが。
京和：例えば先ほど挙げたプロジェクトの中で、検索改善プロジェクトと言うものがあります。検索改善プロジェクトは「飲食店を探しやすいサービスNo.1になる」というミッションをもち、直近では「ガッカリ体験をなくす」ということを目標にKPIを設定しています。例えば検索する時に、０件ヒットはユーザーにとっては1つのガッカリ体験になるだろうから、それを改善していくといった形です。
直接の売上を上げるとなると、食べログのような大きなサービスの場合は色々な要因が絡んできて難しいので、それにつながるような部分のKPIを自分たちで設定して改善するようにしています。
寺田：Growth開発に関しては、あえて数字を追わないということにしています。ROIを追うと絶対に手をつけない部分でも、今実際に困っている人や事業がいるよねと。そういうところをちゃんと潰していってあげることに価値があると考えています。
丹：両社と重なる部分があると思っています。ONEはtoC向けですごく伸びているのですが、そこでエンジニアが担っているのは広告の売上とニュース機能のPVなどです。エンジニアだけでもコントロールできる指標は、エンジニアが追うようにしています。
一方でZeroについてはプロダクトをまさに作っているフェーズでして、導入していただくにあたってのペインを潰しにいっている段階なので、数値は追っていないということになります。
京和：食べログも、LINE Growth Technologyさんのような側面があります。例えばUI改善のような領域は指標化が難しく、あえて数値目標を持たないプロジェクトもあります。
プロジェクト全体でバランスをとりながら、数字をもつところ/もたないところをデザインして進めています。
エンジニアが身につけるべきビジネス知識とは？
－－ちなみに、エンジニアはビジネスの知識はどれくらい身につけているものでしょうか？ビジネスモデルや売り上げの仕組みなどについてです。
京和：身につけていれば身につけているほど良いと思っています。どういうビジネスでどういうところからお金をもらっていて、どういう価値を提供しているのかといった一連の循環や、どういうステークホルダーがいるのかの理解も大事だと思います。
また、技術的負債というのもあります。技術的負債とは「開発と共に得られていく知識や理解と目の前のシステムとの乖離」であると言われています。（参考:【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明)
この負債を極力少なくするために、エンジニア自身が事業やビジネスを理解することがとても重要だと考えています。
丹：うちの場合は、そこまで強くエンジニアのビジネス理解が言われているわけではないのですが、ユーザーの方にどう使われるかという理解は求められています。少なくとも、まだビジネスモデルを模索しているような状態なので、全体感は求められていないかなと思います。
寺田：先ほどお伝えしたように、バックオフィス全体の改善につながるためには、サービス全体の知識が必要になります。
また僕たちの役割は、単独のプロダクトの改善だけではなく、複数のサービスに共通する課題を見つけて、標準化・共通化していくことにあります。なので、個別のサービスに関する深い知識はそれほど求められないものの、LINE全体で俯瞰して見た時に共通した課題を探すという意味で、ビジネス的な観点が求められています。
－－会社のフェーズ的にエンジニアが身につけるべき知識は変わっていると思いますが、そこの変遷はいかがでしょうか？
京和：私の場合は食べログの初期の頃からいたのですが、当時は能動的に知ろうとしなくても課題が次々に降ってくるので、それらをひたすら倒していると、気づいたら詳しくなっていました。一方で今の食べログは、すでに色々なものが出来上がっているので、それに付随する知識などをある程度能動的にインプットしていかないといけない、という差はあるかなと思います。
会社としてどう評価するのか？
－－エンジニアには様々な人たちがいると思うのですが、その中で、会社としてどのように評価をしているのでしょうか？
丹：ちょうど今年の7月から半期で評価制度を導入していくというフェーズになるのですが、僕らはMBOとバリューの半々で評価をするという仕組みにしています。
MBOについては、目標を僕とメンバーとですり合わせて行って達成度合を評価するのですが、僕自身は事業の数値はそこまで追わなくてもいいかなとは思っています。エンジニアとしてコードを書いてリリースがされている以上、事業への貢献はなされていると思っており、技術的なクオリティを高めることがエンジニアの第一使命だと考えています。まずはそこに重きを置いた評価をしているという状況です。
－－アウトプットよりにされているということですね。LINE Growth Technologyでは「数値を追わない」という話がありましたが、その場合のエンジニアの成果はどのように評価されているのでしょうか？
寺田：僕らは良くも悪くもほぼ全員がエンジニアなので、各個人がプロジェクトにどう貢献してどうコミットしたのか、どんなアウトプットを出したかが、特に強く見られています。評価制度としては、上司からの評価と360度評価の両面で行っています。基本的にいろんな人との相互評価をする、というのが特色になっています。
－－アウトプット重視にすると、成果に対する関心が薄くなってビジネスに興味がなくなるパターンもあるかなと思うのですが、そこに対してはどうされていますか？
寺田：私のところでは、サービス全体での指標などを、極力メンバーにも落としていくようにしています。自分たちのサービスが数値で見て成長しているのか鈍化しているのか、分析の内容も含めて説明する機会を設けています。
丹：基本的には自分ごと化して欲しいとは思っていますが、うちの場合はチーム人数も少なく事業責任者との距離も近いので、開発をしていたら自然と事業に関わらずにはいられないかなと思います。なので、この組織規模だと関心がなくなるということはないかなと思います。
－－なるほど。カカクコムではどうでしょう？
京和：これまでは自分たちにコントローラブルではないという理由で、エンジニアには事業数値を目標としてもたせていませんでした。現在ではマトリクス型組織に所属しているエンジニアにはプロジェクトのKPIを一定割合でもってもらう設計になっています。より主体的に事業に携わって欲しいという思いもありますし、システムを作るのではなく、事業やプロジェクトのゴールを達成することが仕事の目的である、というのを伝える意志としてやっている側面もあります。
そのため、事業側の目標に関しては、職位が上がるほど全体に占める評価割合が大きくなるという設計にしていて、メンバーの場合の評価割合は低くなるように設計しています。もちろん、事業ばかりになると自分のやりたいこととのギャップも出てくるので、事業に加えて、エンジニアとしてのパフォーマンス、スキルの成長という3つの軸で評価するという仕組みを、試行錯誤しながら作っていっています。
開発とビジネスの境界はどこにあるの？
－－最後に、ここまで見てきた観点を踏まえて、開発とビジネスの境はどこにあるのかについて、それぞれコメントをお願いします。
京和：自己紹介でもお話しした通り、僕自身、経営者やプロダクトマネージャーにも足を突っ込んで仕事をしたことがあるので、その経験からお伝えすると、エンジニアは作るものに対する責任があって、ビジネスはユーザーに対する課題や数値に責任があると思います。
ただ、ユーザーに価値を届けるというのは一連のプロセスであり、エンジニアもビジネスも一緒に手を携えて進めていく必要があるので、そういう意味では、積極的に越境していくべきだと思います。
丹：ビジネス職と開発職という分け方は僕はあまりしっくりこなくて、みんなで事業をやってプロダクトを作っているので、境界は特にない方が良いんじゃないかなと思います。もちろん、職種ごとの専門性があり、そこの境界はあるとは思いますが。
自分たちが書いたコードが、ちゃんとビジネスに役立っていて、そのために書いているという目的意識をもっていることが大事かなと思います。
寺田：私も同じく、ビジネス職と開発職という区分けはあまり必要ないのではと思っていて、その上で、ジュニアからシニアに上がっていくに従って、同じ数字でも責任を持つ領域が変わってくるのと同時に、ビジネスも視野に入れてプロダクトのことを捉えなければならないと考えています。少しずつ視野を広げていくことは、エンジニアでも必要だろうと思います。
取材／文：長岡武司