【開発生産性カンファレンス 2025】整頓のジレンマとの戦い 〜Tidy First?で振り返る事業とキャリアの歩み〜

ビットキーの開発部長が語る『Tidy First?』

佐藤：ビットキーの佐藤です。本日は、私個人の経験を振り返りながら『Tidy First?』観点でどうだったのか、についてお話しします。

ちなみに、私はここ1年間で25kg減量しました。個人の開発生産性向上の取り組みとして、減量も兼ねて生活習慣の改善に取り組んでいます。



半年ほどこのような生活を続けて、体が軽くなり非常に動きやすくなりましたし、頭もよく働くようになった気がしています。
そんな話はさておき、ここからは『Tidy First?』の内容を振り返っていきたいと思います。『Tidy First?』は、実践的なアプローチが豊富にまとめられており「整頓」という簡単に実践できる取り組みを掲げている書籍です。

個人的には「ディスカウントキャッシュフロー」「オプショナリティ」といった経済的な視点での判断軸に触れているところが面白いポイントでした。



『Tidy First?』の目次に書かれているものの中で、本日は第3部の「オプション vs キャッシュフロー」の内容を深掘りしながらお話ししていきたいと思います。

そもそも「キャッシュフロー」とはなんなのか？　キャッシュフローについて、書籍の中では「『お金』と『時間』の価値は一緒ではない」「時間が経過するほど価値は下がる」と書かれています。



これをソフトウェア開発に置き換えると「より早く、より高い確率で、より多く価値を提供する機能をリリースする」「より遅く、より低い確率で、より少ないリソースで実現する」と言えます。つまり「できるだけ早く価値を提供し、整頓などのコストがかかることは後回しにしましょう」と言われているわけです。

それと対をなすのが「オプション」です。「（容易に実現可能な）機能拡張の選択肢があるか」「実装しなくても選択肢があることが価値」だと書かれています。

オプションを下げるケースとしては、下記のようなものが挙げられています。

・重要な従業員が辞める→変更に時間がかかるようになった
・顧客との距離を置く→刺激的な提案を受ける機会が減ってしまった
・変更コストが跳ね上がる→リリース頻度が落ちてしまった
『Tidy First?』では、3番目のケースに対して、整頓を通して改善を試みているのだと思います。

オプションについては、下記のような4つのようなことを実現できると、より良いと言われています。



個人的にはなんとなくわかるのですが、一番上の「振る舞いの変更の価値が変動する可能性が高ければ高いほど良い」というのは、なぜそう言えるのかを改めて考えてみました。

書籍の翻訳者の一人である細澤 あゆみ氏による講演「Tidy First? ―個人で実践する経験主義的ソフトウェア設計 」の内容が分かりやすかったため、引用しながら説明します。



A君が企業Cの株式を購入する場合、もともとの株式は1株1000円でした。1カ月後には市場価格が上がるかもしれないし、下がるかもしれませんが、1カ月後に1000円で購入できる権利を50円で買う。権利を行使するかしないかはA君の自由です。こういったものをオプション取引と呼びます。

1カ月後に1200円になった場合、権利を行使すればプラス150円です。800円になった場合は、権利を行使する必要はないものの、権利料はすでに支払っているためマイナス50円です。

この振れ幅がさらに大きくなり、1400円と600円になったらどうなるのかというと、前者はプラス350円で、後者はマイナス50円です。どれだけ市場価格が下がったとしても、権利料より低くなることはありません。

これを鑑みると「変動が大きいほどリターンが見込める」 と言えると思います。つまり、オプションの価値が高くなるのは、 価格変動性（ボラティリティ）が大きい場合です。『Tidy First?』でも「振る舞いの変更の価値が変動する可能性が高ければ高いほど良い」と書かれています。

また、残存期間（権利獲得から行使までの時間）が長ければ長いほど、大きくブレる場合もあれば小さく低くブレる場合もあるため、オプションは高くなります。「開発を長く続けられるほど良い」というのは、ここに起因しているのではないかと思います。

