主にソフトウェアについて社内の既存のソフトウェアに対する競合技術が社外に現れたと感じた時の判断する目安について妄想してみた。 関連して新たに社内で開発する前に検討する事も考えてみた。

ミドルウェア・プラットフォームを内製するか迷ってる

既に社外に類似サービス・ソフトウェアがあるか調査して存在しなければ内製すればいい。 要望・要件と目的を整理して検索して出てきたシステム・サービスを列挙する。 満たせている/満たせていない、をカタログ的に分類する。目的や要望・要件に変更を加えられないか検討する。 変更を加えた時のデメリットを検討する(一般化できずに社内で使いまわせないなど)。

要件や要望が類似している場合には内製根拠が必要になる。 利用に際してライセンス料・サービス利用料が大きい、検証によって要件を満たせない事を示すの2択が考えられる。 検証によって要件・要望を満たせない事が示されたら、更に提案や要望による貢献で解決できないかも確認する。 長期的にみて改善しそうでも期日に間に合わない場合で、更に内製で間に合うと判断できる場合はそれを採用する。

• 最適化の方向が異なり改善提案は成立しない
• アーキテクチャ的な問題により長期的に改善が見込めない
• 要望をコントロールできない。

内製してみる

社外エコシステムを取り込みやすい様に開発する。

既に独自開発していて競合(ソフトウェア・サービス)が力を付けてきた

気づいたら早めに課題を指摘して社内技術を公開して共存できる様にする。 これがコミュニティを育てて社内技術のレガシー化を防ぎつつ開発リソースをアウトソースするのに繋がる。

公開する内容の選択肢

4つの選択肢をを考えてみた。2つ目以降は(少なくとも間接的に)インタフェース公開が含まれる。 インタフェースについてはエコシステムに貢献して強い立場を作ったり、社内技術がガラパゴス化しない様にできるかを左右するので慎重に扱いやすく外部との相性も良くなるように整理しておく必要がある。

• 課題 + 方法(特許, 論文, 白書, 記事)
• 課題 + 方法 + インタフェース
• 課題 + サービス (+ インタフェース)
• 課題 + ソフトウェア (+ インタフェース)

公開する前に、内製ソフト・プラットフォームで満たしていて社外で満たせていない要件や要望や課題について整理する。

下手なものを公開できないけど早めに貢献したい

関連する内製ソフトウェアの要望・要件から外部と共通の一般化できるばしょを確認する。 外部では満たせない項目は何に依存しているのか調査する。 一般化ができたり自然に辿り着く様な事であれば上述の4つの選択肢などを実践して貢献するのが良さそう。

どの選択肢でも、技術力や主導権を維持してエコシステムが滅びないようにコミュニケーションを測るのが大事になる。 特にソフトウェア公開ではコミュニティの運用や宣伝が必要になったりとマネジメントコストが増す可能性がある。 コアコミッタやってた経験がある人がいたら聴いてみたい、案外そんなことないのかも。

社内要件というかアプリケーション要件がべったりな場合は要件整理のチャンスと考える。 整理の後で一般化されうる部分は、外部に貢献する社外システムを取り込みメンテナンスコストを押さえるか再び検討する。

社内開発をしつつ社外に対して孤立しないための技術マネジメントってこんな感じなんだろうなって思ってる。