日経新聞、クオカード、広木大地氏が語る内製エンジニア組織づくり【DXイベントレポ】

2019年7月22日、社内でのIT・Web戦略やエンジニア組織づくり、デジタルトランスフォーメーション（DX）に取り組む方に向けたイベント「攻めのIT戦略、内製エンジニア組織づくり〜上司の説得方法から、やってみて分かる”べからず集”まで〜【DX-Lab #1】」が開催されました。

エンジニア転職サービス「Findy」のリリース後、1000社以上のクライアント企業とお会いする中で、特に大手企業やIT・Web業界以外の企業において、エンジニア組織づくりやプロダクト内製化、社内のデジタル化に多くの課題があることがわかってきました。

一方で、新たな価値貢献の場として、上記のような企業における採用・評価・育成なども担うエンジニア組織づくりや、デジタルトランスフォーメーション（DX）推進担当に興味を持つエンジニアの方も増えてきています。

そこで今回、その分野で先行している日本経済新聞社と株式会社クオカードでの、システム開発内製化やエンジニア組織立ち上げにまつわる成功事例や苦労等を共有頂くイベントを実施。

また、『エンジニアリング組織論への招待』を上梓し、デジタルトランスフォーメーション（DX）分野でも先進的な発信をしている広木大地さんを迎えて、パネルディスカッションを行いました。そのイベントの模様をお届けします！

■パネルディスカッション登壇者

澤紀彦
日本経済新聞社。2009年3月東京大学工学部を卒業後、同年4月に日本経済新聞社に入社。同社にて内製開発の導入・推進や新サービスの企画開発を担当。

齋藤健一
株式会社クオカードデジタルイノベーションラボ　プロダクトグループリーダー。フリーランス、SIerを経てベンチャー企業数社でCTOを歴任。現在はQUOカードPay開発の責任者としてチームをリード。

広木大地
株式会社レクター取締役。1983年生まれ。筑波大学大学院を卒業後、2008年に新卒第1期として株式会社ミクシィに入社。同社のアーキテクトとして、技術戦略から組織構築などに携わる。同社メディア開発部長、開発部部長、サービス本部長執行役員を務めた後、2015年退社。株式会社レクターを創業し、技術と経営をつなぐ技術組織のアドバイザリーとして、多数の会社の経営支援を行っている。著書『エンジニアリング組織論への招待不確実性に向き合う思考と組織のリファクタリング』

■モデレーター

山田裕一朗
同志社大学経済学部卒業後、三菱重工業、ボストンコンサルティンググループを経て2010年、創業期のレアジョブ入社。レアジョブでは執行役員として人事、マーケティング、ブラジル事業、三井物産との資本業務提携等を担当。その後、ファインディ株式会社を創業。また、現在もHRBP（ヒューマンリソースビジネスパートナー）としてレアジョブに関わっている。

まずは登壇者のプロフィール紹介からスタート

山田：
まずは、今日ご参加頂くお三方が、会社でどのようなことをされているかを含めて、自己紹介をお願いできればと思います。それでは、澤さんからお願いします。

澤：
日本経済新聞社の澤です。2009年に大学を卒業して、新卒で入社しました。約1年後に日経電子版の創刊が予定されていたので、当時は主に開発ベンダーさんにお願いしながら、開発スケジュールを調整していました。

その後、少し余裕ができたので、先輩社員と一緒に内製開発を進めて、それ以降は内製化を推進したり、内製化しているサービスを増やしたり、という取り組みをしています。それ以外には、テクノロジーを使ってデータ分析したり、スマホアプリを作ったり、機械学習を使ったプロジェクトや自動記事作成などの研究開発をしたり、といったサービスや事業の改善を行っています。

山田：
新卒でエンジニアとして入社されたんですか？

澤：
その当時は日経にプログラミングするエンジニアという職種はなくて、総合職として就職したという感じです。

山田：
そうなんですね。それから学生時代にやっていたことを踏まえて、今のキャリアになったと。

澤：
そうですね。学生時代に3～4年ほどスタートアップでアルバイトをしていて、Webサイトをどう作るかはそれなりに知っていたので。人に頼むよりも自分で作った方が簡単だなという。

