0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

プロジェクトマネジメントを引き継いだ話

Last updated at Posted at 2020-07-15

はじめに

2020年5月に転職し、6月から自社アプリのPMを引き継いだのですがその時の話を。
筆者はwebエンジニアとして受託という形で関わっていたのですが、5月に正式に会社にjoinした感じです。

従来の状態

転職した会社はスタートアップで社員も20名弱。
チームメンバーは3つのプロダクトを兼任しながら10名弱。

ディレクターが2名ほどおり、そこで策定された施策や機能などがエンジニアに降りてくる典型のウォータフォールでした。
しかし、問題としてそこから

開発側が調査・工数見積もり→
問題が発生→
ディレクター側に要件定義の戻りが発生→
再度要件定義→
開発側が調査・工数見積もり→
問題が発生→
・・・・以下loop

ということも少なくありませんでした。

私は前職で要件定義からテストまでをおこなっていたので、そのノウハウを組み込むことができればと思いました。

開発手法の転向

まず問題としてアプリの最終ゴールがないことが問題でした。
KPIを決めてそれに向かって走っているのですが、結局ゴールがないままに短期的なプロットを追っている感じでした。

そこでサービスとしてのOKR(googleとかでやってる目標管理指標ですね)の策定と、アプリの最終形を定義しました。
こうすることで常に自分がおこなっていることが間違っていないかどうかの指針しようと思いました。

そして、施策や機能要件を開発者が提案・定義するようなフローとしました。
アプリの最終形があるのでそれに向かっての機能要件などはもうできるようになっているので、それを開発者にしてもらうようにしたのです。

これにより、ざっくりとした工数や技術課題などが初期段階で判明するので、いつものようなディレクターに戻るようなことが発生しない仕組みとしました。

メリット

先に述べたように手戻りがないので無駄がないことと、開発者がユーザ視点で開発できること、開発者全員がPMになれるよう育つことができると思います。

手戻りがない

先述した通り。

開発者がユーザ視点になれる

今までディレクターから降りてくる内容をただ開発しているだけだったのが、要件から入ることでよりユーザを意識した開発ができるようになる。

みんなPM

要件から入り、開発し、効果測定し、改善案を考えて開発する。というサイクルを回せることでPM開発者全員が数値を意識して動けるようになります。
みんなPMの何がいいかというと、PMに依存せずにプロジェクトを進めることができるメリットがあります。
(PMなんてほんとはいなくていいと思ってる)

ディレクターは?

ディレクターはお払い箱?ではなく、マーケティングなどに注力してサービスの拡大施策に集中できることが良いのです。
※会社によっていろんな体制があるのでなんとも言えませんがうちはこういう感じです。

最後に

開発者が一番サービスの内容を理解している(コードレベルで)のでそういったところまでどんどん入っていければ人材としての市場価値も上がるしいいことばっかりではないか?というように思っている次第でした。
走り始めたばかりなので今後どうなるかわかりませんが・・・。

0
0
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
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?