2018年8月17日2020年3月31日

【登壇者】

会社ごとにおけるエンジニアの立ち位置・目標・働き方とは？

大月：みなさん、こんにちは。本日はお集まり頂き、ありがとうございます。

今回のコンセプトは、各5社さんのCTOあるいはエンジニアの責任者クラスの方にお話を伺い、エンジニア目線による会社自慢をして頂くというものになっています。

それではまず、自己紹介からお願いします。

酒徳：こんにちは、株式会社フンザCTOの酒徳千尋です。弊社は現在『チケットキャンプ』という、コンサートやイベントのチケットをオンラインで売買できるサービスを運営しています。今年からCMを何回か打っているので、皆さんに使って頂くことも増えたかもしれません。

今回は、『チケットキャンプ』の内側がPythonで実装されたフレームワークのDjangoで出来ているという経緯もあり、PyConのスポンサーとしてこちらにお邪魔しました。本日はよろしくお願いします。

松崎：皆さんこんにちは。株式会社いい生活でCTOをやっている、松崎明といいます。僕らは少しユニークなビジネスドメインを対象にしていまして、不動産業界が業務で使うシステムを、クラウドサービスとして展開しています。いわゆるBtoBに当たりますね。

そこの中で、皆さんが日々家に住む、家を借りる、買うといったようなアクティビティのデータを『いい生活』のシステムに蓄積し、不動産データの見える化というのを違う観点から試みている会社です。

Pythonに関しては、2011年頃に新しいサービスへリニューアルしたとき僕が推進する形で導入しました。サービスのバックエンドはマイクロサービスアーキテクチャになっているんですけど、そのすべてをPythonで書いています。本日はよろしくお願いします。

小椋：こんにちは、株式会社HDEでCTOをしております、小椋一宏と申します。当社では『HDE One』という企業向けのクラウドセキュリティサービスを提供していまして、Google AppsやSalesforceなどを使う際に、セキュリティ機能を追加するといった会社になっています。現在、150万人以上のユーザーに使って頂いていますね。

サービスはコードベースの約70%以上がPythonで、GO言語が少々といった状態ですね。当社はPyConのスポンサーを続けるというのを趣味でやっていて（笑）、今年はマレーシアと日本のスポンサーをしております。よろしくお願いします。

森本：こんにちは、白ヤギコーポレーションでサーバーサイドの開発をしている、森本哲也と申します。弊社では『カメリオ』というニュースアプリをBtoC向けに提供しているほか、『カメリオAPI』というニュース記事を分類するプロダクトをBtoB向けにサービス展開していまして、私はその開発を担当しています。

APIサーバーとしてはGO言語で作っていて、私自身もGoの開発をメインに担当しています。ただ、管理画面やクローラー、バッチ処理のスクリプト等ではPythonを使っていますね。そのほかにも、自然言語処理の機能開発であったり、弊社のデータサイエンティストもデータ分析でPythonを使っています。よろしくお願いします。

下田：株式会社ブレインパッドの基盤開発部部長の下田倫大と申します。弊社はエンジニアの会社としてはあまり馴染みがないかもしれませんが、ビッグデータとかAIがブームになる以前の、起業した当初からデータ活用の分野でビジネスをさせて頂いております。

受託分析から始まった会社なのですが、そのノウハウの自社プロダクト化や、分析結果を他社に仕組みとして提供し始めたところでエンジニアリングが必要になり、エンジニアを採用するようになりました。

そして、データサイエンティストと一緒にものを作っていく時、Pythonという言語が非常に良いなと感じまして、3年前くらいから会社の中心的な言語として活用しています。本日はよろしくお願いします。

BtoBやBtoCで異なる目標と体制

大月：それではパネルディスカッションに移っていきます。最初のテーマは「エンジニアが語るサービス・プロダクトとの関わり方」。

まず会社内のエンジニアの人数と割合、そして各社がどのような体制でプロダクトに関わっているのかを教えてください。

それでは、下田さんからお願いします。

下田：ブレインパッドはエンジニアが約40名程度となっています。自社プロダクト開発が30名くらい、クライアント向けに分析ロジックを組み込んだシステムを開発する人間が約5名、横串で技術を見ている人間が約5名という編成です。

自社プロダクトはBtoB向けが5個くらい動いていて、マーケティングやWeb広告に対してデータ活用を支援するものを作っています。そこを5～7名の小さなチームで動かして、インフラやフロントエンドをあまり分けることなく、全員がプロダクトを見られるチームにしています。

