エンジニアリング、データサイエンス、ビジネスの 「一人三位一体」。 VPoPが語る、JDSCのプロダクト開発とプロダクト導入。

こんにちは！広報Kidoです。第5回目となる「CXOインタビュー数珠繋ぎ」は、執行役員であり、VPoPである木村さんの紹介です。ソフトウェアエンジニアから、データサイエンティスト、そしてデータエンジニアへと職種チェンジをして、現在はデベロップメント部門でプロダクト開発を担当している木村さん。これまでの経歴と、JDSCで働くことの魅力について語ってもらいました。

データに基づいた意思決定を行いたい。データドリブン組織のためのデータサイエンスであり、データエンジニア。

Kido:はじめに、ソフトウェアエンジニアでキャリアスタートした理由を教えてください。

いきなり消極的な話で申し訳ないのですが、そもそも私は、普通の仕事というものは向いていないというか苦手で、普通の人が出来ることが出来ないタイプなんですね。なので普通の人が出来ないことで勝負したほうが良いと思っていて、腕にスキルを付けてやっていく方がトータルで自分はハッピーだと思っていました。専門性としてソフトウェアエンジニアリングを選んだのは、子供の頃からプログラミングをしていて、これだったらいけそうだというのがあったからです。（会社の自己紹介のところにも書きましたが、小学生の頃から家にあったPCでプログラミングしていて、パソコン雑誌に自作ゲームを投稿するほどのめり込んでいました。）

Kido:子供のころから好きだったことを仕事にしたわけですが、その後データサイエンティストに職種変更したのはなぜなのですか？

「日本の」と言っていいかわからないですが、当時私や私の周囲におけるソフトウェア開発の現場では、何を作るか「決める」ということと実際に「作る」ということを別の人間が担当するということが多かったんですね。私はもちろん「作る」側の人間だったわけですが、色々な開発をやっていく中で、「決める」側の人の意思決定が属人的になってしまっているのではないかということが気になってきたんですね。それがちょうど、データを元に意思決定を行おうというようなことが流行り始めた時期だったこともあり、また、学生時代に統計をやっていたということもありで、データに基づく意思決定を実現してみたいとデータサイエンティストに転向しました。

実際にデータサイエンティストになって、「データ分析して結果を示す」というところにたどり着くまでにやらなきゃいけないところがめちゃくちゃあるなという気づきがありました。データ収集とかクレンジングとかそういうことですよね。ここはエンジニアのバックグラウンドが非常に生きて、データ分析基盤を作るというところでバリューを発揮できたし、このころの経験は今にも生きています。

一方、当初の目的であった組織をデータドリブンに変革するというのはなかなかのジャンプがあって、「そんなに簡単にはできないな」ということも分かってきました。単にデータを分析するということだけではなく、それを形になるように建付けていく、ということが必要だなと思うようになりました。

例えば、スウェーデンのデータ分析チームのビルドアップをやったことがあるのですが、彼らは当初「やりたいけれど、初めの一歩ができなくて、迷っている」、という状態だったのを、データ分析基盤の構築からKPIとダッシュボードの整備、およびそれをみんなで眺めてPDCAを回すという習慣を構築することまでできたので、それなりの成果が出せたのではと思っています。

Kido: JDSCではまたエンジニアとして入社していますが、なぜなのでしょうか？

JDSCは、今でこそデータサイエンティストとエンジニアの境界人材のような人が増えてきましたが、私が入社した当時（2年半前）は、JDSCのデータサイエンティストは機械学習色が強く、アルゴリズムを作るというのが主な領域となっていました。　JDSCで活用できそうな私のスキルセットとしては、どちらかというと機械学習の前提となるデータ収集、データ整備の方に強みがあったということで、入社時に「所属はどっちにする？」と聞かれて、エンジニア側を選んだというのが直接の理由です。

「エンジニアリング、データサイエンス、ビジネスの三位一体」を一人で実現する。

Kido:そもそもJDSCを選んだ理由はどうしてなのですか？

