技術者が出した成果に対して、技術的な面での評価を出せる人がいない。そのため技術者がどのようなものを作ったかではなく、表面上は見栄えがいい報告、労働時間の多さといったものが評価されるようになる。そのため評価制度がほとんど機能しない。
毎朝のラジオ体操を行えばプログラマの生産性が上がると思っている。(非技術的な命令で効率を向上させようとする。)
部下の数が多い社員の意見が正として扱われる。技術的な正しさが追求されない。
マネージャーがプログラマの上位版と思われており、30過ぎてプログラマやってると「まだプログラマやってるの？」と嘲笑される。
技術採用を行うも応募者のプログラミングスキルを面接者が理解できない。面接担当「プログラミングなんて誰でもできる。業務知識のほうが大切なんだよ。」

技術をルールやマニュアルで管理しようとする

問題が発生しても技術的な面からの分析が行えない。そのため対策が対策の体をなしていない。
バグが見つかるたびに、公式サイトのQAをコピペしてきたような無駄に長い説明が手順書に追加される。誰も全容を理解できないマニュアルが出来上がる。
EXCELにあらかじめプログラミングする内容を書いておき、その内容が非技術者のレビューを通過することで品質を担保しようとする。なお出荷予定のソースコードは書いた人しか読んでいない。

非効率な開発手法が使われ続ける

技術に関するものの決済、承認を非技術者が行うため、開発ツールの買い替えが行われない。買い替えには非技術者へ効果を示すための膨大な手間が必要。
- 未だにVisual Studio 2008で開発を行う。
- CIツールはサーバを立てる経費がもったいないので使用不可。
外部サービスは危険なので使用禁止。
合言葉は「今までと同じやり方でコストダウン」。新しいやり方はリスクがあるので禁止。いかに今までと同じやり方で仕事をするかが重視される。
フリーソフトは可能な限り使用禁止。VimとEmacsは使用禁止。サクラエディタは可。

技術屋が逃げる

社外勉強会等で勉強しても勉強したツールが使えない、覚えたことが役に立たない、仮に勉強の成果を発揮できたとしても評価されない。そのような状況に直面した場合、技術屋はさっさと会社を辞めて評価してくれるところに行ったほうが幸せになれるだろう。

2018-06-24

ブラックIT企業の末路

システム開発

もうすでに崩壊した

よく聞く武勇伝で「バイト全員で結託して一斉に辞めました、もうこれであの店は終わりです。」みたいなのがあるけど、じゃあ実際に戦力が全員やめた企業はどうなるのか、そんな話。

体感としてはメルヘン・メドヘン(アニメ)を8話から見始め、今見たのが10話だったという状態に近い。

現在の年齢分布はというと、40~50がメイン層、25～35歳の先輩社員がいない、新人はたくさんいるという砂時計構造。本来もっとも活躍する層がいないというツラミ。

崩壊までの道のり

ある日突然、社員全員が裁量労働制になる。
裁量労働手当(残業20時間分)がもらえる代わりにいくら残業をしても残業代が出なくなる。実際は残業時間平均60くらい。今までは残業代が貰えるから仕事してたようなものなので社員全員のモチベーションが一気に低下。そもそも基本給も低く裁量労働手当を含んだ総額も低い。
優秀な社員から辞めていく。残ったのは仕事ができない社員のみ(俺含む)。若手はほとんどやめる。たぶん若手は結託して辞めたんでしょうね(俺以外)。
同年入社のやつら全員辞めたわつれーわ。
長老たちは俺たちは素晴らしいマネジメントをしていると主張。若手の給料を抑え、いかに自分がうまい汁を吸えるかどうかだけを気にするようになる。
長老「家のローンもあるし、息子の教育費もある、俺らは当然多く貰う権利がある。若者、知らねえ？俺らは今まで苦労してきたんだ！」

平均年齢高すぎ問題

若手を大量採用するも教育できる人がいない。高年齢は若者に対してコミュ障。
新人レクリエーションは登山。もちろん新人は強制参加。
新技術はとりあえず否決。「費用対効果を示せ！」「小学生にもわかるように説明しろ！」
自分ルールを振りかざしボトルネックを生み出す。「俺のエクセルシートならもっと短時間でコピペできるんだよ」
「VB(COBOL)しか分からないよ」

安い人材麻薬