このような特性を持つオプション、つまり容易に実現可能な機能拡張の選択肢があること自体は価値があるオプションです。

しかし、先ほども少し触れた通り、オプションとキャッシュフローは相反するものです。キャッシュフロー観点では「より早く確実にお金を稼ぎ、後でお金を使う。先に整頓はしない」ですが、オプション観点では「今お金を使って、後でお金を稼ぐ。絶対に先に整頓をする」とされている。

このバランス感覚をどう取るか、が問題です。書籍では「整頓のコスト＋整頓の後に変更するコストが、整頓せずに変更するコストよりも下回る場合は先に整頓する」と書かれています。しかし、これが逆の場合は「完全に判断の領域」だと書かれています。

「完全に判断の領域」だと言われても、困りますよね。そこで今回は、完全に判断の領域という部分を、私自身の過去の経験を元に振り返ってみたいと思います。

振り返りをする前に、ビットキーの事業成長についてもお話ししておきます。ビットキーは2018年創業の会社で、2021年以降、4年連続でネクストユニコーン企業トップ20に選ばれています。「つなげよう。人は、もっと自由になれる。」を、ミッション・ビジョンとし「リアルとデジタル間の体験の分断」の解決に挑戦しています。

「リアルとデジタル間の体験の分断」とは、デジタルが進化してソフトウェア上で良い体験ができたとしても、物理世界に訴求できない限りは突破できない部分があるという問題です。突破できないものの1つが「扉」であり、それを解決するために、私たちはスマートロックという手段を提供しています。

SNSで良いコミュニケーションが取れたとしても、扉は開きませんし、扉が開かなければ家には入れません。このようなリアルとデジタル間の体験の分断を解決し、より良い世界を実現したいと考えています。現在は、homehub（暮らし）、workhub（仕事／働く）、exphup（非日常体験）という3つの領域で事業開発をしています。

探索期～変革期まで、各フェーズで何が変わったのか？

佐藤：ここからは、私が2019年の5月に入社したところから現在までの会社の成長過程を、探索期（2019年5月-2020年12月）、拡大期（2021年1月-2023年6月）、変革期（2023年7-2025年6月）に分けて、各フェーズごとに何を考えていたのか？　『Tidy First?』の観点ではどうだったのか？　についてお話しします。




探索期での私の立場と事業状況はこちらです。この時に意識していたのは、『Tidy First?』の第1部の整頓（一部）と第3部の理論（オプション／キャッシュフロー）です。第1部の整頓（ステートメントの小分け、ヘルパー抽出など）や第2部の管理術、第3部の理論（結合／凝集）については意識していませんでした。

もう少し深掘りしていくと、探索期は非常にカオスな状況下で、オプションの価値が非常に高い状態でした。オプションにはいくつかの種類があると思いますが、このタイミングにおいては「すぐに価値提供できる」ことが非常に重要でした。複雑な機能の優先度は低く、限定的であっても動くことが重要で、2～3週間かければできるといったものは価値が低かったのです。

これを実現するために、私は共通化・汎用化を同時に実現できる動き方を優先していました。一方で、今後の展開を中期的に見た時に、明らかな負債とならないように、コアとなる概念の整理や設計は重視していました。



拡大期については、私の立場も変化し、チームや組織の状況も変わっていきました。

『Tidy First?』の観点では、チームや持続可能性といったところは意識できていなかったかもしれませんが、第1部～第3部まで全て必要になったタイミングでした。特に第3部においては、結合／凝集が非常に重要でした。

依然としてカオスな状況で、オプションの価値は高いとはいえ、探索期に比べて中期的に価値を発揮し続けることが重要になっていました。求められる機能の複雑さも増しており、安易な共通化・汎用化はデメリットにつながることが多くなりました。事業拡大に耐えられるよう結合／凝集の考え方が非常に重要になっていて、戦略的な大きな整理も求められていました。



変革期では、会社の運営方針も変わりました。

