横断PjMを任せられたら意識したいこと
これはなに
筆者 (@tk3fftk) がかつて、多部門横断のPjMをいきなり任され、PJが一段落したあとに「こうやればよかったな～」とふりかえった結果のまとめです。
多かれ少なかれ、人は自分の所属する組織の枠を越えたProjectを任されることがあると思うので、この記事が誰かの参考になれば嬉しいです。
※ Product Manager と区別するため、Project ManagerをPjMと表記しています。モノやサービスを指すProductではなく、明確な期限内に何らかのアウトプットを出す行為であるProjectを対象としています。
まずは要件を確認しましょう
要件が定義されていない場合は、PJ内で検討する必要があります。
定義されている場合も鵜呑みにせず確認する必要があります。
「定義した要件を前提に進めて問題ないかどうか」を判定する権限がある人を探して確保しておきましょう。
方針を確認するとともに、後でひっくり返されないよう言質を取る目的があります。
直接の関係者だけでなく、上長やアーキテクト、その他ステークホルダーと認識をおくことも必要かもしれません。
相談しましょう
リモートワークがある程度当たり前の世の中、ということもあり、周りに相談しにくく、周りからもあなたの状態が分かりにくい、という状況が発生しやすいです。
PjM自身で考えることも必要ですが、詰まったら経験豊富な周りの方々を頼りましょう。
(一方で、相談しやすい雰囲気づくりや、相談する機会を設けたりは、PJを依頼する側の責務でもあると思うので、気をつけていきたいですね…！)
定例ミーティングについて
定例ミーティングを設定する場合は、予定をなるべく早く確保しましょう。
期初であれば比較的他の人の予定が定まっていないのでチャンスです。
「とりあえず集まりましょう」という思考を捨てましょう。
その場で議論したい議題がなければ非同期でのやりとりに切り替えたり、必要な人だけ集めるなど、できるだけPJメンバ全体のミーティング負荷を減らしましょう。
レビュー依頼について
PJ内で何らかのレビューを依頼する際は、下記の点を明確にして依頼しましょう。
レビュー期限
レビューの観点
レビュアーに期待すること
レビュー対象がドキュメントの場合、利用するツールによってはコメントに対する返信やアップデートに気づきにくいため、レビュー状況を可視化する工夫ができるとよいかもしれません。
不確実性の高い問題を優先的に片付けていきましょう (「エンジニアリング組織論への招待」より)
不確実性 ≒ 曖昧・分からない・まだ決まっていないものを指します。
本質的に不確実なものは「未来」と「他人」のみ、とされています。
不確実性に向き合うというのは「不安」を伴うため、後回しにされがちですが、不確実性の高いものを先に片付けることで、確実性の高い問題が残り、全体感や未来の見通しが立ちやすくなります。
それは交渉だということに気づけ (「ソフトウェアアーキテクトが知るべき97のこと」の9番目より)
「はい、必要です」と言う代わりに、「確かに待機サーバーがなくてもなんとかなります。ただし、定期メンテナンスとメモリパリティエラーによるクラッシュが起きたときに、システムがダウンしてもかまわなければの話です。まぁ、後者はパリティビット付きメモリーを買えばいいので、あと心配なのは、OSのクラッシュだけです。これは3.9日に1回起きるので、夜間リスター卜が必要になってしまいます。でも、インターンたちが自転車を下りて休憩している間にやれば問題ありません」などと言ってしまうのです。これは正しいことですが、言ってはいけないことです。スポンサーは、「なんとかなります」の後は何も聞いていません。
社内では「スポンサーとエンジニア」という関係はあまり無いかもしれませんが、ビジネスサイドや依頼側から都合の良いように解釈されてしまう、ということはあります。
意図してなのか、確証バイアスにより無意識に行われるかは問いません(分かりません)。
PJ外でPJについて話す場合は、ハードルをむやみに下げない、安請け合いしないことを意識する必要があるかもしれません。
おわりに
つらくなったら逃げてねこでもなでましょう。逃げても死にはしません。