今まで安くでいい人材を使えていたという成功体験が染み付いており、高くていい人材を使うということができない。
優秀な人に高報酬を用意するという発想がない。
新卒を安くで採用する、もしくはオフショアを利用するといったように、1作業者辺りの報酬を安くすることに腐心する。
今後人手不足で安くていい人材が招集できなくなるという可能性を考えていない。

地力の消失

優秀な社員はやめてしまったので、優秀かどうかを評価できる人がいない。
評価は労働時間のみ。長時間労働してる俺すごい → 長時間労働する社員すごい。
新人が書いたコードや、外注が書いたコードをろくに検証しないまま平気でリリースするようになる。検証ができないのはコード読まない、テスト設計考えない人が増え、人手の割にシステムの本質的なことを分かる人間がいないから。
顧客「高くて遅い」「もう新規で仕事任せられない」

結局どうなったか

仕事がなくなった。
新入社員の質が落ちた。そもそも会社全体の質が落ちた。
マネジャー層が増えた。下請け会社に丸投げが増えた。
会社の方針が「上流へとシフト」の連呼。

ブラックITが企業は崩壊した、でもまだ人は生きている。

2018-05-28

チャレンジ目標制度は東芝だけのものではなかった

はじめに

チャレンジ目標制度(以下チャレンジ)が東芝だけのものだと思っていたら東芝だけのものでなかった。
いやまさか、どう見てもあんなパワハラが横行しそうな制度取り入れてるのなんてごく一部だけだろうと思っていたらそうでもなかった。

チャレンジとは

トップダウン的に役職が上のものから目標を設定していって、末端にいたるまで目標を設定し、目標に向けて行動することによって、社長の考えた目標を達成しようという枠組みである。最も上位の目標は利益に直結するものが設定される、会社なので。

社長「今年は営業利益20％アップしたい。」

↓

事業部長「売上30％アップだ！」

↓

部長「売上40%アップだ！」

↓

課長「売上50%アップだ！」

↓

俺「いきなり50％もアップするわけないだろ常識的に考えて」

なぜ東芝だけのものでないとわかったか

会社でチャレンジするぞ！というお達しが回ってきて、研修に行ったらチャレンジを広めるコンサルタントがいた。
「めっちゃいい制度なんすよ」と言っていた。それはねえ君の主観なんじゃないかと。
「するぞ」じゃねえよ、ひとりでやれよ。

研修では平社員にやる気出させて会社の売上増加できますという触れ込みだった。
導入したことによって改善されたことの事例が紹介されていたが、平社員が上司から丸投げされたことを努力で解決する美談という例ばかりで、はっきり言ってなんのメリットも感じられなかった。
たまたまうまく行っただけであって原因がなにも解決してないじゃんと思った。

コンサルが強調していたのは、”平社員ひとりひとりの自発性を引き出すために、社員のモチベーションがプライベートに由来するものでも許してあげよう”ということだった。どういうことかというと、社員が「早く帰りたい」という動機でチャレンジしても、実は介護や子育てをやってるかもしれないので、頭ごなしにけしからんと決めつけてはいけないとのこと。上司は神か。

チャレンジの悪い点

チャレンジした結果、チャレンジはやはりやめておいたほうがいい。

仕組みとして無駄が多すぎ

社員全員が目標設定するのがそもそも無駄。利益上げたいのなら経営陣だけで目標設定すればいんじゃないの？
目標立てるのにものすごい時間取られてるんだけど。この時間を睡眠に使ったほうがよっぽど生産性上がるわ。

例えばライン作業やっている人が売上アップのために、「◯◯工程を効率化する」とかそれらしい目標立てたとしても、営業が受注取ってこれなかったらその時点で最上位の目標を達成できなくておしまい。下っ端が利益目標を立てても意味ない。

仕事というのは（会社によって違いはあるだろうが）すごい大雑把に書くと以下の流れで進行すると思っていて、社員全員が社長の利益増加計画のこと考えながら目標作るのって、生産計画を社員全員が考えてるようなものだと思う。そして日常の業務で「社長が今期20％アップって言ってるから、俺も生産性20％で頑張るぞー」ってなるかというと当然ならない。だって俺の作業と会社の営業利益目標関係ねーし。

生産計画を立てる
営業が生産計画に近い量の仕事取ってくる
平社員が取ってきた仕事を遂行する

