はじめに
日本の主なPM職の一覧
海外案件で求められる英語スキル
モダン環境でPMが関わる技術の一覧
モダン環境で技術寄りのPMが関わる技術の一覧
モダン環境で技術寄りのPMが関わる技術のうち参画時に知らなくてもよい可能性が高いもの一覧
PM案件で面談で知ったほうがいいことと質問する意図
コーヒーブレイク
流行りのコミュニケーションツールに振り回されているチームの実態
AWS CloudWatchとGrafanaでのログ確認はプログラマーが教えてくれる
Swagger, PostmanでのAPIテスト実行は難しくない
最後に

①はじめに

英語に拒否反応があるエンジニアや、レガシーな開発環境での経験者が、現場の働き方を知って前向きに案件を選ぶきっかけになれば幸いです。
案件概要を見たあなたが活躍を想像できて、面談をクリアできる自信をつけることができれば、。

②日本の主なPM職の一覧

役職名	技術関与	役割・解説	主な活躍場所
PM（Project Manager）	★☆☆☆☆	スケジュール・進捗・品質・コスト管理を担い、要件調整～納品まで幅広い業務を管理する。	SIer、受託開発、社内SE
PMO（Project Mgmt Office）	☆☆☆☆☆	複数プロジェクトの支援を行い、会議運営や進捗データ管理、報告書作成を担当。現場よりも裏方業務が中心。	大手企業、官公庁案件
PL（Project Leader）	★★★☆☆	技術知識を持ちつつ、スプリント・タスク管理や開発者との連携を担当。開発プロセス全般における技術的リーダーシップを担う。	Web系、事業会社、外資、スタートアップ
テックリード	★★★★☆	技術選定、設計判断、要件レビューなど、開発プロセス全般における技術的リーダーシップを担う。	Web制作会社、受託開発
スクラムマスター	★☆☆☆☆	アジャイル開発の運用フローを熟知したPM。プロセス改善やチームワークを促進する役割を担う。	アジャイル案件全般
IT PM	★★☆☆☆	システム導入やITインフラ構築を担当するPM。クラウド、ネットワーク、ADなどを導入する案件がある。	SIer、社内情シス

日本ではPMポジションを大雑把に理解している傾向があります。海外の案件でも同様のところがあると思います。そのため実際どういうスキルのポジションであるかを確認してください。確認対象スキルは⑤で紹介します。⑦で面談時の質問内容もまとめています。

私はPMやPMOの立場で、実際はPLだった3つの案件に参画したことがあります。
調整業務以外に、[監視, プラットフォーム運用, バグの一時対応, PHPのクエリ修正, 受入テスト]などをしていました。
案件概要にはPMと記載されていました。

なぜこれを説明したかというと、自分の経験職種を正確に分からないと、自分自身を過小評価して賃金交渉ができないためです。PMとPLやテックリードでは、年収に150万円前後の違いがあってもおかしくありません。
例えば私は…PMとは手元にコードがあるならそれを分析するのが当たり前だとずっと思っていたし、バグ分析して修正指示書を作成してテスト計画までおまけでつけるのが当たり前だと思っていました。しかし普通のPMはプログラマーに全て丸投げするものなのです。

③海外案件で求められる英語スキル

英語力が足りているかは、案件概要を見て予想できます。

レベル1: 社内資料やWebでの技術調査で、英文のドキュメントを理解できること。
- (これは同じチームに日本人がいることが多いです)
レベル2: 海外のエンジニアとチャットやWeb会議でコミュニケーションできる
レベル3: 定例会議に出てプロジェクトの説明や仕様の打ち合わせができる, 頻発するトラブル対応について英語で受け答えができる

レベル1とレベル2は、機械翻訳で英語の読み書きができれば通常業務は問題なく、Web会議はコミュニケーションを補うもので任意の可能性があります。TOEICなどの実績が無くても、実際の業務はこなせる可能性が高いです。
レベル3は、口頭での英語のコミュニケーションが円滑にできることが必須条件である可能性が高いです。

④モダン環境でPMが関わる技術の一覧

カテゴリ	技術例
プロジェクト管理ツール	Jira, Trello, Asana, Monday.com
コミュニケーションツール	Slack, Microsoft Teams, Zoom
ドキュメント管理	Confluence, Notion, Google Docs
クラウド環境管理 ※エラー傾向を報告用に見る程度	AWS-CloudWatch, Azure Monitor, Google Cloud Operations (Stackdriver)
API管理 ※仕様確認に使う可能性	Swagger, Postman, Apigee
APIデバッグ ※動作確認レベルで使用可	Postman, Insomnia
バージョン管理 ※履歴確認や差分把握まで	Git, Subversion (SVN)

