モダン・ソフトウェアエンジニアリングのエッセンス

モダン・ソフトウェアエンジニアリング のエッセンス 2020年7月21日 ワイクル株式会社 角 征典（@kdmsnr）

2

Martin Fowler says（2010） • 厳格すぎて、価値が限られる • Alistair Cockburnが、ソフトウェア開発では人が中心的な要 素であり、人は本質的に非線形的で予測不能なものであると 説明してくれた https://bliki-ja.github.io/Semat/ 3

• https://bliki-ja.github.io/Semat/

Martin Fowler says（2010） • 厳格すぎて、価値が限られる • Alistair Cockburnが、ソフトウェア開発では人が中心的な要 素であり、人は本質的に非線形的で予測不能なものであると 説明してくれた • 人が扱いやすい計算式で記述できる予測可能なエージェントに なれば可能性はあるかもしれない https://bliki-ja.github.io/Semat/ 4

• https://bliki-ja.github.io/Semat/

7.2 理論の使用 • 理論とは？ • i) 現象を「記述」するもの • ii)現象を「予測」するもの • 「予測」するためには「記述」が必要であり、 「記述」するためには「言語」が必要である 5

7.2 理論の使用 • 理論とは？ • i) 現象を「記述」するもの • ii)現象を「予測」するもの • 「予測」するためには「記述」が必要であり、 「記述」するためには「言語」が必要である • 将来を予測したいが、まずはそのための言語が必要 6

Essenceのアーキテクチャ 7

Essenceのアーキテクチャ ① ② ③ 8

①エッセンシャル化された手法 9

ざっくりと「手法」とは何か • 「ソフトウェアを開発・維持するときに必要となるすべてのことに対して、 アドバイスを提供するもの」 • 「すべてのこと」はウォーターフォール手法が理解しやすい • うまくいかないことを除けば（！）そんなに悪くはない • 現実的には、アジャイルを含む反復的手法でやるべき • とはいえ、自己組織化が前提だと「すべてのこと」を見逃しやすい • 全体の見取り図を別途用意しておくとよい 10

手法の問題は大きく2つある • 乱立による足の引っ張り合い（手法の戦争） • 似たようなことをやってるのに名前が違う • 部品（プラクティス）がモジュール化されていたら再利用可能なのに！ • 手法の作者が決める絶対的なルールがある（手法の監獄） • 「👺 そんなものでは止めを刺せん」 • 書籍では触れていないが、認定資格制度の問題もありそう💦 11

「ソフトウェアが世界を食べる」時代（2011） ソフトウェアの手法だけを語ってる場合じゃねえ!! 12

食後の手法はこうありたい • 既製品を使うのではなく、状況にあわせて自分たちで手法を作りたい • ただし、ゼロから手法を作るのは大変すぎる💦 • 既存のプラクティスを「合成」すればいい（3.2「手法はプラクティスの合成） • それに、自分たちで手法を作っても誰も理解してくれない💦 • 「記述する言語」を統一して誰でも読めるようにすればいい • プロダクトのUMLに対するプロセスのEssenceという位置づけっぽい？ （UMLと同じくらいの希望と絶望を持つといいと思う……） 13

②エッセンシャル化された プラクティス 14

プラクティスとは何か • 手法を構成する具体的な作業方法のこと • 手法と違って「こんなんなんぼあってもいいですからね 🥣」 • 3つの領域に影響を与える（アルファの状態を変化させる）： • 顧客 • ソリューション（技術） • 活動（プロジェクト） 15

プラクティスを記述する言語 16

プラクティスを記述する言語 使うべき「もの」 （扱うのほうがよかった？） やるべき「こと」 必要な「能力」 17

「ペアプログラミング」を記述してみた 18

「ペアプログラミング」を記述してみた 使うべき「もの」 必要な「能力」 やるべき「こと」 19

素直な感想 • これって、本当にわかりやすい……のか？ 🤔 • UMLと同じくらいの希望と絶望を持つといいと思う（2回目） • もうちょっと説明を続けます 20

やるべき「こと」がプラクティスの中心 やるべき「こと」 21

「こと」の詳細をカードに記述する 22

「こと」は「もの」の状態を変える 23

用意された7種類のアルファ（もの） 24

アルファはカード化されている 25

アルファは複数の状態を持つ 26

素直な感想 • プラクティスによって状態を変化させるのはわかりやすい • 状態などをカードにするのはいいアイデアだと思う！🎴 • 途中からEssenceの説明に踏み込んでしまってた……。 27

③ Essence （カーネル + 言語） 28

Essenceとは？ 「手法の基盤」となるもの Essence カーネル 言語 29

Essence言語 30

Essenceカーネル ここがカーネル ・もの ・こと こいつらは具体的すぎるので ・能力 カーネルに入っていない （表現型だけ定義されている） 31

カーネルの アルファ（もの） 32

カーネルのアルファ（もの） 33

アルファは複数の状態を持つ 34

状態を進捗させるために考える💭 🗣「ステークホルダーを巻き込むためのミーティングを開催してみる？」 35

「状態を追え」ゲーム 36

「状態を追え」ゲーム 37

状態の進捗の可視化 38

（補足）日本語のアルファ状態カードつくりました https://github.com/kdmsnr/essence-alpha-state-cards-ja 39

• https://github.com/kdmsnr/essence-alpha-state-cards-ja

カーネルの アクティビティスペース（こと） 40

アクティビティスペース（こと） 正確にはプラクティスのアクティビティ（こと）を入れる「ことの入れ物」 41

プラクティスが足りないところがわかる 42

（補足）カーネルでは足りないとき • カーネルにあるアルファ（もの）やアクティビティスペース（こ と）では不十分なことがある • プラクティスの作成時にカーネルを継承して拡張すればいい • e.g.［要求］を継承した［プロダクトバックログアイテム］ • e.g.［作業を準備する］を継承した［チームのキックオフ］ 43

スクラムとEssence 44

スクラムの全体像 45

Essence言語にマッピング 46

Essence言語で表現したもの 47

素直な感想 • えっ、めっちゃわかりにくくなって……ない？ 🤔 • UMLと同じくらいの希望と絶望を持つといいと思う（3回目） • もうちょっと説明を続けます 48

カード化されたのは👍 49

状態が明示的になったのは👍 50

スクラムだけじゃ不十分なこともわかる👍 （［活動］領域だけじゃない気もするけど、不十分なのは同意） 51

スクラムの58%は失敗してる😵 • Essenceのカードを使えば、どこで失敗しているかがわかる • 次の「状態」に進むためには何をすべきか？ を考えられる https://pages.services/ss.ivarjacobson.com/essential-scrum 52

• https://pages.services/ss.ivarjacobson.com/essential-scrum

（補足）Agile Essentials もある https://practicelibrary.ivarjacobson.com/ 53

• https://practicelibrary.ivarjacobson.com/

全体的な印象 • アジャイル開発の「楽しさ」は大幅ダウンしてる気がするね😞 • 「すでに流行ってる」そうだが、全然そんな気がしない...😞 • あれほど避けていた「手法の監獄」感が出てない！？😞 • UMLと同じくらいの希望と絶望を持つといいと思う（4回目）😞 • でも、開発がうまくいってないときに使うのはよさそう🙂 • 「手法の基盤」となる安定感はなんとなく感じられる🙂 • ヤコブソンが元気そうでよかったです🙂 54

開発がうまくいってない方は是非どうぞ！ 55