実践ソフトウェアエンジニアリング第9版の感想
この文章は実践ソフトウェアエンジニアリング第9版アドベントカレンダーの2日目です。
私は Software Engineering: A Practitioner's Approach: 9th edition の翻訳活動に参加し、2021年12月1日に 実践ソフトウェアエンジニアリング第9版 としてオーム社より発刊されました。オーム社のサイトでは以下の紹介文が書かれています。
本書は米国においての第1版の発行（1982年）以来、世界累積300万部を超えるベストセラーの最新刊である第9版の邦訳書です。ソフトウェア同様、改良が続けられているソフトウェアエンジニアリングの「最良の手法」を解説している書籍であり、現役のソフトウェアエンジニアならびに学生諸氏におすすめする1冊です。
そんな40年の歴史を持つ本の共同翻訳が始まった経緯は、監訳者が書いたアドベントカレンダーの1日目に記されている通りです。共訳者の私も知らなかった経緯が記されており、苦難があったと感じさせられました。私が翻訳に参加したきっかけは監訳者に誘われたからです。そういう経験もしておこうという軽い気持ちで参加しました。私を選んだ理由を聞いたら「日本語が書けるから」と言われた記憶があります。その意味は実際に翻訳をしてみてよくわかったのですが、翻訳に求められる能力についてはアドベントカレンダーの後日に書く予定として、今回は本書を読者として見た感想を、本書を引用しつつ書いてみます。
広く、頭から読みやすく、体系的な理解を促す
本書は、ソフトウェアエンジニアリング（工学）について、その意義と定義から始まり、プロセスモデル、要求エンジニアリング、設計手法、テスト手法、品質保証、変更マネジメント、プロジェクトマネジメント、リリース後のサポート戦略、人間的側面、新興トレンドといった広い領域を扱っています。
本書の第1章では、著者とゲーム開発者のキャッチーで重要な会話から始まり、ソフトウェアの定義、ハードウェアとの違い、ソフトウェアエンジニアリングの意義と定義が語られます。そして、続く章でプロセスモデルやアジャイルが扱われ、要求や設計といった作る活動の章、テストやマネジメントといった開発を支える活動の章、という構成になっています。これは私にとっては読みやすい構成でした。プロセスモデルは個々の活動に大きく影響するので、最初に述べておくのが適切だと思います。
また、個々の技術や事例が列挙されているだけではなく、関連づけながら解説されているので、体系的な理解をしやすい文面になっていると思います。前後の章だけでなく離れた章同士の関連も示されています。以下はその例です。
- 第3章 アジャイルとプロセス → 第7章 要求エンジニアリング（ユーザーストーリー）
- 第16章 レビューの推奨手法 → 第3章 アジャイルとプロセス（ペアプログラミング）
- 第27章 ソフトウェアサポート戦略 → 第22章 ソフトウェア変更マネジメント
これは、SWEBOK や SQuBOK とは異なり、Roger S. Pressman がほぼ1人の著者である本書であるから成せる文面ではないかと思います。 (第9版は Bruce R. Maxim との共著ですが、全版の著者であるのは Pressman だけです)
温故知新からモダンまで
1982年の初版から改訂され続けている本書では、温故知新的な知識から近数年のモダンな知識まで扱われているように見えます。以下にいくつか抜粋します。まずは古い文献を参照している記述から。
本来のウォーターフォールモデルは「フィードバックループ」を考慮している[Roy70]のだが、このプロセスモデルを適用した組織の大部分は厳密な逐次型プロセスとして扱ってしまった。
知っている人にとっては有名ですね。
ソフトウェアパターンの歴史は、コンピュータ科学者ではなく、建築家のChristopher Alexanderから始まっている。(中略) [Ale77]。
これは知りませんでした。XPの本に書いてあった、かも。
「人間に適合する技術をつくるためには、人間について学ぶ必要がある。しかし、今私たちは技術だけを勉強しがちだ。結果的に、人々は技術に従うことを求められている。この傾向を逆転させるときがきた、人々に従う技術を作るときがきたのである」[Nor88]。
ユーザビリティに着目し初めた時代の文献が1988年発行だそうです。
対して、まぁまぁ最近のものだと思える記述も紹介します。
Googleは、UX設計を行うための5日間のスプリントを定義した[Kna16][Goo18][DXL18]。
上記と同じユーザビリティを扱う章で2016年と2018年の文献が参照されています。
将来は、超絶的な複雑さを克服するためにAIが広く使われるだろう[Har12b][Xie18]。機械学習はテストとバグ修正を助ける技術の1つである[Mei18]。超巨大プロジェクトが生み出す膨大なデータを理解するにはデータサイエンスが役立つだろう[Kim16b]。このような研究畑生まれのリポジトリマイニングは実務で使われつつある[Dye15]。
データサイエンスの応用事例です。
Google PlayやAppleのApp Storeのようなさまざまなオンラインストアでは、ユーザがアプリ対し星付けやコメントといったフィードバックができる。
これはユーザにとっては当たり前ですが、大学の教科書に載るのは面白いですね。
参照されている参考文献は、書籍、論文、Webページなど全て合わせて驚愕の500超です。本書（訳書）では、和訳された書籍についてはできるだけ参考文献ページに追記しておきました。
実務者視点の記述が所々に見られる
SWEBOK, SQuBOK のように、多数の文献を参照して体系だてられた書籍では文献に基づく客観的な記述が多く、あまり実務者視点の記述はありません。対して、本書では多数の文献を参照しつつも、実務者視点の記述、あるいは実務者を主観的に見た記述が所々に見られます。それらを以下にいくつか抜粋します。
私たちはいつも、ソフトウェアエンジニアリングは実際よりも急速に変化するのではないかと考えがちである。新しいプロセス、独創的な手法、刺激的なツール等の「持ち上げられた」技術が伝来し、専門家は「全てが変わる」と言う。
そう謳う人、考える人、いるよなぁと思わされます。
たとえ最先端技術を扱う開発であったとしても、規律が適用されていない現場は珍しくない。そのような現場では、現代的な手法を知らないままのエンジニアもいる。
データサイエンスや制御理論が得意な方のコードは構造化されてなくて読みづらく、普段の開発を feature branch で見せずにある日いきなりでかい Pull Request を出してくるみたいな話でしょうか。（架空の実話です）
ソフトウェアを開発する組織内の個々のメンバーの「創造性」に誇りをもつ傾向があり、SPIフレームワークを過度に官僚的で堅苦しいものと見なす傾向がある。
私も昔は「CMMIなんてコンサルの商売道具でしかない」って思ってました。
ソフトウェアエンジニアは知的労働者であり、仕事の進め方とプロセスの変更に対するトップからの指示に対して否定的な反応を示す傾向がある[Con02]
両方の気持ちがわかるんですよねえ。
…といった記述があります。これが原著の副題 A Practitioner's Approach であることの表れでしょうか。
CSとCEのことは載っていない
実際のソフトウェアエンジニアリングでは、コンピュータサイエンス（CS）とコンピュータエンジニアリング（CE）の知識も求められます。本書の名前は実践ソフトウェアエンジニアリングですが、本書だけでソフトウェアエンジニアリングに必要な一般的知識を網羅できるわけではなく、アルゴリズム、OS、ネットワーク、並列/並行処理、データサイエンスといったCSやCEの要素は別に学習する必要があります。また、本書の解説は、CSとCEの入門的知識があるものとして書かれています。
具体的な実現方法は載っていない
本書にはクラス図は載っていますが、ソースコードは載っていません。 ユニットテストとテスド駆動開発は載っていますが、xUnit のツールは載っていません。 継続的インテグレーションと DevOps が載っており、Git, Jenkins, JIRA というツール名も出てきますが、ツールの使い方は載っていません。
本書には、特定のプログラミング言語、アプリケーションフレームワーク、ライブラリ、ツールのことは載っておらず、抽象的な方法や教訓が書かれています。それゆえに本書の帯には「ソフトウェア技術者なら、この財産を活用しない手はない。」と書かれています。ただし、読者が本書を財産であると実感するには、読者が日頃ふれている具体的な環境と本書の内容を対応づけられる必要があります。
ソフトウェアエンジニアリングのはずだけど案外載ってない領域
私から見て「え、これ載ってないんですか？」という領域があります。
継続的インテグレーションは載っていますが自動テストは載っていません。システムテスト自動化標準ガイドの圧縮版みたいな節があると想像していたのですがありません。
テスト設計とプロジェクトマネジメントは載っていますがテストマネジメントは載っていません。テストマネジメントツールや、テストケースのマネジメント方法は載っていません。
機械学習モデルに対するテストは従来のテスト方法で対応できると書かれており、QA4AI や機械学習工学研究会の立場と異なります。訳書ではQA4AIへのリンクを訳注として記しておきました。教科書に載るには新しい領域だと思うので、次の版で加筆されるかもしれません。
形式手法は載っていません。以前の版では載っていたそうです。
ソフトウェアプロダクトラインという言葉は出てきますが、その方法は解説されていません。
デバッグの方法は載っていません。どのようなログ設計をしておくのがよいか、一般的にデバッガで何ができるかは、業界やアプリケーション形態を問わない知見があり、載せる価値がある領域だと思います。
マルチプロセス、マルチスレッド、マルチコア、モジュラモノリス、マイクロサービスといった並行/並列/分散システムのための設計とテストの手法は載っていません。組込みとサーバーサイドで欲しいところだと思います。
リリースした後を扱うソフトウェアサポート戦略の章はあり、βテストや運用という言葉も出てきますが、A/Bテスト、カナリアリリース、ローリングアップデート、サイトリライアビリティエンジニアリングといったデプロイや監視の領域は扱われていません。Webシステムに限定されるので扱っていないのかもしれませんし、これから載るのかもしれません。
以上をふまえて、誰が何のために読むのがよいか
本書の対象読者は、原著でも訳書でも、実務者と学生とされています。ではどんな実務者や学生が何のために本書を読むのがよいかと考えると、以下の例が浮かびます。
- [実務者個人の学習] 実務経験者が、自身の経験した実務と関連する本書の記述を探して読み、一段上の理解を深める。また、自身で経験していないものの見聞きしている領域の概略を知り、自身が担当する際に備える。その中で深く知りたい領域があれば、本書の参考文献を入手したり、類似書籍を探す。
- [組織的な技術向上] 組織的なソフトウェアエンジニアリング能力を伸ばす責務と権限を持ち、実務経験豊富な実務者が、現状認識と改善方針を立てるために参照する。
- [ソフトウェアエンジニアリングへの入門] CSとCEの入門的知識とプログラミング技術（大学や高専での学習または独学によるもの）を身に着けた学生あるいは新卒がソフトウェアエンジニアリングへ本格的に入門する際に読む。実務経験と知識を持つ者が教える形をとり、受講者の嗜好やカリキュラムに合わせて本書の内容を抜粋する。
本書は基礎を示す本として素晴らしいもの（財産）ですが、独学のための入門書ではないと判断します。独学で入門するなら、エクストリーム・プログラミング、カイゼン・ジャーニー、チーム開発実践入門といった、チームで長く開発を続けることを語った量の少ない本の方が向いていると思います。そして、実務経験を積んでから本書を読むと、経験と入門書の内容を抽象度を上げて理解でき、周辺領域も理解しやすくなり、業界や職種が少々変わっても通用する知識（財産）が手に入るのではないかと思います。
