「組織づくりもモノづくり」SpeeeのVPoEが実践する組織のエンジニアリング

（※本記事掲載の情報は、公開日となる2020年10月14日時点のものです。）

2020年7月、JASDAQ（スタンダード）へ上場を果たし、ますます成長を加速させる株式会社Speee。本日は、同社で専門執行役員 VP of Engineeringを務める大場氏に、現在に至るまでのキャリアや、Speeeのエンジニア組織構築について話を伺いました。

株式会社Speeeについて

Speeeは、「解き尽くす。未来を引きよせる。」をミッションに、テクノロジーとビジネスオペレーションのかけ合わせを核に、複数の事業を展開しています。

一言であらわすと、データドリブンな事業開発の連鎖でデジタルトランスフォーメーション（DX）を推進する企業です。

大きく2つの領域で事業を展開しています。1つ目は、Martech事業領域です。ここでは、データを活用したマーケティングコンサルティング、機械学習を使用した広告配信プラットフォームや広告の分析・管理プラットフォームなど、総合的にデジタルマーケティングのソリューションを提供しています。

2つ目は、X-tech事業領域です。ここでは、あまりデジタルが活用されていない不動産や住宅リフォームなどのリアル産業に対して、テクノロジーを導入していくことでバリューチェーン全体のDX化を目指しています。

その他、弊社のビジネスR＆D領域では様々な新しい事業を生み出しており、最近は、ブロックチェーンを活用した事業やヘルスケア事業の企画を進行中です。

このように我々は、新しい事業やサービスを連鎖的に生み出すことで、来たるべき未来を少しでも早く実現していくことを目指しています。

小学生の頃からプログラム一筋！そのままエンジニアに

小学生の頃の話に遡りますが、まだ一般的に家庭用パソコンが普及していない時代だったので、初めてプログラムに触れたのは当時のアスキーとマイクロソフトが仕様を規格化した８ビットコンピュータのMSXでした。当時、色々な雑誌にMSX用のゲームのプログラムが載っていて、そのBASICで書かれたプログラムをMSXへ打ち込むとゲームができたのです。

私の家庭ではMSXを買ってもらえなかったため、友人の家に行ってはプログラムを打ち、それをノートにメモして、次の日また１から打ち込むという風にして遊んでいましたね。1文字でも間違えるとゲームが動かないので、四苦八苦する場面もありましたが、楽しみながらやっていました。

それから中学生に上がると、パソコン通信というインターネットの前身のようなものが世の中に普及しました。それも友人の家で使わせていただいていたのですが、通信料がとても高くなってしまい非常に怒られたという苦い思い出があります（笑）それ以降は、通信料が定額になる時間帯を狙い、夜の遅い時間帯までその友人の家に入り浸っていたのでさらに迷惑だったと思います（笑）

昔から、LEGOなどブロック遊びが好きな少年でした。それから学研のマンガでプログラムを知り、「プログラムってこんなに簡単にできるんだ。これなら自分にもできるじゃん」と思って始めたんです。こういう思い込みによる自己肯定感は大事ですよね（笑）今でもモノづくりの原動力になっていると思います。

また、プログラムをする過程で、プレイヤーとしてゲームをやっているだけだと”死んだら終わり”である一方、ゲームを作っている側の人間は、ゲームオーバーの画面を表示したり各種パラメータを初期化してタイトルに戻すなどの”死んだ後の処理”まで考える必要があることに気づきました。中学生ながら、「作る側の人間は全体を破綻なく構築する仕組み（今で言うところの、エコシステム）を作っているんだ」と感心したことを覚えています。

当時は、「プログラムさえ書ければなんでも良い」と思っていたので、高校卒業後の進路は、地元仙台のプログラミング専門学校を選びました。通学に往復2時間程かかったため、その時間を利用して、今後学んでおいた方が良さそうだと思うプログラミング（C＋＋／オブジェクト指向など）を独学で学んでいましたね。

卒業後は、パッケージソフトを作る小さいソフトハウスへ就職しましたが、実際は、顧客ごとにカスタマイズしたシステムを作っている会社だったので、給料も安く長時間労働でした。今でいうブラック企業ですが、そこには6年程在籍していました（笑）

