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 サプライチェーンのためのソフトウェア工学 - 質問?
説明
複雑性と混沌を制御することは、ソフトウェア工学の礎石です。サプライチェーンが複雑かつ混沌としていることを考えると、サプライチェーンが直面する enterprise software の問題の大半が悪いソフトウェア工学に起因するというのも、さほど驚くべきことではありません。Numerical recipes を用いて optimize supply chains する手法もソフトウェアであるため、全く同じ問題に直面します。これらの問題は、数値解析手法自体の洗練度とともに激しさを増していきます。適切なソフトウェア工学は、病院における無菌操作が果たす役割と同様に、単独では何も成し遂げず（例えば、患者の治療のように）、それがなければすべてが崩壊してしまいます。
完全な書き起こし
このサプライチェーン講座シリーズへようこそ。私はジョアネス・ヴェルモレルです。本日は “サプライチェーンのためのソフトウェア工学” をご紹介します。ソフトウェアは現代の 供給チェーン管理定義 の基盤ですが、多くのサプライチェーンの教科書では、サプライチェーンにおけるソフトウェアの役割が大幅に軽視されています。サプライチェーン向けのソフトウェアは、単なる交通手段へのアクセスのような要件ではなく、それ以上のものです。サプライチェーンの実務者の視点からすれば、その作業の大半はソフトウェアによって推進され、ソフトウェアのバグや制約、さらにはソフトウェアに伴う懸念が影響しています。
ソフトウェア工学とは、人々がより良いソフトウェアを生み出し、ソフトウェアからより多くを引き出し、より迅速にそのソフトウェアを構築し、より少ないコストで多くを達成することを目指す学問です。この講義の目的は、ソフトウェア工学が何であるか、そしてサプライチェーンにとってどれほど重要であるかを理解することにあります。また、サプライチェーンの実務者として、思わしくない行動や無策によってあなたのソフトウェアプロジェクトが致命的な打撃を受けることを避けるために何ができるかを理解することも目的としています。
20世紀は労働力の機械化の世紀でした。私たちが知る大企業や大規模なサプライチェーンも20世紀に出現し、労働力の機械化がもたらした進歩は驚異的でした。前世紀において、生産や流通などのサプライチェーンにおけるほぼすべての労働集約的な作業で、生産性は100倍に向上しました。
逆に、21世紀は知的作業の機械化の世紀であると私は考えており、その転換は非常に捉えがたいものです。物理的な労働力の機械化から得られる直感は、知的作業の機械化に転用できるものではありません。転換が劇的でないというわけではありませんが、実際、非常に労働集約的な作業を担っていた労働力の淘汰という転換は、すでに過去のものとなっています。
2020年のフランスでは、ホワイトカラー、すなわちオフィス勤務の人が2700万人いたのに対し、工場労働者は100万人にも満たない状況でした。比率は27対1です。知的作業の機械化がもたらすものを考えると、それは非常に驚くべきものであり、モラベックのパラドックスとして知られる逆説とも深く関連しています。
コンピュータ科学者のハンス・モラベックは1980年、計算に関して、人間にとって最も困難に見える課題、例えばチェスのグランドマスターになることなどは、実はコンピュータにとって最も容易に取り組める課題であると述べました。逆に、両足で直立するなど、人間にとって非常に容易に思える作業は、コンピュータにとっては極めて難解であることが明らかになっています。これがモラベックのパラドックスの本質であり、コンピュータを用いた知的作業に関する我々の直感は非常に誤解を招くものなのです。
さらに問題を複雑にしているのは、ホワイトカラーの自動化が、突如としてホワイトカラー自身によって行われる点です。これはブルーカラーの工場労働者の場合とは異なり、彼らが工場のさらなる機械化や自分たちの職の削減を決定したわけではありません。しかし、ホワイトカラーの職においてはまさにそのような現象が起きています。つまり、モラベックのパラドックスによって機械化プロセス自体が極めて直感に反するだけでなく、その機械化の実行を担うソフトウェアエンジニアの管理もまた非常に直感に反しているという課題に直面しているのです。これがおそらく、サプライチェーンにとっての最大の挑戦のひとつ、すなわちこの機械化に対処する責任を担う人々の管理の問題です。
ここで言わざるを得ないのは、多くのサプライチェーンや関連企業が、いまだに20世紀的な考え方に固執しているということです。彼らは企業の世界においてホワイトカラーが知的作業を担い、その後ブルーカラーが実行するというアプローチを取っています。しかし、フランスにおけるオフィス職と工場職の比率が27対1であり、先進国の多くでも同様の統計が見られる現代では、もはやその方法は通用しません。文字通り、自身の作業を自動化することが求められており、21世紀のこの世界では、真に優れたホワイトカラーこそが、常に自らを自動化し、時には自らを陳腐化させ、次のステップへと進んでいくのです。これは、依然として20世紀的な考え方に根ざす多くの企業にとって、非常に大きな挑戦となっています。
ソフトウェア工学という概念については意見が大きく分かれています。コンピュータ科学の創始者の一人であるエドガー・ダイクストラは、ソフトウェア工学が学問や研究分野として成立し得ないとし、「できないならどうやってプログラムするか」といったレシピに過ぎないと述べました。ダイクストラのこの批判は非常に興味深いもので、ソフトウェア工学が如何に自己啓発的なフィクションに退化してしまうかを示しています。実際、有用で優れたソフトウェアを創り出す成功をソフトウェア工学の目標とするならば、その成功は極めて難しく、科学で成功するのと同様に、ひとたび成功を収めれば、その成功を実現するための機会自体が消費され、再現不可能になってしまうのです。
しかし、私はソフトウェア工学が破滅しているという見解には同意しません。ソフトウェア工学の本質的な問題は、その野心をどのように定義するかにあると考えています。もしソフトウェア工学の野望をソフトウェア創出の成功と定めるならば、確かに破滅は避けられません。しかし、もしソフトウェア工学を実験心理学の狭い一分野として捉えるならば、この視点から非常に価値があり実践可能な洞察が得られると信じています。すなわち、ソフトウェア工学とはソフトウェアエンジニア自身とその相互作用に関するものであり、エンジニアに注目することは、人間の本質が時間を通じて安定しているのに対し、ソフトウェア技術は常に変化するため、非常に有効なアプローチなのです。
科学など他の分野を見ると、実務者が実際に何をしているのかを観察する視点からアプローチすることは非常に有益であることが分かります。例えば、科学では利益相反が悪い科学や知識の腐敗をもたらすことが広く認められています。この点は以前「Adversarial Market Research for Enterprise Software」という講義でも取り上げられました。この視点から、実務者自身に注目すれば、広範な適用性と意義のある洞察を得ることが可能であることが分かります。つまり、ソフトウェア工学とは技術そのものよりも、ソフトウェア技術に取り組む人々、その苦闘とプロセスに関するものであるのです。
本日は4章のうちの第6講義です。この章はサプライチェーンの補助科学に捧げられています。これらの補助科学は、現代のサプライチェーン実践にとって基盤的に重要な要素であると考えていますが、厳密にはサプライチェーンそのものの要素ではなく、サポート的な役割を果たすものです。
これまでこの第4章では、まず現代コンピュータを扱うコンピューティングの物理学から始まり、抽象度の梯子を上ってきました。コンピュータから、ソフトウェアにおける最も微細な興味の対象であるアルゴリズムへと進み、次にサプライチェーンやその他多くの関連ソフトウェアプロジェクトにおいて注目される machine learning に代表される数理最適化へと展開しました。数理最適化はサプライチェーンにとって直接的に興味深いものであると同時に、機械学習自体もサプライチェーンにとって重要であることが分かります。
数理最適化と機械学習に関して言えば、今日注目されるほとんどの概念やパラダイムはプログラム的な性質を帯びています。それは単なる単純なアルゴリズムではなく、非常に表現力豊かで、プログラミング言語という視点から取り扱う必要があるのです。だからこそ、前回の講義は言語とコンパイラについてでした。
本日は、引き続きこの抽象の階梯を上りながら、実際に彼らが何をしているかではなく、人々に焦点を当てます。つまり、ソフトウェアエンジニア自身に注目するのです。これが本講義におけるソフトウェア工学分析の核心です。
本日は、ソフトウェア工学に関する2つの見解をご紹介します。まず、私がこの分野を支配していると考えるメインストリームの見解を提示します。残念ながら、このメインストリームの見解は、前述のように自己啓発的なアプローチを伴い、現実的な野心を示していないとして批判を受けており、私自身もその点に反対する理由があります。それにもかかわらず、一部の誤った洞察が依然として非常に人気であるため、これらを概観することは極めて重要です。そうすることで、無能な人物を排除し、彼らの無能さによってサプライチェーンが危険にさらされるのを防ぐ一助となります。
次に、企業向けサプライチェーンソフトウェア分野で事業を展開するソフトウェア企業のCEOとしての私自身の経験に根ざした、現場の見解に移ります。ご覧の通り、その洞察は技術そのものではなく、むしろ人々に関するものです。
ソフトウェア工学のメインストリームの見解では、ソフトウェアプロジェクトは対象ソフトウェアの要求事項の収集から始まるとされています。大企業の多くのプロジェクトは、通常、提案依頼書（RFP）、見積依頼書（RFQ）、または情報要求書（RFI）から始まるプロセスを採用しています。このアプローチは、20世紀の機械工学や建設分野で成功を収めた慣行に由来します。しかし、ソフトウェアに関しては、要求事項の収集手法が根本的に誤っていると私は考えています。
ソフトウェアでは、自分が何を望んでいるのか分からないのです；何を望むかを把握することは常に最も困難な部分です。例えば、在庫 replenishment のような単純な問題を考えると、その問題定義は非常に明快です：任意の時点で、各 SKU に対して補充または再発注すべき数量を知りたいのです。問題自体は単純であるにもかかわらず、適切な数量を定義することは非常に複雑で困難になります。一般的に、要求事項を明確にすることは、piece of software 自体を作成するよりもはるかに難しいのです。
現実世界からのフィードバックと自分の直感を対峙させることで、初めて要求が徐々に明らかになっていくのです。要求は空から降ってくるものではなく、かなり実験的なプロセスを通じて得られるものであり、現実世界との相互作用が不可欠です。しかし、その相互作用を持つ唯一の方法はソフトウェア製品を存在させることであり、要求の収集は本質的に非常に経験的かつ浮動的なプロセスだからです。問題は、要求の作業が完了した時点で、要求を持つこと自体が無意味になってしまう点にあります。なぜなら、要求が存在するということは、その要求を実装する対応する製品がすでに存在することを意味するからです。したがって、適切な要求にアクセスできる頃には、すでに製品は生産され、稼働しており、その要求が存在するという事実は、いささか無意味になってしまうのです。
つまり、プロセスを要求の視点から開始するというのは、私の考えではまさに狂気そのものであり、要求は後工程の文書化、すなわち製品をそのように実装するに至った核心的な理由を文書化するために最後に出てくるべきだと考えます。
要求が定まった後、古典的なアプローチでは設計フェーズに進むべきだと言われています。確かにある時点では何らかの設計が行われるかもしれません。しかし、その設計フェーズでの思考はしばしば誤った方向に陥っています。問題の核心は、変更コストをどれだけ抑制できるかにあります。非ソフトウェアの観点では、変更コストは時間の経過とともに指数関数的に増大すると考えられています。例えば、車の設計を設計図の段階ですぐに変更すれば、変更コストは最小限に抑えられます。それに対し、何百万台もの車が走行中の状態で変更を加えると、リコールを伴い、そのコストは非常に高額になるのです。
しかし、物理的領域とは異なり、ソフトウェアの世界では変更コストが自然に指数関数的に増加するわけではありません。コストの増大を完全に防ぐことはできないものの、かなりの程度で管理することは可能です。実際、変更コストは時間とともに増加しますが、それは主にコードベースが成長するためです。エンタープライズソフトウェアのコードベースが年を追うごとに大幅に縮小するのは見たことがなく、むしろ増え続けるものです。それでも、変更コストをある程度管理することはできるのです。
今日では、この点はソフトウェア業界でも広く認識されるようになっています。ちなみに、これこそがアジャイル手法の本質です。『ああ、我々はアジャイルなソフトウェア開発手法を採用している』という話を耳にしたことがあるでしょう。アジャイル手法の大きな目的の一つは、変更コストを制御下に置くことにあります。今日、アジャイル手法の詳細には踏み込まないにしても、変更コストを具体的にどう抑えるかという点で、このアプローチはやや誤った方向に進んでいると私は考えています。
私が観察したところ、変更コストの大部分はソフトウェアに関する意思決定から生じており、特に決断を下す衝動を抑えることが非常に難しいという点にあります。将来のソフトウェア製品を見据えると、多くの決断を下さなければなりません。初期の試みは、目の前にあるものを明確にするために、すべての決断を下そうとすることです。これに対し、本当に優れた設計フェーズとは、現時点で必ずしも必要でない決断を全て先延ばしにする能力であり、具体的な設計や技術的アプローチを今採用する必要がない場合、それらは未決定のまま空中に浮いており、いつでも変更可能な状態に保たれるのです。
変更コストを制御するための一つの側面は、実際に可能な限りすべての決定を延期する方法を習得することにあります。サプライチェーンの視点から見ると、これはソフトウェアチームの全員や製品およびそのチームを観察しているすべての人々に対し、あたかも情報を隠されているように映るため、非常に奇妙に見えるでしょう。それどころか、意図的に情報を秘匿しているため、なおさら理解し難くなります。しかし、これこそが必要な措置であり、意図的に行われなければならないのです。だからこそ、少なくとも不安を覚えるものなのです。
さて、もし早すぎる設計の決定が、時に誤ったコントロール欲から生じるのであれば、そのコントロール欲に伴う問題はそこで終わるわけではありません。設計フェーズが終わった後、主流のソフトウェア工学の見解では、ソフトウェアの構築、すなわち実装フェーズに進むべきだとされています。一般的な方法は、ウォーターフォール型のスケジュール、すなわちガントチャートを提示することであり、画面に表示されているのがその例です。私は、このガントチャートやウォーターフォールのアプローチは極めて有害であり、その有害性をソフトウェアに関して軽く見てはならないと考えます。このような方法で問題に取り組むことは、少なくともソフトウェアに関するサプライチェーンを致命的な失敗に導くことを意味するのです。
問題を理解し、ソフトウェアの構築にアプローチするはるかに良い方法は、それを学習プロセスと捉えることです。ソフトウェアの構築は、良い製品を得るために必要な全ての学びを獲得する過程なのです。この学習プロセスの中で得られる知見は、構築プロセスから生み出されるソフトウェアに世界が関与することの副産物なのです。ウォーターフォール型の予測の根本的な問題は、これから発見しようとしているものをあらかじめ投影しようとする点にあります。定義上、これは不可能です。これから発見するものは、それが発見されるまで未知のままであり、予測することはできません。ある程度の予感は持てるかもしれませんが、詳細な計画を立てることはできないのです。あいまいな直感を正確なウォーターフォール予測に変換できるという発想は、再び言いますが、完全な狂気です。
ちなみに、ソフトウェア構築を学習プロセスと捉えるという、一見矛盾しているように見えるこの点は、なぜソフトウェアの複製が非常に簡単な場合もあれば、極めて困難な場合もあるのかを説明しています。もしチームが市場に出回っているソフトウェア製品を複製しようと試み、そのチームが製品製作に至った理解や教訓にアクセスできるならば、通常、そのソフトウェア製品の再実装や再コーディングは、最初に製品を作るために必要だった時間と予算のごく一部で済むでしょう。逆に、チームがそのような高次の洞察にアクセスできず、例えばソースコードしか手元にない場合、そのチームは本質的な学習要素や知識の断片を失い、結果的に非常に低品質な製品に終わることが多くなります。結局、製品の外観だけを複製したに過ぎないのです。
サプライチェーンの視点からすれば、ここでの最大の課題は、自らのコントロール欲を進んで放棄し、抑制することです。ウォーターフォールプロセスは、プロセスを厳密にコントロールしようとする企業の表れです。たとえば、「このプロジェクトを管理下に置こう」と言えば、それは非常に合理的なことと受け取られるでしょう。では、なぜ反対のこと、例えば「このプロジェクトを完全に制御不能な状態にしよう」と言うのでしょうか？しかし現実には、ソフトウェアにおいてこの程度のコントロールは完全な幻想であり、最終的に高品質な製品を提供する能力を著しく損なうのです。コントロール欲を抑えることは、サプライチェーンの観点から見れば、ソフトウェア構築における最大の挑戦と言えるでしょう。
コンピュータプログラムが登場して以来、多くのバグや欠陥に悩まされてきました。そうした明白な問題に対処するため、主流の見解ではテストが必須とされています。テストには多くの形態があります。テストの必要性については賛同するものの、現時点では非常に漠然としています。あるツールは構築後にテストすべきだと強調し、またあるものは構築中にテストすべきだと主張し、さらに別のものは構築前にテストすべきだという立場を取ります。あるアプローチでは、ソフトウェアの構築前、中、後すべてでテストが行われるべきだと述べています。
私のこの問題に対する一般的な見解は、フィードバックループをできるだけ短く保つために必要なことは何でもすべきだということです。前回の講義でも議論したように、実際の世界で機能するものを手に入れるためには、フィードバックループを可能な限り短く保つことが極めて重要です。したがって、テストに関して行っていることが、本当にこのフィードバックループを短縮しているのかどうかに注意を払うよう推奨します。例えば、ほとんどの状況では、テストが先行するというテスト駆動開発手法を自然には勧めません。なぜなら、ほとんどの場合、テストを先に行うことで、ソフトウェアに対する世界からのフィードバックを得るまでの時間が延びるだけだからです。
しかし、テストに関する私の最大の懸念は、あまり語られない制約、すなわち一般に軽視されがちな限界にあります。テストは最終的には、自分自身が設定したルールへの準拠性しか評価できないのです。問題は、ソフトウェアには厳格な制約が存在しないという点にあります。解決しようとしている問題に対して、製品の適正さを化学的に評価する方法は存在しません。これは物理的な領域とは大きく異なります。たとえば、機械工学では、部品の寸法公差という標準的な基準があります。機械工学で何を設計しようと、寸法公差は最も重要な要素となり、明白で自然な候補となります。しかし、ソフトウェアにはそのような自然かつ明白な候補は存在しないのです。
ここでの問題は、適切性の問題に帰着します。例えば、サプライチェーンの例としてsafety stocksを考えた場合、安全在庫の計算を検証する自動テストスイートを設計することは全くもって単純です。この種のテストロジックを実装するのは非常に容易ですが、それだけで安全在庫がそもそも悪い考えであるかどうかを示すことはできません。結局、既に知っていることだけをテストしているに過ぎないのです。
物理的な機械を扱う場合、摩耗や劣化が起こるため、機械を稼働状態に保つためのメンテナンスが必須となります。しかし、なぜソフトウェアには稼働を維持するためのメンテナンスが必要なのでしょうか？確かに、コンピュータは経年劣化で故障するため、時折交換する必要はありますが、この側面は非常に僅かなものであり、エンタープライズソフトウェアにおいては、機械の物理的故障が実際のメンテナンスコストの10%にも満たないのです。こうしたメンテナンスは存在しますが、その影響は極めて小さいのです。
それでも、エンタープライズソフトウェアのメンテナンスは極めて重要です。メンテナンスコストは莫大であり、多くのエンタープライズソフトウェアベンダーにとって、メンテナンス費用はエンジニアリングコストの80％以上を占めることもあります。実際、このメンテナンスの必要性を生み出す要因は、物理的な問題とはほとんど関係がありません。第一の要因は、クライアント自身のwillingness to pay、つまり支払意思です。もし、ソフトウェアの初年度に支払われた設定費用に対し、年間メンテナンス料として20％で済むのであれば、ソフトウェアベンダーはそれを請求するのです。要するに、コストの観点からは、メンテナンスコストはエンタープライズクライアントの支払意思によって左右されるのです。
第二の要因は、ソフトウェアを稼働させ続けるために必要なメンテナンスそのものです。実際、日々が経過するごとに、対象製品を取り巻く環境は製品自体から乖離していきます。オペレーティングシステムは進化し、データベースシステムも更新され、ソフトウェアで使用されるすべてのサードパーティライブラリについても同様のことが言えます。どのソフトウェア製品も孤立した存在ではなく、無数の他のソフトウェア製品に依存しており、それら他の製品はそれぞれ独自に進化しています。それらのソフトウェア製品を開発している人々は、製品に取り組みながら変化を加え続けるため、ある時点であなたの製品は互換性の問題から動作しなくなってしまいます。つまり、市場全体の変化に追いつけなかった結果なのです。第二の要因は、ソフトウェアを動作させ、市場全体との互換性を保つために必要なすべてのメンテナンス作業なのです。
第三の要因は、製品を有用な状態に保つために必要な作業量です。実際、ソフトウェアはある時点で設計・構築されましたが、その後、時間の経過とともに世界は当初の設計時の状態から乖離していきます。したがって、ハードウェア上の互換性に問題がなくとも、世界の変化に伴い、製品に組み込まれた期待値との差が広がることで、有用性は次第に低下してしまうのです。有用性を保ちたいのであれば、ソフトウェアを絶えずメンテナンスし続ける必要があります.
サプライチェーンの視点から見ると、メンテナンスは大きな課題であり、前回の講義（サプライチェーンにおける製品志向のデリバリーについて）でもこの点に触れました。メンテナンスコストは、ソフトウェア事業から得られる資本主義的な利益に大きな影響を及ぼします。理想的には、ソフトウェア事業は非常に高い投資利益率を誇るべきですが、そのためには莫大なメンテナンスコストに悩まされないようにしなければなりません。これらのコストが、ソフトウェア投資から得られる資本主義的な利益やリターンを完全に水の泡にしてしまうのです.
ここでの最大の課題は、供給チェーンの観点から見ても、保守コストを最小限に抑える最も簡単な方法が「変わらないもの」に注力することであるという点です。前述したように、ほとんどのコストは、ソフトウェアエコシステムや世の中で変化している事象に関連しています。しかし、変わらないものに集中すれば、結果的にあなたのソフトウェアの大部分は、変わらないものを扱っているため、ゆっくりとしか劣化しないことになるのです。
問題は、変わらないものに注力するのは言うは易く行うは難しいという点です。なぜなら、その意図に対抗する非常に人間的な力―取り残されることへの恐怖―が存在するからです。報道、メディア、同僚などを見ると、常に新奇なものや流行語があふれており、どの流行語も取り残されることへの恐れから、ただ流れに乗らなければならないという衝動を生み出します。例えば、そうした流行語としてはAI、ブロックチェーン、IoTなどが挙げられます。供給チェーンにおいて、これらの流行語は実際に気を散らすものであり、変わらないものから注意を逸らすことで保守問題に大きく寄与していると考えています。逆に、これらの流行語に目を向け始めると、まるで波に乗っているかのようになり、時間とともに変化しやすいものに乗ることになり、その結果、保守コストが徐々に膨らむのです。
ソフトウェアエンジニアリングに関する主流の見解を一通り述べたところで、供給チェーンを念頭に置いたソフトウェアイニシアチブを展開する際に役立つ、私自身の小さな知見をいくつかご紹介しましょう。ソフトウェア関係者と関わる中で最もよく見られる問題の一つは、自身のアイデンティティに対する誤解です。この考えは起業家のポール・グレアムから拝借したものです。例えば、あるエンジニアは「私はPythonエンジニアだ」と言うでしょう。極端な例ではありませんが、ソフトウェアエンジニアが自分のアイデンティティを、自分が習得した短い技術群―すなわちスキルセット―を通して認識することは非常に一般的です。この、自分のアイデンティティと現在のスキルセットの混同は、ITやソフトウェア業界全体で蔓延する採用慣行によって強化されがちです。採用の観点から、多くの企業が求人広告で「Pythonプログラマーが必要」と記載しているため、一方では「私はPythonプログラマーだ」と考える人が存在し、またある企業は実際に「Pythonプログラマーが必要」と求人を出すのです。こうして、適切なアイデンティティを持つことは単なる認識の問題に留まらず、正しいアイデンティティ―正しいラベル、正しいタグ―を自分に付与することで、市場でより魅力的になり、経済的な報酬ももたらされるのです。
しかし、この技術が自分に結びつくというアイデンティティ駆動の認識は、ほぼすべてのソフトウェアプロジェクト、特に供給チェーンのソフトウェアプロジェクトに多くの問題を引き起こします。たとえば、貴社で採用されている技術に強くアイデンティティを結びつけているソフトウェアエンジニアと接すると、その技術へのあらゆる批判が個人的なものとして受け止められてしまいます。もし「私はPythonプログラマーだ」と言いながら、あなたが私のソフトウェアを批判すれば、私はそれを個人的な攻撃と感じてしまいます。問題は、一度技術に対する批判を個人的な批判として受け取ってしまうと、その問題について冷静に議論することが非常に困難になる点にあります。残念ながら、このようなソフトウェアエンジニアは、部分的に個人的批判と捉えるため、全てのフィードバックを回避してしまう傾向があります。
逆に、もし企業が使用している技術が、そのソフトウェアエンジニアが自らの核心的アイデンティティと認識していないものであれば、たとえば貴社のシステムがJavaで実装されているのに、あるエンジニアが「私はPythonプログラマーだ」と言った場合、その問題はその技術が劣っているという視点で捉えられてしまいます。これも、フィードバックが「私の問題ではない；これは単にこの企業で用いられている非常に質の低い技術によるものだ」という態度で回避されるという問題の一例です。どちらの場合も、ソフトウェアエンジニアが使用している技術にアイデンティティを結びつけているか否かにかかわらず、一連の問題を生み出し、フィードバックが技術改善に活かされるのではなく回避されてしまうのです。
供給チェーンの視点から考えると、供給チェーン環境は非常に混沌としており、そのため常に問題が発生することを念頭に置かなければなりません。このような環境の混乱があるからこそ、ソフトウェアエンジニアのチームがこれらの問題に真正面から向き合い、単にフィードバックを回避するのではなく、何らかの対策を講じることが非常に重要なのです。アイデンティティに基づく認識が原因で、供給チェーンの混乱にさらなるドラマを生み出さないようなチームを編成することが極めて大切です。
この考えは、しばしば自分のアイデンティティや得たいと願うアイデンティティに合致する技術を選ぶソフトウェアエンジニアにも当てはまります。彼らは、スキルを獲得し、履歴書に新たなキーワードを加えるために技術を選びます。しかし、このアプローチは、企業が直面する問題を解決するという目的とは無関係な理由で技術が選ばれてしまう結果を招きます。これは、ある技術が組織が抱える具体的な問題に対処する上で、適切かどうかを判断するための誤った視点です。
履歴書作成はソフトウェアエンジニアにとって強力な動機付けとなり得ます。なぜなら、履歴書にキーワードが並んでいることに現実的な経済的利益が伴うからです。しかし、最も優れたソフトウェア企業は、長々とキーワードが羅列された履歴書を低く評価する傾向にあります。私がLokadのCEOとして、半ページに及ぶキーワードの履歴書を見ると、それは即座に却下されてしまいます。しかし、多くの企業―特に凡庸な企業―は、むしろ多くのキーワードを持つ人材を積極的に求め、そうした人物が社内で非常に多才で機敏であると考えています。私の経験では、これはしばしば逆の結果をもたらします。
アイデンティティと履歴書作成の話題を続けるにあたり、ソフトウェアアーキテクトは特定の技術にあまり執着すべきでないという点に注意することが極めて重要です。そもそもソフトウェアエンジニアの採用は難しいため、時には妥協が必要になることもあります。しかし、ソフトウェアアーキテクトに関しては、特定の技術に感情的な執着を持つ人材を選ぶという妥協は、壊滅的な結果を招く可能性があるのです。こうした人材は、企業全体に大きな影響を及ぼすことでしょう。
この履歴書作成におけるバイアスの問題は、ソフトウェアエンジニアやソフトウェア専門家に限ったものではありません。IT担当者の間でも同様の現象が見られます。例えば、大企業のITディレクターで、既存のレガシー ERP が十分に機能しているにもかかわらず、SAPへの移行を望む方々に出会ったことがあります。SAPへの移行に伴う莫大な費用は、より近代的なERPから期待される利益を決して補えません。こうしたケースでは、ITディレクターが自らの履歴書にSAP導入実績を加えるという個人的な利益が、企業全体の利益を凌駕してしまっている非合理的な行動が働いているのです。
供給チェーンの観点から、こうした利益相反に十分注意を払うことは極めて重要です。利益相反を見抜くのに、特別なソフトウェアスキルや能力は必要ありません。他の分野―たとえば医療分野―では、命がかかっている場合でも、利益相反が原因で医師が誤った薬を処方することがあります。これは、利益相反が極めて有害であることを示しています。命が懸かっておらず、主な関心事が金銭である供給チェーン管理において、これらの問題がどのように展開するかを想像してみてください。この文脈では、利益相反が発生することに対して、なおさら躊躇がなくなるのです。
物理的な世界とは異なり、ソフトウェアの領域では、ソフトウェアイニシアチブの進め方や作業へのアプローチにほとんど制約がありません。人間の本性は真空を好まず、構造の欠如に不安を覚えるものです。その結果、これまでに数多くのプラクティスが生まれ、今なお新たなプラクティスが続々と登場しています。各プラクティスには正統性という概念が伴います。例えば、エクストリームプログラミング、ドメイン駆動設計、テスト駆動設計、マイクロサービス、スクラム、アジャイルプログラミングなどがその例です。プラクティスは多数存在し、毎年新しいものが誕生しています。
すべてのプラクティスには正統性という概念が伴います。人々があるプラクティスに従い始めると、自分たちがその核心原則に沿って行動しているかどうかを疑問視するようになるのです。ソフトウェアエンジニアもただの人間であり、人は儀式や部族を愛します。プラクティスは、共通の信念を持つ部族への帰属意識を与えるため、関連するミートアップが開催されるなど、人間の本能的なニーズを満たすのです。
問題に直面して全てが不確かであり、解決すべき問題に共感できる相手がほとんどいない状況を見つめ続けるのは、困難であり時には落胆させられるものです。興味深いことに、プラクティスが疑問視されたり、やや非合理的であったとしても、そのメリットは実際に存在し得るのです。社内外でプラクティスを宣伝することで士気が向上し、有望な応募者の採用につながる場合もあります。
就職面接で、あなたの働き方について尋ねられた際に、「即興でやっており、ルールはない」と答えるのは、決して説得力のあるものではありません。むしろ、あるプラクティスを提示し、それが社内の問題を解決するかのように信頼感を与える方が効果的です。重要なのは、短期的にはたとえほとんどが非合理的であっても、これらのプラクティスが必ずしも悪いものではないという点です。帰属意識を生み出すことは有益ですが、プラクティスがあまりにも真剣に、または長期間にわたって適用されると、有害になってしまいます。プラクティスは、問題を異なる角度から見ることを強制するだけで興味深いものとなり得ます。しかし、一度ある視点から問題を見たなら、すぐに別の視点を探すべきです。一つの角度に固執しすぎてはなりません。供給チェーンの観点から見れば、これはソフトウェア領域の根本的な奇妙さを象徴しているのです。
工場の現場では、卓越性とは常に全く同じことを行うことを意味します。しかし、ソフトウェアの世界では全く逆であり、同じことを繰り返していると、時間の経過とともに停滞と失敗を招く結果になるのです。
ソフトウェアは非常に複雑であり、エンタープライズソフトウェアはなおさらです。しばしば複数のエンジニアが一つのイニシアチブに取り組むことになり、自然と専門化の傾向が生まれます。あるエンジニアがコードベースの特定の部分に取り組むと、新たなタスクで同じ部分に手を加える際、自然にその人物を再び起用したくなるのです。このメリットは明らかであり、その人物は既にコードに精通しているため、生産性が向上します。
専門化の主な問題点は、コードベースの一部分に対して所有感が生じ、さまざまな問題を引き起こす可能性があることです。この所有感に関連する問題には大きく「トラックファクター」と権力ゲームの二種類があります。truckファクターとは、特有の知識やスキルを持つ従業員を失うリスクを指します。これは、その従業員が他社に転職したり、何らかの理由で勤務できなくなった場合に生じます。権力ゲームは、従業員が自分の貢献が企業にとって不可欠であると認識し、その影響力を利用して高い給与やその他の利益を要求する場合に発生します。
私の経験では、ソフトウェアエンジニアは通常、権力ゲームに走る傾向は強くありませんが、こうした問題は大企業になるほど頻発し得ます。この問題に真正面から取り組もうと、ペアプログラミングなど様々なソフトウェアエンジニアリングのプラクティスが存在します。しかし、重要な洞察は、良いものも過剰になれば企業にとって有害になり得るという点です。問題に対処するために、一つのプラクティスに固執するのではなく、こうした問題の存在を認識することが最も大切なのです。なぜなら、そうしたプラクティスは別の問題を生み出したり、注意を逸らしたり、まだ見ぬ他の事柄に目を向ける能力を制限する可能性があるからです。ソフトウェアの視点からすれば、ここでの重要な教訓は、プロセスではなくカルチャーこそがこうした問題に対する解毒剤であるということです。
我々は、コードの特定部分に特化することで得られる生産性向上と、その部分を特定の人が所有することによるリスクとの間で、非常に微妙なトレードオフに直面しています。求められるのは、チーム全体でコードベースに関する知識に常にある程度の冗長性が存在し、すべてのエンジニアが何らかの形で能力において重なりを持つ状況を育むことです。これは、いかなる生産性も維持したいのであれば達成しなければならない非常に微妙なトレードオフです。実世界でそれを実現する唯一の方法は、ソフトウェアエンジニアリングについて十分に共有されたカルチャーの中で行うことです。仲間の仕事に対して好奇心を持つことを保証できるプロセスは存在しません。好奇心に関するプロセスなどありえず、それはカルチャーの一部でなければならないのです。
ソフトウェアエンジニアのスキルや能力を評価するのは難しい問題ですが、ソフトウェアが明らかにチームとしての取り組みであり、チームがその構成員の総和以上のものとなっているにもかかわらず、メンバーそれぞれの基礎的なレベルがチーム全体のパフォーマンスに大きな影響を与えるため、この問題は非常に重要です。
私がソフトウェア業界の外の人々や、場合によっては業界内部の人々に過小評価されていると感じる一面は、ライティングスキルの重要性です。ソフトウェアを作成するということは、二つの全く異なる受け手―一方は機械、すなわちコンパイラー―に対応しているということです。あなたはコードを書き、コンパイラーがそれを受け入れるか拒否するかを判断します。これは容易な部分です。コンパイラーは、あなたのコードが正しいかどうかを教えてくれる疲れを知らない仲間であり、完全に予測可能で、無限の忍耐力を備えているのです。
一方で、あなたの聴衆には同僚が含まれており、その中には6か月後のあなた自身もいるでしょう。あなたはコードを書き、やがてそれを忘れてしまいます。6か月後、あなたは書いたコードを見て、それがまるで誰か他の人によって書かれたかのように感じるでしょう。なぜなら、そのコードはとても馴染みがないからです。同僚のためにコードを書く場合の利点は、コンパイラとは異なり、同僚たちがあなたの狙いを理解しようと努める点にあります。コンパイラはあなたの意図を理解しようとはせず、規則のセットを機械的に適用するだけです.
同僚は理解しようとしますが、残念ながら彼らはコンパイラのようではありません。無限の忍耐力を持っているわけでもなく、あなたのコードに容易に混乱し、誤った方向に導かれてしまうことがあります。だからこそ、たとえば記憶に残り、洞察に満ち、適切な名前を選ぶことが最も重要なのです。良いプログラムとは、単に正しいものであるだけでなく、変数、関数、モジュールの名前を適切に選ぶことも極めて重要です。そうすれば、同僚―そして再び言いますが、6か月後のあなた自身も―ともうまく協働できるコードになります。サプライチェーンの観点からの主要な教訓は、文章能力が極めて重要であるということであり、しばしば生の技術的スキルよりも重要であるという点です。良い文章能力こそが、サプライチェーンに存在する複雑性を制御する上で最も必要なスキルなのです。アプリケーションの全体像の複雑さを制御することは、偉大な技術的課題ではなく、アイデアや要素を整理し、全体で一貫したストーリーを持つことの挑戦なのです。これらはすべて文章能力に大いに関わっており、以前の講義「Writing for Supply Chain」においても触れました.
もしも優れたソフトウェアエンジニアになるために文章能力が最も重要だとすれば、ソフトウェアエンジニアであるために極めて重要なもうひとつのスキルがあります。それは、痛みに耐える力です。私は、ただソフトウェアエンジニアであるために必要な第一のスキルとして、痛みに対する耐性を信じています。より具体的には、ここで言う痛みとは、非常に壊れやすく、設計が悪く、あらゆる面で落とし穴のあるシステムに直面したときに、退屈やフラストレーションに抵抗する力を意味します。そして、それらはしばしば、もはや存在しない人々によってもたらされたものなのです。ソフトウェアに取り組むとき、あなたは40年分の積み重ねられた問題に常に苦しめられるのです。これが時に、非常に苛立たしい作業となり得ます.
例を挙げるなら、ソフトウェアエンジニアとして、エラーコードに似たものが記載されたランダムで半ばゴミのような会話をウェブフォーラムで4時間かけて掘り下げる忍耐力が必要になるでしょう。このような無意味な情報を何時間もかけて調べなければならず、ときにはごく些細なバグを解決するのに数週間を要することもあります。したがって、その結果として、ソフトウェア業界全体において、痛みに対する高い耐性を持つ人々が選ばれるという、非常に厳しい逆選択プロセスが働いているのです。この選択プロセスには2つの主要な結果があります.
第一に、ソフトウェアエンジニアとして活躍し続ける人々は、非常に高い痛みへの耐性を有している傾向があります。ここで言う耐性とは、常に直面するソフトウェアの問題から生じるフラストレーションに対する抵抗力を意味します。痛みに対して驚異的な耐性を持つ人々を選び出す結果、彼らは自分の行動が状況をさらに悪化させていることに気づかないかもしれません。彼らはソフトウェア製品に余計な癖を加え、その結果、自分自身を含むすべての人にとってソフトウェアと関わる際の苦痛レベルを増大させるのです。しかし、もし彼らが極めて痛みに対する耐性を持っていれば、その事実に気づかないのです。この逆選択プロセスは、通常なら気づくはずの普通の人々―痛みに敏感であったはずの人々―を排除し、結果としてソフトウェアエンジニアにならなかった原因となっています。これは特にサプライチェーンのソフトウェアにおいて深刻な問題であり、なぜなら多くの部分が刺激的ではないからです。必要ではあるものの、平凡な要素を含むため、この分野で高い耐痛性を持つ人々が働くと、潜在的な退屈な作業が多く存在し、状況をさらに悪化させる可能性があるのです.
第二に、この逆選択プロセスのもう一つの側面として、激しい痛みを生む問題を避けるために、より低い給与を受け入れる余裕がある人々は、その選択をするということがあります。すでに高給を得ている人々は、必ずしも高給でなくても、痛みがそれほど激しくない仕事を選ぶかもしれません。ほとんどの人はおそらくそうするでしょうし、実際に多くの人がそうしています。つまり、常に高い環境的な痛みが存在するこの業界に残る人々は、高給の機会を逃す余裕がない人たちであることが多いのです。これが、インドや北アフリカから多くのソフトウェアエンジニアが出てくる大きな理由のひとつです。これらの国々はかなり良い教育制度を持ち、よく教育された人材を輩出していますが、国自体は依然として比較的貧しいのです。このような状況にある人々は、基本給に比して高い給与が期待されるソフトウェアエンジニアの職を諦める贅沢がなく、他の選択肢を取る余裕がないため、この業界に非常に多く存在するのです.
これらの国々に問題があるわけではなく、単に市場の力が機械的に働いている結果に過ぎません。これは判断ではなく、ただの観察です。ところで、痛みに対する耐性だけでは、優れたソフトウェアエンジニアになるためには不十分です。それはあくまで一条件に過ぎず、それを欠けばあなたはそもそもソフトウェアエンジニアではないのです。しかし、もし痛みに耐える力だけを持っているなら、かなり下手なソフトウェアエンジニアになってしまうでしょう。サプライチェーンの観点からの教訓は、企業が内部あるいはソフトウェアベンダーを通じて集めるチームに、痛みに耐える力だけが唯一のスキルとなっていないかを十分に注意深く見極めるべきだということです。そうでなければ、ソフトウェアの品質やその付加価値において非常に悪い結果を招くことになるのです。繰り返しますが、痛みに耐える力は必要ですが、それだけでは十分ではありません.
1975年、フレデリック・ブルックスは、マンマンスがソフトウェアによって生み出される価値や、ソフトウェアエンジニア全体が創出する価値の代表ではないと既に指摘していました。ほぼ五十年後、IT企業は世界で最も大きな雇用主の一角を占めています。2020年のアメリカでは、IT業界に300万人の従業員がいる一方で、自動車産業全体では100万人にも満たなかったのです。現在、IT業界は自動車産業の少なくとも3倍の規模となっています。数百人から数千人の従業員を持つ巨大なIT企業の多くは、もはやマンマンスで請求を行っていません。これは1970年代の話です。現在では、請求単位はキロ日、すなわち1000人日に相当します。状況は、フレデリック・ブルックスがほぼ五十年前に指摘した問題と比べ、規模と問題の大きさが著しく増大したため、むしろ悪化していると言えるでしょう。しかし、初期の多くの教訓は依然として有効です。『人月の神話』は、今なおソフトウェア工学に関する非常に興味深い書籍です.
ソフトウェアにおいては、生産性は非常に大きく変動します。低い生産性の人がいるのではなく、むしろ生産性がマイナスな人が存在するのです。つまり、彼らがソフトウェア製品の作業を始めると、単にそれを悪化させてしまうのです。もはや個々の生産性の比率を取ることすらできません。それ以上に悪いことに、実際にあなたの製品そのものを劣化させる人さえ存在するのです。これは大きな問題です。一方で、いわゆる10倍エンジニアと呼ばれる、平均的なエンジニアの10倍の生産性を持つ人々も存在します。これらの10倍エンジニアは実在しますが、その莫大な生産性は非常に文脈依存的です。ある会社から別の会社、あるいは一つのポジションから別のポジションへと10倍のソフトウェアエンジニアを移籍させ、その驚異的な生産性が保たれると期待することはできません。通常、それは独自のスキルと特定の状況が相まって生み出されるものなのです。それにもかかわらず、わずかな人数がソフトウェア製品によって生み出される価値の大部分を担っていることを心に留めておくことは重要です。時には、全体の賢明な要素と真の付加価値の大部分を一人が生み出し、残りはせいぜい疑わしい付加価値に過ぎないという状況に帰着することもあります。ここでの主要な教訓は、五十年前に提示された通り、サプライチェーンにおいて締め切りに追われた場合、唯一合理的な選択肢はソフトウェアへの取り組みの範囲を縮小することであるということです。他の選択肢はすべて、状況をさらに悪化させるのです.
人手を追加すれば状況はさらに悪化します。遅れているソフトウェアプロジェクトに人手を追加すると、なおさら遅れるというのはよく言われることです。これはブルックスが五十年前に述べたもので、今も有効です。他の選択肢もまた効果がありません。もし人々に残業をさせ始めれば、それは裏目に出て人々が疲弊し、バグが増え、製品はさらに遅延してしまいます。品質を下げようとすれば、最終的には動かなくなってしまう製品になってしまうのです。こうした事態は制御不能となり、手に負えなくなるため、品質面での妥協は許されません.
サプライチェーンの観点からの教訓は、もし10人以上のフルタイムのソフトウェアエンジニアが必要とされるような取り組みに着手するのであれば、最大限の注意を払うべきだということです。通常、これは問題の定義が非常に不適切である兆候なのです。10人が同時に1つの製品に取り組んで生産性を保つのは、信じられないほどのチームワークを必要とします。サプライチェーンにおいては、規模や関わる人数について過剰な野心を抱くことがしばしば見受けられます。実際、50人、100人、200人が同時に取り組むERP移行プロジェクトを見たことがあります。これは全くもってナンセンスです。ある程度の協力関係を実現するには、摩擦によってすべてが失われないよう、非常に有能なチームプレイヤーが不可欠なのです。もし苦労しているなら、ソフトウェアへの取り組みは焦点を絞り、短く、狭い範囲に限定すべきです.
私の最後の観察は、大企業に関する頻繁な誤解についてです。多くの人は大企業はリスク回避的だと言いますが、私の経験ではそうではありません。私の経験では、大企業はリスクではなく不確実性を嫌うのです。しかも、遠目から見ると、その両者は混同されがちです。遠くから見ると、大企業はリスクを避けると言われますが、実際には、大企業は確実な失敗と不確実な成功という選択肢に直面したとき、常に不確実な成功よりも失敗の確実性を選ぶのです.
大企業は、何度も何度も、不確実な成功よりも失敗の確実性を選びます。一見すると不可解で非合理的に思えるかもしれませんが、そうではありません。大企業は一つの実体ではなく、多くの人々からなる政治的な存在であり、政治や対外的な見かたが特に極めて重要だからです.
ソフトウェアへの取り組みの責任者の視点を考えてみてください。一方では、結果が確実に失敗する取り組みがあります。しかしあなたは、規則に則り、正しい手続きを踏んでおり、誰もがそれが失敗することを知っています。安全策を講じた上で失敗しても、誰もあなたを責めません。逆に、不確実な成功というのは奇妙に映るのです。この道を選ぶということは、普通でない、ひょっとするとキャリアにとって非常にダメージとなるようなことをすることを意味するのです.
サプライチェーンの観点からの教訓は、ソフトウェアの世界では、単に教科書通りに―そしてその教科書が全くでたらめであっても―自らを失敗に追い込む状況を作り出してはならないということです。たとえば、私はABC analysisや安全在庫といった手法を用いて、何十年も失敗し続けた企業を見たことがあります。これらの手法は基本的な数学的、統計的理由から明らかに誤っており、その結果、関連する取り組みの失敗を保証するものとなっています。しかし、表面的には狂気じみたものに見えず、教科書的なものとされ好まれてきたのです.
不確実性をなくすためだけに自らを失敗に追い込むという安心感に惑わされてはなりません。不確実性をなくすこと自体が目的ではなく、目的は成功の可能性を最大化することであり、不確実性を減らすことではありません.
結論として、ソフトウェア工学はソフトウェアエンジニアだけに任せておくにはあまりにも重要な分野です。ソフトウェアはサプライチェーンのあらゆる場所に存在し、知的労働の機械化を推進しています。プロセスはまだ初期段階にありますが、疑いなく、競争力を極めて維持できなければ、通常の市場の力によって市場から淘汰されることになるでしょう。サプライチェーンにおける最大の課題は、技術的な問題ではなく、文化的な問題なのです。ソフトウェア工学は、私たちが問題をどう捉え、どうアプローチするかという方法そのものに挑戦しているのです。直感的な解決策は、ほとんどの場合、見事に間違っているのです.
ある意味で、サプライチェーンにおけるソフトウェア工学とは、混沌、すなわちサプライチェーンのあらゆる場所に存在する複雑性と不確実性を制御することに他なりません。この混沌を制御するためにソフトウェアエンジニアがその役割を果たすのです。しかし、もしそのプロセス自体があまりにも洗練され秩序立っているならば、本質的な混沌、すなわち変化、偶然、創造性の余地が失われてしまいます。卓越性と見なされるものはすぐに停滞に陥り、その後失敗へと転落してしまうのです。より伝統的な企業にとって、この文化的アプローチから生じる最大の課題は、単に文化的衝撃だけでなく、支配の幻想を手放すことにあるのです。あなたの5年計画のERP移行は幻想に過ぎず、そんな大規模なプロジェクトを完全にコントロールすることはできないのです。同様に、現行の取り組みの期待利益を示すビジネスケースも幻想なのです.
知的労働の機械化に取り組む際の最大の危険は、完全に合理化できない事柄を行うことではなく、合理的な見かけの下で全く非合理的なことを行うことにあるのです.
質問を見てみましょう。次の講義は12月15日水曜日、パリ時間の午後3時に行われ、サイバーセキュリティがテーマです。さて、質問を見てみます。
質問: ソフトウェア投資における資本主義的リターンはどのように測定しますか？
基本的には、そうではありません。測定は取り組みそのものの副産物です。投資収益率を測定しようとすると、それは非常に不可解なものになります。この質問が暗示しているのは、事前に測定方法を考案できるという前提です。すなわち、ビジネスケースを複数のシナリオで構築する前に、あらかじめその測定方法を定め、その上で判断を下し、ソフトウェア投資に踏み切るかどうかを決定できると仮定しているのです。私が言いたいのは、ソフトウェアの場合、そのようには進まないということです。まず実行し、次に学ぶべきことを学び、その過程でどのような利益が得られるかすらも明らかになるのです。行動を導くためには、高次の理解が必要です。教訓は、無作為に物事を行うのではなく、合理性を装った極端に非合理的な行動を避けることにあります。もしあなたが何かに絶対的な確信を持ち、直感が正しい道を示しているなら、その高次の直感は、見せかけの合理性にすぎず、ごみのような数字に基づく派手な計算よりも、はるかに合理的な議論となり得ます。実際、ソフトウェアの取り組みを進めるにつれて、何を達成しようとしているのかが明確になり、実際に行っていることの適切さをどう測るかを学んでいく過程で、測定は次第に明らかになるのです。もしうまくやれば、測定は副産物として現れます。しかし、その結果として、ソフトウェアに関しては、物事を試みて迅速に失敗する方がはるかに良いのです。大規模なコミットメントに自らを縛るのではなく、少人数で高い生産性を発揮しながら、極めて漸進的に進めるのが望ましいのです。進むべき道はその過程で学んでいくものです。
しかし、そこで別の問題が生じます――そのようなアプローチを取り始めると、企業の経営陣は同時に多くの取り組みを調整しなければならなくなるのです。これは特に伝統的な企業にとっては非常に動揺を覚えることで、経営陣はこれほど多くの取り組みが全く異なる方向に進むとは予期していません。しかし、これこそが何十年にもわたり大手ソフトウェア企業で起こってきたことであり、人間の視点から見たソフトウェアエンジニアリングの重要な示唆の一つなのです。
質問: 多くのキーワードを持っている人が、特定の技術と結びつかないというのは矛盾ではありませんか？
さて、多くのキーワードを持っているからといって、特定の技術と自分が結びつくのを防げるというわけではありません。問題は二つあります。一つ目は、個人のアイデンティティ、すなわち自分自身としての認識、そしてそれに伴うスキルセットとの間に強い結び付きがあるという問題です。これが第一の問題です。第二の問題は、履歴書を作成する際に非常に強い潜在的な利益相反が伴うということです。私のメッセージは、一つにはアイデンティティ政治には注意せよということで、これらは非常に有害です。二つ目は、あらゆる形の利益相反にも注意せよ、これもまた非常に有害だということです。
さて、もし特定の技術を強調し過ぎれば、あなたが好まない技術に関するキーワードを履歴書から排除するかもしれません。しかし、通常はこれら二つの問題は別個であり、たとえばスライドで示したように「私のアイデンティティはPythonプログラマーだ」と言いながら、履歴書には20以上のキーワードを記載する人もいます。これらは互いに排他的ではなく、同時に起こり得るのです。また、アイデンティティが時には望むべきもの、つまり獲得したいものと結びつく場合があることも過小評価してはなりません。たとえば、「これまで主にPythonでプログラミングしてきたが、Rustプログラマーになりたい。だから、今後は自分をRustプログラマーとみなす（たとえこれまでは主にPythonであったとしても）」ということがあり得るのです。ありとあらゆる行動様式が可能です。
質問: ソフトウェアエンジニアリングはサプライチェーンの補助科学とみなされるが、ソフトウェアエンジニアリングにとっての補助科学とは何か？
おそらく、心理学、社会学、そしてエスノロジーなどが、ソフトウェアエンジニアリングに関連する分野でしょう。基本的に人々の相互作用として捉えれば、これらの補助科学は非常に重要です。真剣にソフトウェアエンジニアリングに取り組むには、単にソフトウェア技術だけでなく、人々の相互作用が意味をなすよう、ソフトウェアの文脈を理解する必要があります。コードの内容を必ずしも理解する必要はありませんが、コードベースや既存のツール、そしてそれらが解決しようとしている問題といった概念は理解すべきです。しかし、このサプライチェーン講義シリーズの目的のために、何を含み、何を除外するかの線引きをしなければなりません。すべての研究分野を網羅することは明らかに不可能なのです。
質問: 賢い人を10人集めて解決策を問えば、10以上の方法が出てくる。その中から上位5つのうちの1つに合意し、一貫して用いるのが望ましい。これら二つの相反するアプローチと利益のバランスは、どう取るのですか？
これは非常に広範な質問ですが、ソフトウェアエンジニアリングの具体例に当てはめて考えると、多くの提案が可能ですが、すべてが同じ重みで評価されるべきではありません。ソフトウェアの長期的視点を持つというスキルというものがあります。変わらないものに注目すべきだと言うと、得意な人もいれば、そうでない人もいます。誰がこの長期的視点を持つためのスキルを有しているか、また変わらないものとは何かを見極めるには、経験が必要なのです。私の経験では、通常、35歳に達して初めてそのスキルが身につき始め、最も優秀な人は60歳を超えていることが多いです。動きやパターンを見るのには何年もの経験が必要なのです。
多くの人がいると言うとき、一つの錯覚は、すべての解決策が良さそうに見えるということですが、それはあくまで見かけに過ぎません。実際に試行錯誤するのにどれだけの努力が必要かは分かりません。プロトタイプを作ったり試してみたりするだけで済むのでしょうか？その10人の中に、長期的に有害な解決策を見抜く独自のスキルを持つ人はいるのでしょうか？覚えておいてほしいのは、あなたの保守コストは基本的にあなた自身が下した決定によって左右されるということです。長期的に見て、あなたに損害を与えるような重要な決定は存在するのでしょうか？
これは非常に厄介な点です。そして、長期的視点を持つ人は、なぜある選択肢が長期的にはあらゆる問題を引き起こすのかを説明できるのです。それは単なる勘や直感ではありません。彼らは「こんなことは以前もあった。別の製品でも見たことがある」と言うでしょう。『賢い人は自分の過ちから学び、賢者は他人の過ちから学ぶ』という諺があるように、これは今回の事例にも非常に当てはまります。
質問: サプライチェーン向けソフトウェア導入に際して、投資1ドルあたりの運用効率の向上を、企業はどのように測定するのでしょうか？
これは非常に困難な質問です。問題は文字通りパラダイムの計り知れなさにあります。認識論に起因するもので、ある運用方法から全く異なる方法へ移行するとき、そのパラダイムが根本的に異なるため、大半の指標は無意味になってしまうのです。例えば、テレセールスと電子商取引を比べてみましょう。通信販売会社は19世紀半ばから存在していました。もし電子商取引を通信販売会社に対する改良と見なそうとすると、その改善を測定しようとするかもしれませんが、実際にはほぼすべての通信販売会社が破産してしまいました。現在支配的な電子商取引企業は、かつて最大だった通信販売会社の何桁も上回る規模で、比較は非常に曖昧です。
知的作業の機械化は非常に厄介で不可解です。なぜなら、物理的な領域とは異なるからです。物理的な生産では、正統な方法で効率を測ることができます。しかし、知的作業を機械化し始めると、効率とは一体何を意味するのでしょうか？たとえば、Amazonのような企業では、サプライチェーン全体が完全にソフトウェアによって駆動されています。もしすべてのエンジニアが1、2日何もしなかったとしても、全体のサプライチェーンは問題なく稼働すると私は疑っています。では、なぜAmazonはそれらのエンジニアを維持しているのでしょうか？それは、彼らが改善に投資しているからです。
ちなみに、ジェフ・ベゾスの興味深い点の一つは、「disagree but commit（異議はあるが従う）」という彼の経営プロセスです。彼は、CEOとしての直感でそのプロジェクトが間違っていると感じ、反対する場合があると言います。しかし、採用した人々を信頼しているため、そのプロジェクトに関しては予算面での支援を約束するのです。これは一種の統合失調的なアプローチのようなもので、CEOとして会社の最終的な権威であるべき立場ながら、その権威を放棄し、「反対はするが、予算は使って進めて良い」と言うのです。
このアプローチの理由は、ソフトウェア関連の取り組みは通常、かなり低コストであるためです。もし、あまり高くなく、企業を破産させるような危険もない一見突飛なアイディアが出たなら、なぜ試さないのでしょうか？うまくいけば、それは素晴らしいアイディアになる可能性があるのです。これは、経営陣がビジョンを持ってチームを牽引すべき伝統的なサプライチェーン企業から、転換する際のカルチャーショックをもたらします。ソフトウェアの領域では、リーダーシップとは主にソフトウェアエンジニア間で生じる問題を整理することに関するものです。
Lokadでは、ソフトウェアに投資する際の主な関心事はドルによるリターンではありません。むしろ、その投資がサプライチェーン管理の基盤的側面に対処しているかどうかに焦点を当てています。もしそれが幅広いサプライチェーンの状況にとって核心的であれば、追求する価値があるのです。
例えば、自動車アフターマーケットでは、機械的互換性の問題に取り組むことが最も重要です。あなたは人々に部品を販売しているのではなく、車に部品を販売しているのです。1つの部品が複数の車両に適合することがあり、また、いくつかの部品には機械的な重複があります。この問題は必ず対処しなければならず、ビジネスの核心に関わるのです。対処しなければ、誰かが必ず対処することになり、最終的には市場から締め出されるでしょう。
ソフトウェア投資に関しては、企業の財務の安定性を脅かさない限り、リスクを取り革新を受け入れることが重要です。
質問: 大規模なプロジェクトチームは馬鹿げていると言うのは誤解を招きます。ERPシステムでは、10人のチームが開発には適しているかもしれませんが、より大きなプロジェクトにはより多くの人手が必要です。塔を建てるには家を建てるよりも多くの人が必要です。あなたのコメントを明確にしていただけますか？
多くの人々を敵に回すかもしれない立場を取ろうと思います。何百万人もの生計は、非常に大きなIT企業に依存しています。2020年の米国では、IT企業は300万人のアメリカ人従業員を抱えていました。したがって、非常に多くの人手を必要とするERPを正当化できる理由は全くない、と言えば、大規模なチームを販売するか、その一員として生計を立てているすべての人々は激しく反対するでしょう。
私の反論はこうです。あなたの反対意見は、なぜより少ない人数で仕事ができないのかという核心的な科学的理由に基づくものですか？それとも、現状を維持し大量の人々に仕事をさせることが、あなた個人の経済的利益になっているからでしょうか？経済学者シュンペーターが述べた創造的破壊をはじめとするすべてのイノベーションを見れば、重要な経済イノベーションがあるたびに、通常は大規模な生産性向上が伴っているのです。しかし、時代に取り残された者たちは、これらのイノベーションが実現するのを激しく阻止してきました。
ERPは新しいものではなく、実質的に約40年前から存在しています。現代で見かけるほとんどのERPは、1、2十年前のものと比べてあまり付加価値を提供していません。十分に機能していた古いERPを多く見てきましたし、新しいERPも、特にERP移行プロジェクトに投入された何百万もの費用を考慮すると、大幅に優れているわけではありません。こうした大規模プロジェクトでは、IT企業の生産性は惨憺たるものです。
私の反論は、JD.com、Amazon、あるいは楽天のような企業を見てほしいということです。これらの企業は同様の業務を達成するために、いったい何人の人手が必要なのでしょうか？通常、信じられないほどの比率になってしまいます。例えば、ドイツ・ベルリンを拠点とする大手ヨーロッパ電子商取引企業Zalandoは、自社専用のERPを構築しましたが、そのチームは、ERP移行が必要な同規模企業で私が見たほとんどのチームよりも小規模でした。つまり、一方では、自社のニーズに完全に合わせたERPを自力で構築できる企業があり、そのERPは彼らにとって非常に適切に機能しているのです。そして、そのコストや関与する人数は、同規模の他社が単なるバージョンアップだけで必要とするもののほんの一部に過ぎません。コストもまた、わずかな割合に過ぎません。これほど多くの人が関与する必要があるのかという点に疑問を呈するものであり、これが21世紀におけるホワイトカラー労働の問題なのです。優秀な従業員であり続けるためには、自らを自動化し、陳腐化させる勇気が必要なのです。
これは非常に特異な現象です。ブルーカラー労働者が陳腐化させられたとき、それは他者によって実現されました。しかし、今日ではブルーカラー労働者はほとんど存在しません。これは異なる考え方を要求し、この新しいパラダイムに適応するための闘いが、主にソフトウェア業界から生じている理由でもあります。自らを陳腐化させるというのは問題ではありません。実際には、自分を陳腐化させるのではなく、人間の創意工夫には限界がないのです。単にいくつかの作業を自動化して、次の、以前よりもさらに興味深い挑戦に取り組む余裕を生み出しているだけなのです。Amazonのような企業は、ソフトウェアエンジニアが1つの問題を解決した途端に解雇することはありません。彼らは報奨を与え、次のより難しい問題に取り組ませるために昇進させるのです。
第二次世界大戦後の分析的思考に固執しているサプライチェーンの実務者についての質問に答えると、多くの企業において、ソフトウェアエンジニアリングは進化しているという点に私も同意します（もちろん、すべての企業がそうというわけではありません）。ソフトウェアエンジニアリングは、自らを「人を中心としたプロセス」、あるいは「解釈的プロセス」として定義しています。私もその意見に同意します。ソフトウェア産業は、単に堅固なコアテクノロジーだけのものではありません。確かに一部の職種は驚異的な定量的技術スキルを要求しますが、ソフトウェア産業の大部分は、人間中心のアプローチや共通の文化を有していると認識しているのです。
大部分において、私は、米国とシリコンバレーが世界中のソフトウェア市場を支配しているのは、その文化を再現することがいかに難しいかによると考えています。文化は非常に捉えどころがなく、記録するのも困難です。文化を記録すると、イノベーションに必要な混沌とした要素が抑えられてしまいます。文化を記録し、整理し、プロセス化してしまうと、突如として生の混沌としたアイデアや革新の出現という側面が失われてしまいます。
シリコンバレーのように、この文化が根付いている場所は、常に時代の先を行っています。この話題を締めくくるにあたり、ウィリアム・ギブソンの「The future is already here; it’s just not evenly distributed.」という言葉を引用したいと思います。私は、この文化が現在、他の多くの場所で小規模ながら再現されているのを目の当たりにしており、そのプロセスは時間とともに継続し、成長していくと見ています。
本日はこれで終わりです。また次回お会いしましょう。次のセッションでは、かなり憂鬱に感じられるかもしれませんが、とても重要なテーマであるサイバーセキュリティについて議論します。それでは、また次回！
