ソフトウェア・シンポジウム in 宮崎

エンジニア人材を死滅させるマイクロマネジメントの打破〜エンジニアを活かし育てるトリセツ活動の提案〜
松尾谷徹
デバッグ工学研究所

matsuodani@debugeng.com
要旨と扱い方＝「トリセツ」(取扱説明書) を明らかにする必要がある．

企業の IT 関連職場において，エンジニアの悲痛な叫

ソフトウェア以外の伝統的な機械や電気の分野においびを聞くことが増えている．叫びの多くは，日々の仕事ては，エンジニアを貴重な人的資源とし，雇用側はそのとして，その活動の意味が見いだせない無駄な作業に忙活躍の場と処遇を一般的な雇用者とは区別して提供し，殺されていることから生じている．現代の若者に我慢が育成している．何故ならば，彼等の貢献によって製品や不足していると切り捨てる管理職も存在するが，決してサービスの価値を高め，企業や組織を維持発展させていそうではない．

るからである．

エンジニアは，製品やシステムやサービスにおいて，日本におけるソフトウェア産業は，歴史的な経緯から維持するだけでなく付加価値を生み出すことが求められエンジニアも含め人的資源を消費原料的な作業工数としている．その原動力はクリエイティブな人的資源によるて取り扱ってきた．管理（監督）の現状は，非熟練者に創造的な工夫や変革であり，規範的なプロセスの遵守だ

よるマニュアルに沿った作業の監督と位置付け，量的生けでないことは明白である．

産性，品質の底上げ，納期遵守といった低レベルの管理

しかし，多くの職場レベルのマネジメントは規範的なに留まっている．

側面が詳細に強化され，厖大な手続き的な作業を押し付

では，どのようにしてこの慣習的な問題を解決して行けるマイクロマネジメントが蔓延している．結果的に，

くのか．ここは次の項目に分けて考える．

付加価値を生まない活動にクリエイティブ人材を投入することになり，付加価値が生まれないばかりか，人材を

1. 現状の認識と対策としての見える化

疲弊させ，組織自身をも衰退させている．この現状を明

2. マイクロマネジメントの原因と対策らかにし，この流れを断ち切るための提案を行う．

3. あるべき姿に対するコンセンサス
4. 現実的なトリセツのテーラリング

1. はじめに
2

この主張は，エンジニアの地位獲得を進めようとするものであるが，経済的な地位など利己的なものでは無い．
現代のエンジニアに求められているパフォーマンスを発現状の認識と見える化
大手広告企業における悲しい事件をきっかけに，企業の職場における管理の問題が明らかになりつつある．顕揮し，社会や組織に貢献するために，雇用主や社会に求在化した問題とは労務管理の最低限のレベルである労働めるものである．エンジニアが付加価値生産性を高める時間ですら長年に渡って違法状態であり，それを自律的クリエイティブな成果を出すには，自由な発想と試行錯に改善出来なかったことである．事件は，超過した労働誤が必須であり，それをサポートするエンジニアの処遇時間が原因ではなく，クリエイティブな人材に対する管193

SEA

ソフトウェア・シンポジウム in 宮崎

理規範＝トリセツが未成熟で，封建時代の滅私奉公のよの実現性は高い．

うな主従関係の考え方に近い人的資源管理に本質的な原

職場の状況を客観的に見える化するための計測手段と因がある．

して，質問紙，分析ツールなどを作成するのはさほど困識者が指摘するように，本質的な問題は２つに分類で難ではなく，実績もある．実際の運用方法については検

きる．１つは組織の末端における職場が閉鎖的であり，討が必要で，匿名で第三者が行い，人事評価など意図し未熟な管理が行われてもそれを検知し回避することがでない利用による弊害を防ぐ必要がある．

きないことにある．逆に隠ぺいし悪い方向に強化されて事例もある．

3

マイクロマネジメントの原因と対策

