00:02 イントロダクション
01:43 機械化
07:34 パラドックスを超えて
12:14 これまでのストーリー
14:32 今日のサブモジュール
16:24 要件（メインストリーム 1/5）
20:12 デザイン（メインストリーム 2/5）
25:37 構築（メインストリーム 3/5）
30:29 テスト（メインストリーム 4/5）
34:09 メンテナンス（メインストリーム 5/5）
41:12 アイデンティティ（戦線 1/8）
46:35 履歴書（戦線 2/8）
51:43 プラクティス（戦線 3/8）
56:47 バスティオン（戦線 4/8）
01:02:00 コードライター（戦線 5/8）
01:06:23 痛みの耐性（戦線 6/8）
01:14:55 生産性（戦線 7/8）
01:21:37 未知のもの（戦線 8/8）
01:27:00 結論
01:29:55 4.6 サプライチェーンのためのソフトウェアエンジニアリング - 質問はありますか？
説明
複雑さと混沌を抑えることは、ソフトウェアエンジニアリングの基本です。サプライチェーンが複雑で混沌としていることを考慮すると、サプライチェーンが直面するほとんどの企業ソフトウェアの問題は、悪いソフトウェアエンジニアリングに帰結することはあまり驚くべきことではありません。最適化されたサプライチェーンのために使用される数値レシピもソフトウェアであり、したがって同じ問題に直面します。これらの問題は、数値レシピ自体の洗練度とともに強度を増します。適切なソフトウェアエンジニアリングは、サプライチェーンにとって無菌状態が病院にとっての役割であるようなものです。それ自体では何もしませんが、それがなければすべてが崩壊します。
フルトランスクリプト
このサプライチェーンの講義シリーズへようこそ。私はジョアネス・ヴェルモレルです。今日は「サプライチェーンのためのソフトウェアエンジニアリング」を紹介します。ソフトウェアは現代のサプライチェーンの実践の基盤ですが、ほとんどのサプライチェーンの教科書ではソフトウェアの役割が大幅に過小評価されています。サプライチェーンの視点から見ると、ほとんどの作業はソフトウェアによって駆動され、ソフトウェアのバグや制約、ソフトウェアに関連する懸念によって駆動されています。
ソフトウェアエンジニアリングは、人々がより良いソフトウェアを作り出し、ソフトウェアからより多くを得るための野心を持っている学問です。また、このソフトウェアをより速く作り出し、より少ない費用でより多くを達成するための学問でもあります。この講義の目標は、ソフトウェアエンジニアリングの本質を理解し、サプライチェーンにとってのその重要性を理解することです。また、サプライチェーンの実践者として、ソフトウェアの取り組みを敵対化する行動や不行動によってサプライチェーンを妨害することを避けるためにできることを理解することもこの講義の目標です。
20世紀は労働力の機械化の世紀でした。大企業や大規模なサプライチェーンは、20世紀に登場し、労働力の機械化によってもたらされた進歩は驚異的でした。過去の1世紀において、サプライチェーンに関連する生産や流通などの労働集約的なタスクにおいて、生産性は100倍に増加しました。
それに対して、私は21世紀が知的労働の機械化の世紀であり、この移行は非常に理解しにくいと考えています。物理労働力の機械化から知的労働の機械化への移行には、まったく異なる直感が適用されます。私は移行がそれほど劇的ではないと言っているわけではありませんが、現時点では、非常に労働集約的なタスクに従事していた労働力の排除への移行は既に終わっています。
2020年のフランスでは、事務職の人口は2700万人であり、工場労働者は100万人未満でした。その比率は27対1です。知的労働の機械化がどのようなものかを見ていくと、非常に驚くべきことであり、またモラベックの逆説としても非常に関連しています。
コンピュータ科学者のハンス・モラベックは、1980年に、チェスのグランドマスターになるなど、人間の心にとって最も困難なタスクは、実際にはコンピュータで対処するのが最も簡単なタスクであると指摘しました。逆に、人間にとって非常に簡単なタスク、例えば二本足で立つことなどは、コンピュータにとっては非常に困難なタスクとなります。これがモラベックの逆説の本質です。コンピュータを用いた知的タスクにおいて、何が達成するのが困難かについての私たちの直感は非常に欺瞞的です。
さらに問題を複雑化させるものの一つは、白衣の労働者の自動化が白衣の労働者自身によって行われるということです。これは青衣の工場労働者の場合とは異なります。彼らは工場がさらに機械化され、彼らの仕事がなくなることを決定する立場にはありませんでした。しかし、白衣の労働者の仕事ではこれが起こっています。したがって、モラベックの逆説によって機械化プロセス自体が非常に直感に反するものであるだけでなく、この機械化を実施する責任者であるソフトウェアエンジニアの管理も非常に直感に反するものです。これはおそらくサプライチェーンにとって最大の課題の一つです：この機械化に関わる人々の管理。
ここで、私は多くのサプライチェーンや関連企業がまだ20世紀のマインドセットに固執していることを指摘せざるを得ません。つまり、企業の世界にアプローチする際には、知的労働を行う白衣の人々が解決策や計画を考え出し、それを青衣の労働者に渡して実行させるという方法です。しかし、フランスをはじめとする先進国では、事務職と工場労働の比率が27対1であることから、現在はそうではありません。それは文字通り自分自身の仕事を自動化することであり、これは21世紀の世界において、非常に優れた白衣の労働者が常に自動化を進め、自分自身を使い物にしなくなり、次のことに進むということを意味します。これはまだ20世紀のマインドセットに固執している多くの企業にとって非常に困難な課題です。
ソフトウェアエンジニアリングの概念については、意見が大きく分かれています。コンピュータ科学の創始者の一人であるエドガー・ダイクストラは、ソフトウェアエンジニアリングは学問や研究の分野としては不可能であり、むしろ「できない場合のプログラミング方法」といったレシピに還元されると述べ、非常に厳しい批判を行いました。ダイクストラの興味深い批判は、ソフトウェアエンジニアリングが成功しない自己啓発のフィクションになり得ないということです。実際に、ソフトウェアエンジニアリングの目標は有用で優れたソフトウェアの作成の成功を保証することであると提案すると、ソフトウェアエンジニアリングはほとんど絶望的です。ソフトウェアの成功は非常に困難であり、科学の成功と同じくらい困難です。それには天才の火花とかなりの運が必要であり、そのためのレシピは存在しません。さらに、すべての成功は、その成功を達成するためにかかった機会そのものを消費する傾向があり、その結果、すべてが非再現的になります。
しかし、私はソフトウェアエンジニアリングが絶望的であるという見方には反対です。私はソフトウェアエンジニアリングの野心を定義することが主な問題だと考えています。ソフトウェアエンジニアリングの野心をソフトウェアの作成の成功と定義すると、確かに絶望的です。しかし、ソフトウェアエンジニアリングを実験心理学の狭い分野としてアプローチすることに決めれば、この視点を通じて非常に価値ある具体的な洞察を得ることができると信じています。したがって、ソフトウェアエンジニアリングはソフトウェアエンジニア自身とその相互作用についてのものです。ソフトウェアエンジニアに焦点を当てることは良い出発点です。なぜなら、ソフトウェア技術は常に変化しているのに対して、人間の性質は時間の経過とともに安定しているからです。この技術に苦しんでいる人々の性質はそうではありません。人間の性質は非常に長い間非常に安定しています。
科学などの他の分野を見ると、その実践者が何をしているかを検査するレンズを通じて分野にアプローチすることが非常に有益であることがわかります。たとえば、科学では、利益相反が悪い科学と知識の腐敗につながることが広く認識されています。このポイントは以前の講義「企業ソフトウェアのための対抗市場調査」で取り上げられました。この視点から、実践者自体に焦点を当てることで、広範な適用性と関連性の洞察を得ることが可能です。したがって、ソフトウェアエンジニアリングはソフトウェア技術に取り組んでいる人々、彼らの苦労、そして彼らのプロセスについてであり、それほど技術自体についてではありません。
今日は4つの章の6回目の講義です。この章では、サプライチェーンの補助科学について取り上げます。これらの補助科学は、現代のサプライチェーンの実践において基礎的な重要性を持つ要素だと考えていますが、厳密にはサプライチェーンの要素ではありません。むしろ、サプライチェーンの実践をサポートする要素のようなものです。
これまで、この第4章では、コンピュータの物理学から始まり、ソフトウェアの中で最も小さな興味のある要素であるアルゴリズムに進んできました。そして、サプライチェーンだけでなく、機械学習などの他の関連するソフトウェアの取り組みにも関心がある数学的最適化に移りました。数学的最適化はサプライチェーンに直接関心がありますが、サプライチェーンにも直接関心があります。さらに、すべての興味深い成功は、その成功を達成するためにかかった機会そのものを消費する傾向があり、その結果、すべてが非再現的になります。
数学的最適化と機械学習に関しては、現在の興味深い概念とパラダイムのほとんどはプログラムの性質です。単純なアルゴリズムだけでなく、非常に表現力豊かであり、プログラミング言語のレンズを通じてアドレスされる必要があります。そのため、最後の講義は言語とコンパイラについてでした。
今日は、この抽象化の階層をさらに上に進み、彼らが何をしているかではなく、人々に焦点を当てます。私たちはソフトウェアエンジニア自身に焦点を当て、それがこのソフトウェアエンジニアリングの分析の全体のポイントです。
今日は、ソフトウェアエンジニアリングについての2つの視点を具体的に紹介します。まず、私はこの分野を支配していると考える主流の見方を紹介します。残念ながら、この主流の見方は以前に述べたように批判を引き起こし、自己啓発的なアプローチを提示している人々によって批判されています。私自身を含め、これらの誤った洞察がまだ非常に人気があるため、これらの誤った概念に精通していることは非常に重要です。無能な人々があなたのサプライチェーンを無能さによって危険にさらす可能性があるためです。
そして、私は塹壕からの視点に移ります。これは、私がソフトウェア企業のCEOとして、まさにエンタープライズサプライチェーンソフトウェアの分野で運営しているソフトウェア会社の経験に根ざした要素の集合です。見ていくように、洞察は技術自体についてではなく、非常に人に関するものです。
ソフトウェアエンジニアリングの主流の見方では、ソフトウェアの要件を収集することからソフトウェアの取り組みが始まると述べています。大企業のほとんどのソフトウェアプロジェクトは、通常、提案依頼（RFP）、見積依頼（RFQ）、情報依頼（RFI）といったプロセスを通じてこの視点を採用しています。このアプローチは、機械工学や建設工事で非常に成功した20世紀の慣行から受け継がれたものです。しかし、ソフトウェアに関しては、これらの要件収集のアプローチは非常に誤ったものだと私は考えています。
ソフトウェアでは、自分が何を望んでいるのかはわかりません。何を望んでいるのかを知ることは、常にソフトウェアの中で最も難しい部分です。例えば、在庫の補充という単純な問題を考えてみましょう。問題自体は非常に簡単ですが、良い数量とは何かを定義することは非常に複雑で困難です。一般的な指針として、要件の明確化は、ソフトウェアのピースを書くよりもはるかに困難です。
要件を実現するためには、あなたの直感を現実のフィードバックと対峙させることで、要件を徐々に浮かび上がらせることができます。要件は空から降ってくるものではありません。要件は実験的なプロセスを通じてのみ得ることができ、実際の世界との相互作用が必要です。しかし、この相互作用を持つ唯一の方法は、ソフトウェア製品を持つことです。なぜなら、要件の収集は基本的には非常に経験的で進化的なプロセスだからです。問題は、要件が整った時点で、要件を持っていても、それはすでに要件を実装した製品を持っているということです。したがって、適切な要件にアクセスできるようになるまでには、すでに製品が本番で稼働しており、それが要件を持っているという事実はあまり関係ありません。
したがって、要件を出発点とするプロセスは、私は狂気だと考えています。要件はおそらく最後に遅い段階のドキュメンテーションとして来るべきであり、製品を実装するためにあなたが採用したすべての主要な理由を文書化する場所です。逆の順序ではありません。
要件が明確にされたら、古典的なアプローチでは設計フェーズに進む必要があるとされています。ある程度の設計が行われることは同意します。しかし、この設計フェーズに入る思考方法はしばしば誤ったものです。問題は、変更のコストを管理することです。変更のコストについての古典的な非ソフトウェアの視点は、時間の経過とともに指数関数的に増加するというものです。例えば、設計図だけを扱っている段階で車の設計を変更する場合、変更のコストは最小限です。一方、何百万もの車が道路上にある状態で設計を変更する場合、変更のコストは非常に高くなります。なぜなら、リコールが必要になり、非常に高額な費用がかかるからです。
しかし、物理的な領域とは異なり、ソフトウェアの領域では、変更のコストは自然に指数関数的に増加するわけではありません。コストの増加は完全に緩和することはできませんが、ある程度までコストの増加を管理することは可能です。実際、変更のコストは時間の経過とともに増加しますが、主にコードベースが時間の経過とともに成長するためです。私はこれまでに、エンタープライズソフトウェアのコードベースが1年から次の年にかけて大幅に縮小したことはありません。それらは成長し続ける傾向があります。それにもかかわらず、ある程度まで変更のコストを管理することは可能です。
title: “ソフトウェアの変更のコストを管理する”
この側面は、ソフトウェアの世界でも広く認識されるようになっています。ところで、これがアジャイル手法の本質です。おそらく、「アジャイルソフトウェア手法を持っています」と人々が言うときに、これらの用語を浮かび上がらせたことがあるかもしれません。アジャイル手法の最大の意図の1つは、変更のコストを管理することです。今日はアジャイル手法の詳細には触れませんが、このアプローチがどのようにして変更のコストを管理するのかについては、少し誤解があると思います。
変更のコストを管理するための一つの側面は、実際に可能な限りすべての決定を先送りにすることを学ぶことです。サプライチェーンの観点からは、これは非常に奇妙に見えるかもしれません。ソフトウェアチームのすべての人と製品およびソフトウェアチームを観察するすべての人にとって、彼らは闇の中に置かれているように見えます。それはそれだけではありません。それは意図的に闇の中に置かれているのです。これが必要なことであり、意図的に行わなければなりません。それが最低限の言葉で言っても、それは困惑する理由です。
さて、早期の設計決定が時には制御の必要性に根ざしている場合、この制御の必要性に関連する問題はそこで終わりません。設計フェーズが終わったら、ソフトウェアエンジニアリングの主流の見方では、ソフトウェアの構築、または実装フェーズに進むべきだとされています。通常は、いくつかのウォーターフォールプロジェクション、またはガントチャートと呼ばれるものを提示します。画面に表示されているのがそれです。私はこのアプローチ、ガントチャートとウォーターフォールを信じられないほど有害だと考えています。ソフトウェアに関しては、このアプローチの有害性を過小評価してはなりません。このように問題に取り組むことは、少なくともソフトウェアの取り組みにおいては、サプライチェーンを失敗に導くことになります。
問題を理解し、ソフトウェアの構築に取り組むためのはるかに良い方法は、それを学習プロセスと考えることです。ソフトウェアの構築は、良い製品を得るために必要なすべてを学ぶことです。これは学習プロセスであり、その学んだ部分は、構築プロセスから出てくるソフトウェアとの相互作用によって生まれる副産物です。ウォーターフォール予測の主要な問題は、あなたが発見しようとしているものを予測しているということです。これは定義上不可能です。発見しようとしているものは、それらの要素を発見するまで不明でした。あなたは自分の発見を予測することはできません。それらを期待することはできますが、発見しようとしているものの詳細を計画することはできません。予感は持つことができますが、それが最高のものです。曖昧な直感を正確なウォーターフォール予測に変えることができるという考えは、再び完全な狂気です。
ところで、ソフトウェアの構築という学習プロセスについてのこの小さな見かけの逆説は、ソフトウェアの複製が非常に簡単または非常に困難である理由も説明しています。もしチームが既に市場に存在するソフトウェア製品を複製しようとし、このチームがソフトウェアの製造につながる理解や教訓にアクセスできる場合、通常、ソフトウェア製品の複製（再実装または再コーディング）は、最初にソフトウェアを作成するために必要だった時間と予算のごく一部で行うことができます。一方、チームがこれらの高レベルの洞察力にアクセスできず、例えば、ソースコードにアクセスできるのはそのチームの唯一の手段である場合、チームは非常に低品質の製品を作り上げることが非常に頻繁にあります。本質的に、学習の部分や知識の断片が失われてしまったのです。あなたは単に製品の表面的な外観を複製しただけです。
サプライチェーンの観点からは、ここで最大の課題は、意図的にコントロールの必要性を放棄し、抑えることです。ウォーターフォールプロセスは、プロセスをコントロールしたいと考える企業の表現です。例えば、「このプロジェクトをコントロールしましょう」と言った場合、それは非常に合理的なこととして認識されるでしょう。なぜ逆のことをするのでしょうか？例えば、「このプロジェクトを完全にコントロールから外しましょう」と述べるのはなぜでしょうか？しかし、現実のソフトウェアに関しては、この程度のコントロールは完全な妄想ですし、最終的には高品質な製品を提供する能力を完全に損ないます。サプライチェーンの観点から見ると、ソフトウェアの構築においてコントロールの欲求を抑えることはおそらく最大の課題です。
コンピュータプログラムの登場以来、それらはバグや欠陥に満ちていました。これらの明らかな問題に対処するためには、テストが行われる必要があるというのが主流の考え方です。テストにはさまざまな形式があります。テストの必要性については、同意しますが、この時点では非常に曖昧です。一部のツールは、テストは構築後に行われる必要があると強調しています。一部のアプローチでは、テストは構築中に行われる必要があると述べており、他のアプローチでは、テストは構築前に行われる必要があると指定しています。一部のアプローチでは、テストはソフトウェアの構築前、構築中、構築後に行われる必要があると述べています。
問題に対する私の一般的な見解は、フィードバックループをできるだけ短く保つために必要なことをすべて行うべきだということです。前の講義でこのポイントについて議論しました：フィードバックループをできるだけ短く保つことは、実際の世界でうまく機能するものを実際に得るために非常に重要です。したがって、私は通常、テストに関して何をしているかが実際にこのフィードバックループを締めるのかどうかに注意を払うことをお勧めします。例えば、ほとんどの状況では、テスト駆動開発（テストが最初に来るという方法論）を自然にお勧めすることはありません。なぜなら、ほとんどの状況では、最初にテストを行うことは、ソフトウェアの一部についての世界からのフィードバックを得るまでの時間を遅らせるだけだからです。
ただし、テストについての私の最大の懸念は、語られていない制約、一般的には無視されている制約です。テストは最終的には、あなた自身が確立したルールに対する適合性のみを評価することができます。問題は、ソフトウェアには厳格な制約が存在しないということです。あなたが解決しようとしている問題に対する製品の適切さをアプローチするための化学的な方法はありません。これは物理的な領域とは非常に異なります。例えば、機械工学では、基準となる基準があります。部品の寸法公差です。機械工学においてエンジニアリングを行う場合、寸法公差は最も重要な要素です。それは明らかで自然な候補です。しかし、ソフトウェアには自然で明らかな候補は存在しません。
ここでの問題は、適切さの問題です。安全在庫などのサプライチェーンの例を取る場合、安全在庫の計算を検証するための自動テストスイートを設計するのは非常に簡単です。このようなテストロジックを実装するのも非常に簡単です。しかし、これによって安全在庫が最初から悪い考えであることを知ることはできません。あなたは自分が知っていることだけをテストしているのです。
物理的な機械を扱う場合、摩耗や劣化が予想されるため、機械を稼働状態に保つためのメンテナンスが必要です。しかし、なぜソフトウェアは稼働し続けるために何らかのメンテナンスが必要なのでしょうか？確かに、コンピュータは故障した場合には交換する必要があります。しかし、この側面は非常に限定的であり、エンタープライズソフトウェアでは、機械の物理的な故障は実際のメンテナンスコストの10%にも満たないのです。存在はしますが、この種のメンテナンスの影響は非常に薄いです。
それにもかかわらず、エンタープライズソフトウェアのメンテナンスは非常に重要です。メンテナンスコストは膨大です。多くのエンタープライズソフトウェアベンダーにとって、メンテナンスは実際のエンジニアリングコストの80%以上です。実際、このメンテナンスの必要性を生み出す要因は、物理学とはほとんど関係ありません。最初の要因は、クライアント自体の支払い意欲です。ベンダーがソフトウェアのセットアップに支払った金額に対して、年間メンテナンス料金が20%で済むのであれば、ソフトウェアベンダーはその料金を請求します。コストの観点からは、メンテナンスコストはエンタープライズクライアントの支払意欲によって決まります。
2番目の要因は、ソフトウェアを稼働させ続けるために必要なメンテナンスの種類です。実際、興味の対象となる製品を取り巻く環境は、経過する毎日において製品から逸脱していきます。オペレーティングシステムは進化し続け、データベースシステムも進化し続けます。同様に、ソフトウェアが使用するサードパーティのライブラリも同様です。どのソフトウェア製品も孤立した存在ではありません。すべてのソフトウェア製品は、他の多くのソフトウェア製品に依存しており、それらの他の製品は独自に進化しています。それらのソフトウェア製品を開発している人々は、それらに取り組みながら、それらを変更し続けています。したがって、市場の他の部分との互換性がないために、製品が動作しなくなる時点が訪れます。他の市場との遅れを取り続けるだけで何もしていないのです。2番目の要因は、ソフトウェアを稼働させ続け、他の市場との互換性を保つために行われるすべてのメンテナンスです。
3番目の要因は、製品の有用性を維持するために必要な作業量です。実際、ソフトウェアは特定の時点で設計および開発されましたが、経過する毎日において世界はその製品が最初に設計された時点から逸脱していきます。したがって、ハードウェアの互換性の面で何も壊れることはなくても、世界が変化するにつれて、製品の有用性は減少していきます。なぜなら、世界は製品に組み込まれた期待とは異なる方向に進んでいるからです。ソフトウェアを有用な状態に保つためには、ソフトウェアを常にメンテナンスする必要があります。
サプライチェーンの観点から見ると、メンテナンスは大きな課題です。これについては、サプライチェーン向けの製品指向のデリバリーについて前の講義で触れました。メンテナンスのコストは、ソフトウェアの取り組みから得られる資本的な利益に大きな影響を与えます。理想的には、ソフトウェアの取り組みから非常に高い投資収益率を得たいと思いますが、そのためには、巨大なメンテナンスコストを抱えることがないようにする必要があります。これらのコストは、ソフトウェア投資から得られる利益を完全に打ち消してしまいます。
ここでの最大の課題は、再度サプライチェーンの観点から見ると、メンテナンスコストを最小化する最も簡単な方法は、変化しないものに焦点を当てることです。先に述べたように、ほとんどのコストは、ソフトウェアエコシステムまたは世界全体で変化しているものに関連しています。しかし、変化しないものに焦点を当てると、ソフトウェアの大部分はゆっくりとしか劣化しないことになります。なぜなら、ソフトウェアが取り組むべきものの大部分は変化しないものだからです。
問題は、変化しないものに焦点を当てることが簡単に言われても、実際には非常に難しいという点です。なぜなら、この意図に対抗する非常に人間的な力が存在するからです。それは、見出し、メディア、同僚などを見ていると、常に新しさ、バズワードの連続があり、すべてのバズワードは見逃しの恐れから、ただそのことをやって取り残されないようにするという衝動を持っています。たとえば、AI、ブロックチェーン、IoTなど、非常に現在性のあるものです。私はサプライチェーンでは、これらのバズワードは本当に気を散らすものであり、メンテナンスの問題に大きく寄与していると考えています。なぜなら、それらは変化しないものから注意をそらすものだからです。それに対して、これらのバズワードを見ていると、あなたは波に乗っているのです。そして、時間の経過とともに変化する可能性の高いものに乗っているのですから、メンテナンスコストが時間とともに膨らんでしまいます。
ソフトウェアエンジニアリングに関する主流の見解はこれで終わりですが、サプライチェーンを念頭に置いたソフトウェアイニシアチブを実施するために役立つ一連の個人的なヒントについて掘り下げてみましょう。ソフトウェアの人々と取引する際の最も頻繁な問題の1つは、彼ら自身のアイデンティティについての誤解です。このアイデアは、起業家のポール・グレアム氏から借りてきたものです。例えば、エンジニアは「私はPythonエンジニアです」と言うかもしれません。それほど極端ではないかもしれませんが、ソフトウェアエンジニアは、自分のスキルセットを構成する技術の短いシリーズを通じて自分自身のアイデンティティを認識する傾向が非常に頻繁にあります。このアイデンティティと現在のスキルセットとの混同は、ITおよびソフトウェアの世界で一般的な採用プラクティスによって強化される傾向があります。採用の観点からは、多くの企業が求人広告で「Pythonプログラマーが必要です」と述べています。したがって、一方では「私はPythonプログラマーです」と考えている人がいて、他方では基本的に「Pythonプログラマーが必要です」と書かれた求人ポジションを投稿する会社があります。したがって、適切なアイデンティティを持つことは単なる認識の問題だけでなく、市場で魅力的になるために関連付けられる財務的な報酬が存在するのです。
ただし、技術がソフトウェアエンジニアとしての自己のアイデンティティに結び付けられるこのアイデンティティ主導の認識は、ほぼすべてのソフトウェアプロジェクト、特にサプライチェーンソフトウェアプロジェクトに影響を与える多くの問題を引き起こします。会社の中で場所を占める技術に自己のアイデンティティを強く結び付けている人、通常はソフトウェアエンジニアとのやり取りの際に、その技術の批判が個人的な観点から行われる傾向があります。たとえば、私がPythonプログラマーであり、あなたが私のソフトウェアを批判すると言った場合、私はそれを個人的に受け取ります。問題は、技術の批判を個人的な批判として受け取ると、それらの問題について論理的に考えることが非常に困難になるということです。これらのソフトウェアエンジニアは、残念ながら、フィードバックをすべて逸らす傾向があります。なぜなら、それらを一部個人的な批判と見なしているからです。
逆に、会社がソフトウェアエンジニアが核となるアイデンティティとは異なる技術を使用している場合、例えば、会社がJavaで実装されたシステムを持っており、ソフトウェアエンジニアが「私はPythonプログラマーです」と言っている場合、すべての問題はこの技術の一部が劣っているという視点で認識されます。これもまた、批判とフィードバックが「私の問題ではない。これはこの会社で使用されている非常に劣った技術のせいだからだ」と逸らされるという別の問題です。ソフトウェアエンジニアが使用している技術にアイデンティティが結び付けられている場合と結び付けられていない場合の両方で、技術の改善に向けたフィードバックが逸らされるため、さまざまな問題が生じます。
供給チェーンの観点から考えると、供給チェーン環境は非常に混沌としているため、問題は頻繁に発生します。このような環境の混沌さゆえに、問題に真正面から向き合い、何か対策を講じることができるソフトウェアエンジニアのチームを持つことは非常に重要です。フィードバックが発生した際に、それをただ逸らすのではなく、対策を講じることが重要です。自分たちのアイデンティティの認識に基づいて、供給チェーンの混沌さにドラマを加えるようなチームを組織することは避けるべきです。
この考え方は、ソフトウェアエンジニアにも当てはまります。彼らは自分のアイデンティティや獲得したいアイデンティティに合った技術を選びます。彼らはスキルを獲得するために技術を選び、履歴書にキーワードを追加することができます。しかし、このアプローチは、会社が直面している問題を解決するために関連性のない理由で技術を選ぶことにつながります。これは、組織が特定の問題に対処するために技術が適切かどうかを判断するための間違った視点です。
履歴書を作成することは、ソフトウェアエンジニアにとって強力な動機付け要因になることがあります。履歴書にキーワードのリストがあることには、現実世界の金銭的な利益が関連しています。最高のソフトウェア会社は、キーワードのリストが半ページになるような履歴書を軽視します。LokadのCEOとして、キーワードのリストが半ページになるような履歴書を見た場合、直ちに破棄します。しかし、多くの企業、特に平凡な企業は、多くのキーワードを持つ人材を積極的に求めており、これらの個人は組織内で非常に多目的かつ俊敏になると考えています。私の経験から言えば、これはしばしば逆の結果をもたらします。
アイデンティティと履歴書作成の話題を続けると、ソフトウェアアーキテクトは特定の技術に過度に執着するべきではありません。ソフトウェアエンジニアを雇うこと自体が難しいため、時には妥協しなければならないこともあります。しかし、ソフトウェアアーキテクトに関しては、特定の技術に感情的な愛着を持つ個人を選ぶことは災害的な結果をもたらす可能性があります。これらの個人は、会社全体に大きな影響を与えることになります。
履歴書作成のバイアスの問題は、ソフトウェアエンジニアやソフトウェア関連の専門家に限られるものではありません。IT関連の人々にも同様の問題が発生します。例えば、私は大企業のいくつかのITディレクターに出会ったことがありますが、彼らは既存のレガシーERPが完全に問題ない状態であるにもかかわらず、SAPへの移行を望んでいました。SAPへの移行に伴う巨額のコストは、より現代的なERPの期待される利益によって決して相殺されることはありませんでした。これらの場合、ITディレクターの個人的な利益が会社自体の利益を上回るという非合理な行動が行われていました。
供給チェーンの観点からは、利益相反の問題に注意を払うことが非常に重要です。利益相反を検出するためには、ソフトウェアスキルや能力が必要ではありません。医学のような他の分野では、生命がかかっているにもかかわらず、利益相反のために医師でさえ誤った薬を処方することがあります。これは利益相反が非常に有害であることを示しています。供給チェーン管理の場では、生命がかかっていないため、利益相反を発生させることに対する抵抗感はさらに低くなります。
物理的な領域とは異なり、ソフトウェアの領域では、ソフトウェアの取り組み方やアプローチにはほとんど制約がありません。人間の本性は、構造の欠如によって不安を感じることはありません。その結果、多くのプラクティスが年々現れ、続々と登場しています。それぞれのプラクティスには正統性の概念が付随しています。エクストリームプログラミング、ドメイン駆動設計、テスト駆動設計、マイクロサービス、スクラム、アジャイルプログラミングなど、これらのプラクティスの例は多くあり、毎年新しいものが登場しています。
それぞれのプラクティスには正統性の概念が付随しています。人々がプラクティスに従い始めると、彼らは自分たちが中心的な原則に従っているかどうかを疑問視するかもしれません。ソフトウェアエンジニアもただの人間であり、人々は儀式や部族を愛します。プラクティスは共有の信念を持つ部族に所属する感覚を提供します。これが、これらのプラクティスに関連付けられたミートアップが存在する理由でもあり、非常に人間的なニーズを満たしています。
問題に取り組む際に、何もわからないまま問題を見つめ続け、関連する人がほとんどいないという状況は困難であり、鬱々とした気分になることもあります。興味深いことに、プラクティスは疑問視されることも少し非合理的であることもありますが、その利点は実際に存在します。会社内外でプラクティスを宣伝することは士気を高め、将来の応募者の採用にも役立ちます。
面接で人々があなたの働き方について尋ねるとき、即興でルールがないと言うのはあまり説得力がありません。会社内の問題を解決するためのプラクティスとして自信を持って提示する方が効率的です。重要なポイントは、短期的にはこれらのプラクティスがすべて悪いわけではないということです。所属意識を生み出すことは有益です。ただし、プラクティスがあまりにも真剣に受け止められたり、長期間にわたって続けられたりすると、有害になることがあります。プラクティスは、問題を異なる角度から見るように強制するために興味深いものになるかもしれません。しかし、問題を異なる角度から見た後は、別の角度で見るように努めるべきです。長い間同じ角度で見続けるべきではありません。サプライチェーンの観点から見ると、これはソフトウェアの領域の根本的な奇妙さを示しています。
工場の床では、優れたものとは常に同じことをすることです。ソフトウェアの世界ではまったく逆です。同じことをしている場合、停滞と時間の経過による失敗のレシピになります。
ソフトウェアは複雑であり、エンタープライズソフトウェアはさらに複雑です。しばしば、複数のエンジニアが特定の取り組みに取り組むことになり、それによって特定のコードベースに触れる新しいタスクが必要になると、同じ人物を割り当てるという自然な傾向が生まれます。利点は実在し、この人物は既にコードに精通しているため、より生産的になることができます。
専門化の主な問題は、コードベースの一部に対する所有感を生み出し、さまざまな問題を引き起こすことです。この所有感に関連する問題には、“トラックファクター"と権力闘争があります。トラックファクターとは、独自の知識やスキルを持つ従業員を失うリスクを指します。これは、従業員が他の会社に移籍するか、他の理由で働けなくなる可能性があるためです。権力闘争は、従業員が自分の貢献が会社にとって重要であることを認識し、このレバレッジを利用してより高い給与やその他の福利厚生を要求する場合に発生する可能性があります。
私の経験では、ソフトウェアエンジニアは通常、権力闘争をする傾向はありませんが、これらの問題は大企業ではますます頻繁に発生する可能性があります。この問題に取り組もうとする多くのソフトウェアエンジニアリングのプラクティスがありますが、重要なのは、問題に対処するための特定のプラクティスに固執するのではなく、この問題のクラスについて認識することです。なぜなら、そのようなプラクティスは他の問題を引き起こしたり、注意を向ける能力を制限したりする可能性があるからです。ソフトウェアの観点から言えば、文化こそがこの問題の解毒剤であり、プロセスではありません。
コードの一部に特化した人々が生産性の向上をもたらす一方で、そのコードの一部を所有することに関連するリスクがあるという微妙なトレードオフに直面しています。望ましいのは、チーム全体からコードベースに関する知識のある程度の重複が常に存在する状況を育むことです。つまり、すべてのエンジニアが何らかの能力の重複を持つようにすることです。これは、生産性を維持するために達成する必要がある非常に微妙なトレードオフです。実際の世界でこれを実現する唯一の方法は、ソフトウェアエンジニアリングに関するよく理解された文化を通じて行うことです。同僚の仕事に興味を持つことを保証するプロセスはありません。好奇心に関するプロセスは存在しないのです。それは文化の一部でなければなりません。
ソフトウェアエンジニアのスキルと能力を評価することは困難であり、この問題は重要です。ソフトウェアは明らかにチームの取り組みであり、チームはメンバーの合計以上ですが、チームのメンバーの基本レベルはチーム全体のパフォーマンスに大きな影響を与えます。
ソフトウェア業界外の人々、そして時には業界内の人々にも、執筆スキルの重要性が大幅に過小評価されていると私は観察しました。ソフトウェアを作成している場合、2つの異なる対象を対象にしています。一方では、マシン（コンパイラ）の対象となります。コードを書き、コンパイラがそれを受け入れるか拒否するかを確認します。これは簡単な部分です。コンパイラは、コードが正しいか間違っているかを教えてくれる不屈の相棒です。コンパイラは完全に予測可能で、無限の忍耐力を持っています。
一方、同僚の対象もあります。おそらく、6か月後には自分自身も含まれるでしょう。コードを書き、最終的にはそれを忘れます。6か月後、自分が書いたコードを見て、それが他の誰かによって書かれたもののように思えるほど見知らぬものに見えるでしょう。同僚のためにコードを書く利点は、コンパイラとは異なり、同僚があなたの意図を理解しようとすることです。コンパイラはあなたの意図を理解しようとしません。コンパイラは機械的に一連のルールを適用します。
同僚は理解しようとしますが、残念ながら、彼らはコンパイラのようではありません。彼らには無限の忍耐力はありませんし、あなたのコードによって混乱や誤解を受けることがあります。そのため、例えば、記憶に残る、洞察に富んだ、適切な名前を選ぶことが非常に重要です。良いプログラムは、単に正しいものを持っているだけではありません。変数、関数、モジュールの名前を選ぶことも重要です。これにより、同僚とうまく連携するコードを作成することができます。そして、再び、同僚には6か月後の自分自身も含まれます。サプライチェーンの観点から言えば、執筆スキルは非常に重要です。私はさらに言って、執筆スキルはしばしば生の技術的なスキルよりも重要です。良い執筆スキルは、サプライチェーンに存在する複雑さを取り組むために必要な最も重要なスキルです。アプリケーションの複雑さを取り組むことは、技術的な大きな課題ではありません。それはアイデアと要素を整理し、一貫したストーリーを持つことの課題です。これらは非常に執筆スキルです。以前の講義「サプライチェーンのための執筆」でもこの側面に触れました。
書くスキルは優れたソフトウェアエンジニアになるための最も重要なスキルですが、ソフトウェアエンジニアになるためにはもう一つのスキルがあります。それは、痛みに対する耐性です。実際にソフトウェアエンジニアになるためには、これが一番重要なスキルだと私は信じています。具体的には、私が言う痛みとは、非常に壊れやすく、設計が悪く、あらゆる種類の罠が仕掛けられたシステムに直面する際に伴う退屈さや欲求不満に対する抵抗力のことを指します。時には、そこにいない人々によって仕掛けられたこともあります。ソフトウェアに取り組むと、足元には40年間にわたる蓄積された問題があり、常にそれと戦っています。これは時に非常にイライラすることです。
たとえば、ソフトウェアエンジニアとして、自分が直面しているエラーコードに類似したエラーコードを言及しているウェブフォーラムのランダムな、半ばゴミのような会話を4時間かけて掘り下げる忍耐力が必要です。それを解決するために数週間かかることもあります。その結果、ソフトウェア業界全体で非常に強い逆選択プロセスが働いています。これにより、痛みに対する高い耐性を持つ人々が選ばれるようになります。この逆選択プロセスには2つの主な結果があります。
まず第一に、ソフトウェアエンジニアとして残る人々は、非常に痛みに対する耐性がある傾向があります。私が痛みに対する耐性があると言うとき、私は常に直面するソフトウェアの問題に対する欲求不満に対する抵抗力を指します。痛みに対する耐性が非常に高い人々を選ぶため、彼らは自分の行動が状況を悪化させていることさえ気づかないかもしれません。彼らはソフトウェア製品に余分なクセを追加し、ソフトウェアとのやり取りの痛みレベルを増加させます。しかし、彼らが非常に痛みに対する耐性がある場合、彼らは注意を払いません。この逆選択プロセスにより、注意を払うことができる一般の人々がソフトウェアエンジニアになることができず、痛みに耐えられなかったため、排除されてしまいます。これは特にサプライチェーンソフトウェアにとって非常に深刻な問題です。いくつかの側面は必要ですが、平凡なものであり、この分野で活動する痛みに対する高い耐性を持つ人々が、潜在的に退屈なタスクの多さにより状況を悪化させる可能性があるためです。
この逆選択プロセスの第二の側面は、痛みを伴う問題を避けるために低い給与の仕事を選ぶ余裕がある人々がそうすることです。もし誰かが既に高給をもらっている場合、彼らは給与が低い仕事を選ぶことで痛みを軽減することができます。ほとんどの人々はおそらくそうするでしょうし、実際に多くの人々がそうしています。これは、非常に高い痛みの強度があるこの業界に残る人々は、高給のソフトウェアエンジニアリングの仕事を諦める余裕がない人々であることを意味します。これは、インドや北アフリカから多くのソフトウェアエンジニアが登場する理由の一部を大いに説明しています。これらの国々は教育システムがかなり良く、よく教育された人々を輩出していますが、国がまだ比較的貧しいためです。これらの立場にある人々は、需要が高く、基本給と比較して高い給与が支払われるソフトウェアエンジニアリングの仕事を諦める余裕がありません。彼らには他の選択肢がなく、結果としてこの業界で非常に一般的になってしまいます。
これらの国々には何の問題もありません。これは単に市場の力学的な適用です。これは判断ではなく、ただの観察です。問題は、優れたソフトウェアエンジニアになるためには痛みに対する耐性だけでは十分ではないということです。それは条件に過ぎませんが、もしそれが唯一のものである場合、あなたはかなり劣ったソフトウェアエンジニアになります。サプライチェーンの観点から言えば、ここでの教訓は、会社が集めているチーム、内部的にもソフトウェアベンダーを通じても、痛みに対する耐性だけを持つエンジニアが集まっていないか、注意を払うことです。なぜなら、それはソフトウェアの品質や付加価値において非常に劣った結果をもたらすからです。痛みに対する耐性は必要ですが、それだけでは十分ではありません。
1975年、フレデリック・ブルックスはすでに、ソフトウェアによって作成される価値やソフトウェアエンジニアによって生成される価値を表すものではないと指摘していました。50年近く後の2020年、IT企業は世界で最も多くの雇用を提供しています。アメリカでは2020年にIT業界の従業員は300万人以上であり、自動車産業全体の従業員は100万人以下でした。IT業界の人数は自動車産業の3倍以上です。これらのIT企業の多くは、数百人または数千人の従業員を抱える巨大な企業であり、もはや人月単位での請求は行っていません。これは70年代の話です。現在は労働力単位での請求を行っており、労働力単位は基本的に1000日の労働力を表します。問題は、フレデリック・ブルックスがほぼ50年前に指摘していた問題に比べて、規模と重要性の点で非常に悪化していると言えるでしょう。しかし、初期の教訓の多くはまだ有効です。『神話の人月』はソフトウェアエンジニアリングについて非常に興味深い本です。
ソフトウェアの生産性は非常に異なります。スペクトラムの片方では、生産性が低い人々ではなく、生産性がマイナスの人々が存在します。つまり、彼らがソフトウェア製品に取り組み始めると、それを悪化させるだけです。もはや人々の生産性の比率を作ることはできません。それはそれよりもずっと悪いです。製品を積極的に悪化させる人々がいます。それは大きな問題です。スペクトラムのもう一方では、いわゆる10倍のエンジニアと呼ばれる人々がいます。彼らは平均的なエンジニアの10倍の生産性を持っています。この10倍のエンジニアは実在しますが、この大きな生産性は非常に文脈依存です。10倍のソフトウェアエンジニアを会社間またはポジション間で単純に移動させ、その人が信じられないほどの生産性を維持することを期待することはできません。通常、それはユニークなスキルと特定の状況の組み合わせによって生み出されるものです。それにもかかわらず、ソフトウェア製品によって生成される価値の大部分を生み出すのはごくわずかな人々であることを心に留めておくことは重要です。時には、ソフトウェアのすべてのスマートな要素と真の付加価値の大部分を作成しているのはたった一人の人物であり、残りの人々は最高の場合でも疑わしい付加価値を持つものに対処しています。ここで特定された教訓は、サプライチェーンで締め切りに追われている場合、ソフトウェアイニシアチブの範囲を縮小することが唯一の合理的な選択肢であるということです。他の選択肢はすべて悪いです。
人員を追加することは悪化させるだけであり、遅れているソフトウェアプロジェクトに人員を追加するとさらに遅くなるとよく言われています。ブルックスのこの声明は50年前に有効であり、現在でも有効です。他の選択肢も機能しません。残業をさせると、人々は疲れてバグを作り、製品の遅延を引き起こします。品質を下げようとすると、もはや機能しないものになります。これらのことは制御を失い、手に負えなくなりますので、品質に妥協することはできません。
サプライチェーンの観点から言えば、もし10人以上のフルタイムのソフトウェアエンジニアが必要なイニシアチブに取り組む場合は、非常に注意して進める必要があります。通常、それは非常に悪くフレーム化された問題であることを示しています。10人の人々が同時に同じ製品に取り組むためには、信じられないほどのチームワークが必要です。サプライチェーンでは、人々はしばしば規模や関与する人数について野心的すぎる傾向があります。50人、100人、または200人が同時に作業するERP移行プロジェクトを見たことがあります。これはまったく意味がありません。どの程度の協力を実現するにしても、摩擦を回避するために非常に能力のあるチームプレーヤーが必要です。苦労している場合は、ソフトウェアイニシアチブを焦点を絞り、短期間で狭く保つことが重要です。
最後の観察は、大企業に関するよくある誤解についてです。多くの人々は大企業はリスク回避的だと言うでしょうが、私の経験ではそうではありません。私の経験では、大企業は不確実性に対して回避的であり、リスクに対して回避的ではありません。ただし、遠くから見ると、これら2つは混同されることがあります。遠くから見ると、合理的な説明として大企業はリスク回避的だとされますが、実際には、確実な失敗と不確実な成功の選択肢がある場合、大企業は必ず確実な失敗を不確実な成功よりも選びます。
大企業は必ず確実な失敗を不確実な成功よりも選びます。これは表面上は困惑し、非合理的に見えるかもしれませんが、実際にはそうではありません。大企業は単一の存在ではありません。大企業は多くの人々から成る政治的な存在です。政治と外見は非常に重要であり、特に非常に大きな組織では特に重要です。
ソフトウェアイニシアチブを担当している人の視点を考えてみましょう。一方では、結果が確定しているイニシアチブがあります-失敗するでしょう。しかし、あなたはルールに従ってプレイし、誰もがそれが失敗することを知っています。安全策を取って失敗しても誰もあなたを非難しません。それが期待されていることです。一方、不確実な成功は奇妙に見えます。この道を進むことは、通常とは異なることをすることを意味し、キャリアに損害を与える可能性があります。
サプライチェーンの観点から言えば、ソフトウェアの世界では、本に従って失敗するために自分自身を設定することは、特に本が完全に間違っている場合には避けるべきです。例えば、私はABC分析や安全在庫などの方法を使って何十年もの間、企業が失敗しているのを見てきました。これらの方法は、数学的および統計的な理由から明らかに間違っており、対応するイニシアチブの失敗を保証しています。これらの方法は、教科書の内容であるため、狂気じみては見えなかったため、好ましいとされました。
不確実性を排除するために自分自身を失敗に追い込むことで得られる快適さには注意が必要です。不確実性を排除することが目標ではありません。目標は成功の可能性を最大化することであり、不確実性を減らすことではありません。
結論として、ソフトウェアエンジニアリングはソフトウェアエンジニアだけに任せておくにはあまりにも重要です。ソフトウェアはサプライチェーン全体に広がっており、知的作業の機械化を推進しています。私たちはまだプロセスの初期段階にいますが、既に言えることは、この分野で非常に競争力を持たない企業は、通常の市場力によって完全に市場から排除されるでしょう。サプライチェーンにとって最大の課題は文化的なものです。これは技術的な問題ではなく、文化的な問題です。ソフトウェアエンジニアリングは、私たちが問題を見る方法やアプローチする方法に真っ向から挑戦します。直感的な解決策のほとんどは間違っている傾向があります。
ある意味では、サプライチェーンにおけるソフトウェアエンジニアリングは、カオスを取り抑えること、サプライチェーン全体に広がる複雑さと不確実性を取り抑えることに関わります。ソフトウェアエンジニアの仕事は、プロセス自体が洗練されすぎているか、秩序だっている場合、変化やチャンス、創造性の余地がありません。卓越性と認識されるものはすぐに停滞し、そして失敗に変わります。伝統的な企業にとって、この文化的なアプローチからの最大の課題は、文化の衝撃に加えて、コントロールの幻想を手放すことです。5年間のERP移行計画は幻想です。そんな大規模なプロジェクトには制御できません。同様に、現在のイニシアチブの予想利益を示すビジネスケースも幻想です。
知的作業の機械化に取り組む際、完全に合理的でないことを合理性の名のもとに行うことが最大の危険です。
質問を見てみましょう。次の講義は12月15日（水曜日）に行われ、パリ時間の午後3時に開始されます。その内容はサイバーセキュリティについてです。さて、質問を見てみましょう。
質問: ソフトウェア投資の資本利益をどのように測定しますか？
ほとんど測定しません。測定は取り組みそのものの副産物です。投資の収益を測定することは困難です。この種の質問では、事前に測定を行うことができると前提されています。シナリオを使用してビジネスケースを構築し、ソフトウェア投資を進めるかどうかを決定する前に、事前に測定を行うことができると前提されています。私が言いたいのは、ソフトウェアではそうはいかないということです。まず、何かを行い、それから学ぶ必要があります。そして、途中でどのような利益があるのかさえ学ぶことができます。行動をガイドするためには、高レベルの理解が必要です。何かに絶対に納得しており、直感が正しいと感じる場合、ゴミのような数字に基づく見かけの合理性よりも、はるかに合理的な議論になる場合があります。実際には、ソフトウェアの取り組みを進めるにつれて、測定はより明確になります。なぜなら、目指していることについて学び始め、自分がやるべきこととの適合性を測定する方法を学ぶからです。測定は、うまくやれば副産物として現れるものです。しかし、その結果として、ソフトウェアに関しては、ただ試して早く失敗する方がはるかに良いです。大規模なコミットメントに巻き込まれたくないので、非常に段階的な方法で行い、少人数で高い生産性を持って行う方が良いです。進め方は途中で学んでいくものです。
しかし、そこには別の問題があります。それは、企業の経営陣が同時に多くのイニシアチブをうまくやりくりできるようにする必要があるということです。これは非常に困惑することです、特により伝統的な企業にとっては、経営陣は異なる方向に向かって進む多くのイニシアチブを持つことを予想していません。しかし、これは実際には、大規模なソフトウェア企業で数十年にわたってすでに起こっていることであり、これは人間の視点からのソフトウェアエンジニアリングの教訓の一つです。
質問: 多くのキーワードを持つ人は特定の技術と関連付けられないと言うことは矛盾していませんか？
いいえ、多くのキーワードを持つことで、特定の技術との関連付けから保護されるとは言いません。これは2つの異なる問題です。1つは、個人のアイデンティティ、認識されたアイデンティティ、およびスキルセットの間に強い関連性を持つ人物の問題です。それが問題番号1です。問題番号2は、履歴書を作成することには非常に強い利益相反があるということです。私のメッセージは、一方で、アイデンティティ政治に注意してください。それらは非常に有毒です。私の2番目のメッセージは、利益相反にも注意してください。それらも非常に有毒です。
さて、特定の技術に特に重点を置くと、履歴書から好ましくない技術のキーワードを削除することがあります。ただし、通常、これらの2つの問題は別々です。例えば、スライドで示したように、「私のアイデンティティはPythonプログラマーです」と言いながら、履歴書に20以上のキーワードを記載することができます。これらの2つのことは相互排他的ではありません。同時に発生することさえあります。また、アイデンティティが何かを獲得したいという願望に関連付けられることを過小評価しないでください。例えば、「これまで主にPythonをプログラミングしてきましたが、Rustプログラマーになりたいので、自分自身をRustプログラマーと考えることにします」と言うこともあります。さまざまな行動が可能です。
質問: ソフトウェアエンジニアリングはサプライチェーンの補助科学とされていますが、ソフトウェアエンジニアリングの補助科学は何でしょうか？
ソフトウェアエンジニアリングに関しては、心理学、社会学、民族学などが関連する分野です。人々の相互作用としてアプローチすると、これらの補助科学は重要です。ソフトウェアエンジニアリングにおいて真剣に取り組むためには、ソフトウェア技術だけでなく、人々の相互作用が意味を持つようにソフトウェアの文脈を理解する必要があります。コードの中身を理解する必要はないかもしれませんが、コードベースや存在するツール、それらが解決しようとしている問題などの概念を理解する必要があります。ただし、このサプライチェーンの講義シリーズの目的には、研究のあらゆる分野を網羅することはできないため、線引きをする必要があります。
質問: 10人の賢い人に解決策を求めると、10通り以上の方法が出てきます。そのうちの上位5つの解決策に合意し、一貫して使用することがより良いです。この2つの相反するアプローチと利点のバランスをどのように取るのでしょうか？
これは非常に広範な質問ですが、ソフトウェアエンジニアリングの具体的な場合に絞って考えてみると、多くの提案があるかもしれませんが、すべてを同じ重みで考慮する必要はありません。ソフトウェアの長期的なビジョンを持つというスキルが存在します。何が変わらないかに焦点を当てると言ったとき、この仕事に非常に優れた人もいれば、そうでない人もいます。経験は、長期的なビジョンを持つためのスキルを持っている人や、何が変わらないかを見るためのスキルを持っている人を見極める際に重要な要素です。私の経験では、このスキルを非常に優れたレベルで持つには、少なくとも35歳以上になる必要がありますし、最も優れた人々は60歳以上です。動きやパターンを見るには、数年の経験が必要です。
あなたが多くの人々を持っていると言ったとき、すべての解決策が良さそうに見えるという幻想がありますが、それは見た目だけのことです。どれだけの労力がかかるかはわかりません。単にプロトタイプを作成したり、テストしたりすることはできますか？10人の中には、長期的には有害な解決策を特定するための独自のスキルを持つ人はいますか？メンテナンスコストは、あなたが行った決定によって実質的に決まります。将来に長期的に影響を与える重要な決定はありますか？
これは難しい側面ですが、長期的なビジョンを持つ人は、なぜあるオプションが長期的に問題を引き起こすのかを説明することができます。これは単なる予感や直感ではありません。彼らは、「このようなことは経験済みです。他の製品でそれを見たことがあります。」と言います。言い換えれば、賢い人は自分の過ちから学びますが、賢明な人は他人の過ちから学びます。これはこの場合に非常に当てはまります。
質問: 企業は、サプライチェーンのソフトウェアを導入するために投資した1ドルあたりの運用効率の向上をどのように測定していますか？
これは非常に困難な質問です。問題は、パラダイムの非可測性です。これは認識論から来ており、一つの運用方法から別の運用方法に移行する際に、それらのパラダイムが根本的に異なる場合、ほとんどの指標は無意味です。例えば、テレセールスと電子商取引を比較してみましょう。郵便注文会社は19世紀中頃から存在していました。電子商取引を郵便注文会社の改善と見なすと、改善を測定しようとすることができますが、現実は、ほとんどの郵便注文会社が倒産しました。現在主導権を握っている電子商取引企業は、最大の郵便注文会社よりも桁違いに大きいです。Amazonはおそらく、最大の歴史的な郵便注文会社の100倍以上の規模ですが、比較は非常に曖昧です。
知的な仕事の機械化は非常に困惑し、謎めいています。物理的な生産では、効率を典型的な方法で測定することができます。しかし、知的な仕事を機械化し始めると、効率とは一体何を意味するのでしょうか？Amazonのような企業では、サプライチェーン全体が完全にソフトウェアによって駆動しています。もし人々がただ家にいて何もしない場合でも、おそらくサプライチェーンは問題なく動作するでしょう。では、なぜAmazonはそれらのエンジニアを雇い続けているのでしょうか？それは彼らが改善に投資しているからです。
ちなみに、ジェフ・ベゾスについて興味深いことは、彼の経営プロセスである「意見の不一致でもコミットする」というものです。彼は、自身がCEOとしての直感でプロジェクトが間違っていると感じ、プロジェクトに反対することがあります。しかし、彼は予算的にプロジェクトをサポートすることをコミットします。なぜなら、彼はそのプロジェクトに取り組んでいる人々を雇用し、信頼しているからです。これは少し分裂したアプローチです。CEOとして、彼は企業内で究極の権限を持つべきですが、彼はこの権限を放棄し、「私は反対だが、予算を持って進めてもいい」と言っています。
このアプローチの理由は、ソフトウェアの取り組みは通常非常に安価であるためです。もし誰かが非常にクレイジーなアイデアを出してきて、それがあまりにも高価ではなく、会社を破産させないのであれば、試してみるのはなぜでしょうか？もし成功すれば、それは素晴らしいアイデアになるかもしれません。これは、従来のサプライチェーン企業からの移行時に文化的なショックを与えます。そこでは、経営陣がビジョンを持ち、チームをリードすることが求められます。ソフトウェアの領域では、リーダーシップは主にソフトウェアエンジニアの間で発生する問題を解決することに関わります。
Lokadでは、ソフトウェアへの投資において、ドルの収益よりも供給チェーン管理の基本的な側面に対処するかどうかが主な関心事です。もし広範な供給チェーンの状況に核心的な要素であるならば、それは追求する価値があります。
例えば、自動車のアフターマーケットでは、機械的な互換性の問題に取り組むことが最も重要です。あなたは人々に車の部品を販売するのではなく、車に部品を提供するために部品を販売しています。一つの部品は複数の車と互換性があり、一部の部品は機械的に重なる場合があります。この問題は取り組まなければならず、ビジネスの核心です。もし取り組まなければ、他の誰かが取り組み、最終的に市場から追い出されるでしょう。
ソフトウェアへの投資に関しては、会社の財務の安定性を脅かさない限り、リスクを取り、イノベーションを受け入れることが重要です。
質問: 大規模なプロジェクトチームがばかげていると言うのは誤解を招くものです。ERPシステムでは、10人のチームは開発に適しているかもしれませんが、より大規模なプロジェクトにはより多くの人員が必要です。タワーを建てるには家よりも多くの人員が必要です。コメントを明確にしていただけますか？
多くの人々の生計は、非常に大規模なIT企業に依存しています。2020年のアメリカでは、IT企業は300万人のアメリカ人従業員を代表していました。ですので、私が「そんなに多くの人員を必要とするERPは理由が全くない」と言うと、明らかに、大規模なチームを売ることやそのようなチームの一員で生計を立てている人々は私と断固として反対するでしょう。
私の反論は、あなたの反対意見が、仕事を少ない人数で行うことができないという科学的な理由から来ているのか、それともあなた自身の金銭的な利益からくるものであり、現状を維持し、多くの人々を雇うことを望んでいるのか、ということです。私たちが行われたすべてのイノベーションを見てみると、経済学者シュンペーターが述べた創造的破壊の中で、重要な経済的イノベーションが行われるたびに、通常は大規模な生産性の向上がありました。しかし、遅れている人々はこれらのイノベーションが起こるのを阻止するために激しく戦いました。
ERPsは新しいものではありません。実際、約40年前から存在しています。最近のほとんどのERPは、1〜2十年前のものと比べてあまり価値を追加していません。私は十分な数の古いERPを見てきましたが、新しいERPはしばしば大幅に改善されていません。特にERP移行プロジェクトに数百万ドルが投入されることを考えると、IT企業からはひどい生産性しか見られません。
私の反論は、JD.com、Amazon、または楽天などの企業を見てみることです。これらの企業は同様のタスクを達成するためにどれくらいの人数が必要ですか？通常、狂気じみた比率になります。例えば、ベルリンを拠点とする大規模なヨーロッパの電子商取引企業であるZalandoは、自社のERPを、ERPを移行する必要のある同じ規模の企業のほとんどのチームよりも小さなチームで構築しました。したがって、一方では、Zalandoのような企業は、自社のニーズに完全に合わせたERPをエンジニアリングすることができます。それは彼らにとって適切なERPであり、関与する人数とコストは同じ規模の他の企業が単にバージョンアップを行うために必要とするものの一部です。コストは再び一部です。私は、そんなに多くの人々が関与する必要があるのか疑問に思っています。これが21世紀の白カラー労働の問題です。非常に優れた従業員であるためには、自分自身を自動化し、自分自身を使い物にしなければなりません。
これは非常に特異なことです。ブルーカラー労働者が使い物にされなくなったのは、他の人々によって行われました。しかし今日では、ほとんどブルーカラー労働者はいません。それは異なる考え方が必要であり、それがソフトウェア業界から主に来ているため、この新しいパラダイムに適応するのは困難です。自分自身を使い物にすることは問題ありません。なぜなら、実際には自分自身を使い物にしていないからです。人間の創造力には限りがありません。あなたは単にいくつかのタスクを自動化し、次のより興味深い課題に取り組むために自由になります。Amazonのような企業は、問題を解決しただけでソフトウェアエンジニアを解雇しません。むしろ報酬を与え、次のより難しい問題に取り組むよう昇進させます。
第二次世界大戦後の分析的思考に固執しているというサプライチェーンの実践者に関する質問に対して、私は多くの企業についてはそうではないが、ソフトウェアエンジニアリングは進化していると同意します。それは人々のプロセス、または解釈的なプロセスとして定義されます。私は同意します。ソフトウェア業界は単なるハードなコア技術に関するものではありません。一部のポジションは信じられないほどの定量的な技術スキルを必要としますが、ソフトウェア業界の大部分は人間志向のアプローチ、共有の文化を持っていると認識されています。
大いに言えることは、米国とシリコンバレーが世界中のソフトウェアに対して持つ支配力は、彼らの文化を複製することの難しさに起因していると私は信じています。文化は非常に抽象的で文書化するのが難しいものです。文化を文書化し、整理し、プロセス化すると、イノベーションに必要な混沌とした要素を抑えてしまいます。文化を文書化すると、アイデアとイノベーションが生まれるときの生の混沌さが失われます。
シリコンバレーのような場所では、この文化が広まっており、この点で時代に先駆けています。このトピックについて結論を出すために、ウィリアム・ギブソンの言葉を引用したいと思います。「未来はすでにここにある。ただし、均等に分布していないだけだ」と。私はこの文化が今でははるかに小規模なスケールで他の多くの場所で複製され、そのプロセスが継続し、時間とともに成長すると考えています。
今日はこれで終わりです。次回は非常に重要なトピックであり、かなり鬱陶しいかもしれませんが、サイバーセキュリティについて議論します。次回お会いしましょう！
