「来月も、実装担当としてお願いできればと思っています。条件は今と同じで」

市民プールの入退場システムを支援していたエンジニアは、大会後の振り返りでそう言われた。

最初の依頼は、受付アプリの改修とテストだった。大会前日に読み取り不良が見つかると、施設責任者への説明、端末会社への確認、紙の参加者一覧へ切り替える条件、再テストの順番まで整理した。

「実装しかできない人だと思われたくない」という怖さがあり、進行担当が不在でも「私が整理します」と即答した。大会は予定どおり始まり、担当者からも感謝された。

それでも、更新では実装担当のままだった。担当者に悪気はない。その分、助かったのに、仕事としては数えられないのか と言えず、「承知しました」と返しかけた。

ここで必要なのは、すぐにPMの資格を増やすことではない。最初に約束した仕事、実際に前へ出した判断、次の期間に持つ責任を分けることだ。

「助けたこと」では、役割として残りにくい

「会議に出た」「他社へ連絡した」と並べても、価格や役割を変える理由は伝わりにくい。見るべきなのは、誰が何を決められずに止まり、自分がどの事実と選択肢を揃えたかだ。

この案件では、使える端末の台数、紙へ切り替える時刻、決定者、端末会社の再確認時刻を一枚にした。自分が運用方法を決めたのではなく、施設責任者が選べる状態へ戻した。

ここでいうPM視点は、全部の責任を取ることではない。事実と選択肢を揃え、決める人へ判断を返し、次に動く人を明確にすることだ。

責任と権限を分けないまま「PM的なこともできます」と言うと、会議、連絡、進行、夜のトラブル対応まで集まりやすい。単価が上がる前に、抱える仕事だけが増えてしまう。

IPAのデジタルスキル標準ver.2.0は、異なる背景を持つ関係者の相互理解を促すこと、共通の方向を作ること、複雑な情報を重要な点へ絞って伝えることを、変革を進めるスキルとして整理している。ただし、個別案件の肩書きや報酬額を決める表ではない。

対象となる業務委託では、フリーランス法により、発注者は業務内容、報酬額、支払期日などを書面やメールなどで明示する必要がある。これも、仕事が増えたら報酬が自動で上がる制度ではない。次も頼む仕事なら、業務内容、責任分担、報酬を合意へ残す必要がある。

次の期間の選択肢へ変える

エンジニアは、発注書にある「受付アプリの改修、端末接続、公開前テスト」と、直近二か月で増えた仕事を並べた。

そして、作業時間だけではなく、前へ出した判断を書いた。

読み取り不良が残る中で三つの運用案を整理し、施設責任者が当日の方法を決め、端末会社と受付スタッフが同じ順番で動ける状態を作った。

過去の貢献を並べて終わらせず、次の二案へ変えた。

次の依頼には、こう返した。

状況整理と選択肢の作成までは対応できます。運用方針の最終判断は施設責任者にお願いしたいです。次期もこの対応を持つ場合は、更新時に業務範囲と条件を合わせさせてください。

すぐに希望額がすべて通ったわけではない。それでも、「気を利かせてくれる実装担当」から、「どの判断を前に出す人か」へ会話が変わった🙂

PM視点とは、全部を抱える視点ではなく、誰が何を決めれば次へ進めるかを見つける視点だ。 会議も調整も増えたのに評価へ残らない時は、資格を探す前に、前へ出した判断と、次に合意したい範囲を一つずつ書いてみたい。