開発部門の「働き方改革」
「一億総活躍社会」の実現に向けて「働き方改革担当大臣」が新設されるなど、国を挙げての慢性的な長時間労働の是正の取り組みが行われています。企業には、生産性を向上させて従業員の残業を減らす取り組みが求められています。「無駄な仕事をなくし」、「仕事を効率的に進める」ことが求められ、そのために「長時間労働が当たり前の従業員の意識を改革する」必要があるということがよく謳われています。具体的な施策としては「オフィスを○時に強制的にクローズして残業できないようにする」、「残業が少ない人を評価する」などの取り組みが報道されていますが、製造業の開発部門の多くの方にとって「何か違う」と感じるものも多いのではないでしょうか。
筆者が見聞きした巷の「働き方改革」施策の違和感を通じて、開発部門における「働き方改革」の取り組み方について考えてみました。
■開発部門が感じる巷の「働き方改革」施策
「オフィスを強制的に○時にクローズして残業できないようにする」/「ノー残業デーを増やす」
無駄で余計な仕事をしていることや、ダラダラと非効率に仕事をしていることが前提とされていることに、違和感がある方が多いのではないかと思います。仕事の量を減らさずに、単純に一律に労働時間だけを短くしてもやっていけるような製造業の開発部門には、筆者は出会ったことがありません。企業側に都合のいい、残業代の削減策のように見てしまう方も多いのではないでしょうか。
「残業が少ない人を高評価にする」
なかなか解が見出せない不確実性の高い業務に取り組む製品開発において、厳しい競争に勝ち抜くためには問題解決をエース級のエンジニアに頼らざるを得ません。優秀な人に仕事が集中し、頼りになる人ほど多くの相談を受けて残業しがちであるのはどこの開発現場でも同じでしょう。そもそも開発業務を遂行する能力や出した成果ではなく、残業時間で評価するということ自体に、多くの方が違和感を覚えるのではないでしょうか。
「自分の仕事が終わったら、他人は気にせずに帰宅する」
製品が複雑化し分業化が進む昨今、開発の問題の多くは個人での解決が難しいものになってきています。問題を早期に解決させるためにはチームでの取り組みが必要であり、開発部門ではなかなか取りづらい行動です。
■開発部門において、無駄の排除や効率化の取り組みは当たり前
このように開発部門の方は、メディアで見る「働き方改革」の施策は、自部門に当てはまらないものがほとんどだと感じているのではないでしょうか。この違和感の背景には、製造業の開発部門はこれまでにも様々な改善に継続的に取り組んできているという自負があると感じています。いわゆる「失われた20年」の間に、選択と集中を通じたリストラによって、多くの人員削減が断行されました。その結果、従業員一人当たりの仕事量は以前よりも増加し、その状況に対応するために、無駄な仕事の削減やBPR（Business Process Re-engineering）、IT化による効率アップに取り組んで来ていました。もともと開発の現場には、かつて「QCサークル」と呼ばれた活動のように、現場レベルで継続的な改善に取り組む文化があり、現在の業務に大きな無駄や非効率が残っているとは考えにくいのです。
日々改善に取り組んできた開発部門にとって、働き方改革を大きく前進させるような施策がなかなか見つからないのは、止むを得ないことなのです。
だからと言って、開発部門では働き方改革は必要ない、今まで通りで仕方がないという訳ではありません。このような環境であることを踏まえて、一般に言われていることとは一線を画した取り組みが開発部門の働き方改革には必要なのです。
では、開発部門の働き方改革はどのように進めたらよいのでしょうか。筆者の経験を踏まえ、有効と考える着眼点を４つお知らせします。
■「無駄な仕事をなくす」ために
着眼点１：業務ルール
これまでも継続的に改善に取り組んできたことから、明らかに無駄な業務を見つける事が難しいのは前述の通りです。ただ、改めて自社の業務の前提となるルールを振り返ってみると、実は無駄だったという業務が見つかるかもしれません。例えば、
・設定された背景がわからない古い社内規定が改廃されずに残っている
・誰が使うのか良くわからない報告書を作成している
・現在の技術では起こりえない過去の不具合の再発防止試験を実施している
など、守るべき社のルール自体に無駄が潜んでいることがあります。
着眼点２：グレーゾーン業務
性能向上/品質向上などのように、更に突き詰めようと思えばできるものの、膨大な時間を要してしまうような業務や、リスク管理のように成果を出すために直接的には必要でないが、やっておかないと後で大きな手戻りを生じさせる可能性があるようなものが、これに該当します。やらなければミスや手抜きと言われ、やりすぎれば過剰といわれてしまうような業務です。これらに関してどこまでが必要でどこからが過剰なのか、その基準を明らかにすることで、やりすぎ（無駄）を抑えられる可能性があります。
■「仕事を効率的に進める」ために
着眼点３：チームのパフォーマンス
製品開発は複雑化しており、担当者個々人による問題解決には限界があります。問題解決にはチームでの取り組みが必須であり、チームとしてのパフォーマンスを如何に高めるのかに着目する必要があります。短期的なパフォーマンスを上げるには、優秀な技術者が重要な問題解決に最大限取り組めるようにする業務分担の見直しや、彼らを些細な他のメンバーのフォロー業務から解放する業務マニュアルの作成・改訂などが考えられます。また、中長期的には次世代のエキスパートを育成するためのプログラムの策定や、有望な若手にエキスパートのノウハウを伝承させるためのチーム編成などが有効です。
■「長時間が労働当たり前の従業員の意識を改革する」ために
着眼点４：個人の業務範囲の明確化
製品開発の問題解決にはチームでの取り組みが有効であると述べましたが、問題が解決しない限りメンバー全員が帰れないようでは無駄な残業が生じてしまいます。この対策としては、開発業務の内容を洗い出し、個人で行う仕事とその担当、チームで行う仕事とそのメンバーを明らかにし、自分が関わるべき問題とそうでない問題をはっきりとさせることが有効です。また、自分の関わるべき事が終われば帰るように上司が意識づけをし、不要な残業を生まないようにしていかなければなりません。
これらの着眼点を振り返ってみると、いずれも個人の努力で何とかなるようなものではありません。巷で行われているような一律に残業禁止のルールを設け、あとは個人の努力任せでどうにかなるようなものではないのです。製品開発部門の働き方改革には、業務ルールの見直しや業務の必要/過剰の判断、チームのパフォーマンスを最大化するような体制への組み直しが必要です。マネジメント層が先頭に立って、効率的で早く帰宅しやすい環境作りに取り組んで欲しいと筆者は考えます。開発部門のマネジメント層の方々がこのコラムを参考に奮起され、「働き方改革」を成就されることを願います。
執筆：蟹江 淳
※コラムは執筆者の個人的見解であり、ITIDの公式見解を示すものではありません。
