第18回SPIトワイライトフォーラム

エンジニアのトリセツ

~やりがいのある職場と育成~

後編:深層を探る

– 少々毒があるので注意 –

後編 概要

  • 概要
  • ITエンジニアの人的資源管理・・・働かせ側
    • 経営学から
    • ソフトウェア工学から
  • 働きやすい職場・・・・・・・・・働く側

1.人的資源管理

働かせる側の基礎知識(経営学)

  • ホーソン実験
  • オハイオ実験
  • PM理論
    などなど

企業経営の3要素

素人向けですが,本質として

  • 戦略:何に重点を絞り込むのか
  • 組織化:戦略実現のための役割設計と実装
  • 労働意欲:社員のモチベーション維持

プロジェクトでも同様

IT系だモチベーション維持の部分が弱い

  • エンジニアなど従業員側の問題と考えている?

歴史的に振り返ると

  1. テーラー理論:
    • 20世紀初頭に生まれた元祖プロセス改善
    • 科学的な管理(経営工学)
  2. ホーソン実験:
    • 誤ったテーラー理論の実践者<人間機械論者>打破
    • 人間関係論
  3. オハイオ実験:
    • リーダーシップの2因子
    • 人への配慮行動
    • 民間企業ではミシガン実験
    • 日本では三隅先生のPM理論

ホーソン実験

  • 100年ほど昔
  • 第一次世界大戦後の復興景気が終わり大不況
  • 企業は生き残りのため生産性/品質(歩留まり)向上
  • 結果,労働強化:日本では女工哀史,蟹工船の時代

  • 労働強化に頼らない生産性向上を探る
  • テーラー理論の拡大のために実験
  • 照明や気温など職場環境と生産性を計測

  • 環境を悪化させた実験 ー> 生産性が上がった?!
  • 失敗!!
  • 未知の力が潜むことから10年以上の研究

ホーソン実験の原因

  • 被験者の女工さんの勘違い
  • 非公式な場(食事や休憩時間)で
  • チームの達成意欲が芽生えた
  • 人間関係論
  • 初期の成果は,非公式なコミュニケーションが大事
  • それほど単純では無いが,意欲の影響の研究スタート

チームのパフォーマンス

ホーソン工場は単純作業のチーム,高度化すると

最大の影響因子はリーダーシップ

  • リーダーシップの中身は何か??
  • 東西冷戦時代(50年ほど昔)
  • 米空軍:戦略爆撃隊(超エリート)
  • 機長(准将クラス)の影響を調べた
    • 同じ機材,クルーで大きな差が存在

  • リーダーの行動の何が影響するのか?
  • リーダーシップ行動論の始まり
  • 結果は2因子:仕事と部下配慮

日本では集団力学研究所のPM理論

  • 同じ頃,公務員や教師について計測
    • 硬い仕事(定常的な仕事)
  • P行動:課業を達成するための行動
  • M行動:集団維持のための行動

その後,場面に応じたリーダーシップ行動論

チームのパフォーマンス基礎まとめ

  • リーダーシップ行動
    • 具体的には適切なP行動とM行動
    • 問題リーダは,どちらかが欠如
  • チームの達成意欲
    • 簡単には作れ無い
    • チームを作る+維持

IT系企業のマネジメントや人事系の

専門知識不足

2.ソフトウェア工学

新たな労働形態

NATOプロジェクトの失敗から学び始める

  • 構造化プログラミング:ダイクストラ博士
  • COCOMO:ベーム博士
  • 個人,チーム,組織:ハンフリー博士

ワッツ S.ハンフリー博士

  • 皆さまの教祖様
  • ソフトウェア開発を3形態で区別
    -「組織」の側面だけでなく
    -「個人:PSP Personal Software Process」
    -「チーム:TSP Team Software Process」
  • 組織とは,軍や銀行などの大型調達
    • 技術問題だけでなく何百人の人を動かす場合
    • チャラチャラした技術やToolよりプロセス改善
  • 個人:経験や能力やモチベーションにより2桁の差
  • チーム:10倍程度の差がある

3つは全く違った特性

残念なチームはプロセス改善では救えない!!

元祖:チームの生産性

構造化プログラミンの発見過程

  • ダイクストラ博士は数学者
  • 世界的な企業からの依頼で生産性問題を調査
  • チーム別の生産性データを入手し分析
  • 非常に高生産性チームを詳細に分析
    • 強いリーダーシップ
    • コーディング規則を持っていた
    • レビュー効率を高めるため
  • チーフプログラマ制(棟梁型)の根拠
  • 日本での展開(笑い話)
    • 規約は守がレビューしない(出来ない)
    • よって効果なし

言語の型安全でもこの勘違いが生じている

