ソフトウェア開発エンジニアリングとは何か

ソフトウェア開発エンジニアリングとは何か 個々の才能に依存しないプロセス 2026.09.28 KO | EN | HNでの議論 ソフトウェアとエンジニアリング エンジニアリングのソフトウェアへの応用 エンジニアリングの観点から直感を説明する エンジニアリングアプローチが必要なとき ソフトウェアエンジニアリングの終焉 ソフトウェアを作る人々は、さまざまな名前で呼ばれます。開発者（Developer）が最も一般的ですが、プログラマー（Programmer）は中立的でやや伝統的な響きがあります。コーダー（Coder）は文字通りコードを書く人を指しますが、軽蔑的に使われることもあり、ソフトウェア開発に関わる他の多くの活動に参加せずにコードを書くだけの受動的な役割を担う人を暗示します。その対極にあるのがソフトウェアエンジニア（Software Engineer）です。 ソフトウェアエンジニアという肩書きは、かなり異なる響きを持っています。どういうわけか、ソフトウェアエンジニアはコーダーよりもプロフェッショナルに見えます。何らかの理由で、彼らはプログラマーよりも数学に優れているように見えます。そして、どういうわけか、彼らの仕事は開発者の仕事よりも重要に見えます。実際、カナダの一部の州では、「ソフトウェアエンジニア」、「コンピュータエンジニア」、その他の「エンジニア」を含むコンピューティングの肩書きは、（原則として）州のエンジニアリング規制機関によってライセンスされたエンジニアにのみ予約されています。多くの人は、エンジニアという肩書きを持つ人が公認の専門資格やライセンスを持っていると想定しています。 これらすべては、エンジニアという肩書きが私たちに与える主観的な印象に関するものです。しかし、多くの人がその印象を共有しているなら、その理由を尋ねる価値があります。もしソフトウェア開発が自明にエンジニアリングの一形態であれば、そもそもソフトウェアエンジニアという肩書きに特別なものはありません。この印象はどこから来るのでしょうか？なぜソフトウェアエンジニアリングは、機械工学、電気工学、土木工学とは異なるように感じるのでしょうか？そして、何がソフトウェア開発をエンジニアリングたらしめるのでしょうか？ ソフトウェアとエンジニアリング NATOソフトウェアエンジニアリング会議（Robert McClure, Brian Randell） エンジニアリングの単一の定義はありませんが、一般的には、さまざまな制約の中で数学的および科学的知識を応用して、人間のニーズを満たすために体系的に問題を解決する分野として説明できます。ユネスコ[1]と米国学術研究会議[2]は、エンジニアリングの以下の定義を提供しています。 エンジニアリングとは、技術的、科学的、数学的な知識の開発、取得、および応用に関連する実践、専門職、および芸術の分野です。それは、特定の目的のための材料、機械、構造、システム、およびプロセスの理解、設計、開発、発明、革新、および使用に関するものです。 エンジニアリングは、人間が作った製品やプロセスの創造と設計に関する知識であると同時に、制約下での設計と呼ばれる問題解決方法でもあります。 ソフトウェア開発に他のエンジニアリング分野と同様の体系的な基盤を与える試みは、コンピューティングの初期から行われてきました。1968年のNATOソフトウェアエンジニアリング会議[3]は、ソフトウェアエンジニアリングの出発点と見なされることがよくあります。ドイツで開催されたこの会議で繰り返し懸念されていたのは、ソフトウェアの規模と重要性が急速に増大するにつれて、ソフトウェアがますます複雑になっていることでした。これはソフトウェア危機として知られるようになりました。参加者は合意に至りませんでしたが、ソフトウェア開発という若い分野が、その当面の問題を解決するために、確立されたエンジニアリング分野と同様の方法と構造を必要としているという見解を広く共有していたようです。会議報告書の編集者は、ソフトウェアエンジニアリングという言葉について次のように書いています。 「ソフトウェアエンジニアリング」という言葉は、ソフトウェア製造が確立されたエンジニアリング分野の伝統的な理論的基盤と実践的な規律に基づかなければならない必要性を示唆するために、意図的に挑発的に選ばれました。 一方、Thomas Haighは、ALGOL 60の後継を開発していたIFIPワーキンググループ2.1内で会議の前に行われた議論に、より大きな意義を見出しています。グループの支配的な見解は、少数の基本的な概念を組み合わせることによって複雑なプログラムを表現できるはずだということでした。この哲学はALGOL 68のドラフトに強く影響しました。複雑なプログラムを表現する方法よりも、それらを信頼できるものにすることにもっと関心があったグループ内の人々は、ALGOL 68の方向性に反対しました。ALGOL 68の反対者は、NATOソフトウェアエンジニアリング会議の中心にいました。彼らは、ソフトウェア開発がより厳格で管理可能な活動になる必要があると信じていました。そのうちの一人であるEdsger Dijkstraは、プログラミングを応用数学の一形態として扱い、後に構造化プログラミングを主張するためにソフトウェア危機を再び引き合いに出しました。 これらのソフトウェアエンジニアリングに関する議論が、アプリケーションプログラマーの仕事からどれほどかけ離れていたかを念頭に置く必要があります。会議の参加者のほとんどは研究者でしたが、当時のほとんどのアプリケーションは、ビジネスデータ処理のためにCOBOLで書かれた金融、会計、人事ソフトウェアでした。したがって、1968年に議論されたソフトウェアエンジニアリングの概念は、当時のソフトウェア産業全体を説明することはできません。しかし、今日訓練されているプログラマーは、ALGOL 68の議論やNATOソフトウェアエンジニアリング会議から、間接的、時には直接的に影響を受けています。Cでプログラミングする際にgotoを避けるように言われたり、オブジェクト指向プログラミングや関数型プログラミングのようなトピックに遭遇したり、あるいは単に最新のプログラミングツールを使用したりした場合、これは真実です。 ソフトウェアへのエンジニアリングの応用 ソフトウェア開発をエンジニアリング分野として確立するための数十年にわたる努力を経て、Software Engineering Body of Knowledge (SWEBOK)[5]は、「エンジニアリング」と「ソフトウェアエンジニアリング」の以下の定義を使用しています。 電気電子学会（IEEE）は、エンジニアリングを「構造物、機械、製品、システム、またはプロセスに対する体系的、規律的、定量的なアプローチの適用」と定義しています。（…）ソフトウェアエンジニアリングは、「ソフトウェアの開発、運用、および保守に対する体系的、規律的、定量的なアプローチの適用、すなわち、ソフトウェアへのエンジニアリングの適用」と定義されています。 この定義によれば、ソフトウェア開発をエンジニアリングたらしめるのは、ソフトウェア開発へのエンジニアリングアプローチの適用です。エンジニアリングアプローチとは、エンジニアが特定の基準に従って問題に対する複数の実行可能な解決策の中から1つを選択し、それを実装し、結果を監視するプロセスです。このプロセスは逐次的である必要はありませんが、反復的である必要があります。実際、エンジニアリングアプローチは本質的に反復的です。どの段階で獲得された知識も、以前の段階に影響を与える可能性があり、自然に別の反復を促します。エンジニアリングの決定は推定に基づいて行われるため、決定の質は推定の質に依存します。したがって、エンジニアは推定と実際の結果を比較して、推定のためのフィードバックループを作成する必要があります。推定と実際の結果の間のギャップの原因を理解することで、推定技術を洗練し、将来より正確な推定を行うことができます。これにより、より良い決定を継続して行うことができます。 エンジニアリングの観点から直感を説明する これは少し机上の空論のように聞こえるかもしれませんが、具体的な例が役立つかもしれません。ある日、運用チームがEコマステックプラットフォームで作業しているプログラマーに、製品詳細ページの読み込みが遅すぎると伝え、読み込み時間の改善を依頼します。システムをよく知っているプログラマーは、ページが遅く読み込まれると聞いて、直感的に解決策を思いつくかもしれません。これは必ずしも悪い決定につながるわけではありません。しかし、その決定が代替案よりもなぜ優れているのか、成功と見なされるためにはどのくらいのパフォーマンスを改善する必要があるのか、またはそれがユーザーに実際にどのくらいの差をもたらすのかを説明するのは困難です。 エンジニアリングアプローチは、実際の問題の正確な理解から始まります。「遅すぎる」は多くの意味を持ちうるため、最初のステップは、改善が必要な製品詳細ページのパフォーマンスを測定することです。最近