ゆめみにおけるPMとは

こんにちは、ゆめみでPMをやっているkaihoです。

note初投稿となりますが、今日はゆめみにおけるPM(プロジェクトマネージャー)ってどんなものだろう?というテーマで思ったことを書いていきます。エンジニアの皆さんはよく発信していますが、PMからの発信はあまりないため、ゆめみとしてはこんな面もあるよ、という程度に見てもらえれば幸いです。もちろん、1PMの視点ですので、他の意見などあればフィードバック戴けると嬉しいです。

PMのやる具体的な作業としては、ざっとこんな感じ

・営業チームと一緒にプリセールスに行き、お客様の要望をヒアリング、整理して、ビジネス上およびシステム化における懸念点などを伝える

・持ち帰って概算見積りを作成する(エンジニアの皆さんと連携しながら)

・(コンペなどの場合には特に)提案書を他のチーム(営業・企画・デザイナー・エンジニア)と連携しながら作成し、説明する

・受注確定したら、プロジェクトチームを組み立てる。組み立てるために要件を整理するのも忘れない

・もちろん、プロジェクトチームのチームビルディングはPMの仕事

・各メンバーが何人、どの程度プロジェクトで稼働するかを計画し、リソース計画を立てる

・リソース計画に基づき、正式見積りを作成する。お客様への説明も行う

プロジェクト計画書を作成し、外・内向けに進め方、プロジェクトの目的やスコープを共有する

・正式受注になったらキックオフMTGを開催する。その後の飲み会の手配も行う

・SlackチャネルやConfluenceのスペース、JIRAプロジェクトなどプロジェクトの環境を申請・用意する(お客様を含めて構成する場合もある)

・毎週、毎日など定期的に進捗確認を行う進捗MTGを開催する(スクラムだとデイリースクラムとか)

・スクラムであればスプリント計画振り返りをスプリントの合間に計画し、実行する

・もし、プロジェクトの進行において悪いニュース(当初アテにしていた技術が使えない、等)があったらゆめみのBad News Fast の文化に基づき、ゆめみ内で共有する(みんなが知恵を貸してくれる)

・要件定義・基本設計・開発・テストなどプロジェクトの節目において発生するプロジェクトの成果物をレビューし、必要あれば直す

・テストチームと協力しながらテスト計画を作成し、実行する(この中に、負荷試験やセキュリティ試験なども含まれる)

・テストも終えたら、リリース判定会議をお客様と開催し、リリースするかの最終決定を合意する

・(場合によっては、お客様に代わり、あるいは立会いの元)リリース作業を行う(AppleやGoogleへの申請作業)

・リリース申請がリジェクトされる場合もあるので泣く泣く英語を読みながらリジェクト対応を行う

・これらと並行しながら、次の開発計画あるいは保守・運用計画を考え、営業と共にお客様に提案、合意を得る

・リリースが無事に終わってもダウンロード数の伸びで一喜一憂する

・もしかしたら障害が発生するかもしれないので、第一報を受け、調査・対応する。必要であれば障害報告書を作成し、対応する

・PMが一つの案件にかかりきりになり、忙しくて新しい案件に対応できなくなるので、新しくPMになりたい人を採用するために記事を発信する←イマココ!

以上となります。

ホントはもっとそれぞれについて色々書こうと思っていたら、結構な量になって力尽きてしまったので、ここまで!(とりあえずは上から下までカバーしているんだなと思って頂ければ十分です)

今後それぞれのプロセスの中で考え方や進め方・悩み事など今後細かく書いていくつもりです。(いつ書くとは言わない)。

気になる部分などあればフィードバック頂ければ頑張って対応しますので、応援よろしくお願いします!








この記事が気に入ったらサポートをしてみませんか?