Eureka Engineering
Published in

Eureka Engineering

プロジェクトを “前に” 進めるためにやったこと 2021

これは Eureka Advent Calendar 2021 21日目の記事です。

こんにちは。Eureka でサーバーサイドエンジニアをしている emahiro です。エウレカでは主に Go を使ったサーバーサイドの実装と担当プロジェクトの TechLead としてプロジェクトを推進する仕事に従事しています。

この記事では技術的な内容ではなく、TechLead としてプロジェクト進めていくにあたって幾つかトライしたことについて記載しています。

なお、冒頭から話が少しそれますが、OGP 画像に指定した集合写真はプロジェクトチームで撮ったもので、僕が担当してるチームはこんな感じで出席者の半分以上がアバターを常に纏ってます。個人的にもリモート環境下でもアバターだと動きがあって “そこに人がいる” 感を感じるのでもっとアバターコミュニケーションが広がってほしいなと思っています。

話を元に戻して、ここからが本題です。

前提

まずこの文章を読むにあたっての前提としてエウレカの TechLead の役割とエウレカの抱えていた課題について説明します。

TechLead の役割

エウレカの TechLead は一般的な TechLead の役割とは異なり、主な役割はプロジェクトの “実行と推進” になります。もちろん技術的な意思決定に一定の裁量は持っていますが、エウレカは横断組織として専門職能チームが存在するので、より具体的な技術選定はそちらで行ってもらうことが多いです。僕自身もプロジェクトを進めるにあたって、大まかな方針(どんな設計にするか、SaaSを使う場合は何を使うか?など)については決めつつも、より具体的な実装については職能チームの意思決定に任せて、プロジェクトの推進に関心の多くを割いていることが多いです。

そのため、この文章においてはTechLead の役割が “実行するにはどうするのか?” が関心事にあることに留意してください。

エウレカで抱えていた課題

僕はエウレカに入社して1年半くらい経ちますが、プロジェクト推進する上での課題として、プロダクトの要件をどうマネジメントするのか?Product Managerが全然つかまらない ということがありました。

1. プロダクトの要件管理がされていない問題

まず、1つ目の課題についてです。正直これが全てと言っても過言ではないです笑

プロジェクトを進めるにあたって、やらなければならないことが都度増えてきたり、やりたいことが変わったり、そもそもの制約が変わったりすることは頻繁にあることだと思います。これらが変わることに対してネガティブな見解もよく目にしますが、不確実性が高い領域でプロジェクトを進めている以上、あるプロジェクトを遂行する中でもそのタイミングに応じて必要な条件や制約は変化しますし、変化するのが当たり前だと思っているので、僕自身としては要件が変わること自体はネガティブなことだとは考えてません。特に Pairs をはじめとしてエウレカが主戦場としている事業領域は非常にセンシティブな領域でもあり、都度状況が変わることは今でもしょっちゅうあります。

また、エウレカには Sincerityという行動指針が存在しており、ユーザーやパートナー様に誠実に向き合いながらプロダクトを作っていくことが求められているので、ある程度必要な条件があとから増えても対応していくことが求められますし、それがエウレカでのプロダクト開発の面白さの1つでもあります。

しかしながら、その根本となる必要な条件(=要件) をどうマネジメントするのか?ということについては、プロジェクトごと、チームごとにやり方がバラバラでいろんなところで要件や仕様をまとめたドキュメントが二重で存在したり、そもそも Slack 上で会話されているだけで明文化されておらず、「あれどうなってたっけ?」というのがすぐに見つけられない、チームで合意が取りづらく、それプロジェクトの実行のボトルネックになっている状況が存在しました。

僕が配属されたプロジェクトでも、少なからずこの課題は発生していたため、まず 要件をどう管理するのか? ということと この要件はなぜ存在するのか? という背景をスナップショットでもいいので “残すこと” から着手しました。

2. Product Manager 忙しすぎ問題

次に2つ目の課題について説明します。これはリソースの問題も絡んできて最終的には Hiring などにも範囲が及ぶのでスコープを狭めて話を進めます。

