Unknown Error

日頃考えていることとか、読んだ本の感想とか

マネージャーを否定しない組織をつくる

RSGT2020が1/8~10に開催された。 昨年は楽しかったの一言に尽きたが、今年はとにかく考えさせられた。

というのも、私にとってここ2~3年のテーマだった、Agile × マネージャーというドンピシャなキーノートがSahotaさんよりあったためだ。

confengine.com

本記事では、このキーノートに焦点をあてる。

マネージャーを否定してはいけない

Sahotaさんのセッションで最も印象に残った言葉が、「組織を変革させるとき、誰も取りこぼしてはいけない」というものだ。

私がBas(LeSSの提唱者)の認定スクラムマスターの研修に参加したとき、どんな役割を今やってますか?と質問された。 私はそのときScrumを推進する人ではあったが、Scrum Masterではなかった。なぜなら、私の行う役割にはエンジニアの評価やエンジニアの採用も入っていたからだ。 そのときはEngineering Managerという肩書きを知らなかったので、とりあえずProject Managerと言った。他の参加者にもXX Managerという役割を持っている人がいた。

そこでBasに言われたのは、「おめでとうございます。Scrumではマネージャーという役割はいないです。だから、あなたの役割は無くなります。」という言葉だった。

この言葉に正直、良い気持ちはしなかった。 なぜなら、自分のやっている役割は必要性があってやっているものであり、自分の役割が変わったところで、その仕事は無くならないと思ったからだ。*1

このときから、私のAgileな組織におけるマネージャーとは何かを考える旅が始まった。

f:id:yunon_phys:20200113003458p:plain

開発メンバー vs マネージャーという対立構造は悲劇しか生まない

Agile界隈で私の苦手な風潮はマネージャーを否定する言葉だ。

「邪魔してくるマネージャーをチームからブロックしろ」

「マネージャーの役割はチーム開発では不要だ(だって、Scrumはそれで成り立つでしょ)」

確かにそれはチームという目線から述べたら正しいのかもしれない。 多分、私もチーム開発だけを見ている立場のときにそういう発言をしていたと思う。 でも、その言動は組織を運営する立場(=マネージャー)からすると、とても鋭い刃だった。

一方で、このマネージャーの否定発言こそが悲劇を生み出しているのではないか。 現マネージャーはもちろんだが、特に、Agile開発をしていたメンバーがマネージャーの立場になった途端、その矛先は急に自分に向く。 自分のやっていることは悪なのではないか、自分はチームを邪魔する人間になっているのではないか、などと言った自己を否定する言葉を使いながら。

実際、自分もこのように感じてしまい、Agileの理想から外れている自分と、その一方でAgileを否定したくない自分で葛藤した。 結果として、Agileコミュニティからも少し身を引いた場面がある。 組織運営をしているマネージャーにとって、Agileコミュニティは正直居心地が良くなかった。

一方その頃、Engineering Manager(EM)コミュニティが立ち上がった。 組織運営をする立場の人間が多かったので、その方が居心地が良かったし、何より現実的に今自分が困っている課題を議論できた。 結果として、EMコミュニティの活動が増えていった。

ではまたなぜAgileコミュニティとつながりを持つようになったか。 それは、EM.FMを通してEM像だったり、私の考える組織設計について、 Agileコミュニティにいる方々からとてもポジティブな意見をいただく機会が増えたからだ。

Agileコミュニティの理想ではないマネージャーという存在が、現実的に必要な役割として認識されたのだ。

f:id:yunon_phys:20200113001137p:plain

ヒエラルキーと自己組織化

私の組織ではマネージャー職を設け、一種のヒエラルキーを作っている。 その中でAgile開発をしようとして、Agileの掲げる自己組織化という理想とのギャップに苦しめられていた。

Sahotaさんは、このギャップについて、ティール組織を使って説明していた。 以下は、Sahotaさんの発表内容の一部を切り取って、私の理解しているギャップの根源を述べる。 参考にしたのは、以下の本である。

[イラスト解説]ティール組織――新しい働き方のスタイル

[イラスト解説]ティール組織――新しい働き方のスタイル

多くの会社はヒエラルキーから成る"オレンジ"(あるいは"アンバー"*2 )組織である。 一方、Agileの理想とするのは、自己組織化された"ティール"組織である。

