はてなキーワード: sIとは
「うっ...どうやらおれはもうだめみたいだ。みんな、後は頼んだ...」
「ちょっと待ってください!」
「なんだ...おれはもう...」
「まだ引継ぎが終わっていませんよ」
「引継ぎ?」
「後任の方に対して残すべきドキュメントはどこにあるんですか?」
「ドキュメント」
「あなたがここまでどれだけ進捗したのか、それを管理しているガントチャートなりバーンダウンチャートなりはどこにあるのかと聞いているんです」
「ガントチャート」
「ないのであればPCを渡すので、その中にあるエクセルで作ってください。私のLet's Noteをお貸しします」
「お、おれはMac派なのに」
「Macだとエクセルとの相性が良くないんです。表計算からワイヤーフレーム作成、進捗管理まですべて行えるエクセルが使えないなんてMacは信用なりません。」
「あの、これなにをかけば」
「始まりの村を出発してから魔王を倒すまで、どういったスケジュールでいくつもりだったのか、もう後付けでいいのでスケジュールを引いてください。お客様とやり取りするためにドキュメントは絶対に必要です。ドキュメントがないと魔王討伐どころかソフトウェア開発も出来ませんよ。こんなの常識です。」
「えっと、この装備品一覧っていうシートは何をかけば」
「そこではあなたが今持っている装備を全て記して頂きます。ちゃんとIDをふってくださいね。」
「ID」
「IDをつける際にはお客様とのコミュニケーションで誤解が生じないようにあえてA-xxx-xxみたいにつけます。確かに番号にするとまるでわかりませんが、リモートコミュニケーションにおいて、例えばマサムネと言われた時にそれが武器なのか防具なのかわからないので、装備品定義書を用意してそれを確認しながらやり取りしたほうがいいんですよ。あえてコミュニケーションコストをあげることで証拠づくりをするんです。小規模なプロジェクトならわかりやすい文字列でもいいかもしれませんが、大規模プロジェクトになるとそうはいかないので、今のうちに意味不明なIDをつけられるようにしておきましょう。あ、ちゃんとIDと名称の対応表は作っておいてくださいね。あと、この資料は紙に出力するので罫線などは勿論しっかり整えてください。」
「...」
「あ、勇者がおなくなりに」
去年の秋ころから始まったプロジェクトで毎月100時間弱の残業が発生していて正直しんどかったんだけど、ここ3~4ヶ月は残業時間が月に150時間を超えてきていて正直体調が悪くなるわ、考えることが難しくなるわ、趣味も楽しめなくなるわ本当にろくなことがなかった。
こんなことになったのはプロジェクトの内容を見誤って無理な契約をしたこと、更にその無理な契約の範囲をお客さんが無理やり広げてきて、それを押し返せなかったって言うことなんだけど。。。
ここまでこじれたりしたら会社の方でなんか対応溶かしてくれるのかなぁって序盤は思ってたんだけどそんなことなく、どちらかと言うと死ぬまでやれっていう感じだった。
ちょっとお世話になっている人がいるから頑張っていたんだけど、ちょっとここまで体調崩してやり続けるのは無理だって思った。
で、思ったのは他の会社もこういうものなのかなぁって言うこと。
毎月100時間とか150時間とか残業してると大体終電帰りだし、土日連続で休めることはないんだけど、みんなこんな環境で働かされても文句言わずに働いてるものなの?
この文章だけで判断できないこともたくさんあると思うけど、みんなだったらすぐ逃げ出す?
すぐ逃げ出すと逃げぐせがつきそうっていうのと職務経歴上何も書けなくなるからどうかなーって思ったりするんだけど。
あと、会社に対してはすごく不満はああるんだけど、メンバーにはそこまでひどい不満はないんだよなぁ…
お客さんにちゃんと交渉できないって言うことを除けば…
あ、残業代は割とちゃんと払われてるけど、この間に労組と結んでる36協定の限界の時間を超えてしまって最後の方はちゃんと支払われていない。
給与はそこそこいいほうだと思うんだけど、基本給も上がらんしなぁ…
ふと思い立ったので書いてみる。二年前、新卒として某企業の技術研修を受けた。Javaを用いて、自分たちで一つのプロダクトを作るという研修である。技術を推している会社なので研修内容にはかなり期待していた。Spring等のフレームワークの話、JavaとフロントエンドのAngularやReactをどう連携させるか、もしかして自作のフレームワークを作る研修も受けられるかも、などなどの話を入社前にはしていた。実際そうではなかったわけだが。
詳らかに書くことは出来ないが、当時最も憤ったのは研修の成績をどうやって決めるかに関する講師の考え方。中間発表で企画発表を行い、最終発表でプロダクトとしてのレビューを受けて、プレゼン大会を行って成績が決まった。自分はどちらも中くらいの成績だったらしい。
ここで驚いたのが、コード量が成績評価に結び付くということだ。コード量の最適化という意味ではない。フレームワークなどを使ってコード量を減らしてはいけない、フルスクラッチでプロダクトを作れということだった。意味が分からなかった。
評価するためには十分量のコードが必要ということは理解していた。過去の研修で何人かがフレームワークを用いて適当に作ったプロダクトで済ませようとしたエピソードなどを聞かされた。それはわかる。わかるが、そうした怠慢に基づくモチベーションではなくよりよいプロダクトを作るために先人の肩に乗るのは許されるべきではないのか?
Javaによるプロダクトを理解するため、フレームワークを使うとフレームワークが廃れたときに何にもできなくなる、という言葉を何度も聞かされたが、Javaのプロダクトを理解するのならそれこそフルスクラッチを要求するのではなく歴史があるSpringで十分だし、フレームワークを使ったからといって魔法のように自分の望むプロダクトが出来上がるわけもなく、自分で考える部分が大部分を占めることは自明ではないか。むしろ、その考える時間という本質的な部分を確保するためにフレームワークなどの技術を用いるべきではないのか。
Reactを学びたいモチベーションがあり、Java側でなければ、というかReactはフレームワークじゃないし大丈夫だろうと思って実装を進めていた時に講師の方から「フレームワークは認められない」と言われ、食い下がったもののまるで話が通じなかった。結局自分はそこから大きく計画を修正し、適当なプロダクトを作った。モチベーションは地の底に落ちた。そもそもプログラム研修なのに渡されたPCがWindowsで、エクセル地獄だった時点でモチベーションはまるで高くなかったがReactをやるというのがモチベーションになっていた。それも無駄だった。
今年の新人も同様のカリキュラムだという。しかもまだWindows。フレームワークは一切使えない。エクセルでワイヤーフレームを書けという。SIじゃないから大丈夫だろうと思っていたのに、という新人はたくさんいるだろう。配属後もコードを書く時間はどんどん減っていく。自分自身で勉強し、論文や技術書を読み、週末に自分でプロダクトを作る習慣をつけておかないといけない。自衛しないといけない。
そんな不幸な人たちがいればいいのにと思った。
特定派遣の話だ、その会社はブラックではなく限りなく黒に近いグレーだった
・入社時の雇用契約書はコピー可能だが、派遣契約書は見せてもらえるが守秘義務を理由にコピーは不可
・事前面接を「顔合わせ」「打ち合わせ」「事前説明」と言い換えて当然のように行う
・客に気に入られたり技術職に着けて、5年以上継続して派遣されている社員の給料は上げるが他は新卒の給料(注1)
・現場でパワハラを社員がされても知らぬ存ぜぬ、営業に不満を訴えると契約打ち切りにしても次が決まらなかったらクビにすると脅し
・派遣契約の仕組みを知る現場責任者が常に低評価をして社員が異を唱えても「お前が悪い」(注2)
・求人ではエンジニアと書かれているが客先での仕事の実態は事務と雑用メイン(Excelとwordで資料作成・メールの作成・シュレッダー要員・在庫管理担当)
・会社紹介の社内インタビューに出る社員は全社員の中から運よく技術的な仕事が出来ている特定の極少数な人だけ
・派遣先に社員の待遇は任せているため、労基法に抵触しそうなことも知らぬ存ぜぬ
・新卒・中途の社員育成は派遣先に丸投げ、育たなかったら「運が悪かったね」と一言、次の派遣先が決まらないと強制自己都合退職
・勤務時間が自己申告の場合は社員に圧力をかけて残業時間を抹消
SES案件メインで派遣されて雑用や事務仕事ばかりなのにエンジニア募集と未だに記載している。
会社にクレームを言ったところで管理職が営業で固められているため効果はない
この会社は限りなく黒に近いグレーな会社だが、表向きはホワイトかつ技術者重視で求人を募集している
労働者を騙して接収しようとしている会社を見破るのは至難の業だ、会社一丸となって騙してくるからな
過重労働やサービス残業三昧の会社がブラック企業と言われているが、こんな限りなく黒に近いグレーな会社も存在する
社員に対する扱いが酷いだけで法令にはギリギリ違反にしないため、客先常駐をメイン事業とする会社には上記が当てはまる会社が腐るほど存在する
運よく派遣先に気に入られた人や技術職に着けた社員は会社を悪く言わないだけに余計たちが悪い
SI業界の下請けの現場はこんな会社の派遣社員に支えられている、こんな状況なのに人手不足と言われている
この状況で行進が育つだろうか?ピラミッドの頂点に立つ大手に危機感はないがいずれ彼らの立つ土台が崩れるだろう
人をぞんざいに扱い教育をしようとしない下請け特定派遣会社がSI業界に蔓延っている現状は「日本のインフラ」を根底から崩壊させる危険性を孕んでいる
(注1)3年以上は直接雇用になるのでは?疑問を抱く人が多いだろう、なぜか特定派遣会社には10年以上継続して派遣されてる人がよくいるため何らかの
(注2)派遣社員の客先での評価が上がると派遣社員の給料が上がると同時に派遣料もあがる、それを知ってる現場責任者は意図的に派遣社員を低評価する
日本のIT業界の大部分を支配する大手SIerが存在している限り、今の小学生がプログラミングを習得した所で元請けを頂点とした階級構造を切り崩すことにはならない。
必修化が功を奏してプログラマーが増えたとしても一部の優秀な人間が起業もしくは有名web企業などに就職するだろうが、他はSI業界に行く運命になるだろう。
彼らが進むSI業界には、“「君は優秀なんだから、プログラミングみたいな低俗なことは早く辞めて人を動かせるようになれ。私が引っぱりあげてやる」”と言う上司が存在する大手SIerが支配している。
プログラミング必修化でプログラミングを学んだ小学生の一部がその一員になると思うと心配でならない。
10社くらいに関わってきたけど
いやー意識低いなぁ
もちろん高いところは高いんだけど、メガベンチャーみたいなところとか
ホッテントリ入りするようなところとかはね
総じて言えば若干低め
世の中見渡してみれば
商品開発、製造業、あとはSIやらゲーム業界、コンテンツ業界も、品質に対してはかなりしつこいイメージが有る
もちろん、工数が足りないとか、修正がききやすいとか、スピードを求めたいとか色んな事情があるのはわかる
それでもなんというか、低いことが当たり前になってるような雰囲気が怖い
手に職を付けたい理由はお金?技術をもって自由に稼ぐハッカー?
まず、前者なら大手SIerが鉄板です。なぜなら、給与が圧倒的に高いからです。中小と比較すると同年代で100~200の差は出ます。あなたが結婚したころにはその重みが分かることでしょう。
後者なら、残念ながらもう手遅れです。そういう人は小学生くらいから自ずとプログラミングをして、高校生くらいで何らかのコンテストに出ているような人かと。あなたくらいの年齢では、もう起業しているか、企業からの取り合いになっていることでしょう。今、それをしていないということは、あなたはそういう人ではないということです。
大手SIの良いところは以下のとおりです。聞こえがいいとかそういうのはどうでもいいことです。
・企業システムのある程度精緻に作られたソースや設計書を見れる
「技術」とは何もコーディングだけではないことを知るいい機会になります。
・転職に困らない
・バカな管理者が比較的少ない(中小はその比ではないと思われる)
手に職と言いますが、それを持ち得て必要とされるような能力の持ち主は非常に稀有です。
今からそれを目指すということはそれなりの覚悟と努力する才能が無ければ難しいかと。
システム開発全般について、体系的に教えられる人を外部の講師含めて、ほとんど見たことがありません。
自主的に学ぶ場合は上流から下流工程までを見渡せる大手SIがいいです。
新卒カードを中小企業に切ったら、次は中小企業カードかスキルのある人カードしかないです。
大企業に切れば、新卒に準じる大企業カードか、大企業でスキルがある人という強いカードになりえます。
良く悩んでください。
自分より優れたるものを自分の周りに置きし者ここに眠る。カーネギー
できる人ばかり辞めていく会社が研修費用を出すようになったら、さらに退職が加速したというお話「人事に聞かせたい」 - Togetterまとめ
「従業員にトレーニングをして、よそへ行ってしまったらどうするのか」という疑問に対するStanger氏の答えは、「従業員にトレーニングをしないで、彼らが会社にとどまってしまったらどうするのか」ということになる。
従業員の才能を爆発させるには「会社に人を長く留める」戦略を捨てる必要がある
ttps://b.hatena.ne.jp/entry/s/gigazine.net/news/20171005-superboss/
「弱いつながり」理論でいうと、SNSでつながる友だちは、それこそFacebookの友だちが3,000人規模で、国内のスタートアップの経営者なら、たいていの人に直接または1hopでつながることができる。
ttps://s.nikkei.com/2vJsvYx
優れたマネージャーは自分より高い給与をもらう可能性のあるポテンシャルの高い部下を喜んで雇う
ttp://b.hatena.ne.jp/entry/www.masafumiotsuka.com/2015/11/the_peter_principle.html
人材は会社の資産として残らないが仕組みは会社の資産として永遠に残る
ttps://www.amazon.co.jp/dp/B010JM64M6/
ttps://employment.en-japan.com/engineerhub/entry/2019/11/07/103000
ttps://www.slideshare.net/yattom/ss-79372905
ttps://tinyurl.com/y8tkhuhz
ttps://bit.ly/2MylBjs
"競争優位につながるような戦略的なソフトを開発しようとするなら内製しかない。"
ttps://www.amazon.co.jp/dp/4822273784
ttps://medium.com/@kuranuki/aac6062adfb2
どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるか
(中略)
ソフトウェア開発とは、経営的意思決定の集積なのだから、経営的意思決定を外部の会社に委託するというのは、「経営を外部の会社にやってもらうようなもの」だからだ。
もっと言うなら、自分の会社の今後のビジネス的ポジションを、他社に決めてもらうようなものだからだ。
外注を出された会社は、そのソフトウェアが未来に実現するであろうビジネス的価値を犠牲にして、できるだけ少ないコストで作ろうとする。
ttp://fromdusktildawn.hatenadiary.jp/entry/20061003/1159869683
ttps://bit.ly/2JzCggZ
「ソフトウェア業界(特に受託開発業界)は、基本的に正直者が馬鹿を見る世界である。顧客が、保守性というソフトウェアの最も重要な品質を正しく評価できないという、情報の非対称性が存在するからだ」/分かるなぁ
「モダンな開発環境×技術顧問×内製化」Sansan×日経電子版 アプリ開発の最前線を語る夜
ボタンを1つ追加するだけで2週間。内製化によるスピードアップは必須だった。
「アプリ内にボタンを1つ追加するだけで、2週間の開発期間と、数十万円のコストが発生していました。それでは急な仕様変更に対応できないし、技術ノウハウも貯まらない。」
ネットサービスの肝は、開発にかける額の多寡というよりは、内製化するかどうかにあると思っています。
ローンチした後、そこからの追加・改善はものすごいスピードでやらなくちゃいけない。これは、内製体制でないと絶対に不可能です。
2017年1月、ネット証券大手のマネックス証券は証券基幹システムを刷新した。
お客様へ提供するサービスの開発スピード向上と、ノウハウの社内蓄積、開発コストの適正化を目的に、
(中略)
サービスの改善や新サービスの開発時に、ASPサービスの提供会社との会議に費やしていた時間を削減し開発のスピードアップを図ることで、競合他社への競争力を強化したいと考えました。
ttp://b.hatena.ne.jp/entry/s/quality-start.in/it-strategy/467
ttps://twitter.com/kanayang2009/status/129677947572465666
ttps://amzn.to/2ncDXrO
だから育てるんだ。
ABテスト デザイン OR ボタン OR 文言 - Twitter検索
外注でもA/Bテストでユーザの反応を計測してトライ・アンド・エラーでシステム開発ってできるもんなんだろうか。
できるとして、それって内製化した方がずっとクオリティ高くなるんじゃないの?
ttps://twitter.com/fromdusktildawn/status/874796380522336256
「外部委託すると細かい継続的な機能の改善が遅くなるので、自社採用でかなり優秀な人材をケチらずに採るべきだね。なかなか見つからなくても妥協せずに」ホリエモン
ttps://bit.ly/2QWMsoJ
外注はPDCAを回せないという致命的な欠点がある。ITスタートアップの感覚だと外注と内製には天と地ほどの差がある
ttps://bit.ly/2J5UCWQ
銀の弾丸ではないがリーンな開発は競争力の源泉。そのためにはPMFをコントロールできる開発チームが必須でそれは内製でしか達成困難。
ttps://bit.ly/2vkDd8E
正解に当たるまで回し続ける!3ヶ月で200回のA/Bテストから得た「意外な結果」とは
弊社のイベント一覧のページなのですが、単なるテキストの羅列のパターンと、リッチなレイアウトのものでテストすると、いつも必ずテキストの方が勝ちます。
海外テック情報局:eBayではダサいデザインのほうがコンバージョン率が高かった|gihyo.jp … 技術評論社
デザイナと口論したいのではなく,見たいのは数字とお客さんの利用例。
そして何がうまくいっているのか突き止めたい。
選択の科学 24種類のジャムを売り場に並べたときと、6種類のジャムを売り場に並べたときでは、前者は、後者の売り上げの10分の1しかなかったのです。
ttps://amzn.to/2I2V1O4
エンジニアでないファウンダーは最大一人まででお願いします | On Off and Beyond
理由1:変更につぐ変更を重ねられるようにする
最近 lean startup なる考え方がはやってますが、これはどういうことかというと、
東大合格者ランキングは正しいのか?――常に分母は何かを考えよ
何事にも閾値はある。そこに至らなければ、意味がないという数字だ。
「頭のいい人が成功しない理由」という本に、閾値の話があった。
だれもが中途半端にやめてしまう。それでは足りない。閾値を越えない。
ttps://ameblo.jp/chimu841/entry-10036171360.html
ttps://amzn.to/2Odv25b
①内製
②外注
フラクタルなレモン市場問題|建築不動産クラスタ交流会の件その1
ttp://realtor-readyabooks.hatenablog.com/entry/20100515/1273919457
ttp://ledsun.hatenablog.com/entry/2016/02/28/014851
ttps://ja.wikipedia.org/wiki/情報の非対称性
ttps://ja.wikipedia.org/wiki/逆選抜
ttps://ja.wikipedia.org/wiki/取引コスト
「探索コスト」
時給制(時間を売る)が生産効率低いのって自明だよなぁ・・相当ボランティア精神ないと時給制で効率よくやろうって気持ちにならないよね
でも拘束時間で金額を決めてしまっては効率化を目指さなくなるんじゃないか
ttp://b.hatena.ne.jp/entry/b.hatena.ne.jp/entry/194800390/comment/redhornet96
ttp://b.hatena.ne.jp/entry/twitter.com/etomiho/status/872820182883762176
ttp://b.hatena.ne.jp/entry/twitter.com/etomiho/status/872822997106565120
ttp://getlife.hateblo.jp/entry/2013/09/10/015011
見積もりが人日で工数を計算していると、実際にはそれよりも短期間で実装できても見積もり日数になるまで納品を待ったりすることはある。
納期よりもかなり早い段階で実際には完成しているにも関わらず、
エージェントが利益相反行動をしていないかどうか監視するためのコスト。
自身の行動がプリンシバルの利益追求にかなっていることを証明するために
ttps://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1212240292
ttps://twitter.com/search?q=rails%E3%80%80%E9%A1%A7%E5%95%8F
「顧問プログラマ」再考 - Rails 雑感 - Ruby on Rails with OIAX
ttps://www.oiax.jp/rails/zakkan/rethinking_of_adviser_programmer.html
ITエンジニア採用に欠かせない原則とは (1/5):IT人材ラボ
ttp://b.hatena.ne.jp/entry/s/itjinzai-lab.jp/article/detail/856
ttps://www.slideshare.net/fukumura1/fukuokarubykaigi-medpeer-ver1
【256人がリモートワークで回る仕組みを考える】後編
ttps://www.remotework-labo.jp/2015/10/interview_10/
倉庫のように人がメールをいちいち見てられない現場が想像できないんだろうな。
紙が出てることで受信が目で判断できる、FAXの強さを理解できないやつがSEやると、大抵の場合で現場が死ぬ。
受信したFAXがメールになるシステムもあるし、受信データを「そのまま」ファイル化するのも当たり前にある。
ではなぜそうしないのか?を考えられないやつが、効率化だのと騒ぐわけだ。
結局のところ、メールにしろ、FAXにしろ、そのままじゃデータは使えないんだから、【効率化()】のためには、正規化したデータにする必要がある。
誰がヤんの?
人によりけりでどちらも可能としか言えないですが、その認識が傾向として正しいかどうかの二者択一であれば、むしろ逆な気がします。
また、「受託開発」と世間一般で表現した場合、いわゆるSEを様々な現場に派遣していたり、SIなどをやっているような会社も含まれますので注意して下さい。
自社開発と言っても漠然としているので、分かり易い極端な例として、「新規にWebサービスやアプリを開発しているベンチャー企業」と定義しますと、
そういったところでやっている仕事と、SEの仕事は、(SEとして就く現場によっては)職業として別物レベルで違ったり、共通する点があるにせよ、その濃さがまるで違います。
そのため、SEになってしまい、実際に手を動かしてバリバリ開発するよな場所にいなかった場合は、上記における自社開発の現場ではあまり役に立たない可能性があります。
「受託開発」でも、中にはSE派遣とかではなくて、本当に技術レベルが高いエンジニアリング集団みたいな会社もあるので、そのようなところであれば、両者で行き来できます。
就活されている方である場合、このあたりの選択をミスると、自分の想像とまるで違うところに行ってしまうので、よく注意して下さい。
私はベンチャー企業で開発&採用(小さい会社なので・・・)していますが、若い方の場合、このあたりのミスマッチを転職理由にされている方は多いです。
カロリー(仏: calorie、記号:cal)は、熱量の単位である。「カロリー」という言葉は、ラテン語で「熱」を意味する calor に由来する。
かつては広く用いられていたが、1948年の国際度量衡総会(CGPM)で、カロリーはできるだけ使用せず、もし使用する場合にはジュール(J)の値を併記することと決議された。よって国際単位系(SI)においては、カロリーは併用単位にもなっていない。
だってさ。
実際に、計量単位令第5条、別表第6の項番13をみると
http://law.e-gov.go.jp/htmldata/H04/H04SE357.html
十三 人若しくは動物が摂取する物の熱量又は人若しくは動物が代謝により消費する熱量の計量 カロリー
と。
SIerのヤバい現場は「何をしているのか理解してない」というレベルで分かってない気がします。
この方々に
「このシステムはどんなプログラミング言語で作られているの?」
「この値はどうやって算出しているの?」
と聞くと
「わからない」「担当者に聞いてくれ」「ユーザーに聞いてくれ」
と言います。
確かにプログラミング技術やクライアントの業務に詳しくない人なのかもしれません。
でもシステムってプログラミングって自分で理解していないと作れないものなんですよ。
「プログラミングは俺の仕事じゃない」「ユーザーの業務はユーザが一番詳しい」
そうかもしれませんが、システムを作るあなた方が理解してないものはコントロールもチェックもできないんですよ。当り前じゃないですか。
確認もテストも協力会社の方にお願いするんですか?では協力会社に仕様を伝えるのは誰ですか?
ユーザーからの質問を「担当者に確認します」と言って自分からは答えられない状況が続いているのにおかしいとは思いませんか?
プログラミングも仕様も分からない、呼ぶ協力会社は単金だけを見て決めるんですか?優秀かどうかはどうやって判断するんですか?
スケジュール管理は数字だけを見てできると思っていませんか?その根拠はなんですか?
Git知らないDocker知らないm9(^Д^)プギャーと
でもそんなことは些末なことで、導入してすぐ解決みたいな話ではないように思えます。
それに毎日遅くまで働いて、休日は妻子のために家族サービスとなれば自己研鑽の時間なんてなかなか取れないでしょう。
でも作ろうとしてるものが何なのか理解する時間は会社の中でできると思うんです。
忙しいのは理解しています。稼働調整、スケジュール調整も大事な仕事です。
お客さんと雑談で
「ちなみに現場の人ってこのシステムどうやって使ってるんですかねー?」
とか
プログラミングしている方に
「この処理はJavaScriptで書くのが良いのはどうして?」
とかなんでも良いんです。
「そんなことをしても仕事が増えるだけで、得にはならない」
という意見もわかります。でも自分が理解しないといつまで経ってもコントロールできる立場にはなりませんよ。
ラダー効果が云々という話も聞き飽きたかと思いますが、もうちょっと視野が広がると糞な職場がほんの少し変わる気がしませんか?
というわけでお父さんたちお仕事頑張って!
私の街では、
雪下みかんを投げ合うのが恒例ね。
雪下みかんって言っても、
この時期、
山の方には雪がたくさん降るから、
2年も寝かせるんだって!
まるでイタリアのパルミジャーノ・レッジャーノチーズみたいね!
鬼はーそとーってやるのよ。
トマト祭ばりに投げ合っての、
鬼退治バトルロイヤルではないんだけど、
どっちかというと、
まあ、振る舞いみかんよ。
って言ったあと、
鬼は内、と言いつつ福は外とかのパターンなのよ。
鬼を内にいれ改心させ、
福は外でよそにも福が行きますようにっていわれみたいよ。
ふーん、って感じね。
私も何個か振る舞い雪下みかんをもらったわ。
でもとってもジューシーよ!
でね、イタリアでは
あの何十キロってある、
パルミジャーノ・レッジャーノチーズを大砲で撃って鬼退治するっていうから
イタリアの鬼も大変よね。
食べたら美味しいけどね!
うふふ。
オムおにぎりと迷ったけど海の幸満載感の鮭とシラスのにしました。
いい加減ワンパターンだけど。
また今朝も雪がちらついてるわ。
すいすいすいようび~
むかついているがどうにもできない。そのことにさらにむかついている。
うちの会社は社員数も売上高も数千の中規模SIだ。いつからかわからないが中国にも支社があり、現地の技術者を採用したりもしている。(こうした実績からグローバル企業を謳ったりもしている…)
この会社に入って最初の合同研修期間で彼らと接することになったのだがまずスペックの高さに驚いた。
まず3ヶ国語を扱える。中国語はもちろんネイティブ、英語はビジネスレベルで習得しており、個人差はあるもののみんな日本語での日常会話に支障はない。外国人に難しいとされる日本語の読み書きも、漢字をある程度知っているだけあってアルファベット圏の人々より習得が早いらしい。
俺は文系学部出身だが在学時からプログラミングを始めてWebサイトをいくつか趣味で立ち上げたりしていて、同期の間ではコードが書ける方だろうなどと思ったりもした。半数を超える文系学生と真面目に勉強してこなかった理系学部生・院生の中ではその自己評価はあまり間違っていなかったが、彼らには到底かなわなかった。コンピュータのことを深く理解していて、俺がにわか知識や付け焼き刃で語っている内容に「それはどうやって動いているの?」「既存のあの技術との違いは?」と鋭い突っ込みを何度もくれた。
彼らとの会話は刺激的だったし、一緒に行ったプログラミング研修は楽しかった。研修後の配属先はバラバラになるが「いつかまた一緒に開発しよう」と話していた。
しかし、それから数年が経ち、彼らはみな会社を去ってしまった。
俺が地方に飛んでいた数年の間に彼らと会話ができたのは数えるほどだった。社内報の退職情報欄に彼らの名前が載る度に「何があったんだろう」と思ってはいたが、開いた距離を積極的に埋めることはしなかった。
ところが最近、辞めた中国人同期のうち2人が俺の住んでいる地方に来るというので久しぶりに会おうという話になった。数年ぶりに再会した彼らの日本語はさらに上達していて、日本人とは遜色ないぐらいで驚いたのを覚えている。
だがそれよりも驚いたのは、彼らが在籍時に会社が彼らをいかに扱ったか、という話だった。
SIerでの業務がいかなるものであるかは世に多くの体験談があるので詳細に書くことはしない。が、一言。うちの会社も例に漏れずExcel仕様書を使い、一時代二時代も遅れた技術を使い、技術者よりも管理者を大事にする会社だとは言っておく。
日本の新卒よりも遥かに優れた技術者である彼らが業務においてコードを書いたのは数えるほどだったという。
ある一人は会社が代理店契約を結んでいるMicrosoftの製品サポートをひたすらやらされ、英語ができない他の社員の代わりにサポートデスクとメールをしていた。Microsoftは日本のサポートも充実しているらしいがなぜそういうやり取りが発生するようになったのか誰もわかっていなかったというし、理解しきれない製品を売っていることも不可解だった。
またある一人は1年目から3年目まで巨大プロジェクトのテストをひたすら任され、それが終わった後には小さな開発案件のサブリーダーとして派遣社員への指示やガントチャートの管理をするようになった。技術者としてプログラムを書いたり研究に没頭したいという主張をしたが受け入れられなかったらしい。この会社にとってプログラマは外注で十分だし、その頃の彼は「テスト歴2年の若手」としか映らず、活かす道はそのまま凡庸な「SE」ぐらいしかないと思われたのかもしれない。
そして最もひどい扱いを受けた一人。彼は1年も俟たずに辞めたがその理由もさもありなん。
彼は同期の中国人の中で最も日本語ができなかった。とはいえ日本人の平均的な会話スピードであればリスニングはできるし、スピーキングも落ち着いていれば悪くない。少なくともグローバルカンパニーを標榜するうちの社員の悲惨な英語力に比べれば圧倒的にマシだった。
しかし、その時点で配属先の部署は彼を役立たず扱いした。「カタコトの日本語では客先に連れていくことはできない」「派遣や請負の方と話すときも伝達の齟齬で仕様ミスを生むかもしれないから必ず上長を介して」などといって、所属しているはずのプロジェクトでも何も仕事を与えられなかった。代わりに経費で購入された日本語の学習本を読むことを一日数時間強要された。彼は一日でも早くその状況から抜け出そうと努力し、1ヶ月でJLPT N2(日本語能力試験の上から2番目)を取得するにいたった。そしてプロジェクトに溶け込もうとしたが、こねくりまわされて複雑怪奇になったドメイン知識やそれを体現するExcel仕様書はJLPT N1より遥かに難しかったという。
「"君たち優秀なグローバル人材の技術力が欲しい"と言われたから移住してまで入社することを決めたのに、中国語も英語も技術力も何の意味もなかった」
「日本の企業で働かなければ純粋に日本を好きなままでいられた」
「中国の同期生は僕がSIerで役に立たない技術やカスタマーサポートやExcel仕様書のために時間を費やしている間にキャリアを積み上げている。面子を大事にする中国に戻れば"出戻り負け組"として侮蔑的な態度を取られることもある」
そんな話を聞いて俺はむかついている。
会社は嘘をついていないし、やっていることに違法性はないらしい。過度なパワハラと訴えることが精々だろうか。その程度では人生の一部を無駄にしてしまった彼らの無念と後悔は晴らせないかもしれない。
優秀な外国人技術者を使い捨てるSIerの実態。「すべてのSIerがそうじゃない」「主語がでかい」と誰かが必ず言うだろう。俺もそう思う。きっと彼らが行くべき会社は他にあったのかもしれない。
でもどうか知ってほしい、こういう会社があることを。
そして止めて欲しい、こうした不幸な選択をする人が身近にいたら。
直に、俺も会社を去る。