山田：
ちなみに、実は僕と澤さんは高校の同級生だったりしていて。たまたま日経新聞さんで開催されたイベントで再会して以来、仕事でも関わりがあります。それでは次、齋藤さんお願いします。

齋藤：
クオカードの齋藤と申します。経歴としては、最初3年ほどIT以外を転々として、派遣やフリーランスとしてWebエンジニアをした後、SIerに入社しました。その後、ベンチャー数社でCTOをやっていまして、その会社で外注していたシステムを内製に切り替えるということをやったりしていました。

2017年11月にクオカードに入社して、今年の3月に「QUOカードPay」というサービスをリリースしました。その開発の責任者をしています。入社した時には、もともとエンジニアやデザイナーがいない組織だったのですが、すでにリリース日がほぼ決まっている状況で。全部内製化することは最初から諦めて、外注と内製は切り分けて進めてきました。

エンジニアやデザイナーの採用も進める必要があったんですけど、いわゆる昔ながらの中小企業という感じだったので、まずはリモートワークやフレックスといった制度を整備しつつ、SlackやGitHubなどのツールを入れたりして。そうやって採用を進めて、なんとか無事リリースできました。

山田：
そのタイミングでクオカードに入られたのは、どういった理由があったのでしょうか？

齋藤：
今まで数社のベンチャーでCTOをやっていて、ベンチャーは自由で人数も少ないので、変えられるところも多い一方で、予算や株主などいろいろな制約がありまして。今回は親会社が大きな会社で、充分な予算を使って立ち上げられるという背景もあり、やってみようと思って入社しました。

山田：
ありがとうございます。それでは続いて、広木さんお願いします。

広木：
広木です、よろしくお願いします。新卒でミクシィという会社に入社しました。いろいろと乱高下を繰り返している時期に入りまして、経営と技術というのはどう関連していくのかということを考え、痛感していくような日々でした。

そして、そこで培ってきたノウハウや知見を広く還元することができるのではと考えて、レクターという会社を創業しました。レクターは、さまざまなCTO経験者が集まったシンクタンクのような会社で、技術組織と経営との関係についての知見を多くの方に届けたいと思っています。

レクターでは、技術組織診断を行う「DXサーベイ」というサービスも行っていて、DX:デジタルトランスフォーメーションと、優秀なエンジニアが気持ち良く仕事ができるような環境があるかというDX:デベロッパーエクスペリエンスという二つのDXという言葉が、かなり近いところにあるという考えのもとにそれらを診断・測定して、どこに課題があるかを見つける仕事をしていたりします。あとは、技術経営のアドバイザリーや採用のご支援などですね。

2018年2月には、『エンジニアリング組織論への招待』という本を書かせて頂いて。この本が、ビジネス書大賞と技術書大賞を同じ年に受賞させて頂きました。現状、なかなかこういった本がないのかなと。当然のことではあるんですが、ビジネスと技術は離れているものではなく、一体なんだということを啓蒙していきたいと思っています。

山田：
広木さんは、私の前職であるレアジョブにも技術組織顧問という形で携わっていらっしゃって。今回のテーマで、ぜひ広木さんにと思ってお声がけさせて頂きました。

エンジニア組織としても大きな会社から小さなスタートアップまで、比較的レガシーな会社のコンサルティングなども含めて、かなり幅広く活動されているので、この後のQ＆Aでもどんどん質問を送って頂けたらと思います。

日経新聞、クオカードのエンジニア組織の内製化における現状の取り組みとは？

山田：
では、1つ目の質問から。「エンジニア組織の内製化における現状の取り組み」を、先ほどの自己紹介の順にお話し頂いてもよろしいでしょうか。

澤：
うちの内製化はまだまだで、今で半分くらいです。最初は完全にすべて外注でやって、結構苦労しました。内製化するという発想が組織になかった状態から、今に至るという感じです。

最初は僕ともう1人で、業務の合間にメモリ4GBしかないようなPCで内製化を始めたんです。その時はスマホが出たばかりだったので、スマホ向けのWebサイトを2人で、フロントエンドとバックエンドに分かれて開発を始めました。

