明日の自分をアップデート!

  1. マネジメント
  2. 89 view

IT業界=残業多すぎ問題。本当に生産性を上げないと残業は減らせないのか?

「残業抑制のために生産性を上げましょう」みたいなことがよく言われますが、そんな簡単に生産性は上がらないですよね。

特にIT業界では生産性が上げにくいと感じてます。

システム開発における生産性とは

システム開発における生産性とは、一言で言うなら「システムを早く正確に作る能力」です。

これを分解すると、次のような力が必要になります。

能力説明
ヒアリング・読解力お客様から要求を漏れなく引き出す技術。
文章力・図解力仕様を正確に文章に落とし込む技術。
折衝力お客様と仕様や納期などを調整するためのコミュニケーション技術。
マネジメント技術プロジェクトの進捗を管理したり、品質を管理するための技術。
プログラミング技術プログラムを作成する技術。
テスト技術品質を保証するための技術。

これってエンジニア一人一人が身に着けていかなきゃいけない能力で、つまりエンジニアのスキルアップが生産性向上に直結しています。

他の業界はどうか?

例えば製造業で生産性を上げる場合は、まず次のような選択肢が考えられると思います。

製造業での生産性向上施策
製造ラインを増やす
製造ラインを刷新する(処理能力の高い機材に入れ替える)
共通部品を増やすなど、材料や設計を見直す

個人の能力向上はもちろん大事ですが、それ以外にも機材入れ替えのような即効性の高い選択肢があります。

もちろんそれにはお金がかかるのですが、IT業界の場合はお金をかけても即効性が出ないです。

生産性を上げたくても教育に時間がかかる

この世には、パレートの法則というものがあるらしいです。

パレートの法則(パレートのほうそく)は、イタリアの経済学者ヴィルフレド・パレートが発見した冪乗則。経済において、全体の数値の大部分は、全体を構成するうちの一部の要素が生み出しているとした。80:20の法則、ばらつきの法則とも呼ばれる。

Wikipedia「パレートの法則」より

現代社会では、よくこの法則を会社経営に当てはめて「売上の8割は2割の優秀な人材が生み出している」と言われています。
システム開発会社であれば、「2割の優秀なエンジニアがシステムの8割を作っている」というところでしょうか。

システムの開発現場で働いている方であれば、この法則は実感できると思います。

IT業界の生産性はエンジニアの能力(スキル)に依存していますので、できる人ほどタスクやプログラミング量が多く、仕事が集中していることが良く分かります。

パレートの法則は崩れないという事実

じゃあ優秀なエンジニアを増やせばいいだけなのですが、これもそう簡単にはいきません。

優秀な2割を3割、4割と増やしたところで、結局2割に戻ってしまうからです。

働きアリを使った実験

これを証明する有名な実験があります。

働きアリは「2割のアリが全体の8割の食料を集めてくる」性質があるらしいです。
残り8割のアリは、6割が普通に働き、2割は怠けています。

そこで、よく働く2割のアリだけを集めた集団を作ってみました。
すると、その2割の集団がいつの間にか2:6:2の割合で、よく働くアリ、普通に働くアリ、怠けるアリに分かれてしまったというのです。

現代社会も同じ

「アリと一緒にするな」と思われるかもしれませんが、この法則は会社組織にもあてはまると言われています。

「2割の優秀なエンジニアがシステムの8割を作っている」という基本原則は崩れません

どういうことかというと、教育に成功し、並のエンジニアがエースエンジニアに成長したとします。
おそらく、その教育には相当の時間がかかったことでしょう。

しかしその時には、これまでチームを支えてくれたエースエンジニアがいなくなっている可能性が高いです。

激務に嫌気がさして退職したか、チームを異動したか、はたまた昇進したのか、理由はいろいろあると思いますが、現場から離れてしまう可能性が時間経過とともに大きくなるわけです。

よくよく考えてみれば、退職以外のケースでは経営者としてありがちな判断のような気がします。
優秀な人を集めたドリームチームを作るより、社内の方々で活躍してもらった方が有益ですしね。

生産性は変わらないが、教育は大事

パレートの法則が崩れないということは、「2割の優秀なエンジニアがシステムの8割を作っている」という事実が変わらないということになります。

つまり、チームメンバーを教育してもチームとしての生産能力は変わりません。
(会社全体としては有益で、わずかながら生産性向上に貢献するとは思います)

では、教育をしなくても良いかというと、それはそれで問題があります。

エースエンジニアがチームからいなくなっても良いように、次代のエースエンジニアを育てておかないと生産性が下がることになってしまうからです。

生産性を落とさないためにチームメンバーを教育し続ける必要があります。

生産性に頼らず、残業を減らすにはどうすれば良いか?

最初に答えを書いてしまいますが、「残業禁止」にしてしまうことが最適解だと思います。

残業がどんなにひどかろうが、「残業禁止」にするんです。

「残業するな」と言うと「納期に間に合わない」という反論が普通に来ると思いますが、これは言い方を変えれば「納期に間に合えば何しても良い」と思ってるということです。

少なくとも、IT業界に限って言えば残業はこの認識の「甘さ」から来るものだと思っています。

みなさんのまわりにもいませんか?
お客様との打ち合わせには遅れないのに、社内の打ち合わせにはいつも遅れる人。

こういう時間間隔が残業を生んでいる遠因だったりします。

残業をしない = 同じやり方は通用しない

残業をしないのであれば、同じ仕事のやり方は当然通用しません。やり方を変えましょう。

まずは会議時間を減らして作業時間を増やせないか考えましょう。

社内会議の7割は無駄だと言われていますので、次のようなことができないか考えましょう。

  • 会議時間の7割減
  • 参加メンバーの7割減
  • 会議回数の7割減

会議時間の7割減

事前に資料を回覧するとか、会議で決めるべきことをはっきりしておくとか、時間短縮を目指しましょう。

残業と同じく「延長禁止」にすることで時間感覚の「甘え」を消すことが重要です。

参加メンバーの7割減

発言を一切しないのに、会議に呼ばれる人が意外といます。

情報共有が目的であれば、後で議事録を送るなどの対処で十分かもしれません。

また無駄話が多かったり、話が長い人も可能ならメンバーからはずましょう。
(そういう人に限って目上の人が多く、難しかったりしますが…)

回数の7割減

そもそもメールやチャットで済ませられることは、会議自体をやめましょう。

進捗会議はメール報告でも十分だったりしませんか?

進捗が芳しくないメンバーがいるなら、個別フォローすることで、少なくともメンバー全員の時間を使う必要はなくなります。

課題や進捗状況をしっかり報告してもらうために、文面のフォーマットを工夫しましょう。

残業を禁止すると生産性が上がる

生産性を上げようとしても生産性は上がらず、残業はなくなりません。
しかし、残業を禁止すると結果的に生産性が上がる可能性が高いです。

順番が逆なんです。

エンジニアの仕事は頭脳労働ですから、残業続きで疲弊した頭では生産性が落ちるのは当たり前です。

反対に、残業をしない状態は休息が十分にとれている状態ということです。

残業続きで落ちていた生産性が元に戻るという形で生産性の向上が見込めます。

さらに頭がすっきりした状態であれば、生産性を上げるためのアイデアが思いつきやすく、それを試す余裕も生まれます。

残業が嫌でエンジニアが退職してしまうリスク回避もできますので、結果的に好循環につながりますね。

関連記事

コメント

  • コメント (0)

  • トラックバックは利用できません。

  1. この記事へのコメントはありません。

  1. この記事へのトラックバックはありません。

CAPTCHA


PAGE TOP