IQ49

IT業界の感想

【2019年4月29日】Windows 10 Home EditionでRDP Wrapperを使ってリモートデスクトップ接続する方法

今日もWindows10をUpdateしたらリモートデスクトップで接続できなくなったのでメモ。

  • 前提条件

RDPWrap-v1.6.2 がインストールされていること。

  • 更新

https://github.com/stascorp/rdpwrap/issues/763

掲示板を見て、「動いたよ」と言っている人を見つける。

https://github.com/stascorp/rdpwrap/files/3126174/rdpwrap_working_version.zip

親切な人が動いたときの設定ファイルをアップロードしてくれているので上記からzipをダウンロード。

解凍して出てきた rdpwrap.ini ファイルを C:\Program Files\RDP Wrapper フォルダの同名ファイルに上書き。

自分は何故か上書きできないと言われたので、Windows 管理ツール → サービス を起動し「Remote Desktop Services」を停止させた後、ファイルを上書き。

f:id:baito_mo_yamunai:20190429203435p:plain
サービス2

再起動したら動いた。

古いバージョンのVSCodeのzipを入手する方法

VSCodeをアップデートしたら拡張機能が動かなかったので、古いバージョンのzipをダウンロードしてしばらくはそれでしのごうと思った。が、最新版でないzipファイルがどこに置いてあるかわからない。そんな中しばらく探してると見つかったのでメモ。

https://github.com/Microsoft/vscode/issues/60933

octref commented on 16 Oct 2018 •

As @egamma mentioned, you can go to the release notes page to download old release. One additional trick, you can find a link to download your platform's build, and replace the version number

https://vscode-update.azurewebsites.net/1.27.2/win32-x64-user/stable
https://vscode-update.azurewebsites.net/<your-version-here>/win32-x64-user/stable

適当にググってると上記のページに行き着いた。ダウンロードリンクを自分で探してねとのこと。 https://vscode-update.azurewebsites.net/<your-version-here>/win32-x64-user/stableを適当に書き換えたらダウンロードできて無事解決

【2019年2月】Windows 10 Home EditionでRDP Wrapperを使ってリモートデスクトップ接続する方法

今日Windows10をUpdateしたらリモートデスクトップで接続できなくなっていたので。

注意点としてこの方法も次のWinowsUpdateが来たら使えなくなるであろうということ。

環境

Windows10 home

10.0.17763.292

1. RDPWrapインストール

https://github.com/stascorp/rdpwrap/releases

ここから RDPWrap-v1.6.2.zip をダウンロードします。

zipを解凍したら中の install.bat を実行します。

2. 動作確認

zipについてくる RDPConf.exe を実行すると設定状況を確認できます。全部緑ならなにもしなくてOK。

f:id:baito_mo_yamunai:20190219121304p:plain
rdwrap

3.設定ファイル変更

2018年12月頃は何もしなくても動いたんですけど、WindowsUpdateによって動かなくなりました。自分はListener stateの欄が赤くなっていました。

これに関しては設定ファイルを追記することで動作可能となるようです。さいわいにも親切な人が追記済みの設定ファイルをアップロードしてくれているのでそれを利用します。

https://github.com/stascorp/rdpwrap/files/2809588/rdpwrap.zip

上のリンクからzipをダウンロードし rdpwrap.ini ファイルを手に入れます。

これを C:\Program Files\RDP Wrapperフォルダの同名ファイルに置き換えます。

置き換えた後、再起動してListener stateが緑色になることを確認しましょう。

参考

https://github.com/stascorp/rdpwrap/issues/645

2ヶ月後

【2019年4月29日】Windows 10 Home EditionでRDP Wrapperを使ってリモートデスクトップ接続する方法 - IQ49

CTO不在のシステム開発

はじめに

「会社としてCTOが存在しない」ということはCTOが存在しないことによる直接的な問題もそうだが、CTOが生まれない風土という根本的な問題も抱えており、その両方が技術者にとって住みづらい空間を生み出すのであろう。

技術が評価されない

  • 技術者が出した成果に対して、技術的な面での評価を出せる人がいない。そのため技術者がどのようなものを作ったかではなく、表面上は見栄えがいい報告、労働時間の多さといったものが評価されるようになる。そのため評価制度がほとんど機能しない。

  • 毎朝のラジオ体操を行えばプログラマの生産性が上がると思っている。(非技術的な命令で効率を向上させようとする。)

  • 部下の数が多い社員の意見が正として扱われる。技術的な正しさが追求されない。

  • マネージャーがプログラマの上位版と思われており、30過ぎてプログラマやってると「まだプログラマやってるの?」と嘲笑される。

  • 技術採用を行うも応募者のプログラミングスキルを面接者が理解できない。面接担当「プログラミングなんて誰でもできる。業務知識のほうが大切なんだよ。」

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

  • 問題が発生しても技術的な面からの分析が行えない。そのため対策が対策の体をなしていない。

  • バグが見つかるたびに、公式サイトのQAをコピペしてきたような無駄に長い説明が手順書に追加される。誰も全容を理解できないマニュアルが出来上がる。

  • EXCELにあらかじめプログラミングする内容を書いておき、その内容が非技術者のレビューを通過することで品質を担保しようとする。なお出荷予定のソースコードは書いた人しか読んでいない。

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

  • 技術に関するものの決済、承認を非技術者が行うため、開発ツールの買い替えが行われない。買い替えには非技術者へ効果を示すための膨大な手間が必要。
    • CIツールはサーバを立てる経費がもったいないので使用不可。
  • 外部サービスは危険なので使用禁止。

  • 合言葉は「今までと同じやり方でコストダウン」。新しいやり方はリスクがあるので禁止。いかに今までと同じやり方で仕事をするかが重視される。

  • フリーソフトは可能な限り使用禁止。VimEmacsは使用禁止。サクラエディタは可。

技術屋が逃げる

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

ブラックIT企業の末路

もうすでに崩壊した

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

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

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

崩壊までの道のり

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

平均年齢高すぎ問題

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

安い人材麻薬

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

地力の消失

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

結局どうなったか

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

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

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

はじめに

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

チャレンジとは

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

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

事業部長「売上30%アップだ!」

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

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

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

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

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

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

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

チャレンジの悪い点

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

そもそも優秀とはなにか

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最後に

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