理解しなければらないのは、オレンジ組織がいきなりティールを目指そうとすると問題が起きる、ということである。 本当はそれらの間にあるグリーンを作り上げ、そこからティールを目指すのが本筋である。*3

では、グリーンとオレンジの違いは何か。肝となるのは権限委譲である。 マネージャーの役割を認めながら、権限・責任をメンバーに委譲していくということだ。

グリーン組織の重要な観点として、権限委譲された組織を目指すということは、ヒエラルキーを維持しているということだ。 これは一見矛盾しているように思えるが、一つ一つ丁寧に権限委譲していくプロセスが自己組織化された状態にするために大事なことだ。

Agile開発の文脈では、この権限委譲のプロセスが定義されていない*4ため、 どうしても開発メンバー vs マネージャーという対立構造を生んでしまわざるを得なかったのではないかと思う。

権限委譲を促進させるためのコツ

では、権限委譲をどうやったら促進させることが出来るのだろうか。 権限委譲には私の経験上、スキルの壁・信頼の壁・勇気の壁の3つの壁がある。

1. スキルの壁

メンバー側に権限・責任をもらうだけのスキルが無いと、そもそも委譲されることは難しい。 マネージャーと良く話し合い、どんなスキルが足りていないかを良く話し合おう。

2. 信頼の壁

スキルがどんなにあっていても、メンバーが信頼されていないと委譲は進まない。 信頼を貯める行動を取り、メンバーに任しても大丈夫だと信頼されるようになろう。 そして、マネージャーはXY理論のX理論(人間は本来なまけたがる生き物で、責任をとりたがらず、放っておくと仕事をしなくなる)ではなく、Y理論(人間は本来進んで働きたがる生き物で、自己実現のために自ら行動し、進んで問題解決をする)に立つということも重要である。

3. 勇気の壁

全て委譲出来るかどうかはマネージャーの勇気にかかっている。 マネージャーの恐れをメンバーに伝え、メンバーを信頼しよう。

f:id:yunon_phys:20200113003715j:plain

マネージャーがいない組織を実現できるのか

この問いについて、私はまだ解を持っていない。 ティール組織をまだ理解しきれていないし、どのような実装が自分の組織にうまく適合するのかシミュレート出来ていない。

サイボウズ社の水戸さんの発表は、マトリクス型組織だったところからマネージャー職を廃止したということで、自分の組織と似たようなところもあり、とても参考になりそうだ。

私はAgileの考えに強く共感しているし、コミュニティにもかなり助けてもらった。 だからこそ、マネージャー否定の連鎖を止めたい。

Sahotaさんのセッションは、正にそれそのものだった。 私はSahotaさんからこれまでやってきたことに対して、勇気をもらった気がした。

RSGTのチケットが瞬殺され、プロポーザル採択の倍率が3倍から5.5倍になり、世の中にAgileの考えが広まっていく流れが見えた。 そして、Agileが広まれば広まるほど、私のようにマネージャーが苦しむのは今後間違い無い。

私のやることは、マネージャーを否定しない組織をつくり、そしてその実装例を広めていくことなんだろう。

(追記) @ikuodanakaさんが、この記事では伝えきれていなかった、マネージャーって何をする人なのか、どうなっていく存在なのかを書いてくださった。 note.com

*1:Basは多分、ScrumをやるならScrumの何らかの役割に専念しろ、あるいは、もっと価値の高いことをやれ、ということだったのだと思う。でも、当時の自分はこの言葉を受け止めきれなかった。

*2:アンバーからオレンジの重要な差異は、accountabilityを定義しているかどうか。もしかしたらaccountabilityの定義も危うい可能性がある

*3:ティールが全てにおいて最高の状態ということを言いたいわけではない

*4:Management 3.0では、Delegation Boardというモジュールを用意しているので、この点はAgile開発の良い補完関係なのだろう

自分をアップデートし続ける技術

この記事は「セイチョウ・ジャーニー」「挫折論への招待」アドベントカレンダー Advent Calendar 2019の22日目の記事です。

2019年のアウトプット

今年1年を振り返ってみる。 今年はあまりアウトプットしなかったかもなーと思っていたが、集めてみると結構色々やっていた。

