freeeの開発情報ポータルサイト

【連載 第6回】新規プロダクト&新造チーム&フルリモート:そのときEMに何ができるか?

TL; DR

新規プロダクトを新造チームで開発するとき、私のとったEMとしての行動は、ブランコを漕ぐ子どもの背に手を添える母親と同じものでした。

ブランコを漕ぐ子を見守る母親の写真

はじめに

freeeの金融開発チームでエンジニアリングマネージャーをしている横田と申します。このfreeeカード Unlimited連載企画では、これまでWebアプリ開発エンジニアの視点からの記事を5本続けてお届けしました。

ここで一息ついて、開発チームを下支えする私の立場からのエントリーを投稿させていただきます。

エンジニアリングマネージャーという職種は、少しずつですが市民権を得てきているように思えます。無駄に文字数がかさんでしまいますので、本稿では以降「EM」と省略させてください。EMについては、企業によって役割がかなり違ったり、また、同じ企業の中でもチームによって求められるものが変わってくるなど、まだまだ共通解の無い職域なのではないかと感じています。 本エントリーでは偉そうなことは何も書こうとは思っていません(書けません)。実際にfreeeカード Unlimitedのチームをビルドアップするうえで私がどんなことを考えて、どんなことを実践したのか。そんな話を1サンプルとして世の中に共有しようという意図でお届けします。

freeeでの “ジャーマネ” 文化

ジャーマネ制度

