00:00:05 サプライチェーンソフトウェアの保守性に関するトピックの紹介.
00:01:22 時間の経過とともにソフトウェアがどのように劣化するか、例としてMicrosoftを用いて説明.
00:03:01 Microsoft製品と他のソフトウェアの保守性の違いについての議論.
00:04:16 コンピュータハードウェアの変化やセキュリティ上の懸念から、ソフトウェアが時間とともに変化しなければならない理由の説明.
00:07:50 保守性を検討すべき視点と、ベンダーの存続のみを根拠にする問題点についての議論.
00:09:08 100万台以上のプリンターとの互換性を持つMicrosoftの例が、この課題の規模を示しています.
00:10:07 ソフトウェア設計が保守性にどのように影響するか、そしてソフトウェアを高い保守性に設計する必要性について.
00:11:07 ソフトウェアの保守性を保証するために、ベンダーのインセンティブを分析することの重要性.
00:13:03 保守性は設計の問題であり、技術的質量の保持が保守可能な製品を持つための鍵であるということ.
00:16:00 ソフトウェアの保守性の重要性について議論する.
00:17:00 ソフトウェアの保守性を確保するためのベンダーのインセンティブ.
00:19:00 保守可能なソフトウェアを見極める方法.
00:21:02 保守不可能なソフトウェアの兆候.
00:23:13 ソフトウェアの保守性の重要性に関する最終的な考察.

概要

インタビューにおいて、Kieran ChandlerとJoannes Vermorelは、特にsupply chain softwareにおけるソフトウェアの保守性の重要性について議論しています。Vermorelは、保守性は主に設計の問題であり、ベンダーの存続だけに注目する企業がこの点を見落としていると主張します。彼は、技術の変化とエントロピーによりソフトウェアは時間とともに保守不可能になることを指摘し、ソフトウェア設計における互換性、セキュリティ、シンプルさの重要性を強調します。さらに、Vermorelは派手なユーザーインターフェイスに頼る罠に陥ることを警告し、長期的な実現可能性を確保するために、開発者の保守性に対する計画を徹底的に問い詰めることを提案しています.

詳細な概要

このインタビューで、Kieran ChandlerとJoannes Vermorelは、サプライチェーンソフトウェアの保守に伴う課題と、優れた設計がその寿命にどのように影響を与えるかについて議論しています。Vermorelは、ソフトウェアは物理的な対象物のように劣化しないものの、エントロピーや技術環境の変化によって時間とともに崩壊していくと説明します。Microsoftのような企業が成功しているのは、彼らが製品の長期的な存続に強いコミットメントを示しているためであり、今日でも古い文書を開いて使用できることがその証です.

Vermorelは、Microsoftがソフトウェアの長寿命を保つ能力は、保守への巨額な投資と互換性への注力に起因すると指摘します。彼は、よりスリムで合理的に整理されているものの、同程度の後方互換性を提供しないLinuxとこれを対比させます。さらに、Vermorelは、サプライチェーンソフトウェアが分散型であり、数多くの可動部品が関与しているため、さらに複雑であると認めています.

サプライチェーンソフトウェアの保守がさらに困難になるのは、computing hardwareが絶えず進化しているためです。仮想化は一部の問題を緩和するのに役立ちますが、完璧な解決策ではありません。さらに、ユーザーがソフトウェアと対話する方法も絶えず変化しており、タッチスクリーンや高解像度ディスプレイの普及がその一例です。古いソフトウェアはこれらの最新システム向けに設計されていない場合があるため、直感的でなく、潜在的に安全性に欠ける可能性があります.

Vermorelは、ソフトウェアの保守性がしばしば見過ごされ、誤解されていると論じます。通常の懸念は、将来もベンダーが存続するかどうかですが、彼はこれが問題にアプローチするには弱い着眼点であると考えています。存続しているベンダーがいることは有利ですが、それが保守性の保証にはならないと指摘します。実際、いくつかのベンダーは、新しいバージョンを販売するために保守不可能な製品を作るという逆説的なインセンティブを持っています.

