はんなりと、ゆるやかに

アジャイル、スクラムが好きが日々から学んだことをアウトプット

git2.27以降にgit sparse-checkoutを使う場合はno-checkoutではなくsparseを使おう

以下の記事で紹介したPartial Cloneとgit sparse-checkoutコマンドの組み合わせが、git 2.27 から使えなくなっていました。自分の記事を参考に同じ手順で進めても成功しなかったので気づきました。本記事はgit 2.27 以降で同じようなことをする解決策をまとめます

iucstscui.hatenablog.com

git 2.26 で出来て、2.27で出来なくなった手順

  1. git clone --filter=blob:none --no-checkout https://github.com/git/git.git
  2. git sparse-checkout init --cone
  3. git sparse-checkout set Documentation

git 2.26の場合、「1」を実行するとディレクトリ内は空の状態でcloneされます。「2」を実行するとルートディレクトリのファイルが展開され、サブモジュールが初期化された状態になります。ディレクトリ関連は展開されません。「3」を実行するとDocumentationディレクトリが展開されます。

git 2.27 の場合、「2」「3」を実行してもファイルもディレクトリも展開されません

実は予期しないバグがあった

以下の記事で同じように困っている方に対して回答がありました。
stackoverflow.com

--no-checkout後のsparse-checkout 予期しないバグがあったため、f56f31aのコミットで機能しないように修正されたようです。
※英語ムズイ。読み間違えてなければこういうことらしい。

git 2.27以降でPartial Clone後にgit sparse-checkoutをする方法

今回調べて気づきましたが、git clone に専用のオプション--sparse がありました。これを使うことで解決できます。
git-scm.com

--sparse
Initialize the sparse-checkout file so the working directory starts with only the files in the root of the repository. The sparse-checkout file can be modified to grow the working directory as needed.
作業ディレクトリがリポジトリのルートにあるファイルのみで始まるようにします。スパースチェックアウトファイルは、必要に応じて作業ディレクトリを拡大するように変更できます。

--sparse を使ってsparse-checkoutすると以下のようになります。

$ git clone --sparse https://github.com/git/git.git 

Cloning into 'git'...
remote: Enumerating objects: 292088, done.
remote: Total 292088 (delta 0), reused 0 (delta 0), pack-reused 292088 eceiving objects: 100% (292088/292088), 143.50 MiReceiving objects: 100% (292088/292088), 143.51 MiB | 2.45 MiB/s, done.

Resolving deltas: 100% (217554/217554), done.

$ git sparse-checkout init --cone

$ git sparse-checkout set Documentation

これにより、ルートディレクトリのファイルと、git sparse-checkout set Documentation で後から追加したDocumentatinディレクトリのみが展開された状態になります。不要なオブジェクトを除外してダウンロードできるので、大きなリポジトリもサイズを抑えて素早くcloneできます。

--filter=blob:noneを追加すると、さらにリポジトリサイズを抑えることが出来ます。

$ git clone --filter=blob:none --sparse https://github.com/git/git.git 

Cloning into 'git'...
remote: Enumerating objects: 180497, done.
remote: Total 180497 (delta 0), reused 0 (delta 0), pack-reused 180497 eceiving objects: 100% (180497/180497), 61.63 MiBReceiving objects: 100% (180497/180497), 62.60 MiB | 2.66 MiB/s, done.

Resolving deltas: 100% (114752/114752), done.
remote: Enumerating objects: 385, done.
remote: Counting objects: 100% (385/385), done.
remote: Compressing objects: 100% (385/385), done.
remote: Total 439 (delta 0), reused 0 (delta 0), pack-reused 54
Receiving objects: 100% (439/439), 1.76 MiB | 1.76 MiB/s, done.
Updating files: 100% (440/440), done.

$ git sparse-checkout init --cone

$ git sparse-checkout set Documentation

