スクラムの58％は失敗している　Essenceを混ぜればソフトウェア開発はうまくいく

Essenceの本質

途中からプラクティスの説明ではなくてEssenceの説明に踏み込んでしまったんですけれども、これからが本題です。ここまではちょっと前フリというか背景で、ここからがEssenceの説明になります。

Essenceというのはカーネルと言語で成り立っていて、これまで説明してきたプラクティスとかあるいは手法の基盤となるようなものを目指しています。将来的には未来を予測したいのですが、予測するためには記述が必要で、記述するためには言語が必要ということなので、とりあえず言語を定義したという状況です。

Essenceの言語の要素というのはこのようなかたちで、アルファ、アルファの状態、アクティビティスペース、アクティビティ、コンピテンシー、ワークプロダクト、パターンといった、これだけですね。これだけの要素で成り立っています。

Essenceカーネルというのがまた別にあるんですけれども、この記法の中で左側の「もの」「こと」「能力」ですね。アルファ、アルファの状態、アクティビティスペース、コンピテンシーのことをカーネルというふうに呼んでいます。

これはあらゆるプロジェクトで必要となる要素のことを指していて、右側のワークプロダクトとかアクティビティとかパターンというのはあまりにも具体的すぎるので、それぞれのプロジェクトとか現場に合わせて使うものなので、カーネルでは定義しないことになっています。

カーネルのアルファ

それぞれちょっと説明していきたいと思います。まずカーネルのアルファと呼ばれるものですね。アルファということなので、一番最初に来るもの、一番大切なものということを指しています。

また同じ図になってはくるのですけれども、アルファは7つ定義されています。それぞれが顧客とソリューションと活動に分類されていて、機会、opportunityですね。ステークホルダー、要求、ソフトウェアシステム、作業、チーム、作業方法。これだけ揃っています。

それぞれのアルファは状態カードをもつので、例えばステークホルダーの「認識できた」という状態から、ちゃんとステークホルダーがプロジェクトに「関与している」という状態に遷移させるためにはチームで何のプラクティスを実施すればいいかと。例えばステークホルダーを巻き込むために定期的にミーティングを開催してはどうか。

これはちょっとプラクティスの名前がついているわけではないのですが、こういった新しい施策を実施することによって、アルファの状態が進んでいくことを目指しています。

「状態を追え」ゲーム

このEssenceの本の中にはゲームがいくつか用意されています。例えば「状態を追え」ゲームがあって、アルファが7つあるんですけれども、アルファのカードとその状態カードをこのように並べていきます。

それで状態を達成したら左側に状態カードを寄せていって、残る状態が右側に残っているんですけれども、これを全部左側にもっていくためにはどうすればいいかというのをみなさんで考えていただく。例えば振り返りみたいなところで考えていただいて、「じゃあ次のプラクティスはこれを実施して状態を進めていきましょう」ということでプロジェクトを運営していく、というのが理想的な使い方になっています。

あるいは数値化したいのであれば、状態をそのまま数値に置き換えていただいて、イテレーション1番のときには左のような状態だったものが、イテレーション3番ぐらいになるとだんだんレーダーチャートが広がっていくように診断することも可能になっています。最終的には全部の状態を5とか6とかにするようなイメージです。

日本語版のアルファの状態のカードというのを作っておりまして、よければGitHubに上げていますのでこれ切ったりして使っていただければと。鷲崎先生とかも作っているかなと思いますので、検索してもらえればと思います。

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

次です。カーネルのアクティビティスペース、なにかやる「こと」になります。

「こと」については、アクティビティスペースとアクティビティという2つあるんですけれども、アクティビティスペースのほうがフォルダです。ディレクトリというかフォルダというか、プラクティスのアクティビティを入れる入れ物のことをアクティビティスペースというふうに呼んでいます。

点線のものがアクティビティスペースです。わりと抽象的な概念でカテゴリを表していて、プラクティスを行うと、この中にですね、そのプラクティスのアクティビティをばかばか入れていくようなイメージです。

これはなんでいいかというと、自分がやっているプラクティスをこの中に当てはめていくと、空欄というか足りない部分がわかるということです。

例えばこれはスミスという登場人物のチームのプラクティスを可視化したものなんですけれども、スミスのチームはお客さんに対して何もやっていないことがわかる。あるいはシステムをデプロイするとか運用するみたいなことについてはまだ開発初期段階なので考えていないみたいなことがわかるので、時期が来たらこういった空白部分を埋めるためのプラクティスをなんらか用意しないといけないということがわかるようになっています。

