言語化"しておく"ことが大切だと思うこの頃
メリークリスマス！
2025年クロスマートアドベントカレンダー25日の記事です！
今年は私が言い出しっぺでやらせていただいたアドベントカレンダーですが、とても嬉しいことに、本日まで全てが埋まる形で来ることができました！🎉🎉
ﾍｲｼｬの活気あふれるノリと勢いがめちゃくちゃ好きです！（参加してくださったみなさんに大感謝！！！！！）
そんなアドベントカレンダー、様々な方が参加してくれていることからも、漠然と多くの方がブログを書くことに価値を感じているものと思います。私もその一人です。
そこでこの記事では、ブログなどでアウトプットすることがどうして重要だと感じるのか、自分をふりかえってみることにします。
自分の活躍をアピールするため？文章がうまくなるため？自分の記憶の定着のため？
これらもとても大切だと思うのですが、私はアウトプットの意義は自分の意見の骨子を持つためだと考えています。
かつてからの悩みについて
私は昔から、自分の意見を持てないと感じておりました。
何かついての意見を求められた時に、うまく言葉をまとめることが苦手でした。また、仕事や雑談などで何かの話題が出てきたとしても、僕の口から出てくるのは誰かがXで言っていたことや、記事や書籍で読んだことの受け売りでした。
一時期その受け売りを自分の「意見」だと思っていたのですが、受け売りは受け売りです。自分の意見ではありません。
気づけば、私の中の「意見」だと思っていたものは「インターネットでバズっているものの平均」になっていました。
なぜこのようになってしまうのか
なぜこのようなことが起るのでしょうか。それは私が、何かの事象についての意見を言語化する訓練が足りていなかったことが原因だと思っています。
例えば、Xで誰かがある技術の素晴らしさについて熱弁していたとした時、私はその技術の素晴らしさを素直に受け入れ、納得してしまいます。
しかし、その後別の方がAについて批判していたとすると、私の思いはその反対意見にいとも簡単に上書きされてしまうのです。
喩えるならば、風が吹く方向に自分の思いが揺らいでいく風見鶏のような状態になってしまっていました。
このようになってしまったのは、出来事を知識としてそのまま自分の頭の中に入れる癖がついており、頭の中に入れる前に出来事の言語化を放棄していたためでした。
私の考える言語化の利点
「言語化が重要」という話は、人への伝え方を改善する文脈で語られることが多いように思います。
ただ、言語化をすることのもう一つの大きなごりやくとして、自分の意見を他者と比較可能な状態にすることができることだと私は考えています。
以前の私のように、ある出来事を自分の中に何も変換せずに取り込む場合、その情報は知識として加工されず頭の中に入ってきます。そのため、情報は伝聞のような形としてのみ、私の頭のなかに存在してしまいます。
しかし、一度自分で、反対なのか、賛成なのか、自分にどのような影響があるのかを一度考えることによって、自分の意見と他の人の意見を比較できるようになります。
これこそが、真の自分の意見です。
これに気づいてから、私は一歩ずつ自分の中でどう感じたのかを言語化する癖をつけるようにしてみています。
どのように言語化しているか
言語化は、自分の頭の中だけで行うこともいいのですが、私は雑にでも自分の感じたことを書き出すように心がけています。
私が書き出している先は以下です
- 会社のTimes
- 自分が管理しているNotionのページ
- ブログ（放置しがち）
- 手元に置いてある手書きメモ
特に、自分が管理しているNotionのページには、何かを見たときの率直な意見だったりを書き殴れるようにしております。
外部のブログなどに書くこともしていきたいですが、まとめたものを外用に再編するのは、また別のハードルがありまだできていません（今後の課題です）。
言語化の効能
実際に、頭の中にあるイメージを文字にする過程で、自分の意見を目で見ることができるようになります。論理の破綻が見つかるかもしれませんし、思っていたほど自分が意見を持っていないことを受け入れなければいけないかもしれません。しかし、その試行錯誤の末に初めて、他の人の受け売りではない、真の自分の意見と出会うことができます。
このような取り組みを結構前から心がけてきているのですが、かつて自分がコンプレックスのように思っていた「自分の意見が持てない悩み」は最近あまり感じなくなりました。
今では、このような小さなアウトプットを積み重ねた先に、新しい視点や、説得力のある意見が生み出されるものだと、私は感じています。
特に、仕事などでの意思決定に迫られた時や、登壇資料を作る際には、この小さなアウトプットの積み重ねが効いていると感じます。
さいごに
最後まで読んでくださりありがとうございます。
ブログを書く、日報を書く、日記を書く。日々小さな言語化を"しておく"ことが、自分の意見の根幹を持つためにも重要だと思う という話をしました。
もし、かつての私のような悩みを持っている方の解決になれば嬉しいです！
そして、これからも小さな言語化を重ねて、一歩ずつ前に進んでいけるように頑張ります！
おしまい！メリークリスマス！
ルルーシュから戦略と戦術の違いを学びたかった
こんにちは。
この記事は、エンジニアニメアドベントカレンダー22日目の記事として出る予定でした。
遅れてしまってごめんなさい。
言い訳をさせていただくと
表題の通り、私はルルーシュから戦略と戦術の違いを学びたいと思い、この記事を認め始めました。
というのも、『コードギアス 反逆のルルーシュR2』10話にて、主人公ルルーシュが
「星刻に教えてやる、戦略と戦術の違いを！」
という言葉を発します。
私は星刻ではないのですが、ちょうど戦略と戦術の違いを知りたかったので、ルルーシュから教えてもらおうと思っていました。
しかし、続きを見ていても、ルルーシュは戦略と戦術の違いについて教えてくれません。
このままでは、アドベントカレンダーにかけないじゃないか！！！と思いながら、コードギアスを観ていたのですが、コードギアス、とても面白いですね。
年末はコードギアスを見直そうと思います。
まとめ
まとめることもありません🙇♂️
ただ、もう少し考えればコードギアスを通して戦略と戦術の違いをいい感じに説明できそうな気がしています。
なんと、「【劇場版】アニメから得た学びを発表会」がありますね！！！
トーク募集締め切りが、12/28です！
私はここのプロポーザルとして、ルルーシュから学ぶ戦略と戦術の違いについて考えたものを提出しようと思っています！（宣言）
みなさんも、ぜひ、【劇場版】アニメから得た学びを発表会 にプロポーザルを出しましょう！！！
おしまい
目的に立ち帰り、チームの儀礼的ふりかえりを改善した話
この記事は「ふりかえりアドベントカレンダー2025（裏）」の15日目の記事です！！！
はじめに
私は、一つのプロダクトを開発しているPMを含めた6名のチームに所属しており、ふりかえりのファシリテーションを行っています。
そして現在、もともと行っていたKPT的なふりかえりを変更し、以下のような独自のフォーマットを用いたふりかえりを行い半年以上継続しています。
今回は、なぜこのような形にふりかえりの形を変更したのかなどのお話を通して、この形にする上で大切にしていたマインドなどについてお話しようと思います。
チームで行なっていたふりかえりについて
我々のチームでは、二週間を1スプリントとし、スプリントの終わりにそのスプリントについてチーム全体でふりかえる時間が設けられています
これまでは、以下のような流れでふりかえりを行なっていました
- メンバーそれぞれが、Keep、Problem、Tryについての話題を記入する
- 時間になったら、メンバーが一人ずつ、それぞれの話題を紹介する
- メンバー全員分行う
このような形式を取ることで、スプリント内の自分の行動を振り返ることができていました。また、チームメンバーのプライベートの話題も満遍なくお話しすることもでき、リモートワークがメインの我々のチームの近況を知るいい機会にもなっていました。
この形式の課題感
しかし、この形式でふりかえりを行なっている中で、私は以下のような課題感を感じていました。
- チームで顔を合わせているのに、チームを主語としたお話が出にくい
- それゆえに、ふりかえりを行なった前後で、チームに変化はあまり起きない
- そのため、チームに問題があったとしても、気づいた人が率先して行う形に依存してしまっている
「スプリント最終日にみんなで集まって起きたことについて話す会」となっていたふりかえりは、スプリント最終日になんとなるやる儀礼的なイベントのようになってしまっていたのです。
チームで開発を行なっている以上、意図しない手戻りや認識の齟齬など、人と人とのコラボレーションの界面で発生する摩擦は必ず発生します。その摩擦がチームの話題に上がらなかったり、一部の人間が問題カバーし続ける状態は健全な状況ではなく、改善していきたいと私は思いました。
そこで、このチームの摩擦を低減するような役割をふりかえりの時間に持たせることを目的とし、改善を行いました。
課題が発生してる原因についての仮説
ふりかえりでチームの話題が出ないことの原因としては以下のことが考えられました。
- 進め方が個人の話題を前提としてしまっている
- Keep=ポジティブニュース, Problem=ネガティブニュース というイメージが過度に浸透しており、メンバーがそれに囚われてしまっている
この原因に対処するために、ファシリテーターの声かけ方法の変更と、ふりかえりの進め方の変更を行いました。
実際に行ったこと
実際に行ったことについてお話します。
ふりかえりボードの変更＋進め方の変更
言語化できていないようなモヤモヤした感情や、課題感でも話題に出していいことを強調することを目的とし、チームに取り組む以下のようなボードを作成しました。
- 感謝・見習いたい → チームメンバーに対しての感謝や、見習うべき行動を書く欄です。日々の感謝を伝えることや、個人の良い取り組みを、チームの学びとして引き上げることを目的として設置しました。
- これやってみて良かった！・続けていきたい → 自分が取り組んでみたことについて、他のメンバーにも共有したいことを書く欄です。個人の取り組みが共有されることにより、チームへの良い効果が波及することを目的として設置しました。
- 言葉にならないモヤモヤ → チームでお仕事をする上で、「なんでこうなってるの？」「これやりにくいとみんな思ってないの？」など、解決策を思いついているわけではないけど、課題感を感じているものについて書く欄です。みんなが疑問に思っているけど、誰も話題にしていないような"elephant in the room"的な問題を掬い上げることを目的として設置しています。
- ヒヤリハット・スプリント中の課題感 → スプリント内で発生した具体的な問題を書いておく場所です。客観的な事実をベースとして、改善できることはないかを議論することを目的として設置しました。
項目をKeepやProblemなどのシンボル名にするのではなく日本語にしているのは、メンバーが何を書けばいいかをわかりやすくする狙いがあります。「チームに関するproblemを挙げろ」と言われると尻込みしてしまいますが、「言葉にならないもやもやしていること・疑問」という項目であれば書きやすくなるかもしれません。
このようなボードにメンバーそれぞれに話題を記入していただいたのち、特に「話したい！」「聞きたい！」と思うものについてみんなで目印をつけます。ふりかえりの時間ではその話題を重点的に扱うようにしています。
ファシリテーターの声の掛け方の変更
メンバーの書いてくれた話を、チームの話題として扱うための声かけをファシリテーターとして意識して行なっています。例えば、「〇〇をやるのを忘れてしまった」のような個人の話題に近いものでも、起きた事象をチームに還元できないかの観点で問いかけを行っております。
具体的には、責任の追求にならないようには細心の注意を払いながら、「2週間前に戻ったとして、防ぐことはできたか？」「仕組みかできることはないか？」などの質問を通してチーム全体で議論をし、チームの知見にすることはできないかを模索していきます。
そのほかにやったこと
ただ「やり方を変えます！」というような提案は、あまり上手くいきません。そのため、これらのことを進める上で、チームメンバーにはふりかえりの方法を変更する目的と、ふりかえりの目的をあらためて考えたものを丁寧に共有しました。
また、方法を変更してどうだったかをふりかえりの最後の5分ほどでチームメンバーと共に振り返り、ふりかえりをさらに改善するアイデアや、変更したことによるモヤモヤなどを掬い上げることも意識的に行いました。
変更してみて
以上の施策を通して、当初の課題だった「チームの摩擦を低減するような役割をふりかえりの時間にできていない」という問題は改善しつつあります。実際に、それまでの方法では、チームからTryやActionが出ることはありませんでしたが、今では毎回のふりかえりで、チームで試してみたいことなどを出し、それをスプリントを通して定着させていこうという文化ができつつあります。（Try, Actionがたくさん出ることがいいふりかえりの条件であるとは思いませんが、チームがチームの問題に向き合うことができるようになったことの現れではないかとは思っています。）
おわりに
ふりかえりの改善を通して、今まではスプリントの最後にある儀礼的イベントのようになってしまっていたふりかえりの時間を、よりチームの改善に目を向けるための時間にしたお話をしました。
進め方や、採用しているふりかえりボードの形はメンバーの思考を制限します。その制限が目的の方向に進むために集中を促すためのガイドラインとなっている場合はとてもよい仕組みとして作用しますが、そうでない場合はチームの足枷になってしまうと私は思います。
常にチームの状態を観察し、チームにとって良い形式でふりかえりを行うために、これからも課題に向き合いながら改善をしていきたいです！
テックリードとしてやってきた一年間をふりかえる！
クロスマートテック アドベントカレンダー 12/1の記事です！
私は、PM, エンジニア含めて、約メンバーが7名ほどのメンバーの開発チームに所属しています。
そして、今年の初めにテックリードという役割をいただきました。
そこで今回は、いい機会なのでリーダーの役割をいただいたこの1年をふりかえろうと思います。
我々のチームにおけるテックリードの役割と考えられるもの
テックリードとひとえに言いましても、それぞれのチーム・組織によってかなり役割にはばらつきがあるものと思います。我々の組織ではそもそも、明示的にテックリードの役割というものは定義はされていませんが、私は以下のことを自分の役割だと考えて約一年を過ごしてきました。
- 技術的な視点でチームの方針の決定・改善を行う
- PMと協力して機能開発の順序や方針を決める
- 技術的に難しい課題に取り組み、実装を推進する
- チームメンバーの技術的な躓きをサポートする
- 社外の技術イベントの登壇などを通して、弊社のエンジニア組織を対外的にアピールすること
これらの項目は、私一人が担えばよいものではなく、チーム全体にこれらの責務が緩やかに分散しているのが理想的な状態だとは思います。そのうえで、自分は少し前を歩きながら方向づけをするような役割を意識してきました。
（書籍「スタッフエンジニアへの道」でいうところの、テックリード、アーキテクト、ソルバーを足して3で割ったものに、色々足したような感じになっていますね^^;）
実際にできているか
上であげた役割について、一年間でちゃんとできていたかどうかを考えてみます。
技術的な観点でチームの方針の決定を行う
リーダーとして、チームメンバーが機能開発に集中していくために、開発にまつわる問題を取り除いたり、将来的な技術的なリスクを予見して対策を打っていく必要がありました。
具体的には、
- テストコードの方針
- 開発環境の改善
- ソフトウェアアーキテクチャスタイルの方針決定
などでしょうか。
一年を通してさまざまなものに取り組んではきましたが、正直まだまだできていないことがたくさんあります。
私の課題に気づく力も、それを適切に対処していく力も、まだ十分とは言えません。
来年も引き続き、理想的な状況を想像しながらチームをリードしていきたいと思います。
PMと協力して機能開発の順序や方針を決める
技術の専門家として、PMの描く世界を実現する役割があると考えています。
今年は日頃から、提供できる価値と、開発にかかるコスト、運用していくコストのトレードオフを考えながら、何をどのように作るかを考えてきました。
具体的には
などになります。
ただ、ここら辺は、反省点がたくさんある一年でした。
私が気づくのが遅かったが故に、お客様への価値提供を遅めてしまったシーンがありました。
それは、機能追加による複雑さの向上をより意識しながら振る舞うべきだと痛感したエピソードでした。
技術的に難しい課題に取り組み、実装を推進する
これはテックリードの役割というよりも、書籍「スタッフエンジニアへの道」で出てくる「ソルバー」の役割に近いかもしれません。
今年は率先して、特に複雑な機能の開発に取り組んでおりました。
コードの複雑性をあげ過ぎずに、一旦ひと段落がつきそうなところまでもって来れたのはよかったです。
チームメンバーの技術的な躓きをサポートする
最近ジョインしていただいたメンバーが、スムーズに開発に取り掛かれるようにする施策として、定期的な1on1や、相談しやすい雰囲気づくりを意識してきました。
来年も引き続き、御用聞ポジションを強めていくとともに、チームの成長のボトルネックにならないよう、自分も成長していかなくてはなりません、、！
社外の技術イベントの登壇などを通して、弊社のエンジニア組織を対外的にアピールすること
テックリードの役割かと問われると微妙ですが、発表などは自分が相対的に得意な領域なため、力を入れていきたいと思っています。
ただ、まだまだですね。
今年は技術的なお話の登壇を増やした年でしたが、来年はより多くの機会を得られるように頑張りたいです。
（↑今年行った技術的な社外発表の例）
さいごに
私のふりかえりの色が強い記事になってしまいました🙇♂️
同じような立場の方がいれば、「自分のチームにとっての役割は何か？」をあらためて言語化してみるきっかけになればうれしいです。
来年もさらにチームの成長と価値提供のために、粉骨砕身頑張ります！
大吉祥寺.pmに行ってきました！！！セッションに影響を受けて生まれたActionをここに宣言
全てのトークが最高に楽しかったです！
今日のトークを聞いて、Actionを起こそうと思ったことをここに宣言します。
順不同です。
ブログを書く
うすゆきさん（https://x.com/usuyuki26）による
「令和でもブログを自宅サーバーで」
を聞き、ブログに残すことの価値を改めて感じました。
今までも何度もブログを継続するチャレンジを失敗してきた私ですが、今回のお話を聞き、日記→ブログへの編纂作業こそ自分の考えを深く理解して伝えることにつながると感じました。
ちょっとしたら、うちで動かしてるproxmoxにブログサーバーをデプロイしたいな。
自分を見つめ直し、プロポーザルを出す
Asanoさん（https://x.com/mackey0225）による
「プロポーザル駆動学習」より。
自分の経験やスキル、過小評価しがち（自分もそう）ですが、それ自体が認知バイアスだと感じました。
確かに、自分が経験したことと100%同じことを経験している人はいません。もっといえば、やってきたことから得られた学びもそれぞれ異なるはずです。
「ユニークなスキルや経験がない」のではなく、「（必ず存在するはずの）ユニークな経験やスキルを言語化できていない」のだな痛感しました。
技術コミニティを作る
こうのさん（https://x.com/hk_it7）による
「地方でエンジニアコミュニティを成功させる秘訣」より
地方でエンジニアコミュニティを成功させる秘訣 - 大吉祥寺.pm 2025 | ドクセル
ということで、作りました。
ただいま準備中です！
個人開発をする
Sotaro Karasawaさん（https://x.com/sotarok）による
「大『個人開発サービス』時代に僕たちはどう生きるか」より
現代のソフトウェア開発を取り巻く状況を考えると、ソフトウェア企業に手が出しにくいニッチな領域を攻めることで、個人開発者の勝ち目が生まれている話のロジックにとても納得しました。
元々採算度外視、勉強できればいいやスタンスの個人開発をよく行なっていたので、真剣に考えてみようと思いました。
余談ですが、ウナギトラベルというぬいぐるみ旅行代行サービスを思いましました。
マイクを叩かない
Arthurさん（https://x.com/Arthur1__）
「【実演版】カンファレンス登壇者・スタッフにこそ知ってほしいマイクの使い方」より
ごめんなさい。もうマイクを叩きません！！
自分の提案が質問になっていないかを意識する
なってぃさん（https://x.com/natty_natty254）
「提案レベルを上げてみたら、私の『提案』が『進捗』になっていた件」より
思い返すと、「〇〇という選択肢もありますよね」「〇〇だと厳しいんじゃないでしょうか」の発言よくしていたなぁと反省。
「これは、提案じゃなくて質問してないか」を常に考えながら仕事したいと思いました。
自分がリーダーを任せてもらったという自覚を持つ
アナホレナイフクロウさん（https://x.com/stupid_owl）
「機能追加とリーダー業務との類似性」より
最近自分がちゃんとリーダーとしてワークできているか、不安に思っていました。
正直、自分は不安に思いながら、できていないことに少し目を瞑ってしまっていたと思います。
しかし、「上長がリーダーになれる能力があると思ったから」という言葉にハッとしました。
リーダーを任せてもいいと思ってもらえたこと、それは事実です。
自分に期待されていること、自分ができることを見直し、行動を改めようと思いました。
emconf 2025に参加しました！（EMってなんだろう。が少しだけわかった気がした1日）
emconf 2025に参加しました
とても楽しかったです！参加して良かった。。
何が楽しかったのか、何が勉強になったのか、書き起こしていきたいと思います！💪
参加のモチベーション
最近私は、会社からテックリードの肩書をいただきました。
会社で
— ヲクラ (@3l4I5) 2025年2月25日
「テックリード」
という肩書をもらった！
技術力が10アップした
これまで肩書きが付くような立場に就いたことがなかったため、非常に身が引き締まる思いです。
今までよりも、責任が大きくなった役職になったものの、テックリードの責務や役割については、まだ明確に定義できていない状態でした。
emconfに参加することで、テックリードとして求められる行動のヒントが得られるのではないかということを期待して、今回参加しました。
気づき
EM経験などがない私では、ちゃんと噛み砕くことができずに耳から通り抜けてしまったことがあったと思います（惜しい気持ち）。
その中でも、（僭越ながら）私が十分に言語化できるほど理解できた（と思っている）「EMの大切な役割」について、一旦書き起こそうと思います。
1. エンジニアリングの専門家としてプロダクトの向かうべき方向を考える
PdMが持ちにくいエンジニア視点で、何を作るべきかを意見する。
何を作るべきか、何を作らないべきかなど、エンジニアリングの専門家として組織に提言することが大切な責務だと感じました。
その上で、プロダクトやビジネスについても詳しくなる必要があると感じました。
広木さんの発表（エンジニアリングマネージャーのロードマップ）や、
こにふぁーさん（サバイバルモード下でのエンジニアリングマネジメント）の発表でプロダクトにどのように深く関与すべきかという話がされていたことが印象に残っています
2. 理想を掲げ、それに近づけていく
組織全体の全体最適に向けた理想像を作り、その理想像に向かって具体的な行動を実施することが、EMの大きな役割の一つであると考えました
それがどれだけ正しいとされていることだとしても、組織に根付いている習慣を別の形に変えていくことはとても困難です（私自身、身近な領域でもその難しさを実感しています）。組織の歴史や外的要因などが複雑に絡み合い、結果として現れていることを一朝一夕で変えていくのは、不安定な積み木にさらに積み木を重ねていくような活動だと思います。 その現状を打破して、非連続な変化を起こすのには、痛みを伴うことも多いはずです。
そう考えた時に、「正しい姿を描く力」と「組織を変容させる力」の両方が、EMには大切だと感じました。
岩瀬さんの発表（n=1の経験が紡ぐエンジニアリングマネジメントの可能性 特にP.30）や
Shindenさんの発表（エンジニアリングマネージャーの仕事がレベルアップした3つの視点 P.61周辺）
のお話がここの部分に関連して記憶に残っています。
3. 組織の課題の気づき力・対処力
「理想を掲げ、それに近づけていくこと」と類似した概念だと思いますが、組織の問題・課題への嗅覚の鋭さが大切だと思いました。 多くのEMの方のお話を聞き、それぞれの方が課題として挙げていることが自分の組織に起きていたとして、それを問題だと自分は認識できるのかどうか自信がありませんでした。 そういうものだろう、と自分だったら思ってしまうところを、先々で大きな問題になる可能性が高いものとして対処している方々を見て、鋭い嗅覚に似たイメージを持ちました。
嗅覚を鍛えないといけない・・・！
piroさんの発表（マネージャー全員でマネジメントポリシーを作りました）を聞いている中でそのようなことを考えていたことを記憶しています。
まとめ
他にもEMにとって大切なエッセンスはたくさんあると思います（ちゃんと本を読まないと！）。しかし経験の乏しい自分が、言語化できるほど理解することができたのはあまり多くありませんでした。
また来年、自分の経験が増えて参加した時に、より多くのことを感じ取れるようになっていることを目標にして１年間やっていこうと思いました・・・！
emconfで聞いた話や得た知識を足がかりにして、今後自分がマネジメント業に関わることになった時には、意識しながら行動していきたいです！
そしてEMから逆算したテックリード像をもう少し具体化させるぞ！💪
emconf 2025に参加しました！（EMってなんだろう。が少しだけわかった気がした1日）
emconf 2025に参加しました
とても楽しかったです！参加して良かった。。
何が楽しかったのか、何が勉強になったのか、書き起こしていきたいと思います！💪
参加のモチベーション
最近私は、会社からテックリードの肩書をいただきました。
会社で
— ヲクラ (@3l4I5) 2025年2月25日
「テックリード」
という肩書をもらった！
技術力が10アップした
これまで肩書きが付くような立場に就いたことがなかったため、非常に身が引き締まる思いです。
今までよりも、責任が大きくなった役職になったものの、テックリードの責務や役割については、まだ明確に定義できていない状態でした。
emconfに参加することで、テックリードとして求められる行動のヒントが得られるのではないかということを期待して、今回参加しました。
気づき：EMに求められることとは？
EM経験などがない私では、ちゃんと噛み砕くことができずに耳から通り抜けてしまったことがあったと思います（惜しい気持ち）。
その中でも、僭越ながら私が十分に言語化できるほど理解できたと感じている「EMの大切な役割」について、書き起こそうと思います。
エンジニアリングの専門家としてプロダクトの向かうべき方向を考える
PdMが持ちにくいエンジニア視点で、何を作るべきかを意見する。
何を作るべきか、何を作らないべきかなど、エンジニアリングの専門家として組織に提言することが大切な責務だと感じました。
その上で、プロダクトやビジネスについても詳しくなる必要があると感じました。
広木さんの発表（エンジニアリングマネージャーのロードマップ）や、
こにふぁーさん（サバイバルモード下でのエンジニアリングマネジメント）の発表でプロダクトにどのように深く関与すべきかという話がされていたことが印象に残っています
理想を掲げ、それに近づけていくこと
組織全体の全体最適に向けた理想像を作り、その理想像に向かって具体的な行動を実施することが、EMの大きな役割の一つであると考えました
それがどれだけ正しいとされていることだとしても、組織に根付いている習慣を別の形に変えていくことはとても困難です（私自身、身近な領域でもその難しさを実感しています）。組織の歴史や外的要因などが複雑に絡み合い、結果として現れていることを一朝一夕で変えていくのは、不安定な積み木にさらに積み木を重ねていくような活動だと思います。 その現状を打破して、非連続な変化を起こすのには、痛みを伴うことも多いはずです。
そう考えた時に、「正しい姿を描く力」と「組織を変容させる力」の両方が、EMには大切だと感じました。
岩瀬さんの発表（n=1の経験が紡ぐエンジニアリングマネジメントの可能性 特にP.30）や
Shindenさんの発表（エンジニアリングマネージャーの仕事がレベルアップした3つの視点 P.61周辺）
のお話がここの部分に関連して記憶に残っています。
「明らかに課題」となる前の課題の気づき力・対処力
「理想を掲げ、それに近づけていくこと」と類似した概念だと思いますが、組織の問題・課題への嗅覚が鋭さが大切だと感じました。 多くのEMの方のお話を聞き、それぞれの方が課題として挙げていることが自分の組織に起きていたとして、それを問題だと自分は認識できるのかどうか自信がありませんでした。 そういうものだろう、と自分だったら思ってしまうところを、先々で大きな問題になる可能性が高いものとして対処している方々を見て、鋭い嗅覚に似たイメージを持ちました。
嗅覚を鍛えないといけない・・・！
piroさんの発表（マネージャー全員でマネジメントポリシーを作りました）を聞いている中でそのようなことを考えていたことを記憶しています。
まとめ
他にもEMにとって大切なエッセンスはたくさんあると思います（ちゃんと本を読まないと！）。しかし経験の乏しい自分が、言語化できるほど理解することができたのはあまり多くありませんでした。
また来年、自分の経験が増えて参加した時に、より多くのことを感じ取れるようになっていることを目標にして１年間やっていこうと思いました・・・！
emconfで聞いた話や得た知識を足がかりにして、今後自分がマネジメント業に関わることになった時には、意識しながら行動していきたいです！
そしてEMから逆算したテックリード像をもう少し具体化させるぞ！💪
