目次
- はじめに
- 日本の主な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で設定すると、クエリが発行されます。
エラー発生件数がヒストグラムで表示され、下半分の詳細をクリックするとログが確認できます。
どんなことができるかの公式ページです。
Grafanaでも同様に、対象ログ, 期間, Grepをメインに設定するとクエリが発行されます。
GrafanaはAWSやPrometheus(Kubernetisの管理をするもの)など様々な監視ができる多機能な監視ツールです。
⑪Swagger, PostmanでのAPIテスト実行は難しくない
Swaggerの公式ページで[LIVE DEMO]をクリックすると、デモ操作ができます。
Swagger Live Demo
SwaggerでのAPIの動作テストでは、[Try it out]を押した後に、bodyを修正してAPIに渡す値を設定して実行します。
Postmanのデモページもあります。
Postman Demo
Swaggerを採用しているところが多いですが、より多機能なPostmanでしか実施できないテストが存在するので、両方経験があるとベストです。
⑫最後に
システム設計に、コンテナ, API, Android SDKなどが組み込まれることが多いのがモダン環境ですが、PM視点では成果物をExcelでしっかり作れて、工数管理ができれば慣れるのに時間はかからないと思っていただけたでしょうか。
もっと詳しいAtlassianの使い方は、海外のエンジニアが書いた英語記事を探してみてください。
私が思う最適な設定と運用方法はあるので書く予定はあります。
MS365自動化とAtlassianの実践的な記事は、環境構築して触りながら書く予定です。ヘビーなので時間がかかるかもしれません。
Gitはいろいろなバージョンがあり、どこにでも記事が大量にあるので省略しました。
各ツールの使い方はプログラマーの方が詳しいので、さらに興味があれば探してみてください。
⑧執筆予定リスト
- ✅ 情シスのアウトソーシングの業務品質を担保する
- ✅ Windowsインフラとサーバーインフラのスクリプト更改 -レガシーを知り工程を分析すれば百戦危うからず-
- ✅ ミスマッチを防ぐ案件概要と人材派遣のシステムの基礎
- ✅ 情シスの保守運用自動化_レベル1 入社対応の完成形とは～IT界のナイチンゲールを目指して～
- ✅ 情シスの保守運用自動化_レベル2 ADアカウントとMS365保守自動化
- ✅ 情シスの保守運用自動化_レベル3 SaaS全般アカウントなど一括管理自動化
- ✅ AtlassianとSlackの使い方に関する私なりの最適解