スクリーンショット_2019-05-17_1

半年前にあった開発プロジェクトがうまくいってなかった話

なぜこの話を半年ぶりにしようと思ったのか

この前、副業先のYOUTRUSTの定例でプロダクト開発の話をしていて、うまくいってるプロダクト開発という定義の中にふと思い出したことがありました。半年前、私がよくTwitterでずっとCSSを書いていると言っていたときに、なかなか開発がうまく進んでないなというプロジェクトがあり、自分もその一員でした。

ちょうどそのあとに社内のLTでそのことについて話したのですが、せっかくなので文章にして残しておきたいと思います。

うまくいかない話をしますが、あくまでアンチパターンとして捉えてほしく、誰かを責めるものではないです。またこうしておけばよかったという話も書くので、ぜひ大きめの開発プロジェクト(3ヶ月以上)をする時に思い出してもらえると嬉しいです。


どういったプロジェクトだったのか

- サービス全体のデザインリニューアル
- それに基づいてSEOを上げるための機能を導入
- 全社共通のAPI通したものを導入
- 管理画面の改修

後から増えていったものが多いのですが、最終的に上記のこと+細々な修正などが入り、全てをやりました。

当初引かれた開発スケジュールはテストなど含めて3ヶ月程度のもの、関わった人数はエンジニア4人、デザイナー1人、ディレクター1人でした。


なぜうまくいってないとその時感じていたのか

最初の議論から進まないプロジェクトだった...

プロジェクトのリリースが2018年11月末だったのですが、最初の議論をslack上で遡ったら、2017年9月でした。ずっと話に出てはいたものの、遅れ遅れとなり、きちんと着手が始まったのが2018年6月頃でした。

当初のリリース予定から3ヶ月遅れてのリリース、開発期間3ヶ月から6ヶ月に

2018年8月末頃リリース予定でしたが、伸びに伸びて2018年11月頃になってしまいました。開発期間含め、リリースまで6ヶ月もかかるの大掛かりなプロジェクトになってしまいました。Web開発だと3ヶ月も遅れるリリースは初めてで、正直なところなんでこうなってしまったんだろうと思っていました。(私のBitbucketのコミットログは4ヶ月弱かかっていました。)

他の問題点

- Phase1とかPhase2みたいな段階リリースがあったが最終的になくなった
- WBS(開発スケジュール)の引き直しが3,4回あった
- 後からやることが増えるのが尋常じゃなかった、追加の仕様が多かった
- リソースの確保がそもそもされてなかった
- 他部署のレビューが入って仕様が変わる
- そもそもの目的が何だったのかわからなくなる
- デザインがシステム上できないことが後でわかったりした(確認不足)

当時はだいたいのリリース日がずっと後ろ倒しになっていました。遅延の理由、そもそもの目的は何だったのかというログがたくさんslackに残っています。


問題点をまとめてみた

1. 何のためのプロジェクトなのか途中でわからなくなった

基本的に機能開発や大きな開発をする場合は、退会率の数字を改善するためというような具体的な目的や目標があると思います。

私が途中でやたらとやることが増えるなと感じたときに思ったのが、これって何のためにやってるんだっけと分からなくなりました。

2. やることが多すぎたのと、まとめてリリースすることになった

上記の何のためにやってたっけに繋がるのですが、後からついでにこれもやってしまおう、これもやらなきゃできないなどやりたいことがどんどん増えていってしまっている状態で、かつ相互に絡み合っていたので、まとめてリリースすることになったのも問題でした。(テストの工数なども増えてしまう)

3. タスクの優先順位をつけていない

やることが増えたときに、タスクの優先順位をつけなかったせいか、どんどん肥大化していきました。これは今やるべきより後でやったほうがいいよねとわかっていれば、後々の開発に回せたなと思いました。

4. 最終意思決定者(決めれる人)がいなかった

そんなの誰かが決めればいいでしょって思うかもしれないのですが、意外と重要なポイントなのが、誰が最後にGOと言ったらその開発が進むのかということです。正直PMと呼ばれる人がいない中での大掛かりなプロジェクトだったので、各々が大丈夫かなと進めていて意思決定がお遅くなっていました。


どうすればよかったのか・忘れたくないこと

1. 何のためのプロジェクトなのか途中でわからなくなった
→KPIや目的をきちんと決める(ex. 退会率を下げるための機能開発
→できれば、1プロジェクト1KPIがベスト(単一責任の原則というのがプログラミングにあります)

2. やることが多すぎたのと、まとめてリリースすることになった
→極力小さく開発してこまめにリリース
→せめて最初のやったこと一覧の各プロジェクトを別々にリリースする

3. タスクの優先順位をつけていない
→あるプロジェクトをやっててこれもついでにっていうのはなし
→もし出てきたら優先順位を確認する

4. 最終意思決定者(決めれる人)がいなかった
→最終意思決定者は1人に決める
→意外と重要なポイントです

なかなか最初から予定通りにうまくいくプロジェクトなんてなかったりもします。

上記にふまえて、余裕を持ったスケジュールとか十分なリソース確保とかもうまくいくのかに響く要因だと思うのですが、幸せな開発をしていくためにも色々と気にしてやっていきたいなと思います!




この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

ありがとうございます😊!!これからもたくさん発信していきます!
23

yuzuho takagi

Web企業のエンジニア3年目で、普段はPHPとReact書いています。仕事やプログラミングのことを書いています!

#PdM 記事まとめ

プロジェクトマネジメント、プロダクトマネジメント系の記事を収集してまとめるマガジン。ハッシュタグ #PM / #PdM のついた記事などをチェックしています。広告プロモーションがメインのものは、基本的にはNGの方向で運用します。
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。