1
/
5
Wantedly
About スタディサプリ
スタディサプリ
https://brand.studysapuri.jp

東京都

【Quipperブログ】新メンバーが多い大型プロジェクトでの不確実性との戦い方

鈴木あかねさんのプロフィール
鈴木あかね
人事
on 2019/07/08

こんにちは。Quipper採用担当の鈴木です。今回の記事は、Engineering Managerの@ohbaryeによる「新メンバーが多い大型プロジェクトでの不確実性との戦い方」です！是非、ご覧ください！

ペアプロ・モブプロ、スキルマップ、1-on-1等々… チーム開発にまつわる各論・方法論・話題をよく見る昨今、関心の高まりは歓迎さるべきことながら

  • つまるところそれらが現実のどのような問題を解決していくのか？
  • どのように相互作用するのか？
  • これらが有機的に結びつくことで現実のどのような問題を解決していくか？

こうした疑問に答えたり、具体例とともに記した記事はさほど多くないのではと思います。

本記事では昨年度に筆者のチームが約7ヶ月携わったプロジェクトにて、プロジェクト特性に起因する不確実性と我々がいかに戦ったかを記します。チーム開発を行う方にとってこの記事が実りあるケーススタディとなれば幸いです。*1

なお、本記事では以下のことは本旨とは逸れるため割愛させていただきます。

  • プロジェクトの機能的側面
  • 技術的不確実性
  • 各取り組み単体の詳細

はじめに / プロジェクトの雰囲気を伝える図

この記事で説明する内容を1枚の図にまとめてみました。

思ったより記事が長くなってしまったため、忙しい方向けに本記事の"本質"を先んじて述べます。それは、以下の当たり前に見える事柄をしっかりやっていこう、ということになります。

  • チームの置かれている状況、プロジェクトの特性を見極める
  • 各特性がどのような課題・不安・不確実性を生むのか見極める
  • それぞれの不確実性に対してどのような打ち手が有効かを考え、実行する

とはいえこれだけでは「何が何やら」という感じだと思うので上図をベースに解説していきます。

プロジェクトの特性

このプロジェクトの特性は弊社においては比較的「大型」で「新メンバーが多い」というもの。具体的には以下のような状況でした。

  1. 大型
    • 開発者9人で7ヶ月 *2
  1. 新メンバーが多い
    • 7 Web Engineers
      • うち4名はプロジェクト初期から中盤に入社
    • 1 iOS Engineer
      • プロジェクト中盤に入社
    • 1 Android Engineer
      • プロジェクト開始時点で入社半年

この二要素だけを見ればありふれた開発プロジェクト、ありふれた現場に見えるのではないでしょうか。 もしありふれたものだと感じられるような、類似した状況にいる方にとっては本記事はケーススタディの一つとして役立てられるのではと思います。

どういった課題に繋がるか？

では上述した特性がプロジェクトにどのような課題や不安をもたらすのでしょうか。

ここでは直面した課題を3種類の"不確実性"の分類を用いて表現します。*3

  1. 目的不確実性
    • プロダクトがマーケットに受け入れられるか分からない不安
    • 低減することでプロダクトの定義した成功に近づく
  1. 通信不確実性
    • コミュニケーションにまつわる不安
    • 低減することで相互理解が促進され、伝達コストが低下し、他人が期待した行動を起こして成果をあげる確率が高くなる
  1. 方法不確実性
    • どう作れば良いのか分からない不安
    • 低減することでスケジュール、スコープに関する予測可能性が高まる

それぞれについてより詳しく述べます。

1. 目的不確実性 / デリバーに時間がかかるほど増大するリスク

一般的に、アイデアが形になり市場に届くまでに時間がかかるほど目的不確実性を抱え込むことになります。

最初に捉えた要求が間違っていれば間違ったものを頑張って時間をかけて作りこんでしまいます。正しく課題設定ができてもリリースする頃には市場が変化してしまっていたり、競合にスピードで負けてしまうリスクがあります。*4