概要は1日で全て把握できるレベルです。現場に入って数日使用すれば覚えられるものばかりなので、PMとして仕事ができれば特に問題ないと言えるでしょう。

⑤モダン環境で技術寄りのPMが関わる技術の一覧

カテゴリ	技術例
コード管理	Git, GitHub, GitLab, Bitbucket
CI/CD	Jenkins, GitLab CI, CircleCI, Travis CI
コンテナ管理	Docker, Kubernetes, OpenShift
データベース管理	PostgreSQL, MySQL, MongoDB
パフォーマンス管理	New Relic, AppDynamics, Datadog
クラウドストレージ	AWS S3, Google Cloud Storage, Azure Blob Storage
クラウド環境管理	AWS-CloudWatch, Azure Monitor, Google Cloud Operations (Stackdriver)
API管理	Swagger, Postman, Apigee
APIデバッグ	Postman, Insomnia

これらの技術については、すぐ身につくものではないので実績が必要です。特定の技術を知らなくても、似たような技術の経験があれば問題ない可能性があります。

⑥モダン環境で技術寄りのPMが関わる技術のうち参画時に知らなくてもよい可能性が高いもの一覧

カテゴリ	技術例
ネットワーク監視	Zabbix, Nagios, Datadog, Prometheus
コンテナ監視	Prometheus, Grafana, Datadog
モバイルアプリ設定	Android SDK, Xcode, Flutter
フロントエンド開発	React, Angular, Vue.js
バックエンド開発	Node.js, Spring Boot, Django, Ruby on Rails
インフラストラクチャ管理	Terraform, Ansible, Chef, Puppet
セキュリティ管理	OWASP ZAP, Fortify, SonarQube

⑦PM案件で面談で知ったほうがいいことと質問する意図

納期, 人員を調整する戦略的な立場なのか。
技術的な要件を決めてプロジェクト全体の予定に関与できる立場か。
現在の稼働, 前任者がいる場合の抜けた理由と後任に期待すること
参画直後に求められる重要な課題
オフショア開発でどこの国の海外エンジニアが何時に働いているか
定例会議の開催頻度と求められる英会話スキル

⑧コーヒーブレイク

ここまでが参画するコツです。
以降はコミュニケーションツールの例と最小限の労力で仕事を回すためのポイントです。

モダンなツールや技術は、メーカーのパートナーや技術者の解説が、Web上にたくさん存在するのでYoutubeなどを見ればいいと思います。そのとき各ツールの多機能さに圧倒されてしまうかもしれません。
多機能なことがマイナスな影響を与えて、使い方が重複したり、通知が複数発生したり、あちこち確認するなど、振り回されて消耗する現場が少なくありません。
ツールを使いこなしている姿をリアルに想像して、使わない機能を理解することで、PMとして活躍できる自信はつくと思います。
TeamsとEmailのみでコミュニケーションをするオールドスタイルでも、シンプルで効果的に運用しているPMは存在します。その経験はモダン環境でも十分通用するということです。

モダン環境のエンジニアは、技術に貪欲で優秀な人が多い印象があります。
アジャイル開発はスピードが速いと言いますが、たとえば以下のような理由だからだと思います。アジャイルだから忙しいというわけではありません。

優秀なエンジニアが次々に仕事を取れるので、開発スピードが早くスキルが上がりやすい。
品質管理テストの自動化
バグの解消方法をプログラマがテストして提案してきたりするので会議をスキップしている
小さい開発を最小限の要件定義で始めるので管理やコミュニケーションが都度発生する

日本の大手企業でウォーターフォールで要件定義をする場合も、確実に行う業務は調査と設計やテストを同時並行で行えます。また、1週間かかる作業フェーズでも、PMが成果物を逐次確認して手が止まっているエンジニアを特定することはできます。
アジャイルの良いところをPMが取り入れれば、どのプロジェクトでもチーム全体が全てのフェーズで結果にコミットできる環境が整います。

⑨流行りのコミュニケーションツールに振り回されているチームの実態

参画した現場でツールに不慣れでも、コミュニケーションツールをどのように使うのがベストかを調査して、試してみることをお勧めします。それはPMが変えられることが多いからです。