それから、受託の案件で出向した時、その案件のプロジェクトリーダーを伊藤忠テクノソリューションズ（以下、CTC）の方が務めていて、半年～1年くらい一緒に仕事をしました。その出会いがきっかけで、2001年、CTCへ入社しました。

大手SIer時代。RubyのOSS活動にも注力し、活動の幅を広げた

Javaを使った受託開発の仕事に携わっていました。前職は、人数が少なかったため、営業同行、要件定義、設計、開発、テスト、納品のユーザートレーニングや障害時の対応など何でも一人でやらなければいけませんでした。一方で、CTCの場合は、役割が機能的に分かれていたので分かり易かったですし、非常に楽しく仕事ができました。

同時に、好きなプログラミングの話しができる仲間を求めてオープンソースのコミュニティにも参加しました。当時、自分が携わっていたプロジェクトでは、開発に関わる情報共有をどのように行うか、という点に課題があったのですのが、Wikiが使えるのではないかと考え、Rubyで実装されたRWikiサーバーを立てて情報管理に活用しました。チーム内から上がってくる要望をRWiki pluginを書いてカスタマイズしていくうちに楽しくなってきて、のめり込んでいきました。

OSSのコミュニティは、本当にプログラムを書くことが好きな人達が集まっているので、技術的なことにフォーカスして話すだけでも楽しいと思います。加えて、これらは技術をアウトプットする機会になりますし、活動を通してアウトプット自体も磨かれていくので、エンジニアがキャリアを積み上げるうえでは非常に有効だと思います。

CTCには10年ほど在籍し、色々なことを経験させてもらうことができ、非常に良い会社だと思っています。そのためCTCが云々というより、受託開発という業界の構造に限界を感じたというのが転職を決意した理由です。

受託の場合は、本当の意味での0→1は経験出来ませんし、作った後の改善も出来ません。WEBプログラムの開発において改善サイクルを回していく経験は、エンジニアとして技術的に成長していくうえでとても重要な要素だと思っています。そのため、開発だけでなくリリースして検証し、改善を積み重ねる経験のできるWEBの事業会社を視野にいれて転職活動を行いました。

SI→事業会社へ。成長ベンチャー企業のインフラ整備に貢献

WEBの事業会社を中心に何社か受けたのですが、グリーの面接がすごく面白かったんです。選考のなかで各部門のリーダーが、自分の仕事はここまでといった線を引いたりせずに課題に対して部門の垣根なく仕事をされていることが伺えました。当時のグリーは従業員が1000名ほどで、まさに成長中の組織でしたが、このような完成形が見えないいわゆるカオスな会社の方が貢献できる余地が大きいと思い入社を決めました。

グリーで私が求められていたことは、サービスの１つに関わるというより、グリーの中のエンジニアが、より活躍できるような環境を作っていくということでした。所謂、横断的に技術の知見を普及させることで、今で言うところのDeveloper ExperienceのDXを改善する役割です。GitHub Enterpriseの導入からCI/CD、デプロイメントパイプライの改善、その他、直接プロダクト開発に関わる業務でなくともその周辺にある課題であればなんでも取り組んでいました。

成長中のベンチャーに参画するだけではなく、いつか自分もベンチャーを黎明期から作っていくチャレンジをしたい、と思っていました。そんな折、先輩社員が「転職先探している時に、Rubyでいい会社見つけてみたから、大場さん受けてみたら？」と声をかけてくれました。それがクラウドワークスでした。当時のクラウドワークスの従業員数は10人強、エンジニアとしては4人目だったので、ここなら１からエンジニア組織を作ることに携われると思い、入社を決めました。

Speeeへ参画。エンジニア組織を強化するまで

クラウドワークスでは、後半、技術から離れた役割であったこともあり、また技術の力で事業に貢献できる仕事をしたいと思うようになりました。

その中でSpeeeは、ネットに留まらずリアルな産業に対してテクノロジーの活用を本気で目指していましたし、経営メンバーと話をする中でこの会社へ貢献していきたい、と思えたので入社を決めました。