反対に考えると、チャレンジする企業というのは生産計画を立てずに行動しているだけなのかもしれない。計画を立てられないからこそ、個人の頑張りというブラックボックスに期待して利益を出そうとしているのだろう。
このチャレンジを絶賛していた役員は「システム開発は原価がただみたいなもの」と発言しており、上司が人件費を原価として認識していないという衝撃を受けたのは余談である。

個人に責任を押し付ける制度

トップダウンで降りてきたよくわからん目標を前提として、自分の目標を作るわけだが、業務とはそんなに簡単に効率化できるものではない。例えば上司から「開発時間20%削減」とか言われた場合思うのは、「削減できるならとっくに削減してるわ」ということ。仮にそんなに簡単に削減できたとしたら今まで力を隠していたということではないのか。「ほう、ならば私も拘束具を外させてもらいますよ。」

当然目標は達成できず「なんでできてないの？」と上司から詰められるわけだが、「なんでできると思った？」となるだけでなんの利益も生み出さない。
結局の所、本来組織として改善が行われるところを個人の責任にして嫌がらせしているだけ。
個人に責任を押し付けても隠蔽工作されたり、有耶無耶な目標設定されるだけでなんの意味もない。

東芝だと、目標利益を出す(捏造する)まで執拗な叱責が続き、売上を水増ししたりして、積もり積もって2000億円粉飾していたようである。

数字で評価することの弊害

コンサルは「定量的な目標を設定して結果を分かりやすくしましょう」と言っていた。事例では数字を使って分かりやすくと書かれてあったが、はっきり言って危険すぎる。なぜなら人間は数字でしか評価されない場合、自分を良く見せようとして結果を取り繕う生き物だから。隠蔽されるとか有耶無耶にされるのがオチ。

そもそも本質的な業務というものを数値で測るのは難しいというのがある。数値だけにこだわると、本質的な業務改善を行おうにも数値目標が立てられないため、目標そのものが目先の小手先に頼ったものにならざるをえなくなる。例えば、「エクセルに画面キャプチャ貼るの自動化します」のような。
本来は数値目標が立てられるかとうかにかかわらず無駄なものは削るべきなのだ。

まとめ

チャレンジは責任のなすりつけあいをうみ、人を幸せにしない。
目標の立てやすい、わかりやすいことが優先され、チャレンジごっこに成り果てる。

2018-04-22

「俺は優秀だから裁量労働制でも平気」と思っていたら死ぬ

システム開発

なぜなら俺がそんな甘いことを思っていたから。

そもそも優秀とはなにか

プログラマの9割は自分のことを平均以上のプログラマだと思っています。（俺脳内調べ）

周りを見てきて思うのは、自らの能力を客観視するのは難しいということ。IQ50未満と言われた俺でさえ、自分のことを優秀なプログラマだと錯覚しているからねほんと。そして周りの奴らはどう見てもプログラミング能力しょぼいと思えるのに「俺はこれまで複数プロジェクトを成功に導いてきてプログラミング能力高い」とかマウント取り合っているというわけわからん状態。ようするに自分自身を客観的に見れておらず過大評価している。経験年数が多いからプログラミング力高いってほんとお？
自分を優秀だと思っている時点で、冷静になる必要がある。

システム開発というものは難解でだれしもミスをするものである。自分の思ったとおりに進捗しない。自分ができると思っていた仕事が思ったよりできなかった場合、そのギャップに苦しむのは自分である。
自分は優秀じゃないんだから失敗して当然くらいのスタンスでないと自責の念で幸せになれない。

「俺は優秀なはず！」 → 「優秀なのに思ったほど仕事進まない」 → 死亡！（俺が悪い）

仮に優秀でもそんなの関係ない

仮に優秀だとしよう。
なら果たして好きな時間に帰れるのかと言うとそんなことはない。なぜなら暇な人にはどんどん仕事が割り振られるから。俗に言うできる人に仕事が回ってくる状態。

そもそも仕事量というものは下っ端が決められるものでなく、営業が受注契約を結んだ時点で決まる。受注契約以外にも改善活動とか内製化とか会社が存続している限り仕事は山のように沸いてくる。
そのため普通に仕事していた場合は残業したくないと思っていても営業がたくさん仕事取ってきた時点で終わり。もうどうしようもない。

