マネジメントにルールを設け、キャリアとして意識する
エンジニアの中には一生現役で、できればマネジメントは避けたいと考える人も少なくない。しかし、組織の中で仕事をする以上、チームを束ねたり、成長させたり、場を管理する責務は誰にでも生じる可能性がある。
今回登壇した酒井氏もまた、同サービスのSRE（Site Reliability Engineering）とグループのエンジニアマネージャーを兼任して2年目。経験もまだ浅く、最初は戸惑いもあったという。
酒井氏は「今回は、マネジメント入門者として、どういったことを考え、実践してきたか。理論や思想ではなく、具体的で理由のあるアクションを中心に紹介したい。マネージャーの方はご自身と照らし合わせながら、そうでない方はマネージャーが何を考えて行動をしているのか、ぜひ今後の参考にしてほしい」とセッションの目的を語った。
酒井氏がEMとしてマネジメントを行っているのは、招待した家族だけで子どもの写真・動画を安全に共有できるアプリ「家族アルバム みてね」の開発グループだ。ミクシィ創業者の笠原健治氏がプロデューサーという、注目のサービスであり、2019年5月には利用者数が500万人を突破。積極的な海外展開も開始している。
そのEMになるまでの酒井氏の経歴は、もともと「みてね」開発のごく少人数のスクラムチームに所属したことに始まる。マネージャー不在のフラットな開発組織で、プロダクトの成長とともにスケール可能な組織にする必要性があったことから、長く在籍しておりドメイン知識が蓄積されていた酒井氏がマネージャーを引き受けることになったという。酒井氏は「新しいメンバーにとって安心感を提供することもマネージャーの役割の1つだとすれば、ドメイン知識が豊富というのは、大いに役に立った」と振り返る。
現在、酒井氏が所属する「みてね」の開発グループは、ネイティブアプリと研究開発、SREの3チームによって編成され、総勢18名が所属する。その中で酒井氏はEMとして「複数のエンジニアの生産性を最大化すること」「事業の目標を大幅に超える成果を創出すること」の2点を目標として認識し、マネージャー職に取り組んできた。
マネージャー職は、メンバーの成長やスケジュール、人事評価、予算など考えるべきことも多く、できれば避けて通りたいと思う人も少なくない。酒井氏も、自分のスキルやキャリアと照らし合わせ、不安やストレスを抱える可能性を感じたという。そこで、酒井氏はストレスをためないように、いくつかの「決めごと」を自らに設けた。以下の通りだ。
「特に『キャリアとして』認識することによって、組織最適化のためのマネジメントスキルを汎用的な技術として習得し、活用することを意識するようになった。マネジメント力がつけば、自分自身の収入にも反映され、転職などの際にも強みとなる。たとえ大変なことでも、自分の市場価値や給料が上がると思えば、ストレスも減ると考えた」と酒井氏は語った。
マネージャーが意図して声をかけ、ボトムアップ型組織へと成長
そして、酒井氏が目標として掲げたのが、「ボトムアップ」で一人ひとりが自立的に動き、「学習」し続ける「理想のチーム」だ。これを掲げることで、自分がどのようなことをすべきか、何が足りないのか、照らし合わせながら優先度やタスクを決定できると考えたという。
まず「ボトムアップ」のチームになるために酒井氏が重視しているのは、エンジニアやチームの意見の重要性について、マネージャーである自分も含めてプロダクトオーナーや経営者など全員が理解し合っていることだ。一定のルールのもと、誰もがフラットに意見を言える環境を「何となく」そういう空気でつくるのは難しい。そこで、酒井氏はあえて言葉にして「誰でも意見が言えること」を強調し、意図してそうしたチームにしようと心がけているという。
また「エンジニアの責任によってさまざまな課題が解決されるべき」と、エンジニア自身が感じていることも大切だ。プロダクト開発には複雑な問題が発生するが、決して誰かが解決してくれるわけではない。解決するために自分が行動するものだとエンジニアが認識し、実際に行動できることが大切だ。「これも勝手にそうした空気は生まれないので、どうしたら自立的な行動が生まれるのか、マネージャーが考えるべきなのでは」と酒井氏は語った。
そして、ボトムアップの組織を目指してもトップダウンに戻りがちな理由として「大きい声」に傾きすぎることがあるため、そうならないためのコミュニケーションについても考える必要がある。どうしてもプロダクトオーナーや経営者などの「鶴の一声」で場の空気が変わってしまうことがあるだろう。その際にも、エンジニア一人ひとりが自分の頭で考えるよう、コミュニケーション方法を確立しておくことを大切にしているという。
こうした取り組みによって「ボトムアップ」が盛んになると、効果として「チーム内の意見行動の自由度が上がる」「リスクに対して寛容になる」、そして、トップダウンよりもむしろ責任が大きくなり、「適切な緊張感が生まれる」といった様子に変わってきたという。
自律的に学習する組織づくりのため、問題や改善に気づかせる「振り返り」を行う
そして、酒井氏が目指す組織づくりのもう一つのポイントである「学習」は、技術やスキルを身につけてプロダクトに反映させようという「学習」ではなく、開発プロセスやプロジェクト目標完遂のための「学習」を指す。
これについては、プロセスや進捗管理など、さまざまな視点による短期的・中長期的な「振り返り」が重要だという。その時間をしっかり確保することはマネージャーの役割だ。それらを共有した上で、率直に問題や課題を出し合って、改善案を考え、具体的な行動が起こせるような場をつくること。また、他人やチームの失敗、意見の対立を冷静に受け入れられる空気をつくることも重要だ。
「会議の場では感情的になったり、意見が拡散したり、なかなかゴールにたどり着けないこともある。そうした時のために事前にルールをつくって、明文化しておくと、冷静に会議を回せるようになった。すると、対立する意見に対しての好奇心が生まれ、チーム内に気づきが生まれるようになった」と酒井氏は会議運営のコツを語る。
「学習」によって、「失敗が糧になってチャレンジが増える」やボトムアップと同じく「リスクに対して寛容になる」、そして、振り返りを通じて具体的な改善行動が伴うため「チームとして小さな成功体験の積み重ねと成長を感じられる」という効果もあったという。
「ボトムアップ」と「学習」という2つのキーワードに基づき、理想のチームを目指すうち、「心理的安全かつ責任の大きいラーニングゾーン」を生み出すために両者が必要であり、同時に「相互に必要な要素」であると気づいたという。「学習ができていてもボトムアップができていなければ受け身になりがちで、ボトムアップができていても学習ができていなければ、誰もが好き勝手にやるようになる」と酒井氏は経験から分析する。
メンバーが仕事を進めやすいよう、障害発生を予防・検知・排除
そうした理想のチームを目指し、マネージャーは何をすべきなのか？ その問いについて、酒井氏は、「障害を取り除くことを重視している」と語る。障害の例としては、「会議が多くて作業時間が十分に取れない」「重要事項の決定フローが複雑で時間がかかりすぎて開発者がコードを書く時間がない」「情報が十分にシェアされておらずに判断を誤る」などが挙げられる。
そこで、障害の発生予防から、早く気づくための準備、そして既に発生しているものは積極的に取り除くなどを心がけた。具体的には、次の3点がある。
（1）チーム運営に関わる最低限のルールをつくる
制約を課すのではなく、メンバーを障害から守り、モチベーションを保つためのルールをつくった。例えば、「定例会議を再整理して、不要な会議を減らして作業時間を増やす」「改善活動にどのくらいの時間を使ってもいいのか方針をつくって経営層と握り合う」「会議で議論が発散したり、対立したりした時の対処の仕方を明文化しておく」など。
（2）具体的かつアクション可能なチームと個人の目標をつくる
トップダウンで降りてきた目標に対して、OKRを使って自ら達成したいと思う目標を自分たちでつくるようにしている。自分たちで目標と解決策について考える、さらに個人の目標も自ら設定しすることで、大きな責任感が生まれる。自分の技術がどのように貢献できるか、存在意義を感じやすい。
（3）定期的でオープンな振り返りの場をつくる
失敗はカバーし、成功は称賛する。そうした振り返りの場をこまめに取ることが望ましい。できるだけ短期的な振り返りを多く持ち、失敗の影響範囲を小さくして失敗した時はすぐに具体的な改善アクションを促すようにしている。
この3つの中でも「振り返りは重要」と酒井氏は強調し、「それを実践する上で、さまざまなフレームワークを用いることによって効率的・経験主義的にマネジメントスキルを高めていける」と語った。
楽で効率的なマネジメントのため、フレームワークの活用を積極的に推進
1on1やスクラム開発といった、マネジメントのフレームワークについては、「形だけでしょ？」と言われることもあるという。しかし、「単純に楽であり、身につければどこでも使る」「最初は下手でも繰り返せばうまくなる」「振り返りが用意されているようなフレームワークを採用する」といったメリットを生かせる意味で有用性が高いと酒井氏は反論する。
そのフレームワークの1つとして、まず前述の「OKR（Objectives and Key Results）」が紹介された。OKRとは、組織が掲げる目標を目指し、達成目標（Objectives）と主要な成果（Key Results）をリンクさせて、組織・個人の方向性とタスクを明確にする目標管理方法の1つだ。事業目標に対して何をすべきか自分たちの頭で考えることで、期待と責任が明確になり自分の能力の重要性を感じることができるという。また客観的な指標を用いることで活動を振り返りやすくなる。
酒井氏いわく、OKRそのものの効果以上に、「プロダクトのどこに問題があるのか」「自分のスキルをこういう面で生かし貢献したい」など、これまでになかった突っ込んだ会話ができるようになり、発言し合う関係が生まれてきたという。
2つ目のフレームワークとして紹介されたのが「1on1」だ。2週間ごとに30分、全てのメンバーと行うことを定例化しており、日々の行動・考え方やキャリアの問題など内省的な振り返りの場としている。マネージャーとしては「個人に対して良かったこと」を小さいことでも必ず1つは伝えるようにしているという。その上で、進捗を阻害している要素を取り除くために何をすべきかを考えてもらうという。
そして3つ目が「スクラム開発」だ。短期間で振り返る「スプリントレトロスペクティブ（スプリント振り返り）」がカギで、短期間での失敗の規模をできる限り小さく保ち、失敗を予防・検知・保管する具体的なアクションを起こすところまでをフレームワークとして組み込んでいるため、着実な改善が期待できるという。ただし、あまり頻繁に行っていると「振り返りがマンネリ化してしまう」ことがある。それに陥らないために「複数のスクラムの振り返り方式」「よくあるKPT（Keep・Problem・Try）方式」「Airbnbのゲビア氏による、言いにくいことを言うように促す『象、死んだ魚、嘔吐』」など、さまざまな振り返り手法を用いることで、視点を変え、刺激としている。
学習力やボトムアップ文化を目指して、既存の手法を賢く活用する
そして、フレームワーク以外についても、チームの学習力向上やボトムアップ文化のための取り組みが行われているという。それらのほとんどは、振り返りの中から、メンバーが学びの手法として気づき、少しずつ知見を得ながら実践したものだという。そのボトムアップと学習によってもたらされた結果とともに紹介された。
まず1つ目が「ユーザーストーリーマッピング」。大きな新機能の開発プロジェクトを開始する時には必ず実施するといい、企画者と一緒にエンジニアがユーザーについて考え、抽象的な要求を解釈するといったプロセスを踏んでいる。これをやることで、要求に対する俯瞰的な視野をエンジニア自身が持てるため、自然とプロジェクト中の行動が主体的になっていくという。
そして2つ目が「輪番制リリースマネジメント」。リリースごとのリリースプランニングやマネジメントを、マネージャーやディレクターではなく各エンジニアが行う。QAの進行やマーケティング部門との調整など、リリースごとに必要な情報整理やアクションはエンジニア自身が行うようにしている。こうすることで、自分の開発活動の影響範囲を認識し、リリースに関する問題の改善を行えるようになった。そしてこれまでエンジニア以外がやっていたことで起きていた混乱が起きなくなった。
3つ目が「バックログ準備会」。こちらはエンジニアやCS、プロモーションなどさまざまな視点から課題を出し合う定例会議で、スクラム開発のスプリント中に必ず1回は行われる。課題に対応するためのバックログが完成することをゴールとしており、エンジニア目線で事業にとって必要なことを提案できる。またエンジニアだからこそ提案できる機能や、技術的負債が事業の継続性や生産効率に与える影響など、エンジニアが感じている課題について経営層に必要性を説明し、対応する時間を決定する。
4つ目に「プロジェクトチーム制度」。エンジニアがリーダーとなり、最大半期に渡って実施したい改善などを小規模なプロジェクトとして委ねる制度だ。課題のリサーチや提案から目標の設定、施策の実施にいたるまで基本的に全て“おまかせ”となり、エンジニアがプロジェクト運営を経験することでリーダーシップを促進することができたという。実際にプッシュ通知の許可率向上や管理画面改善プロジェクトなど、アプリのUI/UXに関わる重要な改善が多数行われた。
酒井氏は最後に「マネージャーになる人は不安が多い。理想的な組織を描きつつ、フレームワークを使うことで、自分もチームも学びながら“楽に”マネジメントを行うことで不安を払拭してきた。他にも汎用的なルールをつくって物事を考えることや、常に優先度を考えて行動することでストレスフリーなマネジメントが実現する」と語り、「もしマネージャーとして不安を感じたら『ボトムアップができているか？』『学習できているか？』と振り返ることで何かヒントが得られるのではないか」と結んだ。
お問い合わせ
株式会社ミクシィ
