  |
はてなキーワード: ベンダーとは
https://next.rikunabi.com/journal/20181101_p01/
リクナビNEXTでランキング上位に入り注目を集めているこの記事だが、その内容には致命的な誤りがある。
まず一つ目、DevRelの定義だ。
DevRel（デブレル）とは、Developer Relations (デベロッパー・リレーションズ) の略で、テクノロジーを提供するベンダー（マイクロソフトやGoogleなど）が、開発者と良好な関係を築くことを目的とするマーケティング活動である。
「良好な関係を築く」というのは曖昧な表現だが間違ってはいない。しかし
「DevRelは、その名の通り、開発者との関係性が重要です。マイクロソフトのデベロッパー分野の窓口として、皆さんの声を直接お聞きし、製品に活かしたりドキュメントを用意したりして、より生産的に開発できるよう働きかけることがミッションの一つです。つまり、DevRelとは、開発者の皆さんと『一緒に』創っていく人たちのことです」
これは違う。DevRelは活動であり人ではない。言い間違えたか書き起こしを間違えたのかも知らないが、これでは定義を理解していないと思われても仕方ないし、最重要なキーワードなのに矛盾した定義を見逃す編集者も謎だ。
二つ目はここだ。
はてそんな意味はあっただろうか。安心と信頼のMerriam-Websterで調べてみよう。
https://www.merriam-webster.com/dictionary/advocate
Definition of advocate (Entry 1 of 2)
1 : one who pleads the cause of another
2 : one who defends or maintains a cause or proposal
3 : one who supports or promotes the interests of a cause or group
Definition of advocate (Entry 2 of 2)
transitive verb
: to support or argue for (a cause, policy, etc.) : to plead in favor of
intransitive verb
名詞の方は、一つ目は「主義・主張を代弁する人」、二つ目は「主張や提案を弁護する人」、三つ目は「特定の集団か主義の利益になるよう働きかける人」という意味だ。
「鼓舞する人」というのはだいぶ意味合いが違う。鼓舞するならinspiratorとかになると想像がつきそうなものだが、なぜその意味が近いと思ったのだろうか。DevRelとアドボケイトは記事の肝心となるはずの言葉だが、どちらも説明に不備があっては話の筋が崩壊しかねない。
エバンジェリストからアドボケイトになったとのことだが、エバンジェリストについての記述も詰めが甘い。
https://twitter.com/ayatokura/status/1021190099747262464
今年度は国内では、マイクロソフトのエバンジェリスト(西脇サン除く)という役職は消え、元同僚はソフトウェアエンジニアや別の役職へ転身するかたちに
つまりその時点でエバンジェリストという肩書きは消滅した。つまり
CSEのエバンジェリストが担当企業を訪問し、必要に応じハンズオントレーニングを行い、そのあとは数日間部屋にこもって一緒に実プロダクトの開発を一気に進める。いわば担当企業向けの特別なハッカソン。
したがって「CSEのエバンジェリストが」というのも明らかに矛盾した表現である。インターネットミームにされたり詐称されたりして可哀想な言葉だ(好きか嫌いかでいえば嫌いな言葉だが)。
DevRelやアドボケイトというのはそこまで普及していない言葉で、不思議に思っていた人も多いだろう。そんな中公開されたこの記事は、人々に誤解を植え付ける結果を招いた。
↓
利ざやを大きくするため小ベンダーを安く買い叩くまたはSESで80万円/月程度の単価で人買い
↓
↓
不人気職種となって(もちろん少子化も相まって)人材不足に陥る
発注する側が全然大したことないシステムに巨額を費やさざるを得ないくらいSIerとガッチリ癒着した構造はもうどうにもならない。
しかもマーケティング力のない小ベンダーがそのようなシステムの改修を担う技術力も人員も持ち合わせず、結局はSES事業とならざるを得ない企業が跋扈しているのが現状。「出向させませんよ」なんて言う小ベンダーや受託開発企業はごくごく少数。
いろいろ有って２年ほど努めた会社を離れることになった。職種はWEBエンジニア。主にフロントエンド担当、ポジションとしてはリーダー格。所属会社はいわゆるWEB系ベンチャー。
何社も経験しているジョブホッパーだが、スキルや経験はこの会社で一番貯めることが出来たし、一緒に働いてきた仲間はいい人たちだったので感謝している。しかし事業の方向性と自分の方向性がずれ始めたので会社を離れることになった。
この会社では採用も担当することが出来、そのおかげか今回の転職活動は人生で最もスムーズで、かなり質の高いオファーを複数もらうことが出来た。どこも魅力的な会社で高い評価を頂いているので、辞退する会社には正直申し訳なく思う。もちろん超売り手市場の超売り手職種ということもあり、自分の実力以外の側面も強いのだが。
そこで2回に渡ってありきたりだけど、転職について書きたいと思う。今回は採用側としての視点で書く。
※自分の身バレ以上に応募者のプライバシーのほうが問題なので、ある程度ぼかして書いてます。
100名近く会って実際に通したのは5〜10程度。一次通過率厳しすぎじゃね？って思われるかもしれないが、自分としてはできる限り通すつもりでやった。それでもこの結果だった。
フロントエンドエンジニアということなので、最低限「HTML/CSS/JavaScriptでコーディングできる人」「Gitを使った開発ができる人」という観点でだけしか見ていないのだが、それすら至っていない人が多かった。
「職業訓練校で習ったので、AdobeとHTMLとCSSは出来ます、jQueryプラグインは設置できます。Gitってなんですか？」とか「制作会社でLPを量産してきました。Reactってなんですか？」とかそういう人である。
いくら売り手市場とはいえ、Webアプリ開発者を求めているので、このレベルの人を採用して教育するほどの余裕はない。最低限学習意欲や、キャッチアップする能力があればいいのだが、こういう人に限って「これから頑張ります」という感じなので、正直お断りしていた。
こういう人は本来であれば書類でスクリーニングすべきなのだが、会社自体が有名ではないせいか応募母数が多くないので、こういう人も書類は通していた。
逆にSIerや社内SEからの転向組の方も多かったが、「JAVAで基幹システム作っています、バージョン管理はSVNです。Angularってなんですか？」とか「社内システム開発でベンダーコントロールしてました。希望年収は現職と同じく700万です」とか。もちろんGitHubアカウントなど持っていない。なぜ弊社に応募してこようと思ったのか謎である。
恐らく流行のモダンフロントエンドとRailsでGitHubでPR開発という、ベンチャーによくあるキラキラした部分に惹かれてきたんだろうけど、それにしても準備しなさすぎじゃないですか？この手の人に少し技術的に突っ込んだ質問をすると、大体とんちんかんな回答が返ってくる。
そもそも、いくら応募母数が少ないとはいえこういう人を書類通過させるのもどうかと思う。もうちょっと書類でスクリーニングしてくれと言ったが、自分の意見は通らなかった。ちなみにその上司ももう会社にいない。
上記に書いた社内SE氏もここに含まれるだろうが、それ以外にもこういう人がいた。
「43歳で現在雑用アルバイト。会社のホームページ担当を片手間でやってます(一応paizaではS判定)。ところどころ空白期間あり(聞いたらガチニートだった)。Gitってなんですか？」とか「38歳でコンサル会社でマーケティング担当ですが、技術的スキル手に入れたいのでキャリアチェンジしたいです。スクールでWEBコース勉強してます。Vue.jsってなんですか？」とか。
どちらも普通なら書類落ちレベルだが、前者の方はpaiza経由なので面談確約だし(paiza経由でGit知らないとかギャグかと思った)、後者の方もポテンシャルによっては通してもいいのだが、年齢の割にちょっとキャリアに考えが甘すぎると思ったのでお断りした。
正直なところ、自分もジョブホッパーだしあまり性格がいいとは言い難いし、実はそこまで人柄は見ていないのだが(どんな人にも長所短所はあると思うので)、それにしてもちょっとこの人とは働きたくないなと言う人はお断りした。
具体的には「前回面談で日程勘違いですっぽかしたにもかかわらず、再設定された面談で一切謝罪もなかった」とか、退職理由を聞いたら「上司や同僚とうまくいっていない、自分にはもっとふさわしい職場がある」とか、技術的に少し乖離がありますが大丈夫ですか？と聞いたら「そんなの調べれば出来るし、大した問題ではない」と逆ギレ的に回答してくるなど。
ちなみにこれは全部同じ人。あまりにもひどいので速攻でお帰りいただいた。エージェント経由だったので、一応人柄でこれは駄目でしょ的なフィードバックを返したけど、多分こういう人は改まらないだろう。そもそもすっぽかした人を再面談なんてありえないと思うんだけどね(これは会社批判)。
ジョブホッパーの自分が言うのもアレだが、こういう人は次の職場でも同じ問題で離職することになるだろう。まずは自分を客観視することからおすすめしたい。
その人はもともと難関大学と出て難関資格を持っていて、それなりに高い給与をもらっているハイスペックな人だったが、WEBエンジニアになりたいということで海外にエンジニア留学したといいう人である。
と、ここまで聞けばポテンシャルだけでも一次通過でいいような気もするが、肝心のGitHubの成果物がいわゆるスクールで勉強したものそのままという感じで、あまりクオリティが良いものではなかった。
聞いてみると、その成果物もスクールの仲間で作ったもので、実装は他の人がやっていて、自分はプロマネポジションをやっていたということである。
年齢も若い人だったので「弊社みたいな有名ではないベンチャーではなく、いわゆるメガベンチャー的なところとか受けなかったのですか？あなたならそこでも活躍できそうですよ？」と聞いてみたところ「そういう大きなところでは、自分で手を動かすことが出来なさそうだから考えてないです」とのことである。言ってることとやってることがちぐはぐである。
こういう人に必要なのはスクールに行くことではなく、まず自分がやりたいことを明確化して、実際にそれを実現するには何が必要かを考えることではないだろうか。
正直なところ、無理にエンジニアになるよりも大きな会社で、プロデューサーポジションとかに行ったほうが幸せな気がする。ただそういうところも「意識高い系」はいらんだろうけど。
通した人は母数があまりに少ないのだが、だいたい同じような傾向である
年齢や経歴はバラバラだけど、方向性はだいたい一緒である。正直なところ、実はそこまでハイスペックな人を求めているわけではないし、有名ベンチャーみたいにアウトプット原理主義というわけでもないのだが、ハイスペックな人はだいたい上記が当てはまる。
さてこれだけ頑張って一次面接通しても、最終的に採用に至ったのは2名である。経営者と現場の判断はまた別なんだろうし、うちで欲しい人はよそでも欲しいので辞退もそれなりにあった。
エンジニアはエンジニアリング以外したくない、自分の業務以外はしたくない、という人も多いだろうが、採用に参加するのは自分にもメリットがあるのでおすすめである。
チーム作りとかそういう意識高い的なことでもなく、ひたすら自分の他メリットとして考えても十分有用である。実際に自分の面接官として苦労した話をすると共感を得ることが出来て、非常に有効だった。
id:xlc 人が集まらないのはあなたの会社に魅力がないから、という前提を忘れているんでないかい？
まさにそのとおりで、だからこそ採用に苦労するし、それどころか自分を含めて次々と離職している。ただ今回は自分の採用視点でのナレッジを活かしたいからこういうのを書いた。
リファラルがどうのとマネージャーが言ってきたときは「うちの会社にリファラルで人を採用できるような魅力あると思う？」と言ったらぐぬぬとなっていたｗ。
採用手当以前に、まずは作っているプロダクトと労働環境を魅力的にしろと。
M社の例の怪文書は採用強者側の視点で、自分が書いたのは採用弱者側の視点。強弱にかかわらず最終通過率が殆ど変わらないのが興味深いと思う。
id:thesecret3 100名も会って採用1～2名なら人材紹介か社長の一本釣りのほうがよくないか？
社長はエンジニアの実務層への伝手はほぼ皆無だし(ビジネス出身だし)、人材会社はエージェントを使ってたけどほとんど効果なかった(M社と同じ感想)。いわゆるヘッドハンターを使うほどの金はないし。エグゼクティブではない実務レベルの人をヘッドハンティングするのは。。。これに関しては求職側編で書く。
30歳までにプリセールス系の技術営業か、もしくは別業種の社内SE兼みたいな社員、もしくはPMとか管理職系に行けないけれど、現場の技術と経験だけは妙にあるという、中途半端なオッサンがエルダーと呼ばれる存在になる
↓
ベンダーより年上になるので使いづらくアサインさせづらいので「オッサンなのにぶりっ子」とかいう、他の業種なら気持ち悪くてそもそも採用試験に受からないような存在に進化する
↓
仕事取られるのいやだから、やたら仕事をブラックボックス化する、立場の弱い人間見つけて仕事教えないけど押し付けてわざとミスさせるように誘導させて自作自演でピンチを切り抜けた風を演出し、アピールを始める
↓
仕事が回らなくなり始めてプロパーに負担が増大して人間関係めっちゃギスギスし始める、新しいエンジニアアサインさせても、すぐいじめて追い出すので定着がしなくなり、片肺飛行でさらに負担が増大する
↓
職場を何とか回してる同時期アサインのエンジニア(※俺)が呆れて辞めて、ついに職場完全崩壊、オッサンエンジニアは戦犯指定の誹りを受ける前に即トンズラ
何で高齢エンジニアが嫌われるか理由がよくわかるだろうし、ITがブラックって言われる所以はここ10年こういう面が一番ﾃﾞｶいと思う
奴等はホワイト職場を破壊する天才だし、エルダーでマトモだった奴は体感比率的に今まで10人に1人くらいしかいない
俺も稼げるからとこういう奴が集まってきそうな案件にいったのが悪かったんだけどな
まあ、なんだ。こういう他の業種なら、存在することさえ許されない変なおじさんと顔を突き合わせて仕事をしたい人は、IT業界に来ればいいんじゃないかね
初めてサボンのスクラブ使ったとき、私の肌こんなにすべすべになるんや…って感動したんだけど
窓も全開にして換気したのに
翌朝異臭騒動になった。
ニベア青缶を顔に塗ったらその臭い気持ち悪いって言われてしまうくらい
洗濯はアリエール(無臭)とハミング(水色のボトル)の組み合わせ以外使えないのね。
ハミングも優しくて大好きなんだけどさ。
フローラルとかシトラスの香りがしっかり残る柔軟剤(レノアハピネスとかフレアフレグランスとか)を使っているお家の子憧れだった。
サボンのスクラブ買うときも、大丈夫かなって思いながら買って使ったけど
一週間くらい文句言われ続けて結局自室の棚の奥にお蔵入りしてしまった。
その時思ったよね、一人暮らししようって。
アラサーという年齢に片足を突っ込んでいたのもあって、
戻れる家があるうちに一人暮らし経験しておかないとやばいなっていう気持ちもあったし。
今が良いタイミングなんだろうなって決意して実行。
結果、最高。
季節や気分によって香りを変えたりするの楽しくて仕方がない。
職場の人やお友達になんかいい匂いするって言われると、そうかな～？なんて
すっとぼけてるけど、内心よっしゃーーーーー！！！！ってなっている。
夏場はラリンのフローズンペアのスクラブとボディーオイル使ってたんだけど、
最近涼しくなってきたから、サボンのパチュリラベンダーバニラに戻そうかなー？
実家に居たときほど経済的に余裕はないけど、居たら出来なかったであろう経験が出来ているから
一人暮らし始めて良かったなーって思っている。
しんどくなったらおとなしく実家戻ろう。
これからもスメハラに気をつけながら楽しく使っていこうと思う。
なんだよ私実家大好きかよ。
※この記事はウィスキーストレートの影響により読みづらい部分があります。
クラスやインスタンスすら知らない人達がJavaエンジニアを名乗ったり、Hueのデモをしただけで IoT 特区に派遣されたり
色々不安はあったので、いつか転職しようとは思っていたが、これがまた微妙にぬるま湯な環境なので特に行動しなかった。
インフラ系なんで経営的には過去最高だったり（でも給料はかわらない）会社の存続を心配することは皆無だけども
特定派遣法も厳しくなったこともあり、エンジニアリングより営業や、データーセンターのベンダーコントロールを任されることが増えてきた。
中学の頃からVBをやっているくらいプログラミングが好きなので、
来年の３０前に転職を経験しておこうと思って活動してみた・・・わけだが。
書 類 す ら と お ら ね え ^_^
とりあえず、”業務経歴として”開発できることを求められることがわかった。
ちなみに、自分のコーディングスキルは、学生の頃にSDL、末期にはXNAやcocos2dxでスマホゲーくらいなら作ったことがある。
Unityはまったくしらん。
Web系では vue.js+rails で社内（２０００人程）向けの okweb的なものはつくったりもした。これは割と好評だった。
しかし、振り返れば、確かに「一般サービスの開発経験」は皆無だし、自分が業務でやってきたのは公共系の改修作業がメインで、
新卒であれば、業務経験は問われないので、そういう意味では新卒で入る会社を誤ってしまったようだ。
最近はこのままぬるま湯でもいいのではないかと考え始めたので、僕はこのまま現状維持になりそうだが、
ここ数日Twitter界隈で猛烈に叩かれているサマータイム。
システム的な面を中心にどれだけ不利益が出るかの解説は出尽くしていますが、まだの方はこちらなどをご参照ください。
「サマータイム実施は不可能である」 https://www.slideshare.net/tetsutalow/ss-109290879
本稿では、そのような反対論が特段意味をなさない、すなわち私が「サマータイムに反対しようが賛成しようがどっちみち実現しない」と考えていることについてお話しします。
まず、これらの記事を見てください。特に後者の安岡孝一先生（京都大学人文科学研究所教授）のブログは、本エントリを書くきっかけになり、同時に執筆に当たり大きく参考にしています（一つ一つ参照元の文を示すことは省略させていただきましたことをご容赦ください。）。安岡先生に感謝申し上げます。
「東京五輪終わっても「サマータイム」恒久的運用へ 議員立法による成立を目指す : スポーツ報知」 https://www.hochi.co.jp/topics/20180808-OHT1T50025.html
「日本の法令における「一日」と「二十四時間」 | yasuokaの日記 | スラド」 https://srad.jp/~yasuoka/journal/623028/
---
◆夏時間への切り替え方 導入初日を４月の最初の日曜日とした場合は午前２時に２時間進め午前４時に合わせる。夏時間が始まる日曜日は １日が２２時間になる。１０月最後の日曜日をサマータイムが終わる日とした場合は午前４時に２時間戻し午前２時に合わせる。この日は１日が２６時間となる。
---
必ずしもこのような立法がなされるとは限りませんが、少なくとも夏時間を採用した場合には、同日に同じ時間が2度到来します。2時間をずらすサマータイムであれば1日26時間の日が発生します。そしてこの場合、2つのパターンが想定されます。
①午前0時～午前1時59分59秒の終わりまでが2回あるパターン
②それ以外のパターン
日本の戸籍では、時間単位の記載が行われる事項は必ずしも多くはありませんが、有名どころとしては死亡時刻が挙げられます。
なぜこれが必要かといえば、死亡の先後によって相続の順位に変動が起きるからです。
祖父・父・息子・息子の妻の4人を思い浮かべてください。この4人には、これ以外の身寄りが一人もいません。そして、サマータイム終了日には、午前4時の時点で時計を午前2時に戻すものとします（上記②のケース）。
さて、父がある日の午前3時ちょうど、息子がその1時間30分後に亡くなったことを想定します。民法の規定に従えば、父が死亡した時点で相続が発生し、父の財産の全ては息子に相続されます。そして、息子が死亡した時点で、父と息子の財産の全てが息子の妻に相続されます。簡単ですね。
しかし、日本の戸籍は残念ながら24時間表記ではなく、午前/午後n時という記法を採用しています。彼らの戸籍はどうなるでしょうか。現行制度に基づけば、父の死亡時刻は「m月d日午前3時」と、息子の死亡時刻は「m月d日午前2時30分」と記載されます。さて、これで両名の死亡順序が入れ替わってしまいました。この通りの記載であれば、まず息子の財産を父と息子の妻で分配することになります。そして、父の死亡によって父の財産の全部と息子の財産の一部は祖父に相続されます。
何を言いたいかといえば、死亡の順序によって相続割合は変動するのです。
上のような不具合を回避するためには、「午前2時」から「午前3時59分」までの間の時刻に、例えば「一回目」や「二回目」といった表示をする必要があります。
昔ながらの手書きの戸籍であれば、これは割合簡単なことです。しかしながら、全国の4自治体を除く全ての地域で戸籍はコンピューター化（電算化といいます。）されています。その自治体名などはこちらをご参照ください。
「戸籍電算化 | 晴れのち曇り時々雨 http://www.kumori.net/koseki/」
電算化された戸籍のシステムでは、当然この「一回目」というような文字や記号を挟み込む機能がありません。そして、上記①の場合でも、戸籍は24時間表記ではありませんから、やはり「午前0時～午前2時」が2回生じますから同じことです。さらに、自治体が使用する戸籍のシステムは、法務省が統一的に開発したものではなく、各自治体が個別にベンダーと契約して導入したものです。ベンダーはおおむね数社に集約されていますが、互いに独立したシステムですので、その改修はシステムごとに行うことになります。
次に、スケジュール的なことを考えましょう。「サマータイム法」を提出しうるのは最速でこの秋の臨時国会ですから、まあ10月頭ぐらいでしょうか。そして、サマータイム法案は議員立法（下記参照）であって、決して成立が確定していませんから、早くとも法案の提出時点から前述の戸籍の記載に関する法務省令なり通知なりの立案を始めることとなります。
「【東京五輪】酷暑対策でサマータイム導入へ 秋の臨時国会で議員立法 ３１、３２年限定（1/2ページ） - 産経ニュース https://www.sankei.com/politics/news/180806/plt1808060002-n1.html」
法案成立後なるべく急いで法務省令なりを出すとして、戸籍の記載方法が各自治体に通知されるのはどんなに急いでも10月頭～中旬となります。
さて、戸籍というものは決して間違いがあってはならないものです。この「間違い」というのにはいくつか意味があり、代表的なものとしては、
A.内容に間違いがあってはならない
の2つを挙げることができます。
まず、Aについては、先ほどの例を挙げるまでもなく、戸籍に関する記載を誤れば一発で国家賠償訴訟、管理職以下懲戒処分まっしぐらです。そのぐらい戸籍は重いものです。そして、Bについても、例えば市民の離婚歴や本籍などの情報が流出した場合、こちらも一発でやばいことになります。そのぐらい(ry この2つの帰結として、戸籍のシステムは、改修に当たっても決して脆弱性を生じてはいけないものであり、同時に、改修後のシステムにもエラーがあってはいけません。
では、これらを満たす改修について、今年度中に全自治体が見積もりを取り、来年度予算に反映させるか最悪来年度補正予算に盛り込み、再来年度までに実装までを終えることができるでしょうか。無理ですね。
ここからが大切です。
法案を書く場合には、必ず「法制局」のチェックを受けなければいけません。官僚さんが書き、内閣提出法案（閣法）として提出する場合は「内閣法制局」、議員さんの発案で議員立法として提出する場合は「衆議院法制局」または「参議院法制局」のチェックを受けることになっています。そして、法制局の方は、ここまで書いてきた不都合を当然ながら分かっています。そして、きちんと「無理です」とおっしゃいます。もちろん、原理的には法制局のチェックを受けずに法案を提出する権限が国会議員にはあります。そうでなければ、言ってみれば公務員に過ぎない法制局職員が国会議員以上の権限を有することになり、国民主権に反します。しかし、実務はそのように動いておらず、法制局と何かしらの妥協に至ることになります（明らかに憲法違反の議員立法を提案される先生方も現在の与野党問わずいらっしゃるようですが、その辺は法制局の方が努めて雅な言い回しで案文に落とし込まれているようです。）。しかし、これに関しては法制局の方も法務省民事局の方と一緒になって「無理です。」と言わざるを得ません。妥協の余地がありません。そして、このエントリよりも遥かに分かりやすく不都合を説明されます。この時点でサマータイム法案は葬られます。以上。
ここまでのことを極めて短く書けば、「サマータイムは法制局チェックを通らないので実現しない」ということになります。みなさんどうぞご安心ください。
それでもサマータイムが実行された場合、それは本格的に明白な違憲立法も法制局を無視してバンバン通りうる社会になったということです。サマータイム以前の問題なので共に悲しみましょう。
なお、刑法・刑事訴訟法上の刑期や勾留期間を含めた1日が24時間であるという前提に基づく各規定については、確かに23時間や25時間の日の存在を想定していないというのはそのとおりですが、おおむね①時間単位で規定しなければならないほど短い期間は時間で、②乱暴な言い方をすれば数時間の誤差は許容されるような期間は日数以上の単位で規定されていますので、混乱が生じることはあっても法制上そこまでの支障にならない気がします。
安岡先生のこちらのコメント（なお、こちらのリプライ先になっている刑事訴訟法に関する指摘は私のものではありません）
https://srad.jp/comment/3459182
は、危惧としてはもっともですが、時間の計算であればきっかり実際の時間の経過に合わせた例えば「四十八時間後」に期限が到来することになろうかと思います。この辺は民法138条以下と民法の解説書をご参照ください（民法の規定ですが、特則がない限り全ての公私の期間計算に適用されます。）。あくまで本エントリの目的は「サマータイムが実現しない理由」を述べることですのでこれ以上踏み込みません。
元増田が言ってるのはIBMとかじゃなくて中小のベンダーやらSIのだと思うがな
もちろん実際に裁判沙汰になった事例もあるんだけど、納期が遅れたとかバグが発生したとかを金（賠償請求）で解決することってかなりレアケースな気がする（今までいろんな現場に行ってきたけど1件しかない）。あれって何故なんだろう。
それとも納期が遅れたとかバグによって業務がどれくらい滞ってどれくらいの損失が出たとか計算できない（あるいは計算が難しい）から？
もしくは、なんだかんだ文句は言うけど結局のところ自分たちではシステム作れないから下手に金返せとか言ってベンダーにへそ曲げられても困るってことだろうか？（曰く付きのシステムって引き取ってくれる相手がなかなか見つからなかったりするし）
辞めてから数年、もう時効だと思うので、情報システム担当（社内SE）として勤務していた会社での「不本意だった仕事」について書いてみる。
「年賀状を印刷したいんだけど、やり方がよくわかんないんで教えて？」とか「新しいパソコンを欲しいんだけど、○○さんのお勧めってある？」とかの質問くらいなら、仕事中の雑談レベルで答えられた。
だが、自宅用のノートパソコンをいきなり仕事中の私の前に持ってきて、「なんか変なのが出るんだけど」とアダルト広告表示マルウェアに感染した画面を見せられたときは、仏の○○と言われていた自分もさすがに青筋が立った。
「息子がいじってたみたいでさ、もう高校生だからこういうの興味あるのかな」などと言っていたが、それにしては人妻熟女系の広告ばかり表示されていたのは、そういう趣味のご子息だったのだろうか。
そんな社員の一人が同業他社に転職したことが判明すると、その社員が使っていたパソコンを調べて機密情報を横流ししていないかどうか調査せよという社長命令が下った。
確かに情報漏洩対策として導入した資産管理ソフトだけど、本当にそういう目的で使うことになるとは思わなかったな…と、辞めた社員ともそれなりに親しかった私は複雑で心が重い気分だった。
結果として情報流出はなかったのだが、辞める前のネット検索の履歴に「退職 円満」「労働基準監督署 契約 異なる」などとあって、暗い気分になった。
導入した基幹システムのトラブルが短期間に相次いだため、開発を行ったSIベンダーを裁判で訴えることになった。
ちなみに、現場担当者の私としては、トラブルが多かったのは事実だがSIベンダーの対応は誠実であり、解決に向かう道筋も見えている状態で、責任や費用を云々するよりもまず協同して安定稼働に持っていきたいというのが正直な思いだった。
だが、そうした状況を社長に理解してもらうことができず、社長はSIベンダーを訴えた。もちろん訴えるまでにいくつかの段階を経てはいるのだが、私としてはいつのまにか裁判が決まってしまったという印象しかなかった。現場の言い分を聞く前にいきなり社長がSIベンダーに怒鳴り込んだ、という感じ。
そして私は、裁判に際して、基幹システムがどのようなトラブルでどれくらい停止し、それによって本業にどれだけの損失を与えたか、という資料を作るはめになった。
そうしている間にも基幹システムのトラブルは収まらず、その対応に追われながら（しかも裁判のおかげでSIベンダーの手を借りることも難しくなり）、1ミリも本業に関わらず1円の儲けにもならない資料を黙々と作成するのは苦行であった。お世話になったSIベンダーの担当者の顔が思い浮かび（もちろん彼らとは裁判以降縁が切れてしまった）、心苦しさでいっぱいだった。
日本のIT産業の価値の多くは大手SIに酷使されるITベンダーが作り出す社内向け業務システムやら政府の公開してるシステムが生み出してて今後も変わることはなく、Java身に付ければ食いっぱぐれることはないんだろうなと思ったりはする。
フリーでやってる時期にrubyやらpythonやらのWEB系の仕事より、javaとかphpのお堅いシステム屋の案件の方が単価は高かったし。
rubyとかpythonのコミュニティ見てると今それらにハマってる人って新しいおもちゃが出てきたらそっちにいっちゃって更に新しいおもちゃが出てきたらそっちに行くの繰り返しで、結局rubyとかpythonはphp程の勢力を持たずに終わりそうな気がしてくるんだよね。