つまりリリースまでに時間のかかる大型案件は初めから目的不確実性とリスクを内在させており、この案件はまさに"それ"でした。

2. 通信不確実性 / 効果的なチームになるまでのコスト

エンジニアリングチームがただ人が集まっただけの"グループ"ではなく、成果を生み出すにあたって効果的な"チーム"になるにはある程度の時間と労力が必要です。 *5

そして「新メンバーの比率が高い」とき、その集団においては情報の非対称性*6が高く、これを解消するための時間的・人的コストが増大します。

時間的・人的コストの具体例を挙げるなら以下のようになります。

  • 効果的なチームであるための重要な土台である心理的安全性や相互信頼を新メンバーとの間に築くためには相応の時間が必要*7
  • オンボーディング・教育のコストがかかる
    • 社歴の長いメンバーがメンターになりやすく、一時的にチームの総アウトプットが低下する
  • アウトプットが予測しづらい状態が一定期間続く
    • 一般的にソフトウェアエンジニアが環境を変えたあとに本来の実力を発揮するのはおよそ3ヶ月〜半年かかると言われている*8

3. 方法不確実性 / 未来の予測可能性の低さ

最後の方法不確実性は「大型」と「新メンバーが多い」の二要素の複合により生じるものです。

たとえ目的を適切に設定できたとしても、アウトプットが予測できないチームが大量のタスクを前にしてゴールに到達できるか？という不安・不確実性があります。

（聞いているだけで胃が痛くなるような話ですね）

不確実性を低減するアプローチ

上述した不確実性に対してどのようなアプローチを有効と考えて実践したのか。まず第一にProduct Managementの領域とEngineering Managementの領域を分割するところから始めました。

正しいものをつくるために / 目的不確実性の低減

同プロジェクトではここはProduct managementの領域とし、Product Managerや事業に責任を持つService ownerに以下の活動に取り組んでもらいました。

目的不確実性の低減、以下のアプローチで顧客やマーケットに関する知識を増やすことが有効だと知られています。

  • リーンスタートアップ
  • MVP仮説検証

なお、このプロジェクトにおいて目的不確実性をいかに低減するかを実践した記録がユーザーに求められるプロダクトをムダなく作る方法 〜スタサプ新サービスをリーンに開発した話〜ですので、ここでは詳細は割愛します。本記事と合わせて読むと味わい深いと思います。

チームで正しくものをつくるために / 通信不確実性の低減

ここから先はEngineering Managementの範囲と考えて取り組んでいったことです。ただし、 筆者が全てを実行したわけではなくほとんどのアクティビティは各メンバーが主体的となって取り組んでいってくれたものです。私が指示するでもなく、物事がひとりでに進んでいって大変助かりました！

それぞれの取組についてコメントしていきます。

チームメンバー同士のトレーニング文化の醸成 / Working Out Loud

チームとして成果を出していくためにはまず何よりもチームメンバー内でのコミュニケーション不安を減らし、新メンバーが爆速でキャッチアップ・スキルアップをしてもらう土台を作ること、それに既存メンバーが効率的に寄与できることが大事と考えました。

とはいえLead EngineerやEngineering Managerといったチームの元々の中心メンバーがずっと新入社員のメンターをしているような状況ではスケールしないし、再現性が低くなってしまいます。新メンバー同士で教え合うような動きも生まれにくい。そこで私たちのチームはチームメンバー同士のトレーニング文化の醸成を図りました。

当時に筆者が書いた記事が『Working Out Loud 大声作業（しなさい）、チームメンバー同士でのトレーニング文化の醸成』です。作業の可視化と共有を全メンバーが心がけることによりコラボレーションが促進され、成果達成のためのアクションが自然発生することを期待してこの観念を意図的に広めました。

今ではすっかり組織文化として定着したと思います。*9

:working-out-loud:
reactionをつけられた発言が自動的に集まる #working-out-loud channel

