こちらは<a href="https://qiita.com/advent-calendar/2024/em" target="_blank" rel="nofollow noopener noreferrer">Engineering Manager Advent Calendar 2024</a>の10日目の記事にです 
昨日はもつおさんの <a href="https://note.com/eno_motty/n/n8cb0b1d42497" target="_blank" rel="nofollow noopener noreferrer">中途入社エンジニアへの毎日1on1のススメ</a>でした。 
今年入社した人だったので、「これくらいやっても良かったのかなぁ」と自分の一年を振り返りながら読ませてもらいました。
マナリンクでEMをやっている<a href="https://x.com/kondo_script/" target="_blank" rel="nofollow noopener noreferrer">@kondo_script</a>です。
今年の4月にEMとして入社して、入社エントリみたいな記事を書いてからかれこれ半年強が経ちました。 
<iframe id="zenn-embedded__9a857e5edb2e8" src="https://embed.zenn.studio/card#zenn-embedded__9a857e5edb2e8" data-content="https%3A%2F%2Fzenn.dev%2Fmanalink_dev%2Farticles%2F902eff3aa3e36d" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://zenn.dev/manalink_dev/articles/902eff3aa3e36d" style="display:none" target="_blank">https://zenn.dev/manalink_dev/articles/902eff3aa3e36d</a> 
ちょうどいいタイミングなので、今年一年EMとしてやったことを振り返りながら、今年の学びだった「正しい失敗について」の話をしようと思います。
<h2 id="%E8%87%AA%E5%B7%B1%E7%B4%B9%E4%BB%8B%E3%82%82%E5%85%BC%E3%81%AD%E3%81%A6%E9%9B%91%E3%81%AB1%E5%B9%B4%E3%82%92%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8B" data-line="10" class="code-line">
<a class="header-anchor-link" href="#%E8%87%AA%E5%B7%B1%E7%B4%B9%E4%BB%8B%E3%82%82%E5%85%BC%E3%81%AD%E3%81%A6%E9%9B%91%E3%81%AB1%E5%B9%B4%E3%82%92%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8B" aria-hidden="true"></a> 自己紹介も兼ねて雑に1年を振り返る</h2>
<ul data-line="12" class="code-line">
<li data-line="12" class="code-line">4 月にマナリンクの開発にジョイン
<ul data-line="13" class="code-line">
<li data-line="13" class="code-line">メンバーは私と CTO を含めて5人
<ul data-line="14" class="code-line">
<li data-line="14" class="code-line">全員フルスタック</li>
<li data-line="15" class="code-line">新卒3年目のメンバーが二人いる</li>
</ul>
</li>
<li data-line="16" class="code-line">開発メンバーが全員出社している
<ul data-line="17" class="code-line">
<li data-line="17" class="code-line">ドメイン/技術問わず「わからんかったらすぐ聞く」が出来る環境</li>
<li data-line="18" class="code-line">割とみんな仕事好きでテンション高い。ちょっとうるさい(なかよし)。</li>
</ul>
</li>
<li data-line="19" class="code-line">なぜか入社3ヶ月でCTOとデブサミに登壇することになった</li>
</ul>
</li>
<li data-line="20" class="code-line">フルスタックエンジニア(Next.js/Expo/Laravel)として中〜大規模(当社比)くらいの案件を3つ実装した
<ul data-line="21" class="code-line">
<li data-line="21" class="code-line">プレイング比率高めのプレイングマネージャです</li>
<li data-line="22" class="code-line">PHPとRDBを真面目に触った経験がほとんどなく、結構手探りだった(なんとかなった)</li>
</ul>
</li>
<li data-line="23" class="code-line">リードエンジニアとしてチームメンバーへのFBやコードレビューをやった
<ul data-line="24" class="code-line">
<li data-line="24" class="code-line">Next.js/PHP/SQLの筋力がメンバーの方がある状態だった</li>
<li data-line="25" class="code-line">地味に正式なフィードバックするポジションが初めてだった</li>
</ul>
</li>
<li data-line="26" class="code-line">CTOとの責任分離に悩むなどした
<ul data-line="27" class="code-line">
<li data-line="27" class="code-line">そもそも「立ち上げをやったCTOのいるチーム」で仕事するのが初めてだった</li>
</ul>
</li>
<li data-line="28" class="code-line">EMの役職をもらっての入社だったので、意識的にチームメンバーに影響を与える施策を打った
<ul data-line="29" class="code-line">
<li data-line="29" class="code-line">いろいろやった
<ul data-line="30" class="code-line">
<li data-line="30" class="code-line">ダンボールでカンバン作ってみたり</li>
<li data-line="31" class="code-line">朝会始めてみたり</li>
<li data-line="32" class="code-line">エンジニア定例を始めてみたり</li>
<li data-line="33" class="code-line">Design Doc 作ってみたがあまりうまくワークしなかったり</li>
<li data-line="34" class="code-line">ワーキングアグリーメント作ってみたり</li>
<li data-line="35" class="code-line">インセプションデッキを作ろうとしてやめたり</li>
<li data-line="36" class="code-line">星取表作りをやろうとしてやめたり</li>
<li data-line="37" class="code-line">チームや個人の目標設計してみたり</li>
<li data-line="38" class="code-line">1on1 を習慣的に始めてみたり</li>
</ul>
</li>
<li data-line="39" class="code-line">組織が過渡期だったこともあり、そこそこ定着する習慣を作れた
<ul data-line="40" class="code-line">
<li data-line="40" class="code-line">が、もちろん上手くいかなかった施策もそこそこあった</li>
</ul>
</li>
</ul>
</li>
</ul>
プレイヤーとして、施策単位での振り返りはちょくちょく会社でやっているのですが、マネージャとしての振り返りはこの記事が初めてでした。 
すごく濃い半年強でしたが、この中からいくつか抜粋して話をしてみようと思います。
##　「メンバーの仕事を見る」ことに初チャレンジした 
「1~2名くらいのメンバーの仕事の進捗に責任を持つ」という役割をやっていました。
<ul data-line="48" class="code-line">
<li data-line="48" class="code-line">ワークマネジメントするのが初めて</li>
<li data-line="49" class="code-line">Next.js/PHPを実務レベルで使うのが初めて</li>
<li data-line="50" class="code-line">役割をもってコードレビュー/フィードバックをするのが初めて</li>
<li data-line="51" class="code-line">そもそもこの組織でコードを書く/仕事をするのが初めて</li>
</ul>
と、いろいろ初めてづくしな中でのチャレンジでした。 
当然「最初からできた」とは到底言えない状態(今も自信を持ってできていると言えるかはわからん)でしたが、4、5月の自分に比べると随分回せるようになったと思います。
得た学びとしては
<ul data-line="57" class="code-line">
<li data-line="57" class="code-line">マネージャが迷うとメンバーはその2,3倍迷うこと</li>
<li data-line="58" class="code-line">自分が強くない領域について、メンバーに技術の質問をしてしまう度胸</li>
<li data-line="59" class="code-line">メンバーの特性やフェーズによって任せられる領域が大きく変わること</li>
</ul>
あたりでしょうか。 
特に3つ目は「権限の移譲段階」みたいな話を事前にインストールしていたにもかかわらず、 
「任せ過ぎだった」「任せなさすぎだった」みたいな現象を何度か踏んでおり、理論だけ知っていてもうまくいかんものだなと痛感しました。 
マネージャを続けている限り悩み続けるポイントなのかもしれません。
<h2 id="%E3%83%81%E3%83%BC%E3%83%A0%E3%83%93%E3%83%AB%E3%83%89%E3%81%AF%E3%82%84%E3%82%89%E3%81%AA%E3%81%8F%E3%81%A6%E3%82%88%E3%81%8B%E3%81%A3%E3%81%9F" data-line="67" class="code-line">
<a class="header-anchor-link" href="#%E3%83%81%E3%83%BC%E3%83%A0%E3%83%93%E3%83%AB%E3%83%89%E3%81%AF%E3%82%84%E3%82%89%E3%81%AA%E3%81%8F%E3%81%A6%E3%82%88%E3%81%8B%E3%81%A3%E3%81%9F" aria-hidden="true"></a> チームビルドはやらなくてよかった</h2>
前職/前前職でうまくワークしていたチームビルド施策<a href="https://get.wevox.io/valuescard" target="_blank" rel="nofollow noopener noreferrer">バリューズカード</a>などの実施を検討しましたが、 
結果としてやらないことにしました。
マナリンクの開発組織の特性として
<ul data-line="74" class="code-line">
<li data-line="74" class="code-line">チームメンバー同士の距離感が(出社なので物理的にも)近い</li>
<li data-line="75" class="code-line">コアプロダクトの立ち上げをやったCTOがチームに居るので、開発組織のカルチャーがハッキリしている</li>
<li data-line="76" class="code-line">メンバーが雑談好き</li>
</ul>
みたいなものがあり、ようするに「わざわざチームビルド施策をやらなくても相互理解できてる」という状態でした。 
チームとして未知の人員は私だけだったため、日々の雑談で自分語り多めのオジサンになるだけでそのあたりのギャップは埋められたかな〜と思っています。 
これから新しいメンバーが増えた際はこの限りではないと思うので、そうなったら改めて考えようかと思っています。
<h2 id="%E6%9C%9D%E4%BC%9A%E3%82%92%E5%A7%8B%E3%82%81%E3%81%A6%E8%82%B2%E3%81%A6%E3%81%9F" data-line="83" class="code-line">
<a class="header-anchor-link" href="#%E6%9C%9D%E4%BC%9A%E3%82%92%E5%A7%8B%E3%82%81%E3%81%A6%E8%82%B2%E3%81%A6%E3%81%9F" aria-hidden="true"></a> 朝会を始めて育てた</h2>
入社直後はいろいろなタイミングが重なり、所属するチームで朝会が開催されていなかったため、ふんわりと朝会をはじめてみました。
タスクの進捗管理には、入社前から<a href="https://linear.app/" target="_blank" rel="nofollow noopener noreferrer">Linear</a>というタスク管理ツールが導入されていましたが、 
利用状況がまちまちだったり、既存の運用があったりと、「朝会でスムーズに自分のタスクの話ができる」状態にはなっていませんでした。 
そのため一度ダンボールでカンバンを作成し、「現在の仕事の流れ」を簡単に見えるようにしてみました。 
<iframe id="zenn-embedded__42f163eac12a6" src="https://embed.zenn.studio/tweet#zenn-embedded__42f163eac12a6" data-content="https%3A%2F%2Fx.com%2Fkondo_script%2Fstatus%2F1780432806315012498" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://x.com/kondo_script/status/1780432806315012498" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://x.com/kondo_script/status/1780432806315012498</a>
カンバンを段ボールで作る というのはなかなかよい体験だったと思います。
<ul data-line="93" class="code-line">
<li data-line="93" class="code-line">いつか捨てるツールであることがわかりやすい</li>
<li data-line="94" class="code-line">わざわざ購入しなくて良い</li>
<li data-line="95" class="code-line">「なんか作って試してる感」がでる。チームが仕事の回し方を考えるきっかけになる</li>
<li data-line="96" class="code-line">ホワイトボードと違ってレーンを直せない/付箋が絶妙に剥がれるので「ずっとこのままなのは嫌だな」となる
<ul data-line="97" class="code-line">
<li data-line="97" class="code-line">
<a href="https://fuben-eki.jp/whatsfuben-eki/" target="_blank" rel="nofollow noopener noreferrer">不便益</a>というやつですね</li>
</ul>
</li>
</ul>
運用して3~4か月くらい経ったあと、「そろそろlinearで朝会ができるな」となったタイミングで、段ボールカンバンは廃棄しました。 
その間、メンバー構成が変わったり、開催場所が執務室→会議室→執務室でスタンディングと変化したり、開催時間を調整したり、いろいろな変化がありました。 
自分たちにあったやり方をうまく見つけられたんじゃないかと思っています。
ちなみに現在、linearの運用ルールでは整理できない課題が見つかって、段ボールカンバンの第2弾を実施中です。 
そのうち捨てられるようにしたいですね。
<h2 id="%E8%A8%80%E8%AA%9E%E5%8C%96%E3%82%84%E4%BB%95%E7%B5%84%E3%81%BF%E5%8C%96%E3%82%92%E3%81%A1%E3%82%87%E3%81%A3%E3%81%A8%E3%81%9A%E3%81%A4%E9%80%B2%E3%82%81%E3%81%9F" data-line="106" class="code-line">
<a class="header-anchor-link" href="#%E8%A8%80%E8%AA%9E%E5%8C%96%E3%82%84%E4%BB%95%E7%B5%84%E3%81%BF%E5%8C%96%E3%82%92%E3%81%A1%E3%82%87%E3%81%A3%E3%81%A8%E3%81%9A%E3%81%A4%E9%80%B2%E3%82%81%E3%81%9F" aria-hidden="true"></a> 言語化や仕組み化をちょっとずつ進めた</h2>
私自身のドメインやカルチャー理解の一環も兼ねて、社内の暗黙知を言語化する施策を打ってみました。 
「ワーキングアグリーメント」「評価に関係しない個人のプチ目標」「大臣制度」など、ある程度うまく行った施策もありました。(このあたりはそのうち別途記事にします) 
しかし、「開発チームの中期目標」「インセプションデッキ」「星取表」「design docの導入」など、途中でやめた、うまくいかなかった施策も同じくらいありました。
メンバーが全員出社 + アーリーベンチャー + 教育系のクセのあるtoCビジネスというマナリンクの環境では、 
あえて言語化する必要がないことやうまく言語化できていないが意味があること が結構あったというのがその原因だったと考えています。
言語というのは結局どこまで行っても現実の模型なので、頼りすぎないように、しかし疎かにしないようにのスタンスで使うのがよいのだろうなと。 
結構個人的に大きな学びだったと思います。
<img src="https://res.cloudinary.com/zenn/image/fetch/s--ev2tWeDl--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_1200/https://storage.googleapis.com/zenn-user-upload/deployed-images/31414df385f62c3673256044.png%3Fsha%3Dce8d542dc6fa64ba760ec88816a317078e303ea2" width="300" loading="lazy" class="md-img"> 
ワーキングアグリーメントにもこんなふうに書かれています
<h2 id="%E3%81%BE%E3%81%A8%E3%82%81%E3%81%AB%E3%81%8B%E3%81%88%E3%81%A6-%2F-%E6%AD%A3%E3%81%97%E3%81%84%E5%A4%B1%E6%95%97%E3%81%AE%E3%82%84%E3%82%8A%E3%81%8B%E3%81%9F%E3%82%92%E7%9F%A5%E3%82%8C%E3%81%9F" data-line="122" class="code-line">
<a class="header-anchor-link" href="#%E3%81%BE%E3%81%A8%E3%82%81%E3%81%AB%E3%81%8B%E3%81%88%E3%81%A6-%2F-%E6%AD%A3%E3%81%97%E3%81%84%E5%A4%B1%E6%95%97%E3%81%AE%E3%82%84%E3%82%8A%E3%81%8B%E3%81%9F%E3%82%92%E7%9F%A5%E3%82%8C%E3%81%9F" aria-hidden="true"></a> まとめにかえて / 正しい失敗のやりかたを知れた</h2>
今年の一番の学びは「失敗に対するスタンス」だったと思います。
今も昔もこれからも、クイックアンドダーティーという言葉は大切にしていきたいのですが、それと同じくらい 
絶対に成功させるつもりで計画することが大切だなぁと痛感しました。 
うまくいかせる気がない施策は時間を無駄にするだけでなく、組織にXXはウチの組織には合わなかったという呪いをかけることにもなりかねません。
もちろん、やり切った上で失敗するなら、それはもう胸を張るべきことだと思います。 
それでも上手くいかなかったらすぐ切り替えるのが大事だなと。
例えばdesign docの導入失敗については完全に私の段取り不足でした。 
ここでいう話でもないのですが、どこかでリベンジしようと思っています。こういう呪いって、失敗した本人が解呪しないとどうにもならなくなりがちなので。。。
<h2 id="%E3%81%8A%E3%82%8F%E3%82%8A%E3%81%AB" data-line="136" class="code-line">
<a class="header-anchor-link" href="#%E3%81%8A%E3%82%8F%E3%82%8A%E3%81%AB" aria-hidden="true"></a> おわりに</h2>
この記事を書くまでは「あんましマネージャらしいことできてないな」と無意味にソワソワしていましたが、書いてみると思ったより手を打っていました。 
機会がないとなかなかここまで形にしないので、こういった場があるというのは本当にありがたいことですね。 
とはいえ、来年はもうちょっと細かくアウトプットする年にしようかと思っています。(勉強会とかで登壇もしたいな) 
なににつけてもまだまだ先は長いですが、懲りずにいろいろバタバタしていこうと思います。では。

EM1年目の振り返り、あるいは「正しい失敗」のやり方について

自己紹介も兼ねて雑に1年を振り返る

チームビルドはやらなくてよかった

言語化や仕組み化をちょっとずつ進めた

まとめにかえて / 正しい失敗のやりかたを知れた

朝会

Discussion