RSGT2018 Day1レポート その②

イベント報告 スクラム

その①よりの続きです。

ゲーム開発現場の中心で心理的安全性を叫ぶ

森田さんと田口さんによるゲーム業界での話。

ゲーム開発現場の中心で心理的安全性を叫ぶ [RSGT2018]

グッときたところ（森田さんパート）

  • 自分の中で勝手に決めつけてあきらめていたところがあった。
  • LT大会でアピールのために社長の席の近くでやった。
  • Chatworkで「言える化」を推進する。
  • 外を見るより、中を大切にしていればきっと輪が広がる。

感想 （森田さんパート）

人と人をつなぐ行動を地道にやっているだけではなく、周りへのアピールも配慮しているのが印象的でした。 LT大会で紹介されてたペンギンの見分け方のスライドが気になります。。。

グッときたところ（田口さんパート）

  • ゲームは面白さや手触りを大事にしているのでやってみようは多い。
  • スクラムの3本柱を支えるのは「心理的安全性」

感想 （田口さんパート）

ストリートファイター4に関わってた人とのことで、感慨深いものがありました。 特にスクラムで大事にしている透明性は、心理的安全性の上に乗っているという失敗談？が面白かったです。

Scrum プロジェクト開始のベストプラクティス / Best Practice for Initiating Scrum Project

いつもブログを読ませてもらっているRyuzeeさんのお話。

Scrumプロジェクト開始のベストプラクティス #RSGT2018 | Ryuzee.com

グッと来たところ

  • ベストプラクティスはないｗ
  • カードカルトの話。
  • インセプションデッキはあくまでF/Wであり、共通理解と共通理解すべき領域を決めるもの。
  • 作るものの特性が分からないと開発の仕方は決まらない。
  • クネビンフレームワーク。
  • プロジェクトを成功させたかったら、十分条件ではじめなさい。
  • 非機能はアーキテクト、コスト、納期に影響がある。
  • 検証はタイムボックスにして時間を区切る方が良い。
  • ツールセットは教育しなさい。さもないと痛い目を見る。
  • テスト自動化についてはスクラムでは規定していないけど”必須”。
  • 外から連れてきたスクラムマスターは社内情報にアクセスできない可能性があるのでうまく行かないことがある。
  • 古株の内部の人がスクラムマスターをやると各部署との調整がスムーズにいくことが多い。
  • スクラムマスターの個人の評価は要らないと思う。チームが成果を出してれば十分じゃない？

感想

理想と現実の話があり、実践的すぎる話でめっちゃ勉強になりました！ 実際に取り組む人は必ず聞いた方がいいと思うくらいの話でした。 とくに非機能はアーキテクト、コスト、納期に影響あるというところは、かつてのように機能を作り上げてから非機能を入れ込んでいくという人達に聞いてほしい一言です。 またRyuzeeさんがテスト自動化が必須という話をしてくれたことに意味があると思います。アーキテクチャーからガンガン変更したらガンガン壊れますからね。

昨年はチケットが取れず無念の敗退をしたRSGTだが、今年はなんとか参加できて本当に良かった。 仙台のスクラムマスター同期にも会えたし、ホントありがたい。

RSGT2018 Day1レポート その①

スクラム イベント報告

今年こそはきちんとブログを書くぞ！と決意を新たにしてやっていきます。

さて新年もそうそうですが、Regional Scrum Gathering Tokyo 2018（RSGT2018）に来ました。 年々参加者が増えてプラチナチケットの様相を呈してます。 今年はJoy Incのリチャードさんが来るということでめっちゃ楽しみにしていました。 そう言っておきながら、サインしてもらうために用意していた本を忘れてしまったので現地で4冊購入です。 一つは自分、一つは友人用、一つは会社の社長、最後はイベント用です。

f:id:nemorine:20180111092629j:plain
4冊のJoy, Inc.

スライドはアップされていると思うのでいつものように自分がグッと来たところを中心に書いておきます。

Build a Workplace People Love – Just add Joy

Joy, Inc.の原作者であるリチャードさんの講演。川口さんが（たぶん）一部日本語に直してくれているのでスライドだけでも読みやすいです。

Richard Sheridan - Build a Workplace People Love – Just add Joy - Speaker Deck