これ社内ではネタみたいになってるんですけど、家が近かったから（笑）。まぁ、もちろん、自分のやりたい仕事ができて、家が近かったからなんですけど。家を買う時（駅からの距離と、広さと、間取りと日当たりと、値段と・・とか）と一緒で、トータルバランスで見て決めました。やりたい仕事の条件の一つとして、「いろんな会社のデータを触ってみたい」というのがありました。自社サービスの会社にいると自社のデータしかなかなか触る機会が無くて、それだとすぐに飽きてしまうなあというのがあったからですね。

で、JDSCのフライデーナイト（金曜夜に開催しているミートアップ）にお邪魔したときに、「一騎当千人材」のコンセプトにすごく共感があるというか、私が以前から考えていたことに非常に近いなと思ったんですね。JDSCは、「エンジニアリング、データサイエンス、ビジネスの三位一体」をチームで行って、産業課題の解決にあたっていますが、それぞれの領域を別の人材が担うということは必須ではなく、むしろ複数領域に造詣のあるメンバーでチームを組んだ方が事をうまく運びやすかったりします。なので、メンバーが境界人材になることを推奨していますし、究極的には一人三位一体が出来る人材だけでチームを組めば最強の組織になれると本気で思っています。

データサイエンス業界では、「データサイエンスだけでなくて、エンジニアもビジネスも分からないといけないけど、そんな人いないよね」ということがずっと課題とされていますが、JDSCはそこを正面突破しようというスタンスで、私としても結局そこなんじゃないかと。

Kido: JDSCの仕事で何が楽しいですか？

Wodom!（データ基盤）の導入をやっているんですが、Wodom!を入れる過程というのは、色々な会社のデータを触ることそのものなんですね。まさにJDSCに入社した理由の一つですよね。

Wodom!では、導入と開発を別々のチームでやっています。開発は非常にレベルの高いエンジニアリングの領域なんですが、導入側に求められるのはそれこそ「一人三位一体」の力だったりします。お客様の経営にプロダクトを活用いただくまでの過程は、エンジニアリング、データサイエンス、ビジネスの総合格闘技だと言ってしまって良いと思います。

ゴールは「顧客がやりたいこと」を「プロダクトができること」で解決するということなんですが、当然両者にはギャップがあるので、そこを埋めるということをやらないといけません。「顧客がやりたいこと」はビジネス視点が無ければ見方を誤りますし、「プロダクトが出来ること」を深く理解するためにはエンジニアリングの素養が不可欠です。

さらにお客様のデータは千差万別で、それを一つのプロダクトで解決しようとするためにはまずはデータをきちんと理解した上で、時には技術的にかなりアクロバットなことをしないと導入に至らないということもあったりして、そこを考えて実行していくことは非常にエキサイティングだと思っています。

Kido: プロダクト側（開発チーム）に、要望を出して、開発してもらう、とうことではないのですか？

もちろん要望は出しますが、何を作るかはプロダクト側で決めます。プロダクトに何が必要で何の機能を作るかはプロダクト側が決めるということがプロダクト開発で非常に重要だと考えています。「デベロップメント部門の偉い人」としてそこを捻じ曲げるということももちろん不可能ではないのですがそれをやってしまわないということが、結果として良いプロダクトを育てることになるという哲学を持ってやっています。

ビジネスとエンジニアリングが協調するというチャレンジ。難しいからこそ、それができれば強い。

Kido: JDSCで働いていて、想像と違ったところや驚いたところはありますか？

良くも悪くも、「ビジネスとエンジニアリングの距離が思ったより遠い」ということですね。ビジネスとエンジニアリングが協調するというのは本質的に難しいことだというのは分かっているのだけど、これまでのキャリアでうまくやってきた自負がある自分から見ても、遠いなという印象があります。

例えば、私から見たら冨長さんはビジネスの人なのですが、JDSCにおいてはデベロップメントの人なんですよね。JDSCのビジネスの人というのはもっと遠くにいるようなイメージなんです。ただ同時にJDSCに入って思ったのは、オールドエコノミーの業界にガツンと入り込める人って、私から見た時に、それぐらい遠いビジネスの人じゃないとダメなんだな、ということなんですね。それだけ距離のある人と協調するというのは当然めちゃくちゃ難しいのだけど、もしそれが出来れば強いなと思ってます。

