🐈
不安要素を解消してチームが効率良く開発するために、プロジェクト開始時にやっておきたいこと
はじめに
皆様こんにちは、株式会社プラハのAwataです。
今日は、以前書いたリーダーの振り返り記事で軽く触れていた、不安要素の洗い出しについての記事を書いていこうと思います。
なんのためにやるのか
狙いとしては以下のようなものがあります。
- 開発が本格的に始まる前段階において、不安要素を洗い出して後から致命的な問題が発覚することを防ぐ
- 不安要素を明確にし、それに対しての対策を考えることで、開発に集中できる環境を作る
- 不安要素を共有することで、関連する問題が起きた時に素早く協力しやすい環境を作る
進め方の紹介
続いて、どのように進めていくのかを紹介したいと思います。
プロジェクト成功の定義
まず、「成功の定義」 を決めます。
今回は、法人向けに展開するための新規開発ということで、それぞれの定義は以下のようになりました。
- 期日までに開発が完了すること
- 期日までに開発したシステムが、法人向けに展開できること
プロジェクト失敗の定義
次に、「失敗の定義」 を決めます。
- 期日までに開発が完了しないこと
- 期日までに開発したシステムが、法人向けに展開できないこと
不安要素の洗い出し
ここでついに、失敗の定義をもとに不安要素を洗い出します。
- 作ったサービスを使ってもらったが、満足いくものにならないかもしれない
- 開発の難易度が高すぎて、期日までに開発が完了しないかもしれない
- 既存システムの負債に引っ張られてしまい、期日までに開発が完了しないかもしれない
- デザイナーが不在の案件なので、要件からデザインに落とし込めないかもしれない
対策の検討
最後にこれらの不安要素に対しての対策を考えます。
- POとのコミュニケーションを密に取ることで、本当に必要とされているサービスを作る
- 実装の詳細についてはある程度こちらでコントロールできる環境のため、うまく難易度を調整する
- 極力既存システムと疎結合な設計にする
- デザインについては更に拡大していくフェーズが来たら作り直すことも事前に同意を取る
まとめ
今回は以上になります。
このMTGを事前にやっておくことで、無駄に不安を感じる必要が減ったり、チームが成功に向けて同じ方向を向くことができたと感じています。
また、不安要素の解消に関連する作業は、リーダーが積極的にやる方が好ましいと自分は考えています。
リーダーが不安要素を取り除くことができれば、メンバーは開発に集中でき、アウトプットを最大化できるからです。
ぜひみなさんのチームでも取り入れてみてください。
GitHubで編集を提案
Discussion