『Tidy First?』の観点では、第1部～第3部まで全て重要で、プラスの要素としてチームや開発プロセスの観点も意識していました。特に結合／凝集や持続可能性といったところが重要だったと思います。オプションの価値については、まだまだ重要ではあるものの、過度な実装は不要となりました。持続可能な状態を実現するために、属人性の低減やチーム／組織として動きやすい状態をつくることが重要になりました。探索期や拡大期の短期／中期的な視点から、長期的な視点に変化し、将来への投資の重要度が増していきました。

探索期はできるだけコストをかけず、短期的にリターンが得られるものに対して投資をしていました。拡大期は徐々に中期的な目線で戦略的に投資をし始めて、変革期は長期的な視点で積極的に投資をしていく形に変化してきました。

短期的なオプションの価値が高い、カオスな探索期での取り組み事例

佐藤：ここからは各フェーズの具体的な取り組み事例を交えて、『Tidy First?』のオプションやキャッシュフローの観点でどうだったのかを振り返っていきます。

最初にお話しするのは、探索期で取り組んだ「ECサイトのクーポン対応」です。



この時に私は、できるだけ汎用的に設計するとともに、今後利用されるであろう機能も合わせて実装しました。ただ、クーポンの発行画面などの一部機能はスコープアウトしました。

ユーザーやクーポンごとに利用回数があるかもしれない、特定の料金以上などの適用条件があるかもしれない、調整金額は料金全体から固定率／固定金額の割引なのか特定の商品や送料に対してのみ割引くのか……様々なパターンを整理して分類しました。実際には、特定のユーザーで1度だけ指定金額で割り引きするという内容だったのですが、全体の設計は汎用的にしつつ実装しました。

『Tidy First?』の観点で言うと、オプションでは直接的な要件だけでなくクーポンとして求められる機能を想定して設計し、概念整理をした上で同時にできる部分は合わせて実装しました。

キャッシュフロー観点では、どうしてもコストがかかってしまいますが、コストを抑えるためにスコープを限定し、クーポン登録画面は除外しました。後からの変更が大変なDBは事前に丁寧に設計し、実装はできるだけコストをかけずサクッと実施しました。

探索期においては「同時にできる箇所は合わせて実装した」という点が非常に重要だと思っていますし、結果として運用の幅が広がりました。実際に、新たなプロモーションを打つ、もしくはトラブルに伴い運用でカバーするといった際に、ビジネスサイドのみで意思決定して実行できました。低コストで実現可能／すでに実現可能であるというオプションは、探索期のような変動が非常に強いタイミングにおいて、非常に価値があったと思います。



次に紹介するのは「アカウントを持たない『子ども』が顔認証を使えるようにした」という事例です。

ここでは「子ども」の顔の管理について、会社全体で徹底的に議論しました。「子どもが成長してアカウントを自分で所有するようになる」「離婚などに伴う家族構成の変更」など、今後の展開で起こり得るユースケースを整理し、今後の機能拡張時に大きなボトルネックとならないような設計をしました。
実際の結果としては「家族」という概念を新たに導入し「家族」が「子ども」の情報を管理し「子ども」に顔情報が紐づくような実装にしました。

『Tidy First?』の観点で振り返ってみると、オプションという意味では、 中長期的な視点で機能拡張時の障害とならないよう大方針の設計に注力しました。必要な機能だけを見ればもっと簡単に実装する方法はありましたが、今後の展開を考えた時に「だれが」解錠手段を管理できるのかがビジネス上で重要な要素だったため、丁寧に実施しました。

キャッシュフローについては、大方針と概念の整理にはコストを払ったものの、実装自体は最小コストで実現しています。
結果として、顔認証ソリューションの提供は成功しました。先ほどお話ししたようなユースケースに対応する機能拡張の出番はまだありません。

「家族」という概念を新しく設けた結果、複雑化しておりメンテナンスコストもかかっています。しかし、中期的に見てリスクは冒せませんし、営業時に「弊社ではこういうことを想定して設計・開発しています」と言えるため、営業トークの武器になっているという意味ではプラスの面もあります。