もう一つ、クライアントへの入り込み方にびっくりしました。経営層のbuy-inの取り方がすさまじいのです。DXとか、組織を変革しようとする時に一番大変なのは社内調整だと思うんですが、JDSCのコンサルはきっちりお客様のトップと握ってきているので、そこら辺をショートカットして案件を進めることができる。あと、私の以前の経験だと、色々な理由でなかなかお客様からデータがもらえずPJがスタックするというようなことがこれまで多かったのですが、JDSCのPJにおいては技術的以外の理由でデータがもらえなかったというのは私が知る限り起こったことが無いですね。

Kido: JDSCに入って得た気づきや学びは何ですか？

JDSCに入って2年くらい、エンジニアリング組織を作るということをやっていました。元々組織づくりにはそれほど興味がなかったのですが、やってみたら思いのほか楽しい。これは古来から同じことを言っている人が何万人もいる話ので、今更いうのもアレかなと思うんですけど、組織をつくるのもプロダクトをつくるのも似ているところがあるんですよね。例えば採用で、エージェントを使うとか採用サイトを作るとか、色々施策を実施しているときの頭の中は、アーキ設計しているときやライブラリ選定しているときと似ているんですよね。これは良い学びだったと思います。

日々、手を動かして、技術に追いつく。
CTOも当番制にして、2－3年でエンジニアに戻るのが理想。

Kido:他に日々、気を付けていることはありますか？

「意識を高める、技術についていく、手を動かす。」ということですね。何より技術についていくというのが大事です。組織づくりは、それはそれで楽しいですが、そればかりしていると、技術から取り残されていきます。どこかのタイミングで現場のエンジニアに戻る、ということをしないといけないと思っています。

一度マネジメントになったらずっとマネジメントやる、という意識は止めたほうが良い。両方一緒にやるのも、出来る人は出来るかもしれないですが、ハードワークが嫌いな私には無理です。なので、エンジニアリングマネージャやそれこそCTOも当番制でいいんじゃないかなと思っています。2～3年CTOをやったら交代して、現場に戻るというのはJDSCでは制度として作ろうと思っています。最近HashiCorpの創業者が現場エンジニアに戻ると言ってみんな驚いていたけれど、私は近い将来、世界中でそれがエンジニアのキャリアパスとして当たり前になると思います。

今の私の仕事で言うと、前述の通り、一人三位一体をしているので、エンジニアとしてもデータサイエンティストとしても働けていますし、プロダクト開発にも片足を突っ込んでいて、そちら側にはOSSのコミッタなどきわめて優秀なエンジニアのおかげで最新の技術をキャッチアップできているわけなので、やることはめちゃくちゃ多いですけど1プレイヤーとしてかなりハッピーな環境で働いていると思います。

Kido: 最後に、木村さんがJDSCの魅力だと思う所と、どんな方にJDSCが向いているか教えてください。

JDSCは端的に言って頭のいい人が多いので、話が早く居心地が良いと思うときが多いです。さらに、皆リーダーシップもある人なので、自己組織化したスクラムチームというのがそこかしこで実現できており、日々尊敬の念に堪えないです。

あとはやはり、繰り返しになりますがすごく長いリーチでビジネスとエンジニアが協調しているという点。異様にスキルが高いエンジニアが作った、めちゃめちゃとがったプロダクトでオールドエコノミーの産業課題を解決するというようなデリバリーパイプラインの長さは、他の企業ではちょっとまねできないのではないかなと思います。

敷居の高さを指摘されることも正直多いのですが、尖ったエンジニアの方だったり、領域横断型の人材だったりという方には活躍のオポチュニティも多いし、非常に居心地の良いカルチャーだと思いますので、どんどん入ってきていただきたいなと思っています。

Kido: ありがとうございました！

こちらを読まれた方で、少しでも興味を持った方は、ぜひお話聞きに来てくださいね。

現在の募集はこちら