まず最初は、クローズαとして、自分たちがニュースを読む時に使って楽しめればいいかなという感じで始めたんですけど、割とポジティブサプライズな部分があって、思ったより出来が良く、いろんな人に使ってもらえるようになりました。

そこからはパブリックβとして、お金をかけてプロモーションしたりすることはなかったんですが、少しずつお客さんがついてきて、内製化の効果が経営陣に認められていったんです。以降、エンジニアを採用したり、内製化のためのコンサルに入ってもらったり、内製化のプロジェクトを増やしたり、ということが徐々にできるようになりました。

山田：
内製化の始まりのところを、澤さん自身が手を動かして作り始めたと。

澤：
そうですね。大きな外部ベンダーに頼んでいると、細かい仕様の変更って難しいじゃないですか。かつ、意思決定プロセスが厚かったので、言葉選びが難しいですが、Webのことをよく知らない人がたくさん集まって作ってもUXは上がらないのかなと。

でも、わかっている人が作れば、1ヶ月くらいで簡単にできるものもあります。それを口で言ってもあまり信用されなかったので、空いた時間で実際に作り始めました。

山田：
現在、内製の割合が半分くらいとおっしゃっていましたが、何人くらいの組織でやっているんですか？

澤：
カウントの仕方が難しいんですけど、おおよそ50人くらいかなと。

山田：
何年くらいかけて、その規模になってきたんですか？

澤：
最初に始めたのが2010年とか2011年なので、7～8年かけてですね。

山田：
かなり段階を追って作ってこられたと。ありがとうございます。では次に、齋藤さんお願いします。

齋藤：
私が入社した時は、そもそもシステムもまったくなく、メンバーもいなくて、リリース日だけが決まっていたので、組織作りや採用、システムの要件定義など、すべてを並行してやらなければならない状況でした。ただ、UXを考えるとアプリはなるべく内製でやった方が良いというのが経営陣とも一致した意見でした。

なので、まずは一刻も早く求人を出そうと思っていたんですけど、みんな朝8時45分にスーツを着て出社するような会社なので、それを求人に書いても誰も来ないだろうと。最初はそういった話を、何度も時間をかけて会社に説明しました。

まずは、就業規則を変えてフレックスやリモートワークを導入できるように、経営企画の人と相談して進めつつ、並行して「そもそも誰のためのシステムなのか」というところから、プロジェクトメンバーと要件定義を固めていきました。

就業規則が決まってきたら採用を開始しつつ、採用できたところから自分の手を離していって、残っているタスクを対応していくという、かなり綱渡りなやり方で進めていました。それで、一応なんとかリリースできたので、上手くいったと言えばそうなんですが、現状はその弊害が出てきてしまっている部分があって。

今は10人ちょっとのエンジニアがいるんですけど、コミュニケーションが上手く取れていないとか、作ろうとしていたものの認識が合わないという問題が起きています。今はスクラムを本格的に導入して、そういった課題を解消していこうとしているところです。

山田：
それが入社されて1年くらいの間に起きたということですか？

齋藤：
そうですね。

山田：
日経さんと比較すると、かなり急速に組織を立ち上げていった感じですね。ありがとうございます。続いて、広木さんの方から。主にクライアントさんの話になるかと思いますが、お願いします。

広木：
僕の場合はクライアントさんによってさまざまですが、内製化だけがいいわけではないと思っています。ただ、そうした時にそもそも能力がないと判断がつかない、というのが非常に重要なところかなと思っています。

お二方がおっしゃっていたように、新しい技術によって価値が生まれやすい部分を特定して、順番に進めていけるのであれば問題ないと思うんです。しかし、そうではなく突然2～3人のエンジニアを採用して内製化しましょうと言って、「みんな辞めてしまったんですけど、どうしたらいいですか？」みたいなケースもあったりして。

そういう会社さんの場合、そもそもベンダーにちゃんと発注できているかという時点で怪しいことも多々あります。ベンダーとの契約内容を見てみたら、ソースコードの権利がなかったりとか。そうなったら、どうしようもないじゃないですか。