なぜ喜びなのか？

  • 13歳からプログラミングを始めた。
  • リチャードさんの人を喜ばせる原体験は、子供時代にお母さんを喜ばせるために一人で組み立てた棚。
  • エンジニアの喜びとは「自分の作ったものが、世に出て、誰かに使われること」。これに尽きる。

メンローでやっている取り組み

  • 仕事は必ずペアで実施する。
  • スタンドアップミーティングは毎朝10時に60人～70人（犬も）で実施する。そのときバイキングの兜の角をペアで持つ。
  • オフィスの壁を取り払ったが、これはオープンオフィスではなく、オープンカルチャ。騒音も受け入れる。
  • デモはShow＆Tellといって、お客さんにデモをしてもらう。これによりエンジニアが集中する。
  • Planning Gameカードはタスクのサイズと紙のサイズが連動していて、まるでブロックのように1イテレーションで入れるアイテムを決めることができる。

伝えたいこと

  • 実験していこう（子供と一緒に出社、犬を連れてきた話） fight fear, embrace change, Run the experiment
  • 赤ちゃんが一緒だと顧客がやさしくなる。
  • 意図的に文化を形成していくことも大事。

人の採用

  • メンローでは採用時にペアにして、ペア作業をやってもらう。その過程を見て採用を決める。

感想

ここに書いた以上に濃密な話がいっぱいだったので、リチャードさんの話だけでも札幌から来た甲斐あったーと感じました。 かなり人に焦点を当てて、みんなが快適に、そして喜びを感じる文化と仕組みをしっかり整備しているようです。 良い文化が良い人を醸成していくんだろうなぁと感心しました。近いうちにメンローに見学に行きたいなぁ。 グッと来た取り組みはShow＆Tellで、自社で実験してみたい。

心が折れてもソシキ・カイゼンを続けられるたった一滴の魔法

市谷さんとKAIZEN JOURNEYという本を出す新井さんの話。

心が折れてもソシキカイゼンを続けられるたった一滴の魔法 - Speaker Deck

感想

自称普通の人の新井さんが、心が折れそうなことがあっても、何とかやっていくための処方を教えてくれました。 自分も話を聞きながら、コミュニティの仲間はいいなぁと再認識しました。 リチャードさんの話とオーバーラップすることもあり、とても良かったです。 しかし、一滴だと思っていた魔法が二滴目があることと、「その人生で迷ったら、駅すぱあとで。」という名言が頭から消えません。 新井さんが普通の人ではないという疑惑が確信に変わった瞬間でした（笑

サーバント・リーダーシップを掘り下げて考えましょう

近頃自分の中で大ヒットした『日本企業の社員は、なぜこんなにもモチベーションが低いのか 』の著者であるロッシェル・カップさんのセッション。

日本企業の社員は、なぜこんなにもモチベーションが低いのか?

日本企業の社員は、なぜこんなにもモチベーションが低いのか?

サーバント・リーダーシップ を掘り下げて考えましょう

グッと来たところ

  • 上の人が変わるのを期待してても仕方ないので、まず自分が変わる。（ガンジーの言葉を引用して）
  • Googleの社内調査では 人間関係スキル ＞ 技術スキル。
  • スクラムマスターは相手に考えさせる質問をする必要がある。
  • 相手にフィードバックするときは否定的な表現を避ける。

感想

セッション後に通常のコマンド型のリーダーからサーバントリーダーへ変わるキッカケはどんなものがあるかを質問してみました。 日本だと恐怖が支配しているために、なかなか変われないとのことです。 まずは安全な場を作らないと、変化することができないと言っていました。いやー 恐怖が支配するって修羅の国ですなぁ。。。 google の話は面白そうなので後で読みたいです。

Google Leadership Lessons and Rules | Jesús Gil Hernández



ということで、その②に続きます～

ペルソナのコツ

アジャイル開発

皆さんは開発やテストでペルソナを作ることがありますか？ 作っているとしたら、どうやって、どこまで作りこんでいますか？ガイドラインはありますか？今回は自分が思うペルソナの作り方について考えていきたいと思います。

それでは最初にペルソナ定義を見ていきましょう。

ペルソナ（心理学）～ Wikipedia https://ja.wikipedia.org/wiki/%E3%83%9A%E3%83%AB%E3%82%BD%E3%83%8A_(%E5%BF%83%E7%90%86%E5%AD%A6)

