プラットフォームチームからデリバリーチームへ。MODEのIoT技術を支えるフルスタックエンジニア

MODEは、AI-driven IoTソリューション「BizStack」を通じて、製造、建設、物流現場のデジタルトランスフォーメーション（DX）を推進しています。現在、社員は日本とアメリカを拠点に50名以上が活躍し、多様な視点とスキルを活かして企業の成長を支えています。

今回は、ソリューションエンジニアとしてデリバリーチームに所属する高松 真平さんに、現在の業務やMODEのエンジニアリングカルチャーについて伺いました。

MODEを選んだのは未経験の業務に挑戦できそうだったから

― まず、これまでの経歴とMODEに転職したきっかけについて教えてください。

高松：社会人になってからずっとソフトウェアエンジニアとして働いてます。新卒では日系SIer（システムインテグレーター）のSEとしてスタートしたんですけど、キャリアの半分くらいはベンチャーやスタートアップで、ソフトウェアエンジニアをしてます。

コードを書いてプロダクトを作るのが好きで、クライアントワークやマネージメント寄りの仕事をしながらも、基本的にはずっとソフトウェア開発に携わっています。

前職では、たまたま関わったプロジェクトでMODEのプロダクトを知りました。それとは別に、ガソリンスタンドの洗車機をIoT化するプロジェクトにも関わり、そこで少しだけIoTの経験を積みました。

その後、転職を考え始めた時期に、LinkedInでMDOEから声をかけてもらったのが最初の接点です。カジュアル面談でエンジニアと話す機会があり、その時にIoTのプラットフォーム開発という挑戦が、エンジニア的に面白そうだと思ったんですよね。

プラットフォームは、様々なケースに対応する抽象的な設計が必要です。現実のモノを扱う難しさとやりがいがあると感じました。

MODEへの転職の決め手は、やったことのないことが一番多そうだったからですね。IoTやプラットフォーム開発はもちろん、グローバル対応のプロダクト開発にも挑戦できるのが面白そうだと思いました。

他のオファーは、すでに経験したことが多くて、何をするかが想像できてしまいましたが、MODEでは未知の領域が広がっていて、それが一番の決め手でした。

今は「お客様の要求を満たす」のが仕事

― 現在の業務であるデリバリーチームでの仕事について教えてください。

高松：デリバリーチームには、ソリューションアーキテクトとソリューションエンジニアがいます。ソリューションアーキテクトは主にプリセールスで、受注に至っていない案件に対応します。一方、契約後や継続的にお付き合いしているお客様から新たな要望をいただいた場合には、ソフトウェアエンジニアやソリューションエンジニアが関わります。

お客様はシステム開発社ではないので「システム的にこうしたい」みたいなことは、クリアには言えません。なのでお客様が何をしたいのか、要求を深堀って整理して、それを作り上げてサービスインしています。

一般的なSIerとの違いは、私たちの仕事が「お客様の要求を満たす」ことに重点を置いている点です。その方法はいくつかあります。

一つは、プロダクトチームと協力して進める方法です。お客様の要望を聞き、プロダクト開発チームに依頼します。例えば「この機能が足りないから追加してほしい」と依頼する形です。

ただし、プロダクトチームには彼らのポリシーというか、開発方針や優先事項があるので、そこから外れる要望は、そのまま受け入れられるわけではありません。

また、プラットフォームは汎用性を考慮しなければならないので、最終的に提供されるものが、当初の依頼とは少し異なる仕様になることもあります。そのため、デリバリーチームは顧客の要求と、プロダクトチームが作るものとの間にあるギャップを埋める役割を担っています。例えば、技術的な要求をプロダクトのエンジニアがわかる言葉に変換してあげます。そして、途中でき上がったものに対してフィードバックをして、お客様のニーズを満たせているかを一緒に考えながら進めるイメージです。

二つ目は、デリバリーチーム内でスクワッドという数人のエンジニアでチームを組んでいるので、そのメンバーでカスタム開発をするやり方です。きっちりと計画や設計ができて、かつその人数もしっかりと確保しないとならない場合は、人を巻き込みます。

三つ目は、自分で作る方法です。あまりに要件が固まっていない場合、トライアンドエラーで、作ったものをお客様に見せて、フィードバックをもらいながら進めます。自分で要件定義しながら作るほうがマッチすることが多く、そういう場合は自分の手を動かします。

