📚

実践ソフトウェアエンジニアリングを読んだ

に公開

GA technologiesでソフトウェアエンジニアをしている中坂です。今回は「実践ソフトウェアエンジニアリング(第9版)」を読んだのでその感想を書きます。

https://www.ohmsha.co.jp/book/9784274227943/

どんな本?

実践ソフトウェアエンジニアリング(第9版)は2021年にSoftware Engineering: A Practitioner's Approach (9th Edition)が邦訳されたものです。原著の初版は1982年で、その当時から40年以上何度も改訂を重ねられて今に至っています。300万部以上売れているらしく[1]、世界で最も売れているソフトウェアエンジニアリングの教科書の一つとのことです。

頁数は548ページと技術書としては一般的な部類に見えますが、実際にページを開いてみると1ページが縦に2分割され文章が詰め込まれており、体感としては1000ページに近いボリュームに感じます。

この第9版に関しては5部30章で、それぞれ下記のような構成になっています。ソフトウェアエンジニアリングに関する全領域を著者の視点から体系的に分類しているようです。

目次

  • 第1章 ソフトウェアとソフトウェアエンジニアリング

第1部 ソフトウェアプロセス

  • 第2章 プロセスモデル
  • 第3章 アジャイルとプロセス
  • 第4章 推奨のプロセスモデル
  • 第5章 ソフトウェアエンジニアリングの人間的側面

第2部 モデリング

  • 第6章 プラクティスの指針となる原則
  • 第7章 要求エンジニアリング
  • 第8章 要求モデリングの推奨手法
  • 第9章 設計の概念
  • 第10章 アーキテクチャ設計の推奨手法
  • 第11章 コンポーネント設計
  • 第12章 ユーザエクスペリエンス設計
  • 第13章 移動体端末におけるソフトウェアの設計
  • 第14章 パターンに基づく設計

第3部 品質とセキュリティ

  • 第15章 品質の概念
  • 第16章 レビューの推奨手法
  • 第17章 ソフトウェア品質保証
  • 第18章 ソフトウェアセキュリティエンジニアリング
  • 第19章 ソフトウェアテスト―コンポーネントレベル
  • 第20章 ソフトウェアテスト―統合レベル
  • 第21章 ソフトウェアテスト―移動体端末と特定ドメインに対するテスト
  • 第22章 ソフトウェア構成マネジメント
  • 第23章 ソフトウェアメトリクスと分析

第4部 ソフトウェアプロジェクトのマネジメント

  • 第24章 プロジェクトマネジメントの概念
  • 第25章 実行可能で役立つソフトウェア計画
  • 第26章 リスクマネジメント
  • 第27章 ソフトウェアサポート戦略

第5部 先端的な話題

  • 第28章 ソフトウェアプロセス改善
  • 第29章 ソフトウェアエンジニアリングの新興トレンド
  • 第30章 おわりに

個人的な感想

以下では本書を読んで、個人的に感じたことや考えたことを書きます。

ソフトウェアエンジニアリングについて

この業界である程度働いていると誰しもソフトウェアエンジニアリングとは何か?について考えたことがあるかと思います。

IEEEのSWEBOKではソフトウェアエンジニアリングは下記のように定義されているとのことです。

ソフトウェアエンジニアリング:ソフトウェアの開発、運用、メンテナンスに対するシステマティックで規律(discipline)ある、定量化できるアプローチの適用、すなわちソフトウェアに対するエンジニアリングの適用。

Roger S. Pressman、Bruce R. Maxim.「ソフトウェアとソフトウェアエンジニアリング」.『実践ソフトウェアエンジニアリング(第9版)』.オーム社,2021/12/01,p7

これを読んで全てを理解するのは難しいですが、まず「開発・運用・メンテナンス」がソフトウェアエンジニアリングの対象領域である、と述べている点に注目したいです。

現場で長くソフトウェアエンジニアとして働いている人にとっては当たり前ですが、まだ実務経験が浅い人だとどうしても開発にだけ注目してしまうのではないかと思います。ソフトウェアエンジニアは開発するというプロセスだけでなく、その後運用しメンテナンスをし続けるというプロセスにも責任を追っています。

Googleのソフトウェアエンジニアリングの1章では、

ソフトウェアエンジニアリングとは時間で積分したプログラミングである

Titus Winters、Tom Manshreck、Hyrum Wright 編、竹辺 靖昭 監訳、久富木 隆一 訳.「1章 ソフトウェアエンジニアリングとは何か」.『Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス』.株式会社オライリー・ジャパン,2021年11月,p3

と表現されていますが、ソフトウェアエンジニアリングというのはソフトウェアを開発するだけではなく、後世に向けて継続的に発展させていくための全ての営みだということだと解釈することもできます。

ソフトウェアの特性について

本書では、ソフトウェアがハードウェアと異なる特性として以下を挙げています。

  • 摩耗しない(物理的な劣化は起こらない)
  • 悪化する(変更によって構造が複雑化し、品質が低下する)
  • カスタムメイド(スペア部品で変えが効くような標準的な部品から組み立てられるわけではない)

