この記事は、DMMグループAdvent Calendar 2021の19日目の記事です。
はじめに
こんにちは。DMM.com ITインフラ本部、インフラ部の大山です。
私はWeb アプリケーションのバックエンドやフロントエンドの開発や、DevOps によるインフラの運用の簡素化などに取り組んでいるソフトウェアエンジニアです。具体的には、DMM.com インフラ部で開発している情報管理システム AirOne の開発・保守・運用と、StackStorm を用いた インフラの運用自動化 に取り組んでおり、また現在、StackStorm の Contributor もしています。
以前は、OpenStack による Private IaaS の構築・保守・運用 を行なっており、(ほんの一瞬だけですが) Upstream の Technical Contributor もしていました。
現在はソフトウェアエンジニアをしつつ、チームリーダーをしております。
また、チームは各メンバーが現状と目標をよく理解したうえで、それぞれが何をすべきかを考えて行動してくれ、皆が協力しながらプロジェクトに取り組めているとても良い状態で、現在私は全キャリアを通じて最高のチームで仕事ができています。
しかし、チームがこうした状態に至るまでに、様々な問題や苦悩、失敗を経験してきました。特にマネージャーの役割や仕事を、プレイヤーから見えていた表面的なモノだけを考えていたことで、多くの失敗をしてきたように（振り返ってみて）思います。
今回はチームが発足してから今日に至るまでに、チーム運営に関して経験し学んだ内容について記載致します。
プロジェクト発足。そして皆居なくなった
2017年1月、現在私たちが取り組んでいる情報管理システムAirOneのプロジェクトがスタートしました。
プロジェクト発足時のミッションは「現在の情報管理システムの課題を何とかせよ」というものでした。プロジェクトは、当時のインフラ本部長の肝入りでスタートしました。プロジェクト発足時のリーダーは、直属の上司でもあった 高嶋隆一 氏でした。彼は私のエンジニア人生の恩人であり、私はエンジニアとしての仕事のやり方の多くを彼から教わりました。
そんな高嶋氏は、プロジェクトの意思決定以外のほぼ全て（ゴール設定、実施計画、メンバー運営、設計、開発、運用など）を私に任せてくれる一方で、よく部下の仕事ぶりを観察し、部下が行き詰まっているところを見計らっては休憩がてらコーヒーを飲みに誘ったり、よく飲みに連れて行ってご馳走してくれる、とても人情味があり、部下からよく慕われる人物でした。
またプロジェクト発足時のメンバーは、私の他に２名のベテランエンジニアがおり、プロジェクトは順調なスタートを切りました。
途中の経過は省きますが、部内でのヒアリングや、そこで得られた課題の整理、そして課題を解決するための手法の比較・検討の結果、2017年04月に既存システムの課題を解決する情報管理システムを内製し、リプレースすることが決定され、正式に情報管理システム AirOne の開発がスタートしました。
その後、１年半の開発期間中に 所属会社の統合 とそれに伴う部署再編を経て、2018年07月頃に旧システムをリプレースする段取りまで何とかこぎつけることができました。
そんな矢先のある日、上司の高嶋氏からいつものように「コーヒーを飲みに行かないか」と言われ、向かった先の会社近くのテラス席で「再来月、オレ会社を辞めるから」と告げられ、大変ショックを受けたことを覚えています。
更に追い打ちをかけるように、その前後に２名のシニアエンジニアの方々も、それぞれの事情で会社を去られ、プロジェクト発足からのメンバーは私一人だけとなってしまいました。
新メンバーの採用と受難の日々
その後、上司が退職される前に採用したエンジニアと、協力会社のエンジニアと私の３人で、何とか情報管理システム AirOne のプロトタイプが完成し、2018年11月に旧システムからのデータ移行を完了させ、プロジェクトは無事正式リリースさせることができました。そして上司が退職した後は、別のチームマネージャーがチームリーダーを兼任することになりました。
しかし、その後のユーザからの要望であったり、トラブルシュートなどで、開発期間中にも増して忙しい日々が続きました。そんな折に、私はチームリーダーを兼任されているマネージャーから引き継ぐこととなり、この時初めて名実共にプロジェクトとチームのリーダーとなりました。
チームリーダーとなってからは、とにかく無駄を省くチーム運営を心掛けていました。
当時は「ミーティングは基本的に作業時間を減らす無駄なもの」と考えており、極力ミーティングを減らしていました。上司への進捗の報告や情報共有など、最低限必要なミーティングは通路に置かれているホワイトボードの前に集まって立って行っていました。またミーティングも前置きや雑談を一切行わずに、要点や結論だけを報告・共有することを徹底し、質問が出たときだけ詳細を説明するというように、とにかく「無駄」とするものを削るようにしていました。
こうした結果、思惑通りミーティング時間は減りました。しかし、チーム内でのコミュニケーションはみるみる減り、やがて意思疎通に齟齬が生じるようになりました。
言ったことが伝わらない。認識の共有ができていないので、アウトプットが噛み合わない。そんな状況が続き、もどかしさが態度に漏れ、メンバーが萎縮し、アウトプットが振るわない。チームの雰囲気がどんどん悪い循環に陥り、遂にチームメンバーの一人が異動を希望、そして協力会社のエンジニアの方も異動されてしまいました。この時、完全にチームのリーディングもマネージメントも完全に失敗したことを自覚しました。
マネージメント研修と、そこで得た学び
私が属するDMM.com のIT インフラ本部ではマネージャー向けの研修を積極的に行なっており、私がチームリーダーとなって初めて参加した研修で、私はマネジメントに対する考え方が大きく変わるきっかけを得ました。
その研修の内容としては、「優れたマネージャー」は何を以ってして「優れている」と言われるのかについて、彼ら（彼女ら）が普段行なっている行動を分析・構造化し、「良いマネジメント」とされるマインドや行動について考えた上で、ケーススタディを進め、自身の現場でのアクティビティについてフィードバックしていく、といった内容でした。
その際、研修冒頭で「マネージャーの役割とは何でしょうか？」という質問が出されました。そのとき私は、自信満々に以下の通り回答しました。
『 プロジェクト（チーム）の目標を設定し、設定した目標に向けて計画（道筋）を立て、リソース（ヒト・モノ・時間）の配分・調整・管理を行いながら、目標を達成すること』
これに対して出された「答え」は以下の内容でした。
-
仕事の側面
- 仕事の管理：仕事の計画を立て、メンバーに仕事の割り当てをし、指示命令し、進捗をコントロールする。またそれらを円滑に進めるための調整を実施する
- 仕事の改善：絶えず問題意識を持って問題を発見し、改善していく
-
人の側面
- 人間関係の強化：職場のメンバー同士のコミュニケーションを豊かにし、それぞれの力を集結させる
- 部下の育成：メンバー一人一人の能力、意欲を最大限に引き出し高めていく
これは「過去から現在までの優れたマネージャーの行動から、マネージャーがこなすべき役割をまとめたものだ」と紹介されました。
「仕事の側面」に関する役割は、概ね考えていた通りでしたが、「人の側面」に関する役割は完全に私の考えを超える内容でした。しかし研修では如何に「人の側面」の役割が重要で、世の多くのマネージャーが軽んじている（または行なっていない・考えていないか）について語られました。
こうした考えに当時の私は、大きな衝撃を覚え、すぐには受け入れられませんでしたが、「人の役割」の重要性を理解し、これまでの結果を振り返ることで、自身の失敗の原因がそこにあるのではないかと思うようになりました。
救世主の登場と試練の始まり
私は幸運なことに、こうして学んだ内容を実地で試す場が存在していました。またそんな折に、前職の先輩でRubyのコミッタなど数々のOSSへの貢献活動で知られる、業界きってのスーパーエンジニア 高野光弘 氏をチームに招くことができ、この頃からチームの状況が徐々に改善していきました。
高野氏によって、デプロイシステム、ミドルウェアのバージョンアップ、E2Eテストによる品質保証など、数々のシステム改善が進むとともに、チーム内でのコミュニケーションが活発に行われるようになりました。
高野氏の仕事の姿勢はとても謙虚で誠実、それでいてエンジニアリングに関しては非常に熱心な方で、彼の姿勢を見て、信頼できるチームのメンバー同士においては相手に対する「注意」や「指摘」といった、相手がプレッシャーに感じる言動は、協力して仕事を進める関係を築く上で必要無いことを学びました。
例えるならば、Web アプリケーションサービスを提供するチームのエンジニアが、バグを修正する際に、本番環境のアプリケーションノードにログインし、デプロイされているコード手動で修正するという（Webアプリケーション開発の常識では考えられない）ことをしたとします。
この場合、当該チームの責任者であれば「本番環境に気安く入っちゃだめですよ」「デプロイ済みのコードを直接触るやり方はありえないです」といった注意や間違いの指摘をするかもしれません。しかしこうした言動は、言われた側の人間に不必要な精神的負荷を与えうる（エンジニアのモチベーションを下げるだけでなく、人間関係をも毀損しうる）ため、以下のように言い換えると、そうした問題は起きづらくなると思います。
「今度からは、コードを修正する際にはソースコード管理システムへの修正リクエストを出して、CI とレビューを通してから、規定のデプロイの仕組みで反映させて頂けますか？もしわからない事があれば質問をしてください」
どちらも同じ趣旨の内容ですが、言われた側の印象は後者の方がだいぶ良いと思います。また前者の場合、マネージャー側は「注意」と「指摘」を行なったエンジニアの行動改善に対するリアクションを取りづらいですが、後者の場合、マネージャー側は「お願い」をしているので、行動改善をお願いされたエンジニアがその通りに行動してくれた際に感謝を伝える（リアクションをする）ことで、エンジニアにプラスのフィードバックを与えることができます。
また、別のケースとして何か必要なことをしていなかった相手に対して、「〜をし忘れていますよ」といった指摘から、「〜を今週中にしていただけますか？」といったお願い（とそれに続く感謝）に変えることで、同じ内容でも受け手の印象に、だいぶ違いが生じると思われます。
このように高野氏の参加をきっかけにして、誰かに対する注意と指摘をやめ、お願いと感謝をすることで、同じ内容を伝えるにしても、相手のモチベーションを下げるリスクを低減できることを学びました。
その後、私たちのチームにソフトウェア開発ほぼ未経験というエンジニア 日名川幸矢 氏が参加してくれる事になりました。彼のことは以前から知っていたので、チームに来てくれることを嬉しく思う一方で、また過去と同じ失敗を繰り返すのではないかという不安と、もうそうはならないという自信がこの時はせめぎ合っていました。
それから約１年半を経て
日名川氏は我々が当初期待していた以上の成長と活躍を果たしてくれ、今では我がチームの全ての分野の開発・運用をリードするエンジニアに飛躍してくれました。彼は常に高いモチベーションで業務に取り組み、また常に質・量共に高い成果（アウトプット）を出し続けることで、エンジニアとしての模範となり、チームの他のメンバー（特に私）が彼に倣って業務に励むようになりました。彼の活躍によって、WebアプリケーションのDBのボトルネックや、数々の不具合、そしてユーザからの要望が、立ち所に解消・追加され、今日のユーザの拡大、及びシステムの安定運用に大きく貢献してくれています。
その後、元メルカリのフルスタックエンジニアsyucream先生こと 大久保諒 氏もチームに参加してくれ、大久保氏も日名川氏と同様に高いモチベーションで、質・量共に非常に秀でた成果を出し続けてくれており、プロジェクトの推進に多大な貢献を果たし続けてくれています。
彼らの活躍によって、チームのアクティビティはどんどん加速し、かつては不肖ながら私がチームをリードしていましたが、今は私がチームのアクティビティに必死になってキャッチアップしています。
チームリーダとしての私の存在が、どれほど彼らの行動に寄与できているかは定かではありませんが、小さな心がけの変化から、とても大きな環境の変化を経験しています（ひょっとすると、単に現在のメンバーが優秀過ぎて、勝手にチームが良い方向に加速的に進んでいるだけなのかもしれません） 。
終わりに
冒頭で申し上げた通り、現在私は最高のチームで仕事をする事ができ、その成果が会社やお客様、そして社会に微力ながら寄与しているという自覚とやりがいを持って仕事に取り組むことができています。
ただ、ここに至るまでに、私自身が組織や会社にとって必ずしも有益でない場面があったかと自覚していますが、それでも私をマネージャーとして起用し続けてくれた上司や組織、またこれまでに私と一緒に仕事をしてくれた全ての方々に深く感謝しています。本当にありがとうございます。
今後もエンジニアがもっと楽しく仕事ができ、もっとたくさんの成果を生むチームにしていきたいです！
