開発者体験向上は、開発に携わる人間にとって重要であり、向上に取り組む企業も増えている。
本記事では、「Developer eXperience Day 2024」（主催：日本CTO協会）にておこなわれた講演を紹介する。株式会社ビットキー VP of Technology 白木 孝典さんが「ビットキーにおける開発者体験向上に対する考え方と挑戦」をテーマに講演した。
ソフトからハードまで広く扱うスタートアップとしてのビットキーの組織戦略を踏まえつつ、そこから生まれた取り組みの事例を紹介した。
白木 孝典 さん
株式会社ビットキー VP of Technology。2018年にビットキー創業メンバーとしてジョインし、ビットキーの提供するサービスの各種技術選定やアプリケーション開発を牽引。現在は技術部門全体の責任者として、組み込みソフトウェアやハードウェアデバイスまで範囲を拡大。インフラの採用・変更などの大きな意思決定や個々の機能設計は継続しつつ、組織作りやプロセス作りまで幅を広げて活動中。
目次
ビットキーと開発組織について
ビットキーは2018年に創業し、最初は家の鍵から事業をはじめて拡大してきました。
鍵と鍵穴の関係、あるいは鍵の受け渡しという概念があります。それを、認証、認可や取引という概念に抽象化して、物理世界とデジタルの境界をなくしていっています。
インターネットやスマートフォンは進化していますが、物理的な鍵があることによる空間の分断があるのは避けられません。それにより、実現できない理想の体験がたくさんあって効率化しきれていないことに課題感を持っています。
具体的な例をもとに、社会課題の1つを説明します。インターネットでなにかを買うと、宅配サービスによって家に買ったものが届きますが、荷物は家に誰かがいないと受け取れません。宅配ボックスがあれば、そこに届くこともありますが、埋まってしまっていると入れられないこともあります。
そうすると、荷物は一度持ち帰られてまた届ける再配達という形になります。これが物流の2024年問題という社会問題の一因になっているんです。再配達のコストが高く、届けきれなかったり、長時間労働を引き起こしています。
本来、届けてほしいニーズと届ける仕事がマッチしているのに、それができないのはもったいないシーンですよね。なぜ、こうしたことが起きるのかというと、鍵があるからです。もう少し正確に言うと、届けてきてほしい人に鍵を渡せないからですね。
たとえば、届けてくれる人に対して、配達日だけ本人認証によってマンションのエントランスを通れるようにできれば、部屋の前まで荷物を届けてもらえます。
セキュリティ向上にもつながります。本人認証ができれば、悪意あるなりすましも防止可能です。
ビットキーはハードウェアとソフトウェアの両方をつくっていて、複数の事業ドメインとレイヤーがあり、開発も大変です。そこで開発者体験の向上が重要になります。
まずは組織構造について紹介します。
大枠として、「homehub」と「workhub」のアプリケーションをつくるチームがあり、それを横断して支えるチームがたくさんある形です。認証に関わるIDやデジタルキーをつくっているチームと、アプリケーションをつくるチームに分けていることが特徴的だと思っています。ビットキープラットフォームは安全性が重要であり、求められる技術的難易度が高いです。開発も運用も間違えられません。そこで専門のチームをつくりました。そのチームがAPIを提供して、アプリケーションチームはAPIを使う形にすることで、安全なところを守りながら早く開発できるようになっています。
ビットキーではハードウェアもつくっています。オフィス内に研究開発室（社内呼称：工房）があり、そこでデバイスの設計や解析をしています。デバイスごとに縦割りのプロジェクトチームではなく、ハードウェアのワンチームですべて横断して扱っています。
制御盤連携IoTデバイスの開発事例
制御盤連携をおこなうIoTデバイスの開発という比較的珍しい開発事例をお話しします。
まず、制御盤とは、ビルやマンションを一元的に制御するデバイスのことです。ドアロックやエレベーターの着床制限、空調や照明などを取り仕切ります。
ビットキーでは、workhubから制御盤を操作するときに仲介する制御盤連携デバイスを開発しています。
この制御盤連携デバイスは開発が特徴的です。まず、連携先の制御盤というのは、簡単には手に入りません。入手できないことが普通にあります。開発したいのに開発対象が手元にないみたいな感じです。動かしながら開発することが難しいですし、検証も大変です。
とはいえ、開発サイクルが遅くなると品質がよくなりません。理想は毎日リリースしたいくらいです。そこで、ビットキーでは仕様書どおりに動作するエミュレーターをつくって開発を進めています。実機を使って検証した結果、違いが発見されたらエミュレーターにフィードバックしていきます。
結果として、2-3日に1回リリースするサイクルが可能になりました。開発者体験の面でも、開発者がそれぞれ手元で気軽に動作確認できることで、快適なうえ生産性が上がっています。
実機の制約がなくなることで、WebベースのE2Eテストに含めることができます。これにより、検証の自動化も実現しました。
リグレッションテストの自動化
そもそも機能はつくればつくるほど、システムが大きく複雑になるため、壊れやすくなります。その分だけ、リグレッションを抑えるためのテストのボリュームは増えていきます。そうなると会社としてはコストも上がるし、リリースに時間がかかるようになってしまうんです。
それだけではなく、開発者個人の体験としてもつらいです。ちょっとした改善をしようと思ったときに、検証で「数十人日溶けます」と言われてしまうと、気持ちとしてつらいですよね。そもそも、そういう状態でちょっとした改善はできません。
そこで、リグレッションテストを自動化することがとても大事になります。とくにDevOpsにとっては欠かせません。自動化だけがやれることではありませんが、大事なことです。
そうした考えから、ビットキーではいろいろなところでリグレッションテストの自動化に取り組んでいます。単体テストだけではなく、E2Eテストの自動化にも積極的に取り組んでいます。E2Eテストの自動化維持は大変です。ただ、長くシステムを開発・運用するのであれば、いずれは必ずペイすると思っています。まだまだ道半ばという感じではありますが、頑張って取り組んでいるところです。
コーディングの自動化
実装についても自動化したので紹介します。3年ほどまえに、結構ボリュームのあるシステムを新規で開発する必要がありました。開発期間が3か月で、余剰人員がいないタイミングだったため、1人でやらないといけませんでした。唯一の救いは、なにをつくればいいのかというゴールが明確だったことです。
そういう状況だったので、「人力でシステムをつくる」のではなく、「人力でシステムをつくれるものをつくろう」と発想を変えました。実際につくったものを適用した例が次の2つです。
それぞれの詳細について今日はお話ししませんが、資料がビットキーのSpeaker Deckにありますので、 興味があれば見てください。
コードをほとんど書かなくてもシステムを作れるようにした話
ビットキーのプロダクトの根幹スマートアクセスをよりスケールするための破壊と創造
この自動生成システムは、その後パッケージングして社内に展開しています。
SlackとNotion運用の工夫
世の中にあるコミュニケーションツールの運用は、会社や組織によっていろいろあると思います。ビットキーでは、Slackを使っていて、チームのチャンネルをつくっています。以前は「#team-◯◯◯◯」というチャンネルだけがありました。その状態だと内輪のやり取りのなかで外から真面目な投稿をするのは、結構心理的にきついんですよね。逆にそういうことが起こらないように遠慮すると、チームが盛り上がらなくなります。
そこで、チーム外の人とコミュニケーションを取るためのチャンネルと、チーム内コミュニケーションのためのチャンネルを明確に分けたんです。かつ、インターナルチャンネルもオープンチャンネルにしていることがポイントですね。これをしないと、インターナルなやり取りをプライベートチャンネルやDMでするようになります。
同じような課題を感じている方がいれば、試してみるといいかもしれません。
続いて、Notion運用についてのちょっとした工夫についてです。まず背景として、創業初期からOKRを導入していました。
事業拡大とともにチームが増えていくと、全社で毎週集まることが難しくなります。チーム間でお互いがなにをしているのかがわからなくなり、分断してしまっていたのですが、Notionでいい取り組みをしていたチームがあったので、それを紹介します。
そのチームは毎週、なにをしたのかをNotionへまとめて全社公開することをはじめました。自分のタイミングで興味あるところを見に行けるので、体験としていい形です。ただ、それだと気づきにくいので、さきほど紹介したSlackのチャンネルを使って周知しています。
見る側はいつでも見られますし、チーム内は目標を立てて公開し、成果も発表するので、いいプレッシャーは残ります。組織として結構いい効果がありました。
もう1つNotionの運用で工夫していることがあります。チームのポータルページをつくり、チームの役割やニュースを公開しています。ニュースやアップデート情報など、広く発信したいものは、さらに一層上にしてチーム横断で共有しはじめました。
組織間の情報流通やお互いになにをやっているのかわからないという方がいたら、参考にしてもらえるとうれしいです。
つらいまま開発しない
2021年にビットキーの開発組織内で、Web系出身のエンジニアが組み込み開発をすることになりました。もともと、CLIやCI/CDパイプラインが充実した世界で生きてきたエンジニアが、急にベンダー指定のIDEを押し付けられたところから話がはじまります。
それがイケてなくて、開発がつらい状況でした。自分の好きなエディタがつかえないとか、周辺システムが充実していないとか、体験が最悪だったんです。
その彼は、つらい体験をそのままにせずに、ベンダー指定のIDEを使わなくてもいいように開発をするところからはじめて、環境をなんとかしたんです。彼はそのときのまとめとして、「イノベーティブになれるかは環境が大きく左右する」と言っていました。
日々やりづらさを感じたら、なんとかするところからはじめるといい。この言葉を聞いてすごく思いました。みなさん、日々の環境にはこだわっていきましょう。
開発者体験が快適だと生産性が上がりますよね。そうすると品質もよくなります。日々のストレスがなくなるので、クリエイティビティが上がります。そしてそういう人同士のコラボレーションが自然と起きて、イノベーションが生まれると思うんです。
開発者体験は、楽しいとか快適というところに目が行きがちだと思っているのですが、それだけではありませんよね。その先には多くの効果があり、会社の行く末を大きく左右するほどのものになりかねないと思っています。
取材後記：開発者体験がイノベーションにつながる
私の勤めている職場でworkhubを利用しているため、ビットキーには勝手に親近感を抱いていた。設立から6年目のスタートアップでありながら、社員数は200名を越えている。ソフトウェアとハードウェアの両方を扱うため、多様な人材が必要だろう。
そのなかで開発者体験を高めることに挑戦している。開発者体験を高めることは、採用面や離職防止への効果だけではなく、クリエイティビティやイノベーションにもつながると白木さんは話していた。
DX（Developer Experience）の重要性をあらためて感じたセッションだった。
（取材／文：川崎博則）