remote: Enumerating objects: 347, done.
remote: Counting objects: 100% (347/347), done.
remote: Compressing objects: 100% (345/345), done.
remote: Total 751 (delta 6), reused 2 (delta 2), pack-reused 404
Receiving objects: 100% (751/751), 1.58 MiB | 1.34 MiB/s, done.
Resolving deltas: 100% (45/45), done.
Updating files: 100% (751/751), done.

cloneしたディレクトリのサイズを比較すると、--filter=blob:noneなしの場合は161MB、ありの場合は81MBと節約できました。

まとめ

  • git 2.27移行は--no-checkout を使ったsparse-checkoutができない
  • git clone --sparseを使う

自己組織化されたチームで共につくろう / Re-RSGT! チームの自己組織化、リーダーシップ、スクラム開発で力を発揮するデザイナーについて に参加した

2020/08/20 に開催された「Re-RSGT! チームの自己組織化、リーダーシップ、スクラム開発で力を発揮するデザイナーについて」に参加しました。RSGT(Regional Scrum Gathering Tokyo)は日程が合わずに参加したことがありませんが、1度は参加したいイベントです。いや、1度ならず毎回参加したい。今回はそんなRSGT2020で惜しくも採択されなかったテーマのお話でした。とてもとても良い内容で今回聞けて良かったです。

taco.connpass.com

今回の発表内容

  • スクラム開発で力を発揮するデザイナーについて —アジャイルに適応したデザイナーとは
  • チームの自己組織化とリーダーシップのセルフマネジメント

スクラム開発で力を発揮するデザイナーについて —アジャイルに適応したデザイナーとは

登壇者:といださん

  • kintoneのサービスに関わっている
  • ウォーターフォールからスクラムに切り替えたデザイナーの話
  • ウォーターフォール時代
    • デザイナーはデザインを作ること
    • こうしたマインドセットだとスクラムに適応しづらい
    • スプリント後の微調整の役になったり、スプリント前にすごい青写真を作る役になったり
    • デザイナーと開発チームに壁ができる
  • 問題点
    • デザイン完成したってなっても懸念が見つかったり、開発が難しかったり
    • それでは、デザインが完成したと言えない
    • デザインを作って渡すプロセスはアジャイルと合わない
  • モブプロ
    • 開発チームのモブプロに混ざった
    • メリット:デザインの意図が伝えられたり、開発者側からの提案があった
  • バックログ
    • バックログ検討のスプリントと開発のスプリントがある
    • バックログを作るとこにもデザイナーが関わる
    • バックログ検討のスプリントでは「気づきを与える/得る」ことが重要
  • デザイナーはデザインという手段で、ユーザーに価値を届ける

スクラムは「共につくる」が大事だと考えさせられたお話でした。スクラムフレームワークに沿って開発するだけじゃなく、「チームで作る」のベストを考え続けることが大切だと思っていて、それに向かって行動されているのは素晴らしいですね。

以前参加した勉強会でヒトは分業し大量生産を可能にすることで進化してきたが、今は多様性が求められていてエキスパート同士がともに作ることが大切だと話されていました。

エンジニアだけじゃなく、デザイナーの方や企画の方、営業の方と共に開発できる場を作り、ほんとうに必要な価値をユーザーに届けられるようにしなければ!そう思えたお話でした。

チームの自己組織化とリーダーシップのセルフマネジメント

