昨日オンライン開催された、Essence セミナーの平鍋からのレポートです。冒頭、Ivar Jacobson からもらったビデオを、ぼくが解説しながら流しました。

基調講演

より詳しくはこちら。スライド(PDF)もこちらから。
https://essence.ivarjacobson.com/videos/tokyo-keynote-july-21-modern-software-engineering-essence

• ソフトウェアはビジネス的に大きな成功をおさめているが、それをささえるソフトウェアの工学は未熟なままだ。
• これまで発見されているベストプラクティスを、「方法論」の呪縛から開放し、みんなで議論し改良し、使えるようにしたい。
• 3つのペルソナ＝スポンサー、テッククリード、チーム、それぞれの課題は、
  • スポンサー：2,500万人ものソフトウェアエンジニアがいるのに、工学というより工芸のようだ。毎回新しい方法論や技術が現れ、投資が無駄になる。名の通った Guru の手法（方法論セールスマン）に依存している。チーム間で手法が流通しない。
  • テックリード：方法論争から開放され、必要なプラクティスを自由に利用したいのだ。それぞれの方法論のいいところをミックスしたい。また、手法ごとに語彙が違う。違う手法を使うと学ぶのがたいへん。
  • チーム：成功しているアジャイルチームは、自分たちで仕事の仕方を選べるのだ。アジャイルフレームワークに沿って仕事をさせられるのではなく、自分たちでプラクティスを選びたい。バックログをひたすらこなすのではなく、スマートに仕事がしたい。

エッセンスは大学でも教えられている。400年後にエッセンスを見ると、それは、ニュートンやガリレオが400年前にやったことと同じように見えるだろう。

Essence はどの方法論とも競合しない。例えば、Jeff Sutherland の Scrum と協調している。“Better Scrum with Essence” with Jeff Sutherland and Ivar Jacobson)

講演は、「一緒に未来を創っていこう」というメッセージで締め括られました。

角さん（翻訳者）の Essence 解説

とても分かりやすい解説でした。キーコンセプトである、７つのアルファや、例としてのペアプログラミングの記述、カードの説明などなど。本を読んでも難しそうだったコンセプトが明確になったと思います。

鷲崎先生のお話

これまでのソフトウェア工学が、「テーゼ」と「アンチテーゼ」の上下に触れながら、止揚されていく様子を Boehmの資料をもとに解説があり、ポストアジャイルとしての Essence の位置どりが話されました。また、小林さんの Essence を利用した事例も紹介されました。

パネルディスカッション

富士通の宮田さんから、日本のSI、そこで働くSEのあり方を変えていきたい、という力のこもったメッセージがありました。ある意味日本のSE論、とそこになかったものの反省から、知識を蓄えて、これからの創造的なSEのあり方を模索せねば、という危機感というか気迫を感じるお話でした。

富士通クオリティラボの島田さんから、品質保証の立場から、どうやってアジャイルに関与していくか、という戸惑いと思いをお聞きしました。やっぱり「参加していく」ことが重要だと話されていて、品質は「最後のゲート」ではなく、共に作る、ものだと再認識しました。

小林さんは現場視点から、Essence の事例をいくつか見せていただきました。使ってみるとなかなか面白い発見があるものですね。「匠メソッド」のマッピングも面白かった。

ぼくの方は、これまでのソフトウェア工学の Guru たちがこぞってアジャイル側に加担していること、でも、残していくものを残していく器（うつわ）として Essence の役割を話したつもりです。アジャイルの成功は「チーム」の成功、「ビジネスの成功」を基本としていて、それを直結しています。でも、チーム横断、企業横断、さらに産業横断でその体験を蓄積する仕組みがないのです。これはおそらくわざとで、動く実装があってはじめて機能する、というインターネット創生にはじまり、ソフトウェア現場、クラフトマンシップの学びから、まずはチームでビジネスの成功をつくらないと始まらない。企業で知識を蓄えるしくみは、たとえば、野中郁次郎のスクラムには、最初から書かれている(Multi-Learning)。ただ、問題は、いまの大企業のソフトウェア開発が、この「知識トップダウン」になっていること。知識が急激にアップデートされるのに、過去の成功・失敗から取り出された「守るべきこと」の集積になっている。知識のトップダウンを避け、さきに動くチームがなければならないので、順序としてはこれでいいい。次にぼくらがやらなければならないのは、知識を集める仕組みで、企業ワイド、産業ワイドにできるようになるといい。知識のボトムアップ。こここそが、Essence の生きる道、ソフトウェア工学の道ではないか、そして、アカデミアの役割もそこにあるのでは、と思っています。

また、「ソフトウェア工学は工学になりきれていない」という話は、土木工学がもともとエンピリカルであり、そこから、エンジニアリングの力で安定したという話の引用です。Mary Shaw の GOTO カンファンレスの面白い講演がこちらです。 Mary Shaw “Engineering Discipline of Software

すべて話し切れませんでしたが、ソフトウェア工学で Evergreen に残っていくコンセプトはあると思います。昔話になりますが、このあたり。

（このあたりは、ここに詳しく。）

聴衆の永田さんから、「例えばペアプロを例に書いていたが、実感が伝わってこない」はその通りで、たぶんそこは削ぎ落とされてしまうのでしょう。永田さんもおっしゃられていましたが、むしろパターンなどの方が、いきいきした人間の活動としての部分をキャプチャできると思います。

角さんが、bliki の記事を紹介されていましたが、SEMAT へは、Martin FowlerもAlistair Cockburnも署名していたのですが、途中から興味を失ってしまったみたいです。

最後に

sli.do に上がった質問はリアルタイムに答えられましたが、角さんがまとめて意見を書いてくれています。（こちら）