ソフトウェアが世界を食べたあと何が残るか　アジャイルでは残せない資産を残すためのEssence

ソフトウェア工学の懺悔

鷲崎弘宜氏（以下、鷲崎）：ありがとうございます。続きまして永和システムマネジメントの平鍋さんからポジション表明をよろしくお願いします。

平鍋健児氏（以下、平鍋）：僕は今アジャイルの世界で生きているので、ソフトウェア工学って何だったんだっけ？という話がしたくて（笑）。

アジャイルが今すごく流行っているというか、アジャイルは救世主になっているか？　角さんの言葉で言うと、ソフトウェアが世界を食べたあとっていうのはもうアジャイルしかないんじゃないかとも思っていた。このままで、ソフトウェア工学って生き残れるのかな？と思っています。

Jacobsonさんも含め、ソフトウェア工学のいろいろな大家いろいろながソフトウェア工学について懺悔をしているっていうシリーズが僕は大好きなんですけれども（笑）。いろいろな過去に正しいって主張されてきたことが、「いやいや、違うよ」っていうふうにですね。…違うじゃないな。何だろうな。フォーカスはそこじゃなかったっていうことをいろいろな人が言っています。

DeMarcoも「もうそのときは去った」みたいな言い方をしているんですよね。それから「フォーカスがずれていた」という話もしています。Youdonさんもずいぶん前に私が訳した『ソフトウェア工学で最も大切な10の考え方』で、いろいろなことがソフトウェア工学として生き残っているけれども、結局ピープルウェアっていうことがすごく強くて、いい人がいい環境で働いて、オリジナリティを出すチームの重要さについて言っています。これってソフトウェア工学の中で、なかなか語られていないことなんですね。指数曲線的に増大するのだって言ったのは間違いだった（笑）、というふうに言っていたり。

Beohmさんは、ソフトウェアを作るときのスイートスポット、つまり先読みをしてエンジニアリングをコーディングに入る前に先にたくさんやっておくというトレードオフについて話しています。先にやればやるほどコストは使うけれども、あとになって安いでしょっていう話がプロジェクトによってズレている、という指摘です。

世代を越えて知見や資産を蓄えるためのEssence

僕はJacobsonの擁護をしたくて、この場で話しますけれど、Essenceの前のSEAMATが出てきたときに、さっきも言ってましたけれども、言葉の流行が工学の一分野というよりファッション業界のようだと。これがやっぱり大きいんじゃないかなと思うんですよ。

僕はアジャイルが大好きだしやってもいる。短期的な、つまり1プロジェクト、1プロダクトあるいは1スタートアップを成功させるっていうときはたぶんアジャイル1択だと思うんです。でも産業界や、もう少し長いスパンで見て、ソフトウェア工学として残していくべきことが本当に残っているのか？　ということにはすごく懐疑的で、そのための1つのアイデアだなと僕は思っていますね。

僕も大好きなTom Gilbさんは、ソフトウェア工学の定義をWikipediaで見ると「systematicでdisciplinedなquantifiableなアプローチだと書いているんだけど、自分だったら“balanceされた価値のセットをbalanceされたステークホルダーにライフサイクルに渡って届ける”と書くだろう」って言っています。これがけっこう僕は好きです。

1プロジェクト1企業の価値を短いタームで出していくときと、僕らが作ってきた知見や、あるプロジェクトで得た知見をどのように企業の中、あるいは社会の中、あるいは世代を超えて蓄えていくのかと考えていったときに、Essenceは意味があると思っています。

チームやプロジェクトのデザインには言語が必要

これはJacobsonが告げていたそのままなのですが、言語が必要だと。方法論とまったく思っちゃいけなくて、方法論をニュートラルに知見を集めて使えるかたちにすると。さっきどなたかがSlidoで言っていましたけど、方法論メタモデルって言えるんですよね。知見をこの中にこの言葉で蓄えていくということが重要だと思っています。

僕自身、今ソフトウェアって考えると、ソフトウェアデザインとチームデザインと両方の面があって、それをつないでいるのはピープル、人々なんですよね。ピープルの部分というのは、アジャイルが強く語っている部分で、今までの UMLみたいなデザインの言語でデザインは語られてきたんだけれども、チームやプロジェクトのデザインもある程度言語が必要なんじゃないかなと思っています。

UMLってもう廃れているとみなさん思っているかもしれませんが、例えば自動車業界で欧州の規格でECUの中のソフトウェアが相乗りできるようなAUTOSARというアーキテクチャがありますが、その仕様書はUMLで書かれています。

UMLは組み込み系の中ではすごく使われていて、やっぱり産業や国を横断してなにか規格を作っていったりするときにすごく重要な役割を今でも果たしています。あ、ちなみに僕はUMLのエディターソフトでastah*（アスター）っていうのを作っています（笑）。

言語があるってやっぱり重要で、それがワクワクしないっていうのはワクワクしないんですよ。ワクワクしないけれど、残していく活動、つまりP/L（損益計算書）ベースの年次のプロフィットロスを見るんじゃなくて、B/S（バランスシート）としての僕たちが蓄えてきた資産とか、得てきた経験っていうのをなにか残していかないと、なかなかソフトウェアがエンジニアリングにならないのかなと思っているポジションです。以上です。

補助輪としてのEssenceの可能性

鷲崎：ありがとうございます。それでは最後に角さんよりポジション表明をよろしくお願いします。

角征典氏（以下、角）：私はスライドは用意していないんですけども、先ほどの講演にあったように、私は基本的にはウォーターフォールを経験したことがありません。アジャイルばかりやってきているので、基本アジャイルでソフトウェア開発を進めていこうとは思うんですが、やっぱりうまくいかないところってけっこうあるんですね。

そういったところに対して、カードを使って全体像を把握して、自分たちで改善していけるという補助輪としてのEssenceはすごく可能性があると思っています。これをは本当にいろいろなところに勧めていきたいなと思っています。以上です。

鷲崎：簡潔にありがとうございます。

（次回へつづく）