昨年との一番の違いは、依頼されて出演する機会が多かったことだ。

ただ、ほとんどは過去〜今の話なので、ある種貯金を食いつぶしているという危機感はある。 常に自分をアップデートして、新しいことをやったり、(自分なりに)新しい発見をし続けるということがこれからも必要なのだろう。

では、どうすれば自分をアップデート出来るのだろうか? 以下では、数ヶ月後の自分という他人に向けたメモも兼ねて、今の私なりの自分のアップデート方法を書いていく。

自分という人間を理解する

何をするにしても、自分とはどんな人間であるかを理解しておくのがまず必要だと考えている。 ただし、自分という人間は常にアップデートし続けるということを前提に置くので、自分の理解を常にやり続けるということが必要である。

自分の好きを知る

仕事や趣味の活動などを通じて、自分の好きなことを理解しておくと、それがあるだけで癒やしになるので、言語化しておく。

ただし、好きと得意は別ものとしてとらえておく。 好きだから得意とは限らず、逆もまた然りだ。 特に、好きというだけで仕事にして得意でないことをやってしまうと、相応の努力が必要になり、最悪嫌いになってしまう可能性もある。*1

自分の得意・強みを知る

これも仕事や趣味の活動などを通じて、これが得意だ、これが強みだ、を理解しておくと、新しく何かをやるときの指針になる。

客観的な指標であれば、ストレングス・ファインダーが有名だ。

ちなみに、3年前に受けた結果がなんだか今と合っていない気がして、今年の3月にもう一度受けてみたが、やはり強みが大きく変わっていた。 どうやら強みは変化するらしい。 f:id:yunon_phys:20191221172553p:plain

自分の苦手を知る

逆に苦手を知ることで、苦手を克服するために努力する、あるいはそこを避けてやらない、という手が取れる。

私の場合は、苦手を克服するという選択をする場合は、その先にどうしても達成したい目標があるときだ。 逆に自分のやりたい方向ではないことに対しては、無理に苦手を克服しない。

苦手を避けてやらないことのほうが、私の場合はほとんどだ。 苦手なことをやることより、得意なことをやることの方が価値が出るし、スキル・能力がつきやすいと考えているからだ。

自分の感情を感じる

感情の上下をするポイントを理解しておくと、反応的に意思決定をしなくて良くなるので、言語化をしておく。 例えば、どんなときに楽しいと感じるのか、どんなときに怒りを感じるのか、どんなときに悲しみを感じるのか、どんなときに恐怖を感じるのか、など。

ブッダの考えを理解すると、反応的にならないようなり、まさに悟った人になれる。

自分の考え方の癖を知る

何かを意思決定するときには、ベースになる思考の癖が必ずある。 その思考の癖は、

の3つによって形成されていると考えている。 それぞれの付き合い方がうまいと、より合理的な意思決定が出来たり、非合理的な意思決定をした自分の振り返りの材料となる。

認知バイアスについては、例えば以下のサイトが参考になる。

認知バイアス一覧で社会心理学入門〜社会科学の知の蓄積を活用した社会教育の実現に向けて〜効果、錯誤、誤り、仮説一覧〜

2019年の本だとFUCTFULLNESSが流行りましたね。

価値観の調べ方については、以前まとめた記事がある。

充実とは価値観が満たされた状態である|ゆのん|note

チームで楽しみながら価値観を知りたいという人は、価値観ババ抜きであったり、Management3.0のMoving Motivatorsをやるという方法もある。

価値観ババ抜きとは | 価値観ババ抜き | myvaluecard

ムービング・モチベーターズ、モチベーションポーカー | ニューワークス

メンタルモデルについては、『学習する組織』の推論のはしごや、『なぜ人と組織は変われないのか』の免疫マップが参考になる。

学習する組織――システム思考で未来を創造する

学習する組織――システム思考で未来を創造する

最近だと、そのものずばりの本が出ましたね。

この本によると、人のメンタルモデルは

メンタルモデル 痛み繰り返される不本意な現実
価値なしモデル 何か価値を出さないと自分の価値は認められない
愛なしモデル 自分のありのままでは愛してもらえない
ひとりぼっちモデル 人が去っていく、離れていく、つながりが絶たれる分離の痛み
欠陥欠損モデル 自分には決して埋まらない決定的な欠陥がある