登壇者:Iidaさん

  • なぜ組織に向き合うのか
    • 組織を変えるのは人の思い
    • 組織に向き合ったのは役割が与えられたからではなく、そうしたいと思ったから
    • 問題を発見したときは1人なので「ぼっちからはじめる」
    • ぼっちは強み
    • 組織に向き合わなくても仕事は出来る。でも1人で出来ることに限りはある。組織で活動して大きな価値を生み出す。
    • みんなも組織を改善をしてほしい→自己組織化を目指す
  • 理想と現実
    • 全員がよりよくしたいと思っている?理想はそうだけど、自分の仕事の範囲に割り切る人もいる
    • 善意だけでは組織は変わらない
    • 組織の課題のために行動しない理由はたくさんある
  • 自治と責任と秩序
    • 自己組織化と言えども何でも自由にできるわけではなく、責任が伴う
    • 何を達成するべきか分かっていて、それを達成することが責任
    • 難しいし、大きな力が必要(大きな力は情報と権限)
  • どうやって組織に向き合うのか
    • リーダーシップの役目は""を作る
    • メンバーをその気にさせる
    • みんなが自然に改善する環境をつくること
    • 組織を改善すると確実にリターンがあることを伝える
    • 信じて待つ
    • 人に関するスキルは技術的なスキルに繋がらないので時間を使いたがらない人も多い
    • 実験をスケールさせることが大切
    • 失敗しても大丈夫な環境にする
    • 心が折れそうになったら...一度離れても良い。そこから見える景色もある
  • それを推進したリーダーは何を得るのか
    • 組織に向き合う経験自体価値がある
    • 人の問題は人がいる限り起きるから他の場所でも経験が活用できる

組織と自己組織化とリーダーシップについてわかりやすく言語化されていて共感できることが多かったです。特に「リーダーシップの役目は""を作る」というお話は「そう!そう!そう!」っとうなずいていました。チームビルディングと呼ばれたりもしますが、チームや組織の場がうまく出来ればプロダクトも良くなっていくと思っています。

テクニカルな部分に思いが強い人、プロダクトに思いが強い人、ピープルマネージメントに思いが強い人、ワークライフバランスに思いが強い人、いろんな価値観の人がそろっていて、みんながイキイキ開発できる場を作りたいと思っています。今回はその参考になるお話でした。実験が当たり前の環境を作っていきたい。

発表後のQAで「TECH HAS A COMPASSION DEFICIT(テックには思いやりの欠如がある)」という話がでてきました。テックだけに限った話ではないと思うのですが、分業すると相手の背景が分かりづらくて思いやりが足りてないと感じる場面はありますね。
builtin.com

まとめ

  • 「Re-RSGT! チームの自己組織化、リーダーシップ、スクラム開発で力を発揮するデザイナーについて」に参加した
  • 組織の壁を越えて共につくることが大切
  • 自己組織化された組織を作り、大きな価値を提供する
  • 自己組織化を活性化させるには実験できる環境が大切

僕も自分の考えややってきたことを言語化してこういった場で発表して、誰かの役に立ちたい!頑張らねば。

関連記事

自己組織化にはこちらの本がお勧め
iucstscui.hatenablog.com

思いやりを持つにはこちらの本がお勧め
iucstscui.hatenablog.com

スクラムについていくつか記事を書いています
iucstscui.hatenablog.com

UnityのLayerとSortingLayerとOrder in Layerについて調べた

Unityでボタンなどを配置していると描画順の設定が分からなくなって調べました。描画順を制御する設定は「SortingLayer」「Order in Layer」の2種類です。それとは別に「Layer」という設定があり混乱しました。ややこしい。
なお、描画順は「SortingLayer」「Order in Layer」以外にもカメラの設定の影響も受けるんですが本記事では扱っていません。というか調べきれてません。

描画順に関するドキュメントはこちら
docs.unity3d.com

SortingLayer と Order in Layer

SortingLayer は複数のスプライト(2Dオブジェクト)の順序を設定できます。同じSortingLayer 内はOrder in Layerで順序を設定できます。

docs.unity3d.com

Layer

Layerは描画順に影響ありません。同じレイヤーを表示非表示したり、ライトを照らすかどうかなどに使います。
docs.unity3d.com

動作確認

f:id:iucstscui:20200814012719g:plain
ボタン、テキスト、パーティクルシステムを使って描画順を確認しました。

ButtonやTextはuGUIの一つ