ここでは[Atlassian, Slack, Tableau(BIツール)]の構成で業務にあたっている例を挙げます。
Atlassianは、プログラマーチームなどが使う機能が一番多いです。慣れてきたら、彼らの業務フローも分析してください。ここでは、PMが一番使う機能における問題点を説明します。

Atlassianの主な機能はJiraとConfluenceです。

Jira=課題管理, プロジェクト管理
Confluence=文書作成管理(設計書や報告書)

Atlassianは多機能で、課題に対するコメント機能や、Slackとの連携機能が豊富です。うまく運用できていない現場では、以下のような問題が発生します。

カテゴリ	重複・課題内容	備考
タスク進捗報告	Slackで進捗を報告し、同じ内容をJiraにも書く	どちらに書くべきか混乱しやすい。Slackで報告→Jira反映が漏れることも
課題コメント	JiraのコメントをSlackでも共有、またはSlackの会話をJiraに転記	情報の二重管理、見落としの原因に
タスク起票	Slackで依頼され、Jiraに手動で起票	通知ベースで動いてしまい、正式なタスク登録が遅れる
通知管理	Jiraの通知とSlackの通知で同じことが何度も通知される	重要度の違いが分からずスルーされがち
リマインダー	Jiraの期限管理とSlackリマインダーが別管理	どちらを正とするか曖昧になるとヌケ漏れ発生
担当アサインの伝達	Slackで「この人がやる」と話す → Jira上でアサイン漏れ	Slack上の合意がJiraに反映されないと責任が不明瞭に
承認・確認の履歴管理	Slackで「OK」と言って終わる → Jiraで承認プロセスが追えない	後で誰が承認したか分からなくなる
メモ・議事録の分散	Slackのスレッドに重要なやりとりが埋もれる	ConfluenceやJiraコメントに残さないと記録が取れない
期限変更の通知不足	Jiraの期限を変更してもSlack通知がされない（設定により）	Slackベースで管理してると見逃す
通知の洪水化	Jira課題1つに対して、Slackの複数チャンネルで通知が来る	通知疲れによる無視が起こりやすい

Tableauを使ってレポートを作成し、Confluenceに報告用レポートをまとめて、外部報告用にPowerPointにまとめるという流れの場合は、設定や運用がうまくいっていない場合には以下のように業務が重複する可能性があります。

重複の内容	発生ポイント	解説・理由
Jiraのデータを手作業でTableauに取り込む作業	Jira ➝ Tableau	API連携またはアドオンがないと、CSVエクスポート＆再整形が必要。都度発生する。
TableauレポートをConfluence用にキャプチャ・整形し直す作業	Tableau ➝ Confluence	グラフを画像にして貼り直す、説明文の追加など。レポート内容の再編集が発生。
Confluenceの要約をさらにPowerPoint形式に書き換える作業	Confluence ➝ PowerPoint	フォーマットが異なるため、見出し・図表・説明文をスライドに最適化し直す必要がある。
進捗報告の数値（例：完了件数、残タスクなど）を毎回転記する作業	Jira ➝ Tableau / Confluence / PowerPoint	自動集計ではない場合、毎回値を見て書き写す or コピーする必要がある。
ステータスの定義・説明文の再記載	Confluence / PowerPoint	各種資料でステータスの定義や凡例を繰り返し書くことになる（読み手が違うため）。
関係者ごとの出力形式に合わせて表現や言い回しを変える作業	Confluence ➝ PowerPoint	上司向け、クライアント向けで表現を変える必要があり、同じ情報を何度も翻訳するような作業になる。
Jiraに登録していないタスクやメモをConfluenceやPowerPointで補足	Confluence / PowerPoint	Jiraが全ての情報源になっていない場合、毎回補足や整理が必要。

⑩AWS CloudWatchとGrafanaでのログ確認はプログラマーが教えてくれる

エラー発生個所を予想する場合に、技術系PMはログ確認を行います。
確認対象のログやGrep検索する文字はだいたい決まっているため、運用として参画する場合にはノウハウがあると思います。開発修正しているプログラマーの方が詳しいと思います。
参画したら問題が発生して使うことになる前に一度触ってみて、プログラマーが普段使用しているクエリを共有してもらい、PM用に手順書を作成しておくと問題解決がスムーズになります。

AWS CloudWatchの画面です。
どのログをいつの期間確認するか。文字検索はするか。といった内容をGUIで設定すると、クエリが発行されます。