たまたま代休を取っていた5/29に発売だよ〜という事に気付いて嬉しかったので、積ん読消化順を差し込んで読んだ。
書籍のタイトルと翻訳者の名前を見て即買いした次第。
- 作者:Ivar Jacobson,Harold “Bud ”Lawson,Pan-Wei Ng,Paul E. McMahon,Michael Goedicke
- 発売日: 2020/05/29
- メディア: Kindle版
どんな本でしたか？
(本当にタイトルしか見てないので、内容知らずに買ったなぁあ・・・)
端的に言えば「開発やプロジェクト運営に関する1番いいプラクティスください！！って思うけど、どうやって捉えればいいと思う？」みたいなやつ。
本書は「Essence」という言語の紹介と実践を示した本という事になる。
ここで「言語」と言ってイメージしてほしいのは、UMLのような意味でのLnaguageだ。
Essenceは、次のような理解に基づいた力を提供する。
- ソフトウェアエンジニアリングは広範な領域に及ぶ取り組みで、各領域の1つもしくは複数にまたがる大小様々なプラクティスが存在している
- これらのプラクティスをどう採用し、どう評価していけばよいか？
- もしソフトウェアエンジニアリングの各領域と相互関連を俯瞰してみることが出来、各プラクティスをそのマップ上に並べることが出来、共通の言語で分析や説明をすることが出来れば、それらは比較検討が可能になる
例えば、「スクラム」はアジャイル開発におけるプラクティスである。
「スクラムとはなにか」について、Essence言語にもとづいて説明することが出来る。
(Kernel and Language for Software Engineering Methods (Essence), v1.2 P226)
これはAbout the Essence Specification Version 1.2の「Essence/1.2/PDF」から引用した図だ。
これは、スクラムが(ソフトウェアエンジニアリングを構成するようそのうち)「要求・作業・チーム・ソフトウェア・システム」に関わる = 問題解決に役立つことを視覚的に表している。
(同 P272)
「要求」に関する活動を行うと、成果物として「プロダクトバックログ」を期待されることを表す。
このように、「どの領域における問題に対するアプローチなのか」を俯瞰可能にすることが力の1つだと考えられる。
もし「要求の吸い出しに問題が生じている」と考えるなら、 一覧化したプラクティスの中からRequirementsに対して関連しているプラクティスを検討すれば良い。
前書きでも終章でもないが、個人的にはこの一節にEssence(と本書)の魅力が詰まっているように感じた。
我々のゴールは、手法やプラクティスの議論を習慣にして、実務家を楽にすることである。つまり、手法やプラクティスの検討に悩んだり、ムダに時間を費やしたりすることを減らしたいのである。高品質なソフトウェアを生み出すために、自分たちの得意なことに集中してもらいたい。
Ivar Jacobson,Harold Bud Lawson,Pan-Wei Ng,Paul E. McMahon,Michael Goedicke. モダン・ソフトウェアエンジニアリング (Japanese Edition) (Kindle の位置No.5802-5804). Kindle 版.
こんな人に良いんじゃない？
チーム開発をやっていて、「もっと上手くいきそうなのに何が足りないんだろ〜」という気持ちがある人にとっては、活動をとりまく所々の問題について構造的に分析するためのヒントになるかも。
「こういうプラクティスと前使ってたプラクティスと、どっちが良かったんだろ〜」と考えたい人にとっては、局所的な方法論について俯瞰して考えてみるヒントになるかも。
一貫してEssenceについての書籍だが、理論や背景を説明する部分と、(架空の)事例を通じてPJやチームの状況に対してどのようにEssenceの考え方を適用していくか？という紹介がバランス良く織り交ぜられていると感じた。
また、各章の最初と最後に「今から話すこと」「この章を読んで理解したこと・出来るようになったこと」が箇条書きでまとめられており、重要な点をリマインドしてくれるのも特徴だ。
読後の感想
正直、「今の自分が読むにはちょっとレベルが足りなかった」ような感じがした。
例えて言うなら、RPGで1個飛ばして次の街に付いてしまったような感覚。倒せなくもないけどギリギリすぎるジムリーダー戦をやるやつ・・・
ただし、そうはいっても「全く理解できなかった」「無駄だった」という話では断じてない。
自分はプロジェクトマネジメント的な立場に立ったり*1という経験がなく、主体的に「スクラムっぽくやろうか？」「今回はDDDを使って進めようか？」といった選択をしたことがない。そのため、本書で描かれているような話に対して実感を持って「なるほど！あの時に苦しんだ点は、こういう考えで打破できたかも知れない！！」というような感動を得るには至らなかった・・・というような意味で、「まだ早かった」と感じるのだ。
逆に、以前「フレームワークとしてアジャイルのプラクティスを採用したいわけではないが、アジャイルのもたらす価値について知り、それをチーム開発に活かしたい」と悩んでいた同僚(では無いけど！偉い人！)などは、何か自分とは違った観点で得るものがあるかも知れない。
他方で、手法やプラクティスといったものを「メタ」視点で眺める力を"先に手に入れた" というのは、今後の役に立ちそうでワクワクもしている。そういう意味では、「今読んで良かった」。
実際、「Essenceのレンズを通してプラクティスを見ることで、新しいプラクティスを読み解きやすくなる」というのはEssenceの目標の1つでもあるのだから。
何よりもまず、ソフトウェアエンジニアリングの手法とプラクティスの適用方法およびスコープを理解するための共通基盤が手に入る。これはあなたのキャリアのなかで大きなメリットになる。新しいプラクティスや手法が登場しても、自身の知識体系のなかに簡単に組み込むことができるからだ。 (中略) 簡単に言えば、開発者は内省のできる実践者となり、商用フレームワークの外側で、自らの作業方法について考えられるようになる。
Ivar Jacobson,Harold Bud Lawson,Pan-Wei Ng,Paul E. McMahon,Michael Goedicke. モダン・ソフトウェアエンジニアリング (Japanese Edition) (Kindle の位置No.2241-2248). Kindle 版.
あるいは
一般的なプラクティスがエッセンシャル化され、学生やプロたちがEssenceを理解すれば、こうしたプラクティスをすばやく学習できるようになる。
Ivar Jacobson,Harold Bud Lawson,Pan-Wei Ng,Paul E. McMahon,Michael Goedicke. モダン・ソフトウェアエンジニアリング (Japanese Edition) (Kindle の位置No.3319-3322). Kindle 版.
内容に関するメモ
以下、気になった箇所やポイントだと思った箇所についてまとめていく
カーネル
Essenceは「ソフトウェアエンジニアリングの本質的な事」に注目して作成された言語で、「あらゆる種類のソフトウェアシステム開発で見られる要素」を取り扱っている。
言い換えると、「どんなプラクティスであっても、必ず共通の言語に結びつけて表現できる」というアイディアだ。
この「(最小限の)共通基盤」のことを「カーネル」と読んでいる。
カーネルは3つの領域を基本構成としていて、それが「顧客」「ソリューション」「活動領域」だ。
また、カーネルの要素には「アルファ」「アクティビティスペース」「コンピテンシー」「パターン」の4つの種類がある。
カーネルの要素には4つの種類ある。
1 必要不可欠な使うべきもの：アルファ
2 必要不可欠なやるべきこと：アクティビティスペース
3 必要不可欠な能力：コンピテンシー
4 必要不可欠な要素の配置：パターンIvar Jacobson,Harold Bud Lawson,Pan-Wei Ng,Paul E. McMahon,Michael Goedicke. モダン・ソフトウェアエンジニアリング (Japanese Edition) (Kindle の位置No.1798-1801). Kindle 版.
アルファ
アルファは「必要不可欠で使うべきもの」と説明されているが、これが中々ピンとこなくて前半苦しんだ・・・
- 顧客領域
- 機会
- ステークホルダー
- ソリューション領域
- 要求
- ソフトウェアシステム
- 活動領域
- 作業
- チーム
- 作業方法
が、カーネルアルファとして示されている。
「カーネル」に含まれないアルファというのもあり、プラクティスに紐づくアルファがそれだ。
例えばスクラムで言えば「スプリント」は「作業」の下位のアルファとなる。
アルファは「状態」を持っており、変化を理解したり追跡したいもの。
例えば「要求」アルファの状態として、「企画されている」「対応済みである」といったものがある。「ソフトウェアシステム」については「デモ可能である」「運用可能である」、「作業」については「準備できた」「完了した」、「作業方法」については「基盤を作った」「利用中である」「順調である」・・・というとイメージが湧きやすいのでは。
本書を読みながら、ソフトウェアに関する活動は、この「アルファ」を最終状態まで持っていくことである〜と言えるのではないかな？という気がした。 言い換えると、あらゆるプラクティスは「カーネルとなるアルファの状態を、どのように進捗させていくか」というものでは・・？
コンピテンシー
これは「プラクティスを導入する時に必要な能力」の事で、例えば「リーダーシップ」「開発」などといった感じだ。
コンピテンシーにはレベル分けも備えている。例えば「開発」コンピテンシーであれば「指示があれば使える」だとか「導入について判断し実施できる」という場合では、両者は同じ「開発」についてのコンピテンシーでも同一のものでもないと言えるだろう。
プラクティスに対してコンピテンシーが紐付いている事で、「このプラクティスを採用するに必要なコンピテンシー」といったものが明らかにしやすくなったりする。
それを見ながら、開発やチームや作業方法などなどのアルファを推し進めるために、必要な部分を補っていくことが求められるだろう。
パターン
(追記) この記事を書いた当初「パターン」がいまいちピンと来てなかったのだが、呟いてみたら翻訳者の角さんからメンションを頂いた。
たとえば必要な「コンピテンシー」をいちいち列挙すると大変なので、「スクラムマスター」みたいな役割のパターンとして定義する、みたいな。言ってしまえば、ディレクトリーのような感じですかね。
— 角 征典／Masanori Kado (@kdmsnr) 2020年5月31日
パターン、本書においては例えば「役割パターン」「学生ペア」とか「チェックポイント」というような例が紹介されている。
「典型的な問題に対する汎用的なソリューションのことである」という記述になっているが、この「(チームメンバーに対する)役割」や「(アルファの状態に対する)チェックポイント」など、一見全く違うような事柄に対して適用可能な同一の概念・・・？と思い混乱していた所だ。
が、「いちいち列挙すると大変(なのでパターンを上手く使うと便利)」という視点をもらったことで、理解が出来たように思う。
要するに、言葉のとおり「パターン」なのだ。
「日常生活の例におけるパターンの例」として「教室には教師がいて、机がいくつもあって生徒が椅子に座る」「これは講義の効率のためのデザインだ」のような話が載っていたが、この例えに引っ張られすぎた麺もあるのかもな・・・
個人的には、「並び順を考慮してデザインした配置」のような概念より、「適用できるものをセットにして組み合わせたミックスイン」みたいな感じなのかな？と思うところ。
例えば「役割パターン」について「コーダー」には「ソレに必要なコンピテンシー」が列挙されていて、「コーダーのパターン」というだけで「その言語での開発ができる」「テストを書くことが出来る」のようなコンピテンシーを兼ね備えることを指し示している。
Better Scrum Through Essence | Ivar Jacobson International を参照すると、スクラムにおける「プロダクトオーナー」「クロスファンクショナルチーム」「自己組織化」などはパターンとして扱われている。
アクティビティスペース、アクティビティ
言葉通りの意味で「アクティビティ」という概念が登場するが、アクティビティはカーネルに含まれていない。
「やるべきこと」がアクティビティではなく「アクティビティスペース」なのは、アクティビティの場合汎化できない = 「カーネル」と呼べないから。
アクティビティは、プラクティスによってもたらされる。
アクティビティスペースの中にいくつかのアクティビティを乗せることになる。
あらゆる開発活動において、いくつものアクティビティを実行することになる。たとえば、プロダクトオーナーとユーザーストーリーに合意する、顧客の代表者にシステムをデモする、作業を見積もるなどがある。Essenceでは、アクティビティを定義していない（要求の獲得や伝達の方法はチームによって大きく異なるからだ）。だが、アクティビティスペースと呼ばれるものをいくつか定義している。アクティビティスペースとは、カーネルの上にあり、アクティビティを入れる汎用的な（つまり手法に依存しない）プレースホルダーである。
Ivar Jacobson,Harold Bud Lawson,Pan-Wei Ng,Paul E. McMahon,Michael Goedicke. モダン・ソフトウェアエンジニアリング (Japanese Edition) (Kindle の位置No.1863-1868). Kindle 版.
アクティビティスペースについて、以下の図が紹介されている
Ivar Jacobson,Harold Bud Lawson,Pan-Wei Ng,Paul E. McMahon,Michael Goedicke. モダン・ソフトウェアエンジニアリング (Japanese Edition) (Kindle の位置No.1874). Kindle 版.
ここに書かれているテキストを眺めてみると、「どんなプラクティスであるかに関わらず重要である活動の種類」であることがイメージしやすい。
これがまさに、本書に書かれていた「カーネルは皆さんの作業を構造化するのに役立つ」の感覚のように思う。
プログラミングとソフトウェアエンジニアリング
プログラミングといえば「コードを書く」ような具体的な作業だが、ソフトウェアエンジニアリングといえば(先に「アルファ」やそれを包む領域として示したような)広範な領域に関わる総合的な活動である、というような話で分かりやすかった。
↓のツイートは、この「エンジニアリング」について書かれている箇所を読んでいた時のメモだった。
本章を学習すると、以下のことができるようになっているだろう。
(中略)
チームワークがソフトウェアエンジニアリングのダイナミクスにどのように影響するかを理解できる（例：コードの理解しやすさの重要性）。
(中略)
ピープルマネジメントがソフトウェアエンジニアリングとどのように融合し、なぜそれが検討すべき重要なことなのかを理解できる。Ivar Jacobson,Harold Bud Lawson,Pan-Wei Ng,Paul E. McMahon,Michael Goedicke. モダン・ソフトウェアエンジニアリング (Japanese Edition) (Kindle の位置No.897-899). Kindle 版.
さっき本読みながらメモってた感想と同じような事を書いてるツイートが流れてきたから思わずRTしちゃった pic.twitter.com/zN1tFASYe0
— 今日も誰かのにちようび(おいしい鮭親子丼) (@o0h_) 2020年5月29日
プラクティスと手法
プラクティスは「特定の目的を念頭に置きながら何かを実施するための繰り返し可能なアプローチ」と説明されている。
繰り返し可能 = 再現可能性のある、となれば「形式知として説明されている」という話になる。
「手法はプラクティスの合成」というのが、Essenceのとる立場だ。
例えば「マイクロサービス」というのはプラクティスであるが、それは「ステークホルダー」アルファについて直接的に何かを満足する取り組みではない。テスト駆動開発でも継続的インテグレーションでも同様。逆に、ユーザーストーリーを分析するプラクティスについては、「ソフトウェアシステム」についてガイドをするものではない。
あるいは、「スクラム」はプラクティスの1つであるが、それ自体も「デイリースタンドアップ」「プロダクトバックログ」といった下位のプラクティスの合成であるとも言われている。ただし、それが全領域を満たしているかというと、そうではない。要求分析と言った活動までは指示していない。(POのロールの定義とかはあると思うけれど)
つまり、総合的にソフトウェアにまつわる活動を完成させるには、「各領域を満たすプラクティス」を選択して採用する必要がある。
同じ領域に対して複数のプラクティスが組み込まれることもあり、「ペアプログラミング」と「TDD」などは共に「作業方法」に関するプラクティスと考えられるはず。
そして、自身の組織にあった手法をみつけるために、プラクティスを選択したり磨いたりしなければならない。
チームとプラクティスの採用
プラクティスを採用する時、チームは1個の活動主体としてプラクティスを活用できる必要がある。
その際に、「どういう形式でプラクティスを導入するか」という内容にも触れていて、なるほど〜そうだよな〜と思った次第。
曰く、「メンバーの能力の高い/低い」と「メンバー同士の背景の共通/相違」がパラメータとしてあり、「明示的/暗示的」「コーチングやトレーニングの実施/実施しない」という選択があるとのこと。
「プラクティスを明示的にする」とは「実際に我々のチームがどのやり方を使うか」を示すことであり、「コーチングをする」とは「プラクティスについての理解を深めるための知識を提供する」こと。
背景が共通していなければプラクティスを明示する必要があるし、能力が高くなければまずトレーニングが必要となる。
背景が共通していてかつメンバーの能力が高ければ、恐らく「良い感じにやりましょ〜」で事足りる。逆に、背景の相違が大きい(新しい人が入ってきた場合には大きくなりがち)場合には、どういう風にやっているかは示す必要があるだろう。
もし「Essentceついて理解がある」メンバーだったり、「プラクティスがエッセンシャル化されている*2」のであれば、お互いの知識の交換は手間が少なくなりそうかも。
Essenceの獲得によって実現できるマインドセット
前提としてソフトウェアを取り巻く環境は急激に高度化・複雑化しているという状況があり、それによって「変わらないもの」「変わるもの」の見極めはより重要度を増して言っているように感じる。
終章となる第23章「そして未来へ」では、「意識すべきマインドセットの変化」があると説明する。
- 誰かが手法を選択する → チーム全体で手法を所有する
- 手法をしっかり説明(記述)する → 手法を使ってみる事に集中する
- 「ベスト」な手法を取り入れる → 万能な手法は存在しない(自身らの活動に応じて、手法を進化させ続ける)
ひどく真っ当で、とてもアジャイルな考え方に感じた。
ただ、この「振り返ってみる」「新しいことを知る(知りやすくしておく)」には、やはり共通言語の存在が必要になりそう。Essenceはそういう地平を目指している、というものらしい。
賢く反省をしつつ新しいことも面白がってやっていかないとダメねぇ。
プラクティスライブラリ
実際に利用したプラクティスについて、エッセンシャル化し、組織の共通資産とする必要があると説明されている。
さて、自分は、てっきり「巷で有名になっているプラクティス」についてはインターネット上にライブラリがあると強く期待していた・・・それがあると正に「分厚い専門書を読まなくても、プラクティスの概要を掴むことが出来る」からだ。
読了した後にワクワクしながらSoftware engineering essentialized - software-engineering-essentialized.com を開いてみたのだけど、そうかぁ〜そういうのがあるわけではないのか〜・・・どっかにあるのかなぁ。。
その点が少なからずがっかりしてしまったかな、期待しすぎた！
まとめ
コレは必ず将来どこかで思い出して読み直す一冊だな、という気がした！
特に自分の場合、問題を構造化することでその理解が捗りやすくなる〜という感覚が強いので、その「構造化」のための助けとなるツールと出会えた事は嬉しく感じる。
積ん読行列に「ドメイン駆動設計入門」と「みんなでアジャイル」が並んでいますので、読みたいですね・・・・
あとDDD本を読んでいることもあり、ユースケース駆動開発の 思春期 になりつつあるかも知れん
セミナーやるみたい。聞いてみたいかもな。全てオンライン開催・参加無料 👀
第3回 モダン・ソフトウェアエンジニアリングのエッセンス
日時: 2020年7月21日(火) 19:00-21:00
主催: スマートエスイー
講演者（予定）: Ivar Jacobson（ビデオ）、角征典、平鍋健児、小林浩、宮田一雄、島田さつき、鷲崎弘宜
プログラム・参加申込: （近日掲載予定）機械学習工学やIoT工学など、DX時代を迎えるにあたり様々な手法やプラクティスが現れる今こそ、変わらない本質を捉えて、ソフトウェアエンジニアリングに必要な変革を自ら組み立てていく取り組みが求められます。本セミナーでは、UMLの父であるIvar Jacobson氏ら著『モダン・ソフトウェアエンジニアリング』をベースにOMG標準 Essenceを解説し、これからのソフトウェアエンジニアリングを展望します。Essenceは、国際的な運動SEMAT（Software Engineering Method and Theory）により、ソフトウェア開発において重要な概念や状態を整理した枠組みであり、方法論の組み合わせや新たな方法論の構築の基盤を与えます。