エウレカの事業領域は上記の通り非常にセンシティブなものであり、PdM に求められる業務の幅も多く、様々なステークホルダーと関係しながらプロダクトを作ることが求められます。PdM はミニ CEO と呼ばれることもあるのでこの辺りについてはエウレカに限った話でもないのかもしれませんが、コロナ禍における WFH の定着も相まって PdM が日中ずっとどこかしらの Zoom にいて全然会えない、という問題が発生しました。

Slack でメンションを飛ばしても非同期で仕事をしてる以上すぐに返ってくることは期待できませんし、期待してもいけません。返事がなかったから何も進まなかった、ということはどうしても避けたかったので、ある程度 TechLead として決められることは決めてしまう、後から報告して PdM とすり合わせて多少の手戻りは許容する、と言った方針でプロジェクトを進めていくことにしました。

“前に進める” ためにやったこと

上記の2つの課題を解消してプロジェクトを前に進め、プロダクトをユーザーに届けるためのスループットを上げるために以下のことを行いました。

  1. TechLead の役割の明文化を行う。
  • PdM のやらないことを全てやる。
  • Mini PdM として現場での意思決定を担当する。

2. コミュニケーションのインターフェースを統一する。

  • ドキュメントのフォーマットを統一する。
  • PRD の導入
  • 集まるときは集まる。

3. 運用前提で作る。

  • 運用チームが使えるように作る。
  • SaaSで済むところは SaaS で。
  • 会社の用意してくれた環境は大いに利用する。

1. TechLead の役割を明文化し発信する

これは去年の TechLead になった時に担当するプロジェクトのメンバーとPdM 向けにスライドを作って公開しました。

PdM 捕まらない問題を解消し、かつ当時の PdM は技術出身ではなかったので最初は以下の2点をベースにPdM をサポートしてい行きました。

  • PdM がやらないことを全てやる
  • PdM と現場のエンジニアの通訳になる

2020年 はこれで回してみて、実際にプロダクトの体験のキーとなるところ以外の実装に関わるところや仕様の細かい調整、関係各所との技術的なやりとりは全部自分で巻き取りつつ eKYC をはじめとした機能やその改善をリリースしていくことができました。

ただ、2021 年は プロダクト開発全体として大きな変化があったので、PdM がさらに忙しくなりほんと1日のうち一瞬でも捕まらなくなってしまったので、基本的に会社の定めたロードマップに則ったプロジェクトに関する必要なことも含めてある程度 TechLead が仕切ってまとめ、PdM と細かいところを擦り合わせる、という方式に変えました。

同時に 2021 年度版の TechLead の役割には メンバーの実行をサポートする という役割を追加しました。これは 2020年後半からプロジェクトの推進そのものに関与する時間が増えてしまい、エンジニアとしての具体的な実装に関わることに手が回らなくなってきたことと、エウレカでは現場レベルでの積極的な「越境」の文化があるので、職能を跨いでコミットしてもらうことはむしろ歓迎されることでした。具体的にはプロジェクトチームに Front-end も Back-end もかけるメンバーがいたので、もう1人の Front-end のメンバーに Go 書いてもらうためにサポートを依頼したり、Back-end の開発方法についてのナレッジのシェアを僕が行ったり、あと、職能チームの長にちょこっと話通したり(怒られるかと思った)実行に関わることで越境が発生する場合にサポートをすることで、TechLead の手を空けつつ、プロジェクトの進行には影響が出ないようにしました。ちなみに空いた時間でステークホルダーとの調整とか、仕様考えたり、後述する PRD を書いてたりました。

TechLead としてここまではやるよ!とあらかじめ公表しておくことである程度の情報が集まってくること、および細かいところの進行は PdM とすり合わせが行えれば特に勝手に進めていくことに問題はない合意が取れたので、この辺りは PdM がボトルネックになって進行が遅れる、ということは少ないプロジェクトになったのかと思います。

2. コミュニケーションのインターフェースを統一する

