人手が足りない時こそルール駆動開発の検討を

IT人材の不足はかなり重症です。どのお客様でも「人手が足りない」と耳にします。そんなわけないと思うのですが、とにかく人手が足りないとおっしゃっています。

世間的にも「人手が足りない」という現象が見られます。私の勝手な憶測ですが、飲食店や配達員などの人材不足は、給与に見合う仕事ではないからではないかと思います。カスタマーハラスメントやパワーハラスメントにあってまで働くには給与が安すぎるのではないかと。仕事に見合う給与があれば、人材はいるのではないかと想像します。（とはいえ、経営が苦しいのはよーくわかります... 材料費の高騰、燃料電気代の高騰、輸送費の増大、自然災害… ）
その他にも様々な問題はあるかと思いますが...　しらんけど。（笑

一方、ITの世界での「人手が足りない」は、少し様子が違うように見受けられます。基幹システムの入れ替えなどでは多くのタスクがあり、多くの人材を投入しているのに炎上を繰り返し、終わらない事にことを発している気がしてなりません。
また、新しく何かを作ろうとしている中でも物事の整理ができておらず、開発者が自由奔放なプログラミングをしてしまい、出来上がったときには既に茹で上がって伸び切ったそうめんのような状態で、なにか新しいことをやろうとしても、影響分析やらで人を大量に消費しているのも見受けられます。

何が言いたいのかというと、作っているモノの品質が悪いのが根幹にあるのではないかと思うのです。品質が悪いのでテストに通らない。少人数で対応するべき状態なのに、人を大量に投入して対応しようとしているのでは？もっと言うのなら、実装が悪いのではなく、設計が正しいかどうかの判断を実装しての確認をしておらず、机上での確認で済ませてしまっているために、実装->テストと来た時点でようやく設計がおかしいことに気づいているのではないでしょうか。

これ、やっぱり最初の別れ道で間違った方向に進んでしまっているとしか思えません。

本来なら自社の文化を込めた、業務に適したシステムをスクラッチ開発で作りたかったはずなのに、開発ベンダーからの予算オーバーでパッケージを選択し、パッケージを超絶カスタマイズして悪循環にハマっている事例等が後を絶たないと思うのです。
パッケージを、カスタマイズしようとすると、そのパッケージの内部構造をある程度知っておく必要がありますが、集められる人材は素人に近い方ばかり。うまくいくわけがないのです。

最初の見積もりの時の判断基準が「コストを抑える」だけで、アーキテクチャを変えてシンプルに作るとか、不要な機能は再実装しないとかの判断がないのが、ここに至る主たる原因と思います。

開発ベンダーの多くは人月商売をしていますので、投入する人数は多くしたいのです。それにより、営業マンのステータスは上がりますが、お客様を含めた現場は疲弊するだけの構図です。さらに、新しいことにチャレンジしたくても、人がいない。

全くもって良くありません。

私が声を大にし言いたいのは、多くの会社では既に使っていない機能は半分くらいあるわけで、それらはいつでも断捨離できるようにすること、アーキテクチャを今風のものに変え、アプリの更改をしやすくすることで、そもそもの工数を減らす方向に持っていくべきではないかということです。この人材不足の状態ならなおのこと。

物(データ)と事(タスク)を整理するルール駆動開発なら、次に何をやるべきかといった「タスク」を明確にしつつ品質向上を最優先することで、少ない工数で構築することが可能です。

ぜひご検討ください。猫の手を借りるよりも遥かに効果的。