ファームウェアエンジニアの中林 (id:tomo-wait-for-it-yuki) です。 先日発売された「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」をNature Library1の制度で読んでいたところ、個人的に大きな発見がありました。特に、今までなんとなくもやっとしていたファームウェアチームの立ち位置が腑に落ちました。
要点としては、ファームウェアチームはストリームアラインドチームではなく、プラットフォームチームだった！の一点に尽きるのですが、この気付きに至るまでの自分の葛藤 (と呼べるほどのことでもないのですが) など含めて紹介したいと思います。
「チームトポロジー」については、翻訳者のみなさまが様々情報発信されていますので、ぜひ本や下のリンクにある発表資料を読んでみたり、fukabori.fmを聞いたりしてみてください。
Natureにおけるファームウェアチームの立ち位置
ユーザーの手元に届くデバイス (Nature Remo) に搭載するソフトウェアを開発するチームなのですが、最終的にユーザーに価値を提供するのはモバイルアプリやサーバーがメインです。 Nature Remoのファームウェアは (基本的に) 直接ユーザーに価値を提供するレイヤーではないのです*1。 Web技術に詳しい少数のソフトウェアエンジニアがNature Remoを開発してきたので、デバイスは機能を減らし土管のように扱うことで拡張性と速度とを得ていた経緯があります。
私が入社したのがNature Remo3発売後で、Nature Remo mini2の開発も大筋が終わっている時期でした。 そのため、入社後はNature Remoの安定性を向上したり、Remoで問題が発生したときにすばやく察知できるようなHealth Check機能を開発していました。 Nature Remoの安定性向上は重要と認識しつつ、ユーザーの手元に届くNature Remoで動くソフトウェアを開発しているのに、直接的な価値を提供できていないことに、少し戸惑い、というか、「これで良いのかな？」と感じることもありました。
特に2022年1月からは、「既存Remo」チームとして、モバイルアプリエンジニアの亀田さんやアルノさんと同じチームで活動し始めたことから、さらに「これで良いのかな？」感が増えていきます*2。 名目上同じチームですが、モバイルアプリではEVPS機能のリリースやデザインリニューアル、細かいユーザー体験向上施策で着実にユーザーに価値を提供していました。 私自身は独立したタスクを個別にこなしており、直接的な価値をユーザーに届けられていなかったので、そのことがギャップを大きくしていました。
突き詰めると、「Natureのファームウェアチームは何をするチームなのか？」という問いに対して、自分自身が明確な答えを持てていなかったわけです。
チームトポロジー読み始め
NatureにはNature libraryという本の購入制度があります。 ちょうど次は何を読もうかな、と考えていたときに「チームトポロジー」が目に入り、Nature libaryで読んでみよう！となったのがきっかけでした。
チームトポロジーはコンウェイの法則をうまく利用し、逆コンウェイ戦略をうまくやろう、という趣旨の内容です。逆コンウェイ戦略がなぜ重要か、をパート1で問いており、パート2以降は逆コンウェイ戦略を実践するためのプラクティスが述べられています。
その中でパート2では、4つの基本的なチームタイプが紹介されています。
- ストリームアラインドチーム
- イネイブリングチーム
- コンプリケイティッド・サブシステムチーム
- プラットフォームチーム
パート2を読んだとき、Nature Remoのチームトポロジーを次のように考えていました。図は「チームトポロジー」内の記法を用いています。
ストリームアラインドチームはユーザーに価値を届けるチームです。 サーバー、モバイルアプリ、ファームウェアでNature Remoのサービスを提供しているので、まあこうでしょう、という感じでした。
プラットフォームチームはストリームアラインドチームが自律的にユーザーに価値を提供できるようにするチームです。 内部サービスを提供し、ストリームアラインドチームに下位のサービスを意識せずに済むようにします。 プラットフォームチームに属するのはSREのイメージで、サーバーと密接にコミュニケーションしている状態を表しています。
コンプリケイティッド・サブシステムチームは複雑なサブシステムを扱うチームで、Nature Remoで扱う赤外線データのDBであるIRDBがこれにあたると考えました。
現状だとイネイブリングチームは明確には居ない状態です。
チームトポロジーChapter6での転機
そのままチームトポロジーを読み進めていましたが、Chapter6「チームファーストな境界を決める」で組込みチームがいる場合の実例が掲載されています。 ここで、2つの選択肢があると述べられています。
1つはクラウドをプラットフォームとして、モバイルアプリと組込みIoTとがプラットフォームのクライアントとなるケースです。 こちらは、すぐにNature Remoのアーキテクチャにそぐわないと思いました。
では、もう1つの選択肢はどうかというと、組込みIoTをプラットフォームとして扱い、クラウドとモバイルアプリはそのクライアントとなるケースです。 これを見た瞬間、「これだ！」という直感がありました。
Nature Remoのファームウェアはプラットフォームで、サーバーとモバイルアプリに内部サービスを提供しているんだ！
という納得です。 まさしくファームウェアチームのフォーカスすべきことは、Nature Remoを安定させて、サーバーとモバイルアプリが価値を提供しやすい環境を整え、全体のサービスとして価値を向上する、という点だったのです。 ストリームアラインドチーム (サーバーやモバイルアプリ) と密接にコラボレーションし、ユーザービリティや信頼性など、そのニーズを満たします。
そう、私はサーバーチームやモバイルアプリチームに安定したIR Blaster*3 as a Serviceを提供するために存在していたのです！
もちろん、これは「現時点で」というだけで、今後、会社やファームウェアチームの規模が大きくなるにつれて移り変わっていくものと考えています。
Natureでやりたかったこと
ここからは自分語りなのですが、Natureの面接を受けたときに、次のように言ったのを良く覚えています。
「プラットフォームを提供する仕事がしたい。」
これは、もともと私がエンドユーザーに機能を提供するレイヤより、低レイヤ技術を始めとしたプラットフォーム寄りの技術に強い興味を抱いているためです。 面接では、技術的なレイヤというより、社会のプラットフォームになりうる製品を作りたい、というコンテキストでしたが。 うろ覚えですが、面接担当者だった亀田さんか北原さんに、「あまり低レイヤな仕事はないけど…」みたいな話をされたような気もします。
ではこの1年半、「プラットフォームを提供する仕事がしたい。」という私の欲求は満たされていなかったのでしょうか？
お気づきかもしれませんが、意外とそういうわけではありませんでした。 「チームトポロジー」を読むまで気づいていなかったのですが、ずっとモバイルアプリチームやクラウドチームに対して、プラットフォームを提供する仕事をしていたのです！ すなわち、ずっと自分のやりたいことを仕事としてできていたわけです。自覚はなかったですが！ この気づきは、低レイヤ技術にこだわらなくてもプラットフォームを提供する仕事ができる、という救いを私に与えたわけです*4。
こうして、1年半越しのフラグが見事に回収されていきました。 現在のNatureのチームトポロジーでは、ファームウェアチームはプラットフォームチームと考える方がしっくり来ます。 それが明確になったから、といって急にファームウェアチームの仕事が変わるわけではありません。 しかに、何にフォーカスするべきか、コミュニケーション方法をどうするか、など改善の1つの道筋が見えたのは「チームトポロジー」を読んだおかけです。
「チームトポロジー」は組織設計の分析や戦略を立案する上で、重要な視点を提供してくれる本だと感じました。
Nature Libraryの仕組みがなければこのタイミングでは読んでなかったと思うので、会社の制度にも感謝です。 私が入社した1年半前と比較しても、福利厚生が整い、格段に働きやすい環境になっています。 リニューアルした福利厚生については、下記noteをご参照ください。
エンジニア積極採用中です
Natureでは価値あるソフトウェアをすばやく届ける適応型組織設計に興味ある仲間を募集しています。
カジュアル面談も歓迎なので、ぜひお申し込みください。
