いきなりPMになった1年目に何からしたか：自社プロダクトと協力会社

いきなりPMを任されて、何から手を付ければいいのか。入社前から、自社プロダクトの開発とPMをお願いすると言われていました。個人開発なら、したことがありました。でも、本格的なシステム開発も、何人かで作るチーム開発も初めてでした。

私の場合の答えは「順番に片づけた」ではなく、PM（顧客対応）と開発を同時に始めた、です。要件はすでに固まっていたので、設計フェーズから入りました。技術は、仕事で必要になったものをその都度覚えて、そのまま使いました。

では、技術が分からないままのPMは、社内や協力会社のエンジニア、TLとどう話せばよいのか。そして、要件が決まっているのに、最初の顧客とは何を話すのか。この2つは、入社直後の私がまさに立っていた場所でした。

チーム開発もPMも初めて。何が分からなかったのか

当時の私は、整体師を5年やったあと、39歳でITに戻ったばかりでした。ネットワークエンジニアの経験はあっても、アプリ開発は初めてです。

覚えることはたくさんありました。GitHubの使い方、フロントエンド、バックエンド、フレームワーク。正直に書くと、フロントエンドとバックエンドの違いも最初は分かっていませんでした。

そこに、チームで作るという初めての形が重なります。社内と社外の協力会社を合わせて、数名のエンジニアやTLがいました。私はその人たちと、どうやって作っていくかを話し合う立場にいました。

分からないのは、技術だけではなかったんです。

技術の分からなさと、チームで進めることの分からなさ。いきなりPMを任された1年目は、この2つが同時に来ている状態なのだと思います。どちらから片づけるかを考える前に、両方が目の前に来ていました。

何から手を付けたか：順番ではなく、同時に始まった

要件はすでに固まっていました。なので、私が入ったのは設計フェーズからです。何を作るかではなく、どう作るかを決める所から始まりました。

最初の3か月、まず手を付けたのは、要件資料を確認して、不明な部分を確認することでした。

そしてPM（顧客対応）と開発は、最初から同時でした。PMに慣れてから開発、でも、開発に慣れてからPM、でもありません。始まりから両方です。

技術は、まとめて勉強し直したわけではありません。業務のあとも自主的に仕事の開発を続けて、必要になった技術をその都度学び、そのまま実践しました。ほかの人が作っていたバックエンドに手を入れて、テストコードが足りずにCIに止められたのも、戻ってすぐのことです。

そもそも、5年離れていた人が、なぜ入社直後からPMと開発を任されることになったのか。

今、案件を掛け持ちしている日の優先順位の付け方もあります。リリース日（納期）、調整が必要なこと、ボトルネックになる所、他人が絡む所は先にやる。自分で完結してコントロールできる所は後に回す。

チームで作る以上、これは1年目のPMにも当てはまる考え方だと思います。

では、この「人が絡む所を先に動かす」癖は、どこで身についたものなのか。

技術が分からないPMは、協力会社のエンジニアやTLとどう話したか

チームには、社内のエンジニアだけでなく、協力会社のエンジニアやTLもいました。技術については、私のほうが分からないことの多い立場です。

社内のもう一人のメンバーは、開発経験が豊富なエンジニアでした。担当はレイヤで分かれていて、私は個人開発でも実装していたブロックチェーンのレイヤ、社内のエンジニアはバックエンドと管理画面側、協力会社のエンジニアはフロントエンド側です。

フロントエンドとバックエンドの違いも分かっていなかったので、会話をしながら、どういう仕組みなのかを少しずつ理解していきました。技術的な部分は、社内のエンジニアに色々質問しながら深めました。協力会社には関連システムの構築をしてもらっていたので、何をどう作るかは、打ち合わせをしながら決めていきました。

そこで効いたのは、積極的に話しかける、分からないことは聞く、無理なことは話して調整する、という、とても基本的なことでした。整体院で人と向き合ってきた中で身についたもので、入社してからそのまま効きました。

技術が分からないPMにできるのは、分からないことを抱えたまま進めないことです。

一方で、聞くのとは逆向きの難しさもあります。頭の中にあるだけのことを人に伝えるのは難しく、伝えるための資料を作るのにもコストがかかります。関わる人（ステークホルダー）が多くなるほど、調整には時間もコストもかかる。

自社のエンジニアと協力会社のエンジニア、TL、そして最初の顧客。この間に立つのが、入社直後の私の仕事でした。

要件が固まっていても、最初の顧客とは話し続けた

自社プロダクトでの相手は、これから最初の顧客になる人たちでした。要件はもう固まっていました。それでも設計は、その人たちと会話をしながら進めています。

要件が決まったら、あとは作るだけ。そう思いたくなりますが、私の場合はそうではありませんでした。

気をつけていたことの根っこは、整体院にいたころと同じです。顧客が求めていることと、こちらができることには、ずれが出ることがあります。そのときに大事なのは、落とし所を探すことと、それをきちんと説明することでした。

ただ、最初の顧客だった当時は、とにかく要望をかなえることを意識していました。今ならQDCを意識したうえで、やるやらないを判断できると思います。でも当時は、顧客が言っていることは全て受け入れる気持ちで進めていました。

作る人と使う人の間で、話をつなぎ続ける。要件が決まっていても、その仕事はなくなりませんでした。

受託PMから見て、自社プロダクトのPMは何が違うか

今の私は、受託の案件でもPMをしています。金額も人数も違う案件を、いくつも掛け持ちしてきました。

受託の5,000万円の案件では、提案が実際のシステムや運用と合っておらず、要件定義に落とすまでの顧客との調整に長い時間がかかりました。顧客は最初、支払っている金額に対してどうなるのか、とコストを気にしていました。

では、案件の規模や関わる人の数で、忙しさはどれくらい変わるのか。

入社直後の自社プロダクトでは、要件はすでに固まっていて、相手は最初の顧客になる人たちでした。私が持った受託の案件では、相手は発注した顧客で、5,000万円の案件のように金額の話も出てきました。私の経験から言える違いは、まずこの入り口の形です。

同じだったこともあります。顧客と作る人の間に立って、分からないことは聞き、無理なことは話して調整する。これは自社プロダクトでも受託でも、そのまま要りました。

人に任せる難しさも、受託で味わいました。後輩に指摘事項を伝えても、修正することを明確に指示しないと正しく伝わらず、明後日の方向に修正が進んで手戻りが多くなりました。

受託でPMやPLをしてきた人なら、顧客とエンジニアの間に立つ経験は、自社プロダクトに移っても使う場面があるはずです。

では、採用する側は、PM経験のどこを見ているのか。

入社前の私と同じ場所にいる人へ

入社前に、自社プロダクトの開発とPMをお願いすると言われたとき、私はチーム開発も初めてでした。それでも、設計から入り、PMと開発を同時に始め、分からないことは聞きながら進めてきました。

何から手を付ければいいか分からないのは、技術とチームの分からなさが同時に来ているからかもしれません。全部を覚えてから始めなくても大丈夫だと思います。私の場合、聞ける相手はチームの中にいました。