人材の採用は困難な時期ですが、特にエンジニアリングの専門知識を持つ人材の採用は困難です。多くの企業が顧客との関わり方を変革するためにテクノロジーに目を向ける中、ソフトウェア開発者の需要は高まっています。優秀なエンジニアの維持、あるいは新規採用を目指す企業にとって、開発者の満足度を維持するための鍵は何でしょうか？
SalesforceのMuleSoftによる新たな調査によると、その答えは「開発者の負担を軽減するために、より広範な人材に権限を与えること」かもしれない。つまり、開発者以外の人々に開発能力を与えるということだ。一体どういうことなのだろうか？
参照: 開発者の燃え尽き症候群を防ぐ10の方法 (無料PDF) (TechRepublic)
まず、害を与えるのをやめましょう
開発者は顧客へのリーチ方法を革新しなければならないというプレッシャーにさらされているため、多くの開発者が燃え尽き症候群に陥っていると訴えるのも不思議ではありません。さらに、大規模な辞任が続く現状も重なり、開発者の数が不足し、要求される時間を達成できないという状況に陥っているのです。
MuleSoftの調査によると、開発者のバーンアウトの最大の要因は「他のチームからの作業負荷と要求の増加」であり、回答者の39%が影響を受けています。関連して、37%はデジタルトランスフォーメーションのプレッシャー（37%）がバーンアウトの一因であると回答し、35%は新しいテクノロジーやアプローチに適応するためのスキル習得に苦労していると回答しています。
この状況はすぐに改善される見込みはありません。調査対象となった組織の76%が「ソフトウェアアーキテクチャの習得に必要な認知負荷が高すぎるため、開発者の不安や生産性の低下の原因となっている」と回答している現状では、改善は見込めません。過去数年間、私たちは開発者に様々な新しい選択肢（フレームワーク、データベース、言語など）を提供してきましたが、開発者はますます「専用」の選択肢を避け、より少数の汎用的な選択肢に安らぎを見出すようになっています。だからこそ、企業は開発者の選択肢を制限することで複雑さを取り除き、生産性を向上させる社内プラットフォームへの関心を高めているのです。
また、企業がローコードツールやその他の方法にますます注目し、MuleSoftが「ビジネステクノロジスト」と呼ぶ人材をソフトウェア開発の領域に取り込むようになっているのも、このためです。ビジネステクノロジストとは、「IT部門外の従業員でありながら、デジタルトランスフォーメーションにおいてより積極的な役割を果たせる人材」のことです。つまり、開発者ではないものの、開発者の負担を軽減できる人材です。では、どのようにでしょうか？
参照： 開発者としてのビジネスリーダー ： ノーコードおよびローコードソフトウェアの台頭（無料PDF ）（TechRepublic）
あなたを助けるために私を助けてください
調査対象企業の90%は、他社が自社の開発者向けにアプリとデータを統合できれば大きなメリットになると回答し、同じ回答者の70%はそうした計画があると回答していますが、実現に向けた取り組みは依然としてほとんど進んでいません。開発者以外の人材へのオフロードを困難にしている要因には、以下のようなものがあります。
- 専門的なITスキルがなければ、複数のクラウドプラットフォーム間の統合を管理するのが難しい（47％）
- ソフトウェア開発における自動化の限界（46％）
- データサイロ（42％）
- ガバナンスとセキュリティ（41％）
- 軽量ツールへのアクセスが限られている（38％）
MuleSoft のグローバル フィールド CTO 兼デジタル トランスフォーメーション オフィス VP である Matt McLarty 氏は、ソフトウェア開発を自動車製造に例え、自動車製造を実際のビジネスに変えるためには根本的な変化が必要だと述べています。
自動車製造という仕事は、大衆が利用しやすいように細分化する必要がありました。ソフトウェア業界はまさにその段階にあります。比較的少数の労働者、つまりソフトウェア開発者に、大量生産の重荷を背負わせるわけにはいきません。組織全体を巻き込む必要があります。ローコードツールと自動化技術は、そのための手段であり、従業員の満足度を向上させ、ストレスを軽減することが既に実証されています。
Forresterによると、現在Unqorkのようなローコードツールを本格的に活用している企業はわずか10～15%です。しかし、Gartnerは2024年までにアプリ開発機能の65%がローコードプラットフォームで実行されると予測しています。これは楽観的な見方かもしれませんが、開発者の相対的な不足と、ローコードサービスへの需要の過剰が相まって、ローコード導入は想定よりも早く進む可能性があります。
開示: 私は MongoDB で働いていますが、ここで表明されている意見は私個人のものです。
