この記事は株式会社ビットキー Advent Calendar 2022 20日目の記事です。
Home Product Circle所属の佐藤 拓人(@takuuuuuuu777)が担当します。
0. 留意事項
IoTと記載していますが…単体でネットワークにつながるデバイスではなくスマホと介してネットワークとつながり制御を行うスマートロックを主たるデバイスとして本記事では取り扱っています。
当初本記事ともう一つの記事を合わせて投稿予定でした。本記事で取り扱っているドメインの概要を紹介し、別記事で sudoモデリング
を実践した際の実例を紹介する予定でした。…が特許の都合上同時に公開することができずとなってしまったので、本記事だけ先んじて公開しています。
もう一つの記事も準備が整い次第公開予定です。文中に別記事を示唆する内容が含まれている部分もありますが、モデリングの実例について記載した記事は追って公開する予定であることをご了承ください。なお別記事は [第二弾] IoTスタートアップで実践したsudoモデリング実例!
という題目で公開を予定しています。
1. はじめに
本記事では筆者がモデリングをする際に整理したドメイン知識をまとめた内容を記載しています。
別記事で本記事記載のドメインをもとに sudoモデリング
を実施した記事を記載していますので良ければ見てみてください。
ドメイン駆動設計
への取り組み方については非常に優れた書籍が多数あります。しかし、実際のプロダクト開発での実例を知る機会があまりなく、具体事例をイメージしづらいなと感じていました。一つのドメインの実例として今後の開発の助力としていただければ幸いです。
1-1. 自己紹介
株式会社ビットキーで開発をしています (Twitterはこちら)。フロントもバックエンドも開発しますが、バックエンド開発が好きで、TypeScriptをよく利用します。物事を抽象的にとらまえ構造化して設計/実装するのが好物です。
ビットキーの中でも Home
と呼ばれる暮らしにまつわる領域の開発を担当しています。ビットキーの中には大きく Home(暮らし)
, Work(働く)
, Experience(非日常)
の3つ領域があり、その中の1つが Home
です。
1-2. ドメインとの向き合い方
約7ヶ月前の2022年5月あたりから DDD
を段階的にプロダクトに導入していました。(詳細は過去投稿しているQiitaの別記事参照)
優先的に解決したい課題は「堅牢」「知識の集約」でした。また、既に実装済みのプロダクトのリファクタリングも多く、新規にモデリングをするよりは、 オブジェクト指向
の仕組みを如何に適用していくか、に重きをおいていました。
その後しばらくして、新規機能開発をする際に既存の構造を見直すのが必要となりました。そこで、モデリングの進め方として sudoモデリング
を参考に実施することに決めました。モデリングをする過程において、既存のドメインについても整理をしようと思い、本記事を作成しました。
2. 歩んできたみち(ドメイン)を振り返る
ビットキーという設立4年目のスタートアップの会社で、私が所属しているHomeの領域で取り扱っているドメイン(業務知識)の内容について記載します。
ドメインを理解するうえで、どのように事業を進めてきたか…という情報は背景や優先度の付け方の考え方を理解する上で重要な要素となると考えています。そのため事業フェーズの変遷と合わせて、時系列で記載をしています。1
2-1. bitlock LITE × bitlock app 市場リリース (2019/05〜)
最初期に to C
向けのプロダクトとして市場にリリースしました。( スマートロック
+ スマホアプリ
)
bitlock LITEというスマートロック、を bitlock appというスマホのアプリで、デジタルなカギを使って解錠することができるというソリューションです。
既存の家の扉についているカギのつまみの部分を挟み込むように後付で設置をし、スマートロックに内蔵されているモーターを動かすことでカギの解錠/施錠を実現することを可能としています。(※詳しい説明は弊社のECサイトをご覧いただけますと幸いです。)
家のカギをデジタル化することで、物理カギを持ち歩かずともスマホで解錠できる、オートロックなどの仕組みを導入する事ができるというメリットの他にも、カギの受け渡しもデジタルなカギでやり取りすることができます。また、特にカギを取り扱う上で認証/認可の責務をビットキープラットフォーム(以降BKP)としてマイクロサービスとして独立させて、特にセキュリティ性に考慮した作りで実現しています。
簡略化していますが、実際のユースケース例を図示します。
【After】扉にbitlock LITE (スマートロック)を設置することでスマホで解錠することができるようになります。また手ぶら機能というものもあり、扉に近づくことでアプリを操作することなく解錠することも可能になりました!
カギの受け渡しをするシーンに置いても...
【Before】物理のカギを利用している場合、家族(同居人) には物理的に合鍵を作成して渡す必要があります。
【Before】また、自分が不在の際に親や友達が訪問してきた場合…その都度カギを追加で渡すことができないので、待っていてもらうか一時的にカギを貸し出して…ってことが必要になります。
【After】デジタルなカギであれば、条件を指定して渡すことができます。
至極シンプルなソリューションではありますが、物理のカギをデジタル化することで創出される価値があります。
2-2. B to B to C での提供開始 (2019/10〜)
to C
だけでなく、to B
を対象とした機能のリリースもしました。to B
なのでスマホアプリだけでなく管理画面をあわせてリリースしています。
「ヒトの出入りを制御する必要な空間の管理を行う会社」がターゲットで、賃貸物件を管理している管理会社やオフィスなどで利用されます。
さらに、ここでは筆者が所属していたチームが取り扱っていた、賃貸管理会社に限って説明をしていきます。
to B
においては、ざっくり以下の手順で利用されます。
※ 入居者がカギを利用できる期間は入居契約の期間に基づくので、入居契約の情報もシステムで管理をします。が、本プロダクトにおいては、スマートロックと組み合わさって提供される機能が事業的に優先度が高いため、カギにまつわる機能を中心に機能をリリースしています。
物理カギの場合だと…
【Before】物理的なカギを事前に管理会社から物理的に対面で受け取る必要がありました。
【Before】さらには、退去時にはカギを返却も行う必要がありました。 (同居人にカギ渡してたらそれも回収して返却する)
bitlock を導入することにより…
【After】デジタルなカギでやり取りが可能となるので、カギの受け渡しのために直接対面しなくてもOKになります。(※ 運用方法によっては物理カギの受け渡しも行います)
【After】退去する場合にも直接カギを受け渡ししなくても、カギが利用できない状態とできます。
to C
だけでなく、B to B to C
もスコープに入れることで、業務トランザクションと連動してカギが発行され、特定の空間に実際に入室することができる。という、一つ進歩した価値を創出することができるようにになりました。
また、今後のプロダクトのビジョンを広げやすくなりました。
2-3. B to B to Cの機能強化 (2020/01〜)
B to B to C
の領域に関して機能強化をリリースしました。その中でも主要なものをここで記載しています。
■ 賃貸物件に関わる「内見」や「現状回復工事」を実現するための機能をリリースしました!!
特に内見を行う仲介業者や、原状回復工事を業者も物件のカギを扱う必要があり、これを物理カギではなくデジタルなカギで実現するための機能です。内見に関しては内見予約を行うサイトもリリースし、予約された内見に応じて利用可能なカギが発行されるようになりました。
入居者だけでなく、内見を行う仲介業者や現状回復工事を行う清掃業者へのカギの受け渡しや管理といった大変な業務を一気に削減することが可能となりました。
■ 設定基づいて合わせて共用部のカギを発行する機能をリリースしました。
賃貸のマンションのエントランスが自動ドアにカギがついていたり、共用部にカギが付いている場合などがあります。この場合物件のカギだけでなく合わせてカギを渡して上げる必要があります。また入居者や内見、現状回復工事など利用シーンや対象とする物件によって制御が必要となる場合もあり、これを制御したうえでカギの発行することができるようになりました。
B to B to C
の領域で、1つのスマートロックを解錠できるだけの価値だけでなく、業務トランザクションや他の空間とデバイスとの紐付けを活用することでより高い価値を創出できるようになりました。
2-4. 連携対象の拡大 (2020/01〜)
インフラ会社や、他社の内見システムとの連携。家事代行会社との連家など、他のサービスと提携した機能をリリースしました。
ビットキーの企業理念は 『テクノロジーの力で、あらゆるものを安全で便利で気持ちよく「つなげる」』 です。
入居者 ⇔ 賃貸管理会社 間だけでなく「暮らし」の文脈で重要となる他のサービスを積極的に連携をしています。
以下が実際の例になります。
-
賃貸の入居者が対象のためインフラ会社と提携してガス/電気の申込みと合わせて利用できる
-
内見業務効率化のために既に運用されている他社のシステム上で内見の予定の登録をすると期間に応じたカギを発行できる
-
家事代行業者のシステムと連携して、依頼と合わせて担当者に依頼期間内で利用可能なカギが発行されて、不在の場合でもサービスを受けることができる
ちょうどこの頃、後のhomehubのキーワードとなる「暮らし」というワードが頻出するようになってきました。
入居者 ⇔ 管理会社 間の閉ざされたシステムではなく、他サービスと連携してさらなる大きな価値を生み出していく大きな一歩を歩みはじめした。
2-5. homehubの爆誕!!!! (2021/01〜)
現在のプロダクト名である「homehub」という単語が誕生しました!
もともとは「bitlock app」「bitlock MANAGER」という製品名でした。その名の通り、bitlock の利用 / 管理を主として扱うアプリケーションでした。そこから「homehub」という名前に変更となり、「暮らしのハブとなる製品」というコンセプトに変更となりました。
これに伴って、toC向けのスマホアプリや、ECサイト、toB向けの管理画面をすべて刷新しました。またデバイスに関しても、後継機を合わせてリリースしました。
機能の改善はもちろんのこと、NFCカードや、パスコードなどの解錠方法を利用することができるようになりました。bitreader+というデバイスを追加で設置することでNFCカードやパスコードで解錠することができるようになりました。
bitreader+はオフラインで動作するデバイスで、仕組みとしては以下です。
- bitreader+とbitlock MINIを連携できるように設定しておきます。
- bitreader+に事前に利用可能なNFCカードやパスコードの情報を登録しておきます。
- 利用者がNFCカードをかざしたり、パスコードを入力します。
- 2のNFCカード / パスコードが利用可能なものである場合、bitreader+からbitlock MINIにに対して解錠コマンドが実行され解錠することができます。
これまで積み重ねてきた武器をもって、今後さらなる大きな価値を生み出していくためにプロダクトビジョンから整理し直して新たな道を切り開きました。
2-6. homehubとしての機能拡張 (2021/01〜
「bitlock の利用 / 管理」というスコープから、「暮らしのハブ」というスコープに進化しました!!これに合わせて、特にB to B to C
の領域において大きく機能拡張をしました。
施設予約、掲示板、お知らせ / 広報誌、管理会社のサービス連携、理事会総会など、「homehub」というコンセプトにおいて、実際に利用してくださっている顧客に価値をだせる領域を順次拡張し開発を推し進めました。
分譲マンションなど地域コミュニティに関する機能など、今まで以上に幅広く開発をし、機能リリースを行いました。
2-7. homehubの洗練 (2022/04〜)
一気に作り上げたhomehubの機能で特に主要な部分を洗練させていきました。
主だった対応は以下です。
- homehub appのリニューアルリリース
- B to B to C領域での次世代製品の対応
- パスコード × サービサー のソリューション
- 基幹システムとの連携
- B to B to B to Cへの対応となるサブリース機能のリリース
…など多数
特にパスコードの中でもTOTP(Time-based one-time password)による解錠は賃貸領域において重要な機能でした。
内見をする仲介業者や、リフォームなどの現状回復工事をする業者の中にはスマホを利用できない場合が一定数存在しており、これを解決するための有効な1手となりました。
内見予約や現状回復工事の予定情報と連動して、利用可能なパスコードを参照できるようにするのはもちろんのこと、用途に合わせてパスワードの桁数やインターバルを指定ができたり、同じ建物内のエントランスと専有部とを同じパスコードで解錠できるようにする仕組みなど、プロダクトとして成長することができました。
【Before】個別にパスコードを登録するとエントランスと専有部で利用できるパスコードがばらばら…
【After】設定によってエントランスや共用部と専有部を同じパスコードで解錠できるように!202号室も北口も南口も共用部も同じパスコード「9876」で解錠できるように!
機能を増やすだけでなく、既存の機能をより高いソリューションへ進化させるために必要な改修をしつつ着実に価値を増やし続けました。
特に利用者数も機能数も増えてきて、如何に継続的にプロダクトを成長させていくかという考えが重要になってくるフェーズで既存の機能の見直しや改修も積極的に実施しています。
〜〜今ここ!〜〜
2-8. まとめ
ここまでがこれまでのざっくりとした事業フェーズの変遷と、歩んできたプロダクトの進化 (ドメイン) の内容です。
当初はToC向けのスマートロックを中心にして、BtoBtoCへの参画、他サービスとの連動、デバイスの種類や解錠方法の増加…といった具体に機能拡張をしてきました。
これらを業務委託など外部のリソースを活用しながら限られたメンバーで実現してきました。
(※ 2022/12時点でHomeProductのメンバーは私含めて5人)
3. 難しさがどこにあるのか考える
最初はシンプルなものでもそのまま開発を進めていくと、どんどん苦しくなってくるシチュエーションが多くあります。実際に開発をしていて苦しい思いをし、「DDD」の要素を取り入れる判断しました。その要因となった要素をここで整理します。
3-1. 領域の拡張
当初リリース時点と比較して、対象領域が圧倒的に広くなったことです。
もともと限られたリソースで開発をしており、属人性が強い領域がありました。領域が広くなったことと、合わせて業務委託などの外部のリソースも使い始めたことで全体の整合性を保つことが難しくなってしまいました。
結果として以下のような事象が発生してしまっていました。
- 特定の領域の修正をした結果、意図しない箇所で不具合が発生してしまう
- 機能横断の修正をする際に、特定の導線の考慮が漏れてしまう
3-2. 扱うデバイスの種類やその機能の増加
最初期は一つのスマートロック(bitlock LITE)のみを取り扱っていました。
ですがその後に続々とデバイスが増加しました。
製品名 | 詳細 |
---|---|
bitlock MINI | bitlock LITE の後継機 |
bitlock GATE | マンションのエントランス等の自動ドア対応のデバイス |
bitlock GATE for Elevator | エレベータの制御盤と連動して利用可能な階数の制御も行うデバイス |
bitreader+ | bitlock MINIなどのスマートロックと合わせて利用することで、NFCカードやパスコード(テンキー)で解錠することを可能とするデバイス |
bitlink | 各種デバイスをネットワークに繋げて遠隔操作や状態の取得を可能とするデバイス |
bitbutton CARD | bitlock MINIなどのスマートロックと合わせて利用することで、ボタンをクリックするだけで解錠することを可能とするデバイス |
homehub entrance | マンションのエントランス等を顔認証で解錠することを可能とするiPadアプリ |
他社様製品の電気錠 | マンションなどに組みこまれている電気錠 |
...他多数... |
もちろんHardwareは別で、かつ中身のFirmwareも異なります。製品によっては利用できる機能も異なり、またデバイスと通信するためのBLE通信のIFも異なります。
特に他社製品の電気錠と連携する場合には他社ごとの独自機能がある場合もあり、これらを統合的に管理することが難しくなってきてしまいました。
3-3. 解錠方法とソリューションとしての機能の複雑さの増加
当初は、モバイルアプリからの解錠のみを取り扱っていました。
その後、NFCカードやパスコード、顔などでも解錠することが可能となりました。
特にパスコードは、常に特定のパスコードで解錠することができる固定パスコードだけでなく、Google Authenticationのように時間経過に伴って一定の間隔で更新され続ける TOTP などの取扱もふえました。
特にパスコードは不動産業界でスマホを保持しない業者が解錠するために一つのソリューションとなり得て、内見予約 / 現状回復工事 / 宅配 … さまざまなシチュエーションで、利用される解錠手段となりました。
各利用ケースごとにパスコードの利用する際のロジックが集約されていない結果、保守が煩雑となってしまう…といった事象も発生していました。
3-4. 組織 ⇔ 個人 / 組織 ⇔ 組織 を連動して生み出す機能の増加
もともとは個人のみでの利用だけでした。その後B to B to Cでの利用が始まりましたが、
入居契約に伴って個人にカギを発行した後には、個人としての利用として独立させることができていたためそこまで複雑に感じることはありませんでした。
その後、個人が保有しているNFCカードで組織が管理しているデバイスを解錠できるようにする機能や、管理会社が企業に社宅として物件を貸し出し、その後企業が社員に物件を割り当てていくといった形態が登場するなど、登場人物間のリレーションが複雑化するようになってきました。
3-5. メンバーの知識格差
単純に領域が広いので、後から参画したメンバーや業務委託のメンバーとの間に、ドメイン知識の格差が発生しました。
ドメイン知識を習得するのも大変な状況となっていました。ドキュメントも断片的にしか存在しておらず、当時の実装者のみが知っている暗黙的な仕様等も存在していました。
仕様を適切に把握するためにはソースコードを読み込まなければならず、かつソースコードも膨大で大変…という状態に陥ってしまっていました。
4. おわり
まずは、長文となってしまった記事を読んでいただきありがとうございます。
記事を作成し始めた時点ではここまで長文にするつもりはなかったのですが、気づいたら..けっこう長くなってしまっていました..。(…なお投稿直前はこの2倍の分量でした…ww)
4-1. まとめ
ビットキーのHome領域におけるドメインを事業フェーズに移り変わりと合わせて記載しています。
実際に事業フェーズを進むにつれてドメインがどのように進化してきたかと、発生した課題について私の所感をまとめています。
ここで取り上げた課題を考慮した上で、新規機能の開発/モデリングをどのように取り組んだかと別記事にまとめて後日公開予定です。
4-2. 感想 / 学び
実際に本記事を記載するにあたって、すらすら記載することができず、つまづきながら言葉を選び考えながら記載をしています。自身が常日頃開発しているプロダクトの説明なのに、すらすら記述することができない…というのは「ドメインの理解」や「言語化」においてまだまだ精進する余地があることの示唆だと考えています。
普段何気なく取り込んでいる開発で扱っているドメインを言語化する過程で学びも多くあり、まだまだ未熟な部分があったと感じることができました。今後も「ドメインの理解」や「言語化」において精進していきます。
4-3. 余談
今ふりかってみて、事業の創業期からこのモデリングの仕組みないしはDDDをとりいれたほうが良かったか?という問いに関しては「NO」だと考えています。
homehubという概念が爆誕し、対象のビジネススコープが大きく変わったタイミングで仕組みを考え直す選択は考える価値があったと考えていますが、初期はどうしても速度が求めれらるのでこの仕組をそのまま取り入れられるかと言われると「難しい」「手続き型で実装したほうが価値をだせていた」と感じています。
「事業フェーズごとに最適な戦略は異なる」ということと、「ターニングポイントにおいていかに先んじて戦略を変える舵きりをすることの重要性」の2点が重要であると
4-4. sudoモデリングの宣伝
本記事に記載しているドメインをベースに、「入居/空室モード対応」という機能の開発をすすめる際に sudoモデリング
を実践した実例を別記事にまとめていますので、ぜひ読んでみてください。
できるかぎり実際に利用した資料をそのまま利用しているので、かなり具体的な内容となっています。
※ sudoモデリング
とは、松岡 幸一郎さんが提唱しているモデリング手法です。システム相関図(S)、ユースケース図(U)、ドメインモデル図(D)、オブジェクト図(O)の4つを用いて行う手法です。詳しくはこちらの記事を御覧ください。
-> こちらは冒頭に記載している通り、後日公開予定です。
4-5. 勧誘
ビットキーの事業内容に興味をもって、一緒によいプロダクトに洗練させていだける方!募集しています!!!!
明日の21日目の株式会社ビットキー Advent Calendar 2022は、VPoP所属の町田(@machdia)が担当します。お楽しみに!!
-
時系列はざっくり全体を理解しやすい粒度で引いていますので事実と多少異なる場合があることをご了承ください。 ↩