システム開発プロジェクトにおいて、スケジュール遅延を防止するため「進捗管理をしっかりしよう。」ということがよく言われる。
「進捗管理」は確かに重要なことだ。「計画」をきっちり立て、「進捗管理」をしっかりしていれば、それだけでプロジェクトはうまくいくだろうか？
世の中のシステム開発プロジェクトでは少なからず「ブラック労働」に陥ることがある。
「計画」、「進捗管理」、このようなもっともらしい言葉だけが勢いよく飛び交い、「無理な要求を受けていないか」「元々のスケジュールが短すぎないか」など、その「前段」に着目されることは少ない。
1.進捗管理手法については色々議論されているが、長時間労働はなくならない
システム開発において、作業の進捗管理の方法については開発現場内でも色々と議論が交わされている。一般的なのはガントチャートであるが、redmineなど色々とツールも出てきている。独自の進捗管理方法を考案している現場もある。
しかし、どれを用いても開発にはトラブルや開発途中の仕様変更・仕様追加がつきものであり、これが影響してなかなか長時間労働から抜け出せないのが現状である。
一般的には、進捗管理が適切に行われないために進捗遅れの兆候を掴むことができず、対応が後手後手になることで、遅れが拡大し、これを挽回しようとした結果、長時間労働に巻き込まれてしまうケースが多いという論調で語られる。
しかし、私の経験上はそのようなものではなかった。元々の計画が不適切であればどんなに良い進捗管理をしたところで、進捗管理以前に破綻してしまっている。
逆に大雑把な進捗管理でも計画自体に余裕があれば、その中で小さなトラブルが発生し対応しても、トータルとしては計画通りに進む。心理的な余裕や集中力の高まりによって、ミスが少なく効率的に進めることができ、計画よりも早く進むことさえある。
2.「細かい計画を立てるべき」という勘違いがかえって負担になる
私がよくやる計画は大雑把なものだ。
詳細があまり見えないものでも、半月または１ヶ月単位や半月単位でやることを単純に書き出す。日にちあたり、時間あたりの詳細な計画までしてしまうと、その後、状況の変化に伴う計画修正や細かな更新のほうに工数を取られてしまい、生産的ではない。
大きな入れ物に大きな石を荒く入れるイメージである。これだと隙間だらけになりそうだが、それくらいの余裕を持たせるのが良い。計画より実績の方が進んで時間が余れば、さらにその先の業務の準備や余裕時間で行える業務改善に取り組むでも良い。私は「やることが無くて暇」という理由で困ったことはない。
計画を細かくして余裕を作らないように作業を詰め込み過ぎると、何かイレギュラーなことが発生したとたん計画からの遅れが出て、すぐに破綻してしまう。システム開発の現場で、ベンダーに細かく計画を立てさせ、ベンダーを細かく管理しようとする顧客ほどこのようなことをするから、ベンダー側の立場としては非常にやりにくい上に、このような開発案件に限ってブラック労働になりやすいのだ。
大雑把な計画でも、少しづつ遅れが見えることがある。少しの遅れなら、都合よく考えて「まだ、〇〇期間があるから大丈夫！」などと楽観的に考えることが危険である。細かい計画をするのではなく、遅れの兆候が少しでも見えたら、早めに声を上げることだ。そして、早めに声を上げやすい組織体質や労務環境にすることだ。大雑把な計画が悪いのではない。
計画時によく考えないといけないのは、計画を細かくすることよりも、最短で完成するためのプロセス（作業順序）を考えることである。それと、余裕がなくなったときにやらないこと（捨てること）も決めることだ。
3.「計画をしっかり立てる」だけでは長時間労働の対策にならない
よく、スケジュールが厳しい開発や複数のプロジェクトを掛け持ちするメンバーがいるなど、余裕のないプロジェクトにおいて、リーダーや管理職はメンバーに対して、
「スケジュールが厳しいから『しっかり計画を立て、進捗管理を行う』ように」
と言い放ったりする。これは非常にナンセンスだと感じる。
余裕のない開発ではメンバーが無理をして長時間労働が発生するリスクがある。
『しっかり計画を立て、進捗管理を行う』だけでは、長時間労働の対策にはならない。
本来必要なのは、不要な作業を削ぎ落とし、余裕を持った計画をし、それでも利益が出るビジネスを創出することだ。
これを行わず、開発現場に対しては「計画と進捗管理をしっかりと！」と言うのは、単なる丸投げである。
「時短ハラスメント」（＝「ジタハラ」）とニュアンスがよく似ている。「時短ハラスメント」とは、「時短だ！」「効率よくやれ！」などといった号令だけが飛び交い、業務量も求めるアウトプットも投入リソースも変わらないままであるため、かえって心理的圧迫となるハラスメントを指す。
また、計画をしっかり立ててもシステム開発はトラブルがつきものである。想定外のことが起きれば、どれだけ計画や進捗管理をしっかりしていても計画に対する実績の遅れは避けられない。工場の製造ラインのような定型作業であれば、細かい計画もそれなりに効果があるだろう。しかし、システム開発の素人は工場の製造ラインと同じ感覚で計画を立てさせようとする。ここに落とし穴がある。
私が見てきた限りでは、トラブルが多い開発現場ほどトラブルを想定していないのである。計画を細かく立てることよりも、起こりうるリスクと対応策を考えるリスクマネジメントを充実させた方が良いのてはないだろうか。
4.そもそも「無理な計画をしない」という「前段」ができていないケースが多すぎる
進捗管理が要らないと言っているのではない。進捗管理は必要である。
覚えておかなければいけないのは、進捗管理はプロジェクトの計画に対する遅れに繋がる兆候をできる限り早い段階で検知するための手段に過ぎない。
どれだけ進捗管理が素晴らしいものであろうと、その「前段」が出来ていなければ長時間労働となりプロジェクトは破綻する。ここでいう「前段」とは「スケジュールの適切性」である。これができていないと、詳細作業をタスクに分け、計画を立てても必ず無理が発生し、必ず計画に対する遅れが出てくる。
そもそも、無理な計画に対して計画通りにいかないことを「遅れ」と言ってしまうと、相手にどのような印象を与えてしまうか考えるべきである。
計画通りにいかなかった「無理な計画」であるプロジェクトに対して、「進捗が悪い」「進捗管理が出来ていない」と言ったところで何の解決になるだろうか？
諸悪の根元である「無理な計画」をどうにかすべきなのだが、この点を誰も指摘しないのが現実だ。
o08usyu7231.hatenablog.com
当たり前のことだが出来ていないから、ブラック労働が無くならないのである。ブラック労働になりやすい開発現場に共通する特徴の一つは、管理職やリーダー・マネージャーがメンバーへ行われる要求に対して、その「前段」が出来ていないことである。
「前段」が出来ていなければ、現場は過重労働に巻き込まれ、メンバーがいくら頑張っても取り返しがつかないどころか、心身に支障が出るなど逆効果である。
「前段」が出来ているかどうかを正しく見極め、転職を考えている人は「前段」が出来ている企業を選ぼう。