ペルソナデザイン https://ja.wikipedia.org/wiki/%E3%83%9A%E3%83%AB%E3%82%BD%E3%83%8A%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3

元々は心理学の用語であの有名なユングが使っていたんですね。 マーケティングなどでは『最も重要で象徴的なユーザーモデル』とのことです。

作るメリットは・・・

「ペルソナ」導入により得られる4つのメリット

一人の顧客像に対するデータを徹底的に分析することで、ユーザの実態に対する理解が深められる 「思い込み」や「関係者間の意識のズレ」を防ぎ、精度の高いユーザ視点を持つことができる 担当分野の異なる関係者間でも、同じ顧客像を常に意識することが容易となるため、議論の質が高められる 価値観の多様化とニーズの細分化が進む中、ユーザの本音を理解し、コミュニケーションを深めていくために効果的である 参考) https://smmlab.jp/?p=20107

自分もテスト設計コンテストのときに作りましたが、どこまで作ればいいのかというのがモヤモヤしていました。

さてそれでは実際によくありがちなペルソナを作ってみましょう。

電気ポッドを使うペルソナ その①

尾湯 沸（おゆ わかす）
北海道大学の学生。
出身は音威子府で現在は札幌の麻生で一人暮らし。年上の彼女を絶賛募集中。
バイトはファミレスで深夜勤務を週4で頑張っている。
カップラーメンが好きで1日少なくとも1食はカップラーメンを食べる。毎月実家から３０個のカップラーメンを送ってもらっている。
趣味は貧乏旅行で、一年に一回はバックパックでアジア諸国を回る。

それではこのペルソナの問題点を挙げてみましょう。

  • 作るときにユーザーの声や統計情報などを参考にせず、自分の経験や思い込みで作っている。
  • ペルソナに書かれている情報のほとんどが製品に不要な情報である。
  • 特化しすぎていてカップラーメン専用ポッドのようなペルソナになっている。
  • そもそもこのような行動をする人が極少数である。

どうしても作っていると詳細設定をするのが楽しくなってしまうんですよね。。。 JaSST北海道で楽天の川口さんに会ったときに、どこまで作ればいいのかという疑問をぶつけてみたのですが、『ペルソナは検証可能じゃなければならない』という回答をもらいました。 ペルソナはあくまで仮説ですので、川口さんの言葉は当たり前なのかもしれません。ただ自分はこの回答でかなりスッキリしました。上記のペルソナも行動様式が似ている人を集めるのは不可能に近いと思います。

まずは不要な情報を削除して、シンプルにしてみましょう。

電気ポッドを使うペルソナ その②

尾湯 沸（おゆ わかす）
大学生で現在は一人暮らし。
毎朝コーヒーを飲む。週に少なくとも3食はカップラーメンを食べる。
使い終わった電気ポッドのお湯を捨て忘れることがよくある。

ポッドに関わる情報はありますが無味無臭すぎますし、あるシチュエーションでどういう判断や行動をするかは分からないですよね。もう少し性格やこころの奥に持っている欲求を付加していきましょう。

電気ポッドを使うペルソナ その③

尾湯 沸（おゆ わかす）
大学生3年生で現在は一人暮らし。彼女はいない。
朝、頭をスッキリとさせるために毎朝コーヒーを飲む。
好きな食べものはラーメン。外食もするが、少なくとも週に3食はカップメンを食べる。
面倒くさがりで、残ったお湯がそのままになってしまうこともよくある。

どうでしょうか？製品をどう使うかに加えて、行動を決定する一要因である『面倒くさがり』という性格を表すワードを入れています。性格や欲求を入れ込むことで、細かいところまで規定する必要がなくなります。この人だったらこの状況ではこういう行動するだろうな、という共通認識を持つことができます。

最後にもう一つアンチパターンを紹介します。製品には関係ない欲求の付加情報をつけると、その情報に引っ張られてしまい本質を見失うことがあります。

電気ポッドを使うペルソナ その④ アンチパターン【関係ないけど気になっちゃう設定】

