00:00:04 ソフトウェア・フランケンシュタイン化の紹介。
00:00:35 B2Bソフトウェアに対するソフトウェア・フランケンシュタイン化の影響。
00:01:31 顧客の要求がソフトウェア・フランケンシュタイン化にどのように影響するか。
00:02:32 ソフトウェア上の「傷跡」とその意味。
00:05:33 ソフトウェア・フランケンシュタイン化の維持費用。
00:08:00 新しいソフトウェア機能の課題と費用。
00:08:57 複雑さのない機能：B2Cにおける洞察。
00:10:36 B2Bアプローチによるソフトウェアソリューションの問題点。
00:13:18 Lokadの経験：正しさと迅速さ、そして技術的負債。
00:15:14 Envision：複雑性に対するLokadの解決策。
00:16:30 ドメイン固有のスクリプト：制約と衝突の回避。
00:17:43 サプライチェーンにおけるソフトウェアの肥大化への対処。
00:18:01 複雑なソフトウェアをシンプル化するための戦略。
00:20:54 ソフトウェアシステムにおける『技術的質量』の管理。
00:22:00 システム変更におけるIT、サプライチェーン、マーケティングの相乗効果。
00:22:43 過剰なソフトウェアカスタマイズの問題。
00:23:48 カスタマイズを通じたソフトウェアベンダーの信頼性のテスト。
00:24:00 製品開発戦略に対する影響力の獲得。
00:26:08 カスタマイズを避けるための、スリムで焦点を絞ったソフトウェアの選択。
概要
Lokad TVでは、ジョアネス・ヴェルモレルがソフトウェア・フランケンシュタイン化という概念を紹介しています。これは、B2Bソフトウェアが元の設計に沿わない行き当たりばったりの改修を通じて進化していく様子を指しています。彼はこれらの変更を『傷跡』に例え、複合的で進化したソフトウェアシステムの形成に寄与していると述べています。ERPsは一例として提示され、ソフトウェアアーキテクチャの維持と新たな要求への対応との間にあるジレンマが強調されています。ヴェルモレルは、急いだ判断がしばしばソフトウェアに傷跡を残し、保守費用を増大させる結果につながると警告しています。ソフトウェア管理における避けられない複雑性を認めながらも、彼はB2Cモデルから学んで機能間の相互作用をコントロールする重要性を強調しています。Lokadはこの問題に対して、「Envision」という、インフラストラクチャの問題とドメイン固有の問題を分離するドメイン固有のプログラミング言語で応えています。
詳細な概要
最新のLokad TVのエピソードでは、会話がソフトウェア・フランケンシュタイン化という概念を中心に展開されます。これは、Lokadの創設者であるジョアネス・ヴェルモレルによって提唱された用語で、B2Bソフトウェア、特に長寿命かつサプライチェーンソフトウェアが、ソフトウェアベンダーとそのクライアントとの間で継続的な交渉や大規模な契約を通じて進化していく様子を描写しています。
ヴェルモレルは、ソフトウェア・フランケンシュタイン化は、顧客の要求に応じた調整が行われるときに起こると説明しています。これらの変更は、しばしば元々のアーキテクチャ、理念、設計と一致しません。その結果、ソフトウェアはこれらの改変、つまり『傷跡』を時間とともに蓄積し、ヴェルモレルが『フランケンシュタイン・モンスター』と呼ぶ、複合的で奇妙に進化したシステムへと変貌してしまうのです。
さらに彼は、この現象が特にサプライチェーンソフトウェアに顕著である一方で、多くのB2Bソフトウェアにも一般的に見られると指摘します。それにもかかわらず、『傷跡』という用語が必ずしも否定的なものと誤解されるべきではないと明言しています。これらの改変は、新たな機能を追加することでソフトウェアを強化し、その機能性を向上させる可能性があるのです。
ヴェルモレルは、エンタープライズリソースプランニング（ERP）ソフトウェアの例を挙げ、季節性が固定された52週間のプロファイルを用いることで捉えられるという前提について説明します。この設計は、旧正月、ラマダン、イースターのように、異なるカレンダーに従い年ごとに日付が変動する需要が生じない限り、うまく機能します。
このような場合、ソフトウェアベンダーはトレードオフに直面します。必要な機能を提供するために、ソフトウェアのアーキテクチャに完全には適合しない「ハック的」な解決策を統合することで新たな需要に対応します。しかし、この方法はしばしばさらなる『傷跡』を生み出し、ソフトウェアのフランケンシュタイン化に拍車をかける結果となるのです。
ソフトウェアビジネスにおける主要顧客との交渉が急速に進むことを強調しながら、ヴェルモレルはその緊急性が思わぬ形で『ソフトウェアの傷跡』を招く可能性があると警告します。彼は、急ごしらえの機能実装が時間とともにソフトウェアの複雑性と保守費用を増加させるプロセスであると定義しています。
ソフトウェアアーキテクチャの複雑さを説明しながら、ヴェルモレルはコードの一行一行や各機能には保守が必要であると指摘します。機能が追加されるごとに相互の接続が複雑になり、いわゆる「二次的複雑性問題」を引き起こします。基本的に、部品の数が増えるとその潜在的な相互作用の数は指数関数的に増加し、バグ、クラッシュ、セキュリティ脅威など、さまざまな問題の温床となるのです。
ヴェルモレルは、機能間の相互作用の数を制御するためには、綿密なソフトウェアアーキテクチャがいかに重要であるかを強調します。彼は、機能の数が倍増した場合に必要な保守作業量を倍増に留めるべきであり、急いで開発された場合にしばしば発生する4倍以上の増加とは対照的であると述べています。
ソフトウェア企業が新機能を過度な複雑性を増すことなく導入する方法について問われた際、ヴェルモレルはGoogleやNetflixのようなB2Cソフトウェア企業から学ぶことを提案します。彼らは解決すべき具体的な問題を十分に理解し、類似の問題群に対応するソリューションを設計するための時間をかけています。これに対し、B2Bの世界では、顧客が問題だけでなく自ら解決策を提案してくることが多いのです。
これらの問題に対してLokadがどのように対処しているかについて、ヴェルモレルは、物事を正しく行うことと顧客の要求に迅速に応えることのバランスをとるのに苦労した初期の取り組みを明かします。彼らは初期の頃に増大する技術的負債に気づき、これを有害なものと認識しました。個々の顧客を満足させるために機能を追加することは短期的には有益に見えるかもしれませんが、結果として長期的には複雑で一貫性がなく、管理が困難な製品につながることが明らかになったのです。
この認識を受けて、Lokadは独自の解決策を考案しました。それが「Envision」と呼ばれるドメイン固有のプログラミング言語です。Envisionの目的は、インフラ面の問題とドメイン固有の問題を分離することで、過度な複雑性を増さずに新機能の追加と保守をより効果的に管理できるようにすることです。
ヴェルモレルはさらに、特に供給チェーン業界において、各顧客向けの大規模なカスタマイズによってソフトウェアが肥大化してしまう問題について詳述します。カスタマイズは個別のソリューションを提供することを目的としていますが、結果として複雑で扱いにくく、保守やアップグレードに多大な労力を要するシステムとなってしまうのです。これを避けるために、ヴェルモレルはLokadがドメイン固有のスクリプトであるEnvisionを使用して、非常にカスタマイズされた一方で管理可能なソリューションを顧客に提供している方法を紹介します。
ソフトウェアの複雑性というテーマに触れ、チャンドラーはソフトウェア企業が肥大化を防ぐために何ができるかを問いかけます。ヴェルモレルは、シナリオは、企業が自社のソフトウェアにアクセスできるかどうかに依存すると答えます。もしアクセスできなければ、企業は取得したソフトウェアの複雑性に対処せざるを得ません。しかし、アクセスが可能であれば、使用されていない要素を特定して削除することでソフトウェアを簡素化し、複雑性を大幅に低減することができるのです。
ITおよびサプライチェーン・エグゼクティブの責任に焦点を移すと、ヴェルモレルは、IT担当者は通常技術的知識を持っているものの、特定の機能のビジネス価値を理解していないことが多く、その結果、必要な機能と不要な機能の間に乖離が生じると指摘します。したがって、経営判断者はITと密接に連携し、優先順位の設定とシステムの簡素化を推進する必要があります。
サプライチェーン・エグゼクティブが新たなソフトウェアに投資する際の助言として、ヴェルモレルは過度なカスタマイズを要求することはさらなる問題を引き起こすため避けるべきだと警告します。代わりに、エグゼクティブはベンダーのプロダクトマネージャーやCTOと定期的に連絡を取って直接自分たちのニーズを伝えるべきです。特定の機能を契約に盛り込むのではなく、問題点を解決できる相手に提示することを目指すべきなのです。
最後に、ヴェルモレルは、包括的なソリューションではなく、ひとつのことに秀でたソフトウェアを選ぶよう企業に助言します。この焦点を絞ったアプローチにより、改善が促進され、多数の相互に連関する機能によって引き起こされる複雑性が低減されます。ロードマップをコントロールする者と近い関係を維持し、明確にフォーカスされたソフトウェアを選択することで、企業は複雑性をより適切に管理し、生産性を向上させることができるのです。
完全な書き起こし
キアラン・チャンドラー：本日は、ソフトウェア・フランケンシュタイン化というテーマに取り組みます。ジョアネス、この言葉はなかなか発音が難しいので、君に任せようと思う。今日は大きな緑の怪物の話ではないだろうよ。一体、我々が話しているのは何なのか、詳しく教えてくれ。
ジョアネス・ヴェルモレル：我々が語っているのは、ソフトウェア、特にB2Bソフトウェア、さらにはサプライチェーンソフトウェアにおける進化を促すプロセスについてです。それは主に長寿命のB2Bソフトウェアに適用されます。このプロセスを、私は「フランケンシュタイン化」と呼んでおり、ソフトウェアベンダーとそのクライアントとの間で交渉される大規模な契約の絶え間ない流れによって、年々ソフトウェアが進化していくのです。興味深いのは、この「フランケンシュタイン化」という部分が、ベンダーとその大口クライアントとの間で交渉されたすべての大規模な契約が、ソフトウェアに傷跡を残す可能性がある点に由来するということです。
これは、ベンダーが大企業と交渉を行う中で徐々に進行するプロセスです。その大企業は要求を持っており、その要求に応じるためにソフトウェアには、全体のアーキテクチャ、理念、または元々の設計に合致しない調整が施されます。その機能は追加されるものの、どこかハック的な方法で行われます。これが傷跡となるのです。問題は、このプロセスを何年も繰り返すと、結果としてソフトウェアが一種のフランケンシュタイン・モンスターになってしまうことです。多くの傷跡から形作られた、不格好で非常に複合的な獣へと変貌し、奇妙な進化を遂げる――これがフランケンシュタインソフトウェアモンスターの正体です。これはほとんどのデータベースでも見られる現象ですが、サプライチェーンソフトウェアでは、まるでステロイドを投与されたかのようです。
キアラン・チャンドラー：君が言うところのこれらの傷跡について話そう。どんなものなのか？ 改善されているということは、余計な機能が追加されるという点では悪いことではないはずだが。
ジョアネス・ヴェルモレル：はい、もちろんそれがトレードオフです。ソフトウェアを改善したいと思うのは当然ですが、ソフトウェアは非常に複雑な存在です。建物のように、ただ階を追加したり、綺麗に拡張できるものではありません。ソフトウェアには、はるか初期に行われた多くの侵すことのできない設計上の前提があり、それがアーキテクチャ上の一体性を与えているのです。
たとえば、多くのERPは、特定の年を表すために52週間のプロファイルで季節性を捉えるという考えのもとに構築されています。つまり、文字通り52列（各週ごと）のテーブルがあり、生産または販売するあらゆるアイテムに適用できる季節性プロファイルが存在します。しかし、旧正月のような行事をモデル化したい場合、伝統的な中国暦に従って年をまたいで移動するため、52週間の枠に収まらないのです。同様の問題は、ラマダンやイースターでも発生します。
このように、一見素晴らしい前提が、枠に収まらない要求に直面すると崩れてしまうのです。そして、その現れ方は様々です。問題は、ソフトウェアベンダーとして、これらの新機能を完全に自然な形でアーキテクチャに統合するために、全ソフトウェアスタックを書き直す時間が実際にはないという点にあります。結局、少々ハック的な対応になってしまうのです。
キアラン・チャンドラー：重要なクライアントとの交渉では、契約をまとめるのに何年もかける余裕はありません。そして、未来を実現するためにも何年も待つことはできないのです。だからこそ、通常以上に大規模な交渉が必要になり、毎回相対的な緊急事態の中で物事を進めなければならない。つまり、ほとんど設計上から急がされている状態です。しかし、何が傷跡となり、何が良い機能となるのでしょうか？ すべてのソフトウェアは進化し、変化し、顧客のために働かなければなりません。では、どこでその境界線が引かれるのか？ 開発中の何かが傷跡にならないとどうやって判断するのですか？
ジョアネス・ヴェルモレル：問題は、その維持にどれだけのコストがかかるかです。大規模な企業向けソフトウェアに存在するコードの1行1行は、すべて保守しなければなりません。ソフトウェアの専門家でさえ気づいていないこともあるのですが、ソフトウェアは複雑な機械のようなもので、すべての部品が他のすべての部品と何らかの形で相互作用しなければならないのです。これは二次的な複雑性の問題を引き起こします。
それはどういう意味でしょうか？ もし部品が10個あれば、基本的に約100の潜在的な相互作用（10×10）が存在します。もし1000個の部品があり、すべてが相互作用するなら、1000×1000の相互作用が生じるのです。すべての潜在的な相互作用が、セキュリティ問題、バグ、クラッシュ、誤った結果、あるいはソフトウェアの大幅な遅延など、さまざまな問題の温床となり得るのです。
部品を追加するごとに、ソフトウェア内の部品間の潜在的な相互作用の数は増加し、その増加率は部品の数以上に急速です。そして、ここでいう「部品」とは、機能、能力、画面、データオプション、またはエントリなどを意味します。
もしあなたがソフトウェアアーキテクチャに非常に注意を払えば、機能間の相互作用の数を抑え、制御することができます。ソフトウェアの機能数を倍増させても、相互作用の数を4倍にしたくはありません。なぜなら、機能数が倍増すると、実際には保守に必要な労力が4倍になるからです。
しかし、それは非常に困難です。急いでいるときに機能を倍増させると、保守に必要な労力は実際に4倍、あるいはそれ以上に膨れ上がります。時間が経つにつれて保守コストは跳ね上がり、新しい機能を展開する能力はどんどん低下します。新しい機能を導入するたびに、十分に検討されていなかったために、さまざまな部分間で互換性の問題や奇妙な予期せぬ相互作用が一斉に発生し、その結果、問題は次第に深刻になっていきます。
Kieran Chandler: それでは、そのソフトウェア会社の視点から考えてみましょう。どうすれば新機能を導入できるのでしょうか？クライアントを喜ばせながら、余分な複雑さを持ち込まずにこれらの機能を実装するにはどうすればいいのでしょうか？何ができるのでしょうか？
Joannes Vermorel: 私の考えでは、教訓はB2Cソフトウェアの世界にあります。GoogleがGoogle検索に対して新機能を次々と展開するわけでもなく、Netflixが新規クライアントのためだけにNetflixに新機能を追加するわけでもありません。彼らは、新しいクライアントを獲得するために、「もしそれらの機能がなければ契約してもらえない」という理由で即座に実装することはしません。
彼らはそんな風には動作しません。どの領域に属するのか、具体的に解決しようとしている問題は何かを考え、非常に高い視点からその問題を俯瞰して考えるのです。
Kieran Chandler: あなたは、単一の小さな問題ではなく、同一カテゴリの問題全体に対する解決策を生み出すことを目指すアプローチについて語りました。これには、関連する広範な問題群に対応するためにソフトウェアを再設計する必要があります。そしてこれは常に起こることです。クライアントと対話するとき、彼らが提示するのは問題そのものであり、提案された解決策ではありません。対照的に、B2Bの世界では、顧客は自分たちの問題と共に解決策も提示する傾向があります。この解決策が、既存のソフトウェアスタックや問題の進化に適しているかどうかは別として。つまり、彼らは本当に耳を傾けていないのでしょうか？
Joannes Vermorel: 全くその通りです。重要なのは、特定の解決策に固執するのではなく、核心となる問題を的確に理解することなのです。GoogleやNetflixのような大企業はその良い例です。
Kieran Chandler: つまり、企業は本当に耳を傾けていないということでしょうか？ところで、フィードバックを求めるあの迷惑なポップアップはどうなんですか？実際に誰かがそれらをチェックしているのでしょうか？
Joannes Vermorel: あなたが指摘するポップアップは、通常好ましくない機能です。しかし、Googleのような企業には評価すべき点があります。利用規約に従わなければならないこれらのポップアップは、彼ら自身の選択ではありませんでした。規制上の制約によって実装を強いられたのです。ですから、一見奇妙に思える機能でも、彼らの意図ではないのです。また、ウェブを制したのは、非常に迷惑な広告を出す企業ではなく、Googleのような、クリーンで目障りでない広告を展開する企業であったことも見逃せません。彼らは顧客のことを考え、製品の価値を損なうような迷惑なものは導入しなかったのです。彼らは自社の機能について十分に検討する時間を確保しています。
Kieran Chandler: B2Bのソフトウェア企業、特にサプライチェーン分野では、多様な状況が存在します。数百にも及ぶシナリオがあり、しばしば最後の瞬間に多数の機能が交渉され、それらは半年後にはほとんど悪いアイデアとなるのです。では、ソフトウェアのフランケンシュタイン化は悪いことだということでしょうか？もしそうなら、Lokadではこの問題を避けるためにどのような工夫をしているのでしょうか？
Joannes Vermorel: 全くその通りです。ソフトウェアのフランケンシュタイン化は大きな問題です。Lokadでの最初の数年間、我々はこの難題に直面していました。それは非常に厳しいトレードオフでした。正しくやるには1年から2年かかり、それはあまりにも遅すぎる。一方、適当な方法でやれば数週間または数ヶ月で済むかもしれませんが、その場合、大きな傷跡、醜いハックが残り、技術的負債が積み重なってしまうのです。Lokadの初期の数年間は解決策がなく、技術的負債は着実に蓄積していき、憂慮すべき事態となっていました。その時点で、数十年先を見据えると、競合他社がサプライチェーン最適化のための巨大なソフトウェアに次々と機能を追加し、不整合な状態になっているのが見えてきたのです。
Kieran Chandler: ソフトウェア企業は常に新機能を追加し続け、結果として混乱し、膨大な製品になってしまうようですね。Lokadでのこの問題に対するアプローチについて詳しく教えていただけますか？
Joannes Vermorel: もちろんです。ソフトウェアが膨張してしまう原因は、一度に1つの悪い機能を追加していくことにあります。もし20年その道を進めば、結果は巨大な製品となるのです。これは、開発者が無能または愚かだという話ではなく、ただ単にクライアントを一人ずつ獲得しながら段階的に開発を進めるための結果なのです。しかし、このアプローチはクライアントごとにソフトウェアを蓄積していき、最終的には非常にひどい結果を招くのです。
そこで、我々はLokadで全く異なる視点からアプローチすることに決め、結果としてドメイン固有のプログラミング言語であるEnvisionを誕生させました。Envisionを用いることで、実質的にすべての問題を分離しました。インフラストラクチャ、データインフラストラクチャ、そして機械学習のインフラストラクチャを分けたのです。これらは長期間にわたって保守・アップグレードを続ける製品であり、変更やアップグレードを決定するたびに数年の努力が必要となります。
そして、個々のクライアントごとに、Envisionで記述された完全にオーダーメイドの実装をスクリプトとして作成します。Envisionはサプライチェーン最適化専用に設計されているため、非常に高い生産性で、各クライアントに合わせた完全オーダーメイドのソリューションを書くことが可能なのです。
つまり、我々は白紙の状態から始め、完全にカスタマイズし、その結果、クライアントから「サポートしていない」と言われるような要求に直面することを避けているのです。Envisionのプログラム能力のおかげで、もしクライアントのために特別な対応が必要になったとしても、最悪の場合、作成するスクリプトが通常ほどコンパクトでなくなるだけです。それでも、特定の種類の問題を容易に解決できるように設計されたインフラの恩恵を享受できるのです。
もしプラットフォームに高度なプログラム的なドメイン固有の機能を導入すれば、急いで交渉して製品に傷を残すという事態を回避できます。各クライアントごとにオーダーメイドのプログラム環境でカスタマイズを行い、その後、自社のスケジュールに沿ってプラットフォームのアップグレードを進めることができ、多くの場合、そのスケジュールはクライアントのものとは一致しないのです。
Kieran Chandler: この問題をかなり早い段階で把握されたのですね。他のソフトウェア企業がこのような膨張したシステムに直面している場合、どのようなアドバイスをされますか？彼らは何か対策を講じるべきでしょうか？あるいは、事を簡潔にするためにいくつかの機能を削除し始めるべきでしょうか？
Joannes Vermorel: 状況は様々な要因に依存します。もしあなたがWMS、ERP、MRPなどのソフトウェアを所有する大企業であり、実際にソフトウェアにアクセスできなければ、それは単なるベンダー製品となり、その複雑さから逃れることはできません。
もしソフトウェアにアクセスでき、かつそれを簡素化したいなら、まず使われていないすべての部分を見直し、積極的に廃棄することから始めるべきです。多くの場合、既存のソフトウェアの一部を削除することを心配するのは、その機能を失うことへの懸念からです。確かに、機能を削除すれば、その機能は失われます。しかし、ほとんど使用されていない部分を除去することで、その小さな機能が原因で引き起こされていた一連の問題も、まとめて解消できるのです。
我々はLokadで、文字通り何千ものテーブルを持つERP実装をしばしば目にします。例えば、5000のテーブルを持つERPもあり得ます。各テーブルには10から200のフィールドがあり、その結果、膨大な複雑性が生まれるのです。ERPのバックアップさえも、非常に複雑な作業となります。
Kieran Chandler: テーブルがあまりに多いので、テーブル一覧などを保存するためのテーブルまで必要になるわけですね。まさに、使われていない多数のテーブルや画面を特定して削除するだけで、すべてがシンプルになるという状況です。
Joannes Vermorel: その通りです。例えば、あるデータベースのバージョンから別のバージョンへアップグレードする際、もはや誰も使っていないロジックの一部もアップグレードしなければならないという問題に直面することがあります。存在するすべてのコード、たとえそれがJava、C Sharp、SQLなどで書かれていたとしても、そのコード行が存在する限り、それを保守し続けなければならないのです。もしそれを削除すれば、次回の統合や移行時に「これを次のシステムにどう移行すればよいのか」という問いに悩まされることもなくなります。
そして、これはサプライチェーンの経営者が真剣に考えるべき点です。ソフトウェアを購入する際、本当に必要でなければ、その部分は持たない方が良いという簡潔さの原則に従うべきなのです。不要な部分は単なる負担となるだけです。つまり、獲得し運用するソリューションの技術的負荷に常に注意を払うことが重要なのです。
この技術的負荷はただでは得られません。画面が多ければ、その分、トレーニングする人数も必要になります。もしいくつかの画面を削減できれば、トレーニングの負担が減り、不具合報告も少なくなり、さらにはIT部門との衝突も減るでしょう。これはITの複雑性を管理するという問題でありますが、問題は、通常IT部門はビジネスの価値を判断する情報を持たないため、本当に必要な機能とそうでない機能の違いを見極められない点にあります。彼らはテーブル、フィールド、画面、または機能をユーロやドルに換算する能力を持っていないのです。これは、サプライチェーンやマーケティングといったビジネス側の人々だけができることです。だからこそ、IT部門は企業内の意思決定者の支援を受けて、システムの優先順位付けや簡素化の推進を図る必要があるのです。
Kieran Chandler: まとめると、もし私が自社のために新しいソフトウェアへの投資を検討しているサプライチェーンの経営者であれば、あまりカスタマイズを求めるべきではないということになりますね。なぜなら、カスタマイズは問題を引き起こす要因になるからです。では、何を基準にソフトウェアを選ぶべきでしょうか？
Joannes Vermorel: その通りです。カスタマイズや特別な機能を要求することは、問題を生み出すレシピに過ぎません。もしソフトウェアベンダー自身が十分な問題を抱えていなければ、あなたの要求は新たな問題を生み出し、状況をさらに悪化させるだけです。ですから、基本的にはそうすべきではありません。もしカスタマイズを要求できる状況にあるとしても、それはテスト程度にとどめるべきです。なぜなら、ベンダーが自発的にカスタマイズの議論に乗ってくるということは、そのベンダーに誠実さが欠けている証拠だからです。そうなれば、そのベンダーは他の全てのクライアントに対しても同様の対応をしている可能性があり、たとえ今日製品が優れていたとしても、5年後には悪夢と化すのは必至です。
まず、もしカスタマイズを要求するのであれば、その要求は拒否されるべきだと本来期待すべきです。もしそうでなければ、それ自体が問題なのです。
Kieran Chandler: つまり、人々が要求すべき一つのことは、特別な機能、ということですよね？もし何か要求するとすれば、ベンダー側のCTOやプロダクトマネージャーへの直接アクセス、もしくはその人との定例ミーティングを月に2時間設ける、といった要求でしょうか？なぜでしょうか？
Joannes Vermorel: ソフトウェア企業のロードマップを技術的に構築している人々に直接アクセスできるよう交渉すれば、単に自分たちの変更点を提示することができるのです。自分たちの解決策を強制する必要はなく、ただ単に問題を提示するだけで済むのです。エンジニアは、問題が提示されると自然と解決策に取り組むものです。定例のミーティングで問題を提示すれば、契約で特定の機能を要求する必要はなく、数年以内に、あなたが提示した問題に沿った機能が製品に現れるでしょう。
Kieran Chandler: それについて、もう少し詳しく説明していただけますか？
Joannes Vermorel: 数学的に考えてみてください。ソフトウェア企業のCTOが、月にクライアントとどれだけのミーティングを持てるでしょうか？例えば、最大で20回だとしましょう。月1回のミーティングであれば、実質的にCTOの精神的リソースの約5％を獲得できる計算になります。つまり、あなたの問題が、協力しているベンダーの技術開発において、相当な注目を集めることになるのです。
Kieran Chandler: では、あなたの提案は何ですか？
Joannes Vermorel: 賢明に行動するのであれば、ロードマップに対する決定権を持つ人々に近づくべきです。急いで破綻した機能を交渉するよりも、はるかにスマートな方法です。それは、たとえあなたの解決策が後で見捨てられたとしても、またはあなたの問題が変わったとしても、6か月以内に廃棄されるようなものではありません。また、もう一つの助言として、あまりにも多機能なソフトウェアは避けるべきです。むしろ、1つのことをうまく行うソフトウェアを選び、全てを雑にこなすような多機能なソフトウェアは避けるべきです。
Kieran Chandler: その点について、もう少し詳しく説明していただけますか？
Joannes Vermorel: すべてを網羅する巨大なフレームワークよりも、焦点を絞った小規模なソフトウェアを改善するほうが簡単です。何かを調整する際、機能間の相互作用が二次的に増加することを考慮に入れる必要があります。たとえば、1000の機能があり、そのうちの1つを追加する場合、既存の1000の機能とのすべての相互作用を考慮しなければならないのです。しかし、もし機能が10個しかなければ、11番目の機能を追加するときに考えるべき相互作用は10個だけとなります。つまり、解決しようとしている特定の問題に対して、効率的で鋭く絞り込まれたシステムに注力すべきなのです。
Kieran Chandler: 素晴らしい！申し訳ありませんが、今日はこれで終わらせざるを得ません。ただ、数人のCEOはそれをあまり喜ばないかもしれず、これからさらに電話が増えることになるでしょう。さて、今週はこれで全てです。来週、また新しいエピソードでお会いしましょう。それでは、お元気で。
Joannes Vermorel: ありがとうございます.