ButtonやTextはuGUI(UnityのUIシステム)と呼ばれます。uGUIは単体で配置できずCanvasの子として配置します。また、今回設定したい「SortingLayer」「Order in Layer」はCanvasにしか設定できませんCanvas内のButtonとButtonの間に別のSpriteを配置したい場合はCanvasを分ける必要があります。さらにCanvasを配置した直後はRenderModeが最前面固定の「Screen Space - Overlay」になっているため、「SortingLayer」などが変更できませんので注意です。RenderModeは「Screen Space - Camera」を選択してください。
f:id:iucstscui:20200815000010p:plain

また、同Canvas内のButton等の順番はHierarchyの順と一致します。たとえば、Button2とButton1の並びが下記の場合はButton2が上になります。
f:id:iucstscui:20200814233533p:plain
f:id:iucstscui:20200814233606g:plain

反対にするとButton1が上になります。
f:id:iucstscui:20200814233941g:plain

Particle Systemの画像はスプライト

Particle Systemは「SortingLayer」「Order in Layer」が設定できます。Renderer設定内に「SortingLayer」「Order in Layer」があります。
f:id:iucstscui:20200815000109p:plain

SortingLayerの設定

Sorting Layerの設定項目からAdd Sorting Layer ...をクリックすると、SortingLayerを設定する画面になります。その中でレイヤーを追加したり順番を入れ替えてレイヤーを設定をします。その後、各スプライトの「SortingLayer」を変更します。
f:id:iucstscui:20200815001302p:plain

Order in Layer

同じSorting Layerが設定されたスプライト順が設定できます。入力数値が大きければ前面になります。

今回の設定

今回のヒエラルキーの設定です。
f:id:iucstscui:20200815002732p:plain
Button1-1とButton2-1の間にパーティクルを出現させたかったので、それぞれのCanvasでSorting Layerを別にしました。Particle SystemはButton1-1と同じSorting LayerでOrder in Layerを別にしました。

Sorting Layer順:Default > Btn1 > Btn2 (右が最前面)
CanvasBtn1:Sorting Layer[Btn1] Order in Layer[0]
CanvasBtn2:Sorting Layer[Btn2] Order in Layer[0]
CanvasText:Sorting Layer[Default] Order in Layer[0]
Particle System:Sorting Layer[Btn1] Order in Layer[1]


その結果、以下の挙動となりました。
f:id:iucstscui:20200814012719g:plain

まとめ

  • オブジェクトの描画順は「SortingLayer」と「Order in Layer」が影響
  • uGUIのCanvasは「SortingLayer」と「Order in Layer」が設定できる

フィードバックをもらい続けるために! / Scrum Masters Night! Online 〜第3夜〜に参加した

2020/08/07 に開催された【Dev向け特別セッション開催!】Scrum Masters Night! Online 〜第3夜〜に参加しました。日々スクラムと向き合い学んでいますが、いろんな方と話すといつでも新しい発見がありおもしろいなーっと思います。今回のScrum Masters Night! もそんな場でした。日常に少し変化をつけるという意味でも勉強会はとても良いきっかけになります。

smn.connpass.com

今回は特別セッション「スクラムを実践する上で "設計" をどのように考えるか」とOSTの2本立てでした。OSTはテーマが15個以上も出ていて盛り上がっていましたよ。今回も新しい発見があったのでさっそく現場で活用していきます。それでは、内容のまとめていきます。

今回の内容

  • スクラムを実践する上で "設計" をどのように考えるか」
  • OST

スクラムを実践する上で "設計" をどのように考えるか」

株式会社Odd-e Japan CTO 金井様

  • Developerの視点から考えるべきこともある
  • イテレーティブなマネージメントはイテレーティブなエンジニアスキルがないと痛みを伴う
  • BDUFのマインドセットを持っているとフィードバックの数が下がる
    • BDUF(Big Design Up Front):最初から大きな設計が効率的であるという考え方
    • 大きな設計に慣れている人スクラムを実践すると2、3スプリントでコードがつぎはぎ状態になり品質が落ちる
  • インクリメンタルな設計の発想を持ちましょう
Q&A

・NoCodeな環境ではTDDなどが難しいですが、どう考えますか?
TDDも一つのプラクティス。実践して合わないと判断したのであれば、その現場では正解です。大切なのはスプリントごとにフィードバックがもらえるモノが作れていることです。

