天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

XP祭りで登壇してきた

XP祭りで登壇してきたので、ふりかえりや感想をつらつら書いていきたいと思います。
登壇資料作り&登壇にあたって過去一苦労したプレゼンでしたが、登壇できて楽しかったです。

confengine.com

※タイトルを回収する、680日目のブログが本記事です。

スライド

speakerdeck.com

登壇しようと思ったきっかけ

XP祭りのプロポーザルを書いてほしい&ブログのことを話してほしいと言われたのがきっかけです。

人から聞いてみたいと言われた内容をベースにプロポーザルを書いて発表するのは、自分としては初めての経験でした。

登壇準備

冒頭に書いた通り、今回はなかなかに苦労しました。。
苦労した理由は、以下の通りです。

XPの実践経験が極めて薄い&XPの理解が浅い

XPは数冊本を読んだだけですし、実践経験としても数ヶ月やってみたけどうまくいかなかった経験しかないこともあって、どういう話をすればXPに絡むのだろうか?XPに詳しい方々や実践者の方々が面白いと思うだろうか?という見当があまりつかず、発表内容を練るのに苦戦しました。

XP祭りはXPに関係ない話をしていいんだよ、というのはもちろん知っていたのですが、個人の想いとして、XP祭りの開催趣旨を考えるとさすがにXPに多少は絡めて話をしたいよねという思いがあったというお話です。(XPに関係ない話をされる発表があってもいいと自分自身も思っていますし、運営スタッフの方々もそう言っているので、本当に単なる個人的な想いのお話です)

原稿(話す内容)を詳細に練る前にプロポーザルを出した

普段は、最低限スクリプトでは話す内容が整理された状態でプロポーザルを出したのですが、このプロポーザルはイベント参加中に、完全なるノリで出してしまったので、あまり話す内容がイメージできていない状態でスタートしました。

書いた時はなんとかなるのかなーと思っていましたが、結果的に、作り直しが何度も発生して*1普段準備かける時間からだいぶ大きなオーバーヘッドが発生してしまいました。

バタバタしていた

予想外のこともあったとはいえ完全に自分が悪いのですが、9月は私事でめちゃくちゃバタバタしていました。

結果的に、まとまった時間で準備がなかなか進められなかったのですが、かといって発表を辞退したり普段のプレゼンから手を抜く気持ちにもならずで、めちゃくちゃ焦っているけど時間はない、という状態になっていました。(ゆとりを作らない反面教師の例ですね。。)

登壇のふりかえり

思ったことを箇条書きで書いていきます。

  • 不安な気持ちを抱えながらの登壇になってしまったので、いつも以上に言葉が出てきませんでした。話していて、だいぶ言葉足らずになってしまったり、当初話そうと思っていたことがとんでしまって話のつながりが悪い部分も多くありました。
  • 後半部分はXPと(無理矢理)繋げながら工夫や自分が得たものの話をしたかったのですが、繋げ方が弱く、発表したくらいの繋げ方しかできないなら、XPとか意識せずに自分の話したいことがもっと伝わるようなスライドにすればよかったな、と思いました。スクリプトに一度落とした時は言語化できたのですが、当日話そうとすると言葉が出てきませんでした。
  • 最後のオチの部分は、実は自分の今後の仕事の話と絡めてインパクトが強い話を入れる予定だったのですが、発表の場で話すことが急に不安になってしまって、やめました。やめた結果、最後の話の展開が浮いてしまったかなーと思いました。わざわざ流れを変えてインパクトが大きい話をぶち込む予定だったので、不自然に流れが変わって終わったような印象を自分は受けてしまいました。

つらつらと書いていったら、反省ばかり出てたので、自分を慰める意味でよかった部分も箇条書きで書いていきます。

  • 毎度のごとくですがコメントにはめちゃくちゃ助けられました。ありがとうございました。
  • (参加者のDiscord上での反応を見る限りですが)共感してもらいたいところとどうにかしていると思って楽しんで欲しかった部分を狙い通りに使い分けられた気がします。
  • 発表の準備過程でXPの白本をめちゃくちゃ読み返して、新しい発見やこれまで見落としていた内容が多くあることに気がつきました。
  • 参加者に合わせてプレゼンを構成する練習ができました。

おわりに

競合セッションが多すぎて、プレゼン一週間前は「参加者0人なんじゃないの...?」と不安に思っていたので、参加してくださる方が多くてすごく嬉しかったです。

ブログの更新は、今後も毎日続く予定です!

*1:当日の朝にも発生してしまいました