尾湯 沸（おゆ わかす）
大学生3年生。現在は同じ大学の1コ下の可愛い系の彼女と付き合っている。
しかしバイト先の先輩女性のことが好きになってしまい彼女と別れるべきか悩み中。先輩とは1日1回以上LINEでやり取りしているので、先輩もまんざらではないようである。
朝が苦手なので目覚めに毎朝コーヒーを飲む。
好きな食べものはラーメン。外食もするが、週に少なくとも3食はカップラーメンを食べる。
片付けが苦手で、部屋のキッチンは洗い物が溜まっていることが多い。残ったお湯がそのままになってしまうこともよくある。付き合っている後輩は家に遊びに来るたびにしっかり片付けをしてくれる。

どうでしょうか？優柔不断という性格を伝えたいのかもしれませんが、もはやポッドをどう使うかより、彼女と先輩女性の恋愛模様に目が行ってしまいますね。ということでこれも個人的にNGかなと思ってます。もちろんペルソナをイキイキさせるためには多少の付加情報は必要ですが、バランスが重要ですよね。

自分なりのペルソナ作成のコツを簡単にまとめると、

  • 検証可能であるかを意識する
  • 性格や欲求を付け加える
  • 気になっちゃう不要な設定は付け加えない

ペルソナに付加情報を加えて具体的にすることも重要ですが、さらにその奥底にあるユーザーの性格や欲求にアプローチするのがより重要だと思います。

ということで有意義なペルソナライフを！！

このエントリはJaSST東北ブログのエントリのミラーになります。

バグをｘｘと呼ぶ

ゲーミフィケーション ソフトウェアテスト

バグをドラゴンと呼ぶという記事が世に出たのが2年前。 http://konifar.hatenablog.com/entry/2015/05/02/003449

そろそろ新しい呼び方を提案していく時期だと思います。

実は考え始めると難しくて、バグに対する３つの行為をうまく置き換える必要があります。

  • バグを見つけた
  • バグを修正する
  • バグを修正した

どれもテンションが上がらないといけないと思います。 どれかだけだとメタファとしては弱くなってしまいます。

例えば、金塊、宝石、お宝などだと見つける方のメタファにはなるけど、修正するほうにはなりにくい。その点ドラゴンは見つけて良し、戦って良し、倒してよしのグレートなメタファです。

ということで、ドラゴンに負けないメタファを考えてみます。 ※昔仙台のテスト勉強会で考えたアイディアも入ってます。

勝手にnemorineランキング。

第5位 昆虫

バグを憧れの昆虫にしてみます。チームのみんなで少年の心を取り戻しましょう。

  • バグを見つけた → ヘラクレスオオカブト見つけた！
  • バグを修正している → 今捕まえてる！
  • バグを修正した → 捕まえた！

第4位 美少女

男性の多い職場ならではのノリ。

  • バグを見つけた → Ｓ級の美少女見つけた！
  • バグを修正している → 今告白している！
  • バグを修正した → 彼女になった！

第3位 肉

なかなかいいメタファだと思いますが、話しているとお腹減りますね。 すぐ品切れになる有名な焼肉店をイメージしています。

  • バグを見つけた → 特上カルビあった！
  • バグを修正している → 焼いてる！
  • バグを修正した → 食った！

第2位 キャバ嬢

美少女よりさらにリアル感が増します。年齢高めのオジサンばかりのチームだとこのメタファがいいかもしれません。

  • バグを見つけた → めっちゃ美人のキャバ嬢見つけた！
  • バグを修正している → キャバ嬢を口説いてる！
  • バグを修正した → キャバ嬢をアフターに連れ出した！

第1位 ねこ

もはや殺伐としたプロジェクトにはこれが必要なんじゃないかと思うくらい ほのぼの感あふれるメタファ。

  • バグを見つけた → あっ三毛猫見つけた！
  • バグを修正している → いま、三毛猫とじゃれてる！
  • バグを修正した → 猫いなくなった！

まー 職場ではなかなかできないと思いますが、 もしやってみた人いれば連絡ください♪

「企画と開発のボーダレス化へ Day1」

イベント報告

今回の勉強会は「企画と開発のボーダレス化へ」。 もうテスト～開発も飛び越して、マーケットの話までやっちゃうTEF道は面白すぎるｗ 講師はCJM（カスタマージャーニーマップ）の勉強会のときにゲストで来ていた内城さん。 今回は2回シリーズのDAY1「インプット編」です。

内城さんはこれまでに200以上の製品開発に関わっているみたい。 もうそれだけですげぇ！！

