メンバーが仕事を進めやすいよう、障害発生を予防・検知・排除
そうした理想のチームを目指し、マネージャーは何をすべきなのか？ その問いについて、酒井氏は、「障害を取り除くことを重視している」と語る。障害の例としては、「会議が多くて作業時間が十分に取れない」「重要事項の決定フローが複雑で時間がかかりすぎて開発者がコードを書く時間がない」「情報が十分にシェアされておらずに判断を誤る」などが挙げられる。
そこで、障害の発生予防から、早く気づくための準備、そして既に発生しているものは積極的に取り除くなどを心がけた。具体的には、次の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に関わる重要な改善が多数行われた。
酒井氏は最後に「マネージャーになる人は不安が多い。理想的な組織を描きつつ、フレームワークを使うことで、自分もチームも学びながら“楽に”マネジメントを行うことで不安を払拭してきた。他にも汎用的なルールをつくって物事を考えることや、常に優先度を考えて行動することでストレスフリーなマネジメントが実現する」と語り、「もしマネージャーとして不安を感じたら『ボトムアップができているか？』『学習できているか？』と振り返ることで何かヒントが得られるのではないか」と結んだ。
お問い合わせ
株式会社ミクシィ
