ITエンジニアと意思疎通できない経営感覚のズレ 貴重な戦力の離職を招く間違いのポイント

著者フォロー
ブックマーク

記事をマイページに保存
できます。
無料会員登録はこちら
はこちら

印刷ページの表示はログインが必要です。

無料会員登録はこちら

はこちら

縮小

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

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

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

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

影響範囲を考慮するため、即答を控える

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

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

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

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

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

次ページ前任者の設計を引き継ぎたくない
関連記事
トピックボードAD
ビジネスの人気記事