プロジェクトを進めるにあたってコミュニケーションの必要性は誰も疑う余地のないことかと思います。しかしコロナ禍で定着した WFH の影響で同期的なコミュニケーションを前提としてスループットを担保することに依存するのは難しくなった(※1)と感じており、非同期を前提としてスループットを落とさない、また、埋もれがちな要件のこぼれによる手戻りを少なくすることが必要だと考えていました。

実際僕自身も去年の春先から原則 WFH になった(※2) ときに、同期的なやりとりを前提している場合、どこかはわかりませんが、きっとどこかでブロッカーが発生して、それはおそらくコミュニケーションに依存するポイントで発生しそうだなーという感覚があったので、既に存在していた要件のマネジメントへの改善も兼ねて、 ドキュメントをベースにしたコミュニケーション をチームの軸にすることを決めました。そして、チーム全体として誰が書くか、で残されたドキュメントの書き方にブレが生じ、読み手に負荷がかかることを避けるために、ドキュメントのフォーマットをある程度統一しました。

※1. 僕自身は同期的なコミュニケーションに価値は感じており、できるなら同期的に、さらに言えば不確実性が高い物事にアプローチしているチームであればあるほどオフラインで仕事をした方がスループットは上がると思っています。しかし、それを強制はできないので同期的なコミュニケーションに依存せずに、スループットを上げる可能性があることはできるだけやろうよ、というスタンスではいます。

※2. 現在は現職では WFH 強制は緩和されており、週一程度の出社推奨を前提としたハイブリットワークスタイルとなっています。

ドキュメントフォーマットを統一する

ここではフォーマットとして PRD という仕組みを導入したことについて記載します。

Product Requirement Document の導入

エウレカに存在した要件や背景のマネジメントの課題を解決するために、WFH 開始当初からまずはどういう状態が望ましいのか考えて、いくつかのアイテムをこなしながら、以下のような状態になると上記で示したような課題は軽減され、プロジェクトを前に進めるスピードは加速するのではないか?という仮説を持つに至ってました。

  1. 要件とその背景を記載したドキュメントを用意すること。
  2. そのドキュメントはワンソースでプロジェクトに関わる全員が見れること。
  3. ドキュメントのフォーマットを決めること。

これらの状態に近づけるためのツールや手法は世の中にいくつか存在すると思いますが、僕が担当していたプロジェクトでは PRD (Product requirements document) を導入して運用していくことに決めました。

なぜ PRD を選択したのかというと、僕が前職で PRD を実際に使っており、どういうものか知っていて運用方法も覚えていたのもあって、導入が比較的容易だったからです。また PRD のフォーマットについてもいくつか流派がありますが、僕は及川さんが書かれた 『ソフトウェアファースト』に記載されているフォーマットが使い慣れた物だったので、これとほぼ同じ物を使っています(前職のフォーマットそのままなのですが…)

後述しますが、これが2021年後半には全社で使われるようになり、様々なプロジェクトでコミュニケーションの Hub として機能し始めており、チームによっては上手く項目をカスタマイズしたり、以下の Atlassian が公開してるドキュメントに沿った構成にしてるチームもあります。

プロジェクトないのアイテムが始まる前にこのテンプレを用意し、プロダクトの要件をリードする立場の役割のメンバーが記入していくような運用を行いました。ただし、PRD はプロジェクト、およびプロダクトに関わるメンバー全員が記入できるものであるのでもあるので、都度メンバーに記入してもらったり、また QA メンバー(※1)や運用に関わるカスタマーサポートのメンバーが読んでわかりづらいところはコメントもらうようにしました。

ただ導入当初から 誰が更新するんだ という問題は発生するとわかっており、これはドキュメント運用の宿命と思っていたので、原則としては PdM に依頼しつつも、実際にプロジェクトやプロダクト開発が走ってる最中は上記の PdM 忙しすぎる問題があったので、TechLead がほとんど責任持って作成・更新を担当してました。もうこの辺は覚悟を決めた 筋肉運用 で成立させていましたね。既存のプロジェクトメンバーの負荷を軽減するために一時的に僕が全ての負荷を負った格好になります(まぁ長続きはしなかったので少しずつ改善していきました。)