なので、内製化や組織作りには何段階かステップあって、そのどのステップにいるのか見極める人がまずいないと、組織を立ち上げようと言っても上手くいかない。今回お話し頂いているケースは、お二方がそういった役目をされたので立ち上がったと思うんですよね。なので、まず判断できるようにしないと、いろいろなことが進まないと思います。

山田：
例えば、どういう段階の会社があるんですか？

広木：
以前、Qiitaに「なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか」という記事を書いたのですが、システムには自分たちで制御できる段階があって、そもそも仕様書を把握していないとか、ソースコードのコントロールを持っていないとか、自動テストが動いてないとか、いくつかの段階かあります。

仮に内部の人が作ったとしても、組織変更を繰り返して誰もノウハウを持っていない状況になったら、内製化していても頼んだベンダーが消滅してしまったのとほぼ同じ。そうなるとコントロールできていないわけで、実際は二元論ではなくグラデーションになっていて、その段階のどこに自分たちが位置しているのかを知っていく必要があると思います。

山田：
ありがとうございます。それでは次の質問にいきたいと思います。

エンジニア組織の内製化を推進するために経営陣を説得させるためにできること

山田：
会場からも「どうやって経営陣を説得するか」という質問が結構来ているんですが、皆さんが実際にどうやって納得させていったのか、教えて頂けますか？

齋藤：
仮にエンジニアがいないと話にならない状況であれば、まずはエンジニアが行きたいと思う環境を作らなければいけません。採用が上手くいっている会社さんは露出を頑張っているところが多いので、いろんな事例を踏まえて「こうしないと採用が上手くいかないし、となるとビジネスも立ち上がらないですよね」と説明していきます。

リモートワークなどは経営陣から反発されることが多い部分だと思うんですけど、そこは今何をやっているか確かめられるツールもあるし、家にいるからといって仕事していないみたいな状況には必ずしもならないですよ、と。例えばGithubとSlackを連携するとか、やり方はいろいろあるので、とかいろんな話をしてきました。

けど、やっぱりスムーズにいかないこともあるので、そうしたら何回も言い続けます。たしか心理学か何かの本で読んだのですが、1～2回言われた程度では人間の頭に入らない。何回も言われると、抵抗がなくなってくるんです。ただ、あまり言いすぎると怒られるので温度感を見つつ、他社事例を踏まえて粘り強く交渉を続けるというのは、私がよくやる手法です。

山田：
そういう時、どんな事例を出すと経営層に刺さるんでしょうか？

齋藤：
今回の場合だと、フィンテックのペイメントサービスなので、競合他社って巨人ばかりなんですよね。そういうところは当然働きやすく、エンジニアが入りたい組織になっているわけなので、「こういう会社と戦っていかなきゃいけないので」と言って全部見せて。誰も8時45分に来てないですよねと（笑）。

リモートワークなどは入れていないところもあるので、それは導入するとこうなってとか、いろいろ説明します。「とにかく早くやらないと採用できない」「こういう会社と戦うためには、そんなやり方ではダメです」と言い続ける。

山田：
競合の話を出しつつ、とにかく繰り返すという。

齋藤：
そうですね。上手くいっている会社を例に出して「うちとこの会社、どっちに行きたいですか？」と並べたら、当然そっちに行きたいわけですよね。なので、うちもそれに勝てるようなものを用意しないとダメだと。

山田：
澤さんのところは、どんな感じですか？

澤：
うちはベンダーさんにお願いしていた時に、小さなデザイン修正や機能改修に対してすごく時間が掛かっていたんです。それで、ビジネス的にいつまでにやりたいと経営陣が思っていることも、あまり実現できない構造になっていて。「内製だったら」と重ねて主張していっていたので、それほど苦労せずに「部分的には内製もいいよね」という雰囲気作りがしやすい状況だったかなと思います。

山田：
日経新聞さんは組織自体がかなり大きいと思うんですけど、そういう話に最初に理解を示してくれる人ってどういう人たちですか？

