10Xに技術的負債をもたらした「2つの境界の歪み」その構造と解消への営み

by 10xinc

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

技術的負債とは何か ● 技術的負債は、同じ開発コストあたりで生み出せる価値を低減させるもの。 ● 技術的負債は、開発自体に使える時間を低減させるもの。 ● 結果、技術的負債が増えると、その返却に当てる時間を取ること自体が難しくなる現実には、開発によって資産を作り出し、その資産が価値(売上)をもたらすので、より複雑なモデルとなる- cf. ソフトウェアと財務 10X, Inc. ALL RIGHTS RESERVED 11

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

何が技術的負債を生み出すのか技術的負債を助長する構造ソフトウェアを開発する組織内での責務(境界)の問題 ● 開発チームがオーナーシップを持って判断できない ● 負債のツケを、開発したチーム自身が払う構造になっていない ● 短期的な意思決定に寄りがちになるソフトウェアの利用者との責務(境界)の課題 ● 小売業だけで業務が完結できずオペレーションが必要になる ● 調査の問い合わせが来る 10X, Inc. ALL RIGHTS RESERVED 14

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

チームの責務境界実際どうだったか？良かった点: ● パートナーに寄り添った意思決定/開発ができた。 ● ビジネスサイドと開発チームが密にコミュニケーションしパートナーの課題を柔軟に解決することができた。 ● 実際に調査や要望に答えるスピードは上がった。課題となった点: ● 短期的に要望に答えるため、時に保守や長期的な観点を欠いた機能開発が行われた。 ● 対象とする業務の知識が開発チームに蓄積されない。 ● 開発した機能のオーナーシップを持ちきれない状態になった。 10X, Inc. ALL RIGHTS RESERVED 17

Slide 18

Slide 18 text

チームの責務境界オーナーシップを持ちきれない、とは？ ● ● ● ● ある機能を作った開発チームがそれをリリース後に運用し続けるわけではない。「運用でツケを払うのが開発したチーム自身」という構造になっていなかった。長期的に機能としてどうあるべきかを考えた上でNoを言うことが難しい。結果、局所最適な実装が多くなる。業務の理解よりも、目の前の課題を解くことにフォーカスする。 10X, Inc. ALL RIGHTS RESERVED 18

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

チームの責務境界実際どうなったか？良かった点: ● 開発チームが業務の知識を深める動きを取りやすくなった。 ● 長期的なトレードオフを意識した上で、開発チームがスタンスを持って意思決定できるようになった。 ● 調査や運用のコストを下げるための提案や開発がチームから出るようになった。課題となった点: ● 個別パートナーの短期的な要望に寄り添ってタイムリーに答えることは難しくなった。 10X, Inc. ALL RIGHTS RESERVED 21

Slide 22

Slide 22 text

チームの責務境界短期的に早く要望を満たせないことについて ● ● 短期的に早く個別の要望に向き合えたとしても、長期で見ると結局要望を満たすためにかかる時間は増大する（開発にかかるコスト / 保守のコストが増える）。長く事業を続けることが前提として成り立つのであれば、初手から将来のコストが増えない作り方をした方が、結果より多くの要望を満たすことができるはず。 10X, Inc. ALL RIGHTS RESERVED 22

Slide 23

Slide 23 text

チームの責務境界チームの構造によってすべてが解決したのか？ ● ● ● ● No。構造は問題を解決しやすくする方向づけをするが、それによって解決するわけではない。各開発チームがソフトウェアの保守性を下げる要素を整理したり言語化し、1つずつ向き合って解決してきた。その改善に時間を割く、という組織としての意思決定は必要。また、期待する開発に時間を割くことができる状況かのヘルスチェックも定期的に実施する必要がある。 10X, Inc. ALL RIGHTS RESERVED 23

Slide 24

Slide 24 text

Slide 25

Slide 25 text

チームの責務境界顧客別のチーム構造の再考余地 ● ● ● 10X, Inc. ALL RIGHTS RESERVED この形も当然事業や組織の状況によって成立し得る。ただし、組織やソフトウェア上に境界/ガードレールがないと、容易に個別性がプラットフォームを侵食する。プラットフォームの外側と内側の境界をソフトウェア上でも明示的に設計し、 IFや契約を介して個別性を外側に配置できるなら成り立つと考える。 25

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

顧客との責務境界何に時間を割いていたのか？ ● ● 機能の改修や開発以外の保守に、多くの時間を割いていることがわかった。イレギュラーな調査やオペレーション（イレギュラーといいつつ、実際には定常的な業務になっている）。イレギュラーな作業の例 ● ● ● 一定の頻度で必要となる手動オペレーション。コード内にハードコーディングされた設定値の変更。内部データを確認する必要がある調査依頼。 10X, Inc. ALL RIGHTS RESERVED 29

Slide 30

Slide 30 text