体制としては、各プロダクトにビジネス側のメンバーをリーダーとして置いて、数字を追う面はそちらに任せ、エンジニアは開発に集中できる環境になっていますね。

ただ、弊社の特徴としてデータサイエンティストと仕事をするという部分があります。

データ分析が絡んでくるので、「そのデータをどう活用していくか」、「プロダクトにどう組み込んでいくか」というのもエンジニアの仕事になる。そこが、いわゆる一般的なサービス開発、プロダクト開発をしているエンジニアチームとは違うところですね。

森本：白ヤギコーポレーションの場合、全体で7人という小さな会社で、社長だけが非エンジニアという特殊な環境になっていますね。

カメリオの開発が3人、カメリオAPIの開発が私1人、データ分析のコンサルなどがその他という感じで、かなり小さい規模になっています。

小椋：当社HDEは会社全体で約120名、エンジニアが約30名です。自社プロダクトに携わっているのはOpsチームも含めて約20名で1チームは4～6人ですね。

なるべく小さなチームで、各々が自主性をもって意思決定する環境を心掛けています。なので、役割分担はあまりなされていません。

もともとオンプレミス運用をしていた時代の名残で、OpsチームとWebチームに分かれているのですが、クラウドに全面移行してからはOpsも含めた業務を全体で回しています。

業務としては改善、機能の追加、新規サービスの企画をやっていますね。サービス開発のところは1～2人くらいのチームから徐々に膨らませるかたちでやっていて、その他を4～5人のチームでやっているという感じです。

松崎：ウチは会社規模で130名くらいです。エンジニアはQAとインフラとを合わせて60名程。そのうち、メインプロダクトに携わっているのが30名弱。5～10名くらいのチームが4つあって、プロダクトラインとして動いているかたちです。

オンプレでやっている状態なので、Ops選任ではなく、各チームが協力し合ってオペレーションに絡む状態になっていますね。

プロダクト企画に関しては三つ巴の体制を取っていまして、エンジニア、営業、企画の各シニアクラスが月一で会議して、各チームが合意したうえで改善施策や新規開発を進めるという感じです。そうすることで企画の起点をエンジニアのアイデアベースや、お客様の声といった様々な部分に求めることができるんです。

酒徳：フンザは全体で35名くらい、エンジニアが10名程度です。その内訳はチケットキャンプとは別の新規事業担当が2名、アプリ専任が3名、サーバーサイドエンジニアが残りという感じですね。

弊社はコンシューマー向け、しかもCtoCの分野でやっているのが特徴なので、サービスの改善時にはユーザーの声を特に重視しています。

サービス改善としては、プロダクトマネージャーから出てくる企画、ユーザーが実際に困っている点、エンジニアの提案が主な起点になっていて、全てのチームが一体となって企画ができるような環境になっています。

また、弊社の強みは会社全体やチーム単位での目標を持つことです。週一で目標を共有して、二週間単位で回すということを心掛けていますね。

エンジニアはどの程度数字を追うべきか？

大月：ありがとうございます。先ほど“追うべき数字”のお話がありましたが、続いて、「各社さんのエンジニアが数字の部分をどの程度追いかけているか」を教えていただけますか？

また、それに関連して「技術選定はどのように決めているか」も教えていただきたいです。「なんとなく決めています」とかでも構わないので（笑）

酒徳：ウチは数字を厳しくみていますね。毎日の朝会で「昨日の売上」を共有して、数字に対する意識を社員全員が持つ取り組みをしています。エンジニアも例外ではありません。

なので、例えばエンジニアがなんとなく「こういうものを作りました」と報告しても、「それ、どれだけ売上に貢献しているの？」って聞かれてしまいます。

大月：ある意味、健全ですよね（笑）

酒徳：そうですね（笑）技術選定に関しては、エンジニアに任せられていて、最終的にCTOが判断するというかたちになっています。技術選定で揉めることは少ないですね。

大月：おそらく朝会が上手く機能していて、目的がしっかり共有されているからこそ技術選定もスムーズなのかもしれませんね。松崎さんはいかがですか？

松崎：弊社も同じように朝会が週一であって、目標達成までの進捗は全社で共有をしています。ただ、プロダクトラインが複数あってプロダクトごとのKPIを追うかたちになるので、エンジニアは数字の責任自体を追ってはいないですね。そのぶん、技術の導入状況や機能の使用具合はチームごとで共有して、施策に活かしています。

技術選定は難しい話ですね。技術選定をする際に考えるのが、“プロダクトがどのくらいもつのか”で、これを見極めるのが難しいんです。