澤：
新聞社にはさまざまな職種の人がいますが、我々は日経電子版を企画開発する部署なので、話をする先は主に部署内なんです。他の部署の人たちは、どうやって電子版のサービス作っているかについて関わりがないですし、就業規則を変えなくてもできることしかやっていなかったので。ちなみに、うちは最初から朝10時が定時ですね。

山田：
記者の方々もいらっしゃるので、わりと自由に働ける環境がもともとあったという感じですね。広木さんの場合は、クライアントさんから「一緒に説得して欲しい」といった話もあるのかなと思うのですが、いかがですか？

広木：
ありますね。そこは立場的にいろいろな事例を知ってるので、「世の中こうなってますよ」という説明ができることは、とてもよい説得材料になるかなと。説得するのであれば、本当にトップの方がいいと思っています。結局、経営トップが腹を括ってどうするか、という方向によってずいぶん変わるので。各個撃破するにしても、経営者が付き合う人間を順番に変えていく必要があるなと思います。

まわりの意見というのは非常に重要ですし、実際すべての組織がIT企業化していく時代だと2013年頃から言われて、もう6～7年経っているわけです。それでも「デジタル化したらどうなるの？」「内製化したらどうなるの？」と言っているのは、2周も3周も遅れてしまっている話だと思っていて。それってまわりの人が危機感を持っていない限り、ずっと同じなんだろうと思うんですよね。

黒船がやって来て「あれ、ヤバいかも」というような話が多いんですが、正直そう思ってからでは遅いことの方が多い。そういう兆しを感じている業界があったら、その業界の経営者との付き合いをどう増やしていくかなども上手くやっていかないと。なかなか本当に潰されてしまうという危機感がない限り、経営を変えようとはしないんじゃないかという気はします。

山田：
僕もいろいろな業界の企業さんとお会いしているんですけど、ナンバー1の会社は早いなと思います。例えば、メディア業界なら日経さんも早いですし、銀行業界だとやっぱりMUFGさんが早かったりするので。経営トップの意識ってすごく大事だと思います。

内製化や組織作りで直面する課題と対処法とは？

山田：
それでは、次の質問に移りたいと思います。内製化や組織作りに取り組まれてきた中で、どんな課題があってどのように対処してきたか。これについて教えて頂けますか？

澤：
そこまで大きく課題や悩みを感じないのは、僕の満足度のハードルが低いからかもしれないですけど……。いきなりエンジニアが増えて、エンジニア以外の人たちとのコミュニケーションがそんなに円滑ではないとか。「エンジニアの人たちが飲み会に来ない」みたいなことは結構言われますし（笑）、よくわからない人たちだと思われているかもしれない。

あとは、やっぱり既存のことにどうしても時間を取られてしまって、新しい技術をどんどん取り入れていく組織とまでは言えないのかなと。開発のミッションをガッツリやってもらう人たちと、新しい技術を開拓していく人たちは別にすべきかなとか。それがささやかながらの悩みですかね。

山田：
採用まわりは上手くいっていますか？

澤：
採用は、今年からFindyを使わせてもらっていて。既存の採用サイトやエージェントでは獲得しにくかったスタートアップ志向の人たちにリーチできるようになったと思います。さらに、以前から技術ブランディングとして、イベント登壇や自社ブログでの情報発信を始めていました。それによって草の根的に裾野が広がっていって、我々の技術情報や実際に働く様子が伝わることがプラスになっているのかなと思っています。

山田：
日経新聞さんは、エンジニア発の情報発信量が非常に多いですよね。続いて、齋藤さんはいかがでしょうか？

齋藤：
うちはスケジュールありきで採用して走り続けてきたので、それによる歪みが今かなり起きています。人を集めてきただけでは良いチームにならないと言いますが、まさしく今そんな状態になってしまっていて。いかに人の集団ではなく組織にしていくかというのを、今更ながらやり直しています。その手段の1つとしてスクラムを導入して、改善していこうと思っています。

山田：
人が急激に増えた組織をどう整備していくか、というところが課題になると。広木さんには、よく相談される課題やそれに対するアドバイスをお聞きしたいなと思います。