正直僕自身の作業時間が取れずしんどかったこともありますが、自分の作業時間の確保状況とスケジュールを照らし合わせてメンバーに業務を移譲(時には越境)をしながらかろうじてスループットを維持してました。自ら移譲しないとやってられない状況を作り出してしまっていたので、これは結果的には良かったと思います。作ったプロダクトの運用方法を考えてもらったり、細かい仕様の調整などは実装に関係するメンバー間でいい意味で 勝手にやってもらって 僕や PdM はあとからすり合わせに参加するくらいでした。

※1. PRD に記載された機能要求をベースにしてテストケースが作られるのが理想だからです。

PRD の全社展開

僕が担当していたプロジェクトで小さく始めた PRD の運用でしたが、たまたま運用が別チームのメンバーの目に止まって、徐々に別プロジェクトへの導入がされていきました。

これは実際に PRD を書くようになってから機能のデプロイ頻度が向上したこと、またメンバーが入れ替わっても、スムーズにプロジェクトで扱うプロダクトの概要や進め方に慣れていたことが、他チームの振り返りやシェア会等で共有されていたかららしいです(僕は当時知りませんでした。)

現在では、進行中のプロジェクトにおいて大きなアイテムであればあるほど、PRD を作ってから進めることが習慣化してますし、最近整備されたプロダクト開発フローの中でも、PRD を書くことがステップとして組み込まれる、までに広がりました。

ちなみに広げる方法も全部ドキュメントにまとめておきました。運用のサンプルや参考資料、 FAQ まで添えたそれなりに量の多いものを気合いで作ってしまいましたね。笑

PRD 課題とこれから

とはいえ、現状これを書くことには一定慣れが必要なドキュメントでもあるので、本当はプロジェクトに関わる全メンバーに書いて欲しいところですが、実装作業にフォーカスしてもらうことも必要であったりすること、またどうしても要件を決めたり、調整に出るのが PdM や TechLead に限られてしまっていたり、そもそも知ってる情報にどうしても差が生まれてしまうことに起因して、プロダクトをリードする役割が運用者として固定されがちで、ここの役割の作業時間が肥大化してしまう(ボトルネックになってしまう)という課題は残っています。

僕自身、機能要求を一度決めたとしても、日々変わる要件や実装してみてわかってくる要件や仕様の漏れに追従して機能要求を更新していくのがしんどくなってしない、たまに更新漏れが発生してしまったこともあります。ここについては、エウレカではグループウェアに Whimsical、プロトタイムツールに Figma を使っていたりするので、現場レベルで日々変わる内容については Whimsical や Figma でやりとりしてもらい、決まった結果のみシェアしてもらうようにしました。要は要件レベルで調整が必要ない、プロダクトの実装に関する部分については自由に決めてもらうスタイルに移行した形になります。この点はエウレカでは任せていても問題ないアウトプットが出てくるメンバーが揃っているので何も心配することはありませんでした。むしろ、決められるところは決めてもらったほうが僕も関心事を減らせて良かったです。

ドキュメントの運用と機能要求の鮮度を常に保つ問題に関しては、後者は一定改善することができましたが、前者はまだ残っています。個人としては PRD で重要なのは背景とユースケース、そして製品原則であり、少なくとも “なぜそのプロダクトを作るのか?””そのプロダクトはどう使われるのか?” そして “そのプロダクトはどういう振る舞いをするべきなのか?”、 についてはプロダクトに関わる全メンバーが書けるようになって欲しいし、そうしていくべきなのかと思っています。

PRD はあくまでツールであり、あくまで非同期で動いてるメンバー間でプロジェクトを円滑に進めるために作っているものなので、プロダクト開発チームに限らず、マーケチーム(※1)なども含めプロダクトに関わる全てのプロセスに組み込んで行きたいなと思っています。

※1. 最近知ったのですが Marketing Requirement Document (MRD) というものもあるらしいですね。あんまりちゃんと調べてないのですが。

集まるときは集まる

