---
title: それって技術の仕事！？ 仕様の輻輳問題　〜心理的輻輳から脱出して健康な開発に〜
tags: 
author: [Akira Ikeda（クオリティアーツ）](https://www.docswell.com/user/Akira_Ikeda)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/V7PKQ35XJ8.jpg?width=480
description: 2023年6月12日(月) ～ 14日(水)に仙台市で開催された，SS2023 in 仙台での発表です．  論文冒頭です． --- 本FPでは，多くのエンジニアが経験する「仕様の輻輳問題」を取り上げて議論する．仕様の輻輳を「エンジニア個人に対して仕様にまつわる調整事項がエンジニア個人に集中し，開発進捗に大きな影響を生じる状態」と定義した．仕様の輻輳の状態が悪化すると，エンジニアの「心理的輻輳」を引き起こし，それが更に仕様の輻輳を悪化させる．仕様の輻輳は多くの現場でエンジニア個人が解消しようとしているが，本来は PM（Project Manager）の仕事である．べき論はあるが，日々の実際としてエンジニア個人はどう対応すべきだろうか．エンジニア側かつ文化や人間的側面から議論する．  https://www.sea.jp/ss2023/download/18-ss2023.pdf
published: June 13, 23
canonical: https://www.docswell.com/s/Akira_Ikeda/Z7N168-2023-06-13-SS2023
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/V7PKQ35XJ8.jpg)

それって技術の仕事！？
”仕様の輻輳”問題
～心理的輻輳から脱出して健康な開発に～
池田 暁
松尾谷 徹
クオリティアーツ
デバッグ工学研究所
1


# Page. 2

![Page Image](https://bcdn.docswell.com/page/2JVV54P3JQ.jpg)

自己紹介 池田 暁
•
•
所属：クオリティアーツ（個人事業主）
経歴：
•
情報通信や医用，自動車分野でソフトウェア品質を中心に業務（社員数多）
•
2002年～：日立グループ３社
•
•
Web分野で業務（社員数小～中）
•
•
•
日立情報通信エンジニアリング，日立ハイテク，日立Astemo
2021年～：ビズリーチ
2023年～：マネーフォワード
社外活動：
•
•
•
•
SS2023実行委員会
NPO法人ASTER（ソフトウェアテスト技術振興協会）
AFFORDD（派生開発推進協議会）
NaITE（長崎IT技術者会） ←9/15に長崎で技術イベント「長崎QDG」やります
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/5EGL61PYJL.jpg)

自己紹介 松尾谷 徹
所属： 有限会社 デバッグ工学研究所
経歴： 電気メーカにて周辺機器の須知設計（HW），汎用機OS（MULTICS）
開発，開発支援システムの開発，などを経験．
JTC1/SC7 WG9 国内主査を経験
明治大，東京理科大 ，法政大の兼任講師を経験
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/4JQY4D267P.jpg)

アジェンダ
• 問題提起（論文の概略）
• 本FPでの議論提起
• 会場議論
• 議論１
• 議論２
• 議論３
• まとめ，今後について
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/K74WQZLME1.jpg)

問題提起
論文の概略
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/LJ1YPRLYEG.jpg)

背景と課題
• 近年，ITプロジェクトの対象が複雑化し，工数ベースの請負作業から，DX
など対象分野のスキルや，機械学習/仮想環境のスキルなど，スキル重視ベ
ースへと変化している．高度なスキルを持つエンジニア（コアエンジニア
と呼ぶ）パフォーマンスを引き出すことがプロジェクト管理の中で重要な
課題となっている．
• コアエンジンニアがジレンマに陥り，そのパフォーマンス低下を引き起こ
す仕様の輻輳問題は，実装段階以前にステークホルダー間で調整し，契約
や仕様のコミットが必要な様々な要件を決められず，先送りして実装段階
へ投げることが主な原因と推測される．我が国独特のあいまいな契約や工
程完了のコミット文化が影響している．
• 文化や組織，人間的な原因を含んでおり，技法や技術だけで解決できない
課題であり，かつ状況が深刻化することでプロジェクトや企業の開発競争
力にも影響することから，ＦＰのテーマとして取り上げる．
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/GJWG21V172.jpg)