簡単にまとめると、整頓にはあまり力を入れず、すぐ実行できる共通化・汎用化や、コアとなる概念の整理に力を入れていたのが探索期です。

結合／凝集への投資が重要になった拡大期の取り組み事例

佐藤：次に拡大期についてもお話しします。短期的だけでなく中期的に価値を発揮し続けることが求められるようになり、事業拡大したことで複雑さが増し、結合／凝集が重要になってきたタイミングです。

このタイミングで、リポジトリパターンを導入しました。



これを『Tidy First?』の観点で振り返ると、1つは結合／凝集です。インフラ層とDBの結合を低減し、インフラ層の処理をまとめることで凝集度を向上しました。

オプションという観点では、結合／凝集を改善することで機能追加や調査が容易化しました。一つひとつの効果は大きくないかもしれませんが、高頻度に触る領域であるため、トータルで大きなリターンが期待できると判断しました。

キャッシュフローの観点では、レイヤを追加するなど既存の構造を変えることになったため、初期的なコストは増えます。とはいえ、できるだけコストを抑えるため、可読性は多少下がりますが、継承クラスを使うといった工夫もしていました。

結果として、結合／凝集の観点では改善しました。ただ、継承クラスを使っていたため、認知負荷は上がってしまいました。最近の状況を考慮すると、AIに書かせた方が良いと思います。



戦術的DDDの導入にも取り組みました。事業拡大に伴いソースコードがスパゲッティ化してしまったため、低結合／高凝集を実現したかったのです。戦略的DDDはほぼ取り扱っておらず、実装コストを下げるために限定的な導入をしています。

『Tidy First?』の観点では、エンティティやバリューオブジェクト、ドメインサービスといったドメイン知識を集約させることで結合／凝集の改善を行い、修正箇所や影響範囲の判断における課題を解消しました。

キャッシュフロー観点では、実装量が増加することを懸念して領域を絞って導入しました。初期的な実装コストを抑えるため、継承クラスを使ってオブジェクト指向型のプログラミングを簡単にできるような状況をつくりました。

すぐに結果が出るものではありませんが、徐々に整い始めています。少なくとも、この取り組みがあったからこそ、現状の実装方針をより良い形で整理できていると思います。



アクセスコントロールの実装についてもお話しします。
上図に書いてあるような状況を改善するために「ヒト」「モノ」「空間」という粒度で大きく再整理しました。特に「モノ」については、解錠／認証／連携といった全てのデバイスに当てはまる、かつそれらの要素があればスマートアクセスというドメインが成立できる機能を抽象化して、大々的に整理しました。

そして、従業員の属性や来訪者がどの会議室で何時の予定があるか、そこに行くためにはどの経路が必要なのかといった情報から「いつ」「誰が」「どこに」アクセスできるかを判断し、解錠可能とするための処理を実行するサービスをつくりました。

『Tidy First?』の観点で言うと、結合／凝集が一番大きかったと思います。事業拡大に伴い必要となったコアドメインを新設し、コアとなる要素を大きく再整理しました。その結果、全体的に結合／凝集を大きく改善できたと思います。

オプションとしては、デバイスやユースケースが増えても低コストで対応しやすい状況を整備した結果、事業展開を大きく促進できたと思っています。

キャッシュフロー観点では非常にコストがかかっていますが、非常に大きなリターンが期待できるため、大きく投資をしています。ただ、会社全体の大規模施策であるため、概念整理は丁寧に実施し、コストをかける領域については慎重に検討して実行しています。

結果としては、その後のパフォーマンス観点などで大改修が入ったのですが、整理した概念自体は今のプロジェクトにも受け継がれています。ここで整理したことで、デバイスやユースケースの追加対応は、以前と比べて非常に低コストで安全に実施できるようになりました。



このタイミングのまとめとして、 中長期的なオプションの価値が高く、結合／凝集が非常に重要になりました。探索期と比べて中期的な視点で、場合によっては大きな投資もしますし、小さな投資は積極的にしていました。短期的なリターンの価値が相対的に下がったことと、機能が複雑化したことによって、このタイミングでは共通化や汎用化を積極的にしなくなりました。