ワークショップのお題はTV！どんなTVがこれから求められるのか。 お題だけで超楽しそう！！

まずは内城さんからコンセプトのお話。 コンセプトって分かりにくいので、大ヒットしたシャンプーを具体的な例として説明してくれました。 「コンセプトとは、市場で優位なポジションを築くため、どんな価値に重心をかけるか示した約束」 いやー なるほどって感じですね。そして言葉のチョイスがオシャレ。 逆に何でもやるはコンセプトではない！といってました。激しく同意ですｗ

今回のワークで使う思考のフレームワークはとてもシンプル。 「自社の強み」 × 「生活者・市場の潮流」 という二つの観点から新しいTVを考えていきます。

ポストイットとペンを持ちながら、生活者や市場の潮流についてのデータを聞きながら どんどん書き留めていきます。30枚くらいは書いたでしょうか。 面白いキーワードも出てきます。ほんの一部ですが紹介します。

f:id:nemorine:20170607135456j:plain

  • 働きながら余生
  • 多世帯社会
  • コダルト
  • 晩婚晩産化
  • 育ジイ育バア
  • 女性のオス化
  • 生涯独身 男性20%

その後、そのポストイットをグループでまとめて、キラリと光る何かを探していきます。 自分達はユーザー側から、「孤独」というキーワードを見つけて、双方向にやり取りできるような新製品のタネを考えました。 もう一つの方向はテレビの形を変えたらどうかという技術の方からの視点で鏡のように丸だったり、水槽に映すと面白いかもというアイディアが出ました。

参加者から「ターゲットユーザーを絞るということは、他のユーザーを捨てるということではないのか？」という質問がありました。 「捨てるというより、尖らせていくイメージです。ユーザーのさらに奥にある困りごとや感情を掴むことができれば、最終的には他のターゲットにも波及していく」と言ってました。 ルンバの例で、最初は忙しい家族向けだったのが、掃除が大変な老人に好評になったというのを聞いて、なるほどと納得しました。

帰り際に内城さんにマーケティングでオススメの本とかありますか？と聞いたところ、、、 「本ではなく、ヒットしているものについて考え抜くことが重要です」といわれてそれも感動しましたｗ

あっという間の2時間でした。 次回のDay2を楽しみにして、それまで世の中の製品を色々見ていこうと思います。

TEF道イベントの勝ちIBURIの会 ーテスト設計コンテスト優勝記念ー

イベント報告 ソフトウェアテスト

TEF道イベントの勝ちIBURIの会 ーテスト設計コンテスト優勝記念ーに参加しました。

テスト設計コンテストというテストエンジニアの最高峰を決める戦いがあります。 http://aster.or.jp/business/contest/finals.html

そこで優勝した北海道のチームSTUDIO IBURIを招いて、優勝の秘訣を聞きました！ 結論を言っちゃうと、「すごい良かったので他の地域でも是非どうぞ！！」って話です。 3人組みなので、交通費*3くらい。都合10万くらいでいけると思います。

せっかくなのでなかなかなかなか明らかにならない3人の話も書いておきます。

  • みずのり：現職は花屋さん。前職はマネジメント、テスト、モデリング、TOCが得意。
  • MAQ ：現職は薫製屋さん。空いた時間でエンジニア。テスト、コード両方いけるがテスト好き。
  • せーの ：モデリング、コードが好きだが、テストに足を踏み入れた。冷静に見えて熱い男。

いつものように自分がグッときた事を書いておきます。

グッときた事１

品質特性とか既存のフレームワークではなく、顧客の仕様書から言葉を拾い出して丁寧にモデリングしている。 顧客ドメインのモデリング、テスト設計が導出されていた。 ここらへんはDDD（ドメイン駆動設計）の思想が見えた。

グッときた事２

色々な図（ビューといっている）を出しているが、リポジトリは一つであり、見せ方が違うだけというアプローチ。 達成ビューは顧客向け、などこの図は誰のためというのがしっかり考えられている。 変更も考慮していて、astah*というUMLのツールを使って各ビューを作成している。 ここらへんはRDRA（らどら）の思想が見えた。

グッときた事３

クラス図を上手く使ってテストカタマリーを作っている。 is-aとhas-aの関係や、テストの目的、どんなテストをするのかが、一目で分かるようになっている。 ここらへんはクラス図の特性をうまくアレンジしていると感じた。