ハードウェアはお馴染みのバスタブ曲線に従って摩耗し、時間と共に劣化していきます。これは身の回りのあらゆるハードウェアで起こっており直感的に理解しやすいです。

一方でソフトウェアはハードウェアと異なり環境的な要因で勝手に劣化しません。ここで一瞬「?」と思ったかもしれないです。というのも、では我々が日々苦心している技術的負債や障害といったものは劣化ではないのか?という疑問が湧くからです。

本書では、ソフトウェアは劣化はしないが「悪化」はするという表現をしています。つまり上記のソフトウェアにまつわる日々の苦労は悪化によるものだということです。

そして悪化を引き起こすものは「変更」であると述べられています。変更によりソフトウェアは一時的に故障率が上がります。その後、故障率が一定まで下がる前にさらに別の変更が入ります。この繰り返しでソフトウェアは徐々に悪化していくのです。

現代ではビジネスの要求は日々変わり、その要求スピードも速くなっています。ソフトウェアはその要求を満たすために変更から逃れられません。

先ほどソフトウェアエンジニアリングは将来へ通じて良いソフトウェアを開発し続けるための営みだと表現しましたがそれは言い換えると、ソフトウェア開発において逃れられないこの「変更」をいかにうまくコントロールするべきなのか、ということだと言えるでしょう。

ソフトウェアエンジニアリングの4つの層

本書ではソフトウェアエンジニアリングを以下の4つの層で説明しています。

  • 品質(すべての基盤)
  • プロセス(開発の枠組み)
  • 手法(技術的な手法)
  • ツール(自動化されたサポート)

特に品質に焦点を合わせることが全ての基盤であると語られています。

そもそも品質とは何か?については第3部15章の「品質の概念」以降の数章かけて触れられており、ソフトウェア品質の一般的な意味では「作る人と使う人に重要な価値をもたらす有用な製品を作り出すための、効果的なソフトウェアプロセス」とあります。ただし、品質はそれほど単純なものではなく、McCallによる品質を構成する要素の定義やISOの品質モデルなど様々な要素、品質をいかに評価するのか?など議論の範囲は広いです。

そもそもなぜソフトウェアエンジニアにおいて品質が重要なのか?についても疑問が湧くかもしれませんが、そこはさすが品質について厚く述べられている本書なので第1章の2Pに21世紀のソフトウェアを構築するための大前提に下記の記述があります。

個人や企業、政府において、日々の活動や統制に加えて、戦略的、戦術的な決定判断をソフトウェアに頼る状況が増えてきている。ソフトウェアが問題を起こしたならば、人々や企業が少し不便になることもあれば、致命的な結果にもなることもある。ソフトウェアは高品質であるべきだ。

Roger S. Pressman、Bruce R. Maxim.「ソフトウェアとソフトウェアエンジニアリング」.『実践ソフトウェアエンジニアリング(第9版)』.オーム社,2021/12/01,p2

品質の高いソフトウェアを作るということは当たり前の前提であり、取捨選択される対象ではないということでしょう。これは実は全てはビジネス起因でバランスにより判断すべきものであると考えていた自分としては結構衝撃的な考えでした。後の章で「ほどほどに良い」ソフトウェアのジレンマについての話が出てきますが、そこではそのアプリケーションドメインにおいて本当の意味で「ほどほどに良い」ものは何か開発者が明確に定義することができるのか?と疑問を投げかけています。

確かにできないわけではないですが、それよりもむしろ市場投入へのビジネスサイドからの圧やMeskimenの法則(物事を正しく行う時間はあったためしがないのに、やり直す時間はいつだってある)に流されてほどほどで折り合いをつけてきただけではないでしょうか。

とはいえ完璧な品質を求めることは難しく、であるからこそ品質には予防・評価・失敗の観点から語られるコストがつきまといます。それらを認識しコントロールすることが重要であり、後章に続く品質保証やプロジェクトマネージメントなどの話の中でそれらのコストをどうコントロールするか?という話につながっていきます。

少々脱線しましたが、ソフトウェアエンジニアリングは品質という基盤の上に、どういうプロセス(ウォーターフォールやアジャイルなど)で作るのか?という枠組みがあり、その中に具体的にどういう設計手法やプラクティスを適用し実装していくのか、という大きな枠組みで捉えられるようになるこの4層の考え方はとても有用だと感じました。

その他

本書ではお馴染みの原則やプラクティスや設計手法などが数多く紹介されていますが、中でも自分は知らなかったのですが、第1章で紹介される「Hookerの7つの原則」というものが良かったです。

  1. システムが存在する唯一の理由(ユーザに価値を提供する)
  2. KISS原則(シンプルに保つ)
  3. ビジョンの維持(一貫性のある設計)
  4. 他者が使用することを意識(将来のメンテナンスを考慮)
  5. 未来へオープンであれ(変更に対応できる設計)
  6. 再利用を計画する(コンポーネントの再利用性)
  7. 考えよ!(行動前の熟考)

