2022年のふりかえり
一年のふりかえりだけは残しておこうと思い、一週間前くらいから過去の記憶や記録を漁って記載しています。
1月：マネージャーに俺はなる！
マネージャーという役職に就きました。 上司（直属ではなくその上の層）から「一緒に組織を良くしてほしい」と言ってもらえたのが、自分の向かいたいキャリアパスにあったため、割と二つ返事で「やります」と回答しましたし、「向いてなかったり、悩んだらその時に考えます」と伝えもしました。
ちょうどこの時には「チームトポロジー」を読んで、勉強会に参加したり。
チームとマネージャーのインタラクションはどうしようかなと考えていました。
2月～4月：最悪の中の最善を希求したい
🔥案件にアサインされ、障害対応チームのマネジメントを任されました。前から噂には聞いていたので、色々とやるせない気持ちになっていました。
中に入ってみると組織の成功循環モデルでいうところの悪循環にガッツリはまり込んでいて、メンバーのモチベーションはダダ下がり。顧客本陣の近くにいるテストチーム・マネジメントチームと障害対応チームのコミュニケーションを整理していくところから取り掛かりました。
- ダイレクトチャット禁止。
- 電話で直接指示するの禁止。
- タスクは一元管理して全部みえる化すること。
- オープンなチャネルで随時情報共有すること。
- チームにタスクを投入すること
実際には最後の取り組みはうまくいかなかったです。個人への依存が激しすぎて好転するのに時間がかかりすぎるため目をつむってしまいました。あまりの酷さに感情的になってしまって、マネジメントチームメンバーに強い言葉を使ったところは反省です。
1ヶ月経過した頃に最初にやった取り組みがやっと浸透して効果が現れてきた印象。ただ、正攻法にこだわって時間がかかってしまったかも、もっと上手く情報を共有する仕組みは作れたかも、と心残りはあります。とにかく情報を整理して、割り振って、フォローして、問題を見つけては解決して、できない時にはエスカレーションしての繰り返しでした。
状況が好転するかしないかという道半ばでまた別の案件にアサインされることに。実際にはかなりしんどい状況だったので助かったという気持ちのほうが強かったです。
5月～7月：後悔はないですよ 反省は死ぬほどあるけど
新規案件の要件定義を担当することに。プロジェクトリーダー1人のところに自分ともう1人がエンジニア枠で参加しました。あれ、マネージャーの役割はどこいった？感が否めませんが、マネージャーは隙間を埋めることも役割ということですかね。
業務フローは整理済みということであったのですが、曖昧なところが散見されるので業務部門の方にヒアリング。画面モックアップと業務フローとを合わせてユースケースを明確にしていきました。RDRAの考えに基づいてユーザとシステムの境界を明確にすると日々新しい発見があり楽しい。感謝もされるとなお嬉しい。
業務フローとシステムの境界を整理し、ユーザーヒアリングでユースケースを特定していたら不要な業務が見つかって「何でこれやってたんだっけ？」「これやらなくて問題ないね」となって感謝された。
— m-ono (@msts_0w0) 2022年6月7日
こーゆーのがあるから要件定義は面白い。
7月頃からアーキテクチャ検討を担当。ある程度制約があって、フロントエンドが Vue.js＋TypeScript で、バックエンドが Spring。バッチ系はSpring Batch。
フロントエンド周りは初めてのことが多くてめっちゃ学びが多かったです。アトミックデザインも参考にして学習コストも考えて構造を決める。Vue2とVue3で色々変わってきているのにやっぱり2の方の情報が多くて困りました。状態管理周りは特にわからなくて後続のメンバーへ宿題に。
バックエンドは、三層＋ドメイン層にしてロジックを分離しました。この辺は今までの経験からスムーズにできたけど慣れてないメンバーに教えるところに時間がかかってしまいました。まだまだ手の内化できていないので改善したいです。
チーム全体で改善したいのは、APIを中心とした開発知識の浸透と効率化。画面機能として一体に考えすぎず、フロントエンドはAPIの制御やデータ状態管理、バックエンドはAPIインターフェース定義と分離して進めた方が良かった気がしています。このあたりもチームによって習熟度が異なったり、案件によって異なったりするので、ナレッジマネジメントによってうまくノウハウを伝えていきたい。
最近読んだこの記事が素晴らしかったので、年末年始に読み込んで活かしていきたいと思います。
8月～9月：大事なことは知るだけではダメなんだ… 時間をかけ魂に刻み込まねば…
要件定義した案件も軌道に乗ってきたので設計レビューしたりしながらチームに任せて徐々にフェードアウト。その他にはITサービスマネジメント・ITILを勉強したり、顧客向け提案書作成したり。「チームで作り込む」タスクから「答えがないものに対して個人で挑む」タスクに切り替わったため、しばらくはパフォーマンスが上がらず苦戦しました。
たたき台を上司に提示して見てもらってからはスムーズなったので、早くたたき台を作ることを意識しておきたいです。しかし、あれだけメンバーには「早目にたたき台を見せてね」と伝えておきながら、いざ自分のこととなるとうまくできないのは何ででしょう。。。
10月～12月：マネージャーになりたいなら、頭 作り替えろ
10月から本格的にラインマネジメント業務をやっていくために、「エンジニアリングマネージャーのしごと」を読みました。
メンバーには1on1を実施することを伝えて、予定を組みました。各案件の都合もあるのでどちらかというと若手メンバーから実施することになり、最終的にリーダーメンバーについては実施した人・できなかった人がはっきり分かれてしまいました。やはり、年上の部下になるメンバーにはどうしても気後れしてしまう傾向がありそうです。また、周りからも難しい人というイメージがある人も同じ傾向があるので、今年度中に解決に向けて動きたいです。
一番効果を実感できたのが「2章 まず自分を管理しよう」でした。「カレンダー」「ToDoリスト」「メール受信箱」「情報を記録する場所」の4つのツールを活用したところ、頭の中にとどめる情報が最小化され、毎日を規律に従って迷いなく動けるようになってきました。ルーチンワークに苦手意識がありましたが、ToDoリストのリマインドによってリズムよく仕事ができています。実は年始に手帳を使ったスケジュール管理を始めたのですが、こちらに移行してから手帳は「情報を記録する場所」のみになりました。ただ、アナログはアナログで素早く確認・ふりかえりができるため今後も続けていきたいと思います。特に、活動の分類（情報収集・意思決定・ナッジング・ロールモデル）のふりかえりがあまりできていなかったので、記録として残すようにしたいです。
また、営業メンバーと一緒に顧客を訪問する機会も増え、そこで記録した情報をデジタルでも残して関係者にメールすることを続けていた結果、上司や営業メンバーからも感謝され、仕組み化され、情報連携がスムーズになりました。情報を開示する範囲やタイミングについては、「12章 情報の証券取引所」をもう一度読んでおこうと思います。
本格的にマネージャー業務を行うようになって、やめた（やめざるを得なかった）ことは「ソースコードを見ること」でした。個々のチームを知ることはもちろん必要で、介入の度合いは状況に応じて変化しますが、一つ一つの内容までを見ることはなくなりました。その代わり品質メトリクスやチームのメトリクスに対して意見するようにしています。
最後に
マネージャーになって一番の変化は視点・視野・視座が明らかに変わったことです。今まで開発チームを率いてプロジェクトマネジメントをしていたときも気をつけてはいましたが、1アカウント2～3チームをマネジメントすることと、複数アカウント複数チームをマネジメントすることは大きな違いでした。説明責任・成果責任も加わるので、意思決定することに以前よりも大きな不安がつきまといます。不安に対してはきちんと向き合って、不確実なこと、曖昧なこと、知らないことを一つずつ具体的なものに置き換えて行く必要があります。
仕事納めの次の日に呪術廻戦0を視聴したのですが、禪院真希のセリフが印象的で痺れました。
じゃあ祓え 呪いを祓って祓って祓いまくれ‼ 自信も他人もその後からついてくんだよ‼
チームメンバーにロールモデルを示せるよう行動し続けることを来年の目標にします。