顧客との責務境界レギュラーなイレギュラー作業 ● ● ● ● ● アプリケーションの仕様やコードで表現されていない業務。アプリケーション上でガードレールを設計できず事故りやすい。想定しなかったステータスやデータの状態になりかねない。アプリケーションで担うべき業務がアプリケーションで表現されていない、というモデリングの負債とも言える。（アプリケーションで担うべきではない業務を持っているが故の負債、もある。） 10X, Inc. ALL RIGHTS RESERVED 30

Slide 31

Slide 31 text

顧客との責務境界レギュラーなイレギュラー作業はどこから生まれる？ ● ● ● 開発のタイミングでは想定できなかった業務や概念が運用に入ってから発見される。最初はイレギュラーなように見えるが、実はその業務を行うためには一定の頻度で必要な業務であることが多い。これをイレギュラーという認識のまま責務を明確にせず対応すると、どこかで歪みが来る。 10X, Inc. ALL RIGHTS RESERVED 31

Slide 32

Slide 32 text

顧客との責務境界歪みを正すために - 責務の境界を再設計する ● ● ● 10X, Inc. ALL RIGHTS RESERVED アプリケーションの利用者とアプリケーションの責務の境界を改めて明らかにする。そのために、イレギュラーだと捉えていた業務を改めて理解した上で、ソフトウェア上にモデリングする。技術的な修正だけではなく、仕様やアプリケーションの利用方法を含めた線引きの調整が必要になる。 32

Slide 33

Slide 33 text

顧客との責務境界事例1. 配達エリア移管オペレーションネットスーパーが店舗ごとに持っている「配達エリア」を移管する機能。例えば新しい店舗がオープンしたとき、近隣店舗のユーザーの担当店舗が変更になる。各種データの変更、ユーザー通知が必要となる。当初はこの業務を織り込んでいなかったため、必要に応じて手動オペレーションで対応していた。後に業務フローを整理した上で、正式なアプリケーションの機能として組み込む意思決定をした。エリア移管、と呼ばれる定常業務が存在するならばそれはアプリケーションの機能として提供されるべき。本来アプリケーションが持つべき責務を、開発チームの手動オペレーションによって担っていた事例と言える。 10X, Inc. ALL RIGHTS RESERVED 33

Slide 34

Slide 34 text

顧客との責務境界事例2. 決済失敗時の手動徴収業務クレジットカード決済で避けられないエラーが発生した際、小売スタッフが代金を手動で徴収する業務が存在していた。この業務や状態の管理がシステムの外で行われていたため、想定外のデータ状態や開発チームによる手動オペレーションが一定頻度で発生していた。該当の決済エラーを準正常系の業務として扱い「手動徴収が必要」という状態をステータスに組み込んだ。結果、アプリケーションの想定した状態遷移に沿って業務を完結できるようになった。本来アプリケーションが持つべき責務を、顧客企業の手動オペレーションによって担っていた事例と言える。 10X, Inc. ALL RIGHTS RESERVED 34

Slide 35

Slide 35 text

顧客との責務境界事例3. 掲載商品データの不具合調査小売企業の基幹システムから商品データを取り込み、売場に表示する工程で「なぜこの商品は表示されないのか」「なぜこの価格になるのか」という問い合わせが頻発していた。これを解決するために、10Xが担っていた小売企業ごとの個別データパイプラインを標準インタフェースを介したものに移行し、責務の境界を動かす、共通の中間生成物をデータベース上に残すといった改修を実施。現在は、この中間生成物を小売企業が閲覧できるよう開発を進めている。個別性を受け入れるためにまず必要だったのは、個別の実装ではなく共通インタフェース。本来顧客企業のアプリケーションが担うべき責務を、我々のアプリケーションが担っていた事例と言える。 10X, Inc. ALL RIGHTS RESERVED 35

Slide 36

Slide 36 text

顧客との責務境界これらは技術的負債と言えるのか？広義には言えると考える。業務を理解し、その概念を蒸留した上でモデリングすることがソフトウェア開発・エンジニアリングであるとするならば、適切ではないモデリング・不足したモデリングは技術的負債とも言えるのではないか。機能開発時の業務の理解不足や考慮不足の結果、あるべき境界で責務を切ることができなかったがゆえの負債である、と捉えることはできる。 10X, Inc. ALL RIGHTS RESERVED 36

Slide 37

Slide 37 text

Slide 38

Slide 38 text

顧客との責務境界言葉の発明 - 運営自律性 ● ● ● 「ネットスーパーの運営を小売企業で完結させるための機能が揃っているか？」を意味する言葉。保守性に向き合うタイミングで誕生し、社内では浸透している。この「運営自律性」という言葉があることによって、仕様や設計の時点でその運営まで含めて正しい責務を設計できてるか？を意識しやすくなっている。 10X, Inc. ALL RIGHTS RESERVED 38

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

おわりに生成AIと境界の課題 ● ● ● ● ここまで話したような境界の課題は、生成AIで開発コストが下がる世界では課題とならないのでは？初期的にはYes。ただし、構造が誤っていれば結局コストは増え続ける。コストは無くなったわけではない。トークンという形で支払うことになる。ある意味、初期にサインが見えづらくなるので、より注意深くなる必要があるのではないか。 10X, Inc. ALL RIGHTS RESERVED 41