見出し画像

若手エンジニアがコミュニティを超えて読書会を行った感想 ~エンジニアリング組織論への招待 前編~

こんにちは、ARエンジニアのイワケンです。

先日「アクティブブックダイアログ」を実施した記事を投稿しました。そこから別の人から「アクティブブックダイアログ興味あります!」と声がかかり、そこからメンバーを集めて実施するまでの流れと実施してみての感想をこの記事では述べたいと思います。

読書会のキッカケ

私が前回のnoteを投稿し、Twitterで感想をツイートしたところ

画像1

とむくん から「ぜひ参加してみたいです!」とリプライが来て企画がスタートしました。

とむくんと私は、サイバーエージェントという会社の先輩と後輩の関係でありつつ、部署が違うためガッツリ絡んだことはありませんでした。いわゆる知り合いの関係です (clubhouseが流行った時期に結構話した感はあるけども)

そこから「読書会」を媒体として、色んな人とのつながりが増えていくことになります。

読書会の募集をSlackのtimesで

とりあえず6人で行いたいと思ったので、あと4人集める必要があります。

すごいラフに自分のSlackのtimesに投げました。

そしたら、何人か反応してくれました。どの人も喋ったことはあるけど、普段の業務では共にしない人ばかりでした。

しかし「読書会」を通じて、新たなコミュニティを作っていこう、という想いがあり、前向きに受け入れていきました。

結果的に、色んな部署から集まり、6人で実施することができました。
内定者も1人参加してもらえました。

画像2

画像3

ヒアリングしながら実施方法を確認

メンバーが集まったので、どのように実施するか決めました。

ある程度、私の方で型を作りつつも、メンバーの意見を尊重して決めました。

ヒアリングしたのは

・本の選択 → エンジニアリングの組織論への招待に決定
・実施時間帯 → 平日の夜か、休日か→平日夜に決定
・事前要約か、当日要約か → 当日要約に決定

などです。

一緒に勉強会を盛り上げていくために、Why (なぜやるのか) を共有した上で、How (どのように実施するのか) はみんなの意見を聞いていくと、自分事化しやすいのでは?という仮説で行いました。

本の選択に関しては「皆が興味があるもの」を選びつつ「企画者のこだわり」を可視化することを意識しました。本を選ぶとき沢山候補がでて選べないというときがあります。

画像4

僕がこの本を推したかったのは

・自分自身 社会人2年目で開発責任者で悩んでいた時に、この本に救われた
・この本の考え方を共有していくと、チームとして強くなる強い仮説があった

この2点です。それで2冊目以降から、みんなの読みたい本を聞いていこうかなと考えていました。

また、実施時期が「休日より平日夜が良い」というのは、個人的には新しい気付きでした。

事前要約か、当日要約かというのは、アクティブブックダイアログの良いところとして「事前準備無しで手ぶらで参加して実施できる」というところを体験したいとなり、当日要約スタイルとなりました。

当日の進行スケジュール

当日はGoogle Slideに行うことを準備し、Zoom上で進行しました。

9_29 abd21th エンジニアリングの組織論

だいたい2時間半で終わる予定でしたが
19:50スタート, 22:40終了で 2時間50分くらいかかりました。具体的には

・サマライズが40分 -> 50分
・ダイアローグ 40分 -> 50分

に時間変更が起きました。

これ自体は悪いことではないと思っています。これらの情報を元に次回のスケジュールを次のように決めました。

・事前に要約する章を割り当てる
・当日要約を30分

初回である今回は担当章を当日割り当てにしました。
その結果、文章の理解と要約を40分で行わなければならず、時間が足りなくなりました。次回の試みとして事前割り当て、当日要約にすることで、当日は要約に集中することができるのではないかと思っています。

本の内容を少しだけ紹介

エンジニアリング組織論への招待の内容を少しだけ紹介すると、キーワードとしては

・不確実性とエンジニアリング
・経験主義と仮説思考
・全体論とシステム思考
・メンタリング
・心理的安全性
・アジャイル

ここらへんですね。

序盤で好きな文言があります。こちらは要約の一部のスライドです。

9_29 abd21th エンジニアリングの組織論 (2)

エンジニアリングとは「不確実性を効率よく削除し、何かを実現すること」

この「不確実性を削除」という主張が本書の特徴ですね。

