月100時間の残業をゼロにしたITエンジニアが語る｜仕事を効率化するタイムマネジメント術

そうですね、現在はフリーランスのエンジニアとして受託開発に携わっていますが、以前はSESとして会社勤めやプロジェクトごとの契約で仕事をしていました。 当時は月に100時間の残業が当たり前。多いときには140時間を超えることもありましたが、働いた分だけ残業代が入るので何の問題意識もなく働いていました。

同じ職場には月に200時間残業している人も…。そんなとき、仕事の効率化で知られる吉越浩一郎さんの「『残業ゼロ』の仕事力」を読んで、残業が問題であることに気づかされました。

その本で最も印象的だった問題は「残業はそのプロジェクトの問題を隠してしまう」ということです。そもそもプロジェクトに問題があるために残業せざるを得ないのですが、残業が当たり前の状況では問題に気づかず、問題を意識できません。

プロジェクトによって異なるとは思いますが、例えば、プロジェクト自体に無理がある、人手が足りない、効率が悪いといった問題があります。無駄な会議やドキュメント、プロジェクトのやり方そのものに問題がある場合も多い印象です。

私自身がエンジニアとして残業をしない働き方に変えたとき、それが許容されず当時の上司との関係性が悪くなったことがきっかけになっています。その会社での契約が終了して、それをきっかけにフリーランスになったのですが、周囲でも同じような課題を感じているエンジニアがたくさんいたので立場を変えたいと思いました。

日本ではエンジニアが作業員として扱われることが多く、立場はあまり高くありません。私は、エンジニアは専門家であるべきだと思っていて、エンジニアのみなさんに「作業員ではなく専門家として働きましょう」と訴えたいと思い、本著を書きました。

あります。残業をしていた頃は、常に疲れていて眠い状態でしたが、残業をやめて体調が良くなり、頭もスッキリしました。その結果、生活の質が上がっただけでなく、仕事でも判断力や業務効率の向上につながりました。

残業はプロジェクトの問題点を隠してしまうだけでなく、睡眠不足や疲れが取れないなどエンジニアの生活の質を低下させ、仕事の効率や品質も低下させます。その結果、成果を十分に出せず自信を失うことも。低評価になるのを防ぐため「残業を断れない」という負のスパイラルに陥ってしまいます。

その根本的な原因は「残業を問題だと考えていない」こと、当事者意識と問題意識の欠如にあります。例えば働き方改革が叫ばれるなかで「残業はしないほうが良い」「するべきではない」という考えが浸透しはじめました。しかし、IT業界では「エンジニアだから残業は仕方ない」という意識が根強く、エンジニア自身も「自分たちは特殊なケースだから残業は仕方ない」と考えることが多いように感じています。

そのとおりです。私はたまたま読んだ本で「残業すること自体が問題である」ことに気づかされましたが、何かそのようなきっかけがない限りは、「残業が問題だ」と気づくことはなかなか難しい。体を壊したときに初めて残業が良くないことに気づくという最悪のケースもあります。

私が残業について最もお伝えしたいことは「時間は命だ」ということです。今日1日を生きることは、自分の1日分の寿命、命を費やすことだと私は考えています。時間というのは自分に与えられた命であり、自分の財産であり、資源なんです。だから人の自由にさせてはいけないと思っています。

確かにそうですね。運用保守系のエンジニアの場合、トラブルの対応を迫られて「できません」とは言えませんよね。そういうイレギュラーな対応はあるかもしれませんが、日常的に残業をしなくても良い仕組みづくり、一人ひとりの長時間労働を改善する体制づくりが果たして本当にできないのか、検討してみる価値はあるのではないでしょうか。

私も下請けのSESとして100時間残業しても「残業代が入るからいいや」と思いながら働いていましたので、残業で稼ぐという気持ちはわかります。しかし、実際に残業をやめてみて、自分と家族の時間や心身など、残業で犠牲にしていたことが多いことに初めて気づきました。だから、もし目の前に「残業代が欲しいから残業する」という人がいたら、「いろいろなものを犠牲にしている」と声を大にして言いたいですね。

