見積やプロジェクト管理に関して思うこと

見積やプロジェクト管理というテーマで

私が悩んできたこと、取り組んできたこと、Webの記事やいろんな人との会話で学んだことなどを残していこうと思います。

現在、一人開発の部門にいるため見積やプロジェクト管理について学んだことは、生かす機会がありません。

せっかくの反省や新しい学びを生かすことができないのはもったいないのでWebに書き、いろんな方からのフィードバックがいただければと思います。

ーーーーーーー

悩んでいた当時(2013～2014年)の制約条件

・私は見積を作れる立場にない

・見積を作る人、仕様書を書く人はソフトウェアを作らない

・ソフトウェアは昔からいろんな人の手が入ってカオスなソースコードとなっている

・いわゆる「派生開発」となるが、ソースに手を入れる影響範囲が多い。ノウハウが共有されていない

・見積を作る人、仕様を書く人とソフトウェアを作る人の作業量に関する認識のギャップが大きい

ーーーーーーー

1. [プロマネ97]「見積り＝不幸の始まり」にしないために

http://d.hatena.ne.jp/asakichy/20130925/1380060989

まさに「守れる約束をする」のが理想。

「ソフトウェア見積り」という本があることを知った。高額だけど目を通してみたいな！

https://www.amazon.co.jp/exec/obidos/ASIN/489100522X/asakichy-22/

2. なぜ開発で見積り失敗して忙しくなりがちなのか

http://blog.shibayu36.org/entry/2014/03/25/090923

すごくわかりやすかった。バッファを持たせることは、新しい上司も言っていたな。苦しかった開発の当時はバッファがなかった。

3.工数見積もりで陥りやすい罠

http://forza.cocolog-nifty.com/blog/2011/09/post-cb31.html

ここでも「アジャイルな見積りと計画づくり」という本がおすすめされていた。これも気になる。

https://www.amazon.co.jp/dp/4839924023/

4. やばい！間に合わない！工数見積を見誤ったときのリカバリ方法3選

http://media.coach4pm.com/entry/estimation-recovery

ここでも「バッファ」は言われているな。

5. 開発の見積もりとスケジュール管理

http://techlife.cookpad.com/entry/2016/04/06/100000

クックパッドさんの記事。

見積-タスク-スケジュールが、各担当者の数字遊び的な要素で決められていたような気もする… (明らかに実装できない少ない工数でスケジュール引いてた、タスクを分割して報告する仕組みがない、当然遅れる、深夜残業までしなければこなせなくなる)

私が一番しんどかったのは2013～2014年頃で、当時は打てる手も乏しく、PMはいつも忙しそうで相談に乗ってもらえず、毎日苦しいと思いながら仕事をしていました。

2015年以降は上司も変わり、少しづつやり方も変わり、良い方向に向かってきました。それでもまだ、見積の精度には「？？」な部分があり、自分の立場からは改善が難しいと判断し、上流工程へ進んで上流から見直した方が早いと考え、新しい上司に相談、勉強するようになりました。

(※とはいえ、2016年夏からは長期の一人案件で、上流工程の勉強も兼ねているんですけどね…)

同じ仕事するなら、「必要とされるところで、楽しく、儲かる」仕事がしたい。そのための努力ならする。

学んだことをここに書いて、少しづつ自分の頭の中も整理したいと思います。