のどれかに分類されるらしい。私の場合は典型的な価値なしモデルだ。*2

他人から見える自分を知る

上記の内容を親しい人とお互いシェアすると、それについての反応がきっと返ってくるだろう。 それらが自分が思った通りであればその認識を強化すれば良いが、あなたにはこういうところもありますよ、というフィードバックは新しい自己発見につながる。

これを促すツールとして、持ち味カードは一つの手段として有効だ。

www.delight-c.com

習慣的に挑戦する

自分のことを理解するためには、今何が出来るのか・何が出来ないのかの理解も重要だ。 これらの理解のためには、想像ではなく実感値として持つ必要があるため、行動で判断するのが有効である。

そこで、自分の現在地点を把握出来るようにするため、習慣的に挑戦する。 挑戦には

  • 新しいことをやる
  • 難しいことをやる

の2種類がある。*3

日常から新しいことをやる

新しいことに挑戦することのハードルを下げるため、日常に新しいことを取り入れる。 例えば、食べに行ったことのないレストランに入ってみる、いつもと違う経路で通勤してみる、などでも良い。

このように自然と新しいことへの挑戦をしておくことで、挑戦の恐怖を取り去り、 いざ何か本当に新しいことをやる/やらないの選択肢が出たときの練習が出来る。

ちなみに私が新しいことを挑戦したときは、その感想を何らかの形(多くは人に話す)でアウトプットするようにしている。 そうすることで、新しい挑戦に対するふりかえりを促し、良かったこと、良くなかったことの価値基準を自分の中で言語化出来るためだ。

難しい挑戦が出来る環境に身を置く

私は自分に甘い人間なので、難易度の高い挑戦を自分で設定するのは難しい。 そこで、私は難しい挑戦が出来る環境に身を置くようにしている。

難題がたくさん降ってくる場所であっても良いし、難題を一緒に考えてくれる人が近くにいるのでも良い。 クリアした結果が価値の高いものであればある程、難題のクリアしがいがあるので、自分の見えている世界だけで難題を選ばないようにしている。

常に学ぶ

私のストレングス・ファインダーに学習欲が入っているように、学習が好きな人間である。 そこで、私が意識的にやっていることを書く。

何からでも学ぼうとする

私はどんなことからでも大なり小なり学べることがあると考えている。

勉強会に出席してあまり面白く無い、と思うことも正直ある。 そのときになぜ自分が面白く無いと感じたかを自分に問いかけてみる。 すると、その面白く無いと思ったポイントに対して、自分の知識が不足していたからなのか、興味がそもそも無いことなのか、 という整理が出来て、その整理する作業そのものが自分を理解するということにつながる。

また、今その瞬間に必要でないと思った知識も、そこで学びがあったからこそ未来にそこから話が広がったという経験を何度もしている。 なので、知識は入れておくことに越したことがないというのが私の考えである。

学んだことをアウトプットする

挑戦にも共通するが、学んだことは可能な限りアウトプットするように努めている。

例えば、WEB記事を読み、その中から1行でも学びのあったところを引っ張り出し、そこに対しての自分の考えを述べるなどしている。*4 そうすることで、他の人の文章が自分の文章になる感覚があり、自分の学習になると考えている。

ここについてはアウトプットすればする程自分に返ってくるので、来年もっと意識して無意識に出来るレベルまでなるように取り組みたい。

学んだことに固執せずに学び直す

学んだことは時間をかけたり、命を削って得たものだったりするので、どうしても大事なものとして固執してしまう自分がいる。

『失敗の本質』にも、学習を軽視し、自己否定学習(unlearning)が出来ていなかったことが、第二次世界大戦で日本軍が負けた理由の1つである、と分析している。 自分の学んだことは一面的であり、多面的な評価をした場合はそれが全てではない、ということを肝に銘じておく。

ポジティブな感情もネガティブな感情もうまく付き合う

ポジティブ心理学によると、ポジティブな感情は認識しづらく、ネガティブな感情の方が残りやすい、といったネガティブバイアスがかかりやすいとされている。*5 つまり、無意識のうちに、好きや楽しいより、嫌いや辛いに注目しすぎている。

面白い実験動画を紹介しよう。 白いTシャツを着ている人が何回パスをしたのかカウントしてみて欲しい。

