嫌われるのが怖い人間からの「『嫌われない』を諦めない」 #devlovex 登壇記

登壇,講演,発表 リーン、アジャイル、スクラム

DevLOVE X で 「嫌われない」を諦めない というタイトルで登壇してきました。

伝えたかったこと

伝えたかったことの中で、今回メインに据えたのは

  • ものごとを推し進めるために、「嫌われる要素」を取り除く努力もしよう

ということでした。

このテーマの動機（個人的な部分をメインに）

「嫌われるのを怖がる」という弱み

僕は「嫌われるのを怖がる」タイプです。 「全員に好かれるなんて無理なんだから、嫌われちゃってもいいじゃん」という励ましを受けるやつです。HSP (Highly Sensitive Person) の数値も高めの人間です。

なので、「相手を伺いながら、大きな衝突が起きないように進める」というアプローチを取りがちで、「嫌われることをいとわずに物事を大きく進める」というのはかなり意識しないとできません。克服しようと努めている弱みのひとつです。

前職でメンターをしていただいていた方に「その、周りを見て調整する能力が強みであり最大の弱みだ」とフィードバックをもらったこともあり、今でも胸にとどめています。

「嫌われるのを怖がる」という強み

でも逆に、「嫌われるのを怖がる」という弱みに感じることも、裏返せば強みになりうると言うことだとも思います。

続きを読む

flexy に取材いただき、アジャイルの話をしました

リーン、アジャイル、スクラム 登壇,講演,発表

取材依頼をいただきまして、話してきました。

言いたかったこと

記事が、ちょっと偉そうな感じのトーンになってしまったかもです・・・。

言いたかったことは、

  • なんでもいいから良くすることを始めてみよう。別にルールなんてないよ。
  • とどまることなく、世界に誇れるくらいまで邁進しなきゃな
  • 経営層、マネジメント層はちゃんと理解して、チーム支援したげてね

という感じです。

嬉しかったこと

取材いただいた担当の方から、

今回の取材を通してアジャイルがすごくクリアにわかるようになりました。そして横道さんに教えていただいたように振り返りを早速実践しています。

というメッセージを後日頂いて、これだけで取材受けた甲斐があったな、と思いました。

武装解除 × アジャイルリーダーシップ（Agile Leadership Summit 2019 をやります）

リーン、アジャイル、スクラム 登壇,講演,発表 イベント紹介

2019年7月8日(月) に、Agile Leadership Summit 2019 というイベントを開催します。

「基調講演 + Open Space Technology*1」という構成で、企業内でアジャイルを推進、実践している方を対象したイベントになります。

基調講演は、日本紛争予防センター（JCCP）理事長の瀬谷ルミ子さんという方で、世界の紛争地の復興、治安改善、兵士の武装解除・動員解除・社会復帰（DDR）を行われている方です。

www.jccp.gr.jp

「武装解除・動員解除・社会復帰（DDR）」。
究極のコンフリクト・マネジメントですね。 アジャイル導入・推進や、もちろんプロダクトを作る過程においても、さまざまな利害関係者のコンフリクトを解消することが大きな仕事の一つになっていると思います。

今日、瀬谷さんご本人と打ち合わせを、アギレルゴコンサルティングの川口さんとしてきたのですが、対峙している表面上の事象自体やコンフリクトのスケールの大きさは違えど、（失礼ながらも） ひょっとして同じ仕事なのでは？ と錯覚するほど共感する内容をたくさんお話いただきました。

私が、瀬谷さんの著書の中で共感を覚えたのは、以下の一節です。

あのときは、私に専門性がないことが問題だとおもっていた。でも、たとえ私がどれほど有能な専門家でも、 人々が自発的に望んで居ないことを押し付けるのは、ただの自己満足なのではないかーーー

職業は武装解除

職業は武装解除

私が行っている仕事は「武装解除」ほどの大義はないかもしれませんが、こういったジレンマを感じた瀬谷さんがどのようなアプローチで紛争地のコンフリクトを実際に解決していったのか。それは私たちの仕事にも大きなインスピレーションを与えると思います。 当日は紛争解決の生々しいエピソードを多くしていただける予定ですので、ぜひお楽しみに・・・！

こういった話を聞いた後の Open Space Technology ってどんなテーマになるのかなぁ・・・今から楽しみ・・・！

チケットはこちらから。（有償ですが、非営利です。） www.eventbrite.com

余談

Linda と瀬谷さんが邂逅するのをみてみたい・・・！

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

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

*1:参加者自身がテーマを出し、グループに分かれた参加者同士でそのテーマについてディスカッションを進める形式

ふりかえりで「Problem」を出すときに気をつけること

リーン、アジャイル、スクラム プロダクト開発プロセス

KPT などを利用してふりかえりする場合、チームで

問題点をあげる → 原因を考える → 改善アイディアを考える → …

というステップを踏むことがあると思います。

この「問題点をあげる」というステップにおいて、以下をすっ飛ばして挙げてしまうことがあるなぁと思います。

  • 「なんでそれを問題だと思ってるか」
  • 「それによって誰に、どんな困ったことが起きた(起きる)か？」
  • 「そのインパクトってどんくらい？」

「Problem/問題点」を出しましょうと言わると、「これが問題だろう」と（悪意なく）決めつけてしまって、言葉たらずになることがあるんですね。

たとえば、

今週やることを絞れていなかった

というふうに出すよりは、

今週やることを絞れてなかったせいで、どの案件も中途半端になってレビューしてもらうタイミングが遅くなってリードタイム伸ばしてしまった。例の重要な後続タスクも遅れると思う。自分のスイッチングコストも高くてストレスが半端なくて憂鬱だった

必ずしも定量的でなくてもいいとおもうし、感情でも良いと思う。
長いけど、付箋何枚か分けて書けばよさそう。

このあたりがないと、

次の「原因を考える」「改善アイディアを考える」のステップにおいて、

  • 問題設定の筋が良いのか？実は問題は他の所にあるのでは？解決する価値が他の問題と相対的にどうなのか？という議論や判断ができない
  • 問題に共感してらえない

ということが起きますよね。
以後気をつけます！

もし自分以外がこういった形で問題点をだしていたら、

上記の問いをそのまましてしまう、でも良いのではと思います。 そのときには、責めるような雰囲気にならないように、「誤解が無いか確認したいんですけど、」のみたいな枕詞をつけると良さそうです。

もちろんふりかえりプロセスの中にいれても

いいとおもいます。

問題点をあげる → 原因を考える → 改善アイディアを考える → …

というやつを

問題点をあげる → 問題のインパクトを整理する→ インパクトや今後の発生確率、頻度を踏まえて Dot Voting → 原因を考える → 改善アイディアを考える → アイディアを コスト x 効果マトリクスに雑マッピング → 取捨選択して ToDo にする → ハイタッチして家に帰る

とかに

関連

ykmc09.hateblo.jp