ソフトウェア開発の世界で残業が当たり前になってしまう理由

先に結論から言ってしまうと

・最初から残業ありきで計画している
・ワーク・パッケージの粒度が粗い
・見積り時に抜け漏れが多い

のいずれかあるいは掛け合わせが起きているから、ではないかと思うんです。

どんなに緻密にスケジュールを立てた気になっていても、気が付けばすぐに残業が慢性化してしまう…そんなプロジェクトに遭遇した、あるいはやってしまった人はいると思います。

これは、PMBOK的には「マネジメントあるある」として比較的有名な事例です。

プロジェクトマネジメントにおいて、一般的にいうところの"きちんと計画を立てた"としましょう。たとえばある設計工程でWBSを定義したとします。通常は

　〇〇設計
　　　└ ××画面
　　　　　　└ △△設計書

という程度までワーク・パッケージ（仕事の塊）を構造化、細分化していくのではないでしょうか。そしてその単位でスケジュールの目安を設定していくことになるのだと思います。

仮に上記の通りだったとしましょう。

さて、みなさんはこの状態からスケジュールを設定する場合、

　・とりあえず作成完了するところまでのスケジュールを引くでしょうか
　・レビュー→修正→再レビューまで詳細な工数や日程をイメージして
　　スケジュールを引くでしょうか

実は、こうした微細な差が後々スケジュールの帳尻合わせによって発生する『残業』の差となることが非常に多いのです。

要するに、計画に無い細やかな作業が隠れ潜んでいて、スケジュールを遵守するために残業でカバーせざるを得なくなってしまっているのです（あるいは、計画上にはなかった会議体を急に設定しだして、周囲を巻き込み、盛大に遅延を誘発させてしまったり…と言うこともあるでしょう）。

さらには計画時点だけでなく、見積りの時点でどこまでの作業を見越して工数を積んでいるでしょうか？

やはり設計工程の工数は、設計書を作る工数"だけ"積んでしまったりしてはいないでしょうか？

見積り時点でここがイメージできていないと、当然薄利となるか、あるいは赤字化してしまうことになります。
　
このように、WBS作成時点では所詮「ワーク・パッケージ（作業の塊）」であって、詳細化された各作業にどのようなものがあるのかまで細分化されていないケースが多く、結果として１つ１つの作業レベルまで落とし込むと、想定外に時間がかかってしまい、残業等のコスト圧迫を誘引してしまうことになります。

PMBOKでは、WBSによってワーク・パッケージを定義した後、さらにそこからアクティビティを定義することを求めています。アクティビティとは、最小単位の作業を指します。

たとえば、設計書であれ、ソースコードであれ、試験仕様書であれ、『レビュー』と言う作業だけでもアクティビティまで細分化すれば以下のようなものが抽出できます。

これだけの関係者に、これだけの作業を１つ１つ依頼しようと思ったら、どのくらいの工数がかかることでしょう？（しかも、単価の高そうな人たちばかり…）

※ちなみに、このレビュー方式は最も公式な方法と言われ、且つ最も効率的(低負担、低コスト)に行うことのできるレビュー方式で、名をインスペクションと言います。当然、顧客レビューでも同様の方式が有効です。

平均しても１レビューあたり総工数は１人日近くかかってるんじゃないかと思う時も多々あるほどです。

こうした作業や管理業務は、見積りの時点では一律「総工数の〇％」と決めてしまっていて、内容をよく定めず、思考停止しているマネージャーというのは案外多いものです。

こうしたアクティビティ単位の誤差を認識できるか否か、が見積りやスケジュールなどに大きく影響を与えやすいことを理解しておきましょう。そしてそれが残業を減らす大きな要因にもなってくるはずです。

これらの改善はそのまま"働き方改革"などにも好影響を与えます。

結果として、従業員１人１人の負担を意識的に軽減でき、またスケジュールの破たんを未然に回避でき、安定したプロジェクト運用が行いやすくなる一要因となります。