1976年の「ソフトウェアエンジニアリング」という論文を読んだ感想
これは、IEEE TRANSACTIONS ON COMPUTERS, VOL. C-25, NO. 12, DECEMBER 1976に掲載されたベームという有名な方の「ソフトウェアエンジニアリング」という論文の感想です。
最近、ソフトウェアエンジニアリングって言葉の意味を調べ直してました。私たちの仕事は「エンジニア」って言うことが多くありますが、正式にいうとソフトウェアエンジニアだし、エンジニアリングをする人たちだからエンジニアなはずなので、そもそもソフトウェアエンジニアリングって何かからわかっておく必要あると思うからです。
そうしたら、辰巳さんに以下の情報を教えてもらいました。
最初に"Software Engineering"という用語を定義したのは1976年のBarry Boehmさんの論文かもしれません。
— Keizo Tatsumi (@KeizoTatsumi) April 29, 2024
"Software Engineering"
IEEE Transactions on Computers, Vol.25, Issue 12, Dec. 1976, pp. 1226-1241https://t.co/dyOKut0Q7C
バリーベームはソフトウェアエンジニアリングを学ぶ上で必ず押さえていた方がよい人です（要件の段階でバグを取り除いたほうがテストで取り除くより効率良いし、本番行ってからより1/100のコストしかかからないって話を最初にしたのはベームです）。
なのですが、私はこの論文を実際に読んだことがありませんでした。ちゃんと知っておくべきだと思い奮発して買ってしまいました。（円安なので高かった！）
読んでみると、50年近く前の論文なのに本質的に書いてあることは今も変わらなくて、刺激的でした。
アブストラクトにはこんなことが書いてあります。
This paper provides a definition of the term "software engineering" and a survey of the current state of the art and likely future trends in the field. The survey covers the technology available in the various phases of the software life cycle-requirements engineering, design, coding, test, and maintenance-and in the overall area of software management and integrated technology management approaches. It is oriented primarily toward discussing the domain of applicability of techniques (where and when they work), rather than how they work in detail. To cover the latter, an extensive set of 104 references is provided.
（ゆもつよ訳）本稿では、「ソフトウェアエンジニアリング」という用語の定義と、この分野における技術の現状と将来のトレンドに関する調査を行う。この調査では、ソフトウェアライフサイクルのさまざまなフェーズ（要件エンジニアリング、設計、コーディング、テスト、メンテナンス）、および全体的な領域で利用可能なソフトウェアのマネジメントとインテグレーション技術のマネジメントのアプローチをカバーしている。この調査は、技術がどのようにワークするかを詳細に説明するのではなく、技術の適用可能な領域（いつ、どこで、どのようにワークするか）を説明することを主眼としている。技術がどのようにワークするかの詳細な説明をカバーするために、104の広範な参考文献を用意している。
論文について
構成はこうなっています。
はじめに
定義
ソフトウェア要求エンジニアリング
ソフトウェア設計
プログラミング
ソフトウェアのテストと信頼性
ソフトウェアメンテナンス
ソフトウェアマネジメントと統合アプローチ
まとめ
どんなことが書いてあるかと、私の感想をそれぞれ書いていきます。
はじめに
まず、「1950年代ごろは、ハードとソフトのコスト比率だと、ハードが80％以上だったが、今後ソフトのコスト比率が増えて1985年くらいには全体の80％くらいがソフトのコストになり、さらにその中の80％くらいがメンテナンスコストになる」って調査を引用してます。そしてソフトウエアエンジニアリングを「コスト効率よく、信頼に値する」開発の手段であるって書いてます。
定義
ソフトウェアエンジニアリングの定義はこうです。
Software Engineering: The practical application of scientific knowledge in the design and construction of computer programs and the associated documentation required to develop, operate, and maintain them.
（ゆもつよ訳）ソフトウェアエンジニアリング：コンピュータープログラムの設計と構築、および各種（開発、運用、メンテナンス）に必要なドキュメンテーションにおける、科学的知識の実践的な適用。
この定義にいくつか大事なポイントがあるよって書いてるのですが、最後に書いてあるこれ↓
The final point is that our store of knowledge about software which can really be called "scientific knowledge" is a rather small base upon which to build an engineering discipline. But, of course, that is what makes software engineering such a fascinating challenge at this time.
（ゆもつよ訳）「科学的知識」と呼べるようなソフトウェアに関する知識の蓄積は、エンジニアリングのディシプリン（訓練して自分たちでできるようにすること）を形成するためのベースとしてはかなり小さいということだ。しかし、もちろん、それこそが現時点でのソフトウェアエンジニアリングの魅力的な挑戦なのである。
が「だよ、そうなんだよな！」って感じです。私だけでなく、みんな気付いてることだし、いろいろな方による多くの名言もありますが、結局エンジニアリングってサイエンスを適用する際に起きる人間模様とか人のスキルアップのための努力とか組織文化とかそういう話が大事になるんだよなって思います。「1976年から既にわかってることなんじゃん」って思いました。
ついでに書くと、エンジニアリングを「工学」と訳すのは私は嫌いです。エンジニアリングはあくまで「技術の現場への適用」をすることであり、「技術の現場への適用」を学問として学ぶことが工学なので。
ソフトウェア要求エンジニアリング
要求の段階で仕様化するのがなんで大事かというと、「この段階で間違いがわかれば、運用に入ってからよりも1/100の工数で修正できるからだ」っていうベームならではの話が既に図とともに説明されています。この段階でちゃんと仕様化されてないと、他にも問題があるって書いてあり、「トップダウン設計ができなくなる（トップダウンとは、要件が正しく完璧だって前提で設計をして良いという考え方）」とか「テストするのものがわからないのでテストできない」とか書いてます。まったく今に通づる話でこの50年弱の間、私含めてエンジニアは何をしてるんだろうって笑っちゃいます。
ソフトウェア設計
これには「要件と設計のジレンマ」って副題がついてます。「理想的には、ソフトウェア設計に進む前に、完全で、一貫性があり、妥当性が確認され、曖昧さがなく、ハードウェアに依存しないソフトウェア要求仕様があることが望ましい。」けど、それは無理なので複数の設計をして選択が必要になるとのこと。確かに。けど、問題は選択肢がどんどん増えてって自由度が高いために選択のための技術などが必要になるって話が書かれてます。標準化した方が悩まなくて済むとも書いてあります。
プログラミング
プログラミングは研究してる人がたくさんいるからそっち読んでね。って感じでした。
ソフトウェアのテストと信頼性
しょっぱなに「テストにかかるコストが高い（開発工数の40～50％を占める）」にもかかわらず、コードを実行するまでテストのこと何も考えないことが多いって書いてあります。
テスト計画をちゃんと立てるのがよいとか、信頼性の評価でハードウェアの考え方が使えない（ソフトは劣化しないとかですね）、シンボリックエクゼキューションの話とかテストの十分性（入力空間や出力空間が無限になるよって話）、静的解析、デバッグ、再テストなど本当に色々なことが書かれてて、例は古いのですが考え方は今でも全部使えるものばかりで、逆いうと、それだけ進化できなかったのか、難しいのかって感じです。
ソフトウェアメンテナンス
こちらもしょっぱなに「ソフトウェアメンテナンスは非常に重要な活動であるが、非常に軽視されている。」って書かれてます。メンテナンスは、今でいう機能修正や拡張とリファクタリングがあるよとか、ドキュメントのトレーサビリティと、再テスト可能なソフトウェア構造が重要だって話が書いてあります。
ソフトウェアマネジメントと統合アプローチ
こちらのしょっぱなの文章は原文から載せたい！
There are more opportunities for improving software productivity and quality in the area of management than anywhere else. The difference between software project successes and failures has most often been traced to good or poor practices in software management.
（ゆもつよ訳）ソフトウェアの生産性と品質を向上させる機会は、他のどこよりもマネジメント分野に多い。ソフトウェアプロジェクトの成功と失敗の差は、ソフトウェアマネジメントの良し悪しに起因することが最も多い。
そのうえで「計画しない」とか「リソース見積もらない」とかマネジメントの問題になる理由をたくさん上げてくれていて、その解決のためにワインバーグやブルックス（人月の神話の著者）の本を始め、たくさん紹介してくれています。けど、問題点としてマネジメントとテクノロジーの断絶（Management-Technology Decoupling）ってことが書かれてて、これも現代でも問題になってるよなーって思いました。マネジメントするにもまずは技術ありきで、技術をどう上手く使うかって話のはずなのに、両者がうまく噛み合ってない、逆に技術の話にはマネジメントが入らない、ここに問題があるって、これも50年近く前から言われてることなんだよなって改めて考えちゃいます。
まとめ
まとめでは、ハードウェアエンジニアリングの世界とソフトウェアエンジニアリングの世界を比較した表を提示してて、ソフトウェアエンジニアリングは「比較的経済性に依存しないコンテキストにおける、専門家によるシステムソフトウェアの詳細設計とコーディング」の領域では発展しているが「普通の技術者によるソフトウェアの要求分析、設計、テスト、保守の適用という、経済的にもっとも大事な問題」で、この領域だと「私たちの科学的基盤は非常に乏しく、現在の技術が "ソフトウェアエンジニアリング "と呼ぶに値するかどうか、真剣に疑問視してしまう」状況だとのこと。なのでこの後者の領域は、リスクが高いけど取り組む価値があり、いろいろな問題の解決に向けた道が開けるので頑張ろうって感じでまとめてます。
全体を通しての感想
この論文は1976年のものですが、「これって実は2024年の論文ではないのか？」って思ってしまう錯覚におちいりました。今、こういうことが書いてあってもそれほど驚かないので。
途中でも書いたけど、ソフトウェアエンジニアリングって、その科学的知識を適用するのが人なんだってところが難しくしてるのかなって思いました。この論文のソフトウェアテストのところでも、テストの入力空間が無限になる理由に「どのような入力xに対しても、プログラムがそれを特殊なケースとして誤って扱わないことを保証しなければならないから」無限になるとか、プログラムの証明も非自明なものは非常に困難で100行のコードでも専門家が1人月かかるとか書いてます。
だからこそ「a fascinating challenge(魅力的なチャレンジ) 」だってベームさんも50年前に言ってるので改めて頑張ろうと思いました。
いいなと思ったら応援しよう！