もう１つは，末端の職場で異常な管理を行う者の管理規範にある．多くの場合は，管理に関して未熟な者が独

なぜマイクロマネジメントのような不適切な管理が自善的な考えで管理行為を行うことにあるが，その職場や然発生的に多発するのかについて考える．マネジメント

組織において慣習化している場合もある．の中に人的資源のパフォーマンスを高め育成する機能が，この項では，職場の閉鎖性について考える．問題が顕重要な要素として含まれていることを否定する者はいな

在化するのは，事件となった場合や，パワハラとして強い．しかし，末端の職場において大義名分的な育成機能い被害を受けた者が訴えた場合など，かなり悪い状況でより，日常の習慣的な管理機能が優先され結果として逆ある．この現象は，大学ではアカハラであり，家庭ならに人的資源のパフォーマンスを抑圧するケースが生じてDV である．現実として，これらのパワハラ類は顕在化に至らないが潜在的な状況を含めると，閉鎖的な主従関いる．習慣的な管理機能とは，進捗報告や予実管理，コ係において多発しており，根底には上司部下の関係を封チャレンジ的ではな実態は実効性の低い文書作成と打ち建的な身分関係と誤解している国民的な未熟から生じて合わせに忙殺される．

ンプライアンスや QCD 関連のレビューなどであるが，おり，簡単に解決できない問題である．

問題を起こす管理・監督者の多くは，人的資源管理のよって，国民性を変える前に，職場における過剰な閉職務に対して未経験でかつ専門的な知識も訓練も受けて鎖性を減らし，問題の兆候を検出する仕組みが必要であいない場合が多い．具体的には，エンジニアが職位が上る．いじめ事件などの事例では，組織側は隠ぺいの意図がり，未経験の管理・監督の職務に就く場合である．常が強く，組織側の調査結果はでは「いじめは無かった」

識的に考えると，高学歴で社会人となりそれなりの実務となり，後から第三者による調査（アンケートや聞き取を経た者が，マイクロマネジメントのような稚拙な行動り）で深刻な状況と兆候があったことが明らかになるこに走るとは考え難い．何らかの原因が存在するのではなとが多い．

いか．

見える化の手段としては，簡便な調査紙によるアン原因として考えられるのは，管理・監督の職務を身分ケート調査から，心理測定尺度の研究で明らかになった的な地位としてとらえ，君主的で指示命令すること＝管構成概念を用いてその構成因子ごとの得点と，ビッグ理者と考える時代錯誤的な勘違いである．経営学におけデータを用いた判別分析（AI 技術）を行う方法が考える人的資源管理の基礎知識からしても，現代ではあり得られる [1, 2]．

ない管理規範ではあるが，パワハラやアカハラの原因因IT 分野においては，JISA の援助を基に 2001 年に実子としては強い．

施したエンジニアのパートナー満足調査（PS 調査）がでは，何故このような稚拙な思い込みに走るのか．そある [3]．この調査は IT 系のエンジニア約 1500 名に対の原因は，職場の閉鎖性にあるのではないか．配属後，して主に「仕事満足」の観点から分析した [4]．閉鎖性

その職場一筋ですごし，社外の学会や業界どころか，社の打破のためには，これに加えて「不満足」の観点を追内の他部署とも社会的なつながりを持たないため，常識加する必要がある．

的な社会経験が無く，未成熟で独善的な行動に陥ると考もう一つのひな形は，職場のリーダシップ研究で良くえられる．

知られている「PM 理論」から，エンジニアが強い「不次項のあるべき姿とは分けて，人的資源管理の前提と満足」を生む因子を探る方法である [1, 5]．
「苦手な上司しての「トリセツ」が必要である．ベからず集のような／良かった上司」の比較研究も行われており，この方法

事例と対策的なものや，人を扱う管理への入門書的なま194

SEAソフトウェア・シンポジウム in 宮崎

とめ方が考えられる．

好奇心であり，これが欠如している職場では，チャレンジ精神が疲弊しクリエイティブ活動が芽生えない．この

