あるプロジェクトに途中参画することになった際、なるべく早く立ち上がるために取り組んだこと・意識したことを記録しておきます。
状況
「即戦力として立ち上がる」といっても、参画するプロジェクトによって当然必要なことも変わってくるものです。今回の状況を整理します。
- 私
- 支援先企業様のアプリ導入プロジェクトに参画。支援先企業様のお客様(A社様、B社様)の窓口兼、アプリ導入の各プロジェクトの(一応の)PjMとしてアプリ開発PJを推進。
- 今回は諸事情により、すでに始まっているプロジェクトに対して途中参画した(PjMの交代)。
- 支援先企業様
- お客様(A社様、B社様を含む様々な企業様)向けに、アプリを開発・導入している。設計は日本で行い、実装はオフショア拠点で実施。
- お客様毎のプロジェクト体制を敷いている。
- お客様(A社様、B社様)
- 既に自社導入済みアプリに対して、機能追加をすべくPJを推進している。
- 追加する機能毎のPJ体制を敷いている。
取り組んだこと・意識したこと
マインド面として意識したことを1点、実際に意識的に取り組んだことを順に4点挙げました。当たり前のことを書いているだけな気がしますが、まずは当たり前を当たり前にできるようになっていけるように、次の案件に入る未来の私や、この記事を読んでくださった方の参考になれば嬉しいです。
- マインド
- ①素直な心・謙虚な心・感謝の心をもつ
- 具体的な行動
- ②プロジェクトの概要を把握する
- ③すぐ取り掛かるべきことを把握する
- ④支援先企業様の開発スタイルを把握する
- ⑤支援先企業様のキーマンの人柄・考え方を把握する
①素直な心・謙虚な心・感謝の心をもつ
やはりマインド面は重要かと思います。
即戦力が求められるポジションであっても、プロジェクトに参画してすぐは分からないことが多いのは当然だと思います。分からないことを恥ずかしがったり恐れたりせずに、必ず確認していくようにしました。「即戦力であらねば」という気持ちが邪魔をして、分からないことを分からないままにしてしまうことの方が問題だと思います。
また、仕事を進めるうえで年齢は関係ありません。自分が分からないことを教えていただく際は、年上だろうが年下だろうが謙虚な心で接するように心がけていました。なにか指摘を受けた際も、素直に、謙虚に、「むしろこれでさらに良くなる」という気持ちで受け止めるようにしていました。
逆に、こちらが思うことも素直に伝え、持っている知識は惜しむことなく伝えていくようにしました。
こうしたマインドをもって取り組めたことで、途中参画ではあったものの早期に良好な人間関係を構築できたのではと思います。
②プロジェクトの概要を把握する
プロジェクトに参画して真っ先に行ったのは、お客様の目的・今回のプロジェクトにおけるゴール・期間などをまずはざっと抑えていくことでした。また、最初からすべてを覚え・理解することはハードルが高いので、「どこを見ればどの情報にたどり着けるのか」という点を把握できるように意識しました。
具体的には、キックオフ資料に記載されている内容と、社内のプロジェクトWikiとアプリの設計書などを突き合わせて確認していきました。概要はなるべく早く覚えるようにし、細かい部分は案件を進めながら確認して理解していきました。
また、プロジェクトの体制なども確認し、誰に何を聞けばよいかも把握できるようにしました。
- キックオフ資料
- お客様の目的・プロジェクトにおけるゴール・プロジェクト期間
- プロジェクトWiki
- 運営ルール
- 最新のマスタスケジュール・要件一覧
- 基本設計書
- どこにどういう内容が記載されているかの把握
③すぐ取り掛かるべきことを把握する
プロジェクトの概要を把握できたら、「何がどこまで動いているのか/すぐに取り掛かるべきことは何か」といったことを把握するために、前任者に確認しつつ直近2~3回分の議事録を読むようにしました。もうプロジェクトは始まっているので、私の都合で待ってもらえるはずもありません。今すぐ動かないといけない部分はよく分からないなりに、色んな関係者に確認しながら動き、不明点をどんどん整理して聞いていくようにしました。
- 議事録
- お客様からの質問事項・宿題事項などがないかの確認
- 前任者のToDo表
- 残タスクの確認
ただし、支援先企業様の開発スタイルなども抑えておかないと適切な対応もとれないため、次の④⑤のような取り組みも行いました。
④支援先企業様の開発スタイルを把握する
支援先企業様の設計担当や開発チームに対して適切に依頼ができるようになるために、開発スタイルやプロセスを確認しました。ウォーターフォール開発なのかアジャイル開発なのかによってプロジェクトの推進方法は変わってきます。また、ウォーターフォールといっても、フェーズの多少、管理方法などは会社/プロジェクトによっても変わってきます。前職の経験をベースに、支援先企業様のプロジェクトがどのように進むのかを整理していきました。
- 開発モデル・フェーズ
- 開発フェーズの数、区切り方
- 管理方法
- 次フェーズに進む際の判断基準・イベント等
- 各フェーズにおける役割
⑤支援先企業様のキーマンの人柄・システムの全体像を把握する
プロジェクトの進み方がつかめたら、各フェーズやチームにおけるキーマンに実際の声を聞くことで、キーマンの人柄を理解するようにしました。
設計担当者・ブリッジSE(開発オフショア拠点と日本の橋渡しをしてくれる方)・テストチームリーダー・インフラチームリーダーといった方々に個別に30分程度お時間をいただき、各担当者の役割や責任範囲、各担当者が稼働する期間の目安、各担当者の苦労点、私(PjM)や私を通してお客様にどんな要望があるのかを伺っていきました。
各担当者から見たプロジェクトの景色を重ねていくことで、よりプロジェクトの全体像が立体的につかめるようになりました。
- 共通
- 各担当の役割・責任範囲・苦労していること
- 各開発フェーズにおける、担当者の所用工数の目安
- PjMやお客様への要望
- 設計:設計リーダー
- 設計思想、気を付けていること、基本設計書に書くこと/書かないこと
- 開発:ブリッジSE
- オフショア拠点との連携時差はどれくらいか
- 開発進捗をどのように計るか、どこを見たら進捗が見えるのか
- DBアクセス・画面制御・ビジネスロジックなどをどのように分離しているか(どのようにデータ流れ処理されるか)
- テスト:テストリーダー
- どういう観点でテストをしているか
- インフラ:インフラリーダー
- ネットワークやサーバー構成がどのようになっているか
最後に
以上のような取り組みで、今回のプロジェクトにおいては比較的スムーズに立ち上がることができたのではないかと思っています。今回は、システム構成図、ドキュメント一覧表など、全体が分かるような資料がなかったので、多くはヒアリングを通して理解していきました。
分からないことは多くありましたが、参画してすぐだったので、こちらから「参画したばかりなので、挨拶がてら状況教えてください」とお願いしやすかったですし、皆さんいろいろな情報を教えていただけたので、やはり遠慮せずにどんどん情報を集めていくことが重要だと改めて感じています。
また次のプロジェクトを経験した際に本記事をブラッシュアップできればと思います。
おすすめの本
本記事では全く触れていませんが、今回のプロジェクトでは、基本的にNotionを使って各種管理を行っていました。Notionを使ったプロジェクト管理について非常に参考になる本でしたので気になった方はご覧ください。
コメント