著 : Ivar Jacobson、Harold “Bud” Lawson、Pan-Wei Ng、Paul E. McMahon、Michael Goedicke

訳 : 角征典

監修 : 鷲崎弘宣

Amazon : https://amzn.to/3QRFaBO

主に、国際的な共通基盤 Essence について書かれた書籍

『モダン・ソフトウェアエンジニアリング』 という書籍名ではあるが、ソフトウェアエンジニアリング全体というよりは、主に開発におけるプラクティスの言語化を扱っている

書籍名はちょっと誇張が過ぎると思う

とはいえ、プラクティスや手法について言語化するとか、そういう思想は非常に良いと思うので、学ぶことはあった

Ivar Jacobson International のプラクティスライブラリ : https://practicelibrary.ivarjacobson.com/start

プログラミング、ソフトウェア開発、ソフトウェアエンジニアリング

手法とは、ソフトウェアを開発・維持するときに必要となるすべてのことに対してアドバイスを提供するもの

ミニ手法 = プラクティス

世の中には無数の手法が存在するが、それらは小さなプラクティスの合成にすぎない

プラクティスは再利用可能

手法に関してパラダイムシフトが起こると過去との断絶が起こる

プラクティスについても再利用がなされず車輪の再発明が多い

各チームや組織が独自の手法を構築するための基盤となるソフトウェアエンジニアリングの共通基盤 (カーネル) の構築を目指す

2014 年に Object Management Group (OMG) によって Essence が標準化

Essence の話

プラクティスのエッセンシャル化の方法

1. 要素を特定する

2. 要素間の関連と各要素の概要を下書きする

3. 詳細を追記していく

ソフトウェアエンジニアリングの理論

合意された統一的な理論はない

「Where's the Theory for Software Engineering?」 という論文

チェックポイントを設定する

どういうチェックポイント？ そのチェックポイントで検査するアルファはどれか？ 通過条件となるアルファの状態は？

例 : 要求項目、欠陥、課題

Essence を使って反復型開発の手法を確立する

継続的な PDCA

各アルファは各領域の理論に基づく

チームについてはタックマンモデル

ステークホルダーについてはステークホルダーエンゲージメントの各種業績

アルファは個別のものだが、独立していない (同じ開発プロセスを異なる視点で見ている) ので、ウェーブ上に進む

ソフトウェア開発をするにはスクラムだけでは不十分

適切な要求を考え、それらを設計、実装、テストするプラクティスが必要

要求プラクティスとしてユーザーストーリーやユースケース

ソフトウェアシステムを進化させるプラクティスとしてマイクロサービス

プラクティスを適用すると、具体的な監視項目 (どのアルファ・サブアルファを監視するか？) が明確になる

ユースケース、ユースケース駆動開発

Unified Modeling Language (UML) での表記

ここでの大規模は 30 人以上が関与する開発 (30 人に強い意味があるわけではない)

成功の秘訣は、サブシステムとチームの依存関係を減らすこと

過去にはコンピュータが高価だったため、高速なプロトタイピングに適した環境ではなかった → CMMI や RUP

現在はコンピュータがより安価に → DAD、LeSS、SAFe などの大規模アジャイル開発手法が登場

プラクティスアーキテクチャからメソッドアーキテクチャ (手法のアーキテクチャ) へ

組織でのプラクティスライブラリの構築

文化は重要

「文化は戦略を食らう」 という格言もある (ピーター・F・ドラッカーの言葉)

#書籍 #文献