本記事の目的

開発系の中・大規模プロジェクトにおける開発者としてやっておいたほうがよいことを筆者の経験から記載し、全くそういったプロジェクトに携わったことのない若手の少しでも糧になってくれればと思い記事として綴っています。
尚、環境・クライアント状況・要件など人やプロジェクトによって観点は変わるため、1つの心構えや参考記事として閲覧ください。
また、プロジェクトに携わったことのある方は当たり前に思うところもあると思いますがその点はご了承ください。

納品物を決めておく

いつまでに何をどの程度の粒度で納品するのかをあらかじめ決めておくと、プロジェクト終盤でお客さんと揉めることがなくなります。
もし、なにか揉め事がおきたとしても事前に握っている為回避することができます。
納品物に変更があった場合でも随時お客さんと握り全員が見れるところに記載しておくことがベストです。（議事録やコミュニケーションツール上など）

詳細にタスクを洗い出しておく

こちらは、筆者としては中・大規模なプロジェクトに関わらずやっておいた方がいいことになります。
大規模プロジェクトでは通常であればWBSがあると思いますが、厳密にはその粒度の話です。
※WBSの話と思った方がわかりやすい方はそう捉えていただいてもかまいません。

詳細というのは 設計検討・開発・検証・お客さんとの制作物の確認MTG等を細かく洗い出す感じになります。

詳細にタスクを洗い出すメリットとデメリット

メリット

• どのようなタスクが存在しそれにどれぐらい時間がかかるのかというのを俯瞰して見れるようになる

• 洗い出すことで頭の整理につながり、難解だとおもっていたことが意外と簡単になったりする。

デメリット

• エクセルやスプレッドシートで管理を行なっていた場合にタスクの項目行が増えるのでスケジュールなどがずれた場合に手間が増えてしまう。

筆者としては手間は増えるとしても、全体の俯瞰と整理ができることによるメリットの方が大きいと考えています。

ルールや管理方法などを明確し資料化しておく

これは、コーディングルールやgitを使用していればブランチの管理、
コーディングレビュー観点、開発手順書などプロジェクトメンバーが一律で関わること全てにおいてになります。

ルールや管理方法を明確にしておくことで、制作物の品質の統制・ソースコードの統制をすることができます。
ルールや管理方法が明確になっていないと、人によってよしなに対応してしまい管理が煩雑になり予期しない障害などにつながります。

少人数のプロジェクトであれば不要と思うかもしれませんが、必ずしも人数が増加しないといったことや、別会社への委託や社内内部での引き継ぎがないとも言えないと思います。
上記のルールや管理方法を明確にして資料に記載しておくことで、
引き継ぎや新しく加わる方にも容易に対応することが可能になると筆者はかんがえています。

まとめ

いかがだったでしょうか。
本記事はその中で全体を通してこれはやっておいた方が良いと思うことの一部に過ぎません。
なぜ一部なのかというと、冒頭でお伝えしたとおり、開発プロジェクトは環境や状況・要件によってやっておくべき細かい点は沢山あるためです。

筆者としては開発をどのようにすれば効率と品質を保てるのか、開発だけでなくその先の全体を見据えた上でどうすると良いのかを念頭に考えております。
それはなぜか、
開発プロジェクトが終わった先には運用があるからです。
そこまで見据えた上でプロジェクトを考えていくことでより高い目線で話をすることができ、お客さんもまたそこまで考えてくれているという関係構築の向上にもつながると筆者は思っています。

ここまで、ご一読いただきありがとうございます。