LoginSignup

This article is a Private article. Only a writer and users who know the URL can access it.
Please change open range to public in publish setting if you want to share this article with other users.

More than 1 year has passed since last update.

PLでプロジェクト参画時の初動テンプレムーブ

Last updated at Posted at 2020-11-23

0. Description

チーム規模5~15人, 他シス連携2~5, 画面数が大枠8画面程度, バッチ数大枠15本程度
中規模?くらいの既存案件にPLとして参入

1. 完了条件の決定 → タスクを洗い出し、優先順位と予定を立てる

期せずしてPDCAのPにあたる。
まずは引継ぎ(完全新規の場合は発足/立ち上げ)に際し、完了条件を決定する
要件仕様を理解する、が目的では無限に勉強し続けて終わってしまうので
何をどのレベルまで成果物を作成のように決めてあげよう
タスクとして「資料読み込み、把握」とかあったとしたら、要約して小学生でもわかるように書き直した資料を作りながら、とかね

その後にシステムの規模感を把握
現行資料を漁り、開発チームの業務がどのレベルか、どの程度の工数なのかなどをざっくり把握
現行のクォーター要件と進度、現行チームの業務形態を参考に、読み込まなければならない資料を洗い出して
引継ぎのための具体的な資料、ソースの全量を元に工数を見積もる
まぁここは安定のExcelで一覧表ぶわぁっと作って、機械的に工数見積もっていって足し算すればいいさね

ポイントはここに時間をかけすぎないこと、どうせ未来のことはわからん
かといって適当過ぎても後で〇ぬので、冷静かつ素早く。

2. 全体像を捉えながら、理解の粒度を上げていく

PDCAのD。
大切なのは、開発チームが一人ではないこと
あくまで調整や要件の考慮、タスク管理がメインであり、開発も大事だが、細かいところまで現時点で理解しておく必要は...
必要はあるが、優先度は低くするべきだ

流石にいきなり全DBの全カラム覚えろとか言われても、できるかもしれないが、それより重要なことが他にある
自身の役割を考えれば、画面とバックエンドはどうやり取りしている?とかも、細かく追うのは後回しにするべきだ

かといい初手で

現行要件の事前調査, 要件定義書, 設計書, 各種規則, ソース, 業務フロー, 見積もり系, その他細かい資料

などをすべて読むにはさすがに時間がかかるので
漠然と、全体像を捉えながら、徐々に細部の解像度を上げていくように資料を読み込むとすっきりする
画角に捉えた映像を、徐々に鮮明にしていく

なので最初は

  • 要件定義パワポ
  • システム鳥瞰図
  • ER図

などを参考に
とにかくシステムとして**「つまり何をしてくれるものなのか」**を要約しながら
CRUD図や外部システムIF定義書、バッチ定義書や、実際の検証環境の画面など
実際の細部を読みつつ粒度を上げていくことで

ピンぼけした何か → 身体 → 手足 → 指 → 爪の模様 → ...

というようにクローズアップしていこう

あと管理系業務はPLのみの担当なので
これだけは他人に任せられない。ので最も力を入れるべき。

3. 作業しながら進捗を共有

PDCAのCなのかな。
仕様を勉強するのって暗中模索感が否めない。明確に完了条件を決めても、「いや資料読んだけどだから何だ」みたいなね
得た知識で実際にどうのこうの触ったり、運用業務と会話したり
ようはアウトプットがないと「覚えたけどこれでいいの?」的な不安がものすごい。
およそ開発要件があってガツガツコーディングしていく方がはるかに楽。

なので実際の作業中は、定期的にチームで進捗を共有しつつ
具体的な内容をアウトプットしあう時間を設けることが大切だと思う
その時の個々人の進み具合を見て、この人にはこれを任せようだったり、自分これ間に合わなそうだからあの人に頼もうなり
チームとして相互依存できるような状態を作り上げられるとよい
まぁ最終的には全部ひとりでできるようになるのがいいのだけれど、最初はね。

理想は明確で
「要件来る」→ その場で議論して、「非機能仕様的に無理/コード的に無理」や「あたり少ないからいける」みたいに
頭の中に全部入ってて、その場でさらっと答えられちゃうのがベスト (無論持ち帰って細部検討するが)
経験や規模次第だが、そのレベルって少なくとも2, 3か月以上は続けないと厳しそう

4. 実務に入りつつ、ひたすらあさる

Actじゃないから、これはPDCAサイクルじゃないかもしれない。いやこれActなのかな。
いつまでもちんたら資料読んでるわけにもいかんので、どんどん実務に入りますが
実際に開発する部分ってめちゃめちゃ細かい粒度で事前調査から要件設計製造...ってすると思うので
心配しなくてもどうせめっちゃ詳しくなると思う

のであくまで初動ムーブで、ユーザの求めるシステムの鳥瞰をわりとな粒度で把握しておいて
**そのタンスのどの引き出し見れば、この要件が満了できんの?**って
おおよその場所を把握しておくことが大事

開発しながら「ここ把握漏れてた」みたいなものが出ないように、システムとして致命的なものは何かとか
最悪これさえできてれば成り立つよねみたいなところも 一応把握しておくと
ガチ大失敗は避けられるかもしれない

0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up