仕事の納期もゆとりがあればいいのだが、システム開発において突発的な対応というのは当然のように発生する。特にリリース前に「あの機能がやっぱり足りてなかった！」というのはしょっちゅう。
システム開発は開発環境さえあれば前準備ほとんどなしで取り組めるから突発作業を平然と積まれる。

更にチームの規模によって作業バッファが変わるという要素もある。
チームメンバーが少ないと作業バッファをもてずタスクが積まれる。
これも本人の技量とは関係がない。

裁量労働制にも関わらず残業時間で評価する企業に入ると死ぬ

「でもそんなの関係ない俺は早く帰るぜ」とやっていたら評価を下げられる。別に3,4時間で帰ってるわけでなく8時間働いているのだが、サボっているように見えるらしい。

さらにシステム開発は個人で働くのでなくチームで働くものである。チーム内で残業時間が少ないやつがいると「お前のせいでチームの評価が下がるぞ」とマネージャーからの激が飛ぶ。チームメンバーに迷惑をかけるかもしれないと言われて気持ちよく定時に帰れるものだろうか。
やっていることは江戸時代の五人組そのものではないか。

見込み残業◯◯時間で手当もらってるから残業するのも仕方ない？

「見込み残業◯◯時間で手当でてるからそのぶん残業するのは当然」
もっとものように聞こえる。基本給が低くなければ。
そもそも基本給が高ければ"見込み残業代◯◯時間"という表記は必要ないのではないか。たとえ手当が多いように見えても基本給を下げて調整すればいいのだからみせかけだけの◯◯時間にはなんの意味もない。意味があるとしたら「手当やってるんだから残業する義務があるんだぞ」と社員を恫喝するときだけだろう。

"優秀な人は仕事を早く終わらして帰れる"は会社が従業員を騙すための方便に過ぎない。
"早く帰れないやつは優秀ではないので基本給が低いのも仕方ない"という暴論に繋げられる。

最後に

残業せずに帰るために必要なのは技術力でなく、帰りたいから帰るというメンタル。

2018-04-15

責任は徹底的に追求するが、対策はほとんど追求しない組織で感じたこと

システム開発

今いる職場というものが、責任はとことん追求するが対策はほとんど追求しないというなんだかなあという職場。そのせいもあってかうつ病経験者が多い。具体的に書くと4人に1人はうつ病になる。

うつ病患者や自殺者が多い職場というのはもうどうしようもないものがある。俺も昔は「上司が悪い」とか「アイツさえいなければもっと良くなる」と特定の個人に責任があり、職場としては責任がないと思っていたがそれは間違いだと最近気がついた。たしかに特定の害悪というものは存在するのだが、そいつがいなくなってもまた空いたポストに代わりのものが収まるだけなのだ。なぜならそれは組織としてのカルチャーの問題であり、人間というのはうつ病経験者が蔓延する職場で数年働くと自然と同僚をうつ病に追い込む体質になってしまうのだ。
これを書いている俺自身も他人をうつ病へ追い込む性質になっているのでないかと恐怖せざるを得ない。

後工程の作業者へのリスペクトがない

例えば上流設計者はプログラマを平気で馬鹿にするし、プログラマは平気でテスターを馬鹿にする。
仕様の食い違いや漏れがあった場合はいかに後作業者がミスをしたかのなすりつけが発生する。自分の担当分以外は関わらないのが当然というスタンスなので、担当者しか把握していないドキュメント、プログラムというのが平然と存在する。

属人化しているというのは結果であり、結果だけ見て「属人化はよくない」と叫ぶのは原因を把握していない証拠である。本当に気を遣うべきは、なぜ担当者しか把握していない制作物があるかの根本的な問題の解消である。

プログラマやテスターを馬鹿にしているExcel使いを観察して気がついたのだが、彼はプログラムを書く能力もテスト設計をする能力も非常に低いものだった。おそらく彼の中のプログラマやテスターのハードルというものが非常に低く設定されておりそれゆえに、他のプログラマやテスターもこんなものだろうという意識が生じ見下すに至ったのだろう。

プロジェクトは黒字で当然という歪んだ結果主義