Speeeは、もともとコンサルティング事業から出発した会社です。そこからプロダクトを作る会社になろうチャレンジとしていたのですが、過去に何度かプロダクト作りに失敗をしています。何故なら、コンサルティングのゴールから逆算して可能なかぎり課題を洗い出し精緻に分析にして不確定要素をつぶしていくやり方と、そもそも不確定なものがあることを受け入れて漸進的に開発を進めていくプロダクト作りとでは、大きく異なるので、その違いを認識せずに混ぜた状態だとうまくいかないんですね。入社当時のSpeeeは、そういった失敗から学び、少しづつ改善を重ねて中には大きく成長するプロダクトの芽がでている状態でした。

一方で、組織体制にはまだ課題がありました。職種ごとにチームが分かれていたため、職種間の連携が薄く、プロダクトチームとエンジニアチームの間で連携が上手くとれていませんでした。それ故に、エンジニアは、プロダクトチームの考える企画を待つだけの受け身の状態になっていました。

こうなってしまう要因は、職種間で会話が生まれにくくなっていることだと思い、職種ごとに分かれていた座席をプロダクト毎にまとめたり、OKRの導入やKPTなどのプラクティスの導入など、本当に色々やりましたね。

当時は私が自分でメンバーを巻き込んでKPTを主催していたので、社内では「KPTおじさん」だと思われてました（笑）

また、組織図上も職種の役割をあいまいにすることで、お互いの領域を超えながらプロダクトチームが１つのチームとして自律的に動けるよう仕組みを変えていきました。

開発チームの採用方針としては、裁量が大きい自己組織化したチームの中で活躍できる人材を採用するようにしています。

しかし、課題に上がるのは、新卒の採用です。何しろ弊社は事業の成長速度が早いので常に人は足らない状態ですが、ドメイン知識や事業の特性の理解などベテランエンジニアでないと突破が難しい局面も多く、ジュニアのメンバーをフォローする余剰を生み出すことができず、組織の受け入れが十分にできないという理由から、新卒採用を止めるという意思決定を4年前にしました。

それからの4年間で、事業と組織を両輪で強化してきました。まだまだ未完成な組織ですが、それも含めて楽しめる仲間も揃い、今年から改めて新卒採用をスタートしました。多様な視点や価値観の中で相互に刺激を受けて成長してもらうことで、少しずつ自走できる組織を目指していきたいと思っています。

VPoEが思うSpeeeの現在と今後

メンバーの目標設定や育成が5割、中途と新卒の採用が4割、技術戦略の立案推進が1割です。目標設定については、もともと個別クローズに実施していたものをGitHubでメンバーにオープンに共有して型化しました。みんなエンジニアなのでGitHubに非常に馴染んでいるのもあり、プログラミングを書くように目標を書けて振り返り、改善できたらよいだろうと思いまして。今のところ、まだまだプログラムと同じようにレビューし合うところまでは至っていませんが、徐々に整ってきたように思います。

その他、インフラやSREといったバックエンドエンジニアの評価ですが、プロダクト開発とは異なり、事業への貢献度が目に見えづらいという話はよく聞きます。しかし私は、インフラのようにコンピュータシステムのレイヤーが低くなればなるほど、数値として可視化できるポイントが多くなるので、「この半期で××%改善する」というように定量的に取れる数字を事業への貢献をするための目的に落とし込むよう工夫しています。

私は、コードを書くこと（＝モノづくり）が好きですが、「組織作りもモノづくり」の一つだと捉えています。エンジニアの中では、コンウェイの法則という考え方があります。その中では、アーキテクチャーの構造が組織に反映されていくという話がなされていますが、私はその逆も然りと思っています。組織の方をよりよく変えていくと、システムアーキテクチャもよりよくなっていく、表裏一体で繋がっていると思うんです。

現代は、私たちが小さい頃に思い描いていた「インターネットやデジタルだけで完結する世界」ではなくなってきています。流行りの言葉としてDXというとワードがありますが、いわゆるオンラインの先にあるリアルワールドの営みを構造化し、仕組み化することがエンジニアリングに求められていると強く感じます。

シンプルに考え、抽象化できてもどこかにほころびが現れ矛盾を生み出します。そこで、複雑なことを複雑なまま受け入れて解決するのには、テクノロジーの活用が不可欠だと思っています。

幸い、SpeeeはそのようなDXの社会実装を専門にしているので、私はそこのVPoEとしてエンジニアの成長に貢献し、何年先でも求められる、そんな人材を輩出し続けられるよう頑張りたいです。