シェア
はてブ
2024年6月28日、ファインディ株式会社が主催するイベント「開発生産性Conference 2024」が、開催されました。本記事では、株式会社ビットキー VP of Technologyの白木 孝典さんによるセッション「ビットキーの開発組織戦略と各チームの開発生産性向上に対する取り組み事例」の内容をお届けします。
■プロフィール
白木 孝典（しらき たかのり）
株式会社ビットキー VP of Technology
2018年にビットキーの創業メンバーとしてジョインし、ビットキーの提供するサービスの技術選定やアプリケーション開発を牽引。現在はVPoTとして、ソフトウェアからハードウェアまで多岐にわたって活動する。
ビットキーの展開する事業と、それに取り組む開発組織の体制
白木：ビットキーの白木です。よろしくお願いします。本日は、ビットキーの開発組織としての戦略と、そこから生まれた各チームの開発生産性向上に対する取り組みを、順番にご紹介していこうと思います。
白木：最初に自己紹介をします。改めまして、ビットキーでVPoTをしている白木と言います。ビットキーの創業メンバーで、創業初期にインフラやアーキテクチャなどを決めたのち、モバイルやWeb、バックエンドの設計や実装など、主にソフトウェアの領域で広く開発をしてきました。去年から組み込みとハードウェアも見始めています。
まず初めに、ビットキーがどういったモチベーションでどんな事業をやっていて、その達成のためにどのような組織で取り組んでいるか、主に開発組織にフォーカスしてご紹介します。
ビットキーはこのように複数のプロダクトを世の中に提供していますが、それらの中心にあるのは鍵のアップデートです。インターネットや、そこに乗っているサービス、スマホなどが、どんどん便利になってきていますが、物理的な鍵のところで分断が起きていて、体験がつながらないことが世の中の非効率の一因になっていると考えています。
白木：例えば、最近話題になっている宅配サービスを例に挙げると、Amazonなどで商品を購入して届く日が決まっていても、宅配サービスの人はマンションのエントランスを物理的に突破できないので、我々消費者は家で待機していないと受け取れません。家で待っているのは大変ですし、そこで受け取れないと再配達が必要になってしまいます。それが今では、物流の2024年問題という大きな問題として顕在化してしまっています。
そうした例の他にも、鍵があることによって生まれている非効率はあると思っています。また、場所も家だけではなく、オフィスや複合ビルなど、いろいろなところで起きています。
そこで、どうすれば鍵の本来持っているセキュリティを損なわずに、利便性を上げられるかということを考え、1つの答えを見つけてビットキーは生まれました。今ではスマートロックやビルの制御盤、エレベーター、自動ドアなど（のハードウェアと連携する）、分断を解決するためのハードウェアやソフトウェアをたくさんつくっています。
そして、homehubとworkhubという製品を世の中のサービスとつなぎ、それらのデバイスも扱えるようにすることを進めてきて、当初描いてきた夢が実現しつつあります。ただ、スタートアップはお金や人などのリソースが限られているので、この大きな構想に取り組むのは容易なことではありませんでした。
ですので、これまでいろんなチームがいろんな工夫をしながら取り組んできました。開発組織の構造が、その一歩目ですね。ソフトウェアからハードウェアまで横断して扱いながら、複数の事業を可能にすることを狙った構造にしています。事業の変遷に合わせて形は変えてきていますが、今回は現在のビットキーの開発組織をお見せします。
白木：大枠としては、上段のユーザー体験を第一とするhomehubのチームとworkhubのチーム、そしてそれらを横断して支えるチームに分かれています。創業初期からは、この赤い部分だけでした。
下段の右側にあるBKPというのは、ビットキープラットフォームのことです。最初は事業が1つだけだったので、上段の2つは分かれておらず、Webとモバイルは全部で1つでした。特に重要なポイントは、中核となる認証認可のところ、つまりIDと取引とデジタルキーを扱うビットキープラットフォームと、それを扱うアプリ側のチームを分けているところです。
ビットキープラットフォームが提供するデジタルキーと鍵穴のシステムは、鍵を扱うので特に安全性が重要ですが、そこで求められる技術的な難易度は相応に高くなります。この辺りは、会社としても積極的に特許を取っていますが、当然それだけでは足りず、実装においてもシステムの運用においても、絶対に間違えられないところです。
だからこそ、専門のチームを独立して立てています。そして、そのプラットフォームがAPIを提供し、homehubとworkhubがそれを扱う構造にすることで、最も重要なところを安全に守りながら、高速な開発を可能にしています。
同様に、SREと技術支援のチームを、homehubとworkhubとは分けて横断する形で置いています。ここでは共通的な課題の解決や改善、例えばクラウドのコストや脆弱性への取り組みを行ったり、インフラを新しくしたりなど、常に横断して活動し、homehubとworkhubの高速かつ安全な成長を支援しています。
そして、デジタルキーと鍵穴を実装レベルで扱うのはファームウェアです。なので、制御や組み込みという領域のなかで、もともとWeb系を中心する技術である電子署名などを扱える必要があります。これには、ファームウェアの開発をしているエンジニアが高度な鍵交換や署名検証を理解しながら取り組んでいます。チームのなかで、メーカー系とWeb系の知識が混ざっているようなイメージですね。
また、ハードウェアは専門のチームを置いていて、オフィス内にある工房で日々デバイスの解析や設計をしています。ビットキーはこれまで、いろいろな種類のスマートロックやカードリーダーなど、多数のデバイスを開発してきていますが、デバイスごとの縦割りではなく、ワンチームで全てを横断して扱っています。
ただ、ハードウェアに違う形で向き合っているチームが2つあり、そのうちの1つが、ハードウェアデバイスそのものは開発や製造をせず、世の中にある汎用的なデバイスをもちいて、IoTデバイスとIoTクラウドの領域を両方を扱うエッジ専門チームです。
もう1つがR&Dチームで、こちらはハードウェアを本格的に試作に向けて設計していくよりもっと手前で、最新の技術を取り入れ、その組み合わせをコンパクトに実現して検証を高速に繰り返しているチームです。そのチームは、実際に動作する新規デバイスをつくったり改善したりして、社内で2週間に1回お披露目しています。
品質への取り組みについては、ソフトウェア、ファームウェア、ハードウェアそれぞれに専門のQAチームがいます。ソフトウェアにおいてはもう1つ、開発とQAの間に立って開発の立場で品質を支援するチームを置いています。そこでは、テスト自動化の推進や品質を向上するための開発プロセスの浸透などを行っています。
そして、これらすべてに対してPdMとデザイナーが中心となって、最終的なユーザー体験を設計し、プロジェクトを推し進めて検証しています。その際、データエンジニアリングのチームが出しているアウトプットを、重要な指標としながら活動しています。これらの構造によって、最終的なユーザー体験をつくるという部分はPdMが引っ張りつつ、チーム間の独立性や支援関係を成り立たせています。
BDDを取り入れ、重要な機能から開発や検証ができるように
白木：お伝えした各チームの活動は基本的に独立していて、自律的に日々工夫しながら開発をしています。そのため、いろいろなところでいろいろな工夫が生まれてきます。ここからは、そうやって生まれた大量の取り組みから、いくつかピックアップしてご紹介していこうと思います。
最初は、workhubでBDDを取り入れた話をします。BDDは振る舞い駆動開発、BはBehaviorです。イメージを持ってもらうために、このときの実際の案件について軽く説明します。これはworkhubでアンチパスバックに取り組んだときの話で、アンチパスバックというのは、正しく入っていない人は出さないという、入退室や入退館におけるセキュリティ機構のことです。
白木：不正な入室をした人を外に出さないようにすることで、例えば盗難を防止するといったものですね。ビットキーでは、創業からずっと境界を超える権利を汎用的に広く扱ってきているのですが、この課題に取り組む時点では、どこかを通過したという状態を持って動的に権限を変えることができませんでした。それをできるようにするという開発です。
当初、workhubの開発チームはQAからの検証の戻りが多く、開発もQAも疲弊していました。案件の状況としては、納期がずらせず、スコープは握りが甘いところがあり、QAのリソースには余裕がない。ただ、お客様からのニーズを踏まえると、インパクトが大きな機能なので、初期から品質を高めたいという要求もあり、なかなか難しい状況でした。
そうしたなか、BDDを取り入れてみようという声が上がり、実際に取り入れて進めるという意思決定をしました。BDDとはざっくり言うと、自然言語でテストケースを記述し、価値の認識を合わせながらプロジェクトを進めるやり方です。それによって重要な機能の開発を早め、QAのシフトレフトを自然に起こして、重要な機能の不具合の検出をどんどん早めていく。そういった狙いで取り組んで、実際にそれを実現することができました。
実際にやったことは、この通りです。そもそも最初は、必要な機能の一覧がただずらっと並んでいる状態でした。そのため、まずはユーザー体験について、開発とQAが一緒になって整理して、共通言語で理解を進めました。
白木：次に、QAが中心となってクリティカルパスを決めました。それをもとに改めて開発タスクを整理し、順番を入れ替えて計画を立て直しました。これによって、上から順番に開発していくと、QAも自然に重要なところからテストができる状態になりました。
それだけではなく、付随して発生した効果がいくつかあるので、それもご紹介します。この案件はビットキーのシステムにおいて新規性が高く、さまざまな人が関わっていました。そうしたとき、たいてい目線を合わせながら進めることに一定の難しさがありますが、この取り組みを中心に毎日会話する時間が生まれ、それによって円滑にプロジェクトを進めることができました。
また、この活動を進めるにあたって、これはBDDならではの取り組みというわけではないのですが、まずインターフェイスとデータベースの設計をNotionで行って、その段階でインフラやSREの観点を強く持つエンジニアが積極的にレビューに入るようにしました。
早い段階でレビューを行うことで、開発者にとっては設計を前提としないゼロベースの素直なレビューを受けやすく、それによって成長にもつながりやすいという効果がありました。機能に対しても同じように、設計に対して妥協のないフィードバックを受けてから実装に進んでいくやり方になるため、結果的に短い時間で高品質を目指せたと思います。
ちなみに、homehubでも同じころに別の活動をしていました。話としては似ているので詳細は避けますが、そちらではDDDを進めるために、イベントストーミングを実施していました。BDDとイベントストーミングは、やり方や目的などいろいろ異なりますが、たまたま今回は、課題の認識がドメインレベルでそろい、それをもとに体験の優先順位をつけられるという点で同じような効果が生まれました。
短納期における工夫、コードジェネレーターとE2Eテスト
白木：QAの話に触れた流れで、E2Eテストやリグレッションテストの自動化の話をしていきたいと思うのですが、その前にそれにつながる別の取り組みからご紹介します。
これは開発者1人で、短納期で新しいサービスをつくったときの話です。このときは、開発しなければならない機能が多くて、開発期間も短く、余剰リソースもまったくないという状況だったので、何か大きな工夫をするか、あるいは外からリソースをたくさん確保するかの2択を迫られていました。
ただ、開発量は膨大ではあるものの、何をつくるべきか、どんな実装をすべきかといったイメージは持てている状態からのスタートでした。つまり、手を動かすのがすごく大変だというだけだったので、何か工夫できないかということで、できる限りのコード生成の自動化を目指しました。最終的には、つくりたいものを定義するだけで、中身がだいたいつくられるという、こだわり抜いたコードジェネレーターをつくりました。
それがどんなシステムかについては、あまりここでは掘り下げませんが、大きくやったことは、この左側の3つです。入力と変換と出力のインターフェースをまず定義し、それを使って下の2種類の生成機構をつくりました。
1つ目が、DBのテーブル定義をすると、右上の内容をつくるというものですね。DBのマイグレーションのためのファイルと、テーブルデータの追加、取得、変更、削除の関数と、必要なインプットが提示されたオープンAPIのオペレーションと、その定義と関数をつなぐAPI層、Service、Interactor、Usecaseをつくります。前提として、このシステムはクリーンアーキテクチャを採用してつくりました。
このときは、機械的に決められるところは何でも、ルールベースで全部つくってやろうという気持ちで取り組みました。例えば、リレーションしている2つのテーブルがあって、そこにデータを放り込みたいとき、requiredやForeign Keyのような情報があれば、頑張ればバリデーションやインサートの処理ってだいたい決まりますよね、というのをやりました。
そしてもう1つは、OpenAPIを定義すると、API層とそのAPIを呼び出すためのクライアントを自動でつくるものです。こちらは、中身はまだこの時点ではわからないので、後から実装するパターンです。
最終的に人間がやらないといけないのは、単純なデータ操作のときはテストだけ。そうでないときは、API以外のInteractorの実装と、その単体テストとE2Eテスト。その実装も、DB操作周辺は全パターンすでに関数が生成されているので、主にそれらを使いながら中間の値の加工だけを実装していくイメージです。
白木：E2Eの実行は、ここでのやり方はまずDockerでAPIサーバとDBサーバを立てて、DBマイグレーションをするところから始まります。そこから、先ほどお話ししたようにAPIクライアントを自動生成しているので、それとユニットテストの実行機構を利用して、E2Eでのシナリオをつくっていくというやり方で、E2Eテストを実現しました。これにより、3ヶ月でつくり切ることができました。
この機構は、続く別件で同じように新規サービスを作るときにも流用しました。体験としてはこちらの方が良く、2回目なので生成機構は最初から存在していて、ただリレーションの設計をすれば、あとはだいたいできるという状態です。シンプルなCRUD以外のロジックについても、中身のInteractorを書くだけで、周辺の関数もそろっている状態から新規開発がスタートするという、なかなか珍しい体験だったと思います。
このときの工数のほとんどは、E2Eテストをひたすら書いていく部分でした。今では、自動生成機構のうち共通的で、かつ変化があまりない領域はパッケージングしてしまっていて、それを他のところにも流用しています。この際、シンプルなCRUDの自動生成は便利なのですが、実際にはそれほどなく、だいたい条件分岐などいろいろロジックが入るので、複雑さが勝つと考えてばっさりカットしました。
資産になると思ってつくったものが負債になるというのは、よくあることだと思うのですが、今回ビットキーではエンジニアの積極的な協力もあり、今でも継続して活躍してくれています。自動生成の話は以上ですが、E2Eテストについてもう少しだけ触れたいと思います。
白木：そもそもE2Eテストというのは、開発すればするほどどんどん増えていくリグレッションのリスクに対して、人的リソースをそのぶん無限に増やしていかなくても良くするための、素晴らしい方法だと思っています。そうしたE2Eテストを、ビットキープラットフォームやIoTを扱う領域においても重視し、積極的に自動化に取り組んでいます。
まずビットキープラットフォームでは、例えば変更のたびにQAチームが張り付いてリグレッションテストをするといったことは、基本的にしていません。これはかなり前からですが、E2Eテストを完備して日々自動的に実行することで、安心してリリースできる状態をずっと維持しています。
また、IoTやエッジの領域は物理的にものを扱うため、テストの難易度が高いです。ただ、難易度が高いといってもやりようがないわけではなく、最初からIoTやエッジの自動テストを前提にして、アーキテクチャから設計することが重要だと思っています。
スケーラビリティや可用性は当然考えるのですが、それだけでは足りないということですね。将来変更するときに、デバイスの動作まで含めて安心してリリースしていけるかという、運用や保守の観点を最初から持ってシステムを設計することが大事です。
実際にこのIoTクラウドやIoTデバイスの領域では、例えば制御盤を扱うときには、まず制御盤のエミュレータづくりから始めました。制御盤は結構大きな箱で、開発環境にあまり数を調達できないので、なかなか開発が難しいというところもあり、エミュレータづくりから始めました。
そして、現在ではmablというWeb向けの自動テストサービスを活用し、画面からのテストに組み込んで自動化をしています。結果として、今ではIoTの領域においても安心してリリースできる状態を維持しています。
Notionでの1週間ハイライト、Slackチームチャンネルの工夫
白木：長々とややこしい話をしたので、ここからは少し趣向を変えて、開発行為ではなく開発チームの営みの話をします。前提として、ビットキーでは創業以来ずっと、OKRを取り入れて運用してきました。会社や各チームが高い目標を設定して四半期を走るなかで、毎週チェックインから始まってウィンセッションで終わるというサイクルを繰り返してきました。
これは目標管理としてもチーム間の共有としても、上手くハマっていて、見通し良くみんなが高い目標に向かうという、とても大きな効果を生んできたと思います。ただ、事業が拡大してチームが細分化していくなかで、毎週の定期イベントの時間が延びて、だんだん上手くいかなくなっていきました。
チームが細分化していくと、どうしても興味が遠い領域も出てきます。そうなると、ただでさえ時間が長いので、だんだん内職の時間になってくるんですね。最初のころは、チームごとの発表時間をできるだけ短くするという努力でしばらくしのいでいましたが、それもすぐに限界がきました。
なので、次にOKRイベントの単位を分割しました。ただ、結局分けても後から膨れ上がっていき、分けることで分断も生まれ、その繰り返しになってしまいます。そうした状況で、各分割単位でもいろいろな工夫がされてきて、そのなかで1つイケてる活動が生まれたので、それをご紹介しようと思います。
これはhomehubのモバイルチームでの話ですが、1週間のハイライトを毎週Notionに、チームメンバーみんなで書いていくという営みを始めました。先ほどのOKRイベントの代わりですね。いくつあるかわからない発表を聞き続けるのは結構つらいですが、こういった形であれば、ポジティブな気持ちで見やすくなります。発表者のスピードや話し方に左右されたり、機材のトラブルなどで時間を消費したりといったこともなくなります。
白木：Notionのページはつくって終わりではなく、Slackで周知します。そうすることでみんながちゃんと気づけますし、場所や時間の拘束もなく、自分の好きなタイミングで見に行けます。
そのうえで、チームとしては毎週、目標や成果を明らかにしているので、目標管理の良いプレッシャーは残りますし、頑張ったものを見てもらえるという気持ちも大事にできます。逆に、みんなの頑張りを見たい、知りたいという気持ちにも応えられます。これは本当に良い取り組みだと思うので、もし似た悩みがあったら、ぜひ参考にしてもらえると嬉しいです。
続いて、この話に関連して、Slackのチャンネル運用に関するちょっとしたTipsを紹介しようと思います。ビットキーでは、Slackでチームごとのチャンネルをつくっていて、そのなかで生まれた工夫です。
これは先ほどと同じhomehubのモバイルチームの話ですが、最初にSlackのチームのチャンネルを2種類に分けるという運用を始めました。1つはチーム外とやり取りをする窓口のチャンネルで、もう1つはチーム内のコミュニケーションに特化したインターナルチャンネルです。
1つでいいと思われる方もたくさんいると思います。ただ、チームの内輪の話で盛り上がっているところに外から入り込むのは、一定の心理的ハードルがありますし、逆にそれを気にして、いまいちチームの話で盛り上がれないといったこともあるかもしれません。そのため、2つのチャンネルに分けました。これによって、円滑なコミュニケーションができていると感じます。
さらに、こうした内輪の話をする場をあらかじめ用意することで、コミュニケーションをオープンに保ちやすいという効果もあるのではないかと思っています。こうしたチャンネルがないと、内輪の話はプライベートチャンネルやDMでされがちだからです。今ではビットキーの多くのチームで取り入れられ、多数のインターナルチャンネルがつくられています。
Web開発の知見を活かし、組み込み開発環境の整備へ
白木：続いて、少し毛色を変えて組み込みの話をします。これはソフトウェア畑のエンジニアがファームウェアを開発することになって、その環境にギャップを感じたときの話です。2021年にビットキーのエンジニアが発表したもので、少し昔の話なのですが、今日のテーマにぴったりだったので持ってきました。先ほどのSlackのTipsよりは持って帰るのが大変かもしれませんが、何かのきっかけになればいいなと思います。
ビットキーは創業時、エンジニアは全員ソフトウェア出身でした。そこから手探りでハードウェアのエンジニアを採用するなどしてきたのですが、ファームウェアに関しては基本的にソフトウェアなんですね。WebやモバイルのようにリッチなOSはないですし、電子部品の仕様と戦うという違いはありますが、それ以外は基本的にソフトウェアです。
それから、ビットキーの場合は冒頭でお伝えしたように、組み込みや制御という領域のなかに、デジタルキーや鍵穴という情報管理や検証などのロジックが入り込みます。なので、初期はソフトウェアのエンジニアがファームウェアを開発していたりもしました。そうした流れのなかで、当時ビットキープラットフォームの開発をしていたエンジニアが、ファームウェアの仕事をすることになって、業界のギャップを感じたという話ですね。
彼が感じた当時のつらみや違和感は生っぽい方がいいかなと思ったので、そのときの発表資料から抜粋して持ってきました。この話は、皆さんが想像するような快適な環境があって、パイプラインなどの周辺も充実している、そういう環境から一転して、ベンダー指定のIDEという、なかなか聞かない環境を強いられるところから始まります。
白木：このIDEは、VSCodeやIntelliJのようなイケてるものではなく、コードフォーマットはできはするけど自動実行はできないとか、そもそもキーボードショートカットもないとか、そういうものです。
それに対してこのままでは良くないと考え、つらみを整理して、例えば「Web開発だったら一般的にエディターは好きなものを使うはずだ」とか、そういったことに取り組んでいきました。取り組み内容はスライドにまとまっていて、この話に関連するQiitaの記事などもあるのですが、今日は詳細を割愛して結果の紹介だけに留めます。
白木：一番はIDE依存を剥がすことで、組み込みをVSCodeで可能にしたという部分ですね。他も同様です。CI/CDパイプラインなどを整えて、快適にしてきました。この発表の最後では、「イノベーティブになれるかは環境が大きく左右する」とまとめられていました。これは個人的にも本当にそう思います。皆さん、日々の環境にはこだわっていきましょう。
領域の枠を超えたコラボレーションが生産性向上の可能性に
白木：最後にご紹介するのは、ハードウェアデバイスに関する問い合わせで、生成AIを活用した話です。生成AIはここのところずっと盛り上がっていて、皆さん生成AIに関する話はいろいろ聞いているかと思いますが、ビットキーならではの面白い組み合わせだったので持ってきました。
背景として、そもそもビットキーのハードウェアエンジニアはとても少ないです。仲間は絶賛募集中ですので、興味持った方はぜひお声がけください。話を戻しますと、エンジニアが少ない状況のなかで、ハードウェアの問い合わせは日々頻繁に発生します。そして、その多くが過去に調査済みのものであるというのが特徴的です。
Webやモバイルと違ってハードウェアでは、修正して配信すると顧客の手元にあるものが直るということは、基本的にありません。出荷してしまったものは基本直せず、直すとしても次の製造から適用されて、1台ずつ交換していくことになります。なので、「この問い合わせはあの話と同じですね」ということが頻繁に起きます。
そもそもメカや電気は専門性がすごく高いので、情報がたくさんあったとしても同じ事象なのかどうか、カスタマーサポートの担当者や領域外のエンジニアが切り分けていくのは結構難しいです。実際に、既知の課題とそれに対する切り分けの仕方を、整理してデータベース化していたのですが、そこから正しい情報を検索して取得することが難しく、結局Slackで専門家に聞くということが起きていました。それを改善したいということですね。
このときに、AIが使えるエンジニアと、電気の専門性を持ちながらハードの解析をしているエンジニアのコラボレーションが自然に生まれました。そして、先ほどのデータベースを参照して回答できる、社内向けの生成AIサービスが誕生しました。
白木：生成AI周辺のシステム構成や、使っているLarge Language Model、つくり方などは今日は紹介しません。こういった「どう調べたらいいのかわからない」というものは、そもそも生成AIが得意とすることですし、RAGで特定のデータベースを参照することも普通ではあります。
ただ、調べる先が社内のハードウェアの調査データベースであることや、領域が全然違うエンジニア同士がたまたま近くにいて、コラボレーションして生まれたイノベーションであるという意味で、面白い例かなと思います。ハードウェアは事業で扱っていないとなかなかないかもしれませんが、それに限らず、身近にいる仕事の領域の違う人たちが枠を超えてコラボレーションすることで、生産性向上の可能性が大きく広がると思っています。
最後にまとめです。開発生産性とは、つまり効率のことですよね。同じ時間、同じコストをかけて、できるだけ大きな価値を生み出すという、その仕事の効率は誰もが上げたいと願っているはずです。僕もすごく上げたいと思っています。
そのために、皆さん日々工夫して生産性向上に取り組んでいるはずです。そのときに、例えば最後にご紹介したような領域違いのコラボレーションや、その前にご紹介した自ら新しい領域に行くことで生まれる発見や発明などのように、普段とは少し違うものに触れることが、開発生産性を向上させるきっかけになるかもしれないと思っています。
もしかしたら、会社の枠を超えたコラボレーションで、さらに大きなものを生み出すことができるかもしれません。実際には、会社間では安易に情報開示できないなど、いろいろな壁もありますが、今日はせっかくこういう場なので、いろいろなものを見たり話したりして、何か良いアイディアが生まれるといいなと思っています。以上です。ありがとうございました。
