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ソフトウェアが元の設計と一致しない無秩序な変更を経て進化する方法に言及しています。彼はこれらの変更を「傷」と喩え、合成された進化したソフトウェアシステムの形成に寄与していると述べています。ERPを例に挙げながら、ソフトウェアアーキテクチャの維持と新しい要求の両立のジレンマを強調しています。ヴェルモレルは、急いだ決定はしばしばソフトウェアの傷つけと保守コストの増加につながると警告しています。ソフトウェア管理における避けられない複雑さを認識しながらも、ヴェルモレルはB2Cモデルからの学びが機能の相互作用を制御する上で重要であると強調しています。Lokadのこの問題への対応策は、「Envision」というドメイン固有のプログラミング言語であり、インフラストラクチャとドメイン固有の問題を分離しています。
詳細な要約
Lokad TVの最新エピソードでは、ソフトウェアのフランケンシュタイン化という概念について、Lokadの創設者であるジョアネス・ヴェルモレルが話しています。彼は、この用語を、特に長寿でサプライチェーンのソフトウェアなど、長期にわたって進化し続けるB2Bソフトウェアの変換を描写するために使用しています。これらの変更は、ソフトウェアベンダーとそのクライアント間の連続的な交渉と大規模な取引によって行われるため、ソフトウェアの元のアーキテクチャ、哲学、デザインとは一致しないことが多いとヴェルモレルは説明しています。
ヴェルモレルは、ソフトウェアのフランケンシュタイン化が、クライアントの要求に応じてソフトウェアに調整が加えられることで起こると説明しています。これらの変更は、しばしばソフトウェアの元のアーキテクチャ、哲学、デザインと一致しないものです。その結果、ソフトウェアは時間の経過とともにこれらの変更、または「傷」を蓄積し、合成された奇妙な進化したソフトウェアシステムに変わっていきます。
彼はさらに、この現象はサプライチェーンソフトウェアに特に顕著であると指摘していますが、多くのB2Bソフトウェアのタイプでも一般的です。それにもかかわらず、彼は「傷」という用語が必ずしも否定的な意味を持つものではないと明確に述べています。これらの変更は、新しい機能を追加することによってソフトウェアを向上させることができます。
ヴェルモレルは、企業資源計画（ERP）ソフトウェアの例を挙げています。このソフトウェアは、固定の52週プロファイルを使用して季節性を捉えることができると仮定しています。この設計は、中国の新年、ラマダン、またはイースターなど、異なるカレンダーに従い、毎年日付が変わる需要が発生するまでうまく機能します。
このような場合、ソフトウェアベンダーは「ハッキッシュな」解決策を統合することで新しい需要に対応することができますが、これはソフトウェアのアーキテクチャにシームレスにフィットしないものの、必要な機能を提供します。しかし、このアプローチはしばしばさらなる「傷」を引き起こし、ソフトウェアのフランケンシュタイン化に寄与します。
ソフトウェアビジネスにおける主要なクライアントとの迅速な交渉の重要性を強調する中で、ヴェルモレルは緊急性が誤って「ソフトウェアの傷つけ」につながる可能性があると警告しています。彼はこれを、急いで実装された機能がソフトウェアの複雑さと保守コストを増加させるプロセスと定義しています。
ソフトウェアアーキテクチャの複雑さを説明する中で、ヴェルモレルは、コードの各行や機能ごとにメンテナンスが必要であることに言及しています。機能が追加されるにつれて、相互接続はより複雑になり、「二次の複雑性問題」が発生します。要するに、部品の数が増えるにつれて、潜在的な相互作用が指数関数的に増加し、バグ、クラッシュ、セキュリティの脅威など、さまざまな潜在的な問題が引き起こされます。
ヴェルモレルは、機能間の相互作用の数を制御するための細心のソフトウェアアーキテクチャの重要性を強調しています。彼は、機能の数が倍増する場合に必要なメンテナンスの量を2倍にすることを目指すべきであり、急いで開発すると四倍以上になることがしばしばあると述べています。
ソフトウェア企業が過度な複雑さを増やさずに新機能を導入する方法について尋ねられた際、ヴェルモレルはGoogleやNetflixなどのB2Cソフトウェア企業から学ぶことを提案しています。彼らは解決しようとしている具体的な問題を理解するために時間をかけ、類似の問題の広範なカテゴリに対処する解決策を設計します。彼は、これに対してB2Bの世界では、顧客が問題だけでなく独自の提案も持ち込むことがしばしばあると述べています。
これらの問題をどのように管理しているかについての質問に対して、ヴェルモレルは、正しく行うことと顧客の要求に迅速に対応することのバランスを取ることで初めて解決策を見つけることができたと述べています。彼らは初期の数年間に技術的な負債の増加に気付き、ヴェルモレルはこれを有害だと認めています。彼らは、個々のクライアントを喜ばせるために機能を追加することが短期的には有益に見えるかもしれないが、長期的には複雑で一貫性のない、管理が難しい製品につながることに気付きました。
この認識に対応して、Lokadは「Envision」というドメイン固有のプログラミング言語という独自の解決策を考案しました。Envisionの目的は、インフラストラクチャの問題とドメイン固有の問題を分離することで、新機能の追加とメンテナンスを効果的に管理することです。これにより、過度な複雑さを増やすことなく、新機能を追加することができます。
ヴェルモレルは、特にサプライチェーン業界において、ソフトウェア製品が顧客ごとに広範なカスタマイズを行うことが頻繁にあると説明しています。カスタマイズは特注のソリューションを提供することを目指していますが、しばしば複雑で扱いにくいシステムになり、保守とアップグレードには大きな努力が必要です。これを避けるために、Lokadはドメイン固有のスクリプトであるEnvisionを使用して、顧客に高度にカスタマイズされたが管理しやすいソリューションを作成している方法を共有しています。
ソフトウェアの複雑さについての話題に触れる中で、チャンドラはブロートウェアを防ぐためにソフトウェア企業ができることについて尋ねます。ヴェルモレルは、会社が自社のソフトウェアにアクセスできるかどうかによってシナリオが異なると答えます。アクセスがない場合、会社は取得したソフトウェアの複雑さに対処する必要があります。しかし、アクセスが可能な場合、使用されていない要素を特定して削除することで、ソフトウェアの複雑さを大幅に減らすことができます。
ITおよびサプライチェーンの幹部の責任に焦点を当てると、ヴェルモレルは、ITスタッフは通常技術的なノウハウを持っているが、特定の機能のビジネス価値を理解していないことが多いと指摘します。これにより、必要な機能と不要な機能の間に乖離が生じます。したがって、ビジネスの意思決定者はITと緊密に協力して優先順位付けとシステムの簡素化を推進する必要があります。
サプライチェーンの幹部が新しいソフトウェアへの投資を検討する際のアドバイスをヴェルモレルは提供します。彼は、過度なカスタマイズを要求することに対して警告し、それがさらなる問題を引き起こす可能性があると述べています。代わりに、幹部はベンダーのプロダクトマネージャーやCTOと定期的に連絡を取り合い、直接ニーズを伝えるべきです。契約に特定の機能を強制するのではなく、問題をエンジニアリングの解決策を提供できる人々に提示することが目的です。
最後に、ヴェルモレルは、包括的なソリューションを選択する代わりに、一つのことに優れたソフトウェアを選ぶことを企業に勧めています。この焦点を絞ったアプローチは、改善を容易にし、相互に関連する多くの機能による複雑さを減らすのに役立ちます。ロードマップを制御する人々に近づき、鋭く焦点を絞ったソフトウェアを選択することで、企業は複雑さをよりよく管理し、生産性を向上させることができます。
フルトランスクリプト
キーラン・チャンドラ: 今日は、ソフトウェアのフランケンシュタイン化というテーマに取り組みます。では、ジョアネスさん、発音が難しいトピックなので、お任せします。今日は大きな緑の怪物の話ではないと思いますが、具体的には何について話しているのでしょうか？
ジョアネス・ヴェルモレル: 私たちはソフトウェアの進化を促進するプロセスについて話しています。具体的には、B2Bソフトウェア、さらに具体的にはサプライチェーンソフトウェアに適用されます。これは主に長寿命のB2Bソフトウェアに適用されます。このプロセス、私が「フランケンシュタイン化」と呼んでいるものは、ソフトウェアベンダーとそのクライアントとの間で交渉される大規模な取引の連続によってソフトウェアが進化していくものです。興味深いことは、「フランケンシュタイン化」という言葉が示すように、ベンダーとその大規模なクライアントの間で交渉される各大規模な取引がソフトウェアに傷跡を残す可能性があるということです。
ベンダーが大企業と交渉する過程で徐々に進行します。大企業は要求を持っており、それらの要求を満たすために、ソフトウェアには全体的なアーキテクチャ、哲学、または元の設計とは合わない調整が行われます。機能は追加されますが、ある種のハッキシュな方法で追加されます。それが傷跡です。問題は、何年も繰り返しこのプロセスを繰り返すと、ソフトウェアがある意味でフランケンシュタインの怪物になることです。それは多くの傷跡でできた獣であり、いくつかは見た目が醜く、非常に複合的です。それは奇妙な方法で進化し、それがフランケンシュタインソフトウェアモンスターになる方法です。これはほとんどのデータベースで起こることですが、サプライチェーンソフトウェアではステロイドのように進行します。
キーラン・チャンドラ: では、これらの傷跡について話しましょう。それらはソフトウェアを改善しているわけですよね？追加の機能を追加しているわけですよね？それはそんなに悪いことではないのでしょうか？
ジョアネス・ヴェルモレル: はい、もちろんそれはトレードオフです。ソフトウェアは非常に複雑なオブジェクトです。建物のように簡単に階を追加したり、きれいに拡張したりすることはできません。ソフトウェアには非常に早い段階で行われたいくつかの変更で、ソフトウェアに一定の整合性、つまりアーキテクチャの整合性が与えられます。
例えば、CRUDビジネスアプリについて考えてみましょう。これは、プロファイルを使用して季節性を捉えるというアイデアに基づいて構築されたものです。プロファイルはちょうど52週で、1年を表しています。つまり、週ごとに1つの列があるテーブルがあり、生産または販売しているアイテムに適用できるさまざまな季節性のプロファイルがあります。しかし、例えば中国の新年のようなものをモデル化したい場合はどうでしょう？それはグレゴリオ暦ではなく、伝統的な中国の暦に従って、年をまたいで移動するため、この52週のグリッドには収まりません。ラマダンやイースターでも同様の問題が発生します。
フレームワークに収まらない需要に直面したとき、この非常に素晴らしい前提条件が崩れる可能性があります。そして、それはさまざまな形で現れることがあります。問題は、ソフトウェアベンダーとして、新しい機能を完全にネイティブな方法でアーキテクチャに統合するために、ソフトウェアスタック全体を書き直す時間が実際にはないということです。結局のところ、それは少しハッキッシュなものです。
Kieran Chandler: 重要なクライアントと交渉しているので、取引を終了するために数年もの時間があるわけではありません。そして、将来を実現するためにも数年もの時間がありません。ですので、毎回相対的な緊急事態で行われなければならないのです。なぜなら、通常よりも大きな交渉を終了するためには、事実上急いで進める必要があるからです。しかし、何が傷跡になり、何が良い機能になるのでしょうか？なぜなら、これらのソフトウェアは進化し、変化し、クライアントのために機能する必要があるからです。では、これら2つの要素の違いは何でしょうか？開発中の何かが傷跡にならないことをどのように知ることができるのでしょうか？
Joannes Vermorel: 問題は、メンテナンスにかかるコストがどれくらいかということです。大規模なエンタープライズソフトウェアに存在するコードのすべては、メンテナンスする必要があります。ソフトウェアのプロフェッショナルであっても、人々が常に認識しているわけではありませんが、ソフトウェアはすべてのパーツがどこかしらで相互作用する複雑な機械のようなものです。二次の複雑性の問題があります。
それはどういう意味でしょうか？それは、10個のパーツがあれば、基本的には100の潜在的な相互作用があるということです。10 x 10ですね。もし1000個のパーツがあり、それらがすべて相互作用している場合、1000 x 1000の相互作用があります。すべての潜在的な相互作用は、セキュリティの問題、バグ、クラッシュ、正しくない結果、またはソフトウェアの大幅な遅延の原因となります。
パーツを追加すると、ソフトウェア内のパーツ間の潜在的な相互作用の数が増え、パーツの数よりもはるかに急速に増加します。そして、パーツと言っても、機能、機能、画面、データオプション、またはエントリーを考えることができます。
ソフトウェアアーキテクチャに非常に注意を払えば、機能間の相互作用の数を制御することができます。ソフトウェアの機能を2倍にするとき、相互作用の数を4倍にしたくはありません。なぜなら、機能の数を2倍にすると、必要なメンテナンスの量が4倍になるからです。
しかし、それは非常に難しいです。急いでいるとき、機能の数を2倍にすると、メンテナンスにかかる労力が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年間進むと、巨大な製品になります。開発者が無能や愚かではないのではありません。彼らは単に一つずつまともな仕事をして、一度に1つのクライアントを獲得しようとしているだけです。しかし、このアプローチはソフトウェアを一つずつ傷つけ、最終的な結果は通常非常に悪いものになります。
ですので、Lokadではまったく異なるアプローチを取ることにしました。それが、私たちのドメイン固有のプログラミング言語であるEnvisionの誕生につながりました。Envisionでは、すべての問題を効果的に分割しました。インフラストラクチャ、データインフラストラクチャ、機械学習インフラストラクチャを分離しました。これらは長期間にわたって維持およびアップグレードしたい製品であり、変更やアップグレードを行うたびに数年の努力が必要です。
そして、別々に、各クライアントごとに、Envisionのスクリプトで完全にカスタムな実装を作成します。Envisionはサプライチェーン最適化のために特別に設計されているため、完全にカスタムなものを各クライアントごとに高い生産性で作成することができました。
ですので、私たちはまったく白紙から始め、完全にカスタマイズし、クライアントがサポートしていない要求をされる状況に直面することはありません。Envisionのプログラムの能力により、クライアントのために特別なことをしなければならない場合でも、書いたスクリプトが通常よりもコンパクトでない場合が最悪のシナリオです。しかし、特定の問題を解決するために設計されたインフラストラクチャの恩恵を受けることはできます。
プラットフォームに高度なプログラムドメイン固有の機能を導入すると、製品に傷をつける交渉を急がなくても済みます。各クライアントに特別に設計されたプログラム環境でカスタマイズを行い、自分自身のスケジュールでプラットフォームのアップグレードを継続的に行うことができますが、おそらくクライアントのスケジュールとは一致しないでしょう。
キーラン・チャンドラー: あなたはこの問題を早期に認識しました。このような膨張したソフトウェアに直面している他のソフトウェア会社にどのようなアドバイスをお授けしますか？何か対処することはできますか？いくつかの機能を削除してシンプルにするべきでしょうか？
ジョアネス・ヴェルモレル: 状況はいくつかの要素に依存します。WMS、ERP、MRPなどのようなソフトウェアを所有している大企業の場合、ソフトウェア自体にアクセスできない場合もあります。ソフトウェアにアクセスできない場合、取得したソフトウェアの複雑さに取り残されることになります。
ソフトウェアにアクセスでき、それを簡素化したい場合は、使用していないすべての要素を見直し、積極的に廃棄することから始めるべきです。多くの人々は、既存のソフトウェアの一部を削除することについて心配しています。特定の機能を失うことを心配しています。確かに、機能を削除すると、その機能も失われます。しかし、ほとんど使用されないものを削除すると、この小さな機能の存在によって引き起こされる問題のクラス全体も削除できます。
Lokadでは、ERPの実装で数千のテーブルを見ることがよくあります。たとえば、5000のテーブルを持つERPがあるかもしれません。各テーブルには10から200のフィールドがあり、膨大な複雑さを生み出します。ERPのバックアップを取るだけでも非常に複雑になることさえあります。
キーラン・チャンドラー: テーブルが多すぎるため、テーブルのリストを保存するためのテーブルが必要になります。テーブルや画面が使用されていないことがわかる場合、それらを削除するだけで、すべてを簡素化できます。
ジョアネス・ヴェルモレル: まさにその通りです。たとえば、データベースのバージョンをアップグレードする必要がある場合、誰もが使用していないロジックの一部をアップグレードする必要があるかもしれません。Java、C＃、SQLなど、存在する限り、コードの各行は維持する必要があります。それを削除すると、次の統合や移行時に、このものを次のバージョンのシステムまたは次のシステムにどのように移行するかという質問をする必要がなくなります。
これは、サプライチェーンのエグゼクティブが考える必要があることです。ソフトウェアを購入する際には、節約の原則に従うべきです。本当に必要ない場合は、システムの一部を持つことはありません。それはただの負担になるだけです。取得および運用するソリューションの技術的な質量に常に注意を払うことが重要です。
この技術的な質量は無料ではありません。画面が多ければ多いほど、トレーニングする人が必要です。いくつかの画面を削除できれば、トレーニングが少なくなり、報告されるバグも少なくなり、ITとのトラブルも少なくなります。ITの複雑さを管理することですが、難しい部分は、通常、ITはそれについて何も知らないということです。彼らはビジネス価値にアクセスできないため、本当に必要な機能と絶対に必要ではない機能を区別することができません。テーブル、フィールド、画面、または機能をユーロやドルに変換することはできません。それはサプライチェーンの人々、または別のシステムを見ている場合はマーケティングの人々だけができることです。それがなぜ、ITは会社の意思決定者たちのバックアップが必要であり、システムの簡素化に向けた優先順位付けと変更を推進する必要がある理由です。
キーラン・チャンドラー: では、まとめると、私が会社のために新しいソフトウェアに投資したいサプライチェーンのエグゼクティブである場合、カスタマイズを求めるべきではないと言っていましたが、それは問題を引き起こすということですね。では、何を探すべきですか？
ジョアネス・ヴェルモレル: はい、カスタマイズや特別な機能を求めることは、問題を引き起こすためのレシピのようなものです。もしソフトウェアのベンダーが十分な問題を抱えていなかった場合、新たな問題を作り出して、事態を悪化させるだけです。ですから、本当にそうするべきではありません。実際にカスタマイズを求めることができる場合は、テストとして尋ねることができます。なぜなら、ベンダーがカスタマイズについて積極的に議論に参加するなら、ベンダーには誠実さがないということです。つまり、ベンダーは他のすべてのクライアントと同じようにそれを行っているということであり、それは製品が今日良いとしても、5年後には悪夢になるということです。
まず、カスタマイズを求める場合、求めても拒否されることを期待するのが良いです。そうでなければ、それは問題です。
キーラン・チャンドラー: 人々が求めるべきものは特別な機能ですよね？つまり、求めるべきものがあるとすれば、CTOやベンダー側のプロダクトマネージャーへのアクセスです。契約の一部として含めることはできますか？たとえば、1か月に2時間、この人との会議を持ちたいというような形で。なぜですか？
ジョアネス・ヴェルモレル: ベンダーのロードマップをエンジニアリングしている人々への直接アクセスを交渉することで、単に問題を提示するだけで変更を提案することができます。あなたの解決策を彼らに押し付ける必要はありません。なぜなら、エンジニアは問題が提示されたときに何をするかを知っているからです。問題を提示するための定期的な会議があれば、契約で特定の機能を交渉する必要はありません。数年後には、あなたが提示した問題に合致するような機能が製品に現れ始めます。
キーラン・チャンドラー: それについてもう少し説明していただけますか？
ジョアネス・ヴェルモレル: 数学を考えてみましょう。ソフトウェア会社のCTOを考えてみてください。この人は1か月にいくつのクライアントと会議を持つことができるでしょうか？最大で20回としましょう。1か月に1回の会議があれば、あなたは実質的にCTOのメンタルバンド幅の約5％を得ています。CTOは、あなたが一緒に働いているベンダーの技術的な開発を推進している人です。つまり、あなたの問題はかなりの注意を受けているということです。
キーラン・チャンドラー: では、あなたの提案は何ですか？
ジョアネス・ヴェルモレル: もし賢くやりたいのであれば、ロードマップを制御している人々に近づくことです。それは、あなたの解決策が良くなかったり、問題が変わったりして、おそらく6か月後に捨てることになる壊れた機能のために急いで交渉するよりも賢い選択です。また、別のアドバイスとして、あまりにも多くのことを行うソフトウェアを避けることもあります。あなたは、一つのことをうまくやるソフトウェアを考えるべきであり、すべてを下手にやってしまう広範な機能を持つソフトウェアではなくなります。
キーラン・チャンドラー: その点についてもう少し詳しく説明していただけますか？
ジョアネス・ヴェルモレル: 一つのことに焦点を絞ったソフトウェアを改善する方が、すべてを行っている巨大なフレームワークを改善する方が簡単です。何かを調整するときは、それを二次関数の数の相互作用と考えてください。もし1000の機能があって、1つ追加する場合、既存の1000の機能との相互作用を考える必要があります。ですので、1つの機能を導入すると、1000の相互作用を見る必要があります。しかし、もし10の機能しかなく、11番目を追加する場合、レビューする相互作用はたったの10個です。ですので、再び、特定の問題に焦点を絞り、スリムで鋭く集中したものに注力してください。
キーラン・チャンドラー: 素晴らしい！今日はここまでにしましょう。でも、おそらく数人のCEOはあまり感謝しないかもしれませんね。おそらく今後、もう少し電話がかかってくるでしょう。それでは、今週は以上です。来週もまた別のエピソードでお会いしましょう。それでは、お元気で。
ジョアネス・ヴェルモレル: ありがとうございました。