インタビュー対象者は、保守性の問題は異なる視点から検討されるべきだと強調します。彼は、エンタープライズサプライチェーンシステムのような複雑なソフトウェアは、何百万もの可動部品と多数の企業が同時に関与していることを説明します。これらのシステムは、多様なハードウェアやオペレーティングシステムと互換性を保つため、絶え間ないアップグレードと変更に直面します。Microsoftが100万台以上のプリンターと互換性を保っていることを例に、互換性の確保が大規模な取り組みであることを示しています.

彼は、特に保守性を持つように設計されていない限り、ソフトウェアは本来保守可能ではないと主張します。また、焦点は単一のベンダーの存続だけでなく、サプライチェーンに関与する全企業のエコシステムに向けられるべきだと強調します。Vermorelは、保守性は主に設計の問題であり、特に技術的質量の保存にあると考えています.

デモを通じてクライアントを獲得するために、企業はしばしばデータ可視化、ユーザーエクスペリエンス、リアルタイム分析のために最先端かつ革新的な技術を使用します。これにより「wow効果」が生まれ、販売のポイントとなります。しかし、Vermorelは、このアプローチに異議を唱え、1980年代初期のテキスト端末に似た外観の古めかしいERP画面を例に挙げます。見た目は古めかしいものの、これらの画面は信じられないほど高速で応答性に優れ、依存関係も最小限であるため、非常に保守性が高く効率的です.

Vermorelは、ソフトウェアのすべての層で革新が必要なわけではなく、カレンダー管理やパスワード管理のような特定の領域での安定性がより重要であると強調します。また、ソフトウェアエンジニアリングは学ぶべき豊かな歴史があるため、保守性を優先すべきだと指摘します。しかし、クライアントや見込み客はしばしばこの側面を見落とし、ソフトウェアの保守性よりも、企業が将来存続するかどうかに重点を置きがちです.

あるpiece of softwareが保守可能かどうかを判断するために、Vermorelはベンダーが提供するインセンティブに注目することを提案します。例えば、初期に高額な導入費用を請求し、収益を集中させるベンダーは、その費用を可能な限り何度も繰り返すインセンティブがあるかもしれません。一方、Lokadはコミットメントなしの月額料金を請求しており、企業がリスクを共有することで保守性を優先することを保証しています.

Vermorelはまた、Software as a Service (SaaS) ソリューションの重要性を強調します。なぜなら、SaaSはベンダー自身が自社ソフトウェアの保守を担うことを保証するからです。彼は、企業が多数の最先端コンポーネントを誇示し、その各々のライフサイクルにより保守が悪夢になるような技術的複雑性に対して警鐘を鳴らします。代わりに、サプライチェーンの実務者にとっては、シンプルで保守しやすいソリューションが優先されるべきだと提案しています.

Vermorelは、企業がサプライチェーンシステムに投資していても、さまざまな不具合や問題が発生するため、時間とともに使用不能になることが多いと説明します。不具合が増えるにつれて、ソフトウェアは保守・運用が難しくなり、その結果、ユーザーはシステムの機能を放棄し、Microsoft Excelのspreadsheetsに頼るようになります.

彼は、この状況は業界ではよくあることであり、完全に保守不可能となったソリューションの兆候を反映していると述べています。Vermorelは、派手なユーザーインターフェイスが必ずしも製品の良好な機能を保証するものではなく、潜在的な保守性の問題を隠す可能性さえあると警告します。一方、古めかしいユーザーインターフェイスもまた、ベンダーの保守や更新が不足していることを示す警告サインとなり得ます.

保守不可能なソフトウェアの罠に陥らないために、Vermorelは企業に対し、開発者の保守性に対する計画を徹底的に問い、そのソフトウェアの長期的な実行可能性に寄与する重要な設計決定を理解するよう助言しています。彼は、保守性を慎重に考慮しなければ、業界のソフトウェアは基本的に保守不可能になりがちであると強調します.

Vermorelは、サプライチェーンソフトウェアと金融におけるハイフリークエンシートレーディングシステムとの類似点を強調し、どちらもテキストベースのユーザーインターフェイスを用いることが多いと締めくくっています。これらのインターフェイスは見た目こそ古めかしく見えるかもしれませんが、依存関係が最小限に抑えられ、洗練された設計のおかげで効率的かつ保守性に優れています.