なお、カーネルは一応拡張可能になっていますので、先ほどのアルファ7つしかないというふうに残念がるのではなくて、例えば「要求」を継承して「プロダクトバックログアイテム」を作るとか、「作業を準備する」というのを継承して「チームのキックオフ」というのを作るとか、プラクティスを作るときにカーネルの継承というのが可能になっていますので、カーネルで足りないときにはぜんぜん拡張可能なかたちになっています。

スクラムとEssence

最後です。Jacobsonの講演の中でも最後にJeff Sutherlandと一緒にEssenceとスクラムをやっているというふうに述べられていたかと思うんですけれども、この本の中でもスクラムとEssenceを混ぜてどのように開発するかという事例が載っています。

スクラムご存じでない方のために、ざっとこんなイメージだと思ってください。スクラムチームという役割があって、バックログを作って、その中からスプリントと呼ばれる開発サイクルの中で淡々と作っていく。最後にレビューとレトロスペクティブをやって、プロダクトインクリメントができる。

というのがスクラムの全体像なのですが、これをEssenceで記述しましょうということがされています。

例えばスクラムのチームの役割は、全部パターンというかたちで置き換えますし、バックログに関してはワークプロダクトですね。そしてプロダクトバックログアイテムとかはアルファ。スプリントもアルファですし。イベントに関しては全部アクティビティというかたちでマッピングされています。

このようなかたちでEssence言語に置き換えて、さらに注釈を入れていくと、このようなかたちになります。

見てわかるとおり、めちゃくちゃわかりにくくなっているんですよね。3回目ですけれども、UMLと同じぐらいの希望と絶望をもって接するとちょうどいいのかなという感じです。

もうちょっと説明を続けます。

ただし、悪いところばかりではなくていいところもけっこうあって。例えばスプリントというのは継承したアルファですね。カーネルを継承したアルファになっているんですけれども、その説明がちゃんと概要としてカード化されているし、状態も定義されている。

この状態を定義されているというのもけっこう重要で、今自分たちのスプリントがいい状態なのか悪い状態なのか、あるいは遅れているのであれば、どのようにして次の状態に進めればいいかというのが、ちゃんと明示的になっているのがすごくいいポイントだと思います。

スクラムをご存じの方はわかると思うんですけど、なかなかスクラムだけやってもプロジェクトはうまく進まないので、いろいろな足りない部分を自分たちで補完していかなければいけないのですが、こういったアクティビティスペースにマッピングすることによって、例えばソリューションのところも空ですよね。

顧客も空になっているんですけれども、こういったあたりをほかのプラクティス……まぁよく言われるのは、エクストリームプログラミングやりましょうとか、なにかデザイン思考やりましょうとか、リーンスタートアップやりましょうとか、そういったところで補完することによって、スクラムだけじゃ足りないところがわかるような流れになっています。

実際Jeff Sutherlandが言っている言葉なんですけれども、世の中スクラムが流行ってきていてスクラムがけっこうな度合いで導入されてはいるのですが、58パーセントはだいたい失敗しているということがわかってきているそうなんですね。うまくいっているところは当然うまくいくのですが、見様見真似でやろうとするとなかなかうまくいかないと。

そこでEssenceのカードを使えば、先ほど言ったように足りない部分はどこなのか、あるいは状態のどこで詰まっているというのがわかるので、そこで自己診断ができるようなかたちになっています。

そこでScrum Essentialsというのが用意されています。これはJacobsonの会社とScrum Inc.というJeff Sutherlandの会社が共同で出しているものなんですけれども、こういったものを使っていただいてスクラムを導入するとすごくうまくいくと。

特にスクラムの研修とかあると思うのですが、あれでカードを使ってスクラムの研修をすると、今までけっこう1日とか2日とかかかっていたものが数時間で理解できるようになったみたいなことも、講演の中ではされていました。

スクラムはちょっと苦手だなという人のためには、もうちょっと抽象化したというか、Agile Essentialsというのも用意されています。例えばプロダクトオーナーシップに関するもの、バックログに関するもの、チーミングに関するもの等々、それぞれスタート地点となるようなもの、かつ、検査ができるようなかたちのカードというのが用意されています。

Practice Libraryというのは先ほどJacobsonの講演でもあったかと思うのですが、プラクティスはEssenceで記述して流通可能なかたちになっていますので、ちょっとこれは登録制ではあるのですが、Webブラウザでいろいろなプラクティスが見れるようなものがありますので、よかったらこのあたり見ていただくとよいのかなと思います。

全体的な印象