グッときた事４

プロセス自体もウォーターフォールのように一つずつ完全に決まってから次の工程に行くのではなく、スパイラル的に回して完成度を高めていくやり方。 ここらへんはRDRAやDDDやVSTePと一緒のアプローチ。色々な見方を回すことで足りない箇所を補完していく。

グッときた事５

チームメンバーがそれぞれの役割をこなしている。 特にテストにどっぷり使っていないせーのさんに分かるように説明してもらうことで、花屋と薫製屋の考えも整理されていったとのこと。 そしてそれぞれをリスペクトしているがイイネ！！

最後にせーのさんにモデリングとは何ですか？と聞いてみました。 せーのさん「モデルとは要約力である！」 DDDの増田さんのワークで聞いたフレーズだと思ったけど、今回の経験に裏打ちされた重い言葉でした！！ ※せーのさん的には増田さんからパクったわけではないと主張しているが、ただのツンデレだと思われｗ

まとめると「変なコンサルにお願いするくらいなら、この３人を呼んでみて」って話です。

最後に優勝おめでとう！！北海道から優勝チームが出てくれたってことは意義あることだと思います。

ついでにこの話をより理解するためのトピックは･･･

Fearless Change の導入事例

イベント報告 アジャイル開発 組織

アジャイル札幌のイベントでFearlessChangeの訳者の一人であるヤフーの山口鉄平さんにFearless Changeのお話＋ワークをしてもらいました。 アジャイル、そして自動テストをヤフーではどういう風に導入していくかという生々しい事例を聞ける良い機会になりました。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

山口さんは普及/改善の担当者ですが、やらせる権限はないとのことです。すなわちチーム自身がやる気にならないと改善が進まないとのことです。 山口さんが新しい技術を取り入れるときの問題点は、以下の分け方をしているようです。

  • 技術そのものが知られてない
  • 技術導入の必要性や効果が知られていない
  • 普及の活動計画が求められるものの立てられない
  • 技術に懐疑的で抵抗がある

それぞれについて、山口さんが意識しているパターンを例示してもらいました。 毎日色々な人と話したり、困ってたら助けたり、上の人とネゴを取ったりと地道な活動をコツコツとやってるという印象でした。

f:id:nemorine:20170301084021j:plain

ワークはグループ毎に自分達の問題点出しとその問題点に対するパターンの提示を実施しました。 More Fearless Changeも含めた63パターンを見ながらワイワイやるのはよい練習になると思います。 これはパターンワークショップと呼ばれているものです。

自分がグッと来たパターンは以下の3つです。

  • [22:種を撒く]
  • [34:ちょうど十分]
  • [48:将軍の耳元でささやく]

今回のイベントで心に残っているフレーズは･･･

  • ぶっちゃけると普及の計画は立てにくいｗ
  • 導入時は成功させることが絶対条件なので、確度が高いチームで実施する。[16:イノベーター]
  • 改善の前後のデータを確認して、成長を数値としても実感してもらう。
  • 普及活動は勝てば官軍なので、ホームランではなくヒットを狙う。[2:小さな成功]
  • 偉い人からもジャッジができるように導入の意義をデザインする。[28:経営層の支持者]
  • 社外の人の話を聞いて、やってみよう！って思う人もいる。[27:著名人を招く]
  • あまり説明しすぎない。[34:ちょうど十分]
  • なかなか普及しないラガードの人は必ずいる。
  • 一気に普及するタイミング（キャズムを超えるタイミング）があった。そのときはカンバンがドッと増えた。
  • 実際にはパターンをナチュラルに使えるようになる必要がある。

パターンの知識と実践力＋コミュニケーション能力が求められると感じました。 少しずつでも使っていけたらと思います。

※ カード形式（英語版）のパターンはLinda Risingさんのページに載っています。 http://web.lindarising.info/Fearless_Change.html

※ 川口さんはA4*2枚にまとめてくれています。 http://kawaguti.hateblo.jp/entry/20140228/1393522489

※ Fearless Journeyというゲーム形式でパターンを覚える方法もあるようです。 https://www.slideshare.net/kdmsnr/fearless-journey

# 17.3.2 Fearless Journeyについて勘違いしてたので修正しました。