最終的にはお客様の要求を整理してデリバリーされるまでを何とかする、というのが役割なので、どうやって解決しようか、何を作って解決しようかみたいなところを考えて実行しています。

― 前職の経験で、役に立っているものはありますか？

高松：前職での経験が役立っている部分は多いです。IoTで特殊なところがあるとはいえ、エンジニアリングのベーシックな部分は基盤としてはあります。コードをいかにメンテナンスできるように書くかみたいな根底は、IoTであろうとそんなに変わらないですね。

顧客とのやり取りの経験も、思いのほか役立っていますね。今はデリバリーチームなので、エンジニアの立場として、お客様の要件・要求と、MODEのプラットフォームの機能の将来的な像みたいなものを照らし合わせて、ベストな方針を決めないといけないんです。

結構クライアント寄りの動きをすることが多いので、前職での経験でいくと、お客様と用件を詰めたり、整理したりするのが、実は一番役に立ってるかもしれない。

2024年9月5日開催 MODE CHANGEでの様子

Design Docをしっかり書くのがMODEのカルチャー

― MODEのエンジニアリングカルチャーの特徴を教えてください。

高松：MODEのエンジニアリングカルチャーの特徴の一つは「Desgin Doc（デザインドック）」をしっかり書くことが根付いている点です。これはコミュニケーションのポイントだとも思ってます。

正直なところ、MODEでは採用段階では高い英語力は求められていないと思いますが、英語でレビューをしたり、されたりすることは日常的にあります。口頭でのコミュニケーションだと、言葉がうまく出てこなかったり、技術的な話に到達する前に、話が通じなくなってしまうことがよくあります。そこで、ミーティング前にデザインドックを共有し、それを前提にディスカッションする手順を踏んでいます。相手が事前に読んで理解できるよう、デザインドック単体でも分かりやすく書いておくのがポイントですね。

MODEでは、デザインドックには、決まったフォーマットはないんですよ。新しい機能をリクエストするための書類ですが、ユースケースを必ず書くことが推奨されています。CTOのEthanがこだわってる部分で、その機能が何のために使われるかや、どのようなケースが想定されるかなどをしっかり書くことが求められています。

印象に残っているのは、デザインドックを書いて、A案からC案まで用意した時のことです。第一段階で各案のメリット・デメリットを出し切って検討したのですが、Ethanが全く別のD案を提示してきたんです。次のセッションで、ユースケースについてさらに深く議論した結果、実はD案が最も良いと落ち着いたことがありました。

作り手は、作りやすいものとか、作りがいがあるものを優先しがちです。しかし、先にユースケースを描いてから、ドキュメントだけで理解できる状態にすることがMODEのデザインドックカルチャーですね。

エンジニアを長くやってると「この問題はこうすれば解決できる」と急ぎがちなんですけど、MODEではあえて手を動かす前に、ドキュメント上で十分に検討します。そうすることで、プラットフォームの品質が高まり、長期的に運用できるものが作られていると感じます。

もう一つのMODEの特徴は、メンバーが落ち着いている点です。ディスカッションの時も、感情的になったり、自分の意見を無理に押し通したりする人はほとんどいません。成熟して落ち着いてる人が多いので、居心地は良いですね。

ただし、デザインのディスカッション系はとても活発です（笑）忖度なく、フラットにアイデアが飛び交います。当初想定しなかったオプションプランに、残りの会議時間を全部使って議論してしまうこともあります。

IoTをやってみたら、難しいところは本当に難しかった

― 入社後の印象はどうでしたか？

高松：入社して1年半が経ちますが、入社前の印象と大きな違いはありません。ただ、いざやってみると解像度が高くなるというか、難しいところは本当に難しい。現場のセンサーとハードウェアがいきなりトラブルになる体験もできました（笑）

入社後、担当業務は変化しています。最初はプラットフォームのコア部分の開発をしていましたが、最近は運用中のお客様の改修やシステム移行などの案件を担当しています。

両者で難しさは違います。プラットフォームを作るところは、設計も実装も、今までより深く考えないとなりません。CTOのEthanが全体のレビューをしますが、最初はそこでディスカッションしてアーキテクチャや設計を決めるプロセスに戸惑いました。プラットフォームが長期間運用に耐えうる品質で設計・実装する難しさは、そこで実感しました。

一方で、IoTの現場の難しさもあります。例えば、原因不明で突然センサーデータが来なくなるようなケースがあったとして、どう見ても理論上起こるはずがない。とはいえエンジニアリングなので、全く何の理由がないのはありえません。そこで別の視点からデバッグすると、問題が解決することもあります。