・プロダクトの特性上、手戻りコストが大きい場合のアプローチはありますか?
インクリメンタルな設計が向かない領域もあります。考え続けることが大事。今決めるべきことと後でもよいことがあると思います。

・イテレーティブなマネージメントとイテレーティブなエンジニアスキル。どちらから学びをスタートするのが良いと考えますか?
イテレーティブなスキルの習得は簡単ではないので、実験できる場で試す方がよいです。イテレーティブなエンジニアスキルは単独で学べるため始めやすいと思います。

まとめ

まず、思ったのがイテレーティブインクリメンタルってなんだっけな?です。正直、この違いを分かっていなかったので調べました。以下のブログが分かりやすかったです。

どちらも少しずつ作るのですが、少しずつの作り方が違います。インクリメンタルは完成度の高い部品を繰り返しを作ります。例えば目を描いて、次に鼻を書いて・・・っと作っていきます。イテレーティブはラフ画を描いて、徐々に全体を仕上げていきます。インクリメンタルは完成するまで全体像が見えませんが、イテレーティブは早い段階で全体像が見えます。

今回の発表はイテレーティブなマネージメントにはイテレーティブなエンジニアスキルが必要だということです。納得ですね。例えば、スクラムを実践する場合はXPのプラクティスも一緒に採用しないと苦しい開発になってしまうよっていうお話です。平鍋さんも「ライトウィング」と「レフトウィング」という表現でマネージメントとテクニカルな2つの攻めが必要だと書かれています。

すでにレガシーなコードを抱えているプロダクトはTDDなんて夢のまた夢って思ってしまいますが、TDDが唯一の解ではないと思いますので、毎スプリントフィードバックを貰えるモノを安全に作り続けるにはどうすれば良いのかっと悩み続けたいですね。

今回、登場した言葉「インクリメンタルな設計」を始めて知ったのは牛尾さんのブログです。スクラムに興味を持っているとピープルマネージメントによりがちですが、それと同じぐらいエンジニアリングのテクニックも重要ですね(耳が痛い)。
simplearchitect.hatenablog.com

OST

ソフトウェアエンジニアからスクラムマスターに転身するときに気を付けることとかアドバイスとか

  • ソフトウェアエンジニアからスクラムマスターになったとき
    • プロダクトへの貢献が直接的から間接的に変わる
    • チームを見ることが増える
  • スクラムマスターをしてる自分は、コードを書いてる自分と違ってどういう価値を出せてるんだろうと悩む
  • スクラムマスターになったとき、意地でもプロダクトのコードは書かない
    • チームに任せて成長を促す
  • 今、SMに感じている価値を考える
  • 開発メンバーやPOからフィードバックをもらって成長する
    • フィードバックくれと言っても貰いにくい
    • SMから開発チームに相談して、フィードバックもらえる。

スクラムがソフトウェアの分野から登場しているので、ソフトウェアエンジニアからスクラムマスターに興味を持つ人は多いと思います。私もそうです。

その場合の有利な点はソフトウェア開発が分かることだと思います。スクラムマスターの責任に開発チームの成長があります。ソフトウェアエンジニアの気持ちが分かったり、技術が分かる点でソフトウェアエンジニアからスクラムマスターになることはメリットだと思います。

しかし、同じくピープルマネジメントも大切になるので、そちらは改めて学びなおす必要がありますね。利点を活かしつつ、チームの能力を最大化する知識を学んでいくと信頼されるスクラムマスターになれるかなって思いました。

フィードバックを欲しがる人は活躍しているという話もありました。とても参考になりました。ネガティブフィードバックってお願いしても貰えないことも多いです。他人の行動を批判的に表現することは勇気とパワーが必要ですよね。そこで、相談形式で意見を引き出す方法は良いと思いました。「僕はここが出来てないと思うんだけどどうかな?」素直に分からないや困っていることを相談して、自身の足りないことを聞きたいと思います。