完全な書き起こし

Kieran Chandler: サプライチェーンソフトウェアに投資する際、数年ではなく何十年も会社に貢献するという期待があります。しかし、ベンダーの視点から見ると、急速に変化する技術環境により、単にそのソフトウェアを維持すること自体が並大抵のことではありません。したがって、本日は保守性とその挑戦の理由、そして優れた設計がどのように影響を及ぼすかについて議論します。非常に興味深いトピックであり、通常、ソフトウェアと結びつけて考えない保守性という概念にも焦点を当てます。ソフトウェアは実際には劣化しないものと思われがちですが、ではその考えは何なのでしょう?

Joannes Vermorel: 実は、ソフトウェアも劣化します。もちろん、使用後に摩耗が発生し物理的に脆くなる機械的な劣化とは異なりますが、時間とともに物事は崩壊していくのです。これは非常に驚くべきことで、例えばMicrosoftのような世界最大級かつ成功しているソフトウェア企業は、製品の長期的な存続に対する並外れたコミットメントを持っていたために、驚異的な成功を収めたのです。実際、1995年に編集されたMicrosoft Word文書を現在でも開いて印刷できるという事実は、Microsoftの成功の証と言えます。多くの人が気付いていないのは、Microsoftがこの点において非常に独自の姿勢、すなわち製品に対する長期コミットメントを持っていたということです。もし彼らの競合他社の製品を試みたとしても、現在ではMicrosoft WordやExcelに多くの競合が存在した事実すらも忘れ去られており、動作しなかったでしょう.

Kieran Chandler: そうですね、技術の風景は本当に急速に変化しています。では、Microsoftは何をうまくやったのでしょうか?なぜ彼らはソフトウェアの寿命に影響を与えることができたのでしょうか?

Joannes Vermorel: 根本的には、彼らは本気で取り組み、莫大な投資を行ったのです。多くの人々は、Microsoft Windowsが膨大な機能を持ちすぎていると不満を言い、Linuxのオペレーティングシステムはよりスリムで、整理され、全体的に理にかなっていると主張します。それは確かに真実です。しかし、25年前にLinux向けに書かれたプログラムを実行しようとすると、動作しません。私が90年代のティーンエイジャーの頃にWindows 95で購入したゲームは、今日でも動作しています。これがその証明だと私は信じています.

Kieran Chandler: 圧倒的なレベルのコミットメントがあれば、物事は正しく行うことができるのですね。そして、Microsoftが保守性を確保するために行っていることについてのブログを読めば、彼らが実際に途方もない努力をしていることが分かります。しかし、サプライチェーンソフトウェアの場合、市場がそれほど大きくなく、そのような大規模な努力をする企業が存在しないため、同じレベルのコミットメントは期待できません。さらに、サプライチェーンソフトウェアは通常分散型で、多くの可動部品が関与するため、非常に複雑であり、保守性が一層困難になります。では、なぜそもそも変更が必要なのか、ソフトウェアを凍結して永遠に使い続けることができないのか、という疑問が生じるのですか?

Joannes Vermorel: 答えは、まず、コンピューティングハードウェア自体が変化しているため、これが永遠に動作し続けるとは言えないということです。もちろん、仮想化を利用してこれらの問題の大部分を緩和することは可能ですが、仮想化はかつてのハードウェアを完全にエミュレートするわけではないので、完璧な解決策ではありません。そして、計算を行うためのハードウェアだけでなく、例えば、画面の使用方法が変化したという事実もあります。今日の画面ははるかに多くのピクセルを持ち、タッチスクリーンが採用され、旧来のシステムとは異なる挙動を示す多くの要素が存在します。時には、キーボードのキーがそもそも存在しないといった奇妙な状況すらあります。したがって、もしあるソフトウェアが特定のキー用に設計されていたとしても、その当時は明白であったかもしれませんが、今そのキーが存在しなかったり、キーボードの配置が異なったりすると、直感的でなくなります.

