IT企業の工数について


工数の決め方

下記内容は、工数を見積もるために作った一覧表です。私の苦い経験を元にして作成しました。

工数を見積もる目安一覧

  • ・工数を見積る時間
  • ・要件定義書作成
  • ・他機能の影響範囲を調査
  • ・サイトの負荷
  • ・依頼された内容を実装するための技術習得
  • ・実装時間
  • ・単体テスト
  • ・結合テスト
  • ・ステージングテスト(本番前テスト)
  • ・テストケース(製作者用)
  • ・手直し・他機能との連携調整
  • ・不測の事態に備えた時間(バッファ)
  • ・アップロードする際のバックアップ
  • ・アップロードファイルの管理
  • ・メンテしやすいコーディング
  • ・アップロードしたときのテスト段取り
  • ・不具合時の対応策
スポンサードリンク

私の苦い経験

当初入社したてのころは、Web業界でずぶの素人だったのでプログラミングはもちろん工数の決め方もわかりませんでした。私が受け持っていたサービスは大規模な自社内開発で、私がプログラミングの研修をしている間にそのシステムを知る熟練者が次々退職してしまい、私が入る前より3ヶ月ほど長い製作者とふたりで制作してました。

入社してから1か月後、右も左も分からない状態で押しの強い営業の方とミーティングで地獄を見ることになりました。
営業の方からしてみると、開発チームの状況は知ったことではない。
入ってきたばかりの私達でも、以前いた熟練者と同じ扱いで「このぐらいの工数でできるだろう!」と
押される。気負しして言われた通りの工数でせざる得ない状況が続きました。

技術経験がない、いきなりの仕様変更・追加、短い工数、誰からもサポートがない状態なので
始発で出勤、終電で帰宅の繰り返し。リリースしてもバグが出たりと修羅場状態でした。

ある程度経ってからこれではマズいと思い、今まで口頭で案件を伝えられていたものを
「案件をまとめたものをテキストにしていただけませんか?」といったところ、忙しいから無理だの一点ばりで
たびたび案件が食い違いが発生して罵倒が凄まじかったです。

ハードな日々が続き同じサイトを制作した方が退職されました。
このあと、私は上司に対してどうすればこの状況を打開することができるのか説明しました。
色々あり営業の方にもプログラマーーの作業理解をしてもらい、働きやすい環境になりました。
1年経つ頃には、残業時間が月10~20時間ほどにまでなりました。
後輩に同じ思いをさせないでほんとよかったと思います。

初心者のうちは、バッファーをこれでもかというぐらい長く設定したほうが良いです。
経験を積むうちに、バッファーや技術習得する時間を削ることができます。
これだけ考えないといけないので、すぐに工数を答えることはありえないです。
すぐに工数を答えることは、いい加減な工数になってしまうということを肝に銘じてください。
依頼者、制作者、利用者 のために余裕のある制作工数を。
そもそもバグ以外、残業して急いでやる案件なんてほとんどない。
捨て身の覚悟で説明すれば伝わる。