概要・・・変化
• 機能の増大と複雑化が拡大
• その原動力：OSSなど権利制約が緩和され流用技術の拡大
• スキルが「作る」（自由度）から「連携と設定」（制約）に変化
• 仕様作りに大きな変化【技術的輻輳】
• 要件と実現方法とのギャップ拡大
• 全体が解るコアエンジニアでも難しいタスク
• 見えてる世界の差が拡大【文化的輻輳】
• 利用者，調達者，営業，などステークホルダ
• 設計者，実装者，テスト設計，品質保証，などなど
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/4EZLDP4X73.jpg)

変化⇒２極化現象？
騒乱
輻輳チーム
調達カースト？
元気なチーム
疲弊
孤立
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/Y76W1M3P7V.jpg)

引き金は，仕様が決まらない
ややこしい文化対立
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/G75M4ZLP74.jpg)

仕様の輻輳とは
• 「仕様の輻輳とは，エンジニアのロール外で，納期や仕事量や顧客間で調
整が必要な要件変更などを，立場上の差（顧客と請負など）を利用して求
め，それら解決が困難なジレンマ状態」とする．
※輻輳とは物が一か所に集中し混雑することであるが，
エンジニアに仕様についての物事が集中することを想起させる言葉として採用している．
• 仕様の変更は言い換えると仕様の対立
• 対立があるので解消のための調整が必要
• 仕様の対立によって生じるエンジニアへの仕様変更依頼が
増大していくことで輻輳はより深刻になっていく
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/9J29VRLZER.jpg)

（参考）仕様の輻輳を引き起こす事象
の例
• 仕様に関する，発注者と受注者での認識が異なっている
• 開発とは同期していない，ビジネス面からのリリース変更や機能追加のさ
しこみが生じる（確定していた要求が変わる）
• 前工程で要求が固まっていない，（顧客が）誤って承認してしまった等の
理由で，あとで要求の変更や追加，優先度付の変更が発生する
• 顧客側の手続きや納期的な面からの調整
• 仕様の実装のために複数の顧客担当者との調整が必要な場合
（例えば，サブシステム同士と繋げるためのインタフェース実装）
• ステークホルダーの連携不十分による，異なった，
同期しない仕様変更の発生
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/DEY43DQNJM.jpg)

仕様の輻輳が心理的輻輳も引き起こす
• 仕様の輻輳が発生したとき，その解決や沈静化にエンジニアは，要求や仕
様に関する手法を用いたり導入に挑戦したりすることで，事態の改善を図
ろうとしてきた．
• 実際には，手法のありなしにかかわらず，仕様変更依頼の量に加え，複数
の担当者との調整や仕様の輻輳は，エンジニアに心理的な負担を生じさせ，
それが大きくなることでいわば「心理的な輻輳」を引き起こさせる．
• いわゆる「いっぱいいっぱい」な状態になってしまい，
仕様の輻輳を解消するための調整すらも進まなくなる．
• 結果として開発も進まなくなることで，
エンジニアはより精神的に疲弊し，
ますます事態は悪化していく．
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/VJNYV6KV78.jpg)

心理的輻輳を引き起こしている状況
• 担当者と，または本来の担当者とは別の担当者との調整に忙殺されている
• 直接アクセスできないステークホルダーへの確認の試みが生じている
• ロール外責務の，仕様の取り扱いレベルや実装スケジュール，開発リソー
スの調整
• 仕様変更解消に向けたプレゼンテーションの準備と実施，フォローアップ
• etc...
果たして，これらは本来エンジニアの仕事だろうか．
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/YE9P6LVVJ3.jpg)

仕様の輻輳を抑えるのは本来PMの仕事だが
• 顧客との，仕様の内容変更や優先度・重要度，スケジュールやリソース配分等の調整は
本来PMが実施するべきことであり，プロセスで解決するべき問題である．だがエンジニ
ア個人は，その生真面目さにより個人技で解決を図ろうとして沼にはまってしまう．
• 仕様の輻輳が起きた場合はその解決をPMやステークホルダーに調整や判断を委ねる．
• 委ねるためには，仕様の対立や輻輳における全体像を理解し，
然るべき対策に分け，そのうえで委ねる必要がある．
• もちろん仕様の輻輳そのものも理解する必要があるし，
テークホルダーが仕様の輻輳にどのようなかかわり方をしているか，
さらにはその大きな背景である，国内特有の受発注文化等も．
• 理解することが多いため，モデル化等の方法を使い全体理解を
しやすくすることが必要．
モデルがあることでステークホルダー間での仕様の輻輳の抑制について
議論がしやすくなる．
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/GE8DZXP4ED.jpg)

