こんにちは！！
トラストバンクにエンジニアとして入社して3年目の @kazuyaseo です。
会社として2回目のAdventCalendarですが、今年は自分が開始宣言を務めさせていただきます。
今年もテックな物から頑張り話まで色々な記事が上がってきますのでぜひ楽しんでいってください！
トラストバンクと担当サービスの紹介
弊社トラストバンクですが、「自立した持続可能な地域をつくる」というビジョンに沿って、いろいろなサービスを提供している会社になります！
ビジョン実現のためのミッションとして
- 地域にお金の流れを創出する
- 地域内でお金を循環させる
- 地域外へのお金の漏れを防ぐ
の３つがあり、本日紹介させていただく「ふるさとチョイス」と言うサービスは
「地域にお金の流れを創出する」 を実現させるために日々奮闘しているサービスです！
また、一言で「ふるさとチョイス」と言っても歴史は10年以上あり、今では以下の様に複数のプロダクトに分かれて展開をしております。
- ふるさとチョイス
- ふるさとチョイスGCF
- ふるさとチョイス災害支援
- ふるさとチョイスAPI
- ふるさとチョイスCMS
サービスの利用ユーザも様々で、寄付者・自治体・提携企業と提供範囲が広く、
エンジニアとして色々なユーザに対して価値を提供する事に日々やりがいを感じています。
部署の紹介
そんなふるさとチョイスの開発を一手に担っているのが「ふるさとチョイス事業本部の開発部」です。
部署の規模は正社員と委託社員合わせて約40人で、
「システムエンジニア」 「サーバーサイドエンジニア」 「フロントエンドエンジニア」 「QAエンジニア」
と色々な役割のメンバーが所属しています。
今年の４月から部長を @kazuyaseo が担当、
副部長を @trustbank_isobe が担当することになり、
二人の新米エンジニアリングマネージャーで課題解決できるエンジニア集団になるべく奮闘しています。
書いたこと
そんな新米部長が約半年間行ってきた事と、少しだけ心がけていることを以下の章立てで書きました。
「こうやったらうまくやれるよ」 とか 「これをやればバッチリ！」と言った記事ではなく、「心がけていること」とか「気にしていること」を書いています。
どちらかと言うと反省点が多い7ヶ月だったと思っておりますが、そんな経験談も誰かの参考になればと思っています。
1.目標を決める
目標を決める上で意識したことは「1年間何するか」ではなく「1年後どうなっているか」でした。
そのためにも大体3年後ぐらいの姿を想像(妄想)した上で「じゃあ1年後にどうなっていれば良いか？」と落とし込んで考えました。
ある程度先のことを見据えて方針をたてないと、目標に向かって活動してくれるメンバーの納得度が低いままになってしまいます。
部の目標を決める
まずは会社が開発部に対して何を期待しているかをしっかりと聞き、期待値を書き留めます。
その上で、部として「どうなっているか」というのを姿や状態を使って考えます。
作成した大目標をいくつかの細かい目標に分解することで、
より達成までの道筋を明確にするようにしました。
ちなみに、目標設定は「定性的目標」と「定量的目標」の２つをバランス良く設定するのが良いとされており、
定性的目標が多すぎると具体性が無いため達成度合いが曖昧になり、定量的目標が多すぎてもイノベーションや変化が起きにくい、
という指摘を受け、かなり悩みましたが、今となっては悩むこと自体に時間をかけすぎたと反省しています。
最初に良い目標をたてようと頑張るより、目標達成期間まで細かいチューニングをすることが大事と思います。
メンバーの目標と施策を決める
部の目標を立てたら、その目標を元に施策に落とし込みます。
イメージとしては以下のような釣鐘型の目標と施策の構造にして、部全体の目標をマネージャーが責任を持ち、分解目標をリーダーが見る、
目標実現のための各施策をメンバーが推進する、と言う形にしました。
ブレイクダウンさせた各施策を個人の目標に分担する時は、できるだけメンバーのスキルと本人の興味を照らし合わせ、メンバーにマッチする目標を持つように心がけています。
ただ、メンバーが多いとその調整がなかなかうまく行かず、来年はもっとメンバーの意思にマッチした目標設定にしたいと思っています。
進捗確認とチューニング
1度決めた方針をすぐに変えてしまっては意味が無いですが、事業も市場も社内も常に変化していくものなので、
最初に決めた方針がその後もずっと活かせるかと言ったら不可能ですし、その目標に固執すると何もできなくなってしまいます。
そのため定期的なチューニングや変更は必要です。
今は月に1回、メンバーを集めて定期的に進捗確認とチューニングを行うようにしています。
定期的に確認していると良いことが多く、
「業務をしていて気づいたけど、今の課題はこっちだと思います」
や
「こんな事をやってみたら思った以上に効果があったので他のメンバーにも広めたいです」
など、嬉しい提案がかなり上がってきます。
こういった提案を取り入れてチューニングできるようにすることが重要だなとひしひしと感じました。
2.ピープルマネジメント
ピープルマネジメントにおいて実施するべきことは多岐に渡り、業務フォローやキャリア相談・スキル相談・モチベーション管理から勤怠管理など様々です。
日々起きる相談事に対応しつつ、絶対やると決めたこととして 自分は 1on1 を積極的に行いました。
ひたすら1on1
とてもシンプルですが、1on1は常にするようにしました。（※ 副部長も含めて実施したので呼び名は2on1にしてます。
頻度は2週に1回、時間は15分〜30分を取っての実施です。
形骸化やスキップばかりの1on1にはしたくなかったので、個人的に以下の目標を立てて運用してました。
次の1on1がお互いの負荷にならないようにする
そのために意識したポイントを書いておきます。
以下に書いた3つは1つでも破られるとメンバーとの良い関係が築けないなと、いくつかの現場を見て思ったので強く意識しています。
できるだけ話を聞く
タスクを作らない
ネガティブを作らない
また、開始当初は1on1のテーマを「個人目標の進捗確認」として実施しました。
それだと「1on1じゃなくて進捗確認ではないか？」と思われるかもですが、
メンバーとの関係構築ができていない状態から”課題のヒアリング”や”本人が話したいことを話す” をテーマにすると話題が上がってこない事が多く、
話題の無い1on1はスキップされ続けてしまいます。
また、そうならないように上長が積極的にテーマを持ってくるシーンを良く見てきましたが、
上長がテーマを用意すると、回数を重ねる毎に指示・指摘が増えメンバーが負荷に感じていた現場も見てきたので、避けるようにしています。
ただし、進捗確認も大事なテーマでして、1on1の時間を使い切っても進捗確認すら終わらないと言うシーンが多々あり、来年は時間をしっかりと取って対応するようにします。
3.テクニカルマネジメント
テクニカルマネジメントというとちょっとかっこいい言い方ですが、
開発をする上で色々な技術的相談をそう言ってます。
技術相談は様々ありますが、弊社はCTO室があり、機能設計・相談やレビューはCTO室に行って頂いてます。
他にも相談は様々ですが、多いのは以下の2点かなと思います。
- 実装相談
- スケジュール相談
実装相談
実装相談は開発部内部のメンバーからの相談よりも、別部署からの相談事が多くあります。
相談事は「こういった改修は可能か？」「こんなツールを導入してみたい」など、内外問わずいろいろな質問が来ます。
メンバーの時にも相談は受けていましたが、マネージャーになると自分の回答における重みが変わってくるので
注意が必要です。
メンバー時代は受けた相談に対して実装するのも自分自身であるため、
ある程度自分の発言に対して自分でフォローすることができました。
ただし、マネージャーになると、相談に対して実装するのはメンバーになるため、
自分の発言における責任や影響範囲が全く違います。
そのため「自分だったら」と言う判断は確実に禁物です。
判断材料が少ない時ほど陥りやすいので、すごく注意したいところです。
そのため、マネージャーになってからの実装相談は
「いつ」 「誰が」 やるのかをしっかりと想定した回答をする必要があります。
社内の開発項目が多くなるほど、「いつ」「誰が」の想定が難しくなるのですが、
ここで曖昧な発言をするとメンバーに負荷が寄ってしまうので、できるだけ先々の事を考えた上で発言するように心がけています。
スケジュール相談
スケジュールに関する相談はほとんどが「遅れ」に関する相談です。
弊社はプロジェクトが組成さたタイミングで以下のような流れで開発が進みます。
大きな開発フロー
- プロジェクト組成
- 開発メンバーのアサイン
- メンバー全員で 要件定義・仕様検討
- 開発メンバーで 設計・見積もり
- 開発・テストの実施
- QA試験
- リリース
開発フェーズはどこの現場においても常に後工程に入るのでいつもリカバリには苦戦しています。
解決の難易度は高いですが、自分がスケジュールの遅れについて相談を受けた時は以下の２つを意識するようにしています。
利用者にとって必要な機能に絞り込む
利用者にとって必要では無い機能を残し、そうでないものは落としています。
大事なのは「利用者にとって」は絶対に変えないようにしています。
機能を落とす判断は切り出すのがとても難しそうに感じるかもですが、勇気を持って発言すると良いと思います。
要件定義をした時と比べて開発のフェーズに入って実際に動くものを目にすると、
意外と「あれ、これいらないかも」「あったほうが良いと思ったけど、使わないかも……」
と言う機能が結構見つかるものです、
機能を落とすというとイメージがあまり良くないかもですが、
スケジュールの遅れが発生した時は「機能見直しのチャンスだ！」と思って前向きに対応するように心がけています。
後工程を削る
ここで言う「後工程」はほぼ「テスト」が多く取り上げられるかと思います。
「単体テスト」や「結合テスト」「QA試験」などの後工程を削るという選択肢を取るシーンは今までの職場でもたくさん見ていました。
行程を削るとスケジュールの短縮が目に見えてわかるので、よく選ばれることが多いです。
ただし「テスト」を削る事で品質の低下は間違いなくあります。
長期に渡って運用しているサービスにおいては、その運用期間が長いほど後でボディーブローのように効いてきて、最終的には致命的なダメージになります。（なったシーンをいくつも見てきました）
あと、個人的にそもそも品質の低いサービスを利用者に提供するという判断が嫌です。
「運用でカバー」などの言葉を使ったりすることも多いと思いますが、運用でカバーはほぼ無理だと経験で感じています。長期運用を実現するためにも後工程を削るのはしないようにしたいです。
4.採用活動
組織の成長のためにも採用活動はものすごく重要ですし、自分も採用や教育に対しては熱量が高いので、採用活動に関してはリーダー時代から積極的に関わるようにしてきました。
メンバー時代は「カジュアル面談」がメインでしたが、部長になると「面接」になります。
どちらも求職者にとっては「会社に触れ合うための最初の顔」になるので、毎回緊張しています。
カジュアル面談・面接
カジュアル面談や面接で行っていることや気にかけていることはとても多いため別の機会に紹介しようと思いますが、
常に自分が心がけていることは面接官でもカジュアル面談でも
「求職者は自分を通して会社を見ている」
という事を意識して望んでいます。
あまりに見られていることを意識しすぎて、聞くべきことを聞き忘れないようにカンペを用意しながらではありますが、
自分が見ていることよりも見られている事を意識しながら面接をしています。
5.予算管理
歴代の上司達が「重要だ」と口を酸っぱくして伝えて来てくれたのに、実際に手を付けるまでその重要性に気づけなかったのが予算管理です。
最初は「人件費とシステム運用・保守費用を用意すればよいか」ぐらいに思っていましたが、
実際に進めてみると他にもたくさんあり、前任からの引き継ぎが無かったら間違いなく破綻していました
僕は今までエンジニアとしての経歴が多く、これらの管理や考えはとても苦労してます（今でも）。
- 人件費（業務委託費用)
- セキュリティ検証費用
- 資格取得などのための受講費用
- 検証端末費用
- とかとか、他にも色々
弊社はSREがサーバー費用や監視費用などを管理してくれていただいているおかげで開発部が管理する費用の種類はそんなに無いのですが、
上記の他にも、もし「カンファレンスのスポンサーになりたい」とか途中で思い立ったら別途予算が必要になってきます。
何にお金を使うかは非常に大事なので心得ておきましょう。
あと、歴代の上司から教えてもらったことはちゃんと聞いておきましょう。
これからエンジニアリングマネージャーになる人に向けて
文章ばかりなのと、役割が多岐にわたっていたのでまとまりが無くて恐縮ですが、
エンジニアリングマネージャーとしてやっている事を記載させていただきました。
いかがでしたでしょうか。
マネージャーになるタイミングは準備万端に訪れるよりも、急にやってくると思います。
そんな急にやってきた人に少しでも参考になれば幸いです。
書き出してみると改めてたくさんの事をしてきましたが、正直これらをエンジニアリングマネージャーのみで実施し続けると忙殺されてしまいます。
その結果、いざというときの判断力が鈍ってしまい本来の力を発揮できないままになります。
自分の身を軽くし、必要な時に必要な力を発揮できる状況を作り上げて、頼られるマネージャーになれるようにしようと思います！
明日の記事は @a_wis1056 さんです、お願いします！！