新卒二年目から、顧客との要件整理や進行の調整を担うことになった。 肩書きだけ見ればPMに近い。 けれど、最初から全体を動かせたわけではなかった。
私がいたのは、日本の顧客とベトナムの開発チームが協働する環境だった。 顧客の曖昧な要望を開発できる形に分け、認識のずれを見つけ、必要な人に相談する。 早い段階で求められたのは、強いリーダーシップよりも、分からないことを放置しない手つきだった。
技術の下地が、会話の入口になった#
PMが実装をすべて担う必要はない。 それでも、技術的な制約を知らずに約束をすると、顧客にもチームにも負担をかける。
学生時代に、Webサイトを作ったり、自然言語処理を扱う卒業研究をしたり、基本的なコンピュータサイエンスを学んだりした経験が、最初の会話の入口になった。 入社後の研修で、サーバーを立て、小さなアプリをクラウドへ載せるところまで試したことも同じだった。
重要だったのは、知識を持っているように振る舞うことではない。 エンジニアの説明を聞いたときに、どこが分からないかを具体的に言えることだった。
早く任されたからこそ、相談の単位を小さくした#
初めて正式に引き継いだ案件では、問題を大きくしてしまった。 自分で収束させなければならないと思い込み、相談が遅れた。 結果として、顧客への説明もチーム内の調整も後手に回った。
この失敗以降は、相談を「正解をもらう行為」ではなく、状況を早く共有する行為として扱うようにした。
- 事実として起きていること
- 自分がまだ判断できないこと
- 次に影響しそうな相手と期限
この三つを分けて渡すと、相手も助け方を選びやすい。 相談すること自体が、プロジェクトの不確実さを小さくする作業になる。
役割より先に、次の判断を整える#
経験が浅い時期は、PMらしく見せようとして背伸びをしがちだ。 しかし、役割の名前は顧客の不安を減らしてくれない。 次に誰が何を決めるかが見えているときに、プロジェクトは前に進む。
会議で結論が出なければ、決まっていないことを残す。 依頼を受けたら、完了の条件を確認する。 分からなければ、分からないままにせず相談する。
地味だが、この繰り返しが技術的な会話への自信にも、顧客との信頼にもつながった。 若いうちに大きな役割を任されたときほど、一人で背負わない設計が必要になる。
