  |
はてなキーワード: システム開発とは
ワクチン予約の一件で思い出した。箇条書きにする。
接種番号の形式は、遅くとも去年の12月には定められていて、その時点でこのシステムはつくられる予定さえなかった。
https://www.mhlw.go.jp/content/000714248.pdf
なので、それも無理よ。
なんなら、このシステム開発開始時点で、券面印刷終わって送付してたろうし。
やるなら、接種番号と、対応する仮パスワードを自治体に入力させて、別途送付するとかだけど、
かなりの工数と混乱を生むだろうね
おっとおっと言ってるのは「予約システムを作れ」の方じゃねえぜ？
「予約システムを作らせる」の方だ。
つまりは、「役所の書類としての、システム開発の仕様書（政府の思いつきにより超速攻で提出）」だからな？
出来るか？
「仕様書ｗｗｗだってよｗｗｗｗ」「帰ってママのおっぱいでも吸ってな」「マニュアル通りにやっていますというのはアホの言うことだ！」なーんてゲラゲラ笑いたいなら勝手にすりゃいいが、それを口にするならもうこの案件で何か言う権利は無くなるぜ？
それともなにかい？
「形にさえなりゃいいんだ」「仕様書なんて適当でいい」「意思決定なんて滅茶苦茶でいい」「会計監査だってコロナだったからで通っちまえばいいんだ」かい？
マジかい？
俺はそんなの嫌だぜ？
車検に出した車に対して「いい感じにしときましたんで、まあいい感じっすからこんな感じで料金くださいよ。マジいい感じに仕上がってるんで」と言われたらよぉ……俺はもうそんな会社は使わねえぜ？
国が税金でやってる仕事なんだから意思決定はクレバーじゃねえと。
そうなるとやっぱマトモな仕様書が必要になるわけだが、自民党だか厚生労働省だかが支持率低下回避のために適当に吹いた戯言の尻ぬぐいで速攻で仕様書作れって言われても俺なら無理だね。
「そもそも何を作らせたいんですか」って聞いちまうよ。
どうせ上の奴らは「いい感じにだよ。馬鹿かテメーは」って頭の悪いヤクザみたいなこと言うんだろうよ。
そんな中でとにかく納期に間に合わせるために作ったら、そりゃクソみたいなもんを提出することになるだろうよ。
そしてそれを見て作らされた会社も当然のように「え？無理？もうゴミ出すわ」ってゴミ出してきて、それ受け取る側も「もういいわ知らん」でゴミを通すんだろうな。
でもそれを攻めるのは俺には出来ねえわ。
新型コロナワクチン接種もさ、政府が優先順位と余った時の優先順位をちゃんと示せばいいのに現場任せ。
でもやらない理由もわかる。野党とかの重箱の隅つつく奴らのせい。「○○の時はどうするんですか？」って奴。
システム開発とかでもよくある。疑問として提示するのはとても良いし、専門分野からの指摘は時に大きな不具合を発見する手立てにもなる。でも、そんなのはほんの一握り。
大半は気にしなくてもいいレベルの些細な内容を指摘してご満悦した上で、それがハッキリしないと決して先に進ませないようにする。大概無能クズ。でも決済権とか持ってるバブルの粗大ごみ。
まずは医療従事者、次に老人、余ったら公務員、それでも余ったら老人以外。優先すべきは公平性よりワクチンの期限。
ほんと数％レベルのイレギュラーとか現状気にしても仕方ないでしょ。それこそワクチンの副反応で死ぬ確率気にするレベル。だから与党の支持率が下がっても野党の支持率も上がらないし、ゆたぽんの父親が税金無駄使いしようとするんだよ。これじゃ誰も選挙行かないよね。
https://anond.hatelabo.jp/20210517201151
あれさ、少なくとも東京会場側のサイトは、最初のボタンに「認証」って書いてあんだよね。
んで、取れる手立てはいくつもあると思うんだけどさ、
最初に書いとくと、できるチェックはしてるんだよ。
例えば、「現在の入力桁数：4桁」みたいなチェックはしてんだよ。これはわかりやすい。頑張ってる。
んでな、2月31日みたいな存在しない日付についてはエラーになってる。
「入力された内容に誤りがあります。入力内容をご確認下さい。」ってちゃんとわかりやすくでるんだよ。
でも、令和2年生まれとかが予約画面に進めるんだよね。そこは誕生年で弾けって。
まあ、割と無理やりな感じでライセンス表記もさせてるからさ、たぶんこれ、コード書いてるの1人とか2人とかじゃねえの？
https://www.vaccine.mrso.jp/js/app.js.LICENSE.txt
何が言いたいかって言うとさ、これって、納期がクソなシステム開発のあるあるじゃね？
ドメインどうするとかさ、仕様に至る前の段階の話じゃん。何の調整もされてないんじゃないのこれ。
年月日で、65歳未満が予約する際にはエラーを出して弾くようにするとかさ、こんなん何人かのチームでやってりゃ間違いなく誰か指摘するだろ。
「これって、65歳以上の方が対象ですよね？最初の登録時に弾いたほうが良くないですか？」みたいなさ。
「これ、XXXXな理由で接種券番号の仕様がもらえないのはわかりましたけど、市区町村コードは既知ですよね？」とかさ。
つまり、「ああもう何言っても無駄だわ余計なこと言うとこれは俺の責任にされて俺の会社の仕事になるわ言われたことだけやるわ」って状態じゃん。
市区町村コードのPDFだってさ、珍しくもこれちゃんとコピペできるPDFじゃん。そのチェックもしてないんだぜ。
https://www.soumu.go.jp/main_content/000730855.pdf
（つまり、桁数が分かるようにせよとか、桁数があってるかのチェックをせよ、みたいなのは仕様に書いてあったか言われたんじゃねーの）
（そして、市区町村コードから、市区町村を引いて画面に表示せよ、とは仕様に書いてなかった）
どう考えても調整をする人間がまともに調整して、まともな権限持ってる人間が仕様を詰める時間で2日もあって、プロトタイプ作ってレビューして確認して、テストしてで、仕様が固まってて一ヶ月もあったら絶対できるやつじゃん。もっと短納期でも仕様が固まってりゃできるやつ居るだろ絶対。
（イキったTwitterなら（仕様が固まってりゃ）半日あったら実装できて、3日もあったら試験も終わる、とかいうやつ見つかるぜこれ）
つまり、できてないのは「仕様を確認して、まともな仕様を練る」時間がないから。
あとこれ、全スルーしてるから当日落ちなかったんじゃないんだよね。
めんどいから詳細言わないけど、「キャンセルできるようには作ってある」んだよね。ちゃんと登録はしてるし、登録情報とのチェックはしてる。キャパのチェックもしてるし。（既報の情報をちょっと変えると誰でも確認できる）
個人的には、たぶん1人がコーディング、1人がデザイン、1人がインフラ兼QAって3人位のチームで3日くらいでゴリゴリ作ったんだと思うけどな。
この仕様のグダグダっぷり（ドメイン名とかを見ると明らかに関係者間で整理、調整がなされていない）みるに、きっちり落ちずにスケールもしくはピーク負荷読みきったのは天晴なんじゃねえのかな。訴えられない範囲内での仕事はきちんとしているという意味で。
またあっちこっちでテキトーな事言う広報通してない発言がしばらく出るんじゃねえの。
もうあれだと思うな。
建築基準法みたいな法律作って縛るのが早いと思うわ。そういう法律あるとその法律には従って発注するから。
（なお、ブコメにもよくいるけど役所との契約は全国から募らずに、割と地元に金を落とすかどうかって観点がポイントになったりするから、今から似たよーなシステムを土日に作って壊してして慣れといて地方の契約握ってそうなIT屋にあたりつけとくと、またぞろ色んな理由でパンピー向けの予約システムがそこここで発注かかるから、リモートで曾々々孫受けとかでお仕事が受注できる可能性が微レ存）
SIerは年功序列だよ。中の人になって長いので、その理由について書いておく。
SIerは、成果を評価するための「見る目」を持っておらず、持つ理由もないから。
おっと「お前の居酒屋でのくだ巻きなんか聞きたくねーんだよ」と言われないように、少し背景を書いておく。
SIerはざっくりいうと、IT技術について、色んな会社からアウトソーシング業務を請ける会社だ。流石にそれは理解しているよね。
では、例えばこの2人のどちらの評価を高くすべきだと思う?
「前者」がいい？単にプロジェクト管理担当がうまくやっただけじゃない？
異種格闘技戦のように、せめて直接対決すれば評価もできようが、直接評価する機会は基本的にない。
これはプロジェクトの中のメンバー評価でも、ここまで極端ではないが同じようなことが言える。
DBスペシャリストとWEBアプリプログラマーのどちらをどう評価する？という話が出てくる。
「WEBベンチャーとかはなんでスター技術者に高給を払うの？」という疑問があるかもしれない。
となる。「人への投資＝売り物への投資」になるケースが生じうるわけだ。
雑に言うと、
技術力不足でしょぼいアプリを作ってしまい、会社がまるっと倒産するぐらいなら、
技術力が優れた年収1千万の人間数人雇うぐらい安い、というケースも有りうるということ。
一方で、SIerは、
という「人売り」ビジネスだ。
大規模な受託案件も、詰まるところは「人売り」の比率が大きい。
商材としてみた人間は、大して投資せずとも莫大な売上を立てることができ、際立って優秀だ。
人の「売り買い」であれば、かなり安定して利益が出る。
だから、ビジネスとなったら、手堅く稼ぎの大きい「人売り」がSIerの実態なのである。
(「人売り」がチートすぎて、まともな製品開発が割に合わなさすぎる、というのが日本のIT業界の課題、と見ることも出来る)
一部のWEBベンチャーが技術力にカネを払うようになったということ自体、新しい流れだと思ったほうが良い。
他業種を含めて、技術力を評価してお金を払うことは、日本では当たり前のことではなかった。
不動産営業や保険営業だとの世界では、売上成績トップクラスになると、若くとも超高額の収入を得ているケースが散見される。
一方、SIerはどうかというと、「人を売る」商売であるだけでなく、よりチームワークが求められる。
営業一人でもプロマネ一人でもエース技術者一人でも売上は立たない。
そのため、ある程度一人ひとりのメンバーを評価し、報酬の分配を行う必要がある。
さて、年功序列の良いところは、給料を抑えられるというところにある。
一定の期間忠誠心を示し、かつそこそこ以上の成果を残した社員に対して、昇格で報いることがポイント（金銭ではなく）。
これにより、長く所属するほど得、となるので、短期的な金銭報酬を我慢させることが可能になる。
実際には、世代ごとに社員が分断されているため、40代以降になった後、
稼げなくなったタイミングでリストラを行うことで、先延ばしした支払いまで含めて抑制することが出来る。
「若手が優秀」であれば、なおのこと年功序列で給与総額を抑え込みにかかるのが、企業としては合理的な選択なのである。
情報工学の院卒のキャリアでSIerに来てしまったとして、この現状にどうお付き合いすべきか。
悩ましいのは、このひとのレベル。見たところ、学歴はあるとしてもそこまで技術力があるように読み取れないんだよね。。。
ひとまとまりのアプリやシステムを自分で作れるレベルなら会社出ろと言えるんだけど、新人研修の課題をあっさり解けるという程度のレベルだと、早い人には1〜2年位で実力的に追いつかれちゃう、という現実があるよ。
大企業の新人は、飲み込みが早いので、あまり舐めないほうが良いです。
という考えで行くかな。転職するかどうかは、その後考える。
そういう人は完全にSI向いてると思うんだけど、システムがわからない人が要件定義した結果糞システムができあがるのが日本のシステム開発の問題なので、プログラミング自体は細かいスキルなのでどうでもよいけど、サーバーとかネットワークとかクラウドとかシステム関連の技術に全く興味を持てないのであれば、せっかく優秀な頭脳を日本のために活かすという観点ではやめておいて欲しいかなと思う
自分の一社目がまさにそんな会社だったのでガチのアドバイスを。
もう 20 年以上前になるが本当に状況が似ていて、メーカー系のグループ会社、2000 人規模の SIer、親会社の仕事ばかり、新卒は 100 人超、コーディングはしない、ビジネスマナーから始まる超絶ホワイトな研修が半年、などなど。
ちなみに言い当てると、月収が 22 万程度で、6月には寸志が 10 万ほど出る。年功序列で毎年少しずつ給与が上がるが、40 歳で課長、50 歳で部長になっても夢のある金額にはならない。そもそも上には謎の名ばかり役職がもりもりあって、部下無し管理職すらいる、そんな感じじゃない？
自分の場合その会社に就職したのは安定感を求めて、ではなく「この業界にいてどこの仕事が一番自分に合っているかを俯瞰して見たいから」だった。ネットで調べたりまあ卒業生に話を聞いたりとかしたところで、学生身分では絶対に見えない部分があるという確信があったので、一社目は言わば仮面浪人気分で、二社目で本気の就職をするつもりでそもそも入った。それを目的とすると、大手 (あるいは中堅) SIer というのはとても良い立場で、うっかり壮絶ブラックな職場を引く事も無く、ちっちゃなベンチャーで井の中の蛙になる事も無く、業界全体を俯瞰し、どこにどんな仕事があるか、何を避けるべきか、その中で自分がやりたい事は何か、自分がやりたい仕事はどこにあるか、などを見ることが出来る。
結局二年半ほどその会社には勤めて、大手の何が駄目か、何が良いかを学び、駄目なところを一応変えようとしてみたりもして (*)、その後、Web 系の自社サービスをやっている小さなベンチャー企業にプログラマとして転職をした。この初めての転職の時点では「何を避けるべきか」「何を優先すべきか」などが二年半の経験で明確になっていたので、面接時にそれらをちゃんと質問する事が出来た。また「面接官のずるいムーブ」も的確に見抜いて、会社から選ばれると同時に会社を選ぶ立場で面接に臨みとても良い会社を引くことが出来た。
本気の就職をした二社目では、今も交流が続き師と仰ぐ素晴らしい上司に恵まれて、システム開発をイロハから学ぶことが出来たし、五社目になった今でも時に一社目の経験が ── 避けるべき事例としてではあるものの ── 役に立っているので、遠回りでは無くあれは必要な二年半だったと自信を持って言える。
ただ技術的な知識を学び力を付けるという意味においては、一社目は全く役に立たなかったと言って良い。その点については自分自身で担保する必要があるけれど「安定感は会社に与えられるものではないです。自身の技術力が担保するものです。」と言い切る増田にあれこれ言うのは野暮だろう。
以上を踏まえて、合計 5 社、足かけ 21 年 IT 業界で働き続け、転職・スキルアップを契機にやれる事や給与を増やし、今なお現役のプログラマとして外資系 IT 企業で日々コードを書いている自分としては、1 ヶ月で判断して転職してしまうのは勿体ないよ、と言うアドバイスを送りたい。今の立場を最大限に生かして業界の知識を蓄え数年後の転職につなげるのは、増田の人生にとって大きなプラスになりうるはずだ。
(*) 日替わりで誰かしゃべる部全体向けの朝礼で、根回しなどもちろん無く、今の会社の仕組みの何が駄目か、どうしたら良くなるかを提案したところ、後で直属の課長から呼び出され「お前、部長から呼び出されるところだったぞ。おれが代わりに謝っておいたやったからな。」などと謎の恩を売られ色々と察した思い出。
本稿では弱者男性論をシステム開発のメタファーで捉えることで凝り固まった見方をほぐす事を目的とする。（特にはてなにはシステム開発に親しみ深い人も多い筈だ）
特にそれが「解決策なしの問題化」であることをまずは示したい。
弱者男性論に対する反応を見ていると、弱者の訴えや社会的な問題化と、解決策の提示がセットだと思っている様な反応に出くわすことが多い。
「つまりあてがえ論でしょ？」と言う早とちりが頻出するのもこのせいだろう。「結局何が欲しいの？」「どうしたら救われるの？」と言った反応もよく見られた。
酷いものだと「弱者男性の問題は解決できない、だから問題ではないのだ」と言わんばかりのコメントも見られた。
例えば以下のブコメ欄でも、（比較的穏当なものもあるものの）一足飛びに解決の困難さに言及し「無理だ」「意味が無い」と早々に結論付けてしまう様なコメントが多い。（増田は解決策に言及していないにも拘らず、だ）
https://b.hatena.ne.jp/entry/s/anond.hatelabo.jp/20210408101204
しかしよく考えてみて欲しい、システム開発を行う際、例えばバグ票を起票する時に「解決策」を書くだろうか？それは必須だろうか？
そう、システム開発のメタファーで考えた途端、この問題に対する視界は目薬を差したようにクリアになる。
そもそも「解決策」は必須ではないのだ。まずはバグを報告する事、問題を問題化する事、必要なのはそれである。
弱者男性にまつわる問題が実存的だとか解決困難だとか、まずは考えなくていい、まずは問題化する事、解決策に頭をひねるのはその後である。
急いで解決策を出そうとするから「あてがえ論」なんて奇論が出てくる、そんな事をする位なら、解決策はまず考えずに問題化だけしておけばいい。
解決策が無い事は、問題が無い事を意味する訳では無いのだから。
しかし「問題と解決策はセット」と人々が捉えたがる事には理由がある。単純に不快なのだ。
解決策の見つからない問題、というのは世の中当たり前にいくらでも存在するが、そうした問題を意識し続けるのは不快だ。
システム開発においてタスクやバグ等の起票はそのような不快さを問題解決のモチベーションへと変換する方法論でもある訳だが、当然それは社会問題にも応用できる。
そしてそうした社会問題に対する反応も、弱者男性問題に限った話では無い。
最近では車いす利用者の乗車拒否問題で顕著だが、問題を提起した人には解決策の提示を求める声やそのジャッジが押し寄せる事に成る。
仮にもし、件の問題に対してJR側に取れる有効な解決策が無かったとしても、それは問題が無い事を意味するだろうか？
当然NOである。解決策が見つからくても問題は存在するし、その解決策を考えるのは問題提起側だけの義務ではない。社会全体で考えるべき事だ。
社会問題を目のまえに吊るされるのは不快だろう、解決策が見当たらないなら猶更だ、けれどもそれは必要な不快さであり、性急に解決策を求めて「無理だ」と結論付けるべきではない。
「しかしそうは言っても、女性差別等の差別の方が問題だし、リソースは有限だ、解決策の見当たらない問題は無視するしかない」と思う人も居ると思う。
そういう人には、弱者男性問題は今から未来に求められる事になるアップデート、だと考えて見る事をおすすめする。
例えばフェミニズムはこれを女性差別や偏見を解決した3.10まで持っていこうとしている。
そして3.10から更に弱者男性の問題も（今はまだ誰も思いついていない方法で）解決した4.15があると考えて見る。
フェミニズムのやりたい事は2.10→3.10のアップデートだ。
そしてその延長線上には3.10→4.15のアップデートがある。
どうせいつか求められる事に成るアップデートなのだ。（時が進めば3.10も「古臭い価値観」に成ってしまう）
「2.10→4.15のアップデートは飛ばしすぎだ、リソースが足りない」という意見は分かる部分も有る。しかしだからこそ、来たる3.10→4.15のアップデートに備えて、「弱者男性問題」というバグ票を起票だけしておくのはどうだろうか？
3.10→4.15のアップデートはまだ未来の話かも知れない、しかしその問題を今から捉えておく事は出来るし、早めに起票しておく事にリスクは無い筈だ。
今はまだ弱者男性の問題を解決したり、彼らを救う有効な方法は無いかもしれない、
要はよく言う「年度末だから予算使い切らなきゃ！ 次年度予算が少なくなる！」が公会計は強烈なんや。各部署がそれなので「システム開発が必要で期間が2年かかります。耐用年数は5年でその利用を見込んでるので、支払のため再来年度は予算を増額で～」というと民間企業なら「実質5年分だね」として分割して費用を計上するので払う現金があれば通る(複式簿記。発生主義。減価償却)が、公会計だと「再来年に計上だね」(単式簿記。現金主義)となり、利用部署のその年度の予算増額が必要になる。ただ歳入は基本的に限られてる(税金)し、赤字にできない(いわゆる赤字国債は発行する際の条件があって、システム開発は含まれない)各部署の予算使い切りもあるので通りづらいんや。トップダウン(知事なり内閣)があればまた変わるけどな。
オナホとITを融合させ、各男どもの棒にフィットしたオナホの開発を目指している。
あまり詳しくはいえんが、AIを使って、それぞれの棒をもっとも気持ちよく逝かせる構造をつくる、
そんなオーダーメイドのオナホ設計のシステム開発を行っている。
このような研究を行おうと思った動機は、まず既存のオナホが自分にとって心地よくなかったというのがある。
俺は、人類が滅びれば地球環境が良くなり動植物は幸せになれると考えている。
これと同じように、男がダッチワイフでしか逝けなくなり女のなかで射精できなくなれば子どもはできなくなる。
そもそも寿司屋に必要な技術が、魚切って酢飯と一緒に握るだけだと想定してる時点でバカ丸出し
この程度の業務分析レベルじゃ、さぞIT企業時代もロクなシステム開発ができなかったでしょうね
客が目の前で見る職人の仕事って、寿司屋の業務全体で10%もない
単純に寿司という商品を製造する工程だけみても、良いネタを仕入れる目利きの技術やコネクションが必要だろ
有名なすきやばし次郎は、ネタの仕入れに糸目をつけないため、魚の卸業者が良いネタを仕入れたら、真っ先に次郎に営業連絡がくるという
まず良いネタを仕入れることが美味い寿司を作る第一歩だが、そんなのYoutubeで学べるわけないだろ
もうこの時点で、ホリエモンの理屈が如何に浅くてナンセンスかわかる
更に実際の寿司屋には、一般的な店舗経営のノウハウや、客へのプレゼンの仕方、独立した時の潜在顧客を獲得するチャンス、
本や、Youtube動画では学びきれないほどのネタが詰まっていて、これを全て吸収するには1年、2年で収まらないであろうことは想像に難くない
更に更に、そもそも半年ぐらいで寿司屋を開業することが可能だったとして、それが本当に経営する側として幸せなのかという問題もあろう
誰でも簡単に開業できるということは、市場競争が激化するということでもある
半年で開店して、1年で閉店するより、10年店舗で働いて開業、年老いるまで緩い競争の中でのんびり営業できる方が幸せだろう
職場で沸き起こった疑問。採用や昇進・昇給などで、優秀な人を上から順に選ぶことは差別だろうか？
何が起きたか背景。システム開発系の職場で、業界構造的にほとんどが男性エンジニアである。
給与査定では当然それまでの成果や今後の期待を込めて査定するわけだが、
ほとんどが男性の職場ということもあってこれは確率的に普通に起こり得ることだと思うが、
査定に関わるとある女性社員が「これは女性差別ではありませんか？」と声を上げた。
もちろんそんなつもりは無いので「そういう意図はありません」としたものの、どうしても不服なようで、
他のメンバーが渋々承諾し、昇給額が少なかった女性メンバーの昇給額を上げようという話になった。
「女性だからといって優遇していませんか？男性社員は男性というだけで昇給しにくくなるのですか？」と批判した。
その後様々な意見があったが、結局、全員同一の微々たる額を昇給ということになった。
華々しい成果を上げた男性社員も、ほとんど成果を出していない女性社員も同じ金額だけ昇給。
そこで疑問。優秀な人を上から順に昇給させることは差別につながるのですか？
昇給だけではなく、採用や昇進についても同様の問題が出始めています。
https://xtech.nikkei.com/atcl/nxt/column/18/00001/05203/
COCOAやHER-SYSの開発において、日本マイクロソフトは厚労省との契約主体ではない。しかし厚労省がHER-SYSの開発ベンダーを急ぎ探していた2020年4月、ベンダーの選考会に参加して営業活動を展開していたのは実は同社だった。パーソルP＆TやFIXER、エムティーアイは、いずれも日本マイクロソフトのクラウドサービス「Azure」の有力な開発パートナーでもある。各社は厚労省の選考に勝ち残った「日本マイクロソフトの呼びかけでプロジェクトに参加した」（パーソルP＆TのDXソリューション統括部の責任者）。
いわゆる「マイクロソフト村」だ。ときどき見かける組み合わせ（異同はある）。
契約段階でパーソルP＆Tが元請けとなった理由は、関係者によれば「製品の提供に徹してシステム開発案件の契約は開発パートナーに任せる」という、日本マイクロソフトの方針によるものだった。
この座組みもよく見る。Microsoftのソフト製品をバンドルしたりAzureを売ったりしている大手日系メーカーやSIerとガチンコ競合にならないための建前的なやつ？
接触確認アプリの基盤を世界的に提供していた米Apple（アップル）と米Google（グーグル）が、接触確認アプリの提供元は各国の公衆衛生当局に限るという「1国1アプリ」と打ち出したからだ。厚労省はそれまで「接触確認アプリ導入に冷ややかだった」（関係者）が、アップルとグーグルの鶴の一声で「公衆衛生当局」として調達を担当することになったのだ。前述の通り、ここで厚労省は接触確認アプリの開発先の調達をパーソルP＆Tに「一任した」。
ここでHER-SYSと抱き合わせでやらせちゃえって判断した厚労省の誰かが、ある意味で最も無能で罪深いと思う。
たしかに接触確認アプリのサーバーはHER-SYS側のデータを定期でもらう必要はあるけど、逆に言えばそこだけっていうか。接触確認アプリの実装において肝になりさらに難航が予想されるポイントは、HER-SYSとは全く性質が異なるじゃん。AppleとGoogleの突貫協議で開発されたOS組み込みのAPIを正しく取り扱うこと、テストしにくいアーキテクチャが不可避な中でなるべく多くの国民が利用できるように多機種に対応し動作確認すること、そういう感じじゃないの。しらんけど。
なんでHER-SYSのおまけで賄えると思ったんだか。やるならやるで別の予算調達してベンダー選定しなよ。
時間がなかったから仕方ない？長くても半年もいらなかったと思うけど。Androidで通知ができてなかった去年の9月から今月までで半年だ。
さらに接触確認アプリの十分な知見がなかったパーソルP＆Tは日本マイクロソフトにCOCOAの調達やプロジェクト管理を任せる形を取った。「丸投げ」が連鎖したわけだ。注意が必要なのは日本マイクロソフトは接触アプリを公正に選べる立場になかった点だ。COVID-19 Radarには同社社員もおり、その接触確認アプリはサーバーの稼働環境にAzureを使い、AndroidとiOSで共通に稼働するコードを開発するツールには同社の「Xamarin」を使っているなど関係が深かった。厚労省は当時、こうしたベンダー側の事情も知る立場にあったとみられる。
知ってたっしょ〜。知らないわけないよ、絶対知ってたよ。（証拠はない）
「なんでもいいからクラウドもってこい」ならぬ「なんでもいいから接触確認アプリもってこい」って態度だったんでしょう。（証拠はない）
日本Microsoftも厚労省もだんまり決め込んでるみたいだけどね。
日本マイクロソフトと厚労省に対して、COCOAの開発先を選んだ当時の経緯について2020年9月から複数回取材を申し込んできた。これに対して日本マイクロソフトは取材に応じず、厚労省は当時の経緯の説明を避けている。
業界を代表する媒体の取材を何度も断るとあらば、今後数年は真相は明らかにならないかもしれない。
やれやれ。
匿名で自分のログを世の中に浮遊させ、そして拾って頂けるのは楽しかったです。
長く続けるとバカなので何処かで絶対にボロが出る。なのに書きたくなってしまった。
再投稿です。きちんと上がらなかったように見えたので、消してしまって、もうええかと思ってしまったのだけど、
見たかったというコメントを見て、少し修正して上げることにしました。こんな駄文にありがとう。
https://anond.hatelabo.jp/20210130001953
https://anond.hatelabo.jp/20210131035752
これらの続きです。
====
前回のエントリでずっと4GBのメモリとともに作業していたと書いたが4GB以下が正しい。
最初の現場は128MBだった。あと、盾を鉾と書いていた。この誤字脱字と誤用の多さで私のプログラマとしての質の低さもなんとなく察して頂けるだろう。
◯結婚した話◯
何故か結婚の話が書かれていないという書き込みが幾つかあったので結婚の話から。
30歳を越えてから趣味が充実していた事もあって周囲には煩く言われるものの、結婚を考える事はあまりなかったし、結婚の分岐に入ることが必ずしも幸福につながる選択肢とは限らないと考えていた。
この考えは今も変わらないが私は運良く幸福につながるほうへ入ったようだ。すまんな。
何せ30歳を越えてからは同じ趣味のおっさんの友人たちと焼き鳥屋であーだこーだいいながら企画を練り、イベントを立てたりするのが楽しくて仕方がなかった。
20代があまりにも労働をしすぎた。22歳から28歳までの6年間、年俸制なので一円も残業代が出ないのに月300時間勤務を2年半はやったと思う。最初のうちはISDN接続のテレホタイムでのネトゲが自分のゴールデンタイムであり、息抜きの時間だった。
時代が今なら渋谷凛か風野灯織に貢いでいたことだろう。長い労働時間は人生の搾取だ。
嫁は異業種の人で、友人のボカロPのファンだった。彼のライブに通ううちに顔なじみになり、少しだけ会話をするようになった。
ある時行ったライブが月曜夜の開催ということもあって若い人が多く、ライブハウスの中でスーツを着た客が私と嫁しか居なかったので思い切って「今日はスーツ、我々だけですね」と話しかけ、そこから色々な話をしたのを覚えている。いやらしい。
ボカロPのライブでの出会い、つまり私が結婚出来たのは初音ミクさんのおかげだ。
30歳になったあたりからようやくIT業界に過残業を何とかしようという機運がやってきた事、そして定時で上がる精神的な胆力がついた事で音楽を作る時間的精神的な余裕が出来、人との交流が生まれ、ライブに行く機会が出来たから私のような人間でも結婚出来たのかもしれない。しらんけど。
国勢調査によると35歳を過ぎてから結婚した男性は約3%らしい。私は一生分の運をこれで使った。（正しくは6.8%だと何処かの教授が言っていたが）
自分が居た現場の雑感だと、同じシステム開発現場でも大手SI や 大手SI子会社のほうが結婚している人が多かったように思う。多重派遣はやはり収入面で結婚に対してネガティブな意見を聞くことも少なくは無かった。
若い頃は親にも親戚にも「そろそろ結婚も考えないといけないだろうから派遣社員辞めないとね」と言われたことを思い出した。SESの増田は一度は言われたことがあるだろう。
世間一般的には技術職というイメージよりも派遣社員というメージが強く、収入面も相まって世の中の反応厳しい。
普通の一般派遣と請負の派遣の人が混在している現場が多いと思うが、前者は1人でも派遣が出来、上位会社の現場のリーダーが直接指示をすることが出来るので最近はその方が多いように思う。
ところが、一般の派遣会社として登録するには資本金が多くないとダメで、派遣法が改正されたあたりで資本金が少ない会社は請負の道を選ぶしかない。
そうすると複数人で現場に行き、自社のリーダーに仕事の指示をされる形になる。ただ、コレは守られていない現場が多い。
さらに、大手や大手子会社と取引を直接行うのにも資本金の大きさ・設立してから何年等の条件があったりもする。
資本が少ない会社は資本金の多い「別な会社を迂回して」契約する。そこに多重派遣ができる仕組みの1つがある。上位請負の営業が◯◯社経由しろという場合、利権・癒着の場合もあるのだろう。
新人の時、パワハラの教育担当に私が毎日何度も怒鳴られているのが流石にプロジェクト内で目に余るようになったらしく、私はドキュメント整理という新たな仕事を貰う事になる。
炎上プロジェクトの為、全く作られて無かったクラス図をソース等からRational Roseで自動生成し、体裁を整えて他の設計書も含め印刷をした。同じものを2部作るのだが、何故か同一性保持という理由で一部はコピーで制作。分厚いバインダーに綴じた。
印刷とコピーで休憩もせず毎日終電の生活をしていた時、PMに「広島の二番バッターみたいだなおまえ」と言われたのを覚えている。コツコツやるけど面白みがない人間だと言われたのだ。
要領の悪い私に休憩のタイミングなんて解らなかった。ましてやパワハラマンに使えないと毎日散々どやされ続けた後なので尚更である。
その経験から私は同じプロジェクトに居る若手に「そろそろ1回休んだら？」「いつまで働いているの？増田がそろそろ帰れって言ったって言ってもいいよ」となるべく声をかけるようにしていた。モテそう（モテなかった）
この時、たまたま席が空いているという理由で隣に座っていた方が、のちに難易度が高い事で有名な銀行統合の現場の某SIのトップになっていた。プロジェクトの雰囲気は良くなかったが、いつもにこやかで私のような末端にも優しかったのを覚えている。出来る人は余裕がある。
印刷業務が終わった後、入社してからずっとテストだけをやらされていた1年上の先輩のアベさんと、とうとうプログラムの修行に出してもらえる事になった。
新規開発のプロジェクトである。プログラムも一杯書けてラッキーなのではと思っていたのだが、自社の人間はアベさんと私だけで、あとは上位会社のPMと、更なる下請けで構成されていた。
現場のリーダーも下請けの人で、この人が私とアベさんの教育係という事になった。
自社の営業が初日に来て「この子達よろしくね」とリーダーに伝えた所、「任せてください！」と良い返事をしていたが、自社営業が居なくなった翌日から面白いくらい態度が一変することになる。
何を聞いても露骨な悪態をつき教えてくれず、技術的な質問も一切受け付けない。
流石にアベさんと自社の営業に伝えたのだが、翌日朝私のところにやってきて「チクったな」「自社の人間でも無いお前らに教える余裕はない」と言われてしまうだけで特に事態の改善はされなかった。パワハラ上司の次はこれだ。駅のホームドアは大事なので全駅に付けて欲しい。
救われたのはインターネットが使える現場だった事だ。とはいえ、なんせソースレビューも私とアベさんで互に行うので、技術的な進歩がまるで無い。
ある時、私が書いたプログラムがメモリを使いすぎてフリーズするようになり、問題になってしまった。他にも技術的に問題のあるプログラムを書いてしまった事が続いたのと、リーダーに対してハッキリとモノを言うことも災いし、PMの判断で半年でプロジェクトを出ることになってしまった。
もっとうまく立ち回る事も出来たように思う。しかし、若造は人生の経験値が足りなかった。
多重派遣の大きな問題として、現場ガチャにより環境が大きく変わるというのがあるだろう。2~3年も我慢すれば大抵の場合次の現場に行けるのかもしれないが、短い人生の2～3年は少ない数字ではない。
請負ではなく一般派遣扱いで来る技術者の中には新人なのに１人で派遣されてくる人も多い。そんなのは新人教育とは言えないと思うのだが、どこの会社の募集要項にも新人教育はバッチリと書いてある。
その「新人教育」とやらの実態というのは大抵の場合、外部で行われる初心者研修と、自社の営業が「この子よろしくね」と現場に伝える程度の事でしかない。
社会人としての新生活での不安、技術的な不安、誰が教えてくれるのかも解らない不安、定時になっても誰も帰らない・帰って良いとも言われない、作ったものの品質の不安、数多くの不安を抱えて過ごさなければならない。ちゃんと相談出来る人も現場に居ないのである。
技術的な所は勿論、精神的なケアも必要な時期だと思うのだが、このような体験を20代前半でしないといけないのはどうも無駄な苦労をしているようにしか私には思えない。
ただ、新人が伸びる為に必要なのは「経験者によるソースレビューによる指摘」が必要不可欠だと私は思う。レビューを先輩・上司が行い、新人が書いたコードの信頼性の担保が出来ないと、余計なバグを生み、可読性・メンテナンス性も落ちるだろう。
なによりバグを出してリーダー・PM・顧客に「こいつ大丈夫か？」と思われるストレスの大きさと自信喪失感は長く忘れられない。
余談だが、最初の教育担当のパワハラ先輩とはその後別な現場で一緒になった。しかも彼は会社の倒産後、上位請の会社に転職していたので私に仕事を振る立場として現れたのだ。全く知らなかったので顔を見た時は「ヤバい現場に来た」と焦ったのだが、「あの時は俺の頭がどうかしていた。申し訳ない」とまず謝られてしまった。驚くほど柔和な性格になっていて棘が全て抜け落ちていた。その後一緒のプロジェクトの間はたまに昼飯を一緒に行くまでになった。
約1年一緒に働いたが一度もドヤられる事は無かった。許せるか許せないかは別として、パワハラをするほうにも何かしらの事情や背景があるのだなと一つ学んだ。
社会人1年目の忘年会はゲイのショーパブの観劇だった。そこでアベさんはダウンタウン浜田の高校（全寮制男子校）の同級生というママに唇を「むちゅーーー！！」と音が聞こえるような熱烈な口づけをされ、人生のファーストキスを奪われていた。私は隣でただ震えるしかなかった。
知人もなく上京してきた為、他の社員と交流する帰社日をそこそこ楽しみにしていた私は怒りのあまり社内報に若気の至りで”ボロクソ”に書いた所、社長の目にとまり、翌年から忘年会の幹事を任されることになってしまった。なにせショーパブの観劇は社長の要望だったのだ。
そして、普通の居酒屋で特に弾まない会話をして終了をする忘年会を2年繰り返した。
自社の忘年会を面倒に思うベテラン社員は多く、各現場に電話で来てくださいねと念を押して来て貰ったのに参加者が全然楽しそうではないのだ。
普段それぞれが別の現場に居る人なのでそれほど同僚感も無く、特に仲も良い訳でもないので会話が弾まないためだ。良かれと思って2時間半飲み放題にしたが、本当に盛り上がらない。
「なるほど、これで会話をしなくて良いイベント（且つ社長の趣味）がブッキングされたのか・・・」と理解した。
その経験があり、”自社”に缶ビール等の各種アルコール・ノンアルコール飲料とテイクアウトの料理を用意し、16時開始、17時から随時帰りたい人は帰る。という方式に変えた所、立食（椅子も勿論ある）で仲の良い人の所に居て彼らとだけ話すことも出来るし、色々な人と交流することも可能になった。時間が短いために会話のネタに困ら無い事も功を奏し、思った以上に盛り上がる事が出来た。
子供が出来た今ようやく思うに至ったが、子育て世代も延長保育やパートナーにお願いすることもなく早めに帰れて良かったはず。殆どは17時から続々と退社していたが、以前は無かった有志の二次会組もいくつかあったようだ。参加者にも総務部長にも「毎年これで良いね」と言われ、ほっとしたのを覚えている。
何が正解かは解らないが、業務時間内で終わる自社での短い時間の立ち飲み（椅子席あり）は好評だったので、幹事をやらされがちなSES増田は参考になれば良いなと思う。
基盤まわりの仕事をしていた時、あまりにもプロジェクトでメモリの初期化漏れが頻発して問題となり、プロジェクトのお偉いさんが捻り出したアイデアが「”物理”メモリ全部を定期的に端から終端まで0で埋める」というものだった。
そしてそれをどう実現するか？という会議に呼ばれたのだ。
指を使い「物理メモリを”端から””端まで”全部、プログラムが動かない時間に定期的に一回ゼロで埋めればいいじゃない？」との説明があった。
これは良いアイデアだとご満悦の上役と、違和感を覚えない他のベテランの参加者達。
「まず、仮にこれが実現出来たとして、サーバーが立ち上がった時点でOSやミドルがメモリを利用していますが、どうしますか？OSもミドルも当然落ちます。」
「メモリですが、皆さんが普段変数宣言やmallocで受け取っているメモリの番地ですが、全て仮想メモリのアドレスなのはご存知ですか？」
「我々のような庶民は直接物理メモリアドレスに仕組み上アクセス出来ません」
「物理メモリにアクセスするにはカーネルのプログラミングが必要になります」
「メモリにはユーザープログラミングで触れる事が出来る層と、カーネル層という仕切り、さらに仮想メモリ・物理メモリという仕切りがある為に、堅牢性を保持している云々」
ここまで伝えても皆ピンときていない。文章にすればまだ解るが所為オタクの早口の説明なので当然、私の話術にも大いに問題はある。
もしかして自分が間違っているのか？このままだと私がこの対応をやらされる羽目になる。
私は交渉事でうまく立ち回れる技を持っては居なかった。なので、最後の手段に出た。
「だからこんな方法は絶っっ対 実現できないんですよ！！！」と突然のブチギレ。いや、出来るのかもしれんけど。
一同ポカーン。突然のメガンテを使った私に皆パルプンテ状態になり、
「増田がココまで言うのなら出来ないんだろう」という事になった。
正直、高い技術も必要ない汎用的なシステムの開発現場のなんてこんなものだ。AWSもGitHubも触ったことのない私があえていおう。
最初のエントリーに業務時間内に勉強させろと書いたが、目的が無ければおそらく時間があっても、「私は完全に仕事をしています」という顔をしながらviで青空文庫やアマチュアの小説を読んでいた時間の方が長かったのではないかと思う。