「ポモドーロテクニック」と呼ばれる方法があります。限られた時間で成果をだす方法で、実行するタスクを決めて25分間集中し、5分休憩してまた集中する。25分を4回おこなうたびに20〜30分休憩というサイクルで仕事に集中します。

実践してみると25分の集中は想像しているよりも長く感じ、結構エネルギーを使います。しかし、確実に限られた時間内で成果を出せる方法です。少々ハードかもしれませんが、まずは25回を10回繰り返すところからトライしてみてはいかがでしょうか。

仕事への向き合い方としては、「すべてのタスクを終わらせる必要はない」と意識しておくと良いと思います。これは『ITエンジニア残業ゼロの働き方〜現場で本当に使えた仕事効率化の法則95〜』のなかでも、特に反響の大きかった内容です。

はい、タスクの中には自分がおこなう必要のないもの、依頼した本人すら忘れているものもあります。そのすべてを終わらせようと時間を費やすのではなく、納期が近い、自分がする必要があるなど、重要なタスクを終わらせることを優先する。タスクに優先順位をつけ、その日におこなう仕事を最初に決めて仕事を始めることをおすすめします。

タスクの大きさ小ささも考慮しつつ優先順位をつけるのが良いですね。なぜなら、小さい仕事は他の人に助けを求めることができますが、大きい仕事が残った場合は作業を分割できず、どうにもならない状況に陥ることもあるからです。大きい仕事は早めに終わらせることを念頭におきながら、優先順位をつけるのが失敗を回避するポイントです。

そうですね。しかし、緊急の仕事ばかりある状況は問題だと思います。緊急の仕事は、緊急ではない重要な仕事をおろそかにしていることで発生します。大切なのは、日々の重要なタスクをきちんとおこなうこと。そのためにもすべてのタスクを終わらせようとせずに優先順位をつけて、重要なタスクだけをまずは終わらせることを意識すると良いと思います。

「自分の時間を奪うものを排除する」ことは結構大事だと思っています。例えば、スマホを机の引き出しに入れておくことは、私にとって自分の時間を奪うものを排除する有効な方法です。また、何かを探す時間も排除したいことの１つですね。机の上やパソコンのデスクトップが散らかっていると何かを探すことに時間を取られてしまうため、整理整頓は業務をスピーディーに進める上での基本です。

無駄な会議も時間を奪う要因になります。私の昔の同僚は上司に対して「この会議に私は必要ですか？」と問い、自分が出席しなくても良い状況を作っていました。そこまではっきり伝えるのは難しくても、作業の工数を確保するために会議出席の必要性を確認することは大切だと思います。

おっしゃる通り、計画どおりにいかないことはよくありますよね。その際に重要なのは、仮に計画どおりにいかなくても、問題にならないようにタスクを進めていくこと。優先順位を決め、優先度の高いタスクから行っていくことが重要です。また、案件によっては難しいこともありますが、そもそもの作業計画で少し余裕を持たせておくと良いと思います。

コーディングの内容によって異なります。内容が単純で量が多いものは午後でも良いかもしれませんが、緻密な設計や複雑なコーディングは午前中が良いと思います。設計を間違えるといくらコーディングをがんばっても無駄になるので、集中力が高まりやすい午前中に取り組むのがおすすめです。

まず、「調べること」と「聞くべきこと」を区別することが重要です。チームで仕事をしていると「これは自分で調べるべきか」「人に聞くべきか」で悩むこともあります。常に人に聞いてばかりいては自分のスキルも向上しませんし、相手にも嫌な顔をされかねません。逆に、調べることに時間がかかりすぎては効率が悪くなります。

私の場合は基準を設けています。例えば、ソースコードの「処理」といった技術的なことは自分で調べます。しかし、そのプログラムがどのような「意図」でつくられたのか判断が難しい場合は、躊躇せずに担当者に聞きます。「処理」は調べる、「意図」は聞くという区別をしているので、聞こうかどうしようか迷うこともありません。

なるべく相手がイエスかノーで答えられるように気をつけています。自分が残業をしない働き方をしていることもあり、相手の時間を奪うことは申し訳ない思いがあるからです。