ヒットするものほどこのライフタイムが長く、サービスが大きくなると、ユーザーもデータも充実してくるので、いじりたくてもいじれないというジレンマが出てくるわけです。

一方で、使う技術の選定を見誤ると、それが3年後ぐらいにメンテが止まってしまって…、にも関わらずサービスは動かし成長させ続けなければならないということもあるんですよね。エンジニアにとってはあるあるなんですけど（笑）

OSだったりすると選択肢が三つしかなくて、「元のソフトウェアをフォークして、新たなものを作り出してしまう」か、「積極的なコミッターになってそのソフトウェアのメインメンテナーになってしまう」か、「そのソフトウェアを捨て、新たな別のもので代替する」かしかないので、そうならないように気をつけようという意識が共有されています。

なので、サービスがヒットするか分からないときの技術選定は大体でざっくりと決める。そしてある程度成長するとリファクタリングし辛い部分も出てくるので、その頃には一定の基準で決めるようにしています。コミッターの数に対してこの技術は大丈夫か、などですね。

小椋：当社の『HDE One』だと課金モデルがシンプルで、1ユーザーあたり年額いくらという感じで計算できます。なので、売上というよりユーザー数をKPIにしていますね。

ユーザー数も変動が大きくて50～100％というところを推移しているので、拡大し続けるユーザーを支えられるスケーラブルな基盤を作ることも意識していますね。

あとは原価率ですね。拡大し続けても原価が上がれば利益に響くので、上がりすぎないよう調整しています。クラウドが普及して面白いなと思ったのが、エンジニアの原価が見えやすくなったことなんですね。

それまでは何か作ってサーバーはいくらなのか、インフラはいくらなのかとか分かりづらかったんですけど、クラウドになってからは「この一行変えるだけでいくら節約できる」というのが分かって、エンジニアの実装が価値として見えやすくなりました。これは面白いですね。

技術選択に関して言うと、熱意とビジョンがあるメンバーの意見を優先しています。

「仕事だから残業して、頑張って、あとは帰るだけ」という考え方の技術者もいます。ですが、勉強意欲の強いエンジニアは定時に上がって、家に帰ってもずっと技術のことが頭にあって、「明日はこうしよう」ということを無意識に考え続けていたりします。

なので、後者のタイプのエンジニアがなるべくモチベーションを保てる技術選定が重要だと考えていまして、結果としてその方が生産性も上がると思っています。

森本：弊社は7人と小規模なので、数字の責任は社長がもっていて、メンバーの意識は疎いところがあります。ただ、四半期ごとに合宿をやっているので、そこで今後の目標や三か月間の反省を行って、意識の共有を図っていますね。

私個人の技術選定だと、同僚に必ず聞いてフィードバックを交えながら決めています。小さい会社なので揉めることも少ないですね。

ただ、アプリを作っている伊藤という者がいるのですが、彼は勝手に決めて動かすので（笑）、会社の技術ブログでの掲載を見て私も初めて知ることがあります。「サーバーサイドSwiftへ移行しました」と書いてあると、「そんなことしてたの？」みたいな（笑）

あと、今動いているクローラーはPythonで作られているんですけど、それを作り直そうとしていて、いまSwiftでクローラーを作っています（笑）Swiftでクローラーを開発しようとしているのはこの会社くらいでしょう（笑）

これは極端な例ですが、小さい会社で個人の裁量が大きいぶん、個人がモチベーションを保てる技術を選ぶのが良いと思いますね。

下田：弊社のエンジニアは売上にあまりコミットしていません。ただ、主にBtoC企業で採用されているプロダクトを作っているのでスコアリングにはかなり気を遣っていますね。取引社数の増加ペース、ユーザー数に耐えられるだけのアプリケーション構造をしているかなど、営業計画に合わせたKPIをエンジニアに持たせています。

技術選定に関しては、“各チームでやるべきと判断したものはやっていいよ”としています。

僕は性善説を信じているので、エンジニアは結果的に合理的で効率の良いものを選ぶはずと考えているんですよ。なので「いまPythonのところをGOにしたい」という話が来たとしても、そこには何かしらの意図があるはずなので、許可しますね。

ほかにもApacheにSparkを導入するチームがいたり、分析系はジョブ管理が大変なので管理ツールを導入したりだとか、色々やっていますね。積極的にプロダクト改善の提案を引き出すのが僕の役目かなと思っています。

「リモートワーク」って賛成？反対？

大月：ありがとうございます。会社の規模やサービスごとで、かなり特徴が見えますね。