WFH においてある程度非同期でもチームとしての合意が取りやすい型みたいなものは土台として用意してましたが、とはいえある時間とってオンラインでも顔を合わせる機会を大事にしたかったのと、なんだかんだ言っても集まって話すことをいっぺんに話したりした方がプロジェクトとしても効率が良かったので、Daily Standup や Weekly での振り返りは特段理由がなければ “集まるだけ集まって” 何か話してました。

特に良かったなと思うのは “毎日やること、そしてスキップしないこと” だったかなと思います。MTG は忌避されがちですし、ない方が生産性には寄与することはもちろん事実だと思いますが、そこは個人の生産性に一定の制約を設けることを合意してチームとして決まり事としてワークさせていました。話すことが少なければ共有と進捗確認だけして解散!ってこともありますし、プロジェクトの抱える制約や仕様についてその場で考えたり意見を出し合う機会としてもうまくワークしてくれました。この辺は時間いっぱい使う時もあれば使わない時もある、やることある時はじっくりやるし、ない時はぱっと集まってパパッと雑談して終わり!のようなメリハリをつけることは意識してました。無駄に長いMTGとか時間いっぱい何かするみたいなことは僕も嫌なので。 あと、毎日行うっていうのがミソだなと考えていて、理由は2、3日に1回だと、定例まで議題溜めておいてしまう問題が発生して、結果認知が遅れる問題が発生する可能性がありますが、とりあえず毎日集まっていればその時間に最新の状況をチェックできるのでチームとしても健全な状態を保ちやすいと思いました。もちろん、急ぎの話があればいつでも連絡もらうようにはしてました。

またチームでは週一で振り返りを実施しており、これも特段理由がないかぎりスキップしませんでした。(流石に長期休暇前後で有給取得推奨日にかかってたりする時はスキップしましたが)
これは余談ですが、振り返りは木曜日か金曜日に設定すると毎週行うことができます。なぜなら月曜日は祝日の振り返りに被るケースが少ないのと、休み多すぎるで有名なエウレカにあっても月曜日を休みにする人は多いですが、金曜日を休みにする人は僕のチームではそんなにいなかったからです。

多少制約を設けることにはなりますが、集まる時には集まる決めておくと言うのを決めておき、安易にスキップしたりしない方が WFH 環境の世界線においては大事なんだなと思います。別に議題がなければないで、集まって即解散!でもいいわけで。そして集まった時に適当に生まれる雑談とか地味に貴重な時間だったりするんだなと、会を運営してて感じました。僕がいるチームにはたまにVR空間の宮下パークにいたり、謎の水族館にいたりするメンバーがいたのでそんなことでも軽い話のタネになるのはとてもありがたいことでした。

3. 運用前提で作る

何かを作る時に作り方や凝りたいポイントはエンジニアなら無限に出てきますが、目的はプロジェクトを前に進めることで凝り性すぎると目的を達成できないと考えていたことと、エウレカでは予想以上にエンジニアが手を動かして頑張ってたポイントが多かったので、この手を離せるように運用から考えて、プロダクトを作ることは当初から意識してました。

具体的にはエンジニアがまとまった工数を取らずとも運用が成り立つ設計 (ex. API のレスポンスでUIを出し分けるよう) にしたり、 SaaS を取り入れて、SaaS の運用自体は別の運用チームに任せてしまうと言ったことを実行していきました。

SaaS に関してはエウレカでメインストリームで使用するサービスがいくつか決まっていたこともあり、要件が許す限りは SaaS でできることの範囲でプロダクトの仕様を決めたり、スピード重視で作って手運用が残ったりと言ったことを極力避けるようにしてました。余談ですが、僕個人の思いとしては SaaS にできない要件は “原則切る” 交渉をする、くらいの姿勢でいたりします。(その立場で交渉してぶつかった結果、本当に譲れないものが真の要件になると思ってるので。)

もちろんこの SaaS に乗っかっていく過程では、その使い方を運用チームに共有する必要があるので、開発だけなく運用ドキュメントを残してもらったり、ハンズオンによる運用手順のシェア会といったこともチームのエンジニアメンバーに協力してもらって実施しました。開発以外のタスクがメインになる時期もあったりする中、こういったことを快く引き受けてくれたメンバーには感謝してます。