エンジニアリングマネージャーのしごと 読んでみたけど、質問ある?(答えられるとは言っていないに参加してきた

distributed-agile-team.connpass.com

今週も分散アジャイルチームの会に行ってきたので、会の様子と感想を書いていこうと思います。

会の概要

エンジニアリングマネージャーのしごとの著者でもなく、訳者でもなく、想定読者層でもないきょんさんが、本について語るという謎の会です。

会の様子

書籍に関するきょんさんの簡単なまとめ

まず、「エンジニアリングマネージャー、研修の手引き」くらいのタイトルがちょうどいいかな、と思ったそうです笑

本書籍では、エンジニアリングマネージャーがやるような仕事について具体的なステップをプロセス的に書いてくれているのが特徴的で、何も分からない人や体系的に知識を持ち合わせていない人は、非常に実践がしやすいのではないか?と感じているということでした。

そのため、テック業界の全ての人を対象にしているというよりは、エンジニアリングマネージャー初心者だったり企業で体系的なものがなくて何からスタートしたらいいか分からないような人にとって刺さる内容ではないか?というお話でした。

きょんさんの質疑応答

とりあえず、直前のイベントで出ていた質問にまずは答えてくれました。

エッジ(メンバー)を自走させるためのモチベートに苦戦しています。モチベーションが低いメンバーへの動機づけはどのようにするのが有効でしょうか?

ダニエル・ピンクを読みましょう、というのが書籍的にもいい回答なんじゃないか?ということでした。

EMの重要性を社内で布教するコツ等ありますか?
普通のマネジメントとエンジニアリングマネジメントの違いや共通点を教えてください。
エンジニアリングマネージャーのしごとはピープルマネジメントの話がメインと思いますが、プロダクトマネジメント/プロジェクトマネジメント/テクニカルマネジメントもエンジニアリングマネージャーの範疇だったりしますか?

発達の最近接領域の話が本書籍ではされていますが、プロセス偏重のまとめかたになっているため、発達の最近接領域を意識したまとめ方にはなっており、本書籍を読んだだけでは答えられない質問になっているということでした。

そのため、こうした質問が出てくるのは、もしかすると読者の期待値とずれているのではないか?ということでした。*1

エンジニアリングマネジメントのバイブルは?

これはkiroさんと同じく、現状ないということでした。

自分のマネージャーにこの本を読んでもらいたいと思ったときにメンバーとしてできることはありますでしょうか。

「〜さんの仕事に憧れているんですけど、あんまり手間をかけさせたくないので一緒にこの本を読んでもらえないでしょうか?」ときょんさんなら言ってみるということでした。

なお、きょんさんは、「この本だからこういう説得をする」というのはあまり持ち合わせていないということです。(本を紹介されて喜ばれるのは、「自身の課題とマッチしている上に人から紹介されることが嬉しい」という状態なので、コンテキストに絞った勧め方は諦めているということです)

書籍に関してですが、退職のあたりは日本だと法律等の関係で難しいと思いました。この辺りを日本だとどのように進めるべきかといったことがあれば教えてください。

改善目標の提示と降格は(きょんさんの会社でも)普通にあると思うというお話でした。

技術内容がわからなくてもエンジニアリングマネージャーってできるものでしょうか? 

本を読む限りは、エンジニアリングが必要だと書かれていないですが、技術内容が分からないエンジニアリングマネージャーはできると思う(できるに越したことはないけどそれは何でもそう)ということでした。

なので、キャッチアップが必要だと思うならやった方がいいし、キャッチアップする姿勢を持つことは大事だと思うということです。

ちなみにkiroさん的には、エンジニアリングとテクノロジーは違うというお話で、エンジニアリングマネージャはエンジニアリングは分からないと務まらないけど、テクノロジーが分からなくても務まるというお話でした。

きょんさんが良いと思ったところ

エンジニアはこの本読みやすいよね、という目線で参考文献を書いている感じがあるのが好きだということでした。*2

また、章の冒頭にある引用の筋がいいなあと感じたそうです。

きょんさんから参加者への質問

続いて、きょんさんから参加者への質問がありました。
以下に、質問と回答を書いていきます。

「エンジニアリングマネージャーのしごと」で大事だと思う3つをあげたらなにか?
  • 睡眠の重要性/ネットワークの構築/3章の自分に合わせるなみたいなところ
  • 人間って難しい/前向きな差別
  • アクセプタンス/自分の状態管理/メンバ・チームがイキイキ
  • 人間って難しい/コントロールを手放す/現代の職場環境/その人にあった仕事とは
  • 傾聴/会話を双方向にしよう
「テック業界に関わる人間として成功する人を増やしたいんだけど、〇〇がまとまっていないのでやりにくい」のあなたにとっての〇〇ってなに?
  • DDD
  • 過負荷の認識
  • 立場やメンバ間で認識の差がある現状を理解し、埋めようとする姿勢
  • ドキュメントの書き方
  • TWI(JI/JM/JR)
  • 人が育つ環境(育て方ではない)
  • アジャイルの導入(誰も教えてくれなかったアジャイル開発)
  • チームで共有する価値観やビジョンの作り方・まとめ方
  • コミュ障エンジニア向けの信頼関係構築方法
  •  経営、戦略、ファイナンス、会計、アライアンス、10億円くらいまでの起業、採用、評価制度とか無限に出てきそう
  • プロダクトの廃止の仕方
  • 組織を10人から100人にする方法
  • ロビイング

クイズ

最後にとんでもないクイズがきょんさんからありました笑

  • ____________________、_________「_____、_______、______」_______?
  • ____________________、____________「_____:_______、_____:_____________、_____:______________、_____:_____、______、__」_______?

回答が思いついた方は天才です。

会全体を通した感想

質疑応答あり/クイズありと、久々の特別会で、たくさん楽しむことができました。
きょんさんは勿論ですが、訳者のkiroさんとRyuzeeさんが色々コメントをしてくれていたのも面白くて、訳者との距離が近いのってすごくいいなあと改めて感じました。

間違いなくこの場でしか聞けないような話がたくさん聞けたので、改めて素敵な場だなあと感じました。

*1:エンジニアリングマネジメントとは?という質問には答えられていない

*2:著者名と年代という略記で参考文献が書かれているので、参考文献の内容が想起しやすい

Engineering Management | JMDC Tech Talk #2に参加してきた

jmdc.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

「Engineering Management | JMDC Tech Talk #2」は株式会社JMDCが主催するエンジニア勉強会です。

今回は、主にエンジニアリングマネージャーを志す方や新任の方を対象とした勉強会を開催致します。  
ゲストスピーカーとして「エンジニアリングマネージャーのしごと」の翻訳者の一人である原田騎郎様にご登壇頂き、マネージャーに期待される役割の変化と、最近のエンジニアリングマネージャーに求められる役割についてお話頂きます。  
Q&Aの時間も用意しておりますので登壇内容や書籍の内容に関して質問があれば、申込み時もしくは当日にぜひお寄せ下さい。  
また、弊社及びグループ会社のエンジニアによるエンジニアリングマネジメントに関するLTも予定しております。

原田さんの講演

導入〜マネージャーって何?〜

マネージャーって言葉自体が非常に多義的だよね、と言う話からスタートしていきました。

例えば、マネージャーと聞いた時に浮かぶ言葉としては、以下のようにさまざまなものが挙げられるよね、という話が出ていました。

  • 管理者
  • 上司
  • (野球などスポーツの)マネージャー
  • (野球などスポーツの)監督
  • (芸能人についている)マネージャー

...

マネージャーと言う概念の変遷

科学的管理法

どういうやり方をすれば一番うまく仕事ができるのか?をテイラーが考えられた結果、管理者が正しいやり方を教え作業者がそのやり方に従うという考え方が登場し、製造ラインの導入などにつながったあたりの話が管理者という概念のスタートだと言うお話がありました。*1

ホーソン実験

テイラーの後、仕事の生産性を上げるために寄与する要素は何か?と言うのを実験した結果(=ホーソン実験)、寄与すると思われていたどんな要素も生産性に関係がないことがわかり、最終的には職場の人間関係が一番重要だという結果が出たというお話がありました。

X理論/Y理論

「人は怠けるものなので怠けないように監視するべきだ」というX理論と、「人は本来働きたがりなものなので、より自由に意見を述べられ行動できるように支援するべきだ」と言うY理論が登場したというお話がありました。

この結果、監督者としてのマネージャー/支援者としてのマネージャーという概念が登場し、どっちが正しいかわからない状態になったということです。

The New New Product Development Game

その後、The New New Product Development Gameが発表され、ここではものすごい速さでプロダクトをリリースしていた日本ではどのような管理がされていたのか?というのを研究した結果、同じチームの中で「さりげないコントロール」をマネージャーが重要だという結論が出てきたそうです。(=チームを支援する重要性が示された)

パワートゥザエッジ

湾岸戦争でコマンド&コントロールが話題になったこともあり、末端(エッジ)のチームが判断するための情報を提供し、末端(エッジ)のチームが判断する方が組織としてのパフォーマンスが大きく出るよ、と言う話がパワートゥザエッジで紹介されたと言うことです。

エンジニアリングマネージャーのしごと

ここまでの流れでチームを支援する立場としてのマネージャーが大事なのは分かったけど、じゃあチームを支援する立場としてのマネージャーはどんなことをしているのか?と言うのをまとめたのが直近翻訳された「エンジニアリングマネージャーのしごと」には書かれているという紹介がありました。

その上で、本の内容の紹介がされていきました。

まず自分を管理しよう(2章)

「マネージャーのアウトプット = あなたのチームのアウトプット + あなたが影響を与えた他のチームのアウトプット」という2章のお話が紹介されました。

この式から、マネージャーの評価は自分がマネージしている組織に対しての貢献だけでは評価できないことが示唆されている点が重要ポイントだということです。

発達の最近接領域(5章)

「とりあえずやってみて」と育てられたプログラマーは多いと思いますが、それは変な話で、発達の最近接領域の考え方に従うと「学習者が支援ありでできるタスク」をいかに効果的に活用していくかを考えるのが重要だ、という5章のお話が紹介されました。

コントロールを手放す(13章)

マネージャー自身が疲弊しないように、自身でコントロールできないこと/自身でコントロールできること、をまずは分けた上で、自分である程度コントロールできることに対してベストを尽くすんだ、という13章のお話が紹介されました。

いったん落ち着こう/いったん力を抜こう

最後に、本で複数回出てくる、「いったん落ち着こう/いったん力を抜こう」という考え方が紹介されました。
エンジニアリングマネージャーの仕事は覚えなくてはならないことがたくさんあるので、まずは力を抜いてみよう、落ち着いていこうという考え方をぜひ心に留めておいて欲しいということです。

山本さんのLT

kiroさんの講演後は、JMDCの山本さんからLTがありました。

「エンジニアリングマネージャーのしごと」で言及があった内容を参考に、チームが大切にしていることを明文化し、ジョブディスクリプションを作ったお話でした。

結果的にできたジョブディスクリプションももちろん素敵だったのですが、ジョブディスクリプションを作る過程でチームと話し合いを重ね、その中で心理的安全性の構築が実感できたというお話が、非常に印象的でした。

小原さんのLT

続いてJMDCの小原さんから、ツール(15five)を用いてマネジメントのコストを下げたお話を聞いていきました。*2

15fiveの様子をデモしてくれたのですが、1on1やエンゲージメント、OKRの管理など、エンジニアリングマネージャーが担うことが多いであろう業務が幅広くサポートされており、ツールに興味が湧くような内容でした。

Q&A

エッジ(メンバー)を自走させるためのモチベートに苦戦しています。モチベーションが低いメンバーへの動機づけはどのようにするのが有効でしょうか?

kiroさんは非常によく聞かれる質問だそうですが、モチベーションを上げるのは不可能だということです。

ただ、モチベーションを下げないようにすること(仕事を奪って余裕を作ること, モチベーションを上げようと色々な行動をしないこと)はできると言うことです。
また、(エンジニアは特に)面白い問題に飛びつきがちなので、面白い問題を与えておくことと、飛び付ける余裕を作っておくことが大事だとも話されていました。

EMの重要性を社内で布教するコツ等ありますか?

こんなことをやっているよ、というのを周りに見えるようにした上で結果を出し、周りから自然に興味を持ってもらうようにすることがいいのでは?ということでした。

ただ、こうした取り組みをするのにも余裕が必要なので、マネージャー自身がまずは余裕を持つことが重要だと言うことです。

「エンジニアリングマネージャーのしごと」でkiroさんが共感できなかった章があれば教えて欲しいです

最後の方にあった、メンバーのキャリアプランの構築を助ける話が書かれている章については、ちょっと雑すぎないか?(もう少し実験してからやったほうがいいかな?)ということでした。

自分のマネージャーにこの本を読んでもらいたいと思ったときにメンバーとしてできることはありますでしょうか。

複数冊買ってばら撒いて見えるところに置いておくのがいいのでは?ということでした笑

電子書籍だとできないのが難点ですが、読後感があるとその本に食いついてくれる可能性は高まるそうです。

書籍に関してですが、退職のあたりは日本だと法律等の関係で難しいと思いました。この辺りを日本だとどのように進めるべきかといったことがあれば教えてください。

日本では退職は難しいよねという話はありつつ、高いパフォーマンスを発揮できる領域/できない領域が個々人であるので、役割を変えてみるのは一つではないか?ということでした。(逆に海外ではこれはできない)

エンジニアリングマネジメントのバイブルは?

難しいですが、現状はまだないということでした。

なお、マネジメントという観点だと、(バイブルという一神教の存在はないものの)high output managementはおすすめだそうです。

kiroさんが考えるEMの魅力は?

チームが色々なことがみるみる上手になるのを見るのはすごく面白いというお話がありました。

次翻訳したい本は?

山ほどあるそうですが笑、自分が「余裕を大事にしろ」と言っている手前上、今は着手を決めていないということです。

普通のマネジメントとエンジニアリングマネジメントの違いや共通点を教えてください。

違いを見出すより、「マネジメント=チームやメンバーの支援を当たり前にすること」の世界になるといいなあと思っているそうです。

エンジニアリングマネージャーのしごとはピープルマネジメントの話がメインと思いますが、プロダクトマネジメント/プロジェクトマネジメント/テクニカルマネジメントもエンジニアリングマネージャーの範疇だったりしますか?

レイヤーは組織によってなので難しいし、分からないというお話でした。

また、あんまりレイヤー分けを効率よくやることに着眼してもしょうがないし、少し重なっているくらいでも良いのでは?と言うことでした。

英語はどのように学んだのか?

kiroさんは大学時代翻訳のバイトをよくしていたそうで、そこでプロの翻訳者の方と関わる機会があったそうです。

あとは、毎日15分ラジオを聴いていたのとシャドーイングをしていたそうです。

会全体を通した感想

先日ryuzeeさんの出版記念講演(??)も聴いたのですが、今日はkiroさんからまた別の角度でお話を聞くことができて、学びがより深まりました。

Q&Aでは、本に関係ない結構意外な質問も出ており、非常に楽しかったです。

*1:製造業のコンテキストで言うとフォード生産方式の考え方もある

*2:15fiveと利害関係があるわけではない

【祝: 完走!】ZombieScrumSurvivalGuide読書会 #12に参加してきた

yasashii-agile.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

アイスブレイク

健康のためにしていること、を話していきました。
皆さん健康意識がめちゃくちゃ高くて、自分も何かしなくては...と焦りが生まれました。*1

話したテーマ

スクラムマスターは手を出さない、が「何もしてない」と偉い人に思われる説明が難しい

  • 本当に何もしていないことはないと思うので、今自分がやろうと思っていることやMTGで見ていたことなどを提示する
  • やりたいことを書き出してみる(外からチームを見ている人だと、スクラムマスターがどんなことをやりたいか分かっていないので可視化する)
  • 芝居的に(!?)、「スクラムマスター最高!」と言ってみる
  • 360度フィードバックをして、部長に提出する
  • やっていることを可視化することが重要
  • 課題リストを提示する
  • 「何もしていない」と偉い人が思ってしまうのがまずいので、リソース効率とフロー効率の話をする
  • Zoomの背景を使う(課題リストを背景にしておくなど)

Zombie ScrumでおすすめしたTeam health assessmentをやった経験があるか、これに関する意見を聞きたい

  • 視点はいいと思った。ただ、作りこみが内製チーム向けの設問が多い印象があったので、外注チームでは難しく感じた。
  • もっと軽いものをやってみている。
  • 定期的に指標としてトラッキングしていくのは重要だと思う。
  • (やってみた結果をシェアしてくれた上で)現状を把握することができた。

リモートも多いし物理的にスクラムボード置く場所がないんだけど…ベターな方法は?

  • Miroを使う
  • Slack botを多用する(botのキャラクターを指定するなど、飽きさせない工夫がある)
  • オフラインの時と比較して、3倍くらいの頻度でチーム全員がスクラムボードを見る機会を設けるようにする
  • チームと合意していればなんでもいい

チェックアウト〜今後〜

Professional Agile Leaderを次回からは読んでいくことが決まりました!

会全体を通した感想

コツコツと読み進めてついに読破することができて、純粋に嬉しかったです!(ギリギリ日本語版の発表に間に合いませんでしたが笑)

具体的なプラクティスベースではありますが、引き出しが結構増えた感覚があるので、色々と実践してみたいと思います。

*1:中には土日に70km歩くという方もいらっしゃいました

大人のソフトウェアテスト雑談会 #126【ポジティブ】に参加してきた

ost-zatu.connpass.com

三河のその後

三河で衝撃的な発表をしてくれたeroccoさんが、三河の発表後の裏話をしてくれました。

ミルクレープ戦法の方は、発表が終わった後にもikumiさんは「アジャイルがわかってきたようなことを言ったけど本当だったのかなー」といった感想を淡々と話されていたということで、変に納得感がありましたw

XP祭り

今週末に迫ったXP祭りの話をしていきました。

自分も含めスクフェス三河に参加していた人たちは、祭り続きで体力が消費されているようですが笑、XP祭りも楽しんでいこうと思います。

定義が曖昧なロール(SM/EM/PM/QA)

SM / EM / PM / QAなど、定義が曖昧なロールの話をしていきました。

どのロールも採用マーケットが形成されつつありますが、それぞれのロールの定義が曖昧で採用をしている側もよくわかっていない状況になってしまっており、カオスな求人が多数生まれているということです。

じゅんぺーさんとTommyさんの出逢い

Tommyさんから、じゅんぺーさんと出逢ったおかげでQAに対するイメージが変わったというお話を聞いていきました。

Tommyさんは、PodcastでじゅんぺーさんからQAの話を聞いたときに、チームビルディングですら品質を高めるという意味でQAの仕事の範疇だという話を聞いてQAに対する見方が全然変わったそうです。

内容もさることながら、熱い話を聞けて満足でした。

育成には興味がないという会社

カジュアル面談を多数していくと、「うちの会社は育成に興味がありません」と明言する会社もあるという話を聞いていきました。

「強い」人がいて仕事がうまく回っている状況であれば育成にあまり興味がないという話や、人材紹介会社などとパイプがあって人の採用にそこまで困っていない&資金が豊富というコンテキストだと育成の必要性がなくなる、という話でした。

ただし、後述する「育成とは?」の話にも書いたように、人によって何を「育成」と考えているかはずれているので、例えばエンジニアというロールから見た時には育成していないように見えても、人事のロールから見た時には育成していると思っている、といったことはよくあるので、注意したほうがいいという話も出ていました。

育成とは?

上の話から派生して、育成トークをしていきました。
皆さんが思っていたり現場で見聞きしている「育成」の定義を色々聞くことができて楽しかったです。

  • 企業活動が循環するように、従業員に対して投資をしているかが育成だと思っている。(意義を感じて投資をしていればいいので、企業によっては、メカニズムを触れずにパターンをひたすら教えるようなものでもいい)
  • ただただ仕事を与えてしまっているような状況だと、本人はプログラムを書けるように思えていても実際は全然プログラムを書けず...*1みたいな事態を避けるために抽象化をしてあげるような活動だと思っている*2
  • 学び方や成長の仕方を教える活動
  • 「育成という活動に対して意義を感じているか?」と「育成という活動に効果があったか?」という話は別の話なので、切り離して考えた方がいい

育成や教育、学びという言葉は文脈依存性が強いのでズレが起きやすいよね、という話題も出ていて、よく出るテーマなだけに今後会話をするときは意識していきたいなあと思いました。

全体を通した感想

後半の「育成」トークは、めちゃくちゃいい話が多数聞くことができる神回でした。

それ以外の話でも、Markさんがとあることをしながら参加していたり、仕事のリアルすぎる話が展開されていたりと、びっくりするほど葛飾な回でした笑

*1:なんで動いているのかがわからない、言語が変わると全く書けない...

*2:カニズムの説明をしたり、関連本をナビゲートしたり...

マネージング・フォー・ハピネス 出版記念講演に参加してきた

management30.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

ヨーガン・アペロ氏の書籍「Manageing for Happiness」の日本語訳された本「マネージング・フォー・ハピネス」の出版を記念したイベントです。

翻訳者の寳田雅文さんの講演を聞き、その後にLean coffee形式で参加者が話す、という流れでイベントは進んでいきました。

会の様子〜講演〜

以下、スライドと会の様子を記載していきます。

speakerdeck.com

Management3.0の定義

ヨーガン・アペロ氏が提唱したもので、仕事を取り巻くシステムの捉え方を述べているものであり、FW/プラクティスではなくマインドセットを指しているものだとお話がありました。*1

Management1.0/Management2.0とはOSレベル(前提としている考え方)から差異があるということで、Management1.0/Management2.0で前提としている階層型によるコントロールではなくネットワーク型によるエンパワーメントを前提としているということです。

Management1.0とは

階層型によるコントロールを前提として、そこで働いている間違った行動をしてしまう人たちを統制・監視することが重要だという考え方が紹介されていました。

Management2.0とは

階層型によるコントロールを前提としつつ、そこで働いている人たちを最大限活かすために、マネージャーがサーバントリーダーになったり、1on1で目標管理することなどを強制するような考え方だとお話が出ていました。

本(1-12章)の構成

ヨーガンの個人的な経験が語られた後に、原理*2が紹介され、最後にプラクティス*3が紹介される、という構成になっている、と紹介がありました。

Management3.0で原理とプラクティスがセットで提供されている理由

原理だけ提供されても行動はできないですし、プラクティスだけ提供されても文字通りにプラクティスが受け取られてしまってその組織のコンテキストに合わせられないため、Management3.0で原理とプラクティスはセットで提供しているということでした。

Management3.0とマネージング・フォー・ハピネスにおけるマネジメント

Management3.0では、ラインマネージャーが自身のロールを理解する補助となるのが第一のゴールとされており、マネージング・フォー・ハピネスではクリエイティブワーカー*4の仕事がマネジメントだと解釈されているというお話がありました。(=マネージング・フォー・ハピネスは管理職向けの本ではない)

マネジメントの委譲度合い

  1. self-Managed(自己組織化)
  2. Self-Selected(自己選択)
  3. Self-Governed(自己統制)

の3段階がマネジメントの委譲度合いとしてはありますが、マネージング・フォー・ハピネスでは、上記1と2の間くらいのコンテキストで話がされているということです。(少数のマネージャーは必要だというスタンスをとっているため)

マネジメントする対象

人ではなくシステムをマネジメントするんだという考え方がマネージング・フォー・ハピネスでは取られているということです。

なお、ここ最近のヨーガンは「人々はマネジメントするのではなくリードする」と話されているということで、リーダーシップは皆が担うものだと考えられているそうです。

Management3.0の軸となる考え方

人や組織は複雑適応系*5であり、中央集権的なコマンド・コントロールからは一線を画しているということでした。

また、Management3.0を実践する人は複雑系思考者であるという前提も置かれているということです。

複雑とは?

構造(理解しやすさ)と、振る舞い(予測しやすさ)の2軸で捉えているということです。
寳田さんの以下スライドのP16にも分かりやすく記載されています。

speakerdeck.com

他にも、指標→観察→イノベーション→戦略→合意のプロセスをとるシステム思考の考え方も紹介されていました。

複雑系への対応

メンバー全員のコントロールを完全にするのは、メンバー全員の複雑性をマネージャーが備えていないと無理なため、中央集権型でコントロールするのは難しいという話がありました。

そのため、コントロールではなく、「導く」「コーチする」「刺激を与える」「支援する」...が対応する際のアプローチとして適切な言葉ではないか?という話も出ていました。

トリプルループ探求

www.change-agent.jp

寳田さんが翻訳された感想

寳田さんから、翻訳した感想を聞いていきました。

  • 原文があるので0から何かを生み出す必要はない
  • 何者にもなれない人の生存戦略になるかもしれない
  • 自身が翻訳したことで、Management3.0が会社全体に広まった

ということでした。

会の様子〜講演中にあった質問に対する参加者の回答〜

講演中にいくつか質問があり、それに対して参加者の皆さんが回答をされていたので、以下に記載していきます。

自分の仕事でRightなことって何?それをRightにやるってどういうことなの?

  • すぐにレスを返す 
  • 言いづらいことをちゃんという
  • 我慢しない、抱え込まない
  • 困った時に困ったっていう
  • 人がやらないことをやる
  • 議論の中で人格否定をしない。人格否定みたいな発言を2回したら退場(クビ)にさせるのがRightな行動。
  • 自分事として仕事をする
  • ちゃんと休める
  • 役員にいわれたからではなく、本当にやるべきと納得していること。Rightな行動は、
  • 牲者がいても、その声に耳を傾けながら進むこと。

チームで実施しているプラクティスは何の原理に基づいて実施されている?

  • インセプションデッキとか振り返り
  • 振り返り
  • ラクティス: にこにこカレンダー, プリンシパル: 相手への関心
  • ラクティス:ふりかえり, 原理:ふりかえって立ち止まる。目的を見直す
  • 仕事中ずーっとZoomつなぎっぱなし → いつでも分からないことが聴ける
  • 雑談タイム(テーマトーク)。仕事外のコミュニケーション重要
  • 大げさにうなずく

複雑系にアプローチするのに適した言葉は?

  • ではどうしたらいいか?(一緒に考えようか?)

複雑系にアプローチするのに適していない言葉は?

  • やれ
  • 黙れ
  • なぜできないのか?
  • 全部チェックする

ワーク〜ムービングモチベーターズ(ディープエクスプロレーション)〜

講演の中で、ムービングモチベーターズなどを参考に作られた、ムービングモチベーターズ(ディープエクスプロレーション)のワークをやっていきました。

以下の質問に、参加者それぞれで答えていくような形式でワークは行われました。

  • 今週モチベーションに影響した仕事上の出来事は?
  • 誰といるときに起こったか?
  • それはどこで起こった?
  • それはいつ起こった?
  • 似たような出来事は前にいつ何が起こったか?
  • それは誰といるときに起こったのか?誰が周りにいた?
  • 似たようなことはどこで起こったのか?
  • それらに共通していたことと、共通していなかったことは?
  • 10のモチベーターで言うと何に関連してそうか?
  • それは10のモチベーターで何番目に重要だった?
  • そのモチベーターはどう動いた?
  • そのモチベーターが上がると自分はどうなる?
  • そのモチベーターが上がるためには周りの状況がどうなるとよかった?
  • そのモチベーターが上がるには自分がどう動くとよかった?
  • そのモチベーターが上げるためにはシステムにどう手を入れると良いか?
  • 上記について、他の選択肢はあるのか?
  • システムに手を入れる際のリスクは?
  • それはいつ実施できるか?
  • それがうまくいったかの判断はいつすればいいか?
  • それがうまくいったかをどう判断するか?

Lean Coffee

次イベントもあって20分弱と短い時間でしたが、Lean Coffeeに参加してきたので、話した内容を記載していきます。

階層がないよね、といっても階層構造に依存している社員もいるがどうすればいい?

言われていることをやっている人が楽という人もいると思うが、どう対処しているのか?という話を聞いていきました。以下のような話が挙がっていきました。

  • 出島戦略を活用していくことで、階層構造を崩していく。
  • 階層構造が問題というよりは、「その人の理想的な振る舞い」と「目標がトップダウンで決められてしまって振る舞いが制限されていること」の摩擦が問題なのではないか?
  • 階層依存じゃない世界を体験できる実験を本番じゃない安全な場で体験させる。そもそもどういうことか体感でわかんないと「その世界を作りたい」みたいに感じなさそう。
  • 黒船ドーンじゃないと変われないとしたらそれはちょっと悲しい
  • 組織全体が旧態依然だと苦しい

会全体を通した感想

Management3.0は初心者でしたが、バックグラウンドを一から丁寧に説明してくださったので、楽しく参加することができましたし、学びも多かったです。

講演中にあったワークも非常に楽しかったのですが、ジェットコースターに乗っているような感覚があって、Muralにすごい勢いで付箋が貼り付けられていく様子を見るのは圧巻の一言でした。

*1:マインドセットの具体的な実装として、FW/プラクティスがある

*2:ある人や集団が良いとする信念。普遍的なもの。

*3:原理を実現するために取る行動で、初学者でも取り組めるような具体的なもの

*4:ネットワークで独自の価値を創造したりする人or自分のやり方でネットワークを育て、皆と価値を共有できるようにする人

*5:ジョン・H・ホランドやマレー・ゲルマンらが作った造語。理解しやすくしようとシンプルにモデル化しても、出てくる振る舞いはシンプルにならないという考え方。蟻のコロニーやインターネット、証券市場といったシステムが具体例。

スクフェス札幌2022で登壇できることになりました

タイトルの通り、スクフェス札幌2022で登壇できることになりました!

採用通知が届いて

Accept通知があまりにも早かったので、間違えて押されたのかな?と最初は思ったのですが、どうやら本物の通知のようで、安心しました笑

発表場所

札幌は妻の実家があることもあって、スクフェス札幌は現地に行こうと思っています。
なので、現地で登壇することになりそうです!

オフライン参加は、DevOpsDays Tokyo以来なので、皆さんとの再会ができることをすごく楽しみにしています。

同時に、オフライン登壇はめちゃくちゃ緊張することが想定されるので、いつも以上に色々なことが起きることを想定して準備をしなければ。。という気持ちです笑

登壇のいきごみ

スクフェス札幌は自分が人生で初めて参加したカンファレンスで、コミュニティやカンファレンスの素晴らしさを教えてもらった場でもあるため、今回のプロポーザルの内容をスクフェス札幌の場で話すことができるのは本当に嬉しいです。

スクフェス札幌2022は魅力的なプロポーザルが本当に多く*1、選ばれるか自体が怪しいなあと本当に思っていたので、登壇できることを幸せに感じています。

一方で、これだけ魅力的なセッションが集まる中でAcceptいただけたことに対して気負う気持ちや、責任重大だという感情も多少はあるというのも正直なところです。
自分の場合は、気負うことがプラスにはならないと思うので、「自分自身の発表が魅力的なものになるように全力で準備しよう」と、ある程度割り切って準備しようとは思っていますが、魅力的なプロポーザルを出してスクフェス札幌を盛り上げてくださった皆さんの想いを確実に噛み締めながら、準備&登壇ができればと思っています。

おわりに

likeを入れてくれた方々や選んでくれた方々には、改めて感謝をしたいです。どうもありがとうございました。

スクフェス札幌当日の自分にとって最高の講演ができるように、今から全力で準備に励みたいと思います!

*1:ConfEngine上で自分自身が押せるlikeも尽きてしまっていました