CTOインタビュー「全てを設計してから作る」ボーダーレスな開発を支える哲学(2/3)

10/11に公開したCTO Ethanのインタビュー、今回は創業から今に至るための業界の変化や開発組織の変化、Ethanの開発哲学に関して掲載します。

MODE創業以来、一番大変だったことは何ですか？

Ethan：過去だけではなく現在も、事業をスケーラブルにするために適切なビジネスモデルを見出すチャレンジは続いています。技術を有し、顧客の要望に対応できた上で、再現性をもって収益を挙げ、それを維持していくことが必要です。その一端が、プロダクトマーケットフィット、要するに製品が市場に受け入れられる状態を見出すことです。顧客が求める商品を構築し続けることで、顧客が気に入り、もっと買ってくれるようになる。それと同時に、社員が製品を維持し、顧客に満足してもらう。こうした好循環を生み出したいのです。

MODEはこうした目標の達成に向けて今も挑戦を続けている状況にあると思います。どの会社も完全に達成できることはないですが、最も成功している会社は８-９割は達成できているのが普通です。

MODEが創業してから8年が経ちました。この間にIoT業界はどのように変化しましたか？

Ethan：大きく成熟したと思います。IoTははじめ、基本的には問題発見のためのソリューションでしたが、どのように、そして何のためにIoTを使用するかという、はるかに進展したユースケースへと変化しました。それが最大の変化です。

技術的な観点からは、実際のところ、期待値はより合理的で到達可能なレベルへと下がってきています。魔法が起こるわけではありません。データを確実にクラウドに格納しようとするというだけです。その後、やがて魔法が起こります。

魔法は、ソフトウェアやクラウドの中にあります。一方でハードウェア側は今も進化を続けています。８年前、多くのハードウェアはIoTに対応できていませんでした。特に、コネクテッドデバイスは、Wi-Fiに繋げることはできても、数日後にはクラッシュしていたでしょう。その多くはハッキングされやすいものでした。業界の状況としては、すばらしいWi-Fiなどないのが普通だったので、実用的ではありませんでした。

今の業界の状況では、もっと信頼性の高い情報収集の方法があると思います。それでも、ハードウェア面で目指すところまで到達するには、業界全体として進化を続ける必要があると考えています。今はまだ３分の１程度かもしれません。その間も、クラウドサイドのソフトウェア部分の改善を続けることができます。しかし、ユースケースによっては、ハードウェア面で釣り合いが取れるまでは壁に突き当たることもあるでしょう。

IoT業界の変化に合わせ、MODEの開発組織はどのように成長してきたのでしょうか？

Ethan：MODEは当初、ホームオートメーションのような消費者向けソリューションを主に扱うIoTメーカーと提携しようとしました。つまりホームオートメーション商品を作っている他社のベンダーになろうとしていたんです。

でも、IoT業界は、企業向けのデータ収集にシフトするようになっていきました。それでMODEの製品もこうした顧客に対応するものへと再び方向性を変えました。そうなるとチームも変わっていく必要があります。こうした理由から、MODEには導入支援を行うエンタープライズソリューションチームがあります。当然、組織として企業顧客からの機能追加に関する要望や需要に対応できることが必要です。

開発チームのカルチャーや雰囲気についてどのようにお考えですか？

Ethan：主に言えるのは、コラボレーションや助け合いを重視していることだと思います。エンジニアが業務を割り当てられた時、自分一人で完了させなければと思うことがあってはなりません。同僚からアドバイスやフィードバックを求めるよう、促しています。同僚によるコードやデザインのレビューは、MODEの開発プロセスの重要な部分です。

コラボレーション重視のカルチャーは、知識の積極的な共有にもつながります。開発チームでは常に新たな技術や構想を互いに教え合っていますし、エンジニアとして向上し、一層の問題解決ができるよう、助け合っています。

このカルチャーは、ともにチームを作っていく中で自然と組織的に生まれてきたものです。時が経つにつれて、こうした仲間意識が醸成された感じです。そしてもちろん、チームを成長させ続けるには、これを維持していきたいと強く思っています。

技術的な観点で、他社と比べてMODEに特有の難しさはありますか？

Ethan：僕たちは、あらゆるタイプの業界や消費者のユースケースに対応する、より汎用的なソリューションを作ろうとしています。各顧客へのカスタマイズを最小限にしようとしています。全ての人に価値のある、汎用的で有効な製品を効率的に生み出すのは難しいことです。

MODEのエンジニアにはどういった方が多いですか？共通点を伺えますか？

Ethan：MODEの中核には、非常に優秀で経験豊富なエンジニアたちがいます。そして、熱心に学ぶ意欲を持ち、挑戦する気概のある、ジュニアエンジニアも何人かいます。

彼らには二つの共通点があります。まず、彼らは互いに助け合うための時間と努力を惜しみません。彼らは互いに知識を共有し合うことを楽しんでいます。要は、チームの仲間も向上させたい、ということです。

もう一つは、問題解決への姿勢です。彼らは、問題の発生理由や解決策を見出し、前進を続けるのを止めることはありません。才能や経験もあるでしょうが、仕事にプライドを持っているからでもあります。

エンジニアからは「Ethanは全てを設計してから作る」のが哲学だと聞いたことがあります。そのようになったのはいつからですか？また、なぜそれが重要だと思いますか？

Ethan：そうですね、それは事実です。ここ数年、それを強く打ち出しています。ソフトウェアエンジニアはタスクを割り当てられるとすぐにコードを書き始めたくなるものだとわかってはいますが、それにあらがって構想をまとめて書き留める時間を取るよう、彼らに促しています。

これは東京チームを作った時から始まったのだと思います。時差と言葉の障壁があるのは明らかで、対面ミーティングで彼らの思いをしっかりと知る機会を得られないことも多いです。だから僕はチームにこう伝えました。「もし何かを作るなら、まずは何を作るのかしっかりと考え、設計を書き留めておくべきだ」と。

これには二つのメリットがあります。一つは、他のチームメンバーにより明確に自分の考えを伝えられ、相手にフィードバックする機会ができるということです。チームでコラボレーションし、互いにより良い仕事ができるよう助け合う、という哲学にも立ち返ります。

もう一つは、将来の自分が参考にできる記録が残るということです。2年後には、ある設計に決めた理由を自分でも忘れているかもしれませんが、設計文書で再び見ることができます。また、新しいエンジニアが入社したとき、ある決定がなされた理由を実際に知ることができます。こうした知識が失われるのは、チームにとって大きな損失です。

やがて僕は、設計を書き留めるプロセスが構想を明確化する助けにもなると気づきました。設計を書き終えるまでに、いくつかの穴を見つけ、すぐに修正したケースも多くありました。