スクラムマスターとして視座を上げる方法は?

  • 色んなスクラムマスターと意見交換
  • 違う立場にたって考える

視野を広げる、視座を高くする。よく聞く言葉ですが具体的な行動って思いつかないですね。

色んなスクラムマスターと意見交換は良いアドバイスだと思いました。色んな方の意見を聞くことで視野を広げるヒントがもらえると思います。

社内に他のスクラムマスターがいればその方々と話したり、こういう社外のコミュニティに参加して話をするのが良さそうです。

まとめ

  • Scrum Masters Night! Online 〜第3夜〜に参加しました
  • エンジニアリング面でもマネージャーメント面でもフィードバックは大切
  • 毎スプリント安全にモノを作る方法を考える
  • いろんな方と話して視野が広げる

運営のみなさん、参加されたみなさん、ありがとうございました!

Unity:UxmlNamespacePrefix could not be found の エラーを解決した

Unityのビジュアルスクリプティングツール『Bolt』が無償になったので使ってみよう!とアセットをインストールするとエラーが発生し躓いたのでその解決方法をまとめます。なお、今回はエラーの解決方法のみを紹介します。『Bolt』のまとめは別記事になります。

Boltの公式記事
blogs.unity3d.com

環境

Unity 2019.3.7
Bolt 1.4.12

発生したエラー

UnityをUnityHubから起動して、アセットをインストールすると以下のようなエラーが発生しました。

Library\PackageCache\com.unity.package-manager-ui@2.0.13\Editor\AssemblyInfo.cs(7,12): error CS0246: The type or namespace name 'UxmlNamespacePrefixAttribute' could not be found (are you missing a using directive or an assembly reference?)


Library\PackageCache\com.unity.package-manager-ui@2.0.13\Editor\AssemblyInfo.cs(7,12): error CS0246: The type or namespace name 'UxmlNamespacePrefix' could not be found (are you missing a using directive or an assembly reference?)

・・・

どうやら、UxmlNamespacePrefixが見つからないようです。

原因

package-manager-ui がなんらかの原因で壊れていてエラーになっています。
answers.unity.com

解決方法

package-manager-ui を削除することでエラーは解消します。

削除方法

Unity Editorのメニューバー→ウィンドウ→Package Managere→package-manager-ui を選択してRemove
f:id:iucstscui:20200731225241p:plain

まとめ

  • Unity でアセットを試そうとすると関係のないエラーで止まった
  • package-manager-ui に問題があり、削除することで原因は解消される

モダン・ソフトウェアエンジニアリングのエッセンスに参加して、Essenceはふりかえりに使えそうだと思った

セミナー: モダン・ソフトウェアエンジニアリングのエッセンスに参加しました。
smartse.connpass.com

本イベントで紹介されたEssenceEssence means Practice Freedomと紹介されるように、それぞれの方法論で使われているプラクティスを自由かつ適切に扱うためのフレームワークです。


ぼくはUML(統一モデリング言語)のプラクティス版、統一プラクティス言語だと理解しました。角さんのスライドでは何度もUMLと同じくらいの希望と絶望を持つといいと思うと紹介されていました。


本イベントは書籍「モダン・ソフトウェアエンジニアリング」がBaseになっており、著者のIvar Jacobsonさんや翻訳者の角征典さん、監修の鷲崎弘宜さんなど著名な方が集まる贅沢なイベントでした。

今回のオンラインイベントは以下のツールが使われていました。
発表:Zoom
質問受付:Slido

発表資料など

ビデオ講演: Modern Software Engineering with Essence

モダン・ソフトウェアエンジニアリングのエッセンス


ソフトウェアエンジニアリングとEssenceの広がり

ビデオ講演を解説された平鍋さんのブログ

anagileway.com

角さんのQAの回答集

20200721_essence_QandA.md · GitHub

感想

Essenceの説明から受けた印象

