- ソフトウェア特有と見なされがちな 要件変更と不確実性、反復作業やその場しのぎは伝統的な工学でもよくあり、両者には違いより共通点のほうが多い
- 伝統的な工学は Waterfall、ソフトウェアは Agile という区分は単純化しすぎている。物理的な製作は反復コストが高いため事前設計が多いが、トンネル・土木・電子分野でも 漸進的開発と現場適応 が用いられている
- 仕入先の廃業、製造設備の変化、予想外の土壌特性のように、伝統的な工学も計画を覆す問題に直面するため、ソフトウェアだけが特別に 予測不可能 だとは言いにくい
- 実際の違いは、ソフトウェアの 高い一貫性と高速な変更、そして比較的柔軟な制約にある。物理製品は材料ばらつきや摩耗、強度・サイズといったハードな制約、後戻りしにくい変更を受け入れなければならない
- 素早い修正は実験と検証を容易にする一方で、物理的欠陥を コードで回避 するよう圧力を生むこともある。各工学分野は互いの設計・検証・自動化の方法から学べる
ソフトウェアが特別だとする防御論
- 石油貯留層は油で満たされた風船ではなく 多孔質の岩石構造 なので、突然の圧力低下が局所的な空洞によるものなのか、海へ抜けたのかを判断しにくい
- 小さな空洞にはヘーゼルナッツの殻を注入して徐々に埋め、圧力を平衡化しつつ構造内にあるかを試験する
- ノルウェーで石油会社がヘーゼルナッツの殻の最大の買い手だという話は、伝統的な工学も予想外の材料と現場対応に依存していることを示している
- ソフトウェアと伝統的な工学を比較するとき、免許や厳密さの違いによってソフトウェアを工学より低く評価する一方、ソフトウェアを一般的な工学の枠組みでは理解できない 特別な分野 にしてしまうこともある
- 要件があまりにも速く変化するので、事前計画や工学的手法を適用しなくてもよいという理屈は、防御機制として機能する
- NoEstimates 運動 は、伝統的な工学と違ってソフトウェアの見積もりは難しいとして、見積もりそのものをなくそうとする
- しかし、ソフトウェアで苦痛だと感じられている問題の大半は他の工学分野にも存在し、両方を経験したエンジニアは両者の仕事の本質は近いと見ている
よく挙げられる5つの違い
- 伝統的な工学全体を1つの領域のように扱ったり、土木工学と同一視 したりすると、各サブ分野の違いが消えてしまう
- ソフトウェアと伝統的な工学の普遍的な違いとしてよく挙げられる項目は次のとおり
- 伝統的な工学は Waterfall、ソフトウェアは Agile に適している
- 伝統的な工学は予測可能だが、ソフトウェアは予測しにくい
- 工学は主に製造であり、コードは設計なので「コードこそ設計」である
- 伝統的な工学はソフトウェア工学より厳密である
- ソフトウェアは伝統的な工学よりはるかに速く動く
- 一部には実際の違いもあるが、大半は誤っているか、判断に必要な 重要な文脈が欠けている
Waterfall と Agile という単純な区分
- 広く知られた物語によれば、Winston Royce が 1970 年に建築工程を手本に Waterfall を作り、要件変更に弱いこの方式は 2001 年の Agile Manifesto に置き換えられた
- 実際の Waterfall は、今日認識されているほど厳格でも普遍的でもなかった
- 1970〜1980 年代の開発者は、場当たり的な計画や Spiral Model、V Model のようなさまざまな 漸進的モデル を使っていた
- Agile は断絶的な革命というより、当時の流れの自然な帰結に近い
- 伝統的な工学がより多くの事前設計と独立した試験時間を使うのは事実だが、これは Waterfall の硬直性というより 反復コストの経済性 に由来する
- 反復に時間と費用がかかるほど、1回の作業をより長く計画するほうが合理的である
- 回路基板が最初から動作しなければ、工場に再送しなければならず、数千ポンドと 2 週間の工程が追加されることがある
- 設計と実装の境界も明確ではない
- 土木エンジニアの縮尺模型や、自動車エンジニアが美観と空力を試すために作る 実物大の粘土モデル は、設計でありながら実装とも見なせる
- 他の産業にも Agile に似たやり方は存在する
- オーストリア式トンネル工法 は、反復開発と現場での即興対応に依存している
- Handbook of Industrial Engineering は部門間協業と迅速な顧客フィードバックを重視している
- 土木工学でも施工が始まれば、現場の問題に対応するためオープンなコミュニケーションと適応中心へ移行する
伝統的な工学も予測しにくい
- 完成した橋や製品だけを見ると、その過程で生じた摩擦、コスト超過、遅延を見落としやすい
- 壁を 1 インチずれて建てたり、中核サプライヤーが廃業したりするだけでも、計画は揺らぐ
- ソフトウェアは 1〜2 年ごとに支配的なフレームワークや言語が変わるように見えるが、伝統的な工学も ツールと生産環境の変化 を経験する
- 半導体ファウンドリが新しい製造設備を導入すると、チップ設計計画も変わる
- ライブラリほど速くはなくても、変化がないという意味ではない
- 工事中に権利関係が変わったり、検証済みの手順が突然恒久的に失敗したり、開発後半で新事実が見つかったりすることもある
- 橋の基礎工事を始めたあと、特定の土壌が予想と違って凍結し、地震時に過度に液状化することが分かったなら、設計を最初からやり直す 必要がある
- ソフトウェアだけが特別に予測不可能だという考えは、他の工学分野の実際の作業過程を見ていないことから生まれる
「コードこそ設計」という主張
- 「コードこそ設計」は、UML で完璧なモデルを作ってからコードを自動生成すればよいという考えへの反動だった
- CPython コア開発者で、かつて Boeing のシステム統合エンジニアだった Nick Coghlan は、これをソフトウェアと以前の仕事との根本的な違いとは見ていない
- 航空機、航空交通管制、アンテナアレイのように独立した複数のシステムチームが 互換性のあるインターフェース を作るよう調整していた
- 半導体エンジニアにとっては、CPU の最初の回路図からファウンドリから出てきた最終チップまで、全工程が設計であり、製造は設計を渡してチップを受け取る比較的容易な段階かもしれない
- 完成したチップや機械製品に欠陥があれば設計を変えなければならないため、設計と製作は分離されない
- 機械工学の「fettling」は、製作過程の小さな不完全さに合わせて設計を調整する作業である
- 製作が設計を変え、変わった設計が再び製作を変えるという循環が生まれる
- 設計の範囲 そのものも曖昧である
- アーキテクチャ概要、形式仕様、詳細図面は、いずれも異なるレベルの設計である
- 橋梁設計図 のような複雑なプロジェクトには、複数の階層にわたって反復する詳細が存在する
- 施工に最も多くの時間と費用を使うという性質は、橋梁・建築中心の一部の土木工学に当てはまるものであり、それをすべての伝統的工学の代表像として一般化することはできない
- 土木工学も都市建設に必要な多様な領域を含むため、橋と建物だけに限定されない
厳密さに関する誤解
- 伝統的な工学は第一原理から慎重に推論するが、ソフトウェアはコピー＆ペーストに依存するという区分は、実際の仕事を反映していない
- ソフトウェアの相対的に低く見える厳密さは、文化だけの問題ではなく、実装と試験が容易な材料的特性に基づく 合理的なトレードオフ かもしれない
- 仮定を確認する最も簡単な方法が、直接実装して実行することになる場合が多い
- 経験的情報を素早く集める行為そのものも、厳密な検証方法である
- 伝統的な工学製品のほうがソフトウェアより一貫して体系的だという前提も正しくない
- ソフトウェアは記録保存と包括的な検証で、むしろ優れている場合がある
- 伝統的な工学の重要情報が Excel ファイルや古い書類棚に保存され、老朽化したり破損したりする例も多い
- ソフトウェアで当たり前とされる 自動テスト を導入したいと考える伝統的な工学エンジニアも多い
- 物理的構造物でも、必要ならブラケットを追加するような場当たり的対応は引き続き使われている
実際の違い 1: 一貫性
- ソフトウェアは論理によって完全に合成され、ばねのように摩耗しないため、他の工学成果物よりはるかに 一貫している
- ソート関数が異常入力ではない数値リストを 95% しかソートしないなら、正常な動作とは受け取りにくい
- 物理的な材料や部品には、理論値から外れるばらつきが基本的に存在する
- 抵抗器は 1Ω から数億 Ω まで提供され、色帯で理論上の抵抗値を示す
- 緑・青・赤の帯は 5,600Ω を意味するが、金の許容差帯があれば実際の値は最大 5% 異なることがある
- 同じ抵抗器 100 個のうち、一部は 5,320Ω、一部は 5,880Ω かもしれず、それぞれ測定しなければならない
- 摩耗や温度変化まで考慮すると、ばらつきはさらに複雑になる
- すべての物理材料には似た問題があり、ねじメーカー Fastenal も ステンレス鋼のねじをアルミ板に使わないよう 警告している
実際の違い 2: 変更速度
- ソフトウェアは他の工学システムよりはるかに速く変更できる
- 伝統的な工学では、仕様を共有したあと、工場や機械工場での製作と設置、数週間に及ぶ試験を待たなければならない
- 一部のエンジニアリング変更は、1 回ごとに予算から 5,000 ドル が消えるように費用が明確である
- コードは変更後、全テストを数秒で実行できる
- 非ソフトウェア分野では化学工学が最も近い速度を示したが、それでも 1 分単位の切り替えは想像しにくい水準だった
- 他の工学分野が設計ツールやシミュレーションにソフトウェアをより多く使う理由も、実装前にアイデアを素早くプロトタイプ化できるからである
- 高速に変更できる能力には負の側面もある
- 電子・機械装置の問題が完全に解決されないと、ソフトウェアエンジニアに コードによる回避策 で補うよう圧力が集中する
- こうした依存は致命的な結果につながりうる
- 2019 年の 2 度の Boeing 737 MAX 墜落事故で 300 人以上が死亡した
- 調査では、自動飛行制御システム MCAS のバグが原因として指摘された
- Boeing は、後になって見つかった航空機の 空力特性の問題 を物理設計で修正する代わりに、MCAS を追加した
実際の違い 3: 制約と後戻りできない変更
- 伝統的な工学製品には、重量、強度、耐性、温度のような必ず守るべき 物理的限界 がある
- チップ設計では、数分の 1 ナノ秒に相当するタイミング余裕まで他チームと交渉することがある
- ソフトウェアにも、メモリ容量、センサーの 10 サイクル応答、API 呼び出し制限のような制約はある
- ただし、ソフトウェアの制約は、超えるほど状態が悪化するソフト制約であることが多く、開発速度や単純なアルゴリズムのために境界を少し調整できる場合がある
- 伝統的な工学の制約は、超えると製品が動作しない ハード制約 であることが多い
- 箱の幅が少しでも広ければ、ドアを通れない
- 石油掘削施設に設置するスクリューコンベヤが部屋より数インチ高かった事例では、装置を小さくすることも、上の 4 階分のため天井を高くすることもできなかった
- 天井に穴を開けて装置を入れ、上階の人がつまずかないよう穴の周囲に囲いを設置した
- この変更は施設構造に恒久的に残り、その後のすべての変更で引き続き考慮しなければならない
- ソフトウェアエンジニアは場当たり的対応を元に戻せるが、伝統的な工学における物理的な場当たり対応は 恒久的な構造物 になりやすい
違いはあるが、特別ではない
- ソフトウェアには固有のセキュリティ問題があるが、土木工学には天候、化学工学には化学的特性というように、各分野にはそれぞれ別個の難題がある
- すべての工学分野は、事前の抽象的思考、整然とした作業、適切な場当たり対応を重視し、変化する要件と未知の未知 に向き合っている
- 各分野は互いに孤立しており、ソフトウェアエンジニアが機械工学を知らないのと同じように、化学工学エンジニアも他分野の実務を知りにくい
- ソフトウェアが特別ではないからこそ、他の工学分野から改善方法を学べるし、記録・検証・自動化のように伝統的な工学がソフトウェアから学べる点もある
- 続編 工学が私たちに教えられること、そして私たちから学べること では、両者が交換できる具体的な教訓を扱っている
1件のコメント
Lobste.rs のコメント
記事の多くには同意するが、ソフトウェア工学の厳密性については楽観的すぎる。今でも自動化テスト、とくに複数階層にわたる堅牢なテストが開発プロセスに組み込まれるのは当然ではなく、開発者自身だけを唯一のチェックポイントと見なしたり、組織がプロセスを障害物として扱って取り除いたりすることもある
業界は、検証済みのベストプラクティスを体系化しないまま、数年ごとに車輪を再発明している。標準化されたものも、たいていは会社ごとに意味が大きく異なる緩い共通語彙にすぎず、「アジャイル」や「テスト」がその代表例だ。多くの開発者はテストを単体テスト程度に考え、一部はコンポーネントテストや結合テストまで含めるが、会社によってはそれだけを通して本番環境へデプロイしている
以前書いたコメントのように、健全な組織ではコードレビューは品質を担保する複数のプロセスの一つであるべきで、本番デプロイを決める単一の関門であってはならない。コードのマージ後の品質保証プロセスが事実上消滅しているチームや会社は多い
責任を薄めようというのではなく、コードを書く前から品質をプロセスに内在化すべきだ。複数の職種が仕様と要件を議論する Three Amigos セッション、テスト駆動開発、IDE と各チェック段階に統合された静的解析、開発者とは別の品質保証・テスト自動化の専門家などが必要になる
土木工学では、一人が橋梁の設計者であり施工者であり唯一の責任者であることはない。計算と文書作成、再検算、政府の承認、施工中の監査と検査など複数の段階があり、戸建て住宅でも図面・承認・許可・検査を経る。工学的な災害も、複数の段階で防げなかったプロセス全体の失敗である場合が多い
ソフトウェア開発を土木工学と比較するなら、プロセスの水準がまったく同じではないという事実も認めるべきだ。せいぜい、法的要件を迂回しながら最も安い家を建てる住宅開発業者に近いケースが多い
したがって MRI 制御ソフトウェアのような分野ではない一般的なソフトウェアでは、テスト・検証コストとその効果のあいだの妥協点が、土木工学とは異ならざるをえない
3本とも素晴らしいので読むことを勧める。過去の議論もあわせて見られる
https://lobste.rs/s/fv8swh/crossover_project （プロジェクト発表）
https://lobste.rs/s/lmvroa/are_we_really_engineers （再議論）
https://lobste.rs/s/8j8sdc/are_we_really_engineers （別の再議論）
Glenn Vanderburg のこの講演も非常に関連が深い
ソフトウェア開発と伝統的な工学の最大の違いは、変更に伴う摩擦だ。ソフトウェアは比較的安価に変更でき、柔軟なので、まったく新しい可能性が開ける
伝統的な工学も、シミュレーションを多く作るほど、物理・化学的な制約の範囲内でソフトウェアに近い形で変更可能性を広げられる
「ソート関数なら、病的でない数値リストを95%の確率でしかソートしないとは想定しない」という言葉も、今ではLLM 生成コードには実際に当てはまる。たいていは動くが、常に動くわけではない
~hwayne はなぜアカウントを無効化したのか気になる