www.youtube.com

この実験動画から、人は知覚する情報を取捨選択しているということがわかる。 つまり、普段から知覚する情報を好きや楽しいなどのポジティブな物事に意識を向けるだけで、幸せな人生になれるということを意味している。

私の場合、なんでもポジティブなところを見るように普段から訓練しているので、ネガティブな感情に自分が支配されることは滅多にない。*6

アップデートは終わらない

結局のところ、自分のアップデートに終わりはない。 過去の自分をそのときに最適な選択肢を取った結果の自分として受け入れ、未来に向けてより自分が自分らしく、そして自分の才能が花開くように希望を持って生きていきたい。

*1:@akaderaさんはMPが減ると表現していた

*2:最初に書いたモチベーションがそのままだ

*3:この2つの分け方は職場の同僚に教えてもらった。しっくりくる分類のやり方だったので、ここでは採用させてもらった

*4:たまにサボって記事だけシェアすることもある

*5:という、勉強会に以前参加した

*6:支配されたとしても、大体は寝たら治るという特殊能力を持っている

エンジニアだけが優遇されるのではない組織をつくりたい

※ 2つの意味で解釈できるようなタイトルだった*1ため、より伝えたいことが明確になるタイトルに訂正しました。ご指摘いただいた皆様ありがとうございました。お詫び申し上げます

この記事はEngineering Manager Advent Calendar 2019の17日目の記事です。

手前味噌だが、所属している会社のエンジニア組織はだいぶ良い感じになってきているという自負がある。最近書いた自社のブログのエントリも多くの方に共感いただいた。 hackerslab.aktsk.jp 一つ一つの組織活動に対してこれって本当にあるべき姿なんだっけというのを問い続けながら地道な改善を続け、組織としての練度が大分高まってきた。 結果として、自社のあらゆる組織の中で、エンジニア組織は一番改善が進んでいる。*2

一方で、そこはかとなく、「このままで良いんだろうか」というモヤモヤがある。

会社はエンジニアのためにあるのか?

「エンジニアが働きやすくするのが会社にとって一番大事だ」という話を良く聞く。 私がこれを聞く度に、エンジニアが特別扱いされ、優遇される世界にどうしても違和感を持ってしまう。 なぜなら、会社にはエンジニア以外の職種が必ず在籍して、各々が各々の職務を全うした結果、プロダクトやサービスが提供出来ているからだ。 この事実を忘れて、「エンジニアは特別だ」なんてことはとても言えたものではない。

しかも、CTOやVP of Engineering(VPoE)、Engineering Manager(EM)のみならず、人事だったり社長がこの発言をしている場合もある。 自分が、あるいは、自分の所属している組織全体が働きやすくなるのも同列一番にして良いはずなのに、なぜエンジニアだけ優遇しようと発言しているのか理解出来ない。

私のモヤモヤの源泉は、自社でエンジニア組織だけが改善が進んだ状態に対してだ。 もちろん、これはこれで私自身が私の職務を全うした結果なのだが、エンジニアだけ働きやすくなるのは目指したい理想の組織の状態ではない。 組織に所属している全員が働きやすくなるのが、私にとって理想の組織の状態だ。

同じようなことがNETFLIXの本にも書いてあった。

NETFLIXの最強人事戦略 自由と責任の文化を築く

NETFLIXの最強人事戦略 自由と責任の文化を築く

  • 作者:パティ・マッコード
  • 出版社/メーカー: 光文社
  • 発売日: 2018/08/17
  • メディア: 単行本(ソフトカバー)

自社のエンジニア組織の改善は様々な議論の結果である

もちろん私も足りていないマネージメントの知識はたくさんある。 広木さんやEM.FMのゲストに来てくださった方々と話すと、自分の知識の浅さ・狭さを恥ずかしく思うことが正直ある。 それでも、なんとか食いつこうとここ数年マネージメント領域にコミットメントしてきたし、色々な社内外の方々とも議論させていただいた。 その学んだやり方をどう組織に適合させるかを考えぬき、実験しながら少しずつ組み込んでいったので、結果として良い感じにエンジニア組織が構築されていったのだと思う。・・・というと、自分だけの成果のようだが、CTOの組織に対する考え方が何よりも素晴らしかった。Team GeekのHRTを組織が若いうちに取り入れたり、CTOではなくチームに裁量をもたせられるように、適切にチームに権限委譲していた。私はこの考えに乗っかり、add-onしていっただけだ。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

