システムのアーキテクトとして活動していると、グルのように扱われることが多々あります。でも、本当は、メンバの独創を引き出すことこそが必要なのです。メンバの態度を、「決めてください、教えてください」から、「こうしたい」(を阻害しないお膳立て)にするためには、どうすべきでしょうかね。
「独創を出してもいい」ってのが共有されてないのかもですね。あるいはスキルがないので手を出しにくいのかもしれません。いずれの場合も何らかの方法で情報やナレッジを形式知化できるとよさそうです。
Essence の導入について気になっていることがあります。チームメンバー全員が Essence の背景から理解できる状態に持っていくまで、結構な教育コストがかかるような気がします。ゲーム形式での使い方(3種類)も紹介されていましたが、理解度は別にして今のプロセスを可視化するツールとして利用するのは悪手でしょうか。
「カードを広げてみんなで見てみよう」程度なら、教育コストもさほどかからないですし、そのほうがEssenceだとわからずに使ってくれるのではないかと思います。ゲーム形式はそうしたことを目的としていますので、ぜんぜん悪手ではないです。
サイエンスに昇華するまではエンジニアリングは宗教まがいになる、というのはその通りですね。イデオロギーなど難しい事を考えずに、アートからサイエンスになる時期が一番盛り上がって楽しいので、純粋にそれを皆で楽しめばよいのではないでしょうか？
最終目標として「価値」を目指そうとすると、それを生み出すチームやそれを届ける顧客に必ず「人間」がいるので、サイエンスに昇華するとしたら、どうしても社会科学的なアプローチにならざるを得ない気がします。下手に（狭義の）サイエンスにせずに、エンジニアリングのいち分野として確立できないもんですかねえ。
サイエンスの定義はなんでしょう(これはサイエンスではないように思います)
上に関する質問ですよね。なんでしょうね……。再現性なのか、反証可能性なのか。サイエンスも幅広いですしね。
「ペアプログラミング」の記述なのに、どこにも「ペア」という要素が含まれていないから、本質をちゃんと記述できてないのでは……?
カードのほうに「協力して」とあって、それがペアを指してるみたいですね。まあ、わかりにくいのはその通りだと思います。
Essence は 手法定義のためのメタ手法（メタ言語）と理解してよいのでしょうか？元々そのような話でしたっけ？
初期の頃に「メタ手法だからクソ」みたいなことを言われて「メタちゃうわ！」みたいな反論はしてます（下記URL）。おそらく「カーネル」を作ったからだと思うんですが、それでも「言語」の部分は一種のメタですよね。
http://semat.org/ja/blog/-/blogs/some-critiques-of-the-semat-initiative
日本でこれだけの「guru」が関わり、長く経っているにもかかわらず、具体的な実践例が目立たないのはなぜだと考えていらっしゃいますか(ここで挙げられるのも2016年の例)
「日本でこれだけのguruが関わり……」ではなく「日本で目立たないのはなぜ」という質問ですかね？ 情報としてまとまってなかったのが一番じゃないでしょうか。本をよろしくお願い致します。
Essenceカード印刷したやつ技術書典で売って欲しい。データダウンロードでもよいけど印刷されたカード自前で用意するの大変なので。
著作権フリーではないので、売るのは問題がありそう。
品質は工程で作り込むってのはトヨタで昔から言われてますよね。
ですね。
様々な手法に「似たような」ものがあるという議論はアートとしての議論であってサイエンスではないです。手法の構築は知識のメタ化でしかないので、やれば良いだけです。その前に、自分が何を理解できていて何が出来ていないのか、何故理解できないのか、これをしっかり議論するところから始めるべきです。何故そうしないのでしょうか？
ぜひEssence使ってください。
UMLよりわかりにくい……慣れると読めてくるものでしょうか?
要素数は少ないので、複雑ではないです。慣れるというか、がまんすれば普通に読めます。とはいえ、わかりにくいのは同意です。
SCRUMで上手くいっていないチームに、これが有効に扱えるようには思えないのですが、何かコツはありますか。
えーそうですか。私は有効だと思いました。逆にできるチームには不要です。たとえば、スプリントレトロスペクティブでカードを広げて、自己診断してみるのはどうでしょうか。そして、それにもとづいて改善策を練る。このあたりから始めるとよいと思います。
EssenceでなくてもV字モデルでもこのふりかえりはできそうに思いました
わたしも思います。
要求仕様設計段階で量産テストや品質保証を織り込むのが常識だし当たり前の事だと思っているのですが、世の中そうでもないという事なんでしょうか？要求仕様分析段階で品質保証を導入するとか今更過ぎる気がするのですが。
決められたものを作るときは当たり前だったんでしょうが、価値が多様化している現代にそれをやるのは大変なので、さあどうしようか……というのが議論の出発点なのだと思います。
DEVでものを作成し、OPSで運用していく中でQAはどのような役割をするのでしょうか？アジャイルだとPOが要求に対して妥当性確認を行うと思います。QAは何を保証しますか？
POはアジャイルじゃなくてスクラムですね……というのはさておき。上の質問にもあるように基本的には品質を作り込むべきなのだから、従来の事後的な仕事だけでなく、事前的な部分でPOの要求作成などのサポートをすることになります。
ソフトウェアは自然科学から生み出されたものですよ。ヒルベルトの幾つかあった問題の中の1つの問題への回答から始まった分野ですよ。始まりはサイエンスです。ちゃんと勉強してください。
（私の発言宛ではなさそうですけど）勉強になります。
システムズエンジニアリングでも、ビジネスやミッションを大事にしていたり、利害関係者ニーズや利害関係者要求を大事にしています。ＩＴベンダーがどうしても抜ける部分だと思います。
そうですね。もっと顧客に近づければ違うんでしょうけども。
事例を残し、伝えるための共通言語が必要という事は、すごく共感します。今のものは、分かりづらいのに、定義が曖昧な部分がある様に思います。もっと、どちらかに寄せるべきではないでしょうか？がちがちに定義する。または、もっと分かり易く変える。
どっちかに偏れば、きっと反動が生まれるんですよね。いずれちょうどいいところに着地するんじゃないかと思います。
”産”（というか、ベタベタの開発現場の状況（苦悩））を理解した”学・アカデミアン”がいらっしゃらないと難しいかと…象牙の塔／白亜の塔から 好き勝手言ってるような方々（この場にはいらっしゃらないと思いますが）がしゃしゃり出るようでは困ります。（かなりローカルは話で恐縮です。）
チームでやればいいと思いますけどね。大学でいい先生を見つけて（もちろん鷲崎先生でも）、企業がスポンサーになるのがよさそうです。
角さんの意見に共感しました。UMLならまだしも、エスペラント語のようにならないでほしい。なんとか人が使って楽しいと思えるものに仕立て上げてもらいたいです。
ですよねえ。言語の部分はちょっとうーんって感じですが、カードの部分はそれなりに楽しそうなイメージを持ってます。
Practice libraryという言い方と、パターン言語と、どういう器や言語が、良いやり方を伝えるのに適しているのか、改めて悩みが深まった気もします。
パターンランゲージのほうが「いきいき」としてる感はありますよね。一方で、うまく形式化されていないので、標準化とかそういうのには向いてなかったんでしょうね。
「状態を追え」は面白そう。実際にやったことがある方に感想を伺いたい。どこが使えて、どこが使えないのか？ 状態がなかなか動かなくて気に留めなくなってしまうことは起きそうな気がしました。
状態が動かないのは「深く考える」しかないですねえ……。あとは、状態の合意が取れない（Aさんは進んでいると思い、Bさんは進んでないと思う）というのはありそうです。
スクラムの足りないところを補う程度で使うには「重すぎる」という感想
上に出てきた質問と同じですかね。何も使わずにできるチームは別に手を出す必要はなくて、できないチームはどうしても「重い」ことをやらないとね、という。勉強できる子は別に勉強しなくてよくて、勉強できない子は勉強しなきゃダメ、という話だと思うんですよ。。。
プロジェクトで困っているときだけ使うということはできるでしょうか？何をやっているか見失っている時に、カーネルの状態等を明らかにして何をすべきかを決めることができそうです。
できると思います。むしろそういう使い方を想定されているっぽいです。
モデリング言語としてのEssenseを読み書きするのではなく、開発チームのアジリティを高めていくためのアセスメントツールとしてゆるく使ってみるくらいがちょうどよさそう。
そうですね。そういう使い方がバランスがとれてそうです。
リモートでEssence のカードゲームをする方法はありますか。
オンラインのホワイトボードツールに貼り付けて使うとよさそうです。あとは公式サイト（以下URL）にいくつか載ってるみたいです。
http://www.software-engineering-essentialized.com/games
Essence は、定義 と 分析（現状の表現／見える化）の両側面があるのですね…そういえば、UML自体がそうですね。
たしかにそうですね。
UMLが使用／活用されない。情報はアップデートされないのは ”日本”だけでしょうか？
おそらく国ではなくて分野によって違うんだと思います。
ISO/IEC 12207でソフトウェアのライフサイクルプロセスを定義されていると思いますが、それは使用できないのでしょうか？
私は詳しく知らないのですが……「すべてのこと」が網羅できていれば、リファレンスとして使うことは可能だと思います。
SEMATとあまり変わっていない印象ですが具体的にどこが変わったのでしょうか？
SEMATは団体組織名で、Essenceは言語とカーネルですね。
Essensceで使う言葉は、自分たちの言葉、ドメインで決めていけばよいのでしょうか。
そうです。自分たちで「プラクティス」を作ることを推奨しています。
Essenseを実用する時の粒度はどう考えればいいでしょうか？ 要求一つ一つの状態を取り扱うと考えると膨大なカードを用意して動かすような気がしました。
どんな手法を選択するか、イテレーションの期間をどうするか、によって変わると思います。スクラムであれば、プロダクトバックログアイテムが単位になります。それが膨大な量だと言われると、まあ膨大になりますね。そんなもんです。
アルファ同士は依存していないのでしょうか？ アルファの状態の進め方にある程度ルールがある気がしました。
依存しています。図に矢印が描いてあります。
初めて聞いたけど濃いセミナーでした。
よかったです！
形式化して伝承したい、というのは 叶わぬ夢なのではないか と時々自信と勇気を失いそうになります
希望と絶望を両方持ちながら「でもやるんだよ！」ですね。