freeeにおけるマネージャとは、単にメンバーの上に立つ者のことではなく、”タレント”であるfreeeのメンバーを叱咤激励し、成長・活躍をサポートする役割のこと。 (出展:https://jobs.freee.co.jp/benefits/

このように、freeeではマネージャーのことを「ジャーマネ」と呼び、必ずしも組織のリードではなく、俗に「サーバントリーダー」と呼ばれる下支えの役割が良しとされています。

この考えは私にとっても共感が強く、特にソフトウェアエンジニアのような職種の人たちをマネジメントするうえで、この立ち位置というのはとても合うんじゃないかと思います。そしてサーバントではなく「ジャーマネ」という表現がまた絶妙だなと感じています。偉そうな匂いが全くしなくて、かつ遊び心のある良い呼び名ですよね。

新造チームで新規プロダクト開発

時は2020年末、freeeカード Unlimitedの開発がスタートしたわけですが、この新規大規模プロダクトの開発チームは、社内外から集めたメンバーで作る「新しいチーム」で行うことになりました。 これまでの積み上げがある "出来上がったスクラムチーム" の枠に新しいプロダクトを投入するのではなく、枠組みを作りながらそこにまだヤワヤワの新しいプロダクトを投入してモノヅクリをする必要があったのです。実際、これが非常に大変でした。

さらに言うと、プロダクトマネージャ(兼ドメインエキスパート)も新規採用だったので、とにかくフワッフワしたチームでの回り始めとなりました。

固い枠と柔らかい枠の違い
やわらかい枠組みに不定型なものを入れるとカオスに

当時を思い返すと、コロナウイルスの流行の波を何度か乗り越え、多くのWeb系企業がリモートワークを中心にして開発業務を行っていた時期でした。freeeも2020年3月から早々にフルリモート体制に移行し、「なんだ、意外とリモートでも開発生産性は変わらないじゃないか」という意識が積み上がってきた頃でした。私もいくつかのチームをマネジメントしておりましたが、それらいずれもがリモートワーク以前から共に仕事をしてきた "勝手知ったるチーム" ばかりだったため、この時は、リモート下で新造チームを立ち上げるツラみに考えを巡らすことができていませんでした。

リモートでのチームビルドのツラみ

新規サービスの開発初期フェーズは、どうしても仕様の話し合いやアーキテクチャの検討、システムレイアウトの話などが多くあります。こうした「ホワイトボードが無いと厳しいミーティング」類はそもそもがリモート環境下で画面を通じて実施するのが辛かった記憶があります。オンラインホワイトボードサービスのmiroを使ったり、Jamboardで仮想付箋紙を貼りながら議論もしましたが、やはりホワイトボードに向き合いながらする議論とは体験が大きく異なるものでした。

こうした議論への巻き込み・巻き込まれも、現実のオフィスで話をしていれば自然と加われそうなものですが、Google meetでミーティングを行っているとそうはいきません。結果として議論に積極的に参加する者は仕様理解とともに自分事としてプロダクト開発を捉えてくれますが、そこから外れた人にはどうしても疎外感や、与えられたものを自分はやれば良いという受託業務感が生まれてしまいました。

これではまずいと思いインセプションデッキ作りをリモートで開催してみましたが、職種横断で17人も集まると、やはり喋る人と喋らない人の濃淡が出て来るものです。いまいち自分事にし切れないまま時間を無為に過ごしてしまった人もいたように感じています。

全般を通じて、ルールがまだ作られていない組織の中で、リモート環境下でルールをお互いに合意しながら作っていく作業は困難を極めました。また、EMの立場としては雑談ができないのはやはり結構な痛手でした。皆さんよくやると思うのですが、席のうしろを通りかかったときに、「お、今どの辺書いてるの?」とディスプレイを覗き込んだり、トイレに立ったときに遭ったら軽く趣味の話をしたり。こういう雑なコミュニケーションから関係構築することができない環境は、キツいものがありました。これをやるために1on1を作ると仰々しくなるし、大人数でのミーティングのアイスブレイクでカバーできるものでもありません。

こうした課題感を持ちながらも、解決できずに数ヶ月を過ごした開発スクラムチームは、ベロシティの安定しない、カンバンでチケット進捗を追うだけの集まりになっていました。

EMのスクラムへの関わり方

そんなチームに対して、これではいかんと思い取り組んだのがまず下記の2つでした。

  • 毎朝 9:00に開発環境への定時デプロイ
  • スクラム朝会の司会

「えっ、EMがそんな泥くさいことやってるの?」と思われる方もいらっしゃるかもしれませんが、本チームにおいては私はここを担当しています。そして、割と成功事例だったなと思っていたりもします。

ビルドアップ中のチームは、とにかくペースを掴むのが難しいんじゃないかと思っています。スクラム的に言うと、健全なベロシティがどのぐらいなのかがチームとして共通認識に落ちていなかったり、業務にあたる時間帯も稼働曜日も違うメンバーが集まっているので、各々がどういうレビューの振り方や催促の仕方をして良いのかを見極めようとしている最中でした。 この状態のチーム内で、メンバーに快適に開発に専念してもらうためEMが担える役割は、「ペースメーカー」なのではないかと思いました。

freeeカード Unlimitedのスクラムは、PM+UX+Eng+QAから成ります。社内で「アジャイルQA」と呼ぶ手法で開発を行っており、これは機能実装のスプリントと並行して、実装完了したストーリーチケットレベルでどんどんQAを行うという手法です。この開発フローをうまく回すコツは、

  • QA可能な開発環境にできるだけ細かいピッチで最新のWebアプリを乗せること
  • 機能実装を行うWebアプリエンジニアとそれをテストするQAエンジニアに、常に同等程度の負荷が掛かっている状態を維持すること

だと過去の開発から学びました。

忙しいチームとヒマなチームのバラ付きがある状態
忙しいチームと暇なチームがあると効率が悪い

スクラムチームのWebアプリエンジニアの始業時間はだいたい11時です。比してQAチームメンバーの始業は10時やそれより早い人もいます。開発環境へのWebアプリの定時デプロイをWebアプリエンジニアに任せるとなると、どうしても「日」の単位がズレたり、タイムラグができてしまいます。スクラムにとってこれは致命的なので、このギャップを埋め、継続的開発の形を作ることが重要ポイントだと思います。

9時台にデプロイを回すと、前日にWebアプリエンジニアが開発完了した機能を、翌日の10時からQAすることができます。こうすることで、一つ一つのストーリーチケットの完了までのライフサイクルを最短にすることができます。この役割を私が担うことにしました。

ラグが無くアプリ開発とQAが繋がっている図
無駄なくアプリ開発とQAが繋がっている

スクラム朝会のファシリは、このデプロイを担当する流れで私が担当することにしました。 日次でデプロイを行っていると、開発に参加していなくてもチケットの動きがよく把握できるようになります。 常に大事にしていたのは「誰の、どのチケットがQA inしたか」という意識を持ってワークフローを回すことでした。「誰の、」が肝です。 この意識を持ってボードを毎日見ていると、「大物の完了お疲れさま」「バグチケットの対応ありがとう」のようなメンバー個人に対するレコグニッションが行いやすくなります。また、スクラムに埋もれがちな滞留しているチケットの把握にも役立ちます。朝会でそうした滞留チケットを持ったメンバーには「何か困り事あるんじゃない?」という声掛けもしやすくなりました。

新規プロダクト開発における朝会は、必ずといって良いほど延びる傾向にあります。加えて、油断するとメニューもどんどん増えがちです。私がファシリテーションをするうえで意識し続けたことの一つに、「なるべくコンパクトに、15分で終わる朝会を維持する」という要素がまずありました。こうなると司会進行の能力が試されます。議論が長引きそうなら途中であっても切り上げて、別のmtgを作って続きをやるように促す。枝葉に目が行き本来の議題からズレた時に無理矢理引き戻す。会話のキャッチボールが途切れたらバイネームで発言を求める。こうしたコントロールは、出来たてのチームに於いては年長者が強権を持って行うのも正解なんじゃないかなと思います。 また、「今日は金曜だからキリの良い所まで頑張って良い週末を迎えよう!」「明日でスプリントが終わるから、今日はレビューを優先しよう」のような声掛けをするようにも心掛けていました。チームのペースメイクをするうえで、曜日や今日がスプリントの何日目かっていう感覚は大事だと思うんですよね。こうした声掛けは少なからず、1週間のスプリントが平らな一本の線から円に変わり、そして反復が始まる助けになるんじゃないかと思っています。

スプリントが線の連なりから円の連なりに変わる
スプリントを「線」のイメージから「円」のイメージへ

それはまるで・・・

こうした私の役割って例えると何なんだろうな?と思ったときに最初に浮かんだのが、公園のブランコで小さな子どもの背を押す母親のイメージでした。ブランコの漕ぎ出しって、小さな子どもって出来ないんですよね。重い物を動かす時もそうですし、自転車の漕ぎ出しなんかもそうだと思います。車のエンジンやエアコンも動き始めに大きなエネルギーが必要だと聞きます。動き始めの労力・コスト、そうしたものをEMが引き受けることで、そのビルドアップ中のチームを、早く一定速度に乗せることができるんじゃないかと思います。

また、「漕ぎ続ける難しさ」もあると感じています。実は一定のペースで動き続けるのって難しいんですよね。「お、上手く回ってるぞ」と感じて慣性に任せてしまうと徐々に減衰して行くし、気持ちが前のめりになっている時は速く回りがちで、逆にチームに慢性的な疲弊感が見えてくると速度は自然と落ちてしまいます。こうしたチームの状態をスクラムの一歩外から見守って、必要最小限の「外力」を注ぐのが私が意識して担った役割でした。時に背中を押し、時にブレーキをかけて安全にブランコを漕ぎ続ける。そんな「子どもの笑顔を守るために、ブランコの後ろに立つ母親」のイメージがぴったり合いました。

どの速度をこのチームの一定値として良いかがまだ定まっていない初期構築中のチームに於いては、メンバーのスキルセットや一人一人の噛み合い方、チームバランス、そうしたものを観察しながら、ストレスレスに長期で回り続けられるスピードを決める必要もあります。こうした領域にはどうしても感覚知のようなものが必要なので、たくさんのチームを見てきた経験豊富なEMが請け負うことで、良い結果につながる事も多いんじゃないかと思う次第です。

まとめと次回予告

その役割ってスクラムマスターじゃないの?と思う方もいらっしゃると思いますが、そこまで厳密にスクラム運営にコミットはしていません。リファインメントは別の者がオーナーを持っているし、レトロスペクティブもまた別のメンバーがファシリをしています。こんな中途半端な役割には呼び名が無いので、「ペースメーカー」がしっくり来ました。

この役割を私が地道に持ち続けたことで、・・・かは分かりませんが、スクラムチームのベロシティは徐々に安定し、リリース予測も立てられるようになっていきました。スクラムにもリズムが根付き、「この3ptチケットは今スプリントでシュートさせたいので、レビュー早めに対応してください」のような発言が朝会で生まれるようになりました。また、日次で行っていた開発環境へのデプロイも、先日晴れてチームに委譲しました。 このチームには、もう母の手は必要無いようです。

冒頭の繰り返しになりますが、EMはまだまだ役割に一定の規定が無く、同業の皆さんも、常に探りながら・迷いながら業務を行っていらっしゃるのではないでしょうか。実際に私も第3回のエントリーを執筆した元EMのtabachainからは、毎日のデプロイを担当したり、CI/CD周りの整備をEMがするっていう発想はなかったので驚いているという感想をもらったり、第4回のエントリーを投稿した中途入社のluからは、前職のEMに比べてかなりスクラムの中に入ってきているし、実装コードも把握しているという話を聞いたりもしました。それで良いんだと私は思います。チームを一人の人格と捉えるなら、その人格と正面から向き合い、足りないものを補い、あるいは時には引っ張り上げて成長を促す。そんな臨機応変に献身的に動く役割がfreeeの「ジャーマネ」であり、EMの一つの解なんじゃないかと最近思うようになりました。

さて次回は、SREとしてfreeeカード Unlimitedのインフラ構築を担当したrenjikariが「クレジットカードのインフラ作ってみた」と題して基盤側のお話をしてくれます。新規プロダクトはしがらみが少ないので、freeeの中でもモダンなインフラ構成になってます。どうぞお楽しみに!

developers.freee.co.jp


金融チームでは、一緒に「freeeカード Unlimited」を開発する仲間を募集しています。 ベンチャー企業であるfreeeの中でも更にスタートアップ色が強い金融チームで、スモールビジネスの資金繰りにイノベーションを起こしましょう! https://freeecommunity.force.com/jobs/s/detail/a4l2r000000CaUpAAK

※本エントリーで利用した写真はフォトポケットさんからお借りしました。ありがとうございます。