4

あるべき姿を求めて「寛容性」「開放性」を柱にして，日本的な価値観である「育成」「チーム」などを加えた概念を想定している [9]マイクロマネジメントのようなとんでもない状況とは別に，目指すべきトリセツについて考える．理想ではな

5

現実的なトリセツ

く，現実的な姿としては，先行する成功例から学ぶ必要がある．理想とは演繹的な規範から導かれるもので，教トリセツについて，3 項ではトリセツ以前の課題につ科書的な美しい姿である．現実的な姿とは，事例などでいて考え，4 項ではあるべき姿について考えた．ここで実証されたものを意味する．具体的には，客観的な計測は，実際にトリセツを展開する局面について考える．展

や，実際のチームやプロジェクトの事例を基にした取り開する局面とは，展開対象の職場や組織の状況を考慮し，組みである [6, 7]

さらに既存の目指す考えも取り入れテーラリングを行う

ソフトウェアエンジニアのドメスティックな特徴もあ局面である．

るが，大きな括りでこの問題を捉えると，クリエイティ

テーラリングの概要を図 1 に示す．テーラリングのたブな活動と生産活動との対比問題と見ることができる．

めの情報は，トリセツを展開する職場や企業に適合させクリエイティブな活動が 21 世紀の産業を牽引しているるためのもので，２つの要素が考えられる．1 つは，貢ことは，多くの賢者が述べており，産業界においても献目標と示したもので，企業や社会で既に認められたエGoogle，Amazon など 21 世紀に躍進した多くの企業でンジニアの倫理やコンピテンシー（行動特性）である．

実証されている．この分野における先進的な考え方は，雇用側からすれば，トリセツの前提となるエンジニアのリチャード・フロリダによるクリエイティブ・クラスの義務や組織への貢献に関する期待（要求）である．

中の Super-Creative Core が近いと考えている [8]．

具体的な内容としては，企業であれば採用要件として「トリセツ」が目指す方向は，組織がクリエイティブ求めるエンジニアの資質であり，その内容は「チャレンな成果を出すための人的資源管理をステークホルダに解ジ精神」「やる気」などと表明されている．これらを汎りやすく示すことにある．ステークホルダとは職場を含用化すると，エンジニア倫理であり，現代において高いめ経営層や関係する顧客などを指す．具体的な「トリセ支持をうけているのは IEEE の Software Engineering

ツ」は，時代や状況によって変化するので，変化に対応

Code of Ethics である [10, 11]．
現実的なトリセツへの反映は，エンジニアの義務の確認である．これらの倫理が達成されているからこそ，して行く必要がある．あるべき姿は，抽象的であるが基本となる考え方に他ならない．
経済成長の実証研究から，成長に必要な要素が明らか

エンジニアにクリエイティブな成果を期待し，良い処遇になっており，それらのほぼすべては人的資源に関するものであり「才能」「寛容性」「経験への開放性」などが指摘されている [8]．
「才能」とは，スキルと野心であり，具体的には高学歴でかつチャレンジ精神を持つ人的資源である．多くの企業の採用基準であり，これは達成されている．
「寛容性」とは，多様性を認めることであり，エンジニア側からすると自由度である．陳腐化の早い分野において技術を維持して行くには，論文を読み，学会などの情報源に参加し，考え試して技術習得を自律的に行うための自由が必要不可欠である．管理・監督側は，その自由度を認め確保する寛容性が必要である．マイクロマネ
ジメントは，これに逆行している．

図 1: トリセツのテーラリング「経験への開放性」とは，新しい技術や経験に対する195SEA

ソフトウェア・シンポジウム in 宮崎

参考文献（トリセツ）を提供する．
もう 1 つは，対象とする職場の成熟状態である．マイ
クロマネジメントなど未成熟な状態と，クリエイティブ[1] 堀洋道，吉田富二雄，“心理測定尺度集 ii,” 2001．