終わりになりますけれども、全体的な印象です。私は翻訳者ではあるのですが、100パーセントEssenceのことをわかっているわけでもないですし、100パーセント賛同しているわけでもないので、本当に率直な印象です。

アジャイル開発が楽しいという感じは、なんか記述することによってすごくダウンしているような印象がありました。先ほども世界中の企業でとか大学でとか使われているみたいなことをJacobsonは言っていましたけど、「えっ、本当？」。ちょっと日本ではそんなことないので「こんなあんまり楽しくなさそうなのが流行っているのかな？」というのがちょっと正直なところありました。

手法の問題として、グルが何か手法を決めてそれから抜け出せないのが悪いと言っていたのに、「あれ、なんかJacobsonが監獄を作っているんじゃない？」というのもあります。

4回目ですけれども、UMLと同じぐらいの希望と絶望をもって接するとちょうどいいという感じですね。

悪いところばかりではなくて、スクラムがうまくいかないところと、うまくいくところがけっこう明確に分かれていて、できるところはできるしできないところはできないんですけれども、できないところに関しては、このEssenceという補助輪があるとすごくうまくいくような印象がありました。

手法の基盤となるようなものを目指しているというふうにこの本の中でも書かれているんですけれども、このすべての全体像を把握するという意味合いで言うと、すごく安定感があるというのを感じられました。

あと、Jacobson。先ほどビデオでも出てきましたけど、もう本当この20何年間ぐらいですかね。ずっと第一線で活躍されていて、元気そうでよかったなというところです。

というわけで、うまくいっている方はけっこう煩わしいなと思われるかもしれませんけど、うまくいっていない方はぜひこのEssenceを使って自己診断してください。次の一手を考える上ではすごく役に立つ本かなと思いますので、ぜひ興味があれば見ていただければと思います。

以上になります。どうもありがとうございました。

質疑応答

司会者：角さまご公演ありがとうございました。ではせっかくですので、sli.doのほうでちょっと質問が関連するところが出てきますので、ぜひ取り上げたいと思います。最上位に今来ているものです。

「Essenceの導入について気になっていることがあります。チームメンバー全員がEssenceの背景から理解できる状態にもっていくまで、けっこうな教育コストがかかるような気がします。ゲーム形式での使い方も紹介されていましたが、理解度は別にして、今のプロセスを可視化するツールとして利用するのは悪手でしょうか？」という、まぁ悪い手でしょうかというご質問です。

角：ぜんぜん悪手ではないと思います。むしろそういった使い方をされることを望んでいると思います。先ほどスライドでも紹介したように「状態を追え」ゲームというのはすごくわかりやすいと思うので、まずはそこからやっていくのがよいと思いますし、そんなに教育コストもかからない気はしています。以上で大丈夫でしょうか。

司会者：はい。明快です。ありがとうございます。ではもう1つ。これはどちらかというと平鍋さんの最初のほうですかね。

「システムのアーキテクトとして活動していると、グルのように扱われることが多々あります。でも、本当はメンバーの独創を引き出すことこそが必要なのです。メンバーの態度を『決めてください』『教えてください』から『こうしたい』を阻害しないお膳立てにするためにはどうすべきでしょうかね」ということです。

グルという言葉が、最初のJacobsonの講演ですとか、もちろん角さんのほうからもありましたけれども。ではこれは平鍋さんのほうからもし何かあればお願いします。

平鍋健児氏：なんかこういう話はよく聞きますね。でも、やっぱり同じ目線で現場の人と話をして、困っていることに共感して、その問題に一緒に立ち向かっていく、あるいは一緒にやろうよというような、なにかそういう雰囲気づくりとか場づくりとか接し方じゃないかなって思います。

でも、これってすごく会社の文化も関係していると思っていて、なかなか大きな会社にいってそういう組織の中で育った人たち、そういうこと難しい場面もあるけど。

でも、最近だとどうですかね、みんな。僕、アジャイルの界隈にいるとこういうことってすごく逆に珍しくなっていて。若い人も含めて、なにか「やろうよ」という感覚、それから「僕らがこれ作っているよね」という感覚というのは日本の中で今どんどん出てきていると、逆に思っていますね。

だからそういった苦労は、昔は僕もよくわかったし、なんとか一緒にやろうよという気持ちをもっていくというのが大事だと思っていましたけれども、なんかもうぜんぜんそうなっているんじゃないかなって僕は肌感覚として思っていますけど、どうですかね、みなさん。

司会者：ありがとうございます。すごく強いメッセージを頂戴しました。あらためまして、平鍋さん、角さん、本当にありがとうございました。

角：ありがとうございました。

平鍋：ありがとうございました。