SIer でソフトウェアエンジニアが評価されない理由
大手 SIer にもなれば色んな部隊があって、製品開発や技術調査といった仕事に携わることもできる。しかし、だからといって、ソフトウェアエンジニアとしてハッピーかというと、そんなことはない。制度的・文化的な壁に阻まれる。
一人の万年平社員エンジニアとして日々感じている「壁」を、「評価されない理由」と題して言語化してみた。
- 1: 平社員に裁量がない
- 2: 社員に人権がない
- 3: 契約、予算、人月による拘束がきつい
- 4: エンジニアとして評価される軸がない
- 5: 全員にアプローチ(発信・共有)できる手段と文化がない
- 6: 負債という概念に無頓着
- 7: 日本企業的「家族ごっこ」が蔓延している
- 所感
1: 平社員に裁量がない
平社員は「上司からの指示命令で動く機械」とみなされている。自分の裁量で行動することが想定されていないため、エンジニアらしく自立的にバリバリ動いていると悪目立ちし、釘を差される。
- 平社員 ≒ 上司から言われたことをやる人
- 平社員 ≒ 指揮監督がなければ動けない、未熟な人
- 何かをやるなら上司に相談して許可を求めるべきという暗黙の了解
- 平社員が(上司を通さず)自分の裁量で行動することは想定されていない
- 想定されていないがゆえ、そんな行動を取れば上司が不機嫌になる
- 上司も人間が出来てる(ことが多い)ので表面上は何もないが、応答や承認の悪さといった形で表出してくる
- 上司「お前が勝手に動くと俺が管理してないように見られるだろうが」
平社員エンジニアは「上司が管理監督する村(チーム)の一員」であり、勝手に外に出ることはできない。外に出るのは村長(上司)の役目であって、村人たる自分は村長経由で外からの情報を得るだけだ。そういう未熟な存在だとみなされている。
ゆえに上司の許可無く部門やチームの外を超えて発信することさえも認められてない。たとえばプライベートでブログ書いたり GitHub にアップしたりするのと同じ要領で「自分の成果を全社員に公開する」なんてことは許されない。「勝手に何してんの?」「俺の顔に泥を塗る気か?」となる。
2: 社員に人権がない
人権がある(まともな PC 環境がある)ケースは稀だ。
PC ハード:
- 32GB/SSD は夢の世界
- 16GB/SSD もありえないかなぁ
- 研究開発部門やよほど交渉が上手い人なら手に入るかも
- 16GB/HDD、8GB/HDD は優良な SIer ならある
- 4GB/HDD は割と普通
- 劣悪な SIer だとそれ以下も
OS:
- Windows デフォ
- Mac はよほどの理由が無い限り無理
- 業務で iPhone アプリ開発してるなど「業務上の理由」が必要
- 個人改善レベルの理由では通らない
PC ソフトウェア:
- フリーソフト・OSS はいちいち申請・承認が必要
- 申請は長ったらしいエクセル
- 過去記事にも苦悩が現れている のでよろしければ読んでください
机と椅子:
- 机
- 狭いオフィスにごった煮気味なので広くない
- 27 インチディスプレイを横に 2 枚並べられる広さでも恵まれた方
- パーティションとかないので向かいの顔見える、落ち着かない
- 事務用品なので「引き出し付属」デフォ、無論隔離しておける場所も無い、邪魔
- 椅子
- 安物の事務用品
- アーロンチェア……とまでは行かずとも、肘掛け付きのワーキングチェアさえない
- メンテされておらずギーギー鳴ってうるさい
- 備品なので勝手に油差し込むとかも無理
挙げればきりがないのでこの辺にしておくが……。
大手 SIer(というより大企業?)では「大量の社員を画一的に扱う」「社員 ≒ 非エンジニア(ICT リテラシーをあまり持たない)な人たち」という前提で各種制度・体系・環境が組み立てられているので、エンジニアが不便・窮屈に感じるのはデフォ。
一方、非エンジニア達は何とも思っていないこともままある。問題なのは上司など「承認する側」が非エンジニア側の人間だということ。彼らにはエンジニアの要求は「個人的なわがまま」にしか見えないため、環境絡みの要求は一蹴されるのがデフォ。
3: 契約、予算、人月による拘束がきつい
SIer では仕事を管理しやすくするために「人月」という単位を使う。人月とは「社員一人が一ヶ月働いた時のコスト」を表す。一日単位の「人日」もよく使われる。
これを使って、SIer では社員は以下のように管理される。
- 社員は毎日どのプロジェクトに何時間使ったかを正確に記録しなければならない
- 案件 ≒ xx 円で ~~ を成し遂げてください
- 人材の投入方法
- 平社員の 1 人月が a 円、管理職の 1 人月が b 円
- xx 円あるなら平社員は ~~ 人、管理職は ~~ 人投入できるよね
- 予算の消費 ≒ 人月として費やすこと
- 予算を達成するには? ≒ 指定量分の人月を消費する
- ……
要するに「あなたはプロジェクト A に x 時間、プロジェクト B に y 時間使ってね」といったように 期間と人月で行動が縛られる。これは予算達成や顧客契約にも絡むので抗えない(ことが多い)。
当然ながらプロジェクト A や B の直接作業以外の一切は「関係ないこと」とみなされてしまう。自己学習や改善に費やせる余地はない、というか(アサインされた以上は)許されていない。
下手に「~~しました」とアピールしようものなら「何サボってんの」となる。たとえ結果を出している(工夫して時間を捻出してそこで活動している)のだとしても、「そんな暇があったらもっとたくさん仕事しろよ」「もっと早く終わらせろよ」と思われるだけ。
ちなみに、こんな制約もある。
- 社員は毎日、定時間分は何らかのプロジェクトに従事しなければならない
- プロジェクト ≒ 金になる何らかの案件
- 平社員の「~~を試したいです」「改善したいです」は案件にはならない
- こういう投資や社内改善を案件にしたいなら、それはもう壮大な手続きと社内政治が必要に。。。
エンジニアに自由はない。
4: エンジニアとして評価される軸がない
まずは現在の制度や性質をつらつらと挙げてみよう。
キャリアパス:
- 概ねこんな感じ
- 平社員
- リーダー
- 管理職(係長)
- 部長
- ……
- 技術使って手を動かすのは平社員まで
- リーダー以降は「技術使って手を動かす人」をコントロールする立場
給料:
- 昇進しないと劇的にはアップしない
- ボーナス無し残業無しなら月手取り 20 万が上限ではなかろうか
- 昇進したらこれが 25, 30, 40, 50……と増えていく
評価されること:
- xx 円稼いだという実績
- ≒ 大きな SI プロジェクトに属して、その下で働いて成果出す
- xx 円稼げる案件を獲得したという実績
- ≒ 渉外力と人脈が求められる世界
- 上司や上位上司に気に入られること
- 制度上、昇格要件を満たしても大人の事情で覆る
- 大人の事情 = 「彼らが話し合って決める」というブラックボックス
評価されないこと:
- 利益として直接数字に出ない活動
- 技術的に高度なこと
- たとえば社内で前例がないことを成し遂げても評価されない
- 技術はあくまで手段
- モダンな開発手法や OSS を駆使してキレイにつくろうが、素人が地頭と根性で手続き的クソースで汚くつくろうが、評価に差は出ない
つまり技術どうこうで勝負しても評価されない。評価されないから昇進もできず、給与も増えず、したがって生活にも余裕が持てない。単身者はさておき、(共働きでない)世帯持ちの平社員はほぼ 100% が生活残業に頼っていると言っても過言ではないだろう。
評価されたいなら「(既に稼ぎ柱となっている)SI プロジェクトで揉まれる」「上に気に入られる」が必要。
※ここで「技術的に高度なことをしたなら、それを社内に広めればメシの種になるのでは?」と思われるかもしれないが、散々上述したように、そのような提案・啓蒙は一平社員には行えない。そもそも高度といっても、せいぜい Qiita にいるような Web エンジニアにとっては当たり前の水準にすぎないため、「そんなに強いならさっさと転職すればいいじゃん」ともならない。そこまで強くないからこそ、リスクを考えて SIer に留まるしかないのである。
5: 全員にアプローチ(発信・共有)できる手段と文化がない
発信(共有)できることはエンジニアの武器であり価値である。不特定多数に発信することで誰かの役に立つし、フィードバックや繋がりやチャンスも生まれる。インターネットもソフトウェア文化もそうやって発展してきたし、エンジニアもこれに乗っかって自らを広げることができた。
しかし SIer では不可能だ。
- 手段がない
- そういうプラットフォームが存在しない
- たとえば個人がブログやリポジトリをつくって全社員に発信することさえできない
- 無論、インターネットに発信するのも NG だし、申請したところで許可などもらえない
- SIer がネット上で発信していないことからも明らかだろう。
- 文化がない
- 当たり前のように発信するのはエンジニアだからこそ
- 非エンジニアにとって「発信」とは普段から縁がなく、意識もしない行為
- 所感
- 「Twitter で Public に発信してる」率は 5% もない
- 「月に複数回以上ブログでアウトプット」率は 3% もない
- 「GitHub で 100 Contributions 以上」率は 1% もない
- 非エンジニアには発信に要する能力と経験が不足している
- むしろ「形に残る文章を残したくない」という保身的な嫌悪感を持つ人も多い(組織の上に立つ者はこういう世界っぽい?)
- 残すにしてもパワポで丁寧につくったレベルの資料のみ
6: 負債という概念に無頓着
技術的な負債を防止、回避、低減するという発想がない。そもそも負債という概念を知らない。
- 丁寧な設計、テスト、自動化などで高品質を担保しても評価されない
- むしろ「こだわりすぎ」「いいからもっとスピード出せ」
- それよりも突貫クソースで形にした者が正義
- 出世してる人は大体これ
- 持ち前の地頭でゴリ押しクソースを書いて乗り切る
- 評価されて昇進してプロジェクトやチームを離れる
- 後でメンテする人がクソース苦しむ、でも書いた人いないから詰む
そういうわけでエンジニアはストイックに(負債を認めないという)自分を貫かないと、すぐに負債を背負わされることになる。というかそもそも携わる仕事の大半が「負債を抱えたプロジェクトのメンテ」だという現実も。
7: 日本企業的「家族ごっこ」が蔓延している
日本企業(SIer含む)全般に当てはまること:
- 仕事ではストイックに生産性や効率を求めてもばちは当たらないが、彼らはそうしない
- その最たる例が「ダラダラ会議をする」こと
- これの根本的原因は 家族ごっこ にある
家族ごっことは:
- 家族のような「一緒に過ごすことに対して生産性や効率を要求しない関係」を運用すること
家族ごっこの効用:
- a) 単純に居心地が良い
- b) 家族というコンテンツが生まれる
- c) 愛着や親愛を積むことができる
- d) 上下関係をつくることができる(親→子、上司→部下)
- a と b があれば暇しない
- c と d があれば「テキトーに根性と協調で頑張る」ことができる
- 戦略や改善といった「知的活動」に頼らずに済む
一方、エンジニアはこの家族ごっことはそりが合わず(合わないことが多いように思う)、非生産性や無駄が目につく。しかし、これらを指摘・是正しても受け入れられることはない。なぜって、そもそも会社は家族ごっこをしているのだから。生産性や効率という概念そのものが場違いなのである。どころか「人でなし」「機械」「利己的」「自分勝手」といった烙印さえ押されかねない。
所感
今回言語化してみたが、ここまでとは……。
※僕というエンジニアの、狭い観測範囲の話なので、一般論として言えるかどうかはわからない。参考までに。
SIer(というか企業全般)ではソフトウェアエンジニアの文化や価値観がまるで通じないことがわかるだろう。ソフトウェアエンジニアは極めて特殊な人種なのかもしれない。
ゆえに、エンジニアらしく活躍したいなら、同じ人種がデフォであるようなコミュニティや界隈に行くしかないのだろう。それがいわゆる Web 屋なんだろうと思う。