“手法の戦争”と“手法の監獄”から抜け出す　ソフトウェア開発の本質を捉えるEssenceとは

自己紹介とこのセッションの目的

司会者：「モダン・ソフトウェアエンジニアリングのエッセンス」と題しまして、まさしくその『モダン・ソフトウェアエンジニアリング』という書籍を角さんが翻訳されまして、その内容を角さんご自身から、またその使用感ですとか、さまざまなところを含めて解説、ご紹介いただければと思います。それではよろしくお願いします。

角征典（ワイクル）氏：よろしくお願いします。私Jacobsonの動画（※このセッションの直前にJacobsonの動画が映された）を初めて見たので、だいぶ内容的にはかぶっているところもあるかと思いますけれども、日本語で簡単に説明したいと思います。

自己紹介です。先ほどお話ししたように、今回の書籍を翻訳いたしました。時間もないですしスライドがけっこう多いのでプロフィールなど省略しているので、検索していただければと思います。

今日は、このEssence をみなさんに知っていただくのが目的ではあるのですが、と同時に本も読んでいただきたいなと思っていて。内容をしゃべりすぎると「もう本買わなくていいな」となってしまいますし、なにも伝えないと「何だそれ？」ってなってしまうので、さじ加減が難しいんですけど、本当にエッセンス、本質的な部分だけちょっとかいつまんで説明できればと思っています。

2010年のMartin Fowler氏の言葉

私は昔から、リファクタリングとかアナリシスパターンとかで有名なMartin Fowlerという人のブログをずっと翻訳していたんですけれども、2010年に彼がこういう記事を書いていました。JacobsonがやっているSEMATについて批判的な記事を書いています。

あまりに厳格すぎて価値が限られるし、あんまりよくないんじゃないかと。もちろんMartin Fowlerはアジャイルを推しているので、アジャイルとすごく対立する概念じゃないかということで記事が書かれています。

中でもAlistair Cockburn、彼もアジャイルを推進している1人なんですけれども、彼が言うには「ソフトウェア開発では人が中心的な要素であり、人は本質的に非線形的で予測不可能なものである」と。

Alistair Cockburnはすごく批判的なことを言っているので、Martin Fowlerも「すごくそれに賛同している」みたいなことを書いています。

私もこれを読んで「まぁまぁ、そうかな」と当時は納得しまして。最後にMartin Fowlerはこういうことを言っています。「人が扱いやすい計算式で記述できる予測可能なエージェントになれば可能性はあるかもしれない」と。

先ほどもJacobsonからありましたけども、ソフトウェアエンジニアリングをやろうとしている人たちは、クラフトマンシップに寄りすぎているとあんまりよくないので、もうちょっとちゃんとできるところはエンジニアリング化したほうがいいよというふうに言っているんですけれども、アジャイルの人たちはクラフトマンシップをすごく推している。ここにちょっと対立があります。

理論の使用

なんですけれど、そのエンジニアリングを推進したがる人たちというのは、やっぱりJacobsonの講演でもあったように、理論を作ろうとしているんですね。この本の中でも7章のセクション2のところに「理論の使用」ということでまるまる説明が載っているんですけれども、ソフトウェアエンジニアリングをすごく理論化したいとずっとずっと思っていると。

じゃあ理論というものはどういうものかというと、「ある特定の現象を記述するものでなければいけない。さらには今後発生する現象を予測するものでなければいけない」というふうに言っています。

先ほどMartin Fowlerが「人は予測できないんだからそんなの無理だろう」というふうに批判してはいるんですけれども、将来的には予測したらいいなとは思っているのですが、Jacobson的には、予測するためには記述が必要で、記述するためには言語が必要で、今の段階ではとりあえず言語だけ作ろうというのがJacobsonをはじめとしたEssenceと主張になっています。

なので、未来が予測できるうんぬんというのはもっと先の話で、とりあえず言語化だけしましょうというのがEssenceの肝になっているかと思います。

Essenceのアーキテクチャ

Essenceのアーキテクチャというのが4段階、4階層で成り立っています。上から、手法ですね、先ほど言っていた話でいうとメソッドとかメソドロジーと呼ばれるもの。その次がプラクティスですね。そしてカーネル、言語と続くわけですけれども、大きく3つに分けられると考えてください。

手法とプラクティスはそれぞれ独立はしているんですけれども、Essenceといったときには下のカーネルと言語を合わせてEssenceというふうに呼びますので、アーキテクチャ的には基本的に3階層でできています。

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

一つずつ、上のほうから説明していきますね。最初は手法、あるいはメソッド、メソドロジー、方法論と呼ばれるものになります。

ざっくり手法とは何かの定義がこの本の中には載っているんですけれども、ちょっと読み上げますと、「ソフトウェアを開発・維持する時に必要となるすべてのことに対してアドバイスを提供するもの」というのをメソッドと呼んでいます。

そのためにはすべてのことを理解できなきゃいけないわけですけれども、そのすべての範囲というのを把握するためには、今で言うと、ウォータフォール手法というのが一番理解しやすいものであるとされています。実際に分析して、設計して、実装して、テストして、運用してみたいなものがちゃんと定義されている。