お話のなかで「家に帰っても技術のことを勉強してくれていたらいいよね」という話があって面白かったのですが、それに関連して「リモートワーク」を話題に上げてみたいと思います。

「家でやっても変わらない」、「むしろ違う場所の方がはかどる」、「でも、本当にワークしているのか？」など、エンジニアの働き方が多様になっていくにつれて様々な考えも生まれてきました。たまに、「自宅にニューロンを取り入れていて、家の方が早いから出ません」みたいな人もいますからね（笑）

そこで最後は、各社の「リモートワーク」に対する考えを聞いてみたいと思います。取り入れていきたいか？そうでないか？そしてそれはなぜか？など、いかがでしょうか。

酒徳：正直に言うと、リモートワークは否定的ですね（笑）

というのも、コミュニケーションコストがものすごくかかるんです。ウチはSlackを使っているのですが、会話だと数秒で終わることがチャットだと細かいニュアンスまで伝わらなくて時間を取られる。チャットだと誤解しやすいし、感情的になりやすいんです。

松崎：ウチもリモートワークは考えてないですね。

やっぱりチームで開発をしているとコミュニケーションが重要で、チャットだとなかなか意図が伝わらないんです。だから原則、開発のときは社内がいいですね。

ただオペレーションの部分では時間的制約があるので、休日何かあった時にわざわざ会社に出てきて対応しなければいけないかというと、そうでもないと考えています。なので、運用上の問題が発生した場合等では原則リモートで対応する形になっています。

小椋：うちは真逆で、リモートワーク推進派ですね。

もちろんコミュニケーション面でのデメリットはありますが、弊社は2年前くらいから開発を国際的な対応に切り替えていまして、開発チームも半分くらい外国籍のメンバーになっているんです。

なので、常に英語でコミュニケーションを取っているので、インプリシットではなくエクスプリシットなコミュニケーションで仕事をするというのが前提にあります。これはデメリットでもありますが、それによって得られる開発上のメリットの方が大きいと考えています。実際に北京からリモートワークした社員もいますよ。

仕事をきちんとしているかどうかの問題は、会社に居たところでわからないので（笑）

ただ、教育の面で大きな問題があります。新しい人をどうチームに溶け込ますか、どう技術選定をしていくのか、これは隣でトレーニングすることに勝るものはないと考えているので、課題の一つになっていますね。

会社もGitHub中心のいわゆるオープンソースで回していて、それで開発ができるのであればオープンソースと同じことはできるはずなんです。ただ、その中でハードルはあるのでそれをしっかりと乗り越えていきたいと考えています。

森本：弊社もリモートワークはできるようになっています。会議の出席などは必須ですが、基本は会社にいなくても仕事ができる状態ですね。

コミュニケーションに関してお話すると、前の会社でチケット駆動開発をしていて、課題管理システムのチケットにコメントとして「いま何をやっているかを書き込む」というスタイルで仕事をしていたんですね。

それをすると、チケットが更新されていたら「その人が何をやっているか」「どういう意図で機能を開発しているか」といったことが周りの開発者にも分かります。ドキュメントと言うほどではありませんが、そのとき開発者が考えたことやその意図などが文章として残ります。

後になって別の開発者がそのチケットに関することを調べるときにそのときの考えや意図を読み取れます。

下田：私個人としてはリモートワークがいいですね。というのも、今年子供が生まれたので子供を見ながら仕事をしたいんです（笑）

個人ではなくブレインパッドとしては、リモートワークは認められていない状況になっています。開発に関して言うと外からでもできる状態なので、あとは制度上どうしていくかですね。

エンジニアがリモートワークにしたいという気持ちも当然わかるのですが、今の働き方でリモートになってもワークしない可能性が高いので、どうすればそうならないのかが重要ですよね。全体的な生産性や開発の観点から見直して、今のパフォーマンスを維持できるのであれば、会社としても後押ししやすく思います。

その辺をクリアして、いつかリモートワークになると良いなと思います。

大月：ありがとうございます。質問は以上になります。エンジニアの働き方としてよく話題に上がる「リモートワーク」について、各社の考えを伺えたのはとても面白かったです。また、会社という組織におけるエンジニアの在り方や、目標とすべきKPIについても、会社ごとの特色が見えて興味深かったと思います。改めまして、本日は貴重なお話をありがとうございました。

Career Park Tech番外編、いかがでしたでしょうか。

今回は、ベンチャー企業の技術者トップ5名に対談をして頂いて、人事経験のある大月がファシリテーターを務めるという構成でお伝え致しました。

引き続き、キャリアパークをよろしくお願い致します。

（文：藤井翔太）