ITエンジニアと意思疎通できない経営感覚のズレ

ITエンジニアのうち、とくにプログラマは非効率な行動を極端に嫌います。「楽をするための苦労を厭わない」などと表現されますが、1時間かけなければならない固定業務に対し、3時間かけてプログラムを書き、毎回5分で完了するようにしておく、というようなことをします。このような人も多い職種なので、自身の業務と関係なさそうなことを強制されることを極端に嫌います。

例えば通勤。会社との往復1～2時間を毎日義務化されるのは無駄であると捉えられます。中には「通勤を強要されるのであればそれも勤務時間に数えてほしい」などという過激なITエンジニアもいます。

2010年代にはオフィス周辺に住むと家賃補助を出すことでインセンティブとするIT企業が登場しました。インターネット環境が広がり、ミーティングツールやドキュメント共有手法が揃ってくるとリモートワークを要求してくる社員も増えました。

2019年まではフルリモートワークが腕のいいITエンジニアを採用するための売りとなる制度でしたが、コロナ禍でリモートワークが一般的になると途端に差別化が難しくなっていきました。

また、研修や評価なども気をつける必要があります。営業研修のような開発からは遠い研修を受けさせる場合、必ず業務における意味合いや期待値を明示的に伝えなければなりません。

営業研修をITエンジニアに受けてもらいたい場合は、「営業の人たちが使う業務システムを将来的に担当してもらうため、業務フローを知るためにも体験して観察してほしい」などと伝えましょう。

この伝達を怠ると「開発業務とは関係ないことをやらされている」と解釈するITエンジニアが一定数います。以前、この伝達を怠った組織では新卒ITエンジニアが研修をボイコットしたり、短期離職したりしたケースもありました。

「持ち帰って検討します」

Bizがこの発言をする場合、決定権が自身になく、上長に確認するという意図で使われます。しかしDevがこの発言をする場合は事情が異なります。

サイズ感のあるシステム開発をする場合、開発フェーズの中には必ず影響範囲の調査があります。「ブラジルの1匹の蝶の羽ばたきはテキサスで竜巻を引き起こす」というのはカオス理論の中でもバタフライ効果としてよく引用されます。「ほんの小さな動きでも大きな事象に繫がる」という理論ですが、システム開発ではこれと類似の現象がよくあります。

1カ所の変更を加えた際に、期せずして影響してしまう箇所がないかを調べるのです。画面上にボタンを一つ追加したことで全体のレイアウトが崩れることもあれば、ある施策の導入によって全体の処理速度が低下し、ユーザー体験が悪化することもあります。

Bizの人との会話では「仮説で語り切ること」が求められがちですが、システム開発では「できると言ってできない」ケースも往々にしてあるため、開発者にとっては大きなストレスに繫がります。私の経験上、コミュニケーションが苦手なITエンジニアが最も嫌がるのがこの項目です。ビジネスにスピード感は重要ではありますが、実現可能性も加味したコミュニケーションを双方が取れると、日々の業務やプロジェクトが円滑に進むでしょう。

スタートアップ企業界隈ではITエンジニアが技術選定を自身でできる、0から設計から始められるということで、「前任者のソースコードや設計を引き継がなくていい」というメリットを挙げて転職の意思決定をするケースが多く見られます。言い換えると「技術的負債」がないことが魅力だそうです。

ITエンジニアは技術的負債という言葉をよく使います。非効率な処理や読みにくいソースコードを指しているケースもあれば、非効率なデータベース構造を指す場合、メンテナンスがしにくいインフラの場合もあります。