この結果として…と一概に言うのも厚かましいですが、以下のような非常に面白い行動が次々と起こりました。

  • チームメンバー各自が自分の行動をSlackのスレッドで呟きながら作業を進める
  • 困ったときに即座にヘルプを求める
  • チームメンバーの作業内容に割って入ってアドバイスをする
  • 自然発生的にペア・モブワークが生まれる

ペアプロ・モブプロの推進

また、Working Out Loud（作業の可視化・共有）が極まった状態であるペアプロ・モブプロをチームにて積極的に実践していきました。

推進にあたっては、弊チームで最も英語が堪能でモブ活動に強い関心があった @motorollerscalatron に『Code with the Wisdom of the Crowd』 (Mark Pearl, 2018) を読んでもらい、得られた知見の共有と実践を一任しました。*10

GitHub issueにて知見共有するようす。彼のアイコンと表紙の一致は偶然かはたまた運命か

「ペア・モブをやりましょう」と一口に言ってもそれぞれが普段からバラバラのタスクを行っていると、一足飛びには振る舞いを切り替えられないものです。そのため、タスクは人に対してアサインするのではなくペアやモブのチームにアサインするという形を実験的に取ってみたところ、半強制的にペア・モブが生まれることになりました。この挑戦によりペア・モブ活動が促進された面もあるのではないかと考えています。*11

モブ活動を通じて新メンバーに技術・ドメイン知識の共有が促進されていくのみならず、既存のメンバーがこれまで避けていた苦手領域を新メンバーと一緒に克服する動きが起きるなどの素晴らしい体験もありました。また、リソース効率性にフォーカスしたアサインになりがちだったのがフロー効率性への傾倒に挑戦する機会にもなりました。 *12

モビングの実践にはこうした成功だけでなく失敗もありましたが、それはまた別の記事で紹介できればと思います。

スキルマップの運用、期待合わせ会 / チームに必要なものとお互いを知る

スキルマップの運用、期待合わせ会についてはすでにチームメンバーが記事を書いてくれているためここでは参照先を標すにとどめます。

これらを通じてプロジェクトのために必要なスキルの確認、チームのトランザクティブ・メモリーの構築、チーム全体でクロスファンクショナルであるかどうかの確認ができました。

また、お互いに弱みを見せられるチームになったおかげか、各自が苦手な領域を克服する取り組み（ペアプロや勉強会など）を自発的に行う場面もありました。

1-on-1を通じた関係づくり

プロジェクトに新しく参加したメンバーからすると誰も知り合いがいないという状況だったため、関係性を構築するために筆者が全員と1-on-1を定期的に行いました。頻度は人によってまちまちでweekly, biweekly, monthlyでした。

1-on-1と聞くと「組織図上のmanager/subordinateの関係で行われるもの」というイメージを持たれる方もいるかもしれませんが、今回は組織図は一切関係なく職責もまたいで全員と実施しました。

効果的だったかどうか？ですが、定期的な雑談の中で本質的な問題が見つかったり、最初は1-on-1でしか取り上げていなかったことがチームでの振り返りで話されるようになってきたりしました。

また、1-on-1の中でAndroid Engineer, iOS Engineerの方から「Web Engineerと距離が遠い」とのフィードバックがあり、全員とのランチをセットしたりしました。 *14

方法不確実性の低減

自分たちの実力を測るものさしとしてこのプロジェクトではスクラムを導入しました。チームにスクラムの知見がある人はあまりいなかったのですが、Quipperの他チームでの実践事例をもとにトライしてみることにしました。スクラムの実践に関しては多くの先行事例があるのでここでは多くは触れません。

先述してきた活動が繋がり、クロスファンクショナルチームとしての面白い動きがありました。

  • Android EngineerがWeb EngineerとペアプロしてRailsのAPI開発に取り組む
  • Web EngineerがiOS Engineer, Android Engineerと協力してReact Nativeでのモバイル開発に取り組む

