はじめに
弊社では、大きな1つのサービス（ECサイト）をたくさんの部署が協力しながら運営しています。
2012年4月に新卒入社して以来ずっと同じサービスに携わっている自分が、開発チーム内でサーバーサイドエンジニアとして意識してきたこと、そして今はマネージャーとして意識していることを簡単にまとめてみました。
エンジニアとして意識していたこと
1.1/3の法則
1/3の法則とはスケジュールを立てる際に、全体の時間の過ごし方を「設計」「開発」「テスト」それぞれ1/3ずつで分配するという方法です。
ただし、順序は問わずです。
全体の開発の中で、まずモックアップ的に実装することをフェーズ1、プロダクトとして出せるレベルまでクオリティを高める実装をフェーズ2とすると、それぞれのフェーズ内で1/3の法則を適用させます。
入社後しばらくは、コードを書くことが楽しくて「とにかく手を動かして作りまくるぞ！」と意気込んで仕事をしていました。その結果、設計やテストが疎かになり、後から改修を加えにくいようなコードになっていたり、リリース後にバグが発生し修正するということが多々発生しました。
1/3の法則を知り時間の使い方を意識することでコードを書くことだけに集中せず、「設計」「テスト」にしっかりと時間を割き、クオリティの高いアウトプットを出せるように意識しました。
2.スピードとクオリティのメリハリをつける
チームで開発していると、自分の実装がある程度の部分までいかないと他メンバーが動けないという場面があるかと思います。
「どう実装しようか」と悩む前に、中身は置いといて他メンバーと自分との境界線となる部分をスピード重視で仕上げましょう。
その後は、他メンバーへ気を遣う必要なく中身のクオリティを納得いくまで実装できます。
3.作ろうとしているものを周りに伝える
経験上、「この設計は完璧だ」「この実装方針に敵うもんはないだろう」と思っている時ほど考慮漏れ等のミスは起きるものです。
上司や同僚は自分が思っている以上に気付きを与えてくれます。
「あ、でもそこリリースした後評判良ければこういう改修入りそうじゃない？」
「同じような処理を別の〇〇の機能で悩んで結局そのやり方やめたんだよ。理由はこれこれで・・・」
「前回その機能リリースした後、〇〇と〇〇っていうパターンの考慮漏れがあったんだよね」
自分の考えの区切りがついたタイミングで考えた設計内容や実装方針を伝えてみましょう。
もちろんチームでそういった雰囲気作りをすることも忘れずに。
4.自分の領域を広げる挑戦をする
自分の仕事の範囲を自分で広げていくことを意識していきましょう。
今ある知識や経験の範囲内で開発をしていくことは楽でやった気になると思いますが、もっと違うやり方はないのか、本当にこれが正解なのかを貪欲に考えるなど常に自分にハードルを課しましょう。
また、上司の仕事を奪うという姿勢もおすすめです。
他チームと仕様調整をしに行く上司に「俺にやらせてください！」と自ら伝える、難しい案件が来たら手を挙げてみる、こういうことをやってみたいと常に周りに言っておくなどなど。
自分はこの仕事だけやっていればいいんだと思わず、仕事の範囲を自分で広げようと意識することで視野が広がりやれることも増えていくと思います。
マネージャーが考えてくれている成長のレールの先を自分で取りに行きましょう。
5.前向きに取り組む
「前向き」というのは何もあっけらかんに物事を受け入れるということではなく、**「自分が関わるものは全部良い方向に持っていこう！」**というマインドのことを指しています。
たくさんの人が関わり1つのサービスを作る中でただただエンジニアとして「開発」だけをするわけではなく、一つ一つの出来事を「前向きに」受け止め、「前向きに」考え、「前向きに」行動することでいいエンジニアになっていくと思います。
ちょっとした運用作業を任された時にも「どうしたらこれを自動化できるかな」と考えたり、解決したい問題と提案された仕様が少しズレていたら「なぜこれをやるんでしょう？他にこういう解決方法は考えられないでしょうか？」と声を上げてみたり。
また、「あぁ、チームのあの子が悩んでいるな。どうしたら励ましてやれるかな、助けられるところはないかな」とチームの健康状態を気にしてみたり。
何事にも前向きに取り組んでいる姿は想像以上に周りにもいい影響を与え、自分の経験濃度が濃く積み上がっていきます。
いつの間にか頼りにされていたり、いざという時に起死回生のアイディアが閃いたり、ふとした時に恩恵を感じられると思います。
マネージャーとして意識していること
1.信頼を得られる努力をする
開発メンバーとの信頼関係がないと誰も自分の言うことに納得して動いてくれないという最悪のパターンに陥る可能性もあります。
また、他部署の方との信頼関係がないとそういった方々との大きな意思決定をする場で、意見を聞き入れてもらえない可能性もあります。
信頼を得るためにはこれと言った特効薬はなく、とにかく日々誠実さや思いやりを持って行動していくことを意識し信頼を積み上げていくしかないと思っています。
2.依頼された内容をそのまま受け取らない
マネージャーになって改めて実感したことの一つが、開発チームには本当に様々な部署からの相談が続々とやってくるなということです。
ビジネスチームから売上UPのためのキャンペーン施策、CSチームからユーザーさんとのコミュニケーション手段の拡張、フルフィルメントチームから運用変更に伴うシステム改修‥などなど。
1つの大きなサービスを運営しているため、そのサービスの中でアウトプットするものの多くに開発チームが関わっています。
そのため、様々な知見が溜まっていくのも開発チームの強みです。
そして、その強みを活かしてサービス全体に還元していくのもマネージャーの役割だと思っています。
ビジネスチームから「売り上げのために〇〇というキャンペーンをやりたい」という相談が来た際に、「それであれば、前回やったあのABテストの結果使えそうだな。」「あ、その仕様だと以前やったあれに似てるな。ユーザーさんからの問い合わせが増加したとCSチームが言ってたな」という気付きが出てきます。
そこで、依頼内容の本来の目的を深掘りし、最適な仕様を逆に提案するという必要性が出てきます。
サービス上の仕様はもちろん、社内の様々な情報が集まる開発チームだからこそ担うべき役割を意識しています。
3.出しゃばり過ぎない
もともと自分もエンジニアとしてコードを書いていたこともあり、一つ一つの開発案件の細かな設計方針や進め方を決めてしまうことが多々ありました。
スムーズに開発を進めるためによかれと思っていたことでしたが、実はチームメンバーの成長の機会を奪っていることに気付きました。
マネージャーは常に前に立つだけではなく、メンバーが成長・活躍できる土台を整えたり、目的や背景を正確に伝えてみんなの背中を押してあげるという重要な役割があります。
マネージャーが出しゃばる部分・出しゃばるべきではない部分のバランスのとり方は日々意識していこうと思っています。
4.世の中の動向・他サービス・未来を常に意識する
「自分たちが向かっているところはどこなのか」
「自分たちが提供しようとしているサービスは正しいのか」
マネージャーになってこういったことを常に考えるようになりました。
正解があるわけではないのでしょうが、都度都度自分なりの考えを持っておかないと意思決定もできないし、深みのある議論もできないと思います。
そのためには、世の中の動向や他サービスの動き、そして自分たちはどうするのかという未来を常に意識して考えておくということが必要です。
ユーザーさんの時間の使い方や買い物の仕方がこう変わってきていて、他サービスはこういうサービスを提供している。つまりこういう判断なんだろうな、じゃあ僕らはこうするべきかな、いやこの方向も考えられるな、などなど。
5.前向きに取り組む
やはりこれが大切です。
良くも悪くもチームはマネージャーの色が強く反映されます。
チームを率いるマネージャーがいつも下を向いていると徐々にチームもそういった雰囲気になっていきます。
**「自分が関わるものは全部良い方向に持っていこう！」**という前向きマインドで動いているとその姿は間違いなくみんなにじわりじわりと伝わっていきます。
みんなが一丸となって困難に立ち向かえるような強いチームを作るために、まずマネージャーが前向きに動いてみましょう。
最後に
今回、普段考えていることを初めてしっかりと文章に起こしたのですが、自分の考えを改めて見つめ直す良い時間でした。
自分もサービスもまだまだ成長段階です。
マインドだけの男にならないよう地に足つけて前向きに進むのみです。
これからも日々精進し、みんなで楽しく良いサービスを育てていきたいなと思います。