なんですけど、ウォーターフォールはうまくいかないことがもう証明されているので、うまくいかないことさえ除けば、ソフトウェアエンジニアリングのベースとしてウォーターフォールは別にそんなに悪いものではないと。ただし、実践的には反復的手法でやるしかないというふうに、もう明らかになっているので、アジャイルだけではないんですけれども、アジャイルを含む反復的手法でやるようにしてくださいということが述べられています。

なんですけど、アジャイルをご存じの方はわかるかと思うんですけど、あくまでも現場のクラフトマンシップに頼って自己組織化してうまくやりましょうというようなメソッドになっているので、ウォーターフォールに見られるような全体というのがなかなかわかりにくいというか、「すべてのこと」を見逃しやすいという欠点があります。

なので、アジャイルでやることはぜんぜんいいんですけれども、それとは別に全体の見取り図を用意しておいたほうがいいんじゃないかというふうな主張をEssenceのほうではされています。

手法の戦争と手法の監獄

Jacobsonの動画にもあったので繰り返しになってしまうんですけれども、手法の問題は大きく2つありまして、1つが「手法の戦争」と呼ばれるものです。

最近で言うと、大規模なアジャイル開発手法みたいのがけっこうたくさん出てきているんですけれども、そういったものに代表されるように、いろいろな手法が乱立しているのに、「よく見れば似たようなことをやっているんじゃないの？」と。ただし名前が違っているので、AからBに手法を切り替えるとか、あるいはBから何かいいところをもってくるようなことがうまくできないような状況になっていると。

もっとその構成する部品、ここではプラクティスと呼びますけれども、プラクティスがモジュール化されていたり再利用可能になっていたらもっといいのになと。手法の戦争なんかないのになというのが1つ解決策として考えられています。

もう1つが、先ほどもありましたね、グルがいるという話です。手法の作者で絶対的なルールを決めて、それをちゃんと守っていないと「それは本当の〇〇手法ではないよ」みたいなことを言われて否定される。そのことを手法の監獄、prisonというふうに呼んでいます。

書籍では触れてはいないのですが、各種認定制度みたいなものもあると思うんですけれども、ああいうのもたぶんこの認定制度を通るためにはテストしなきゃいけないとかそういったものも考えられるので、あまり肯定的な印象はもっていないと思います。

ソフトウェアがソフトを食べる

2011年ですね。Martin Fowlerが記事を書いた翌年にけっこう有名な言葉が出てくるんですけれども、Marc Andreessenという人が「ソフトウェアが世界を食べている」と。「Software is Eating the World」というけっこう有名な記事を書きました。

現在もそうなんですけれども、ソフトウェアのエンジニアリングの中だけの手法を語っているような状況ではなくなってきていて、例えば医療だったり、あるいは教育だったり、鷲崎先生の言葉を借りるとDXとかIoTとか、いろいろな分野でソフトウェア＋αの部分で融合して新しいビジネスをやっていかなければいけないという時代に、ソフトウェアの中だけに閉じた手法の戦争とかをやっている場合じゃないと。これが問題意識の1つですね。

なので、世界を食べたあとのソフトウェアエンジニアリングの手法はこうあるべきというのを述べられています。先ほどもJacobsonの……本当かぶってしまってあれなんですけれども、既存のなにか手法を使うのではなくて、自由に自分たちの状況に合わせて手法をできれば作りたいと。これが、ソフトウェアが世界を食べたあとの手法のあり方になっています。

ただし、あらゆる現場でゼロから手法を作るというのはすごく大変なので、既存のプラクティスを合成するようにすればいいんじゃないかと。これは3章あたりに書いてあります。

もう1つが、仮に自分たちで手法を作れたとしても、メンバーとか会社の人とか、誰も理解してくれない可能性がある。それが、もう1つの問題点として考えられています。そのためには、話がちょっと元に戻りますけれども、記述する言語をちゃんと統一して誰でも読めるようにしておけばいいんじゃないかということが提唱されています。

ここまで読んでいただくと、UMLを知っている方、Jacobsonもその策定者の1人なわけですけれども、プロダクトあるいはコード、オブジェクト指向のコードを抽象化してUMLとして記述するのと同じような位置づけで、開発プロセスを記述するためのEssenceというふうに考えていただくと、Essenceのことがわかりやすくなるかなと思います。

UMLと聞くと賛否両論あって、現在ではそこまでUMLに対して希望をもっている方はいらっしゃらないかなと思うのですが、出てきた当初はけっこう希望をもって出てきたと思うんですよね。

Essenceもおそらく……まぁ、400年後とか先ほど言っていましたけれども、それなり使えるものにはなるとは思うのですが、あまり期待しすぎると絶望してしまうかなというのが個人的な印象で、ほどほどの立ち位置でEssenceを取り入れていくとよいのかなと思っています。

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