Joannes Vermorel: そして、それは比較的緩やかに進化している問題の一部に過ぎませんが、さらにすべてのセキュリティ問題も存在します。歴史的に製造された多くのソフトウェアは、現代の脅威に対して全く設計されていなかったため、多くのソフトウェアコンポーネントで大量の変更が必要とされるという、莫大なプレッシャーがかかるのです.

Kieran Chandler: つまり、人々は常に職場で最新の技術を使用したがるのですが、これは主要な問題だとお考えですか?それとも、セキュリティの問題や使用上の安全性が欠如しているという点がより重要なのでしょうか?

ヨハネス・ヴェルモレル: まず、保守性というのは、サプライチェーンマネージャーたちがほとんど意識していない問題の一種であり、もし意識しているとしても、その問題を捉える視点は非常に脆弱で、単にベンダーが存続しているかどうかに過ぎません。私の主張は、保守性はベンダーの存続とは無関係だということです。もちろん、ベンダーが存続していることは多少のプラスではありますが、多くのベンダーには次のバージョンをどうやって販売するかという、あえて保守不可能なものを作ってしまう大きな悪戯なインセンティブが存在するため、それほど大きなプラスとは言えません。そもそもこの問題が表面化しないのは、正しい観点から問題を見ていないからです。

キアラン・チャンドラー: 例えば、企業向けサプライチェーンシステムのような複雑なソフトウェアを考えてみてください。何百万という可動部品を持ち、実際に何百万もの部品があり、さらに数十社が様々な理由でその部品の一部を常に微調整しているシステムです。たとえば、新しいハードウェアとの互換性を保とうとすると、その過程で古いハードウェアとの偶発的な不整合が生じることもあります。また、LinuxやWindowsが常に変化しているため最新のオペレーティングシステムとの互換性を求めると、結果として古いシステムとの互換性が損なわれるかもしれません。

キアラン・チャンドラー: このタスクの規模を理解するために、Microsoftの出版物で、ある時点でMicrosoftが100万台以上のプリンターとの互換性を確保していたと読みました。ドライバー、命令セット、ハードウェアが異なる100万台のプリンターを考えてみてください。これほどの数のデバイスと互換性を保つには、途方もないエンジニアリングの労力が必要です。これはほとんど常軌を逸していると言えます。そして、「Windowsは最低だ。たった今、17年前のEpson 7.1.6 point B(スロバキア版)のプリンターを接続したのに、Microsoftはこのデバイスと100%の互換性がない」という声もよく耳にしますが、そうした批判は当然の結果なのです。

ヨハネス・ヴェルモレル: 冗談はさておき、サプライチェーンのソフトウェアは無数の可動部品を持つ巨大なシステムです。依存しているデータベースは常にアップグレードされ、使用しているネットワークレイヤーも、ウェブサーバーも常にアップグレードされています。つまり、可動部品があまりにも多いのです。そして、特別に保守性を高く設計しない限り、そのソフトウェアは保守性を持たないのが当たり前です。サプライチェーンにおいて重要なのは、単にベンダーが存続するかどうかだけでなく、ベンダーと連携する全ての企業が将来も存続し続けるかどうかという長期的な視点が必要であるということです。ですから、企業が存続するかどうかという点は、私にとってあまり重要ではありません。本来、そのような考え方は正しい方法ではありません。もし存続しているベンダーが、より多くのライセンスを売るために敢えて保守不可能な状態を作り出すインセンティブを持っているならば、保守性に向けた進展を果たしたと言えるでしょうか?それとも、逆の方向へ進んでしまったのでしょうか?人々のインセンティブを通して状況を分析する必要があるのです。さらに、保守性は基本的に設計の問題だと私は考えています。しかし、具体的にどのような設計のことを指しているのでしょうか?ここで私が言いたいのは、いわば技術的集合体の保存についてです。

キアラン・チャンドラー: 見ての通り、もし非常にクールなデモを披露する製品が欲しいなら、最新かつ最先端のデータ可視化ライブラリ、そして最新かつ最先端のUXライブラリが必要です。もし派手なリアルタイム解析を行いたいなら、最新で最もクールなサブシステムが必要になります。デモでクライアントを獲得するためのインセンティブは、「ワオ!」という効果を生むことにあるのです。たとえば、多くのクライアントは、自社のERP画面があたかもテキスト端末のように、黒と白の純粋なテキストだけで構成されていると話していました。「何とかしなければならない」と。

