この記事は YAMAP エンジニア Advent Calender 2021 3日目の記事です。

YAMAP開発チームのカオルコです。

今年の8月からプロジェクトリーダー兼フロントエンド開発者として奮闘していました。今回はそこで得た学びを振り返ってみたいと思っています。  かなり抽象的なポエムになりそうです。  

どんなプロジェクトなの？

私が参加しているプロジェクトでは、ビジネスサイドの理想や目標を達成するために、どのようなHOWをやっていくか、主に開発チームで検討するスタイルをとっています。

渡された仕様書通りに実装するのではなく、エンジニア自らがものづくりに参加できるのはかなりわくわくする環境です。

参加しているのは探索的かつ実験的なプロジェクトであり、目標数値が明確でないことが多いです。また、部署の縦割りもゆるやかで「できることはできる人がやる」というtheベンチャー風土があるため、いろんな面で不確実性が高く、自分には少し背伸びしたプロジェクトだと思います。

チームメンバーにフィードバックをもらったり、1on1で壁打ちしてもらったりして学んだ、6つのことを書いていきたいと思います。

1. ミーティングは準備が8割

「たくさんミーティングをしているのに、なぜか前に進んでいない気がします」

これが一番初めにもらったフィードバックでした。ミーティングで大事なのは、アジェンダとゴールを明確にしておくことだと思います。ただ、それだけでは不十分なのだと気づきました。ゴールに辿り着くために必要なものは何か、ステップ数はどれくらいになるか、ゴールまでのプロセスを想像することも重要なのだと思います。

YAMAPの開発プロセスはかなりデータドリブンで、データなしにディスカッションすることはほとんどありません。意思決定するために十分なデータを用意して、事前に自分なりの考えをまとめておくことを学びました。叩きがあるとゼロベースより議論がしやすいです。

また、あらかじめデータや考えを共有しておくことも大事です。時間を有効活用できますし、足りない情報を指摘してもらえたりします。

2. スケジュール調整の落としどころを考える

予定通りに開発が進んでいたとしても、思いもよらぬところでハプニングは起きるものです。ユーザーさんへの周知や他部署との調整、社内からの熱烈なフィードバックなど、プロダクト開発は、実装してリリースするだけではありません。

関係者を明確にしたり、リスク管理をしておくことはもちろん重要なのですが、何かあった時に最善の落とし所を見つける冷静さを持っておくことが大事なのだと思います。

ちょっとぐらいなら無理をきかせて、計画通りにやりたくなっちゃう気持ちもありますが、リスクが見えたら、冷静にスケジュール調整を検討するのが良いと思います。本当に、つい走り切りたくなっちゃうのだけど。（若干体育会系マインド）

スケジュール通りに進むことが大切なのではなく、ハプニングは起きる前提で、丁度良い落としどころを見つけるために調整していくことが大事なんだと学びました。

3. 「ご近所さん」を探せ

ソフトウェアの開発手法であるアジャイルの中に、インセプションデッキというドキュメント作成のフレームワークがあります。

これはプロジェクトの全体像（目的や背景など）を端的に伝えるためのものです。問いに答えていく形でドキュメントを作成していくのですが、その中に「ご近所さんを探せ」があります。簡単にいうと、自分たちを中心に、プロジェクトに関わる人を図式化するものです。わたしはこれを軽く扱ってしまっていて、他のチームに少し迷惑をかけてしまいました。

自分たちにも都合があるように、他のチームにも都合はあるものです。はじめに関係者を洗い出して明確に言語化しておくと、早い段階で展望を伝えておくことができるし、リスク回避にもなります。助け合いもできます。ご近所付き合いは大切です。

4. 目的と同じくらい目的じゃないことが大事

目的を明確にしておくことは何事においても大事なことです。そして、目的に対して「どこまでやるか」も重要な論点の一つです。

もし「目的じゃないこと」を決めていなければ、議論はどこまでも発散していくと思います。アイデアは縦にも横にも広がり、その一つ一つに意見が飛び交い、コミュニケーションにかかる時間は増え、意思決定の難易度はぐっと上がります。  

最初に目的じゃないことを定義しておくことで、議論のスコープが明確になり、より目的に集中できることを学びました。

目的と目的じゃないことの言語化はプロジェクトメンバー全員で行いましたが、良い取り組みだったと思っています。一言一句レベルで定義を話し合うことで、小さな違和感の擦り合わせがかなり上手くいったと思います。

5. すぐに解決しようとしないこと

わたしはかなりせっかちです。何かしらの問題報告を受けると、「では、こうしましょう」とすぐに解決してしまいたくなります。

社内・社外問わず、仕様に対してたくさんのフィードバックをいただきますが、それはどんな問題なのか、その問題は誰のものなのか、よく考えもせず場当たり的に解決してしまうのは、よくないです。というのも、解決策には新たな問題をはらんでいることが大いにあるからです。また、問題だと思っていることは、実は問題じゃなかったりもします。

解決するのではなく、問題定義をすることが重要なのだと学びました。そして、問題定義に正解はありません。やってみて、違ったなってなることもあります。なぜ違ったのか、本当の問題は何だったのか、どこまでも向き合い続けることが大事なのだと思います。

6. 自分の役割のひとつ外側からプロジェクトを見る

これは先輩にもらったアドバイスなのですが、プロジェクトやチームの見え方がかなり変わるものでした。  アドバイス以前にも無意識にやっている部分もあったと思いますが、漠然と客観視していたものが、ひとつ外側の視点を決めることで、より精度の高い客観視になった気がします。

プロジェクトリーダーの外側にはPdMやプロジェクトの戦略メンバーがいます。自分がPdM・戦略メンバーだったらプロジェクトをどう見るか、実際に自分の頭で考えてみることがすごく重要なのではないかなと気づきました。自分の動きも変わるだろうし、外側とのコミュニケーションがスムーズになります。  

プロジェクトリーダーは調整役をすることが多いので、この視点は常にもっていたいと思いました。

まとめ

こうやって言葉にしてみると、ごく当たり前のことを書いている気がします。当たり前のことを当たり前にやるのって、難しいですよね。（当事者として、プロジェクト進行のさなかにいると特に）わたしだけでしょうか。

学んだことを完璧に実践できてはいないけど、自分のものにするには、トライアンドエラーを繰り返していくしかないと思っています。毎日かなり頭を使って本当に大変です。  大変だけど、プロダクトと一緒に成長していけるのは嬉しいことです。

最後に、いつもオープンな議論・フィードバックをしてくれて、あたたかく見守ってくれるチームメンバーに心から感謝しています。ありがとうございます。

余談）思ったよりコーディングする時間が取れない問題

プロジェクトリーダーと開発者を兼務していると、コードを一行も書いてないのに気づいたら夕方、みたいなことがざらにあって、妙に焦りを感じます。空いた時間はまずコードレビューを優先するので、コアタイム終わってからが本番なのだけど、その頃にはHP0になってたりします。

世のプレイングマネージャー的な人たち、どうなってるん・・・？