スキルマップ・期待値合わせ・Working Out Loudの積み重ねが築いた土台の上に、チームで新しいスキルを獲得できる環境が構築できてきた証左ともいえるのではないでしょうか。

また、スクラムによって開発チームの実力が見え、将来の予測が立つようになったことでスコープやフィーチャバッファの調節を行うことができました。プロジェクト以前のスクラムをやっていなかった頃に比して、方法不確実性への対処が格段に上達したと感じています。

得られた成果

結果としては2019年4月に無事プロダクトをリリースすることができました。

また、リリース時点でのチームの最終状態としては以下のようになれたのではないかと思っています。

  • 心理的安全性があり、プレッシャーもあるラーニングゾーンにいる
  • ペアプロ・モブプロを通じてチームメンバー同士で教えたり学んだりすることが日常の一部である
  • クロスファンクショナルで複数のプラットフォームに価値を提供できる

反省 / 満点なんて、あるわけない

さて、ここまで万事快調良い話のように書いてきましたがその実、失敗と反省すべき点も多々あります。チームの反省と個人の反省を分けて記したいと思います。

チームの反省 / 失敗も、混乱も、あるんだよ

何がチームにとって理想なのか、理想に至るための最大の課題は何なのかをプロジェクト中に深く掘り下げていなかったことです。本記事で何度か紹介した図はプロジェクトの最中にぼんやりと筆者の頭にあったのですが、具体的に言語化して「こういうところを目指すぞ！」というのをチーム内で決して上手くは共有できていませんでした。そのせいで本質的ではない打ち手もありましたし、チームがどこに向かっているのか混乱するシーンも多々ありました。

次に、予測可能性を高めるために運用したスクラムですが、リリース直前にプロジェクト外からの差し込み案件が増えて混乱する事態がありました。差し込み案件を担当する別チームを一時的に作る対応をしたのですが、ベロシティが乱れたりチームとしての目標がぶれたりとネガティブな問題も起きました。このあたりは経験値がまだまだ足りないところです。

また、クロスファンクショナルチームではあったものの、モバイルエンジニア（iOS, Android）が1名ずつしかいなかったために相互にレビューができなかったり、議論の中心がWeb Engineerになることが多くありました。言い換えるとチームの職能ごとのパワーバランスが悪い状態でした。あと1名でもT字型のスキルを持つ人材を育てるべきだったかと思ったりしています。いや、オレがそうなっているべきだったんだよ。

個人的な反省 / あたしって、ほんとバカ

第一に言える最大の個人的反省は、私ことEngineering ManagerがIndividual contributorとしての成果にしばらくこだわってしまったことです。

プロジェクトの中盤はスクラムマスターとエンジニアリングマネジャーとプログラマを兼任するような形でした。コア部分の実装を自分が終えることでプロジェクトのリスクを減らせると考えていたのですが、他の方に任せていればもっと仕組みの改善に時間を使えたはず。そのうえ他の方の成長機会を奪ってしまった可能性もあります。さらに、採用活動などプロジェクト外の活動とも並行していたのでそれぞれの役割に徹しきることも振り返ってみれば出来ていませんでした。オレが3人分になる…！と言っておきながらこのザマであり、深く反省しています。

モブプロ推進・スキルマップ・期待合わせ会などのアクションを自発的に行えるメンバーがいなければもっと悲惨なことになっていたのは間違いありません。

そうした問題を自覚したプロジェクト後半では思い切って実装タスクを持たないようにし、Product Ownerとのスコープ調整やスクラムマスターとしての動きに徹しました。

これ以外にも、モブ推進を頑張ってもらったにもかかわらず筆者がコーディングから離れたためにモブれずぜんぜん恩恵を受けてないということや、定性的に「良くなった」と評価しているが良さを計測していないために定量的にチームの状態を示せないことなども反省としてあります。

終わりに