ヨハネス・ヴェルモレル: しかし私はこれに挑戦します。というのも、80年代初頭や70年代後半を彷彿とさせる端末を見ると、人々がそれを使っていて、非常に高速で反応が良いのがわかるからです。画面は超ミニマリスティックで、覚えておくべきごく少数のコマンドしか表示されず、他に気を散らすものは一切ありません。まったく実用性に特化しており、それによって人々は途方もない生産性を発揮しています。見た目は劣っているかもしれませんが、依存関係が全くなく、変わり続けるウェブブラウザに依存しないため、非常に保守性の高いものになっているのです。

つまり、サプライチェーンの最も古い部分と、金融の高頻度取引という最先端の部分を見ると、そのユーザーインターフェースは似たものになっています。超先進的なシステムを用いる量的トレーダーを見ると、そのUIは再びテキスト端末のように見えます。これは少々奇妙ですが、彼らは確かに最先端であるにも関わらず、UIは完全に時代遅れに見えてしまうのです。まさに、ハリウッド映画のような派手なユーザーインターフェースとは正反対です。

キアラン・チャンドラー: 皆が最新技術を使いたがる中で、少し苛立たしくも感じます。つまり、非常に保守性の高い製品を持つということは、結局のところ、最先端であることとは両立しないとでも言うのでしょうか?

ヨハネス・ヴェルモレル: 保守性において最先端であれば、何が問題なのでしょうか?この分野でも確かに進展は見られますが、その効果は「ワオ!」といった驚きを生むものではありません。非常にクリーンなバージョン管理戦略が整い、選んだコンポーネントが柔軟性や保守性を重視するといった興味深い理念を持っていれば、それで十分なのです。

私たちが使用している一部のコンポーネントは、まさにこの理念を持つオープンソースのコンポーネントです。彼らは『マニフェスト』があると言っており、「この問題は過去20年間研究され、設計における最良のトレードオフに収束している」と述べています。そして今後、このコンポーネントに対して行うことは、セキュリティ面で重大な問題が発生しないよう、適切なメンテナンスをすることだけです。

キアラン・チャンドラー: 互換性の面では、偶発的な問題は発生せず、私たちは自らを再発明することもしません。だから、保守性が高いというのは、革新の逆であり、期待外れだと言われるかもしれません。しかし、ソフトウェアのあらゆる層で革新が必要なのでしょうか?例えば、暗号攻撃が発生してアップグレードが必要にならない限り、カレンダーの扱いやパスワードの保存方法を何度も再発明するつもりですか?むしろ、すでに安定性が確立しているものを選ぶべきなのです。

ヨハネス・ヴェルモレル: ソフトウェア工学は新しい分野ではありません。学ぶべき歴史は約50年分もあります。しかし問題は、クライアントや見込み客がその視点に気を留めず、「これからも存在するのか?」という素朴な疑問を投げかける一方で、「次のライセンスを買わせるために、敢えて逆の方法を取っているのではないか?」といった点に目を向けないところにあります。

キアラン・チャンドラー: では、サプライチェーンの現場の担当者は何に注意すべきでしょうか?あるソフトウェアが非常に保守性に優れているのか、あるいは単に少し時代遅れで手抜きなものなのか、その手掛かりは何でしょう?

ヨハネス・ヴェルモレル: まず第一に、インセンティブに注目してください。これは技術的な問題ではなく、むしろビジネス的な問題だからです。例えば、ライセンス購入時にベンダーが高額な実装費用を請求している場合、それはプロジェクトの初期段階で収益が集中していることを意味します。その後は同じような費用が少なくなる、つまり収益が次第に下がっていくのです。ベンダーは、こうした高額な実装費用を繰り返し請求するという構造的なインセンティブを持っているのです。