な活動が進行している状態では掲げるトリセツの内容は変える必要がある．具体的な内容は，テーラリングによ[2] 松尾谷徹，“It に現場力は存在するのか: その計測と評価の試み,” ソフトウェア・シンポジウム，pp.1–8，
2014．

り職場の状況に合わせて解りやすく現実的な表現にする必要がある．
トリセツの内容自身は職場によって多少変化するが，エンジニアが主体的に働く原動力は，外発的報酬ではな[3] 松尾谷徹，“パートナー満足 (ps) と人的リソースのく，内発的報酬であることを理解する必要がある．IT 系

パフォーマンス,” プロジェクトマネジメント学会

エンジニアの内初的報酬は，満足度調査の結果から次の誌，vol.4，no.1，pp.3–8，2002．

通りである [4]．

[4] 榎田由紀子，松尾谷徹，“Happiness & active チー
ムを構築する実践的アプローチ: チームビルディン• 仕事から得られる「やりがい」• 自律的な工夫や進め方の自由「柔軟性」

グスキルの開発 (¡ 特集¿ コミュニケーション・マ• キャリアパスや自己成長「安定性」

vol.7，no.1，pp.15–20，2005．

ネジメント),” プロジェクトマネジメント学会誌，• 同僚からの敬意や良いチーム「仲間」

6[5] 三隅二不二，“組織におけるリーダーシップの研究(リーダーシップ–集団過程の社会心理学 (特集))–(現実の集団におけるリーダーシップの研究),” 年報社

おわりに会心理学，vol.14，no.11，pp.63–90，1970．

日本のソフトウェア産業は，1980 年代から高学歴のエンジニアを長年に渡って雇用し活動してきた．しかし，世界的な IT 技術やサービスの進歩と比べると，相対的[6] “感動するチーム,” http://itpro.nikkeibp.co.
jp/article/COLUMN/20090525/330593/．には衰退していると認めざるを得ない状況にある．その[7] 増 田 礼 子 ，“混 成 チ ー ム に お け る チ ー ム 力
向 上 の た め の 三 者 ヒ ア リ ン グ 活 用 事 例,”

一つの原因は，極端な例であるがここで取り上げたマイクロマネジメントのような，エンジニアに対する人的資源管理の稚拙さにある．

https://www.juse.jp/sqip/symposium/archive/2015/day2/files/ronbun_B3-4.pdf．

その原因は，職場の閉鎖性や封建的な主従関係と真面目な国民性から生じており，改善されるどころか維持さ[8] 井口訳リチャード・フロリダ，“新クリエイティブ資本論,” 2014.12．

れ強化すらされている．海外では，エンジニア倫理とそれに答える雇用側の処遇が，社会習慣として定着している．エンジニア倫理については，我が国でも多くの識者[9] 森本千佳子，“プロジェクト成功のためのコミュニが論じているが，雇用側の処遇＝人的資源管理についてケーション・ファシリテータ活用,” プロジェクトマ

はあまり議論されていない．

ネジメント学会誌，vol.14，no.4，pp.23–28，2012．

ここでの提案は，エンジニア倫理を持つエンジニアに対する，企業や社会のエンジニアに対する処遇改善であ[10] “Software
engineering
codeofethics,”
https://www.computer.org/web/education/

る．どっちが先かと言う鶏と卵の議論もあるが，後者が不足していると考えている．ここでの提案は，閉鎖性をcode-of-ethics.

打ち破るための見える化，エンジニアを指示命令で使う[11] “ソ フ ト ウェア エ ン ジ ニ ア の 倫 理（ 翻 訳 ）,”http://ethics.acm.org/wp-content/uploads/

リーダーシップは長期的な成果を生まない，良い人的資源管理のプラクティスを実証主義で積み上げる，実践には職場の現状に応じてカスタマイズが必要，などである．

196

2016/07/SE-code-jpn.pdf?60549e．

SEA