スクラムやオブジェクト思考やXPなど色々な方法論で使われるプラクティスを組み合わせて自分のプロジェクトに取り入れるためのフレームワークだと理解しました。個人的にはEssenceのフレームワークに合わせて自分のプロジェクト状態を可視化し、取り入れるべきプラクティスを見つけるときに便利だと感じました。

始めのうちはパタンランゲージに近い印象を受けたのですが、パタンランゲージよりも厳格なルールがあるなぁという印象です。パタンランゲージはイキイキしている分カオスな感じですが、Essenceは統制が取れている分、おとなしい感じです。

ふりかえりに使えそう

角さんの紹介にあったアクティブティスペースは自分のプロジェクトの足りていない部分を見つけ出すのに良いフォーマットだと思いました。自分たちのプロセスに当てはめてみると気付けていない抜け漏れを見つけられます。

また、逆に自分たちが取り組んでいて言語化されていないプラクティスを形式知にするきっかけになると思いました。ペアプロなど、すでに言語化されているプラクティスをアクティビティスペースに当てはめていくと、特定のプラクティスを採用してないけど自分たちで決めたやり方でうまくやれていると分かりそうです。それを言語化すると他のチームに伝達できます。

ラクティスを発見して広めていく姿はEssenceが目指す世界だと感じました。

Essence自体もひとつのプラクティスとして活用するとよさそう

Essence means Practice Freedomの言葉があったように、ソフトウェアの分野で使われているプラクティスを自由に組み合わせて応用できる世界を目指して登場したのがEssenceです。みんなが自由にプラクティスを使えるように統一しようとしています。

そうであるなら、Essenceのプラクティスも同じように自分たちのプロジェクトに応用し活用するとよさそうだと思いました。

まとめ

  • モダン・ソフトウェアエンジニアリングのエッセンスに参加しました
  • Essenceは自分たちの状態を可視化するのに力を発揮するフレームワーク
  • 可視化できると足りていない部分が見える
  • 可視化できると自分たちの工夫で対応している部分が見えてプラクティス化ができる
  • ラクティス化が伝達可能な形式で増えていくと、Essenceが目指す世界に近づけそう

書籍はまだ読めていないので読んでみようと興味が出たイベントでした。

補足資料

本ブログをまとめるにあたり、Essenceを調べたので参考の記事をまとめておきます。

SEMATの活動の結果がEssenceです。そのSEMATの Call for Actionを平鍋さんが翻訳されています。

https://blogs.itmedia.co.jp/hiranabe/files/SEMAT-vision-ja.pdf

別の勉強会で発表された鷲崎さんのスライド。分かりやすいです。

SEMAT JAPANのサイトです。

www.semat.jp

Martin Fowler氏のブログですが、SEMATには否定的な立ち位置です。

bliki-ja.github.io

EssenceとScrum

www.youtube.com

効果的な問いでファシリテート上手になる / 問いのデザインを読んだ

問いのデザインを読みました。

問いのデザイン: 創造的対話のファシリテーション

問いのデザイン: 創造的対話のファシリテーション

会議のファシリテート、1on1、ワークショップ。あらゆる場面で活躍する「問い」はプロジェクトの成否や人生を変える可能性を持っています。固定観念が解き放たれるような、新たな気づきが得られるような。そんな「問い」のデザインが得意になれば開発者としてもマネージャーとしても強みになります。

本書は「問い」をデザインする技術が学べます。

目次

序論 なぜ今、問いのデザインなのか
PartⅠ 問いのデザインの全体像
 1章 問いのデザインとは何か
  1.1. 問いとは何か
  1.2. 創造的対話とは何か
  1.3. 基本サイクルとデザイン手順
PartⅡ 課題のデザイン:問題の本質を捉え、解くべき課題を定める
 2章 問題を捉え直す考え方
  2.1. 問題と課題の違い
  2.2. 課題設定の罠
  2.3. 問題を捉える思考法
 3章 課題を定義する手順
  3.1. 目標を整理する
  3.2. 目標のリフレーミング
  3.3. 課題を定義する
