自分を知り他人を知るふりかえり - エモーションツリー

2020年の12月、社内向けに "ふりかえり会" の第一歩 / The first step to retrospective. - Speaker Deck という発表をしました。 ふりかえりの対象を大きく以下の4種類にわけ、この発表では「アプローチの改善」について主に說明しました。

発表後、人や関係性に対するふりかえりについても聞きたいという声があり「ブログを書きますね」と答えて1年が過ぎていたーー。

お互いを知り合うふりかえり

リモートワークでのチームビルディングは難しい。

同じオフィスで働いていたときは、普段の行動や、会議での表情や振る舞いなどで「この人はこういう人だな」「こういうこだわりがあるんだな」というのがお互いになんとなく分かっていました。 それが、リモートワークになり、お互いの人となりを知る機会が減ってしまったように思います（特にうちのチームはカメラOFF派が多く、顔も見えない）。

そこで、アプローチに関するふりかえりの他に、月イチぐらいでお互いを知り合うワークショップをやろうと考えたのが エモーションツリー です。

エモーションツリー

エモーションツリーは、お互いをより深く知ることを目的に設計したふりかえりワークショップです。

同じ出来事に対しても、人によってその受け取り方や反応は違います。 そうしたリアクションの共通点や違いに目を向け、対話を行うことで、お互いの信念、価値、優先順位、期待などを理解していきます。

コップに水が半分残っているときに「まだ半分ある」と思うか「もう半分しかない」と思うか。 プロジェクトが思い通りに進んでいないときに「楽しい（なにくそ）」と思うか「落ち込んで」しまうのか。

どちらが良い悪いではなく、一緒に働くメンバーが（さらには、まだ知らない自分自身が）何を大事にしているのか、どういうときにどういう思考のクセがでやすいのかを理解し尊重することがこのワークショップの目的です。

グラウンドルール

ふりかえりワークショップを行う上で大事にしたいことです。

• 相手を否定しない
• 分かった風で終わらせない
• 言いにくいことも率直に話す

全体の流れ

ホワイトボードツール等を用いて、おおまかに以下の流れで行います。所要時間は1時間から2時間ぐらいです。

1. [準備] 自分のカラーを決める
2. [思い出し] チーム内の大きな出来事を洗い出す
3. [エピソード出し] その中で発生したエピソードと自分自身の反応をコメントする
4. [コメント付け] 他の人の出したエピソードへ、自分なりのコメントを付ける
5. [対話] 各エピソードごとに付けられたコメントを元に共通点や違いを話す
6. [まとめ] 話して気付いた自分のクセや、よりうまくするための方法を発表する

自分のチームでは miro や jamboard を使って以下のようなボードを用意しました。

1. 準備

エモーションツリーでは、誰の発言かが非常に重要です。 誰が出したコメントなのかすぐに見分けがつくように各々の付箋の色を決めます。

2. 思い出し

ふりかえり対象期間で発生した出来事を洗い出します。 これは、次のエピソード出しのための準備運動のようなもので、粒度は荒いもので大丈夫です。

たとえば、以下のようなものです。

• 機能をリリースした
• どこどこと打ち合わせした
• こういう問い合わせがった
• 売上がどうだった
• ほげほげの会議をした

3. エピソード出し

前のフェーズで出した出来事を元に、より具体的なエピソードと自分のコメントを書きます。

ポイントとしては、「嬉しい」「イライラ」「不安」「悲しい」「ワクワク」など感情が揺れ動いた瞬間のエピソードを出します。 感情が出しにくい場合は、その出来事に対して自分がどういう対応をしたかを書いても良いでしょう。

4. コメント付け

他の人が書いたエピソードと感情の付箋に対し、自分はこう感じた、自分ならこういう風に考える、といったような付箋を生やしていきます。 付箋の意図が分かりにくければ、質問の付箋を生やしていってもよいです。

5. 対話

いくつかのエピソードをピックアップし、対話をしていきます。

「なぜそう思ったのか」「他にも似たように感じることはあるか」「異なった意見を聞いてどう思うか」など、相手の価値観や信念に問いかける形で質問を交わしながら、お互いの理解を深めます。 話したことは、どんどん付箋を追加していくと良いでしょう（ツリーと表現している所以です）。

詳細はふせますが、我々のチームでは、全く逆のコメントを付けた方同士が対話をしていると実は裏では全く同じことを考えていて、しかし過去の経験から違う判断に至ったというのが発覚したり、他にも、落ち込んだときにどう立て直している？とかどういうときに楽しいと思う？など普段の会議だとあまりする機会のない話なども盛り上がりました。

