エンジニアチームのマネージャー1年目のふりかえり

わたしは2018年度4月からエンジニアチームのマネージャーになりました。マネジメント処女が体当たりで過ごした日々は早くも四季のうちの三つを過ぎ、「初心者マーク」を堂々とつけられないマネジメント歴二年目が迫っており、経験を十分に血肉に変えられたのだろうか…と少し不安になっています。プロジェクトと違い仕事の区切りがなく、自身のマネジメントをふりかえる機会が用意できていないなーと感じたため、思い出しつつまとめてみようと思います。

経緯; マネージャーになった理由

  • エンジニア(+デザイナー)の人数が増えチームになったためチームマネジメントが必要になった
  • 面倒見の良さげなお節介な性質⇨適正ありそう!いけ!やってみよう!
  • 「強いチーム」で仕事がしたい&「強いチーム」がつくりたいという気持ちがあった

チーム構成はフルコミットのエンジニア4人、3/5稼働の業務委託エンジニア2人、デザイナー1人、プロダクトマネージャーの私(プロジェクトに応じた業務委託メンバーはまた別)でそのうち2名は本年度働きはじめた新卒入社のメンバーという状態で、それまでの私ともう一人の二人での開発と比べ大きく環境が変わりました。わたしの感覚ですが“3”を超えたら、組織は分類が可能な状態になるため、1つの方向に向かい目的に集中するための仕組みが必要だと思います。そのため、メンバーと自分自身が存分に力を発揮できるためのマネージャーの役割を担うことにしました。経緯としては以上ですが、自分が面倒見がよくお節介というのは「???」という感じで、どちらかと言わなくても群を抜いてだらしがなくいい加減で人見知りなタイプなのですが、なぜそんな風に人目にうつるのか不思議です。仕事中の私は別人格なのでしょうか。まあ、いっか。

やったこと

  • 1on1
  • メンバーの目標設定支援と評価
  • チームの目標達成のための課題整理と伝達

細かく整理するべきなのですが、個々のその時の状況/状態とチームの状態をすり合わせ再度整理するという日々だったため、その時々の取り組みは事象に合わせて別でまとめたほうがよさそうだと感じました。

わかったこと

  • 1on1でメンバーが議題にあげてくれたことやフランクに話してくれたことはマネジメントのバックログになる
  • マネジメントの活動の評価軸をなににしたらいいかわかっておらず、ふりかえりがまとまらない(今)

やってきたことの中で外してはいけないことは1on1だと感じています。これはこれからも続けたいです。

議題、頻度はメンバーの希望に応じて週に1回から月に1回程度で設定してもらっていました。 話すことがなければ早く終わることもあったり、タスクが忙しいときはスキップすることもありますが、なるべく個別で話をする時間を定期でとるようにしていました。1on1で話してくれた課題や希望を私のマネジメントのバックログにし、次の1on1までに解決できるようなサイクルをまわすアクションにしていました。

今思えば、個々のメンバーとの1on1が私のマネジメントのふりかえり、計画の役割を果たしていたように思います。

ここまでふりかえって考えてみて改めてマネジメントのふりかえりが非常に難解だと感じました。なにで活動を評価したらいいのかがわからなくなってきました。

次やること;まとめ

  • マネジメントでの活動の評価をどう行うかを考える
  • 1on1の効果を再整理する

バシっとまとめたいと思ったのですが、なにを軸に活動を評価すべきなのかの思考の迷子になってしまいました。チームの目標達成のためにどんなマネジメントが必要なのかということは目的とは別に目標、目指す状態を明確にする必要がありそうです。今日は一旦この今の状態がわかっただけでもよしとしたい。

来たる2019年度もまだまだ初心者であり続けそうなニオイがプンプンしていますが、「やってみよう!」からはじめたマネジメント、次年度はもっとステージアップする取り組みがしたいと思いました。

「eureka×Nulab スクラム開発の現場」でオズビジョンの開発チームの取り組みをお話させてもらいました

1月12日(金)に開催されたeureka×Nulab スクラム開発の現場オズビジョンの開発チームの取り組みのお話をさせていただきました。 20分の持ち枠で「マネージャー不在のチームでのペアスクラムマスターの取り組み_初心者のふりかえり運営」というテーマで同僚の橋本さんとお話させていただきました。 speakerdeck.com

発表内容の概要

チームをリードする存在をおかず、みんなで自身をマネジメントしていこうと決めた約3年前の私たち開発チームは様々な取り込みをしてきましたが、そのチームのスクラムマスターとして一番力を入れ、苦労し、そして改善のためにはなくてはならなかったのがふりかえりでした。 そのふりかえりの運用事例をその当時の課題と私たちが行った解決策とともに振り返り、ペアで活動してきたことで学んだことをまとめました。

今は16名体制のチームではなく、もうすこし少ない人数で機能ごとに分けたチームで活動していますが、この頃行っていたふりかえり文化は各チームに引き継がれ、また開発チームが関わらないところでも全社的にふりかえりが行われています。

細かくいうともっといろんな工夫や取り組みを行い、その中には効果が出たものも出なかったものもたくさんあります。 このあたりは興味がある人がいれば、お話したいです。

発表してみて感想

今までLTしか経験がなかったのでとても緊張したのですが、テーマ然りペアで挑んだためなんとか発表できました。(ペア最強。橋本くんありがとう。)

また、今まで自分たちの活動の中でなにか発信できることなんかあるのかな…というのが、ずっと心の中にあって「アウトプット大事」っていうのは頭ではわかっているけど、どちらかというと面倒で避けたいという気持ちが強かったです。でも、Twitterとかで「参考になった」とか「早速現場で取り入れてみよう」みたいな感想をいただいているのをみて、純粋にすごく嬉しくて、「みんなで取り組んできたことが他の現場での参考にしてもらえるかもしれないってすごいことだなー」と思いました。

あと完全に主観なのですが、エンジニアの集まるイベントはTwitterハッシュタグつけて感想言ってくれたり、いいと思ったらFacebookで投稿してくれたりというのが盛んで、聞いてる人の反応がわかるし、あたたかいし、フィードバックになるし、すごく好きだなあと思います。 わたしも伝えていこうと思いました。

今回はほんのすこし昔の取り組みのお話をしたので、次は今やっていることのお話ができればな…と思います。

最後に

機会をくださったエウレカさん、イベントスポンサーのヌーラボさん、当日聴いてくださった方々、ありがとうございました。 また機会があればよろしくお願いしますです。