持続可能性を高めるための変革期での取り組み事例

佐藤：変革期では、コトよりヒトを大事にする方針に変わり、持続可能性を大事にしようとしていました。

オプションを下げるケースとしてご紹介した「重要な従業員が辞めてしまう」について、拡大期まではケアできていなかったため、変革期ではこの課題解決に注力して整理を進めていました。



具体的な取り組みとしては、モブプロ／ペアプロを導入しました。属人性が極まっていて、新規メンバーの参入障壁が非常に高かったのですが、モブプロ／ペアプロの導入によって改善できました。

オプションとしては、属人性を低減してチームのアジリティを向上させることが目的でした。すぐに効果が出るものではないと思いますが、中長期的に持続可能なチームを構成できることを期待して導入しています。

キャッシュフロー観点では、一時的にチームの生産性が落ちることは許容しつつ投資しました。実際には、チームの生産性が大きく低下することなく実行できました。



そのほか、BDDやイベントストーミングといったフレームワークも導入しています。詳細については「『イベントストーミング』x『BDD』を『モブプロ』で実践したらめっちゃ良かった！」に書いておりますので、よろしければご確認ください。

オプションの価値として期待していたのは、特定のフレームワークに則って、チームやビジネスサイド／QAと一緒に整理をして一定の品質を安定的に出せるようにすることです。そうすることで、個人に依存せず持続可能な状態をつくることを、オプションの価値として捉えていました。

キャッシュフローとしては、以前と比べて実装前の準備にかかるコストが増大し、コストが大きく増えることが懸念されましたが、ここは一旦許容して投資をしています。実際にはコストが大きくかかることはなく、トータルのアウトプットとして不具合の発生率を減らすことができました。



ドメインの整理も再度実行しています。探索期や拡大期では、ドメインが整理しきれていませんでした。変革期ではドメインが見えてきて、かつチームで実現する上で全体の地図が描かれていないと動きづらいという課題感があったため、再度モジュールの整理をしました。

『Tidy First?』の観点で期待したのは、やはり結合／凝集です。ソースコードレベルで解決しきるのが難しい結合／凝集があっても、ドメインを再整理することで土壌を整える目的がありました。

このタイミングのキャッシュフローは、全ての実装を置き換えることはできません。これはまだ途中の段階ですが、順次実行することによって、限定的なキャッシュフローで実現しようと思っています。



変革期のまとめとしては、長期的な視点での投資や整理の価値が向上したため、実行しました。また、持続可能性のためにチームや開発プロセスの整備に投資し、結合／凝集を整えやすい土壌の整備も行いました。

短期的なリターンを優先した対応は非常に減りましたし、拡大期に続いて過度な共通化・汎用化は実施していません。

各事業フェーズが示す『Tidy First?』の最適な活用法

佐藤：最後にまとめます。

探索期においては、カオスな状況下であり、オプションに非常に高い価値があったと思います。一方で、キャッシュフローの観点でも非常にシビアで投資が困難でした。そのため、短期的な視点で低コストかつ最大のリターンが得られるようなオプションのみ実施していました。実際には、共通化・汎用化、概念の整理に注力して、ソースコードの整理は二の次だったと思います。

拡大期については、まだカオスが続いていて、オプションに高い価値がありました。しかし、短期的な視点ではなく、中期的な視点での投資ができるようになってきました。ドメインが複雑化し、結合／凝集と対する整理の価値が上昇しました。

変革期はコントローラブルになってきて、オプションには一定の価値があります。しかし、どちらかというと長期的な視点での持続可能性が重要で、チームやプロセス全体のドメインの整理が必要なタイミングだったと思います。

オプションの価値やキャッシュフローの視点で何に投資するかは、フェーズによって大きく異なります。本日の発表が誰かの今後の参考になったら良いなと思っております。

ご清聴ありがとうございました。



アーカイブ動画も公開しております。こちらも併せてご覧ください。

※ご視聴には登録が必要です