本記事では新メンバーが多い大型のプロジェクトで生じた不確実性・課題と私たちのチームがいかに戦ったかを紹介しました。

スキルマップや期待合わせなどは個々の実践単体でも味わい深いものの、こうした試行錯誤が有機的に繋がることで生まれる組織文化や挑戦があります。それらが間接的にせよ直接的にせよ、成果に結びついていったのだ…ということがお伝えできたでしょうか。

改めて、この記事が我々と同じくチーム開発をする方の一助になれば幸いです。

Engineering Managerの仕事とは

ちょっとした余談です。

実はこの記事の裏テーマとして「QuipperにおけるEngineering Managerの仕事を伝えたい」という意図を筆者は込めました。「Engineering Managerの仕事は成果最大化」などとよく言われるものの、具体的に何をするのかイメージできない、という声もよく聞きます。たしかに成果最大化のためにできることは実質無限にありますし、抽象度が高いものも多いです。例えを挙げるなら以下のようなものたちです：

  • プロジェクトやプロダクトを多角的に見つつ情報や知識を整理して本質的な課題・リスク・障害物を特定する
  • 問題を分解して個別に解決可能にする
  • 有効な打ち手と思われるアクションを実験的に行い、検証する（実行はチームメンバーであることも多い）
  • 行ったアクションの再現性や、成果の持続性があれば成功とし、なければ失敗として棄却する
  • 上記の繰り返し

こうして並べてみるとどうでしょうか。本記事で解説した内容の骨子とかなり一致するのではないでしょうか。

このサイクルで起こすアクションの中にはまさに「設計」（＝ある問題に対して解決策となるような構造を与える活動*15）と呼べるようなものもあります。構造を規定することで課題が解決したりそもそも生まれないようになったりします。設計がうまくいく＝誰かが頑張らなくても仕組みで解決できている状態ですので、Engineering Managerの仕事としては究極ココを目指したいと常々思っております。

また、たとえ筆者のようなポジションが不在でも今回のプロジェクトはメンバーの力により完遂できたと信じていますが、不確実性の特定と対処に取り組む存在がいたことで少しでも円滑に進んだというフィードバックがあれば冥利に尽きます。

最後の最後に所信表明。筆者は前の半期は本記事で紹介したような「1チーム内の開発プロセスに焦点をあてた活動」が中心でしたが、今期はさらに複数チームを見たり非開発者も含めた構造を変えに行くところをやりつつ隙を見て技術的な課題への取り組みも増やしていく所存です。オレは3人分になれないということがわかったので、一つずつ、ね…。

本記事はEngineering Managerの@ohbaryeが執筆しました。

末筆ながら、Quipperでは本質的な課題・リスク・障害物を特定したのちに分解して個別に解決可能にしたい方を募集しております。そのうえでさらに有効な打ち手と思われるアクションを実験的に行っていったり、行ったアクションの再現性や成果の持続性をもって成否を判断したい方にもおすすめです。

https://career.quipper.com/jp/

===== イベントのご案内=====

2019年7月18日(木)に、TECHPLAYにてスタディサプリ/Quipper Product Meetup #3 を開催します。今回のテーマはSREで、以下４つのセッションをお届けする予定です。

  • Observability in StudySapuri
  • Canary release - フレームワークのアップグレードを安心して進めるためのリリース戦略
  • gRPC in スタディサプリ ENGLISH
  • CQRS+ESをKinesis,Spark,RDB,S3でやってみた

皆様のご参加をお待ちしております。詳細/お申し込みは https://techplay.jp/event/737389 をご覧ください！

*1:今回はプロジェクトをある程度一般化して書いているため、似た状況にいるチームは少なくないと思います。とは言え会社・チーム・環境など様々な変数によって最適解はすぐに変わってしまうのであくまでご参考までに、ということを初めにおことわりしておきます。

*2:世間の大多数のプロジェクトと比べると小規模なほうだとは思います。しかし、このプロジェクト以前は筆者のチームでは3名で長くても1ヶ月の案件をこなしていたので、それに比べると相当大きいものでした。

