先日、あるシステム開発のアーキテクチャー承認会議に参加しました。
内容としては、既存プロダクトからフォークしてOEMで開発するという提案。
技術スタックの話が中心になっていたのですが、私にはどうも違和感がありました。
「もっと前段の議論が足りていないんじゃないか」という感覚です。
技術スタックより先に問うべきことがある
OEM開発でプロダクトをフォークするということは、コードベースが二股に分かれるということです。
本流で追加された機能や修正を、OEM側にも取り込みますか？あるいは逆方向は？
これをどう運用するかを決めないまま進むのは、かなりリスクが高いと思っています。
会議でこういう質問をしました。
「多くの部分は本流のリポジトリから分岐して開発することになると思います。本流もしくはOEM側で対応した新機能追加や不具合対応は、もう片方にも吸収する方針ですか？これをどう対応するかの方針は開発コストに直接返ってくる部分だと思いますので、どこまでリスクを取る判断ができているのかという視点での質問です。」
技術スタックより引いた視点からの質問です。
フォーク開発において「コードの乖離」は中長期で最も重くなるコストの一つです。
両方に追従するなら二重メンテが発生する。追従しなければ乖離が進み、将来の統合やバグ修正が困難になる。その判断基準がないまま進めると、後から取り返しのつかない状況に向かいかねない。
だから、承認会議というタイミングで言わなければ意味がないと思いました。
OEMシステム開発で本当に論点になること
せっかくなので、OEM開発で論点になりやすい構造を整理しておきます。
コードベースの管理戦略（一番重い）
- フォークか、設定・プラグインで分岐させるか
- 本流との同期をどう運用するか
- 乖離が進んだときの収束コストをどう見積もるか
誰が何を所有するか
- 知的財産の帰属：OEM先が改修したコードはどちらのものか
- ライセンス：本流のライセンスがOEM提供を許容しているか
- データ：OEM先で生成されたデータの権利
カスタマイズの範囲と統治
- どこまでOEM先がカスタムできるか（UIだけか、ロジックまでか）
- OEM先の要望を本流に取り込むかの判断基準
リリースとバージョン管理
- 本流とOEM側のリリースサイクルの同期
- セキュリティパッチの適用義務をどう扱うか
時間軸で整理するとこうなります。
graph LR
A[短期コスト] --> B[カスタマイズ範囲・テスト責任]
C[中期コスト] --> D[コードベース乖離・バージョン管理]
E[長期リスク] --> F[IP帰属・競合化・契約終了時の処理]
今回の承認会議では、この中期〜長期リスクの議論が抜けていたように見えました。
「下請け思想」の問題
会議全体を通じて感じたのは、ビジネスサイドから来た要求に対して開発サイドが「下請け思想」で動いてしまっているのではないかということでした。
ビジネス側は「OEMで展開したい」という意図を持っています。
ただ、それを実現するときに何が起きるかを具体的にイメージできるのは開発サイドだけです。
リスクを知っている側が言わない ＝ リスクが存在しないことになってしまう
という構造になります。
「作れます」「作れません」ではなく、**「こうすると後でこうなりますが、それでも進めますか？」**という問いを立てるのが本来の役割だと思っています。
短期の誠実さと中長期の誠実さ
ここで一つ引っかかりがあります。
ビジネスの要求に素早く応えることが責任を果たすことだと信じているエンジニアは、誠実なんですよね。
決して悪意があるわけじゃない。むしろ真剣に役割を果たそうとしている。
でも、その誠実さは中長期で見たときに本当に誠実だと言えるのかという問いが残ります。
短期の誠実さと中長期の誠実さは、時に矛盾します。
言われたことを速く正確にやることは、短期では誠実です。
でも、それが後で大きなコストや問題になったとき、チームやプロダクトに対して本当に誠実だったか。
本当の誠実さは、言いにくいことを言うことを含むんじゃないかと思っています。
「取り返しのつかない」という判断軸
今回会議で発言したのは、「この論点を押さえないまま進むのは後からリカバリーできないことに向かいかねない」と思ったからです。
取り返せるものは後で修正できる。
でも、アーキテクチャの方向性やフォークの判断は後から覆すコストが極めて高い。
だから承認会議というタイミングで言わなければ意味がなかった。
会議後に「あの点、自分も気になっていた」と言ってくれた人が何人かいました。
同じことを感じていたけど言えなかった、という人は一定数いたと思います。
言えなかった理由は色々あるでしょう。自分の役割じゃないと感じていた、場が止まる責任を取りたくなかった、など。
でも「気になった」止まりだったのは、もしかするとそれが取り返しのつかない方向に向かうリスクだとまでは認識されていなかったからかもしれません。
承認会議で問いを立てるということ
直接指摘して止めるのではなく、質問を通じて考えさせるというのが承認会議での問いの役割だと思っています。
その問いが場に残ることで、エンジニアが「その視点が必要だった」と気づく。
次回から自分たちで考えるようになる。
会議自体の質が上がっていく。
「なぜその質問をしたか」の意図は、質問の言葉の中に込めた方がいい。
今回は「開発コストに直接返ってくる」「どこまでリスクを取る判断ができているか」という形で含めました。
問いの背景が見えると、同じ視点を次の人も持てるようになります。
こうした場での問いの積み重ねが、組織の「当たり前」を少しずつ変えていくのだと思っています。
すぐには変わらない。でも、確実に効いていく。
参考書籍
技術組織における意思決定やリーダーシップについて、以下の書籍が参考になります。
[📦 商品リンク: moshimo-card-TxhLL]
アーキテクチャの設計判断を体系的に学びたい方にはこちらもおすすめです。
[📦 商品リンク: moshimo-book-MxbAm]