広木：
僕が今、最も課題だなと思うところをお話ししますと、会計制度で資産化されてしまうために、ベンダーに発注してしまう方が資産計上しやすく、結果的にPLヒットしないようにできる国って珍しい。そのため、内製化して、人件費として固定の費用をかけた方がいいよと説明しづらい事情があります。

これによって継続的な開発をするより、同じリソースを割いたとしても、一気に資産計上して失敗したら減損してしまう方が、はるかに経営の見た目上が良くなるというマジックがあって。この制度はこれまで何度もいろんな組織や団体が、どうにかしましょうと提案しているものの、特に上手くいかず。このままだとベンダー比率は、こういった力学によって変わらないんじゃないかと、僕は大きな課題を感じています。

イケてるなと思うソフトウェア開発の組織をもつ企業のIRを見ると、総資産におけるソフトウェア資産の比率が低いんですよ。つまり、ほとんど、費用計上できてしまっているんですよね。逆に厳しいなと思うところは、資産計上したままなんです。これはPLを綺麗に見せたいとか、そういった背景がありそうだなと。もし上場企業に転職を考えていらっしゃる方がいたら、上手く費用計上してソフトウェア資産が計上されていないところがいいかもしれない。

山田：
エンジニアユーザーとお金のことを話していると、メーカーのソフトウェアエンジニアを増やすことはコストアップだと言われるらしいんですね。なぜかというと、設備投資の概念が強いので、例えば工場を作るのは資産計上できるけれども、ソフトウェアの社員を増やすとPLにヒットしますと。そう言われて、ソフトウェア開発が進まないと思い転職を考えているという話を聞いたことがあります。

企業として、エンジニアから選ばれるために、どのような環境を作ればいいのか？

山田：
続いて、エンジニアにとって働きやすい環境を作っていくにあたって、どのような取り組みをしているかを教えていただけますか？

澤：
小さなことで言えば、率先してラフな格好をするようにしていますね。

山田：
先日オフィスに行ったんですけど、他のフロアはみんなスーツなのに、エンジニア部隊だけはTシャツでしたね。

澤：
僕が入社した時もみんなスーツで、その時から制度は別に変わっていないんですけど、僕がこうしていることで後から入ってくる人も「スーツを着なくていいんだ」と思ってもらえれば。今はそういう人が増えてきたので、偉い人も他部署の人も特に言わなくなりましたし、ちょっとした貢献はできたのかなと思います。

あとは、例えばMacを買う時に低スペックなものを選ばなくていいように、毎年予算計上する際には、その時のフルスペックが買えるくらいにしたりとか、技術選定にあたっても我々はわりと攻めて、できるだけ新しい技術を使うようにしていたりするところも、働きやすさを構築しているかなと。

山田：
齋藤さんはいかがでしょうか。

齋藤：
うちもフレックスやリモートワークなどいろいろな制度を取り入れていますけど、それを求人票やWantedlyなどの媒体に全部書くようにして、いいと思う人は来てくださいと。なるべくミスマッチをなくすために、面接に来てもらった人にも「こういう意志で、こういう制度でやっています」と全部説明しています。

あとは、心理的安全性とよく言われていると思うんですけど、自立的な組織を作っていきたいので、できるだけ指示と取られないような形にしたいと思っていて。ただ、私がエンジニアやデザイナーの上長なので、評価の権限を持っている以上は難しい部分があります。

経営学の本なんかでも、いわゆるメリハリのある評価は組織の生産性を下げると書いてあったりしますし、一般的なMBOによる評価制度は時間が掛かりすぎるので辞めましょうと。よっぽど1年間何のコードも書いてないとか、もしくはものすごい貢献をしたとかでなければ、基本的に評価せず一律に上がっていくような形に、うちのチームだけ評価制度を変えさせてもらいました。

なので、気に入らないことがあったら、私に全然言ってくれと。それで評価を下げることはないし、もし何か直して欲しいところがあれば、週次でやっている1on1で伝えるので、そこでフィードバックとして受け取って欲しいと伝えています。このやり方も、ちょっと見直してもいいかもとは思っているんですけど。

なるべくエンジニアが業務そのものに集中できるように、私がもし間違ったことを言ったり、働きにくい環境を作るようなことがあったりしても、それを正せるような環境を作りたいと考えて、そういった取り組みをしています。