6. まとめ

さいごに参加者それぞれが、対話してみて気付いた自分の価値観や、他人を尊重するために取り組めることなどを学びとして発表します。

実際やってみてどうだったか

チームでトライアル実施をしたところ、「面白かった」「良い取り組みなので継続したい」という声があり、一年弱開催しました。 その後は、ある程度相互理解が進んだこともあってやっていないですが、毎回満足してもらえたと思います。

おわりに

今日は、リモート環境下でのチームビルディングとして設計したエモーションツリーというふりかえりワークショップについて說明しました。

実施しながらどんどん形態を変えていましたが、ある程度形式がまとまったのでもし良ければみなさんのチームでも試してみてください！

Confluenceで ctrl+shift+v を有効にして幸せペーストできるようにする

一般に、スタイルなしにペーストするときは ctrl+shift+v または command+shift+v するが、Confluence にはすでにそのショートカットが設定されており、うまく動かない。 そこで、Confluence上のキーボードショートカットを無効にすることで、スタイルなしにペーストできるようにする。

インストール方法

1. Tampermonkey( https://www.tampermonkey.net/ ) をインストール

2. https://gist.github.com/silvers/fad3f99ec8ef288cb116a7afc86ed4c2 を開き Raw をクリックするとTampermonkey でインストールしますか？と言われるのでインストールする

ソースコード

gist.github.com

Confluence は TinyMCE を使っているので、TinyMCE のショートカットを削除してあげているだけ。 他にも邪魔なショートカットがあれば同様のやり方で、消すことが出来る。

Confluence の検索を OR から AND にする UserScript を書いた

Confluence の検索には罠があり直感的な検索ができないので、それをいい感じに検索できるようにしました。

Confluence: Change from OR search to AND search. · GitHub

Confluence 検索の闇

その1. 二文字ずつ分割して検索

Confluence を日本語で使っている人はおそらく検索インデックスとして CJK を利用していると思います。 CJK にした場合、単語区切りではなく、bi-gram（検索文字列を2文字ずつ分割）で全文検索を行います。

https://<YOUR-CONFLUENCE-URL>/explain.action?queryString=東京特許許可局 で細かい挙動を確認することができます。

query:
((((spanNear([title:東京, title:京特], 5, false) spanNear([title:東京, title:特許], 5, false) spanNear([title:京特, title:特許], 5, false) spanNear([title:東京, title:許許], 5, false) spanNear([title:京特, title:許許], 5, false) spanNear([title:特許, title:許許], 5, false) spanNear([title:東京, title:許可], 5, false) spanNear([title:京特, title:許可], 5, false) spanNear([title:特許, title:許可], 5, false) spanNear([title:許許, title:許可], 5, false) spanNear([title:東京, title:可局], 5, false) spanNear([title:京特, title:可局], 5, false) spanNear([title:特許, title:可局], 5, false) spanNear([title:許許, title:可局], 5, false) spanNear([title:許可, title:可局], 5, false))^2.0) (spanNear([contentBody:東京, contentBody:京特], 5, false) spanNear([contentBody:東京, contentBody:特許], 5, false) spanNear([contentBody:京特, contentBody:特許], 5, false) spanNear([contentBody:東京, contentBody:許許], 5, false) spanNear([contentBody:京特, contentBody:許許], 5, false) spanNear([contentBody:特許, contentBody:許許], 5, false) spanNear([contentBody:東京, contentBody:許可], 5, false) spanNear([contentBody:京特, contentBody:許可], 5, false) spanNear([contentBody:特許, contentBody:許可], 5, false) spanNear([contentBody:許許, contentBody:許可], 5, false) spanNear([contentBody:東京, contentBody:可局], 5, false) spanNear([contentBody:京特, contentBody:可局], 5, false) spanNear([contentBody:特許, contentBody:可局], 5, false) spanNear([contentBody:許許, contentBody:可局], 5, false) spanNear([contentBody:許可, contentBody:可局], 5, false)))^4.0) title:"東京 京特 特許 許許 許可 可局"^2.0 contentBody:"東京 京特 特許 許許 許可 可局" ((title:東京^2.0 title:京特^2.0 title:特許^2.0 title:許許^2.0 title:許可^2.0 title:可局^2.0) (contentBody:東京 contentBody:京特 contentBody:特許 contentBody:許許 contentBody:許可 contentBody:可局) (content-name-unstemmed:東京 content-name-unstemmed:京特 content-name-unstemmed:特許 content-name-unstemmed:許許 content-name-unstemmed:許可 content-name-unstemmed:可局))

その2. 単語を並記はOR検索

また、Confluence の検索エンジン Lucene では、ANDやORを明示的に指定する必要があり、指定しない場合（スペースの場合）ORとして扱われます。

「Confluence 検索」と検索したとき:

• 期待するもの：「Confluence AND 検索」
• 実際の動作：「Confluence OR 検索」

いい感じにするUserScript

2つの UserScript を書きました。

confluence-replace-search.user.js

• ヘッダーにある quick-search で開くパネルが対象
• 入力と同時にクオーテーションとANDを差し込んでくれる

confluence-suggest-search.user.js

• 検索ページ ( /dosearchsite.action ) が対象
• 検索後、クオーテーションとANDを差し込んだものを提案してくれる

インストール方法

ユーザの場合

1. Tampermonkey( https://www.tampermonkey.net/ ) をインストール
2. ↑のリンクを開くと Tampermonkey でインストールしますか？と言われるのでインストールする
3. replace-search のほうは、 @match をあなたの Confluence URL に書き換える（suggest-search は書き換えなくても動きます）

管理者の場合

全ユーザに反映させたい場合は、いい感じにソースコードをコピーして、管理画面のカスタムHTMLに貼り付けてください。

社内外で読書会を開催するときのパターンあれこれ

いくつか読書会を開催してきたので、振り返りも兼ねてそれぞれの良いところと悪いところをメモ程度にまとめてみる。自分がやってきてこうだった、という内容なので、他のもっと進行がうまい人がやったなら違う結論になりそう。参考程度に。
分類名や分類の仕方は適当。もっと適切な名前あるかも。

読書会のいいところ

まず最初に読書会の意義について。

• インプットもアウトプットもあり、フィードバックももらえる
• ひとりでは辛い本を読むモチベーションになる
• ひとりだとついつい読み飛ばしてしまうところをじっくり考える機会になる
• 自分が感じたことや、自分の意見をまとめて言葉にする練習になる
• 自分とは全然違う意見を聞いて議論することができる
• 共通言語ができる

交流会

本を持ち寄って、ご飯食べたりお酒飲んたりしながらワイワイ本について話す。
一人ずつ自分の持ってきた本を5分程度で紹介する時間などを取ると会も引き締まって良い。交換会は、いらない本持ち寄り会になる場合もあってなんともなーという感じになることもある。
少人数から大人数まで対応可能。

良い点

• 楽しい
• 普段興味のない本に触れることができる
• いろいろな意見や考え方を聞くことができる
• 短い時間で本を紹介するには読み込む必要があり理解が深まる

悪い点

• 趣味が合わない人が多いと辛い感じになる
• 主に紹介と雑談なので特に結論が決まるということがない

毎回違う本好きなメンバーとワイワイして、刺激を受けるのにおすすめ。

その場で読む読書会

予習は不要。参加者はそれぞれ本を持ってきて、その場で読んで、感想や意見を言い合う方式。10人程度が限度。
読みながら話してもいいが、読む速度が違う人がいると話が合わないので、節とかページで区切って全員が読み終わってから話すのが良い。
その際、札みたいなものを用意して、読み終わったら札を倒す方式にすると全員が読み終わったのが分かりやすくてよい（立てるより倒すほうがわかりやすい）。
また、全員が読み終わるまでの時間を記録したり、会が終わったときに読み終わったページ数を記録するのを続けると、だんだんと読む速度が上がっていくのがわかって楽しい。

良い点

• 事前の予習がいらないので、忙しい人に向いている
• 予習に合わせて話す必要がないので、じっくり話したいところに時間を割いたり、盛り上がらなかったらひたすら読み進めるみたいなことができる
• 疑問点をすぐに解消できるので、わからないまま次を読むことがない

悪い点

• 小出しに読むと分からない系の本には向かない（逆に技術書とかは良い）
• 読む速度が遅い人が遠慮しがちになる
• 問題提起をしたり積極的に話す人がいないと、「うん、なるほどね…」みたいな感じで終わりやすい
• 参加者全員が本を持っていないといけない

事前に読む時間が取れない場合や、関連する話や事例などをじっくり吟味して話し合いたいときにおすすめ。

輪講形式

大学のゼミとかでよくやるアレ。
章ごとに担当を分け、担当者が本の内容を発表・講義する。他の参加者は、発表を聞いて質問したり意見を言ったりする。発表者の内容が正しいとは限らないので、良さそうだなと思ったら、原本を読むことが必要。ただ、ある程度理解した状態で読めるのでスイスイ読める。
全員がある程度、興味を持った本を対象にすると良い。意識の高い人たち向け。

良い点

• 本を読む負担が分担される
• 本を回し読みできる
• 発表者は、内容を要領よく的確にまとめる訓練になる
• 後日、本を読むとしても大体の内容が頭に入っているので楽に読める

悪い点

• 発表者が間違えた場合に、全員が間違えた解釈をしてしまう場合がある
• 発表者によってクオリティが違いすぎる
• 発表者以外はだらけるリスクがある

同じ目的や問題意識を持ったメンバーで難しめの本を読むときにおすすめ。

全員が読んでくる会

輪講形式と違い、参加者全員が対象の本を事前に読んで、議論する。本の内容や分量によっては章ごとに分けて1冊の本を何回かに分けて読む場合もある。一冊丸々の場合は、盛り上がり具合によってすごい時間になることがある。逆に盛り上がらないと時間が余ってしまうので、ちょっと余らせるぐらいの分量を予習するようにしておいて、話が長引いたら次回、にすると良い。
予習がかなりアレで、開催頻度が高いと大分つらいので週一はおすすめしない…。

良い点

• 事前に自分の意見をまとめておくことができる
• それぞれが自分のペースで読むことができる
• 全員がある程度理解していることを前提に議論が進むので深い話ができる

悪い点

• 予習の時間が必要
• 予習ができなかった人がついてこれない
• 意識を保つのが大変
• 参加者全員が本を持っていないといけない

深い議論がしたくて、予習の時間を取る時間/意欲があるならおすすめ。

ワークショップ形式

本を読むのはおまけ程度で、本を実践するのを主眼に置いた会。
読み方は特に決まっていないが、実際に自分で読んだほうが実践しやすいので、「その場で読む会」または「全員が読んでくる会」が良さそう。輪講形式は、先生（発表者）の言ったとおりに、みたいな感じになりやすい感がある。
実際の実務に密接に関わった本を選ぶことが多いし、そうしたほうがモチベーションあがる。
実践する内容によるが、1日かかることもあれば、実際に業務で試してみてどうだったかを発表するみたいなのをやることもある。

良い点

• 楽しい
• 実践するので身につきやすい/理解が深まる
• 読むだけでは分からなかった問題に気づくことができる

悪い点

• 本の選定が難しい
• 社外の人とやるときはなかなか事例を出しづらい
• 内容によっては一回でも休むとついていけないことがある

実際に手を動かして何かしたいときにおすすめ。

まとめ

自分はやっぱり一番やってるっていうのもあるけど、その場で読む会が好きだなあ。
他の人が開催してくれるならワークショップ形式や交流会は楽しいので参加したい。
輪講形式は、それに向いた本やメンバーがいれば全然やっていけると思うので、これから数を重ねていきたい分野。

プロダクトマネージャー風林火山

小野和俊さんの風林火山の話おもしろいなと思ったので真似して分類してみたメモ。

小野和俊のブログ:プログラマー風林火山

分類	能力
風のプロダクトマネージャー	顧客の要望に素早く対応し、プロダクトを成長させていくプロダクトマネージャー。立ち上げ直後のプロダクト向きで市場の変化にいち早く対応できる。開発者出身が多い。
林のプロダクトマネージャー	冷静に市場分析や顧客分析を行い、プロダクトを改善していくプロダクトマネージャー。安定したプロダクト向きで着実に良い製品を作り出す。主なスキルは分析。
火のプロダクトマネージャー	情熱を持ってチームを整え、強い開発力でプロダクトを飛躍させるプロダクトマネージャー。チームが一丸となり、短期間での目標達成に強い。
山のプロダクトマネージャー	プロダクトのロードマップを整え、プロダクトの品質を担保するプロダクトマネージャー。一貫した方針でプロダクトのブランドを守り、様々なしがらみからチームを守る。

完全に独断と偏見なので、もっとこうしたほうがわかりやすそう！とかあれば教えてください！

おにやんま - ISUCON6予選敗退反省会 #isucon

ISUCON6予選に、 id:karupanerura, id:ar_tama と3人で「チームおにやんま」として参加しました。

当日の動きなどは他の二人が書いてくれると思うので、反省点をまとめておきます。

昨年のふりかえりはこちら。

ofsilvers.hatenablog.com

まとめ

チームおにやんま暫定1位だ #isucon

— silvers (@silver_s) 2016年9月18日

ついに頭角を表したチームおにやんま #調子に乗りすぎ

— 貴社の名は。 (@karupanerura) 2016年9月18日

isucon.net

以下の4チームは、最終スコアは上位10チームを上回っていたものの、それぞれ下記の理由により失格となりました。

再起動後のチェックで正しいレスポンスを返せなかった
・ヴェンティッグ
・チームおにやんま

今年もISUCON運営に感謝 #isucon

— silvers (@silver_s) 2016年9月20日

KEEP

きっちりと役割分担できた

インフラ整えるあたりで3人とも同じ罠（symlinkがー、daemon offがー、再起動がー）にハマったりしていたので、誰か一人が全メンバーのインスタンスでインフラ整えて渡すみたいなことをしておけばよかった。 その間に残りのメンバーはアプリケーションの仕様を把握したりコード読んだり。

昨年、このような反省をしたので、今回はきっちりと役割分担をした。 インフラや破壊的な大規模改修は id:karupanerura、地道なアプリケーションの改善は id:ar_tama、計測やベンチ、プルリクのマージ・テスト等サポート全般は id:ofsilvers という感じ。

githubのプルリクもうまく使えて、今回は誰が何をやっているか全員が把握しつつ、一度も作業がバッティングすることなく進められた。

落ち着いて作業できた

なんか午前中にインフラまわりで時間かけてしまって、進捗ゼロです！みたいなので、お昼の時間も忘れて焦ってしまった*1ので、もっと時間をかっちり決めても良かった

音楽流したり、アロマを炊くなどして、精神を整えられた。

思わぬ事態に遭遇したときも、固執せずに代替案などに切り替えられたと思う。

相談の時間がとれた

開始前に、XXXが終わったら相談の時間をとる。XX時になったらアレをする等、相談のルールを決めていたので、3人の方針の認識は統一がとれていたと思う。

PROBLEM/TRY

前回の反省と違って、細かい作業レベルの反省になってきたのは良さそうに感じる。

systemdって分かっていたので準備しておく

workerの調整が結構ギリギリになってしまったので、systemdまわりも最初にリポジトリにいれておくことで、変更履歴を管理するとともに、ansible で配れるようにしておけばよかったなと反省。

コードもデプロイできるようにする

設定等はansibleで配布していたけれど、コード周りは環境でpullしていたのでいっそのことコードも配布できるようにする。

早めの締切を作る

18:00終了の予定で動いていたため17:00過ぎたあたりから最終調整に入ったが、毎回、最終調整の内容が重く、「あと数分あればかなり改善が見込める変更が反映出来たのに！！！」みたいな状況で終わってしまう。 そのため、17:00を提出時間だと思っておくとよさそう。

ふせんを使う

ホワイトボード、githubのissue、slack等情報が分散されてしまったのでタスク等は付箋で管理してみる（分散してそんなに困ったわけではないが、より良く情報を管理できそう）。

おまけ1

明日食べる時間ないので前日おにやんま #isucon pic.twitter.com/aGfUPCKrob

— silvers (@silver_s) 2016年9月17日

朝やんまできたのでがんばる #isucon pic.twitter.com/2IBCYNbwi3

— silvers (@silver_s) 2016年9月18日

反省会の様子です #isucon pic.twitter.com/E1HJiIdoUk

— silvers (@silver_s) 2016年9月18日

反省会終わったので褒め合う会します #isucon pic.twitter.com/fZDgV5Kyxr

— silvers (@silver_s) 2016年9月18日

おまけ2

@karupanerura @silver_s 若者のPerlチームなので僕としても通ってほしかったのですが残念です…

— songmu (@songmu) 2016年9月18日

まだ若者を名乗れるらしい

— silvers (@silver_s) 2016年9月18日

メンション漏れに泣いてる

— あらたま (@ar_tama) 2016年9月18日

1on1ミーティングに備えるアンケート

最近は、大体月一ぐらいのペースでメンバーと1on1ミーティングをするようにしている。

一人あたり30分から60分ぐらいで、前回のミーティングからの振り返りとその他相談を話す感じ。相談は仕事のことが主だけれど、プライベートな内容もある。

1on1ミーティングにあたって今年から事前アンケートを用意するようにしたのだけれど、そこそこいい感じに回っているのでまとめてみる。

事前アンケートを用意するメリット

話すことが事前に想定できる

アンケート自体がアジェンダになるので、ミーティングがコントロール可能になる。 どんな話をするか分かっていると安心感もあるし、話が横道に逸れることもない（雑談は雑談で良いものだけど）。

その場で回答が思いつかなくて適当な返しになることがなくなる（お互いに）

自分の体験談なんだけど、何か質問をされたときにその場では「うーん、今は特に思いつかないです」と答えたのに終わってからアレコレ思いついて、まあいっか、今度話そ、みたいになって忘れてしまうことがよくあって、それって非常にもったいないなと思っていた。 事前に回答を用意する感じになれば、いくらでも悩めるし、アンケート時には思いつかなかったけどあとから「そういえば…」みたいなこともある。

事前に準備ができる

これがすごい良くって、スピード感が出る。

例えば、「会社やチームにこんな不満/要望がある」みたいなことが事前アンケートに書かれていれば、ミーティング前に調整を行って、ミーティング時には「あれ対応しといたよ」みたいなことが言える。 通常であれば、面談 → 対応 → 報告みたいなフローをとる必要があって、結構面倒だったりする。 全員に共有できる内容であれば対応後すぐに報告することもできるのだけれど、内容によっては個別に共有が必要で再度予定確認して会議室とって、みたいになると思いの外時間を使ってしまう原因になる。

また、Aさんの話を聞いた後にBさんの話を聞いたらちょっと見え方が変わってきたみたいなことも多くって、それを事前にみんなの意見を見てからミーティングにのぞめるのも良い。

アンケートの内容（レギュラー）

常に表示しているアンケート項目。回答は任意。

キャリアについて

• 5年後どうなっていたいですか？
• そのために今年このチームでは何をしたいですか？

将来のキャリアプランと計画を聞くことで、今後どのような業務・役割をしてもらうかを判断するために聞いている。 場合によってはこのチームにいたら目標に近づけないこともあるので、別のチームを紹介するなど異動の手伝いをすることもある。

目標/評価について

• 目標や評価について何か悩んでいること・障害はありますか？

期初に決めた目標の進捗がよろしくないみたいなときに、一緒に解決の方向を探るために聞いている。 障害であればできる限り取り除き、自己評価と周りの評価が大きく違っていれば認識を合わせたりする。

相談/不安/不満/報告

• 会社/経営について
• プロダクト/チームについて
• 一緒に働くメンバーについて

いろいろなカテゴリでとにかく話したいことがあれば書いてねという項目。 ここも同様で、障害であれば取り除いたり、意見や提案であれば、取り入れるか取り入れられない理由を説明する。

アンケート項目（季節替わり）

チームのフェーズに合わせて変えていく質問。回答は必須。

プロダクトをよくするために何をしたいですか？

まずはプロダクトのマイルストーンを決めるために、チームメンバーがプロダクトをどう思っているか、どうしたいと思っているかを聞いた。 現実的な回答よりは夢を語ってほしかったので、お金や時間やその他もろもろのしがらみを無視して答えてもらった。

人によってプロダクトのとらえ方が違っていたので、回答をもとに改めてプロダクトの立ち位置やミッションを共有した。

あなたがPMだとしたらプロダクト/チームをどう改善したいですか？

ある程度運用を行ったので、それぞれが考えるプロダクトやチームと、PMが決めたマイルストーンとの差異を確認するために聞いた。 すごい長文で回答をくれたメンバーもいて熱意が伝わってきたし、自分になかった切り口などを知れてとても勉強になった。

今の仕事や環境は、あなたや周りのメンバーの能力をちゃんと引き出せていますか？

みんなが同じ方向を向けるようになったので、今度は配置について聞いてみた。 ほんとはこれがやりたい、あれがやりたい、みたいなことを期待していたのだけれど、そこは満足度が高くて良かった。 かわりに、自分はあの人に以前一緒だったんだけどこういうこともできるので任せてみては？みたいな回答があって、なんか嬉しかった。

あなたに与えられた仕事は、おもしろいですか？

能力は引き出せているけど、ただの作業になってしまって学びがない、みたいなことを防ぐために聞いてみた。

今チームでやっていることで1つだけやめるとしたら何ですか？（一番無駄だと思うことを教えてください）

形骸化した習慣を捨てるために聞いてみた。 結構いろいろな意見があったので、きっぱりやめてみたり、やめる検討中。 「すごい考えたけど思いつかなかった」みたいな回答もあったけれど、今やっている習慣やフローの必要性や目的を振り返る良い機会になったと思う。

まとめ

といった感じで事前アンケート良いよというお話でした。