実証主義:ベーム博士

  • 80年代にCOCOMOを発表
  • COCOMO(constructive cost model)
  • 64のプロジェクトについて計測しモデル化
  • その原因を見積もり因子として表現した
  • 最大の因子はチーム力
  • 日本でも大規模な調査が行われ同様な結果

日本のIT企業に不都合なデータ

  • 生産性はチームにより10倍の差がある
  • この事実が広がると工数ベースビジネスは破綻
  • 企業は底上げに注力(同時に高生産性チームは駆逐)
    • 個人の資格と組織のプロセス改善でごまかした

3.近未来は?

2〜3年先ですら誰にも解らないが

よって私見です

徐々に変化が顕在化する

  • 産業構造が変化している
  • 製造業的な企業から本格的なクリエイティブ型へ
  • 「組織」型のビジネスも残るが維持レベルか?
  • 規模的な生産性(コスト)の価値は相対的に低下
  • より,新規性+スピード
  • 新規性は,プロダクトよりサービスへ
  • サービスは主に様々な接続により生まれる
  • その価値は市場での試行錯誤から

それらの根源は,

クリエイティブなチームや個人

規範を守るだけでは価値を産まない

働き方の変化,働かせ方の変化

  • 2001年にITエンジニアの仕事満調査
    • 1500名規模
  • 従業員の枠組みでは出来なかった
  • パートナー満足と命名して実施

  • ITエンジニアは企業に対する忠誠心が他よりかなり低い
  • 今までとは違った労働階級の出現??
    • 日本では成功例が少ないが
    • 世界的にはチャンスの大きい仕事

日本型企業運営の問題

なぜ日本のITビジネスが異常なのか

伝統的な企業は非効率な企業運営

  • 会議に忙殺:会議とその資料作成の割合が異状に多い
  • 会議の目的:2種類
    1. 縦割り組織の運営会議: 御前会議をトップにtree構造
      • ここで問題にならないように調整と合意形成
    2. そのための準備会議:XX会議の予備会議,XX対策会議
      • 子組織間の失敗しない競争と閉鎖性
      • 2重帳簿的な階層間の報告
  • 江戸幕府の頃と変わらない組織文化【身分階層型】?!

いいけど,エンジニアを巻き込むな!!

巻き込まれると,規範重視の管理社会

このままだと

  • 伝統的な企業の企業文化—簡単には変わらない
  • 職場の立場から
    • 人的資源管理や労務管理の導入へ動く
    • エンジニアの活性には遠い
  • エンジニアの立場から
    • 転職の増加
    • スキルに自信が無くとも自己成長面から転職
  • 結果として,産業構造の変化

日本的な企業文化

演繹的なあるべき姿

  • 滅私奉公的な立派な考え・・・反論できないが非現実的
  • コンプライアンス的・・・労働時間や働き方
  • 夢物語的・・・伝統的な各社のHPに書いてある

ちょっと現実とは違いますね

現実的なあるべき姿

  • 成功事例や失敗事例から学ぶ<実証主義>

現代における経済成長

  • クリエイティブなビジネスの成功
    • 既存ビジネスの品質や生産性向上ではない
  • その推進力<カリスマリーダーシップの次は>
    • クリエイティブ人的資源
    • そのトリセツ

成功企業のトリセツ

  • 基本は労働市場からクリエイティブ人材を集めること
    • 人材が逃げない対策ではそもそもダメ
  • そのために企業側は
    • 「才能」学歴だけでなくチャレンジ精神
    • 「寛容性」多様性を認める職場文化
    • 「経験への開放性」新しい経験に対する好奇心
  • これらを尊重した採用や処遇を示し
    実際にその職場文化を作っている

日本人的には行き過ぎも

  • 寛容性:
    • 男女別トイレの廃止!!
      ひえー・・・・
  • 大丈夫
    • 普通の日本企業のエンジニアや大学の先生が
      GXXXXeから招へいされることは極めて稀

4. 現実的な第一歩

  • 現状に対する警鐘を鳴らす
  • トリセツのお手本となる成功事例
  • 「トリセツ」「アンチトリセツ」などへ

成功事例

  • プロジェクトレベルでの成功事例は多い
  • フェリカネットワークスなど

「トリセツ」「アンチトリセツ」などへ

  • エンジニアが企業や組織に貢献すること
    それに対する正当な処遇・・・・ちゃんと説明する
  • 企業レベルの前に,プロジェクトにおいて宣言する
  • そのためのスケルトンを作って行きたい

まとめ

  • 忍び寄る過干渉とその弊害
  • 日本の大企業型IT没落の遠因?
  • クリエイティブ型エンジニアリングに向けて

参考書

フロリダのクリエイティブ資本論

ご清聴ありがとうございました.