山田：
先進的な取り組みをされていらっしゃる感じですね。

齋藤：
先進的というか、乱暴というか（笑）。

山田：
最近では外資系の企業などで、ノーレーティングが流行っていたりしますからね。広木さんは、まさにDXとデベロッパーエクスペリエンスが表裏だということも書かれていますけど、どんな風に考えられていますか？

広木：
デベロッパーエクスペリエンスの話をする時に、「甘やかすとハッピーなんでしょ？」みたいな捉え方をされてしまうと、結構ズレてくるなと思っています。結局は、いかに理不尽で不透明な要素を排除していくかだと思うんですね。

生産性を上げるために必要なことを選んでいく必要があって、その文化的習慣というものを、いかに取り入れていくかが重要なのかなと思います。それを働きやすさの勘所が分からない人がやると、単に甘やかして逆に生産性が下がる方向にいってしまう可能性がある。

そうではなく、より明確にコミュニケーションしていく方向へ、例えばデベロッパーあたりのデプロイの回数を見えるようにして、どのくらいのスピードでサービスがデプロイされているか可視化したり、チャットの中のプライベートメッセージの割合をどんどん減らしていくようにしたりとか。

ある程度の方向感を持って、透明性やスムーズなデプロイといったところにコミットしていった方が、エンジニアにとって働きやすい環境になっていくのかなと思いますね。

イベント来場者からの質問に答えるQ＆A

山田：
会場からの質問にも答えていきたいと思います。「内製化はどのくらいの比率が適正なのか」という質問がありますが、澤さんところは1対1くらいでしたよね。

澤：
そうですね、1対1くらい。

山田：
それは将来的には、どうしていく方向なんでしょう。全部内製にしていくのか、とか。

澤：
僕はできるだけ内製の方が良いと思いますけど、人によって好みもあると思うんですよね。僕の中で大事だと思っていることは、社員がモチベーション高く開発が続けられるかどうかで、それによって選んでしまってもいいんじゃないかなと。

山田：
エンジニアがモチベーションを感じるのってどういうところだと思われますか？　求人でも、エンジニアではない人に刺さる文面を、エンジニアに送ってもほぼ返信がなかったり。モチベーションの源泉がかなり違う感じはします。

澤：
やりがいを感じられるかだと思います。携わっているサービスで、自分が加えた変更でお客さんから反応がもらえるとか、ないしは事業に貢献できるとか。やっぱり自分の書いたコードの影響範囲が広くなることに、魅力を感じたりするんじゃないかなと。

山田：
まさにスカウト文面の反応を見ていると、どんなサービス規模なのか、どのくらいの人に影響を与えるのか、社会のどんな課題を解決しているのか、といった内容が刺さる。逆に、投資金額がこのくらい、売り上げの目標はこれくらい、みたいな話は刺さらないというのは、データとして出てきています。他に、会場からの面白そうな質問はありますか？

澤：
「エンジニアが増えても企画側の既存社員が旧態依然のままデジタル化できていなければ、デジタルトランスフォーメーションが続かない気がするのですが、どう対峙してきたか、どう乗り越えてきたか事例を教えて頂きたいです」という質問がありますね。

齋藤：
やるべきなんですけど、今の会社だとあまり説得していないですね。やっぱりカルチャーが全然違っていて、ほぼ別会社のような感じになっているので。社内ベンチャー的な位置づけではあるんですけど、やっぱり良くないと思っているんですよね。

今回はスピードを重視してリリースするという会社としてのミッションを優先させたわけですけど、やっぱり1つの会社ではあるので、いろいろと協力しないといけないと思っています。

まずはいろんなツールを入れて、これだけ業務がやりやすくなったというのを理解していただいて。ただ、やっぱりすぐには変わらないなというのが、現状での印象です。まだ今の環境では成功体験を持っていないので、何かあったらぜひ教えていただきたいなと。

山田：
ありがとうございます。時間がきているので、またこの後の懇親会で。ぜひ単刀直入に聞いてみて頂ければなと思います。