なんでSEはこんなに残業が多いんだろう？ 毎日がんばって仕事しているはずなのに、一向に仕事が楽にならない…。
現在、働き方改革にコロナ禍をきっかけとしたテレワークなどの動きが重なり、大手IT企業を中心に急ピッチでワークライフバランスの改革が進められています。
しかし、IT業界全体としては、依然としてSEの残業文化が根強く残っています。
今回は、SEの残業を減らすためにはどうすれば良いかご提案したいと思います。
なぜSEは残業が多いのか？
そもそも、なぜSEの残業は常態化しているのでしょうか？
大きくは、次の３つの要因があります。
- 残業削減、生産性向上のための施策が多い
- できる人とできない人の能力差が大きすぎる
- 仕様変更と不具合多発に振り回される
詳しく解説します。
残業削減、生産性向上のための施策が多い
開発現場は、いつも短納期、人手不足、技術力不足という三重苦に悩まされています。
そんな現状を打開すべく、プロマネや開発リーダーなどを中心に、さまざまな努力と工夫を現場が続けているのが現状です。
例えば、次のような工夫が行われています。
- 不具合検出を上流工程にシフトすべく、レビューを厚くする
- ペアプログラミングでコード品質を安定させる
- タスクを細分化し、進捗を細かく管理する
- アジャイル開発を導入し、仕様変更のリスクを最小限にする
これらは全て素晴らしい取り組みであることは間違いありませんが、そのためにメンバーの作業時間（設計書やコードを書く時間）が圧迫されていることがあります。
残業削減、生産性向上の取り組みのはずが、気づかないうちに目的と手段が入れ替わっている可能性があるのです。
できる人とできない人の能力差が大きすぎる
SEの仕事は、技術力がモノを言う世界です。能力のある人は、能力がない人の10倍以上のパフォーマンスが出ることも普通にあり得ます。
そのため、難易度が高く難しい仕事はできる人のところに集まり、簡単な機能の実装など、難易度の低い仕事はできない人の担当になりがちです。
できる人はガンガン仕事を消化するのに対し、できない人は簡単な設計や実装でも足踏みしてしまい、なかなか仕事が進みません。
そのため、
- 仕事ができる人 仕事が集中する→帰れない
- 仕事ができない人 仕事が進まない→帰れない
となってしまい、チームとして残業が常態化していきます。
仕様変更と不具合に振り回される
システム開発の依頼者であるクライアントは、システムの素人であることが多いです。
そのため、どれだけ精緻に要件を固めても、どうしても後になって追加、変更したい個所を出てきてしまいます。
アジャイル開発など、仕様変更リスクを減らすための開発手法もありますが、後出しの要望が多く、それに振り回されてしまうこともよくあります。
結果として開発工程の後戻りが発生し、そのしわ寄せが残業という形で現れます。
また、システム開発は不具合との戦いでもあります。
不具合はリリースまでに修正されることが求められるため、不具合が多発してしまうと修正作業に多くの工数が取られます。
不具合を検出するためのテストフェーズは、プロジェクトの最後の方に固まるケースが多いため、修正作業を先延ばしできないことも残業が多くなってしまう原因です。
残業を減らすためにやるべきこと
残業削減のためには、まず次の２つの観点から取り組みを始めるのがオススメです。
- 作業時間を確保する
- 作業量を減らす
時間確保と不要な作業の削減を同時に進めることで、開発に充てる時間を最大化するのです。
次の手順で進めると、この２つを同時に進めることができます。
- 個人の１日の作業時間と仕事内容を見える化する
- 開発が止まっている時間をピックアップする
- 開発が止まっている時間を減らす方法を考える
詳しく解説します。
個人の１日の作業時間と仕事内容を見える化する
まず１日のうち、誰がどんな作業にどれだけ時間を使っているかを、把握します。
チームメンバーに１日のタイムテーブルを作ってもらえばOKです。
やることがその時々で違う場合は、曜日ごととか、開発工程ごとなど、分割しやすい単位で作りましょう。
設計、プログラミングなどの開発時間、会議やレビューなどの打ち合わせ時間、メールや電話などの雑時間などに分けて、できる限り細かく取ります。
『開発が止まっている時間』をピックアップする
タイムテーブルが出来たら、『開発が止まっている時間』をピックアップしていきます。
『開発が止まっている』というのは、クライアントへの『納品物』作成のために手を動かしていない時間を指します。
例えば、進捗会議やレビューなどの打ち合わせ時間。打ち合わせ中は設計書もコードも書いていないため、その間は開発が進んでいないと判断します。
勤務時間８時間のうち、２時間は会議やレビューしているようでしたら、１日の４分の１は開発がストップしていることになります。
そういう前に進んでないと思われる時間を把握するのが目的です。
他にもプレゼン用のパワポ作成や、メール、Slack、電話をしている時間なんかも該当します。
やってみると、意外と「開発時間」が少ないことに気づくと思います。
『開発が止まっている時間』を減らす方法を考える
単純なことですが、『開発が止まっている時間』を減らせば、作業時間を確保することができます。
ここまでできたら、あとは『開発が止まっている時間』を減らす方法を考えるだけです。
ピックアップした時間のうち、その時間が本当に必要かを考えましょう。
次のような視点で考えます。
- プレゼン用の資料は本当に必要か？
スケジュールや集計データ表など、管理資料の体裁を、普段から整えておくことで代用できないでしょうか？ - 進捗会議やレビューの時間、参加人数は妥当か？
会議でなく、資料の回覧やメール報告だけで事足りませんか？
または人数を絞ったり、時間を短縮することはできないでしょうか？
会議やレビューの必要性を、もう一度見直した方が良いのかもしれません。
メンバーで話し合えば、いろんな気づきやアイデアが出てくると思います。
注意点として、不必要な時間を減らすために、作業量が増えないように気を付けましょう。
「レビュー時間を短くするために、レビューポイントをまとめたレジュメを作る」といった感じで、余計な作業が増えるようでは本末転倒です。
この場合は、例えば次のような取り組みの方がベターです。
- 最初からレビューしやすいフォーマットの設計書にしておく
- 誰がどういう視点でレビューするかあらかじめ決めておく
アイデアがなかなか思いつかない時は、次の書籍を参考にしてはいかがでしょうか。
仕様変更と不具合は、事前の取り決めで予防線を張る
仕様変更や不具合に振り回されないためには、プロジェクト開始前にクライアントとこれらの扱いを取り決めてしまうのが最も有効です。
次の２つの内容を決めるようにしましょう。
- 仕様変更の受付期間を決める
- 不具合に優先度をつけ、修正範囲を決める
仕様変更の受付期間を事前に決めておく
仕様変更には、受付期間を設けましょう。可能な限り、受注時の契約で縛ります。
リリース直前の仕様変更は、納期が遅れるだけでなく、十分な検証期間が取れないため不具合の原因になる可能性も高いです。
クライアントにそのことを理解してもらった上で、「どの時点までの仕様変更に対応するか」話し合っておきましょう。
受付期間後の仕様変更依頼について、全く受け付けないというのは角が立ちますので、次期開発で対応するような内容にしておくのがベターです。
それでも「どうしても」というものについては対応せざるを得ないかもしれません。その場合は、納期を延ばしたり仕様変更の一部だけ受け入れるなど、負荷が上がらないように交渉しましょう。
契約や事前の取り決めがあれば、交渉はスムーズに進められます。
不具合に優先度をつけ、修正範囲を決める
近年の複雑化したシステムでは、開発期間中に不具合を全て取り切るのは、ほぼ不可能です。
クライアントにそのことを理解していただいた上で、致命的な不具合など、「納品までには、一定レベル以上の不具合を全て解消する」という条件にしておくことが重要です。
不具合に「致命的」「重大」「普通」「軽微」のようなレベルを設け、どこまで対応するかを事前に決めておきましょう。
こちらについても、契約で縛っておければ最高です。
しかし、だからといってテストやデバッグをサボって良いわけではありません。
稚拙な不具合が多ければクライアントの心証が悪くなりますし、エンジニアとしての信用に関わります。
基本的には「不具合を出さないし残さない」というスタンスで開発すべきです。これは必要以上に負荷を上げないための予防線であるという認識を持ちましょう。
本来はプロマネが適正なメンバーを人選して開発にあたるため、不具合多発の事態はプロマネが責任を持って対処すべきです。
しかし、日本企業ではプロマネが人事権を持たないことが多く、開発メンバーを思うように選べないジレンマがあります。
今回の記事は、未熟なエンジニアをプロジェクトに抱えた状態でもどうにかできないか、という思いで書いてます。
残業削減を机上の空論で語ってはダメ
一つの開発プロジェクトが終わると、次の開発に向けてチームメンバー全員で反省会やポストモーテム（事後検証）をするところも多いと思います。
しかし、その多くは「チームとしての反省点と改善策」にフォーカスが当たっていて、メンバー一人一人に対するケアが欠けているように思います。
「チーム」とは、「個人」の集まりです。
個人の小さな努力の積み重ねが、チームとしての成果になるのです。
プロマネが集計・計測する指標（コードの再利用率や不具合検出率など）は、チームとして平準化されたデータにすぎません。
最終的に集計されたデータだけを見て改善策を議論するのでは、机上の空論と同じです。
「その数値を出すために、誰がどんな作業に時間を費やしているか」を見える化することで、初めてメスを入れるべきポイントが分かってきます。
タイムテーブルを作るのは大変な作業ではないと思いますので、残業の多さに悩まされている方にはぜひお試しいただければと思います。それでは(｀･ω･´)ゞ