特に7の考えよ!は

行動を起こす前に簡潔明瞭な考えをもつことは、必ずと言ってよいほど良い結果を生む。

Roger S. Pressman、Bruce R. Maxim.「ソフトウェアとソフトウェアエンジニアリング」.『実践ソフトウェアエンジニアリング(第9版)』.オーム社,2021/12/01,p12

とあり、これは特に納得感が大きいです。

エンジニアリングというのは決まりきった伝統や規律に一語一句従うものではなく、本書のタイトルにもある通り「実践的」な試行錯誤をしていくこともまたエンジニアリングの一つの姿であると感じました。

ちなみに「Hookerの7つの原則」の原文は1996年の頃のテキストサイトで、今でも下記のURLにアクセスすると読むことができるようです。
http://wiki.c2.com/?SevenPrinciplesOfSoftwareDevelopment

対象読者

ところで対象読者については、個人的には実務経験が3年程度はある人が読むのが良いのではと感じました。

本書は学部・院生向けの教科書ということですが、具体的にコードがたくさん出てくるわけではなく定義や理論的な話が中心です。ソフトウェア開発は世間で思われているほど机上で行われるのではなく肉体的な営みだと思います。この本は実務経験が一定ある人が過去の経験を頭に巡らせながら読むことで深い理解が得られる類のものでしょう。

最後に

実践ソフトウェアエンジニアリングを読んで感じたことや考えたことを書きました。ソフトウェアエンジニアリングとは何なのか?ソフトウェアとは何なのか?なぜ品質を求める必要があるのか?など、普段当たり前のように行なっているはずのものなのに意外と理解が甘いことが多いです。

実は今回紹介した多くの話題は第1章に起因する話が中心で、本書の数%程度しか語れていません。その他、第2部にはみんな大好きアーキテクチャの話があったり、第3部には品質やセキュリティの話があったり、第4部にはプロジェクトマネージメントの話があったりと、それぞれの章で幅広い話題が紹介されています。

私個人としてはソフトウェアエンジニアリングでは「変更」を支配すること、つまり変更容易性を高めることが本質的に重要で、ウォーターフォールなのかアジャイルなのかだったり、クリーンアーキテクチャやDDDなどの設計論やSOLID原則やさまざまなその他リファクタリングプラクティスは手法であり、それらはあくまでも広い意味での変更容易性のための選択肢に過ぎないと考えられるのではないか?という示唆を得られたのは収穫でした。少々拡大解釈してしまっている気はしますが、あれやこれやと手法レベルで議論する際にこのようなより俯瞰した目を持つことができればもっと冷静に適切な意思決定ができるのではないかと思います。

昨今、AIがあればソフトウェアエンジニアリングは不要なのでは?という話もありますが、この本を読んでみると、ソフトウェアエンジニアリングはコードを書くことだけではなく、コードを書く前のプロセスや設計、品質保証やプロジェクトマネージメントなど、ただ開発するだけに留まらず重要な要素を含んでいることがわかります。ソフトウェア開発は組織レベルの問題も含めた、人間間のコミュニケーションや交渉や意思決定に大きく影響を受けます。

実務で利用している感覚としてはAIによって今のところ代替できるのはやはりまだ開発の一部分であり、旧来のソフトウェアエンジニアリングの全体のスコープからすると限定的な範囲であるという実感があります。とはいえAIによるコード生成やコードの拡張能力はソフトウェアエンジニアリングの一部として深く入り込んでくることは間違いないでしょう。ただし、それはどちらかというとソフトウェアエンジニアリングと対になるのではなく、ソフトウェアエンジニアリングに内包され、プロセスやフレームワークを発展させるための手法の一部というイメージです。

そういえば、そもそもなぜこの本を手に取ったのかというと上司にソフトウェアエンジニアリングについても学んでみると良いのでは?というフィードバックをもらったからでした。CSだけでなくソフトウェアエンジニアリングの観点でも普段から開発に取り組むメンバーが多く在籍するGA technologiesでは、ソフトウェアエンジニアリングを実務でも実践できるエンジニアを募集しています。

興味がある方はお気軽にご連絡ください!(私のXのアカウントに連絡いただいても大丈夫です)

https://ga-technologies-engineering.notion.site/GA-technologies-9794c78bc56c4011a03f7f3dcf91a18f

参考リンク

https://www.ohmsha.co.jp/book/9784274227943/
https://www.computer.org/education/bodies-of-knowledge/software-engineering
https://www.oreilly.co.jp/books/9784873119656/
https://anzeninfo.mhlw.go.jp/yougo/yougo59_1.html
http://wiki.c2.com/?SevenPrinciplesOfSoftwareDevelopment

脚注
  1. Roger S. Pressman、Bruce R. Maxim.「おわりに」.『実践ソフトウェアエンジニアリング(第9版)』.オーム社,2021/12/01,p445 ↩︎

株式会社GA technologies

Discussion