IT人材不足79万人の真因:生産性向上を阻む『人月の神話型請負』からの脱却

はじめに

こんにちは。ソフトウェアプロセス改善コーチでFindy Tech Blog編集長の高橋(@Taka_bow)です。

経済産業省の2019年発表によると、日本のIT人材不足が2030年には79万人に達する可能性があると予測され、しばしばメディアにも引用されてきました。

この調査レポート発表から5年以上が経過しましたが、果たして79万人という人材不足は現実となるのでしょうか?

今回は最新のデータからこの予測を検証してみたいと思います。

  • 2023年11月2日のNHKニュース www3.nhk.or.jp

  • 2024年7月9日 5:00 (2024年7月13日 17:40更新) 日経新聞 [会員限定記事] www.nikkei.com

「IT人材需給に関する調査」とは

このレポートは、みずほ情報総研株式会社が2015年に経済産業省からの受託調査研究として実施した調査レポートです。

2019年3月に経済産業省から発表されました。当時話題となったのは、このデータです。

出典:「IT 人材需給に関する調査」(経済産業省)(https://www.meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf

これは「今後、IT需要が高位に推移した場合約79万人の人材不足になる可能性がある」という試算でした。なお、需要が中位シナリオで約45万人、低位シナリオでも約16万人の不足する可能性があります。

この背景には2つの要因があります。

  • 日本の労働人口(特に若年人口)が減少(新卒IT人材の入職率は一定右肩上がり)

  • 日本の労働生産性が低い(2022年、OECD 加盟 38 カ国中 30 位)

日本の労働人口減少に関しては、IT業界に限らず日本全体の問題です。

冒頭のNHKニュース「日本のIT人材79万人が不足? インドで始まった人材獲得戦略」は、まさしくこの問題に対応するための動きのひとつと言えます。

労働生産性の低さ

さて、もうひとつの要因「労働生産性の低さ」ですが、次の表をごらんください。これは上記のグラフの一部を表にしたものです。

出典:「IT 人材需給に関する調査」(経済産業省)(https://www.meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf)を加工して作成

IT需要が高位と仮定したとき、

  • 赤で囲んだ部分:生産性上昇率が0.7%だった場合、78.7万人の人材不足
  • 青で囲んだ部分:生産性上昇率が5.23%だった場合、人材不足はゼロ

を表しています。生産性上昇率が5.23%以上アップしていれば人材不足は起きない、という予測です。

では、最新の労働生産性はどうなっているでしょう。

最新のデータを読む

現時点で最新の日本生産性本部が公表している「労働生産性の国際比較2023」から、情報通信業の労働生産性の推移分析を見てみました。

出典:日本生産性本部「労働生産性の国際比較2023」から情報通信業の労働生産性の推移 https://www.jpc-net.jp/research/detail/006714.html

日本の2000年から2021年にかけての生産性上昇率(年率平均)は「-0.1%」にとどまっています。これは、経済産業省が予測した平均成長率0.7%を大きく下回る結果です。

そして、調査レポートが予測する「78.7万人の人材不足」というシナリオよりも深刻な状況である可能性があります。

日本の特徴は、

  • 付加価値額は拡大傾向にある
  • 就業者数も同等ペースで増加している

ことから、付加価値が就業者数の増加に見合った成長をしておらず、生産性の上昇を抑えてしまっていると考えられます。

「人月の神話型請負」が生産性向上を阻む

なぜ、比較的安定推移すると言われる情報通信業において、日本の生産性上昇率は低いのでしょうか。

ひとつの要因として、日本におけるソフトウェア産業の構造的な問題が挙げられます。

まず、多くの企業はソフトウェア開発を外部の受託企業に委託する傾向があります。その際、事前に詳細な仕様を確定し、その通りに開発を進める「ウォーターフォール型」の手法が一般的です。*1

この手法では変更に柔軟に対応することが難しく、生産性向上に課題があると指摘されています。

さらに、多くの受託開発は「人月」に基づく見積もりと請負契約に依存しており、多重下請け構造が蔓延しています。この構造は、柔軟な対応や効率的な開発を妨げる要因となっています。

私はこれを「人月の神話型請負」と呼んでいます。

  • 定義:「人月による見積もりを前提とし、事前合意の仕様とプロセスを厳守するため柔軟な変更対応が難しい請負契約」

「ブルックスの法則」や「銀の弾などない」で有名なフレデリック・ブルックスは、著書「人月の神話(The Mythical Man-Month)」の中で、このように述べています。

私たちが使っている見積もり手法は、コスト計算を中心に作られたものであり、労力と進捗を混同している。人月は、人を惑わす危険な神話である。なぜなら、人月は、人と月が置き換え可能であることを暗示しているからである。(第二章「人月の神話」)

この本が書かれたのは1975年、私でさえ幼少期であり、読者の多くは生まれる前の話ではないかと想像します。

しかし、現代日本のIT業界では「人月で見積もる」が未だに健在である事実に着目せざるをえません。

なぜなら「人月の神話型請負」には、次のような負の側面があると考えられるからです。

負の側面 内容
要求仕様の硬直化 事前合意した仕様に縛られ、 状況に応じた柔軟な改善が難しい
形式的なプロセス管理 決められた手順の遵守が優先され、効率化や創意工夫の余地が少ない
人月ベースの評価 投入工数で報酬が決まるため、生産性向上への意欲が生まれにくい
人員増加による解決 課題への対応を人員増員で行うため、チームの効率が低下しやすい
エンジニアの裁量不足または制限 顧客からの指示が中心となり、技術的な改善提案を行いにくい
技術力の蓄積不足 技術資産が顧客側のものであり、自組織内にナレッジが貯まらない

これらの負の側面は、開発チームの「自立」を損ない、エンジニア個人の「自律」も抑え込みます。

結果として、組織全体の生産性が低下し、改善や変革が難しくなる要因となります。

また、「人月の神話型請負」の問題は、すぐには目に見えにくい「遅効性の毒」のように、ゆっくりと組織全体を蝕むのが特徴です。

この構造的な問題に対処するためには、柔軟で価値を重視した新たな開発体制への転換が不可欠です。少なくとも、次の2点を変えることが必要だと思います。

  • 事前確定型から状況適応型の開発プロセスへの移行

  • 形式的な遵守よりもビジネス価値を重視した評価の導入

つまり、「人月の神話型請負」から脱却し生産性向上を図るには、アジャイル開発を基盤に据え、委託側と受託側双方で「価値を共に創り出す体制」を築くことが重要です。

受託開発でもアジャイル開発はできる

しかし、「人月の神話型請負」をビジネスモデルの柱としてきた多くのソフトウェア受託企業にとっては、どこから手をつけるべきかが大きな悩みだと思います。

そんな難題に光を当てるヒントが、2024年10月30日に開催された「プロジェクト成功への挑戦」というイベントで共有されています。

イベントでは、株式会社永和システムマネジメント Agile Studio プロデューサー/アジャイルコーチの木下史彦さん(@fkino)が、「アジャイル開発と契約」のテーマで、主に「モデル契約」についてお話しくださいました。

木下さんは、従来型の契約が「決めたことを守る」ことを重視するのに対し、アジャイル開発における契約では「変化に対応する」柔軟な仕組みが重要であると説明。

さらに、IPAのモデル契約を例に、準委任契約の採用や、スプリントごとの計画調整が可能な体制づくりをどう進められているかについても詳しく解説されました。

speakerdeck.com

続いて、株式会社永和システムマネジメントのエンジニア、藤田みゆきさんからは「受託開発でのアジャイル奮闘記」と題して、実際の受託開発におけるアジャイル導入の取り組みをご紹介いただきました。

speakerdeck.com

永和システムマネジメントの皆様が示してくださった変化に対応する具体的なアイデアや実践方法は、『人月の神話型請負』から脱却するための大きな一歩となると感じました。

以下に、イベントの録画ビデオもリンクしていますので、ぜひご覧ください。

youtu.be

お知らせ!

現在、私と一緒にイネイブリングチームの立ち上げを行うメンバーを探しています!

イネイブリングチームは、エンジニア組織だけではなくファインディ社全体を支援するチームとしていく予定です。

  • 組織全体のエンジニアリング力を向上
  • 開発スキル向上のためのトレーニングやワークショップを実施
  • プロセス改善の提案とコーチングを行い、開発生産性とDevExを向上
  • 社内外のエンジニアを対象とした活動を展開

このチームで、ファインディの成長エンジンとなりませんか?興味がある方は、ぜひこちらをクリックしてみてください↓

herp.careers

エンジニアのポジションは他にも色々あります。ファインディでは一緒に働くメンバーを募集中です!

herp.careers

では、本日はこのへんで。

See you!

*1:ウォーターフォール型の元となったと言われるウィンストン・W・ロイスによる論文”Managing the Development of Large Software Systems(1970)”では「手戻り」が推奨されています