その他、社内で広く使われてるツールをチームとしては使うことを推奨するなど、プロジェクトを進めるにあたって自分たちで考えないといけない範囲をなるべく小さくするようにしました。なぜなら、新しいツールやサービスを使おうとする姿勢はもちろん大事なのですが、そう言ったツールやサービスはアカウント管理やアカウントを持ってない人は見れず、使うまでに必ず招待 → 登録という1クッションを挟むことになることが個人的には無駄な時間だなと考えていたからです。特に Daily Standup など限られた時間でチームとして集まってる以上、誰かが見れない!→ 別の人が画面共有する、みたいなことに使う時間はもったいと考えていたこともあり、文章として残すことが必要なものは、入社タイミングから全社員が見れるツールとして Confluence と GSuite があったのでこちらに統一し、プロダクト開発に関わるスコープにおいては Whimsical と Figma 絞って仕様なり設計なりを残してもらうようにしました。

ステークホルダーが多いプロジェクトの場合には、”それを閲覧する/できる” というところが最初のハードルだったりするので、スコープに応じてツールを選択することは合意形成のスピードに直結すると思います。こう言ったプロダクトそのものには関係ないところで生まれてくるちょっとしたストレスも、最初から運用されることを前提に構築することで少しは軽減できるかなと思いますし、この辺りの制約を設けることも事前に TechLead の役割を表明した時に書いていたので、事前に合意をとっておく、というのもチームやプロジェクトの運用には欠かせないなと思いました。

SaaS にしても社内で決まっているツールを使うにしても、早く前に進むために多少の制約を受け入れつつ、自分達が楽できるために使えるものは基本的に取り入れていく “巨人の肩に乗っていく” スタイルにしたことで、細々したストレスや余計な作業が減り、その浮いた時間で冒頭記載した職能チームごとのタスクをしてもらったりと、他チームへのポジティブな影響もあったのではないかと思います。

プロジェクトを “前に進める” = 道路整備 & 全方位ボール拾い係

かなり駆け足でしたが、ここ 1 年半でやってきたこと大まかにをまとめたら案外すごい文章量になってしまいました。
これ以外にもいくつかやっていたこともありますし、現在進行形で進めていることもあるのでそれはまたどこかで書ければと思います。

ここまで書いてきましたが、この1年半僕がやってきたことというのは、ユーザーに提供する価値とプロジェクトに関わるメンバーのスループットが最大になるように、ときにはコードを書き、ときにはミニ PdM となって各種調整、要件決めに奔走しながら、同時にベースとなるコミュニケーションに関わる道路整備とこぼれそうなボールを拾い続けてきたことなのかなと思います。

月並みな言葉ですが、プロジェクトを進める、さらに言うと物事を前に進めるのは結局のところ “人” なのでそこで働く”人”たち が気持ち良く動けるようにならないと結果としてプロジェクトは前に進まないことを学べたことも今年1年の自分の収穫でした。

エウレカのものづくりの仕方はここ1年で大きく変わっており、まだまだ至らぬ点( = ボールがこぼれ落ちそうなポイント) がたくさんあります。このボール拾いを一緒に楽しくやってくれる仲間が1人でも増えてほしいと思ってるのでぜひエウレカに興味が湧いてきた方はお話しさせてください。流行りの Meety 開こうかなと思ったんですが、管理がめんどくさいので Twitter で DM かリプくだされば、爆速でスケジュール調整して zoom のリンクを送らせていただきます。

ここまで読んでいただきありがとうございました。
それではみなさん良いお年を〜 👋

--

--

--

Learn about Eureka’s engineering efforts, product developments and more.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Hiromichi Ema

Hiromichi Ema

Gopher worked at Eureka, inc.

More from Medium

Visceral: How to start a product

Design to test, or how I learned to stop worrying and love product ambiguity

Product Tonic Lab Meetup #1 — Anatomy of a Meetup

Guide to User Onboarding in SaaS Products