システム開発の請負において、初期一括見積であれば先行きの不透明さからある程度の割合で赤字のプロジェクト発生するのは当然である、しかし目標で赤字がゼロは当然とされている。そのためどれだけ効率良く開発を行っていたとしても見積り金額より赤字という理由で最低評価を付けられる。
これにより、簡単なプロジェクトを計画通り終わらせるほうが、難しいプロジェクトを計画ズレありで終わらせるより評価が高くなる。

また品質においては事故件数◯件以下というふざけたような目標が掲げられている。これはプロジェクトの難易度に限らず事故一件は同じ事故一件と数えられる。ここでも、簡単なプロジェクトを事故無く終わらせるほうが、難しいプロジェクトで事故を起こすより評価が高くなる。

リスクを恐れるあまり、リスクのある作業を他人に押し付けあっているだけなのではないかと感じる。そしてその根回しに生産活動を行なう労力や時間を割いている気がする。

安易に項目が増えるチェックシート

事故が発生した場合、根本的な対策をとることをせず、チェックシートに項目を増やすことで対応しようとする。事故に至る無数の原因のうち、特定の物しか防止できないような、しょぼいチェック内容のため事故を防止する効果は一切ない。
過去の事例と似たような事故が発生した際には「作業者が手順を守っていなかったため発生した」と作業者が責任を取らさせるが、ほとんどいいがかりに近いものがある。作業者が手順を破るとうことは基本的に発生しない。そもそもSIerお得意のダブルチェックが頻繁に入るので手順をあえて破るというリスクある選択は作業者は行わない。

例えば「プログラムが詳細設計どおりに作られていること」というチェック項目がプログラミング作成時にあったとする。はっきりいってこれはなんの意味もない。プログラムが詳細設計通りに作られていることを検証するのは単体テストを終えた後である。このチェック項目が有効なのは作業者が意図してプログラムを詳細設計通りに作っていない場合だけである。そんなことを確認してなんの意味があるのだろうか。このような責任をなすりつけたいがためのチェックシートで作業者を弾劾するのは正気の沙汰ではないだろう。

残業時間はみんなおなじくらいに

残業時間はみんなおなじくらいに(限界まで)高くするのは当然、ひとりだけ楽して帰るなんてもってのほかというスタンス。おもにこれのせいでうつ病の人でてくるんじゃないかなほんと。苦しんだら苦しんだ分だけ給料に反映されると思っている。

管理職が、部下の残業時間ばかりに目を向けて、仕事そのものと向き合えていない。

ミスを隠蔽する

何か失敗した場合はすぐに隠蔽に走る。隠蔽する理由は上司の追求が厳しいものだから。
そのためPDCAサイクルのCAが回らず、施策を出す→うやむやになって終わるの繰り返し。
無駄な時間だけが過ぎていく。

2018-03-14

システムエンジニアの日常6

小ネタ

プロパー「この画面変な動きするんですけどバグですよね？ちゃんとテストしてるんですか？」

ワイ「ごめんなさい！仕様どおりに作ったと思ってたんです…」

ワイ「今までずっと間違ってたみたいで…ほんとに知らなくて…あのすみませんすぐ直し…ん？」仕様ﾁﾗ

ワイ「仕様やんけ！！」

プロパー「！」

ワイ「仕様に！書かれとるやんけ！！！！お！？」

ワイ「仕様に入っとるでこれ！！見えてんの！？仕様に画面動作入っとるでこれ！！！」

プロパー「あわわわわ」

プロパー「大変失礼致しました！！不快な思いをさせてしまい申し訳ございませんでした！このまま検証を…ん？」要件ﾁﾗ

プロパー「入ってないやんけ！！」

ワイ「！」

プロパー「要件に入っとらんやんけ！！！！お！？」

プロパー「もらった要件見えてんの！？そっちの仕様書には書かれててもこっちが出した要件にはそんなのないわこれ！！！」

ワイ「あわわわわ」

ワイ「ご、ごめんなさい！こっちの勘違いで…ほんと悪気はなくて…！あのすみませんすぐ直しますから勘弁…ん？」ﾀｽｸｽｹｼﾞｭｰﾗﾁﾗ

ワイ「要望きとるやんけ！！」

プロパー「！」

ワイ「実装期間中に！要望出しとるやんけ！！！！お！？」

ワイ「要件締切後に頼んでたでこれ！！覚えてへんの！？要件締切後に頼んどるでこれ！！！」

プロパープロマネ「「あわわわわ！」」