目指す先が「自己組織化された組織」すなわち「抽象化で自由度の指示」でも動ける組織、つまり自走できる組織を目指す。
不確実性の発生源として「未来」と「他人」があるので、その不確実性を減らす仕組みや文化を組織でつくる。
その削除の仕方が「情報を生み出すこと」である。

具体的ケースを置くと「このプロジェクトはいつ終わるか」というのは未来に対する不確実性です。見積もりというやつですね。有名なのが不確実性コーンです。これを効率よく減らすために、エンジニアは序盤に技術検証や仕様を明らかにするムーブなどすることがあります。

画像7

私は2年目のころ見積もりに対する対処の仕方がわからなく仕事で悩みました。なぜ見積もりができないかと言ったら「やったことないことに対してどう見積もるのか」「長期プロジェクトに対してどう見積もりのか」というのがわからず、ズルズル放置してしまいました。そこから周りに相談せず「進んでいると思われていた」状態を生んでしまいました。結果、プロジェクトは非常に不確実性が高い状態になり、会社に迷惑をかけてしまいました。

これは「未来」への不確実性と「他人」への不確実性への立ち向かい方を知らなかったからゆえに起きたことでした。

私が当時この本を読んでいなかったら「悩み」が「悩み」のまま放置されていて「仕事ツライ」という状態になっていたでしょう。現在は「悩み」が「問題」になっており「こうすれば解決できそう」という思考になっていて、精神が安定するようになりました。

ダイアローグ時間は、言葉の定義の深堀と自分の経験談を交えて対話

ダイアローグ時間では、気になった言葉の定義の深堀や、自分の経験談を交えてケーススタディ (どうとらえるべきだったのか) を行うと良いことがわかりました。他にも良い対話のフレームワークがあったらコメントで教えてください。

参加者の感想

サマライズをやってみると難しい。その代わりに他の人のサマライズにコメントすることを頑張った。議論することのメリットを大きく感じた
・発表を聞いていく中で、自分の経験談と本の知識を絡めると説得力が増すことに気づいた。知識の引き出しが増えてよかった。
一人で本を読むだけでは得られない文章への感じ方を議論できてよかった。要約を強制する仕組みはだらだらしなくて良いと思った。
共通知識を前提として議論できるのが良かった。それを元に経験談を深く議論できるのが良い。
・サマライズで伝えたい気持ちが高まりすぎたと反省。本の意味の深堀が多かったので、次回は自分の経験談ベースの話をしたい
・楽しかったので次回も参加したい

主催者兼参加者として感想

今回、同じ会社であるものの普段接していない後輩と読書会を行ったわけですが、この本に即して言うと「後輩と接する中で心理的安全性を作り出すか」というのが自分自身の裏テーマでした。

メンバーからすると、あまり喋ったことがない先輩と読書会、というのは「心理的安全性が低まりやすい」つまり「偶発的な気づきが出にくい状態」なのだと思います。その中で、実施までに色んな工夫をしつつ、もっとこうできたなというのもこの本を読んで色々でてきました。

例えば、最初のチェックインというアイスブレイクで自分を感じていることを話す機会を作ったのは良かったと思いつつ、自分自身の発表の時「もっと自分の弱みを自己開示するようなことを言えばよかった」というのを思いました。

9_29 abd21th エンジニアリングの組織論 (3)

これは、読書会のダイアローグの時間で「心理的安全性」を上げるために何を具体的にするか、という議論の中で改めて気づかされた部分です。

また、参加者として「対人リスクが高い人の心理を知る」というのが僕自身の楽しみでした。というのも、僕自身は「自己組織化された個人」になりつつあり、他の人とコミュニケーションする中で「仕事上でこれ言いにくいな...」というケースが減りつつあります。その中で、今日のメンバーの多くは社会人1年目で「これは先輩に言いにくいな...」「この仕様に対するコメントしずらいな...」といった、リアルな「対人リスクを恐れている状態」「心理的安全性が低い状態」を傾聴して、ディスカッションできたのは非常に有意義でした。その中で、どう接すると良いか、どういう組織の仕組みを作っていくと良いかというのが大事だと思っています。

次回は2週間後!

お楽しみに!

よろしければサポートお願いします! サポートいただいたお金はハッカソンの運営に使わせていただきたいと思います。