再掲：概要・・・変化
• 機能の増大と複雑化が拡大
• その原動力：OSSなど権利制約が緩和され流用技術の拡大
• スキルが「作る」（自由度）から「連携と設定」（制約）に変化
• 仕様作りに大きな変化【技術的輻輳】
• 要件と実現方法とのギャップ拡大
• 全体が解るコアエンジニアでも難しいタスク
• 見えてる世界の差が拡大【文化的輻輳】
• 利用者，調達者，営業，などステークホルダ
本ＦＰセッションでは
こちらの観点を中心に議論
• 設計者，実装者，テスト設計，品質保証，などなど
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/LELMD81V7R.jpg)

本FPでの議論提起
16


# Page. 17

![Page Image](https://bcdn.docswell.com/page/4JMYP6WNJW.jpg)

問題は何か
•
ITエンジニアの深刻な課題
•
•
自身の分野外との（対人）交渉スキル問題
現象：「仕様の輻輳」に陥る
• 主任務が遂行できない
• 異文化遭遇で「狼狽える」
•
•
業務やプロジェクトへの影響 -> 失敗
本人への影響 -> 心理的疲労
17


# Page. 18

![Page Image](https://bcdn.docswell.com/page/PJR91PY479.jpg)

問題の背景
•
経験を積みリーダになると
• 未経験の対人スキルに遭遇
• 特に外部（社内外ステークホルダ）
• 異なる文化・風習 真逆の文化：
• 仕様策定
• ロジカル
VS. 駆け引き
VS. ポリティカル
18


# Page. 19

![Page Image](https://bcdn.docswell.com/page/PEXQY3GZJX.jpg)

提案は
•
職業人としてのＩＴエンジニア訓練
•
•
特にリーダ予備役に対して
ステークホルダとの対峙力
•
２つの要素
• １．メンタルマッチョ/防具
• ２．専門性による貢献/発動スキル
会場議論ではこちらを議論
19


# Page. 20

![Page Image](https://bcdn.docswell.com/page/3EK93Y4VED.jpg)

１．メンタルマッチョ／防具
•
1.1メンタルマッチョ
•
•
•
ITエンジニアのメンタル．マッチョ化
•
かなり困難
•
•
こっちの方が現実的
但し，ＩＴスキルの深さより交渉人ロール
メンタルマッチョ人材のITエンジニア化
1.2 防具
•
•
•
心理的危険を防護するスキル
異文化交流スキル
•
異なる文化・習慣への対応スキル
•
•
仕様化などＩＴの世界
ビジネス交渉や社会習慣（世渡り
分別スキル
20


# Page. 21

![Page Image](https://bcdn.docswell.com/page/L73WG9DQ75.jpg)

2. 専門性による貢献/発動スキル
•
2.1 協働感と役割
•
•
•
まず仲間感を作るスキル
•
•
× エンジニア感を出す＝異質のアピールでまずい
まずは仲間感
•
•
そのなかでの役割，貢献の主張
全体像の把握と相手の立ち位置認識が必要
ステークホルダとの価値共有
2.2 発動スキル
•
相手から見て特別な貢献スキル
•
•
主業務である仕様化スキル（対外態度）
対ステークホルダとの対峙線（役割）
•
•
•
特に，内側・・・全体像を理解し
何が，何時迄に，いくら（資源）で可能か
実践上の見積もり
21


# Page. 22

![Page Image](https://bcdn.docswell.com/page/87DK1GPWJG.jpg)

まとめ
•
職業人としてのスキル不足
•
•
現材の人材育成：専門スキルばっかし
結果，同種スキル集団内でしか働けない
•
•
OJTで成熟できるはずだが
•
•
つまりアシスタント養成？
結果的には残念な状況
実学としてのエンジニアリング
•
•
•
技術リーダ育成
•
•
職場経験型の破綻 -> 変化に対応できていない
どんなスキルが必要でその習得方法は？
•
全体像の把握，シンセシス
•
異文化交流，変革型
技術面
リーダシップ面
22


# Page. 23

![Page Image](https://bcdn.docswell.com/page/VJPKQ3NXE8.jpg)

会場議論
23


# Page. 24

![Page Image](https://bcdn.docswell.com/page/2EVV54K3EQ.jpg)

本FPでご議論いただきたいこと
• 本FPでは仕様の輻輳および心理的輻輳について議論提起したが，現時点で
はあくまで思索にとどまる．
• 本FPでは当事者たる現場のエンジニアより「自身や身の回りに起きている
仕様の輻輳」について例示いただき，それらが持つ特質や特徴，特に解決
すべき課題はなんなのか，複数の事例に共通している課題は何かといった
ようなことの議論を期待する．
24


# Page. 25

![Page Image](https://bcdn.docswell.com/page/57GL61QYEL.jpg)

議論の進め方
• 議論３つを時間を切って進めます
• 白熱してても時間満了で次の議論に移ります
• 輻輳の構造として，エンジニア（チーム）と相手（外）とする
• チーム内での輻輳は今回議論スコープ外
（ex．エンジニアvsエンジニア，エンジニアvsマネージャ）
• 発表者と発言者の1vs1の議論ではなく，会場にいる全員での議論とな
るように発言者はお気遣いください
• 特に，当事者であるエンジニアの方々の積極的な発言を期待します
（若手の方、ぜひ！）
• 関連した新たな視点の提供や問題表明も歓迎です
25


# Page. 26

![Page Image](https://bcdn.docswell.com/page/4EQY4DK6JP.jpg)

議論１
当事者の事例の共有
「自身や身の回りに起きて
いる仕様の輻輳」について，
エンジニアの皆さんの実体
験事例の共有と見解。
26


# Page. 27

![Page Image](https://bcdn.docswell.com/page/KJ4WQZPM71.jpg)

議論２
メンタルマッチョ／防具 に関して
•
1.1メンタルマッチョ
•
•
•
ITエンジニアのメンタル．マッチョ化
•
かなり困難
•
•
こっちの方が現実的
但し，ＩＴスキルの深さより交渉人ロール
メンタルマッチョ人材のITエンジニア化
1.2 防具
•
•
•
心理的危険を防護するスキル
異文化交流スキル
•
異なる文化・習慣への対応スキル
•
•
仕様化などＩＴの世界
ビジネス交渉や社会習慣（世渡り
分別スキル
27


# Page. 28

![Page Image](https://bcdn.docswell.com/page/LE1YPR9Y7G.jpg)

議論３
専門性による貢献/発動スキル について
•
2.1 協働感と役割
•
•
•
まず仲間感を作るスキル
•
•
× エンジニア感を出す＝異質のアピールでまずい
まずは仲間感
•
•
そのなかでの役割，貢献の主張
全体像の把握と相手の立ち位置認識が必要
ステークホルダとの価値共有
2.2 発動スキル
•
相手から見て特別な貢献スキル
•
•
主業務である仕様化スキル（対外態度）
対ステークホルダとの対峙線（役割）
•
•
•
特に，内側・・・全体像を理解し
何が，何時迄に，いくら（資源）で可能か
実践上の見積もり
28


# Page. 29

![Page Image](https://bcdn.docswell.com/page/GEWG21Q1J2.jpg)

クロージング
29


# Page. 30

![Page Image](https://bcdn.docswell.com/page/47ZLDPWXJ3.jpg)

今後の議論
• 「仕様の輻輳」「心理的輻輳」の定義
• 「仕様の輻輳」「心理的輻輳」のモデル表現
• モデルの活用検討や活用のためのスキル定義
• スキル獲得のための教育
• その他関連する事柄
これらをSSのWGで継続議論をしていきます！
関心がある方はぜひ議論に加わっていただきたいです！
30


# Page. 31

![Page Image](https://bcdn.docswell.com/page/YJ6W1MGPJV.jpg)

続きは，WGにて
• WG6: エンジニアの処世術 ～企業人の側面～
• リーダ: 池田 暁(クオリティアーツ)，増田 聡(東京都市大学)，金田 直純，衣
笠 俊，横山 晃生(NDKCOM)
• 概要 (200 ～ 300 字):
• 日本企業の多くは，業種業務で独特の雇用文化・風習を持っており，エンジニア
に対しても常識として，その風習に従うことを暗黙に求めている．仕様を厳密に
決めないと仕事が進まないITエンジニアにとって，この風習に接する機会が少な
いことから，様々なジレンマを生んでいる．
• エンジニア側からは，心理的安全などの声が上がっているが，雇用側や発注側も
合理的な意思疎通ができない課題を抱えている．一種のダイバーシティ問題に属
すのかもしれないが，問題を整理し出口を求める．
31


# Page. 32

![Page Image](https://bcdn.docswell.com/page/GJ5M4ZVPJ4.jpg)

活発なご議論
ありがとうございました！
池田 暁
松尾谷 徹
クオリティアーツ
デバッグ工学研究所
32