*3:この3分類は『エンジニアリング組織論への招待』にならっています

*4:余談: 教育サービス/プロジェクトの特性について。

「7ヶ月近くかけて開発するなんてアジャイルでもリーンでもないな？」「そもそも小さく作れば不確実性が小さくなるよな？」と思われた読者もいるかもしれませんのでそのあたりのdisclaimerです。

我々が開発するサービスは教育ドメインを対象にしている都合上、非常に季節性が高いプロダクトという特性があります。年度の切り替えにあたる3月〜5月に申し込みのピークが来て、それ以降はゆるやかになります。

また、メインユーザーである中高生の学習サイクル・生活スタイルも年度（fiscal year）に密接に結びついているため、年度始まりに最高の学習体験ができるよう、そのタイミングに向けて新商品や機能を作り込むというスタイルが多くなります。（もちろん作る機能や提供する商品によってはMVP検証やA/Bテストを行ったりもします。e.g. A/Bテスト事例: https://quipper.hatenablog.com/entry/2018/05/31/080000 ）

*5:チームとグループの違いについては『チームとグループの違いとは―チームワークをよくしたいなら、まず「理想」を共有しよう』を参照

*6:ベテランメンバーは知っているけど新人は知らないことが多いとか、新人視点で違和感を感じることにベテランメンバーが気づかない、など。

*7:本記事において心理的安全性とは"「無知、無能、ネガティブ、邪魔だと思われる可能性のある行動をしても、このチームなら大丈夫だ」と信じられる"状態を意味します。　https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/steps/identify-dynamics-of-effective-teams/ より

*8:この情報、何かの本か記事で読んだのですが出典を忘れてしまいました…。体感ともさほど離れておらず納得感あったので頭に残っています。もしご存知の方がいたらご教示いただけると幸いです。

*9:組織文化とは > 「ある特定の集団が外部への適応や内部統合の問題に対処する際に学習した、集団自身によって創られ、発見され、また発展させられた基本的仮定のパターンであり、それはよく機能して有効と認められ、したがって新しい成員にそうした問題に関しての知覚、指向、感覚の正しい方法として教えこまれるもの」『組織文化とリーダーシップ』より。これは同僚の@kecholに教わりました。Thanks!

*10:2019年6月時点では邦訳された『モブプログラミング・ベストプラクティス』が出版されていますが、プロジェクトの当時2018年は原著で読むしかありませんでした。リアル「あ〜あの本なら"原著で読んだ"」事案、かっこいいですね。

*11:こうしたやり方に「は〜い2人組つくって〜」的な居心地の悪さを感じる方もいるかもしれません。あくまでチームの間で「まぁ誰と組んでも大丈夫だろう」とゆるく思えるぐらいの信頼関係があることが前提です。

*12:フロー効率性とリソース効率性について

*13:余談ですがチームメンバーの @chiiia12 に「@ohbarye (筆者) の頭の中を知りたい」と言われたことがこの記事を書くことになったきっかけの一つでもあります

*14:正直いうとこうしたソーシャルグルーミングはEngineering Managementの本質ではないと思っているのですが、こうした活動をまずは当たり前にしていこうと思い実施していきました。最近では筆者がこうしたことに気を配らずとも、オンボーディングのプロセスに「チームメンバーみんなと一度はランチに行く」というようなアクティビティが含まれているので盤石です。

*15:『マルチパラダイムデザイン』より

スタディサプリでは一緒に働く仲間を募集しています
開発秘話 エンジニア 日常 チーム開発 Team
9 いいね！
9 いいね！

ブログ

スタディサプリに関わるメンバーによるブログです

もっと見る

同じタグの記事

#エンジニア
もっと見る

今週のランキング

ランキングをみる
鈴木あかねさんにいいねを伝えよう
鈴木あかねさんや会社があなたに興味を持つかも