なんとかしたいと思って出来ることをやった

一方でちょっと別の組織を見渡してみると、そんなにうまくいっていないという事実を目の当たりにした。 マイクロマネージメントを常にしていてメンバーが意思を持てないようになっていたり、 シニアマネージャーが適切に権限委譲出来ずにミドルマネージャーが苦しんでいたり、プロフェッショナルな組織と謳って感情を業務に持ち込めないようになっていたり、 マネージャーとメンバーの間でコミュニケーションミスが発生してマネージャーの信頼が意図せず失われたり、という状態が続いていた。

そこで私自身が何か出来ないか、ということで、いろいろやってみた。

組織の問題を議論出来るSlackルームを作った

まずそもそも皆が今の状態って良いんだっけ?と思えるように、組織で起こっている問題を議論するSlackチャンネルを作った。 最初はManagement3.0の本(Managing for Happiness)を輪読して感想を投稿していただけだったが、後にアジャイルコーチが話題を投下したり、 私自身もニュース記事をシェアしたり感想を述べたりしていったら、いつしかそれに反応してレスを返してくれるメンバーが増えていった。 そのチャンネルには12/16時点で、165人がjoinしていて、口コミで今も人が増え続けている。 多分、全体チャンネル系を除けば最もメンバーが多いチャンネルになっていると思う。 今でも1週間に2~3記事ぐらいはシェアされていて、そこから生まれる議論は楽しくて仕方がない。

Managing for Happiness: Games, Tools, and Practices to Motivate Any Team

Managing for Happiness: Games, Tools, and Practices to Motivate Any Team

  • 作者:Jurgen Appelo
  • 出版社/メーカー: Wiley
  • 発売日: 2016/06/27
  • メディア: ペーパーバック

組織の問題を議論出来るコミュニティを作った

プロダクトを良くするためのマネージメントのやり方をシェアしあわない?というところから7人のEMが集まって、議論をし始めた。 最初の方はアジャイル開発について話したり、EMの採用基準について話していた。 あるとき、もう少しコミュニティとして活動していきたいねということになり、それぞれの持っている価値観をすり合わせ、そこから自分たちは何のために今ここにいるか宣言文を書き、コミュニティの4つの価値観を定義していった。 その後、このコミュニティの価値観に共感したメンバーが5人増え、今ではエンジニアという枠を超えて、どうすれば自分たちのプロダクトが良くなるんだろうか、と話し合っている。

マネージメント勉強会を開催した

今ではもうやっていないのだが、一部のミドルマネージャー・リーダー向けに、マネージメント勉強会を実施した。 お菓子や飲み物を買ってきて、リラックスして話しやすい雰囲気づくりを作り、最近のタイムラインを作って議論してみるとか、ロッシェル・カップさんの本を使ってX理論/Y理論の解説とか、Delegation Boardを作ってみたり、Happiness Doorでフィードバックをもらったりとかやった。 ここでDelegation Boardを10人ぐらいで作ったからなのか、私がDelegation Boardについて社外で何度も発表したからなのかわからないが、 いつしかプロダクトのリーダーの交代時にDelegation Boardをやることが普通になった。 さらにはCEOと事業部長の間のDelegation Boardを作ることになったりと、着実に影響の輪が広がっていく感覚があった。

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

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

みんなが働きやすくなるように新たな挑戦を決意した

これまでやってきたのは草の根活動だったけれど、今度はもっと直接的に組織の課題に立ち向かえるようにしようと、来年1月から人事部にチームを立ち上げて、VPoEと兼務することになった。 作ったチームの名前は、Organization Development Labというド直球な名前。*3

ラボでやろうと思っていることの第一は、会社全体がより働きやすい場となるように、ODに関する過去の研究結果や他社事例を調査し、それを実現出来るやり方を考え、全社に実験しながら導入していくということだ。 基本は、それが成果として現れたかを定量的に測れるように何らかのメトリクスも導入していく予定だが、そこまで従業員が多いわけではないので、定性的な結果判断も十分ありうる。 理想の状態としてはGoogleのように、何でもデータを取りまくって判断するような世界観だ。

