「できる。できない。条件付きでできる」をちゃんと言えるかどうか。〜PMの学び〜

中規模なWeb開発のプロジェクトに参加している。

この規模の案件にメインで携わるのは初めてだし、エンジニアとしてもとてもいい経験になっています。

そもそも今回はPMに近いポジションにいる。（エンジニアとしては手を動かさない）
ここは学びの宝庫かと思えるような環境です。

今まで私が携わったり、リードしていた開発では基本的に「自分の知識の範疇でしか請負わない」というスタンスでした。

今回は自分の知識領域だけでは足りないので、ちゃんとしたエンジニアチームで動いている。

ベテランPMから学ぶ

毎回の会議、毎日のチャットで学びが多すぎてパンクしそうですw

正直私はPMできるほどの器じゃないし、知識もないと思ってます。
それでも今回は元請けとしてやらなければならないので、大先輩にPMをお願いして、それを間近で見ています。

そこで学んだ一つのことば。

できるかどうかと言えば、できます。
ただし納期と予算を考えたら、他の機能とトレードオフになります。

これを常にハッキリ伝えている。

自分でマネジメントどうしてもクライアントの要求に応えようとしてしまう。
クライアントにとっては「いいPM」かもしれないが、エンジニアにとっては「馬鹿なPM」、プロジェクトにとっては「最悪なPM」になるんじゃないかなと。

それをスッパリと経験と事実に基づいたことを言えるPMは優秀だと思った。
その場しのぎではなく、プロジェクトをリリースまで持って行くために必要なことだ。

全ての会議には予め決めるべきことがある

中規模なプロジェクトでは、要件定義の段階でかなり頻繁にクライアントとやりとりをすることになります。
定例会議ですね。

直接言われたわけではないけど、PMの動きや開発チーム内でのやりとりで

毎回の会議では「決めるべき（決めなきゃならない）ことを明確かつ端的に伝えて決める」という意識がないと無駄な時間になる

これは本当に走り出しフェーズでは重要です。
要件が見えてこないと、開発が開始できないばかりか開発工数が出せず金額の見積もゆるゆるなのままになってしまいます。

時間内で決めるべき事項を決めるために、こちらが「この会議ではこれを聞き出す、これを決める」を、準備の段階で明確にして、それをクライアントから引き出すための準備をしなければなりません。

サービスの大枠を聞いて、要件に落とすのはPM、設計をするのは開発チーム

要件定義フェーズでは、会議の中で「要件をクライアントと決めて行く」というイメージがありました。
しかし、それって無理な話なことが多い。

なぜならクライアントはエンジニアリングは全くわからない

からです。

やりたいことは決まっているから、「どんな」サービスにしたいかはあります。

この「どんな」の解像度は開発チームがするものとは全然違い、もっともっと解像度が低い。

実際に開発に進むためには、さらに詳細なところまで詰めていかなければならないが、そこをやるのはPMや開発メンバーの経験と知見によるものです。

クライアントの意図を汲んで、それを要件に落とすのはPMであり、その要件をどのような方法や技術で実装するかは開発チームが考えていくのがよい。

そう考えると、クライアントとのミーティングの中で「要件」を決めるのではなく、やりたいこと、実現したいことを汲み取っていく。
ここで細かく技術的なことを決めても仕方ないんですね。

それを要件に落とし込んで、次回に共有する感じ。

クライアントはどんな技術やプログラムを使って作るかには興味はない。「やりたいこと」が実現できてサービスとして動いていればそれが正義

曖昧にしない

質問に対しての回答が曖昧になることが多い。
その場で判断したくないこと、持ち帰って熟考したり、調べたりする必要があることも多々あります。

そこで曖昧な回答をしないことが後に開発チームを救う。曖昧に答えた内容がクライアントに「これはできることなんだ」と認識されたら、「できるって言ってたじゃん！」と後々になって言われたりしますから。

誤解を招くような話し方はしない。明確に相手に伝わる言葉を考える。これが大事だし、持ち帰って判断する必要があることは、それをハッキリ伝えないと大火事になるんですね。

私くらい未熟だと、50%くらいの確率で持ち帰りたいことが発生します。
そんなときに、グダグダ説明や予想を話さずに、

持ち帰って次回回答します！

ってするのが重要。

そして、

• できる

• できない

• できるが工数と予算がかかる

• できるが他の機能とトレードオフになる

をちゃんと伝える。ここでは特に「曖昧にしない」が大事です。

クライアントの要求はマストなのか、できたらやってほしいのか、なんとなくあったらいいなぁと思って言ったことなのか。

金をかけるか、納期を後ろ倒しにするか、他の機能とトレードオフするかというところをクライアントに判断してもらうのが1番。

できないものはできない。しかし条件次第ではできる。

曖昧にしないで、ハッキリ判断させるのが大事なんですね。

まだまだたくさん学んだことはありますが、今回は今後自分がPMをする上で最も大事にしようと思った教え・学びを記録しておこうと思い書きました。

余談

今回プロジェクトをお願いした大先輩は

案件を炎上させたことがないんです。
クライアントとは常に対等を心がけるし、無理なものは無理といいます。
そして、なんとなく「焦げ臭いなぁ〜」って直感が働くんですよねw その瞬間に問題点や疑念を見つけて、火消ししますから！

とのこと。
すごいなぁと思いつつ、これなら単価高いこともうなづけるなぁと妙に納得しました。

まだこのプロジェクト、先が長いですが、学べるところは全て学ぶつもりでやっていこうと思います。