典型的なWebアプリケーションやモバイルだけよりも、色々なところに問題が起きる可能性があり、障害の原因調査に一番難しさを感じます。

そういったトラブルの糸口は、自分で見つけることが多いです。社内には、部分部分に詳しい人はいますが、お客様個別の運用状況を踏まえて、全ての知識を持つのは自分しかいないことは多いです。例えば、特定のセンサーで問題が発生した場合、そのセンサーのスペックシートや、ゲートウェイとの接続方法、画面上での表示方法など、幅広い知識が必要ですね。

「分割して統治せよ」というエンジニアの名言がありますが、問題を1つずつ切り分けて丁寧に解決することを心がけています。

プレゼンテーションをする高松

大雑把に１週間のタスクをこなすワークスタイル

― MODEでの働き方を教えてください。

高松：朝8時に下の子を保育園に送り、帰って来て8時半頃から仕事を始めます。17時半には迎えに行くので、基本的に8:30~17:30がワークタイムです。お迎え後、家のことが落ち着いたら、もう一度仕事に戻ることもありますが、そのまま終わることもありますね。

シリコンバレーのメンバーとの会議は、7時に始まることもありますが、もともと朝方で4時に起きるので、そこは偶然向いていたと思います（笑）

日中は、業務の3〜4割がミーティングで、社内とお客様のミーティングが半々くらいです。残りの時間は、設計や実装、レビューやデザインディスカッションなどを行っています。

出社はプロジェクトによりますね。センサーを多く扱うプロジェクトだと、オフィスに行くことが増えますが、最近は運用中のシステム移行みたいな業務が多く、出社頻度は減りました。

働き方については、細かくタスク管理をする人もいますが、僕はそんなに細かくリストを作ったりとか、優先順位をつけたりはしていません。大雑把に今週はこれを完了させようみたいな方ですね。

週の頭に目標を立て、それを大まかに消化していくイメージで仕事をしています。その方が差し込みに強いんですよ。複数の案件を同時にやってると、1日の最初に思い描いたことが終わらないことがよくあります。ある程度緩やかに、1週間単位で確実に終わらせる目標設定して、消化していく方が自分に合ってます。

書面でも口頭でも、コミュニケーションを重視

― これまでで印象に残っていることはありますか？

高松：入社してすぐに携わった「センサースキャン」機能の開発が特に印象に残っています。従来は、ゲートウェイとセンサーの接続にエンジニア必要でしたが、お客様が自分で接続できるように改善しました。

このプロジェクトは、最もプロダクト開発に注力した経験で、設計レビューの重厚さや、デザインプロセスが印象に残っています。

成果を上げるために心がけているのは、コミュニケーションです。実装を一人で行うことはあっても、1人で全てが完結するプロジェクトはありません。お客様と話して仕様を詰めるし、コードレビューがあったり、関連するチームと話をするというのもある。社内外の多くの人が関わっているので、コミュニケーションをしっかり取ることは心がけています。

― 英語でのコミュニケーションは多いですか？

高松：デリバリーチームなので、対お客様や、プロジェクトチームのメンバーと話す時は日本語が9割です。

一方、プロダクトチームと話すときは英語です。ミーティングに日本人しかいない時は日本語で話します。ただ、ミーティングノートは英語で書きますし、お客様に提出するドキュメント以外は全部英語で書きます。

最近、新たにプロジェクトが開始し、プロダクトチームにリクエストすることが多かったので、英語を使う割合は多かったです。

― 最後に、これからMODEに入社する人に向けてメッセージをお願いします。

高松：いろんなバックグラウンドや経歴の人がいると思いますが、おそらく今までやったことがないもの、例えばIoTとか英語の環境とか、それこそデザインドックの上で考えるみたいに、きっと新しいものがあるのでぜひチャレンジして欲しいです。

ユニークなポイントがある会社とプロダクトとカルチャーなので、新しいものを求められてる人がいたら、何らかの方向で見出せるんじゃないかなと思います。

技術的に難しい所だったり、エンタープライズのお客様の要件の難しさとか、色々な難しさがあります。すんなり手早く物事が進んでいくというよりは、しっかりと難しい問題を時間をかけて解くといった趣が強く、腰を据えて大きな問題に取り組むのが好きなエンジニアだったら、うまくやりたいことができると思います。