働き方改革に関する
調査・分析結果
働き方改革に関する
調査・分析結果
2019年度調査
発注者・受注者で実現する働き方改革に関する
プロジェクトマネージャの意識調査
2019年度調査
発注者・受注者で実現する
働き方改革に関する
プロジェクトマネージャの
意識調査
●●●●●●●
実態調査の実施目的
本調査は、IT業界における取引構造を踏まえたシステム開発における発注者・受注者間のより良い関係づくりに向け、受注者から発注者への要望を明らかにすることを目的に実施しました。
そして調査結果を基に、それらの要望に対する発注者の考え方のポイントや取組の好事例を取りまとめた「
発注者・受注者で実現するIT業界の取引環境改善と働き方改革~円滑なプロジェクトの推進に向けて」を作成しました。
発注者・受注者が一体となってプロジェクトを円滑に進め、IT業界の取引環境改善と働き方改革の推進に繋がっていくことを目指しています。
実態調査結果の概要
調査期間
2019年8月19日(月)~2019年9月9日(月)
調査方法
Webアンケート
調査対象
IT業界4団体の加盟企業
- 一般社団法人組込みシステム技術協会(JASA)
- 一般社団法人コンピュータソフトウェア協会(CSAJ)
- 一般社団法人情報サービス産業協会(JISA)
- 一般社団法人日本情報システム・ユーザー協会(JUAS)
回収数(率)
715件(17.8%)
アンケート調査項目
- 現在担当しているプロジェクトの概要
- 働き方改革の実現に向けた発注者への要望
- その他(会社の概要等)
プロジェクトの属性
調査回答企業の属性を、プロジェクトの類型・取引構造におけるポジション別に示します。
働き方改革の実現に向けた発注者への要望
働き方改革の実現に向けた
発注者への要望
IT業界の取引構造によって生じる長時間労働の是正を阻害する6つの要因(不明確な仕様、トラブル、仕様変更、発注者の事情(能力・行動・特性等)、契約内容、常駐先の職場環境)に対し、それら阻害要因の改善に向けた受注者から発注者への要望の回答結果を示します。
なお、IT業界で長時間労働が発生する原因のうち、発注者側による原因が半分以上であると約6割のプロジェクトマネージャが回答しています。
長時間労働発生における
発注者側の原因比率が5割以上は62.8%
阻害要因①:不明確な仕様
不明確な仕様を改善するために発注者側に要望したいこと
SoR的なプロジェクト
- 業務の課題、システム化及び製品化の目的について社内でコンセンサスを取る
- 業務要求の優先順位を確定する
- 要件定義は変えないところ・変わり得るところを区別して定義する
- システム化及び製品化の目的が実現されているかどうか最終確認を行う
- 多様化するステークホルダとの合意形成を取る
- 仕様や要求の確定時期を明確化する
SoE的なプロジェクト
- 業務要求の優先順位を確定する
- 多様化するステークホルダとの合意形成を取る
- 発注者は実現すべき価値に寄与するかどうかで仕様を判断する
- 仮説部分を明らかにする
- Test & Learnで進める
阻害要因②:トラブル
トラブルを改善するために発注者側に要望したいこと
SoR的なプロジェクト
- 後工程でのビジネス要求の変更は大きなトラブルに繋がることを理解する
- 開発段階におけるテスト・検証に多くの時間を割くことに合意する
- 受注者をはじめ発注者も含めたステークホルダ間でリスクを明確にし、情報を共有する
- トラブルのリスクが高い要求から優先的に対応する
SoE的なプロジェクト
- トラブルのリスクが高い要求から優先的に対応する
- トラブル時の体制や対応方針を定める
- Test & Learnなのでトラブル(想定外の事象の発生)が起きることを前提とした試行環境を準備する
- マイクロサービス等コンポーネントベースで開発し、トラブルや不適合が発生時にはすぐに対応できるようにする
- 想定外のアクセスに対してすぐにスケールできるクラウド環境を準備する
阻害要因③:仕様変更
仕様変更を改善するために発注者側に要望したいこと
SoR的なプロジェクト
- 仕様変更による納期の延長、コスト超過の負担が発生することを認識する
- 仕様変更時の重要度・優先度を明確にする(業務要求、システム要求、ソフトウェア要求)
- 仕様変更の体制・ルールを整える
- 総工数の枠内での仕様変更後の優先順位変更を受注者と協議する
- 業務の課題、システム化及び製品化の目的を容易に変えない
SoE的なプロジェクト
- 総工数の枠内での仕様変更後の優先順位変更を受注者と協議する
- アジャイル開発において制限無く変更要望を出さない
- Test & Learnで進め、仕様変更ではなくブラッシュアップであると認識する
- 1回のTest終了ごとに振り返りと次回のTest内容を双方で確認する
- プロジェクトを中止する条件を予め決めておく
- リリース後も継続的なブラッシュアップが必要であることを認識する
阻害要因④:発注者の事情(能力・行動・特性等)
発注者の事情を改善するために発注者側に要望したいこと
SoR的なプロジェクト
- 発注者が果たすべき業務の全部又は一部を受注者に負わせない
- 突発的又は開発に直接関係の無い要求は控える
- 業務の属人化をやめる
- 受注者の働き方改革や生産性向上の努力を阻害しないために、発注者は発注条件や取引条件に配慮する
- 発注者は社内のビジネス部門への提案力・発言力を高める
- 業務処理の標準化を意識する
- RFPの質を高める(機能要求・非機能要求をRFPに盛り込む等)
SoE的なプロジェクト
- 各イテレーションに関係者は必ず参加する
- 発注者のデジタル関連の利活用知識を向上させる
- 作り手や提供側の事情を優先させず、常に顧客の視点から考えられるようにする
- 事業責任者がプロダクトマネージャとして最終決断する
阻害要因⑤:契約内容
契約内容を改善するために発注者側に要望したいこと
SoR的なプロジェクト
- 工程ごとに多段階契約にする
- 発生し得るリスクの分析と対応策を事前に共有する
- 仕様の変更管理を考慮し、工数・期間等はバッファをもたせた契約にする
- プロジェクトの発注者としての管理体制(ユーザPM・管理プロセス等)を明確にする
- 総工数枠について合意する
- 超過精算可能な契約内容とする
SoE的なプロジェクト
- 総工数枠について合意する
- 各社員の技量を判定し、技術に応じた市場価値で単価決定を行う
- プロジェクトの特徴に応じて成果報酬型など受託側のインセンティブを考慮する
阻害要因⑥:常駐先の職場環境
常駐先の職場環境を改善するために発注者側に要望したいこと
SoR的なプロジェクト
- 受注者の社内の人事労務制度・働き方に関するルールについて配慮する
- 高い生産性・モチベーションが維持出来る環境を整備する
- コミュニケーションを密に取ることで必要な情報は開示する
- テンプレートの標準化や管理ツール、開発ツールの共有化・高度化を図る
- 客先常駐を前提としない
SoE的なプロジェクト
- テンプレートの標準化や管理ツール、開発ツールの共有化・高度化を図る
- 業務を効率化するためのコミュニケーションツールの導入により業務の効率化を図る
- アジャイル開発に適した開発環境(システム、ワークスペース)を準備する
- マイクロサービス等の開発に適したコンテナ開発環境を準備する
- オンラインベースの開発、打合せ環境を準備する