質問の仕方としては、例えばシステムの意図や方針について知りたいときに「どんな意図なんですか？」と聞くのではなく、「これはこういう意図ですか」と、自分で考えた方針や意図を示し、それに対してイエス・ノーで答えやすいように質問します。自分なりの見解も合わせて伝えることで、思わぬ効果が生まれることもあるんですよ。

これは私自身の経験ですが、自ら考えて質問した意図や方針がそのままシステムに反映され、私自身がシステム開発の上流工程を担う立場としてなくてはならない存在に。そのシステムが顧客にも好評で、追加受注につながったことがあります。

システム開発において「こだわるべきことは何か」を理解することが大事です。エンジニアがこだわるべきは、お客様の要望や課題解決に応えることであり、そのためにシステム開発を行うのです。エンジニアが「こうしたい」と提案する場合、「こうしたい」がお客様に向いているこだわりであれば良いのですが、単に「自分はこうしたい」という内向きのこだわりでは、かえって開発を阻害する要因になります。どこに向いたこだわりなのかを見極めることは重要ですね。

「最新技術を使いたい」というエンジニアのこだわりは、プロジェクト全体に影響を与えるので注意が必要ですね。お客様の希望を形にするために必須でチーム全体が必要性を感じて導入するのなら良いのですが、「最新のものをなんとなく使いたい」という理由で最新技術を使うのは良い方向にはいきません。

１つの関数を30秒で理解できるようにソースコードを書く「30秒ルール」があります。このルールのポイントは、自分以外のエンジニアが30秒で理解できる単位に分割することです。コードを書いている当事者の自分を基準にすると長い関数になりがちなので注意してください。

そのとおりです。ただ、時間感覚が人によって異なる場合があるため、私は30秒ルールより、スクロールせず1画面に収めることを意識しています。一画面に収まらない場合はさらに細かく分け、それぞれを関数化していきます。

私が業界に入った20年以上前は、伝達漏れを防ぐためにコードにコメントを書くように言われていましたが、10年以上前からコメントは書くべきではないという考え方が登場し、私はその考えに賛成です。コードにコメントを書くとコメントのメンテナンスも必要になり時間を要するからです。例えば、以前の携帯は分厚い説明書がついていましたが、iPhoneは説明書がなくてもわかるような操作性にしていますよね。システム開発の現場においても、直感的に理解できるコードを書くべきだと思っています。

今はソースコードの履歴を管理できるシステムがあるので、コメントアウトするくらいならむしろ消すほうが良いと思っています。というのも以前、私が担当していた現場でチームメンバーが何日かけても解決しない不具合がありました。そのコードを見るとコメントアウトばかり。実は不具合の要因がコメントアウトで隠れてしまっていたのです。それらをすべて削除したところ、10分で不具合はすべて解決しました。

また、ソースコードはきれいな状態を維持することも大切です。優秀なエンジニアにはきれいなソースコードを書くという共通点がありますが、締め切りが迫ると汚れたコードのまま使ってしまうことも起こりがちです。

「きちんと字下げ（インデント）をしている」「情報（変数）と処理（関数）の名前がわかりやすい」「長くなる処理を短い関数でうまく分割している」「無駄なコメントがない」などの特徴があります。1度汚れてしまったコードを戻すことはなかなか難しいため、コードをきれいなまま保つことは重要だと思います。

新規のシステム開発の場合、似たような処理はコピーアンドペーストをするのが一番楽ですが、コピペした箇所にバグがあると、コピペしたすべてにバグが生じます。これはメンテナンスとして最悪な状態です。システム開発の仕事は新規が2割、更新拡張が8割なため、「つくりやすさ」より、「メンテナンスのしやすさ」を念頭において開発することが重要です。

一番伝えたいのは「エンジニアは専門家であるべきだ」ということです。エンジニアがおこなうのは知的業務のため、心身ともに充実した状態でおこなうことが重要で、それを阻害するのが残業です。「エンジニアは専門家であれ！」と、1番伝えたいですね。