ラボでやろうと思っていることの第二は、今会社でやっていることのバックグラウンドのデータなり知識を集結させて言語化していくことだ。 Management3.0の勉強会やポジティブ心理学の勉強会などに出席すると、今の会社でやっていることは先進的であるということはわかるが、残念ながらそのバックグラウンドの知識背景を自分たちの言葉で十分に説明しきれているわけではない。 そこで、他の人事チームと協力して、ここの言語化を推進していく。

ラボでやろうと思っていることの第三は、評価制度の見直しだ。 今の制度はメンバーもマネージャーも多大な工数をかけて評価をしているが、本当にそれが見合った工数なのかを改めて考え直したい。 これも他の人事チームと連携して進めていく予定だ。

その他、ラボの活動というわけではないが、バックオフィスの組織改革の相談役みたいな立ち位置にもなる予定だ。 既に人事部外から相談が来ていて、一緒に変革プロジェクトを進めている。

いずれにしても、このODの知識を広く深くつけていくために、新たな学び直しから始まる。 実は既に少し動き出しているのだが、ストレングス・ファインダーの2つ目の資質である学習欲が刺激されるので、モチベーションにもつながっている。

何をする人なのか

EMとかVPoEの枠を超え、組織全体を変えようとするのはChange Managerなのかもしれない。 学習する組織の

人は変化に抵抗するのではない。変化させられることに抵抗するのだ

という言葉があるように、 変化させられたと思わせるようなやり方ではなく、変化したくなる組織とは何かを追求して、エンジニアだけが優遇されない組織をつくりたい。

学習する組織――システム思考で未来を創造する

学習する組織――システム思考で未来を創造する

*1:元々「エンジニアだけが優遇されない組織をつくりたい」としていたが、これだとエンジニア以外は優遇してエンジニアだけが優遇されない(冷遇する)、とも読めた

*2:ありがたいことに、会社の様々な方もこの事実を認めてくれている

*3:Organization Developmentは良く組織開発と訳されがちだけれど、開発は新しくものを作るという意味合いが強くなってしまう感覚があり、それよりは発展とか発達の方が合っているのではと思ったりしている

定期的に16 Personalitiesを調べて、自身の確証バイアスを見直す

Facebookで16 Personalitiesがちょっと流行っていたので、2年ぶりにやってみたら、面白い発見があった。

16 Personalitiesとは?

16 Personalitiesは、無料の性格診断サイト。 www.16personalities.com

16 Personalitiesの説明によると、INTJなど、MBTIの言葉を利用するが、MBTIそのものではないとのこと。 例えば、MBTIで扱う類型論は内向的 or 外向的という二元論を用いるが、両方の特徴を持った人(両向性)であったり、他の人と比較した場合にどちらかというと内向的という指標を用いられない。一方、その度合いを説明するのに特性論という手法もあるが、今度は手軽さが無くなってしまう。

そこで、16 Personalitiesでは、以下のように定義している。

続きを読む

RSGT2019は今まで参加したどのカンファレンスよりも最高だった

1/9~11で行われたRegional Scrum Gathering Tokyo(RSGT)2019に参加してきたのでレポートを書く。

RSGTには初参加だった

多くの人に驚かれたのだが、実はRSGTに参加したのは初。 去年の7月頃、ふとAgileのカンファレンスに参加したことが無いなーとつぶやいたら、梶原さんにRSGTがあるよ!と教えてくださった。

RSGTの存在は知っていたが、毎年なんだかんだ参加出来ておらず、いつも楽しそうだなーと横目で見てるだけだった。 なので、このときは次のRSGTには絶対参加しようと心に決めたのだった。

続きを読む

みんなが知見を公開したら、世の中がもっと幸せになるかもしれない

この記事は#セイチョウジャーニー Advent Calendar 2018の16日目の記事です。

2018年のアウトプット

ちょっと早いが、今年1年を振り返る。 カレンダーを見ながらやったことを書き出してみたのだが、今年は自分でもびっくりするぐらいアウトプットした1年だった。 社外発表としては、現在時点では以下の通り。

残り半月でPodcast出演、ブログ記事投稿も控えている。

続きを読む