はい、2番目です。手法の次が2番目のプラクティスです。プラクティスに関しては、一応これも定義というかそれっぽいことが載っているんですけれども、手法を構成する部品ということです。具体的な作業手法のことになっています。

メソッドと違ってプラクティスはたくさんあってもいいというふうにEssenceの本の中ではされていて、これをバンバン作ってくださいと。現場で生まれてくるものなのでこういうのをたくさん作ってくださいというふうに言われています。

プラクティスが生まれることによって何のメリットがあるかというと、3つの領域に影響を与えるというふうにされています。

3つの領域というのは「顧客」と「ソリューション」……ここはテクノロジーのことを指します。そして最後は「活動」です。ちょっとこれが、言語が「endeavor」という単語で、何と訳すかちょっと迷ったんですけど、一応「活動」にしています。「プロジェクト」とだいたい同義だと思ってください。「プロジェクト活動」というふうに考えてください。

この3つの領域になんらかの影響を与えることがプラクティスに求められている効果になります。もうちょっと詳細に言うと、その3つの領域ごとに「アルファ」というのが用意されているんですけれども、そのアルファの状態を変化させることがプラクティスの役割になっています。

プラクティスは、こんなんなんぼあってもいいというふうにされているんですけれども、みんながわからないような記述で書かれていると困るので、そのための言語をEssenceのほうで用意しています。

大きく3つに分けられると考えてください。1つが「使うべき『もの』」というものですね。ちょっとこれ翻訳がまずかったかなと思っていて、実際は「扱うべき『もの』」のほうがよかったかもしれませんけど。まぁ「使うべき『もの』」。「もの」というふうに考えてください。これが青いところですね。

それから「やるべき『こと』」と「そのために必要な『能力』」。プラクティスというのはこの3つで大きく構成されているとされています。

もう1個「パターン」というのがあるんですけれども、パターンというのはある程度塊を1セットにしたものなので、ちょっと除外して考えてください。

例えば、エクストリームプログラミングで代表的なプラクティスとして、ペアプログラミングというのがあるんですけれども、これをEssenceの言語で記述するとこんな感じになりますというのが載っています。

先ほどの分類を当てはめてみると、「使うべき『もの』」というのは要求とかシステムとか、あるいは行動が対象としての「もの」というふうになります。「やるべき『こと』」というのがプログラミングなので、コードを記述することになります。「必要な『能力』」としては、開発能力とテスト、両方必要になると。

こんな感じで、あらゆるプラクティスをEssenceを使って記述することが可能になるんですよというのが、このEssenceで提唱されていることになります。

率直な感想なんですけれども、どうですかね。先ほどのペアプログラミングの図解を見て、あんまりわかりやすくなっていないような感じがしまして、個人的にはやはり、繰り返しになりますけど、UMLと同じぐらいの希望と絶望をもって接するぐらいがちょうどいいのかなと思っています。

説明をまだ続けますね。

記述したプラクティスがどのようなかたちになるかというと、こんな形になるのですが、中心的な存在はやはり「やるべき『こと』」ですね。プラクティスという「実践」という訳を当てはめられることからもわかるように、「やる『こと』」というのが中心的な存在になります。

「こと」を詳細にカード化する

もう1つEssenceの特徴なんですけれども、この「こと」を詳細化したものをカードにしているというのが、大きな役割になっています。「コードを記述する」というアクティビティの名前があって、概要があって、インプット、能力……コンピテンシーがあって。アウトプットがある。ペアプログラミングの実態って何かというと、カードを見ればその内容がわかるかたちになっています。

あともう1つ特徴的内容なのが、インプットとアウトプット。例えば「要求」のインプットがあって要求のアウトプットが出るわけですけれども、状態が変わっているんですね。「明確化されている」という状態から「対応済みである」という状態。コードを書くことによって「要求」がちゃんと実装されたというかたちになります。

プロジェクトに必要な7つの要素

その用意されている「もの」というのが、状態が変わる「もの」ですね。先ほど要求、真ん中にありますけれども、顧客とソリューションと活動の領域に分かれていて、どのプロジェクトでも必要となるもの、状態を変えなければいけない「もの」は7種類しかないというふうに定義されています。

もちろんほかに必要なものはあると思うんですけれども、あらゆるプロジェクトで必要なものとなるとこの7つしかないですよ。ということで、基本的にはここからスタートすることが推奨されています。

先ほど言ったようにカード化されているのもけっこう重要で、記述としては先ほどのこのようなかたちなんですけれども、詳細が全部カードに書かれています。一つひとつがアルファに状態をもっていて、例えば要求のカードですと6枚の状態カードがあるんですけれども、この状態を次から次に遷移していくようになにか新しいプラクティスを用意していくことになっています。

ここまでの感想なんですけど、プラクティスによってアルファの状態を変化させていって、だんだんプロジェクトを進捗させていくというのはすごくわかりやすい考え方だなと思いました。

あと状態をtangibleなカードにするということですね。昔から人間はカードゲームで遊ぶという慣習があるぐらいなので、カードにして扱いやすくするというのもすごくいいアイデアだと思っています。

（後半へつづく）