ここでLokadを例にとってみてください。私たちは定額の月額料金をコミットメントなしで請求しており、通常2年後には損益分岐します。保守性は基本的に定額料金で、そのコストがLokadの利益を削っています。Lokadを位置付ける際、私たちは自らリスクを負い、保守不可能なソフトウェアを持つ代償を払っていると決めたのです。これが、保守可能なものを作る強力なインセンティブとなっています。もし保守ができなければ、利益を得るどころか、むしろ損失を被ることになるのです。

ですから、初期段階でベンダーが損をするような月額サブスクリプションは、問題を正しく捉えるための非常に健全な出発点であり、それによりソフトウェアは保守可能になるのです。そして次に重要なのは、ベンダー自身が自社ソフトウェアの保守に真剣に取り組むかどうかです。これこそが、基本的にSoftware as a Service(SaaS)の本質と言えるでしょう。もし保守不可能であれば、それは何よりもまずベンダーの問題であり、運用するあなたの会社の問題ではありません。

キアラン・チャンドラー: サプライチェーンソフトウェアについて話す際、競合他社のスライドやPowerPointで、ソリューションのあらゆる構成要素が紹介されているのをよく見かけます。TensorFlow、Apache Spark、Kafka、MongoDB、React、Reduxなど、20以上もの非常に洗練された複雑なサブコンポーネントが搭載されているように見え、最先端だと主張されます。しかし、私がそれを見ると、保守するのは悪夢のようになると感じます。なぜなら、各コンポーネントはそれぞれ固有のライフサイクルを持っており、長期的に連携できる保証はどこにもないからです。保守不可能なソフトウェアに出会った具体例や、それに至った問題について教えていただけますか?

ヨハネス・ヴェルモレル: 症状としては、人々がそのソフトウェアを放棄し、サプライチェーンの管理にMicrosoft Excelやスプレッドシートを用いるようになるという点に表れます。大企業がサプライチェーンシステムを購入しなかったわけではなく、むしろ過去数十年で3つものシステムを導入している可能性すらあります。これらのシステムは複雑な予測、補充、品揃え最適化、そしてプロモーション管理モジュールなどを備えています。しかし、ベンダーによる初期導入の支援が終わると、人々は次第に不具合に悩まされ、その問題が積み重なっていき、システムは次第に保守が困難になっていくのです。

キアラン・チャンドラー: では、人々がそのソフトウェアの使用を放棄すると、どうなるのでしょうか?

ヨハネス・ヴェルモレル: 人々がソフトウェアの使用を諦めると、すべての機能を完全に放棄し、最終的にはExcelのスプレッドシートに頼るようになります。彼らは取捨選択を行い、一つの機能、つまりデータをExcelへエクスポートすることだけに絞って取り組むのです。それ以外の機能が動作するという希望は全て放棄してしまいます。

キアラン・チャンドラー: つまり、スプレッドシートに頼るということです。これは、私が数十社で目の当たりにしてきた話であり、完全に保守不可能になったソリューションの典型的な兆候と言えます。

ヨハネス・ヴェルモレル: さて、今日の結論として、輝いているものが必ずしも金であるとは限らないという核心のメッセージをお伝えしたいと思います。派手なUIを持つ企業には、将来的に保守性の問題が潜んでいる可能性があるため、多少の警戒が必要かもしれません。もちろん、見た目が悪いユーザーインターフェースが解決策だとも言っているわけではありません。90年代風のソリューションを提供するベンダーと取引しているのであれば、そのシステムは既にあまりにも保守不可能な状態にあり、ベンダーさえUIのアップグレードすらできていない可能性が高いのです。厳密なルールは存在しませんが、私のアドバイスは、内部開発や自社内製のソフトウェアであっても、常に疑問を呈すべきだということです。開発を担当している人々に、保守性のための計画は何か、今どのような重要な設計判断を下しているのかを問いただす必要があります。そして、もしその設計判断が将来のソフトウェアの保守性にどのように影響を与えるかという明確なビジョンが示されていなければ、経験則として、そのソフトウェアは保守不可能な状態、すなわち本業界において保守性に十分注意を払わずに設計された製品のデフォルトの状態であると判断できるのです。

キアラン・チャンドラー: では、これで終わりにしましょう。今週の内容は以上です。ご視聴ありがとうございました。また次回のエピソードでお会いしましょう。ありがとうございました。