PartⅢ プロセスのデザイン:問いを投げかけ、創造的対話を促進する
 4章 ワークショップのデザイン
  4.1. ワークショップデザインとは何か
  4.2. ワークショップの問いをデザインする
  4.3. 問いの評価方法
 5章 ファシリテーションの技法
  5.1. ファシリテーションの定義と実態
  5.2. ファシリテーターのコアスキル
  5.3. ファシリテーターの芸風
  5.4. 対話を深めるファシリテーションの技術
  5.5. ファシリテーションの効果を高める工夫
PartⅣ 問いのデザインの事例
 6章 企業、地域、学校の課題を解決する

問いによって変わる視点

本書で「問いのテイスティング」として思考が変わる2つの問いが紹介されています。

A.あなたがこの本を手に取った理由は?
B.あなたがこの本を読み終えるころに得ていたいものは?

AとBを比べると、Aは困っている理由が返ってきて、Bは困っている理由を解決する手段が返ってくると思いました。同じようなことを聞いても、聞かれた側の思考が変わります。これが問いの力で問いの可能性です。

このAとBのどちらが効果的な問いかについては解決したい問題によって変わります。

問いも学習しながら変えていく

問いの基本サイクルが紹介されています。問い→対話→発見→問い→対話→発見→・・・と問いによって生まれた対話から新しい問いを見つけて持続的に学びます

問題の本質が明らかになっていない場合は問題の本質を明らかにする問い使って対話して見つけていきます。問題の本質が見つかれば新たな問いによって解決案を見つけます。1度の問いですべて解決するのではなく、問いを繰り返して具体的な行動に落とし込めるまで進めます。

ブレストなどで新しいアイデアを出そうしますが、どうも新しさに欠けるアイデアがだったり、そもそも意見が出ない経験があります。その原因は全員が本質を掴めてないままファシリテートしていたなぁと思い返しながら読んでいました。解決したい問題の本質を全員で理解してから新しいアイデアのブレストするべきだったと反省しました。


対話については過去に読んだ「他者と働く──「わかりあえなさ」から始める組織論」が参考になりますし、参考図書としても紹介されていました。
iucstscui.hatenablog.com

問題をあらゆる角度からせめてみる

「問い」の力を知ったので効果的な問いを設定したくなります。しかし「じゃあ、設定しよう!」と考えてみても簡単に作れるものではありません。本書では5個の思考で問題を捉えて問いを考えてみることが提案されています。

  • 素朴思考
  • 天邪鬼思考
  • 道具思考
  • 構造化思考
  • 哲学的思考

この5つの思考法に限らず人によって得意な思考法があると思います。そしてそれが固定観念を生み出してしまいます。ひとつの問題を多角的な思考で考え、問いを設定すると今まで気づかなかった考えや新しいアイデアが生まれるので、考えの引き出しを増やしておけば煮詰まったときに次の問いが出せますね。

問いを活用したプロセス

問いを活用したプロセスとしてワークショップの構造が紹介されています。ワークショップは「導入」「知る活動」「創る活動」「まとめ」の構造で考えます。「導入」「知る活動」はワークショップのテーマに関する知識や視点を学び、「創る活動」「まとめ」は新たな意味やアイデアを創ります。それぞれの部分で効果的な問いを使い、メンバーの固定観念を外したり、新たな気づきを与えます。

大事だと思った点は「知る活動」です。いきなり新しいアイデアを考えるのではなく「創る活動」に必要な知識や経験をメンバーで対話する時間をつくって「創る活動」をより効果的にします。

ワークショップのデザインを知る前は概要を説明して出来るだけブレストの時間を取ろうと考えていました。今後は「知る活動」の時間を設けるようにします。

まとめ

  • 「問い」は会議のファシリテート、1on1、ワークショップ多くの場面で活躍する技術
  • 多面的な角度で問題を捉えることで良い「問い」を設定できる
  • ワークショップは「創る活動」も大切だが、「知る活動」も同じ以上に大切