  |
はてなキーワード: ベンダとは
https://anond.hatelabo.jp/20211012135349
これを知るにはSIerとは何なのかを知る必要がある。Twitterなんかだと「リスクテイカー」だとか「プロジェクト代行業」だとか
色々言われているが中の人から見ればその全部が半分ぐらい当たってるみたいな感覚ではないだろうか。
結局SIerっていうのは「IT (ICT)」っていうキーワードをネタに何でも商売する会社ぐらいの意味だと思ったほうがいい。
なので人種としてはITのドメイン知識があるコンサルの集合みたいな感じ。なのでまともなエンジニアはほとんどいなくて
何でも屋というとよくわからないが、いわゆる大手SIerに共通する精神はある。それは他社のビジネスモデルの乗っ取りだ。
結局今の時代はITがなければ業務が回らない世の中になったので、ITを牛耳ることでその会社のビジネスモデルから
生まれる利益を掠め取るというのが大きな目的になっている。つまり自分でビジネスモデルを作らずに他社のビジネスモデルに
乗っかって、あわよくば根こそぎ旨味を奪おうという集団なのだ。
これがよく分かるのは大手SIerになるほど上流思考が強いところからもわかる。これは「RFPや要件定義もおまかせあれ＾＾」
という甘い顔をしながら近づいてきて、他社のビジネスモデルから利益を吸うためのホースを付けるような感じだ。
そのためのホースがITというだけで、別にSIer自体はITにはほぼ興味はなくそこから利益を掠め取れればよい。
しかもそのホースはビジネスモデルの心臓部をぐるぐる巻きにしてあり、下手に取り外すと致命傷になるようにうまく設計されている。
一般にベンダロックインというと特定の商用製品でないと動かないようなシステムを作られてその保守料を延々と払わされる
みたいなイメージがあると思うが、一番ひどいパターンは業務ロジックをすべて握られ、顧客は自分たちの業務の全体が
一旦どんな感じになっているのかを把握してない状態で何故か会社が回っている…みたいなものだ。
これは銀行や電力、公共などではよく見られるパターンである。顧客担当者的にはめんどくさいところ（でも本来は利益を生むところ）
を代行してくれているのでとても助かると錯覚してしまう。そんなこんなで悪性の共依存が日本の大企業の中では至るところに見られる。
https://anond.hatelabo.jp/20211004123017
この増田、薄っぺらい理由でiPhoneを貶めてる気がして全然フェアじゃない気がする
しかもどっちかというとAndroidがメイン機、iPhoneはサブっていう運用だったがつい最近iPhone単独運用に切り替えたのでその理由を解説する
Androidは激安クソ品質のXaiomiだけじゃなく、高級路線のASUS Zenfoneやコスパ最強OppoのReno、キャリア・国内系だとSONYならXperia、SHARPならAQUOS、サムスンのGalaxy、その他Rakuten Mobileオリジナルとかdocomoオリジナルとか死ぬほど機種がある
そんで機種の選定は基本的にSoCの性能をベースに考える必要があってSnapdragonの何を使ってるか、メモリ量は、カメラ性能は、バッテリーはって感じで無限に考える必要がある
性能面でバッチリな機種に出会えたとしても実物がガッカリ品質なことや色が好みじゃ無いことも多いし、そもそも実物確認できない場合も多い
おまけに特に中華系は最初の1年はまともなんだけど2年目から全然使い物にならないってことも多いし逆にAndroidの最新版が落ちてこないことも多々ある
「最近はマシになった」
と言われても最近から1年も経ってない以上は信用できないしそもそもAndroidのようにOSと機種が別々に提供される以上はリスクが必ず残る
加えてHUAWEIみたいにBAN食らってGoogle Playから閉め出されるとかいうリスクも相当に高い
iPhoneは機種が増えたといっても数は少ないし家電量販店に行けば必ず実機を触れる
加えてOSと機種を同じメーカーが手がけてるので古い機種へのサポートも万全で
未だにiPhone 6 plusが使えるし、今使ってるiPhone 12はあと数年は確実に使えるだろうという安心感がある
こういう考えるコストを減らすっていうだけでもiPhoneはかなり有益
iPhoneが未だにLightningなのには本当に驚いている
Android系がType-Cなのにも驚いている
もう時代はとっくにワイヤレス給電のQiになってると思っていた
iPhoneの場合はMagSafeでピタッとくっつくから全く不自由ないし、特に自動車で充電するときが便利すぎる
Lightningの口は全く使ってないから塞いでおきたいぐらいだ
これはiPhoneの利点という訳では無く、Android使ってたときもQiを使うか、そうでなくてもマグネット系のケーブル買ってきて抜き差しをしないようにしてた
充電口を無くすことが故障率を下げる有効手段なのだからQiを推進して欲しいし、なんなら充電口なしっていう尖った機種を出してもいいと思う
いつまでType-Cのケーブル選びで消耗するの？ワイヤレスでいいよ
iPhoneはカメラ性能をやたらCMするし、13だとシネマティックだなんだとCMしてるけれど
特にSONYがIMX586（4800万画素CMOS）を発表したあたりで歴然と差が付いた
他にもHUAWEIは6400万画素とか、Xiaomiは1億画素とかもう無茶苦茶になってきてる
ただ、この高画素に耐えうるだけのレンズ性能はまだないので実用上効果があるかはかなり疑問だ
今のiPhoneの前はZenfone 6を長らく使っていたので4800万画素の写真も撮りまくったが
最初の1ヶ月ほどは楽しく撮影していたものの、途中から「そもそも写真とは」という考えに陥り
ちなみにiPhone 13ユーザが「手ぶれ補正が凄い！」と喜んでる姿を見るが
残念ながらZenfone 6の時点でその程度の手ぶれ補正は付いてたし、HuaweiやXiaomiも同等の機能は昔からある
結局のところこの理由はかなり大きい
iPhoneのみで発表されるアプリはあっても、Androidのみっていうアプリはほとんどない
もしくはAndroidで発表されてるアプリの品質は悪いけれどiPhoneはまとも、っていうのもよくある
最近だとClubhouseがそうだったし、Cocoaアプリなんかも記憶に新しい
IoT系のデバイスとかAndroidもアプリがあるけどバグ修正が放置されてて実質使えないとかも多々ある
仮に限られたリソースでiPhoneかAndroidかどっちかでリリースしろと言われたら間違いなくiPhoneになる
ワールドワイドで見てみればiOS vs Androidという形ならAndroidなんだろうけれど
前述したように期首が乱立しまくってるのでAndroidでアプリを公開すれば全機種で使えるというわけじゃない
アプリ開発者からするとiPhoneに対応さえすればかなりの人数にリーチできる
このアドバンテージは恐らく逆転することが無いだろうしiPhoneの最大の利点だと言っても良い
Googleはこれを挽回したいからPWAとかFlutterとかを進めているがAppleは乗り気じゃ無い
結局、iPhoneを使う人がAndroidを使えば不満が出るだろうし、逆もまたしかりだと思う
iPhoneのこれを使いたい、とかAndroidのこれを使いたいっていう明確な理由があるならその機種を使えば良くて
そうじゃないなら乗り換える必要がない
他人が何を使おうがPlayStationとSega Saturnの争いのように勝った方が有利になることもないので
使いたい方を使わせればいいと思う
https://togetter.com/li/1714221
高木浩光氏による「デジタル庁によるnote発信における問題点の指摘」が話題になっているが、この焦点となっている
「政府機関等の情報セキュリティ対策のための統一基準群」（通称：統一基準群）について、誤解を前提としたブコメがあまりに多いので簡単に概要説明。
あくまで「統一基準群って何？」という大前提についての話で、高木氏の指摘内容自体は説明しない。
●原本はここ
https://www.nisc.go.jp/active/general/kijun30.html
現在令和3年度版策定中なのでこれが現行。全文が公開されている。
「群」と言われている通り、規範－指針－基準及び基準策定ガイドライン、という階層構造の文書群。
専門家でなくても判るよう噛み砕いた文章にはなっているが、規定である以上正確性を担保した文章で、読み飛ばせないゆえに、全体理解には相当負荷のかかる文書群ではある。
但し無論根拠法は存在する。法律（サイバーセキュリティ基本法）において「国の行政機関等はサイバーセキュリティに関する対策の基準を作成しなければならない」と定められていて、「だったら個別に各機関で作るより統一基準を作ろう」という事で、内閣サイバーセキュリティ センター(NISC)が作成しているのがこの文書群。
中央省庁全てと国立行政法人の大半はこのセキュリティ基準を採用していて、ITシステムの導入/運用にあたっては、この基準を守らなければならないというルール。
なお法令ではない以上、破っても罰則があるわけではない。（法律上の義務も「基準の策定」であって「基準の遵守」ではない）
統一基準群は「基準策定ガイドライン」という文書が含まれているとおり、わりと大枠の基準。それなりの自由度が設定されていて、「これをベースラインとして現実的な対策／実要件はこの基準の範囲内で、各省庁(独法)で細部を定めてね」という主旨。
今回の件は（デジタル庁独自基準がどうなっていようと／例え実際のセキュリティ上の問題が無かろうとも）、そもそもこのベースラインの内容に反しているからダメなんじゃね？というのが高木氏の指摘。
膨大な文書であり、かつ行政文書にしてはしばしば改定される（セキュリティ対策なので当然の話）ので内容をきっちり把握している省庁の担当者は正直あまり多くない印象。
IT専門の部署でない部局が行うITシステムの調達では「セキュリティについては統一基準群に則ること」と仕様書に1行記載してすませる(＝設計内容丸投げ)ケースも多い。
統一基準群に基づき独自の具体的基準をきっちり策定し、基準を順守した設計となっているか目を光らせている省庁部局となると非常に限られる。(もちろん厳しい所は厳しい)
セキュリティ基準の必要性は当然なのだが、ITシステムにおいて、何も言われなくても仕様書の一行に対し数百項目の対策リストを出してくるような、統一基準群と標準ガイドライン群(注)に代表される中央省庁独自規則に精通した技術者を抱える特定ベンダに（入札自体はオープンで公平であっても）発注が集中してしまう実状を生んでいる一因でもある。
近年は統一基準群も標準ガイドライン群も「クラウド・バイ・デフォルト」を原則として、外部SaaS等の利用を積極的に推奨する方向の規定にしているのだが、そもそも統一基準群を把握している担当者が少ない現状では、方針がそうなっていてもなかなか浸透しないのが実態かと思われる。
把握できてない以上意図してなくても本件のようなやらかしを踏み抜く可能性がつきまとうわけで（SaaS事業者は統一基準群を守れているか、なんて回答してくれない）、そこを恐れる実務者の気持ちは分からないでもない。
（注） 標準ガイドライン群
正式名称「デジタル・ガバメント推進標準ガイドライン」。セキュリティ面以外のIT利活用の指針文書群。こちらも膨大な文書群で、中央省庁のIT関連ルールにおいて把握が大変な点で統一基準群と双璧。
発注と検収のいたちごっこみたいな仕事に嫌気が差して、入社して2年目からちびちびと転職活動をしていた。
入社して2年目は転職サイトとか転職エージェントとかを使って、もっと手を動かす仕事が良い！みたいな希望で活動した。
何社か応募したけど、採用どころか面接にすら全然届かない。経験も実績もないから、仕様無いと今になっては思う。
でも数少ない面談した企業の方からは「小さくてもいいからWebサービスを作ってみるといい」とか「うちはRails使うことが多いから、Railsわかる人だと嬉しい」みたいな具体的なアドバイスはもらえた。
ちなみにどことは言わないけど、転職エージェントは「年収が下がっていいならすぐに見つかります！」「正社員じゃなくて派遣から始めるのはどうでしょう！？」とか不穏な誘いが多くてすぐに使うのを辞めた。
3年目はもらったアドバイスに従って、仕事の合間に小さなWebサービスを作ることにした。(Railsは使わなかったけど)
流行りのフロントエンドフレームワークを使って、PaaSで公開。テストも書いて、CI/CDもちゃんと整備した。
フレームワークや言語の学習も含めると半年以上かかったけれど、納得のいくものが出来た。
4年目。業務転換があり、ベンダと要件の狭間でストレスが絶頂になった。
この環境から逃げたい、というひどく後ろ向きな理由で転職活動を再開した。
幸い3年目の成果物がある。Twitterの転職タグとかを使って成果物のURLを貼り付けたりすると、5社くらい話を聞いてくれることになった。
驚いたことに、エンジニア業界では有名な会社とかも声をかけてくれたりして、ちょっと有頂天になったりした。
しかしながら結果は惨敗。オンラインのコーディング試験や技術面接に歯が立たず、ほぼ全てがお祈りとなった。
ある企業の面談では、「希望年収の半分くらいなら」と言われたこともあった。この日のことは、未だに忘れられない。
4年目の惨敗を受けて、5年目はしょぼくれていた。
面接で出来なかった問題こそAtCoderなりアルゴリズム本なりで勉強していたものの、「こんなに勉強しないといけないなら、もう現職でいいかな」という思いが大半を占めていた。
なんとなくはてブの技術エントリを読んだり、Qiitaとか面白そうなチュートリアルを手慰みにして時間を潰していた。
そしてそんな折に、知人経由で大手ITを受けてみないかと声をかけられた。
いやいや無茶でしょう、というような有名企業で、自信を喪失していた自分には恐れ多いとしか言いようがない。
とは言え、落ちるだろうから受けない、というのもあまりに後ろ向きな話。
なので、受けるだけ受けることにした。知人の顔を立てる、というくらいのモチベーションである。
内容の詳細は秘密保持の関係から記載できないけど、3年目のサービス開発で学んだ知識と、惰性で技術エントリを読んでいた経験が活きた。
それなりに回答できて、手応えはあった(現職で得た知識とかももちろんあるけど)
結果は通過。そこからあれよあれよと面接ラッシュで、すったもんだありながらも最後は内定。
待遇も満点ではないけど十分な内容で、迷う余地がなかった。強いて言うなら、休みが減るのがちょっとネックかな。
元増田に言いたいのは、一回動くと何かが変わるよってこと。
私が結果としていい転職ができたのは2年目の活動の際に「Webサービスとか作ってみるといい」ってアドバイスをもらえたのがきっかけだし。
ベンチャー企業の人から声をかけてもらえたりするくらい頑張ってるなら、胸を借りるくらいの気持ちで話をしてきたらいいんじゃないかな。
人生の分かれ道は意外なところに落ちていたりするよ
ちなみに私が内定もらったところは、選考中は年齢(と性別)について一切聞かれなかった
自分はここに4年から6年まで通っていた。妹は四谷大塚に行った。理由が値段なのかそれ以外なのかわからん。
通ってる途中でsapixが分離独立して、そっちについて行った生徒もいたけど残った生徒としてはsapixなんてパチモンだよみたいな反発があったかな。
国語の教材がよくて、授業で扱った小説や随筆が面白くて次の日に本屋に買いに行くことがよくあった。大江健三郎とか中勘助とかイザヤベンダサンとかを毎週ランダムに読む機会をもらえて感謝している。
講師はバイトもいたのかもしれないが、中年のいわゆるフルタイムの講師もいて講義は良かったと思う。
希望校には受かった。
最寄り駅まで帰りは講師が引率してくれてみんなで帰ったこととか、進学した後も友達と長い付き合いになったこととか、小学校は楽しくなかったけど塾の思い出はたくさんあるな。
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 136 | 23396 | 172.0 | 38.5 |
| 01 | 60 | 7379 | 123.0 | 63.5 |
| 02 | 15 | 3267 | 217.8 | 57 |
| 03 | 9 | 3920 | 435.6 | 77 |
| 04 | 11 | 2211 | 201.0 | 41 |
| 05 | 6 | 2611 | 435.2 | 37.5 |
| 06 | 17 | 1777 | 104.5 | 44 |
| 07 | 22 | 2693 | 122.4 | 48 |
| 08 | 65 | 6612 | 101.7 | 38 |
| 09 | 91 | 9820 | 107.9 | 48 |
| 10 | 208 | 18526 | 89.1 | 38.5 |
| 11 | 174 | 15949 | 91.7 | 45.5 |
| 12 | 161 | 14850 | 92.2 | 38 |
| 13 | 106 | 17425 | 164.4 | 33 |
| 14 | 119 | 8583 | 72.1 | 40 |
| 15 | 160 | 12793 | 80.0 | 38 |
| 16 | 115 | 13576 | 118.1 | 41 |
| 17 | 130 | 14387 | 110.7 | 44.5 |
| 18 | 143 | 11829 | 82.7 | 37 |
| 19 | 96 | 13986 | 145.7 | 45 |
| 20 | 119 | 14844 | 124.7 | 36 |
| 21 | 162 | 16570 | 102.3 | 39 |
| 22 | 155 | 17593 | 113.5 | 37 |
| 23 | 157 | 47783 | 304.4 | 53 |
| 1日 | 2437 | 302380 | 124.1 | 41 |
日本学術会議(13), 学問の自由(5), 砂嵐(3), フェイルオーバー(3), ナスダック(3), 東証(22), ぐぎ(5), ベンダ(4), アイコラ(4), PostgreSQL(3), CIO(3), 滋賀県民(3), 長男(11), スパム(23), 子作り(10), 産め(8), post(14), 1%(8), 産ま(13), 再婚(6), 毒親(18), ユーチューバー(6), トランプ(19), 産む(14), 名誉(10), 学者(11), 京都(14), 弟(12), m(14), 子育て(20), 会議(15), 出産(19), 育て(22), 障害(23), 離婚(21), 育っ(15), 完璧(13), 土地(12)
■子供作るときどんな覚悟だった？ /20201001170719(60), ■取り返しのつかない人間が職場に来た /20201002023509(30), ■滋賀県って可哀想だよな /20201002002113(28), ■ストレスが溜まると配偶者を虐めてしまう /20201001091449(11), ■俺は男だが(こう書いてもきっと女扱いされる)、増田の原住民は女に厳しい /20201002151539(10), ■日本人について(真剣な話) /20201001124407(10), ■東証システム障害と同時刻に発生したごく小規模な障害との戦い /20201002003926(9), ■東証障害について東証従業員の立場から /20201001221611(8), ■モテない4年間だった /20201001182448(8), ■そこそこ儲けてるイケメンにどう勝てばいいの？ /20201002210238(6), ■嫁がありとあらゆるメニューに隙あらば餡を混入しようとする /20201002101427(6), ■世界はそれぞれにあって、それぞれの苦悩に声を上げればいい /20201002132507(6), ■ITエンジニアの東証CIO賛美がマジで気持ち悪すぎる /20201002175434(6), (タイトル不明) /20091002221208(6), ■anond：20201002103921 /20201002104059(5), ■anond：20201001170719 /20201002105043(5), ■ /20201002204549(5), ■同性の恋人がめちゃくちゃ可愛いのでノロケを聞いてほしい /20201002012613(5), ■自宅で首吊りできる場所は案外無い /20201002174148(5), ■29歳高卒フリーター、SESに就職することを決意 /20201002205304(5), ■深夜の増田良すぎる /20201002015239(5), ■セックスを茶化すな /20201002095024(5), ■ /20201002184044(5), ■はてブって左に偏りすぎじゃない？ /20201002103727(5)
5GHz帯だと、国内ベンダしか対応してない感じの5.6GHz帯しか屋外利用が許可されてないんだけど、屋内に設置した機器同士で屋外を通る形で通信するのはどうなんだろうね?
ちなみに2.4GHz帯なら問題は全くないです
ITでは「ミント味のガムを製造することを認めてよいかどうか」を決めるのはエンジニアであり、そしてエンジニアは実装言語の仕様書を読んでいるだけで、更にその仕様書は半導体ベンダが決定し、加えてその仕様書も主にカリフォルニア辺りの国立大学の発明を言語化しただけのものだ。
https://b.hatena.ne.jp/entry/s/www.timakin.com/posts/hacker-and-suits/
IT技術者のイメージが確立した頃のITというのは基本的に技術が収益性を決定していた。ビジネスの人間からすれば「おかしなこと」で、普通に考えれば顧客が何を求めているかが問題だ、という意識があったはずだ。
例えば、(フォードの速い馬車という意味ではなく)顧客がミント味のガムを求めていることが判明したとする。当然、ミント味のガムを製造すれば儲かる! のだが、ITでは「ミント味のガムを製造することを認めてよいかどうか」を決めるのはエンジニアであり、そしてエンジニアは実装言語の仕様書を読んでいるだけで、更にその仕様書は半導体ベンダが決定し、加えてその仕様書も主にカリフォルニア辺りの国立大学の発明を言語化しただけのものだ。つまり、ITにおいては、顧客が何を言おうと、経営者が何を提供したくとも、カリフォルニアの国立大学の研究室の学生が決めたルールに逆らうことは許されなかった(経営者的糖衣構文を使わずに言えば、実際に技術的に不可能)し、商業的に成功するプロジェクトとは「ルールの中で安価に実現可能なもの」と「顧客が欲しているもの」の共通部分のみを的確に選んで提供することができたプロジェクトだけだった。「技術が分かる経営者」とは、現時点の最新のルールを深く把握し、損益にどう出るかイメージを掴みながら商品企画を選べる経営者だった。
ただ僕も不思議だったのは、３[他部署を巻きこみプロジェクトを推進できる]にいるエンジニアですら「事業がわかる」エンジニアとしての評価を得られないケースがあると言うことです。ユーザーにいいものを届けたいし努力をしているつもりだけど、膨大な負荷がかかっているし経営層は何もわかってくれないということで、奥歯を噛み締めながらその場を乗り切っている方は少なくないのかな、と思います。
これはまさに「技術が収益性を決定するのは、本来はおかしなこと」という経営層の理解と、「現世で現実的に可能かどうかが最優先」というエンジニア間の乖離ではないだろうか? 経営層は顧客に価値を提供して対価を受け取りたいのであり、学術的な努力目標を数多く達成したいわけでは、本来はないのだ。だから他部署を巻き込んで膨大な負荷を受け止め新しい技術的知見を得ても、まったく意味がない。過去、技術的な制約を解除することには大きな意味があった。今はそうでもない。高い技術それそのものによる金銭的価値は少なくなったのだ。その結果、顧客が支払う金銭を最大化する製品設計の価値は上昇したし、そもそも元から低くはなかった。
そして、もちろん実行力も大事なのですが、彼らとの共通言語を持った上で会話ができる、具体的には採用方針を考えたりビジネスの状況を踏まえた塩梅での技術選定をしたり、さらには企業の将来像を共に議論するというある種の机上のフェーズですら、彼らは欲して止みません。それさえできれば多少の評価が得られるというのが、隠れた事実のように感じています（もちろん、それが良いとは言ってません）。視座が４にあるだけで相当な評価を得られるということですね。当然議論してるとしばらくしたら人事や社内管理、事業のブラッシュアップ、営業など、全ての方面で駆けずり回ることにはなるのですが。
となると、自らのキャリアに集中したい、技術力への危機感がいい意味で強いエンジニアであればあるほど例の三大美徳に殉じた方が技術者として成長するし、それで評価を獲得できる会社に転職するのが良い、となります。そして経営層からしてもそういうタイプの人だと同じレイヤーで議論をしてくれることへの期待値が高くないので、自然と「事業をわかって」くれないタイプだと見做して配置換えを行います。全てではないですが、こうした負の循環によって過剰にテックリードがいる組織が僕の頭にぼんやり浮かぶことがあります。
「優れたエンジニアは汎用的な問題解決能力が高く、その能力を是非とも経営でも生かしてほしい。あとは興味を持ってくれる人がいるかどうかだけなんだ…」という意見を経営層が漏らすパターンはこっち寄りです。そしてあくまで個人の嗜好性の問題なので、解決難易度が非常に高く、共通解も存在しません。１つ目の問題のように配置換えで多少解決できることではありません。
以上のような理由から、経営層はエンジニアにも「事業をわかって」欲しいと思いながら、その期待値を高く設定することができずにいるという印象を受けました。
まとめると、既存製品の改修にしろ新製品の企画にしろ、採用や企業内の人員配置にしろ、サプライヤや親会社との折衝にしろ、まず収益性をKPIに選び、検討項目を洗い出し、貪欲に裏付けを持って改善するエンジニアの能力を活かしてほしいという話だ。顧客からの売り上げを最大化する商品企画ができないエンジニアが多い、それが要点だろう。この文章にはエンジニアと経営者の言語が疎通しない理由が詰まっている。話の要点を短くまとめていない。要点をまとめないことを要求している。要点を省いている。だから技術的な制約と戦うエンジニアには通じないのだ。正直に「企業は顧客からの売り上げで成り立っている。だからできれば商品企画の段階でも収益性第一で企画進行が出来る奴が欲しい。そして社内外を問わずオジサンが求めているのは常に出会いだ。だから収益の話をグダグダ伸ばせること、酌ができることは必須だ」と言えばいいのだ。
記者会見（https://www.youtube.com/watch?v=ACFLlMXhlWg などでみられる）および、社内報の一部から得られた情報をもとにしている。
ここまでの説明を聞くと、論理的には、NASのハード障害時は手動で切り替えることで、システム全体再起動は不要で、売買停止の事態は招かれない、ということになる。そこまではいいが、ではなぜ今日それを実施しなかったのであろうか。この点は記者会見で2回ほど質問されていたと思うが、東証側は正面からは答えなかった。
JPXのウェッブサイトに公開された。https://www.jpx.co.jp/corporate/news/press-conference/index.html 経由で https://www.jpx.co.jp/corporate/news/press-conference/nlsgeu000004zjwb-att/20201001_J.pdf
大学時代にプログラミングをかじったら楽しくて、これを仕事にできたらいいなと考えて IT 業界を志望し、
でも Goole とか Amazon とかのイケてる企業に入る実力も到底なかったので、とりあえず大手の SIer に入った。
研修を終えて某大企業に常駐して働くことになったが、労働環境はひどいものだった。
IT ベンダが集まるベンダ部屋みたいなところにぎゅうぎゅうに押し込まれていた。
PC のディスプレイは当然 1 枚しかなく（プログラミングするには 2 枚ほしい）、メモリも足らず、
セキュリティの問題からネットには繋がらなかった。何か調べるときは自分の携帯を使う必要があった。
新卒でもいきなり下請け企業のメンバが下についたが、ペーペーの私から見ても信じられないくらい能力が低く、その人たちのフォローでも時間が取られた。
そうでなくてもプロジェクトは山火事のように燃え続けていたため、仕事量はあまりに多く、だいたい毎日終電まで働いていた。
実際の残業時間は当然のごとく毎月 120 時間をゆうに超えていたが、法律上申告できない部分はサービスとしていた。
ある時、客先のマネージャーに、「このタスクいつ終わるんだ？」と言われ、
私は「（無理して）2週間くらいです」と答えた。 1 週間でやれ、と言われた。
私に残された手段は、1 日で 2 日分働く以外になかった（当時はいい子だったので、バックレるなど考えられなかった）。
終電ではなく逆方向の"始発で帰る"ようになった。シャワーだけ浴びに家に帰って、1 時間くらい寝てすぐ出勤した。
それでも 1 週間ではタスクが終わらず、そいつからは罵声を浴びせられることとなった。
なぜこんな頑張っているのに怒鳴られなければいけないのかと、その日は帰りの終電に乗りながら世の中の理不尽さに泣いた。
数年経って、たまたま割と余裕のあるプロジェクトに移ったので、積もりに積もった会社への恨みを晴らすときだと思い、転職活動をはじめた。
（ハードすぎるときは転職活動をする余裕など到底ないのが皮肉なものである）
自身の技術力が磨けそうで、魅力的なプロダクトを作っていそうなスタートアップ企業を受けて、内定をもらった。
辞めると言ったときには偉い人たち含め、いろんな人から引き止められたが、聴く耳は持たなかった。
（皮肉なことに、上記の厳しい環境でも死ななかった経験からサイヤ人のように戦闘力が高くなっており、評価が高かったらしい）
スタートアップに転職し、前みたいなひどい労働環境はなくなった。
同僚も概して優秀だし、給料も残業がない分は下がったが、もともとそんな金は必要ないので問題はない。
しかし、今となっては SIer はそこまで悪くなかったかもしれない、と思ってしまう。
なぜかというと、今の会社のプロダクトがあまりにクソだと知ってしまったからだ。言ってしまえば "この世に必要のないもの" だった。
現在の弊社が掲げる誇大広告に騙され、入社して内情を知るまでは見抜けなかった。うかつだった。
この世に必要ないプロダクトを作るのは苦しい。自分が世の中に貢献しているという実感が持てないから。
ベンチャーなので営業にも行ったりもしなければならないのだが、その時に「うちの製品は素晴らしい」と思ってもない嘘をつかなければいけないのも苦しい。良心の呵責を感じる。
SIer にいた頃を思い返してみると、作っていたものは世の中に明らかに価値を生み出している大企業の、明らかに必要なシステムだった。
もちろん、SIer だって世の中に必要ないシステム（誰にも使われないシステムとか）を作っているケースもあるのを知っているが、概して数は多くないのではと思う。
今の会社も黒字化など到底無理そうなので、潰れる前に転職しようと思っているが、SIer に出戻るのも悪くないかなと思わないでもない。喉元過ぎれば熱さを的なやつ。
まぁ SIer よりも外資のイケてる企業に行けるならその方が良いし、誰かいきなり 10 億円くれたりしたらもっと良いのだけど。
勤め先で導入している基幹業務システムは国内大手ベンダ製で、質問や作業依頼は専用サポート窓口を通すことになっている。
サポートにメールを送るとすぐに確認の電話があり、迅速に対応してくれるから非常に助かる。
のだが、先輩氏や上司氏はサポートを通さず営業さんやSEさんを捕まえて対応させようとする。現場の人だっていきなり尋ねられても困るだろう… 突然じゃわからないこともあるし、対応する順番や優先度もあるし、今日の作業内容だってもう決まってるだろうし。
「人と対面して人に話をするほうが早い」という意識がどこかにあるのかな。あと言質がないと気が済まない的なやつとか。
今朝、某ブックマークサイトにて大手SIerにおけるクソ設計書について少しばかり話題が盛り上がった。
SIerのシステム開発方法や、所謂「炎上案件」というのは具体的にどういうことなのか、できる限り思い出して書いてみたいと思う。
所属したプロジェクトは3件で、1つ前に所属したプロジェクトはコロナ騒動の直前の2020年1月である。
これを読んでいる人の中には、私よりも玄人なSE、もしくはPMがいるかもしれない。
手持ちのサンプルが少ない故に「ちげーよ！」ということもあるかもしれないが、そこは大目に見ていただけると幸いだ。
まず、ITに携わるシステム屋とはいえ、SIerとベンチャーWeb系は規模と客層も違うし、開発手法も違うと思われる。
開発手法というのは、「ウォーターフォール（各工程を最初から着実に終わらせる手法）」、「アジャイル（短い機能追加を繰り返していく手法）」が一般的にも有名だと思う。
開発手法には「ウォーターフォール」のさらに上の「メテオフォール」というのがある。本気の炎上、アジャイルのようにウォーターフォールする開発という意味だ。
（何を言っているのかわからないかもしれないが、私も何を言ってるのかわからない。https://eiki.hatenablog.jp/entry/meteo_fall）
多重下請けに所属しているSEが「メテオフォール」をかけられたら、もう刃傷沙汰にでもならないと逃げられないと思っていい。
炎上案件のSIerの客層は、金融系・公共インフラ系がほとんどだ、7割そうだろう。（※適当）
自社開発系はさておき、受託Web系やパッケージベンダ系の客層は、小規模案件のプロジェクトもある程度あると思う。
金融・公共インフラ系はべらぼうに規模がデカい。馬鹿みたいな工数が掛かる。
【要件定義 ＋設計開発UT＋結合テスト＋システムテスト＋ユーザー受け入れテスト＋システム移行】 ＋追加要件開発（保守運用）。
大雑把に言うと、「ちょっと顧客情報DBを参照してWebに表示させるシステムが欲しい」として受注した場合、約4000万円がお会計となる。
現行システムのリプレイスだとしても、2000～3000万円はかかる。高い（※謎仕様の現行システムだと炎上不可避案件となりさらに膨れ上がる）
当然、数千万円案件となるとプロパーの社員では人手が足らなくなる。
すると登場するのが「派遣社員（SES）」あるいは「下請け」というシステムだ。
会社によって異なるが、だいたい4～9割が「派遣」や「下請け」の割合となっている。
それでも工数不足になってしまったプロジェクトは、そこから鬼出勤をカマす。
納期を過ぎたらさあ大変、開発経費・損害賠償がSIerの自腹になってしまう。
それで最初に書いた「ウォーターフォール」ってのは何なのか？ってことになる。
「ウォーターフォール」＝「各工程（要件定義、設計、テスト）で客の承認を得て合意を握った上で着実にマイルストーンを固めていく」
「何のために固めるのか？」＝「手戻りを起こさないため（白目）、責任を押し付けられないようにするために」
と、ここまで前置きを書いて疲れてしまったので、続く。
駄文失礼。
