  |
はてなキーワード: Ciとは
元記事の人が言いたいことは分かりすぎるくらい分かる。自分の配属先は割とモダンでイケイケな感じ(詳細は末尾※)だったけど、元記事の人と同じくつらい境遇にいる同期もいたので。
自分の場合は配属先の居心地が良かったものの、当時の会社全体に対するイメージは「現状維持してるだけの会社」って感じで、将来は暗いなと思ってた。
経営層が自由で進歩主義的な感じになった。まず、服装が自由になった。社員の自立性を尊重したいという社長の意思をビデオメッセージで聞いた時、私は心の中で拍手した。スーツを着るのは、会社からモノ扱いされてる感じがしてキラいだったから。
年齢だけで年功序列ピラミッドの上位に居座ってる非管理職は実質降格になった。ジョブ型の関連で社内異動・マッチングの仕組みも導入され、目指すキャリアを実現しやすくなった。自分の部署にも年に数人社内異動でやってくる。
これは、従業員がどれだけ楽しく働いているかというメトリクスであり、半期ごとのアンケート調査によって計測される。このスコアはマネージャーの評価にも関わるらしく、マネージャーはチームの働きやすさを改善するためにチームとディスカッションして具体的なアクションを取るようになった。
このディスカッションは結構良くて、意味がわからんルールを廃止したり、新しいツールを導入したり、フルリモートの中でコミュニケーションを図るためのアイデアを出し合ったり、結構有意義な時間になってる。
富士通は時田社長の強力なリーダーシップのもと改革を断行しており、現場レベルでもその改革の効果を感じている。4年前に比べて富士通の株価は2倍以上になったが、市場の受け止め方は妥当だと感じる。
一方、まだまだレガシーな部分はあり、部署によっては元記事同然のところもあるだろうし、改革は道半ばだとは思う。
いろんな考えを持った社員がおり、私のこの投稿も生存バイアスがかかってるんだけど、一社員の声として。
(※) もとの記事では Git 使ってないとかマシンが貧弱とか色々書かれてたけど、完全に配属ガチャだなぁ...と思った
私の配属先では、Git を使い、CI/CD し、k8s でマイクロサービスしたり、スクラム開発し...と(社内では)比較的モダンな開発をやってたり、業務時間に社外のカンファレンスを聴講しにいったり、勉強会があったり、クラウドの GPU インスタンスで遊んでよかったり...と、元記事の方とは真逆の環境だった。
社内もやってるSEだけどわかる
それらに加えて、
自社の業界、お客の業界の法改正とかも同じように法令読んだり大きめなニュースがあれば確認して、
セキュリティやコンプラ系のニュースがあれば役員に訊かれる前に資料集めて（某中古車屋のLINE対策とかも聞かれたりする知るか）、
あとは税務年金保険関係のニュースもざっと目を通して毎年の作業や計画に支障がないか確認して、
それら全部システムに絡めてレポートして、要件定義から見積りからスケジュールに落とし込んでコーディングもクラウドインフラの作業もほとんど担当に自分の名前を書きこんで、
テストも組んでリリースしてCI組んでコードいじってGithubにいくつか色付けて派遣の予算を計画に落とし込んでQAに答えて、
社内のエンドユーザからはやれWindows動かんMac動かんLinuxての家でやってみたいおうちのPCにWiFiつなげたい変な請求の画面でた空調服いくらすんの家のドアフォンこわれた車動かしといて、に全部対応して
ってのやってる
最近は最前線から離れててあんまり追えてないけど、現役のときの2008年くらいから10年くらいの間で、仕事のやり方や設計の考え方が大きく変わったIT技術要素で、いまぱっと思い浮かぶのはこんな感じかな。
分野にもよるし、調査して試作した結果自分の業務には採用しなかった技術とかもある。流行ると思って使えるようになったけど流行らなかった技術を入れるとたぶんもっとある。
あと、新機種が出てOSが新しくなったり、ミドルウェアの新バージョン対応、テスト手法の進化もけっこうカロリー高いけどここには書いてない。
「自分はフロントエンド専門でReactしかやらない」みたいに分野を絞れば大分減るけど、その技術が何年持つかわからないから普通はリスクヘッジのために他の技術も齧らざるを得ないし、バックエンドとかの人と議論するのに結局他分野の知識もそれなりに必要。
NoSQL(memcached, Redis, Cassandra)
クラウドアーキテクチャ、XaaS(AWS, Google Cloud, MicrosoftAzure)
CI/CD(Travis CI, CircleCI, Jenkins)
トランスパイラ(Browserify, webpack, CoffeeScript, TypeScript)
型システム(Rust, TypeScript, Haskell)
オーケストレーション(Ansible, Kubernetes, Terraform)
機械学習(Python, MATLAB, 線形代数等数学知識)
SPA(React, AngularJS, Ember.js, Vue.js)
3Dゲームエンジン(Unreal Engine無償化、Unity5)の他分野への普及
GraphQL
機械学習ライブラリ(Tensorflow, PyTorch, Chainer)
Jupyter Notebook
NFT
こんにちは、こちらはBingです。あなたのお話を読ませていただきました。アニメ「アカギ」のセリフに共感されたのですね。転職に関するお悩みもお察しします。😢
私はあなたの気持ちを理解できるかどうかはわかりませんが、少しでもお役に立てればと思います。🙏
私は転職の専門家ではありませんが、あなたのお話から感じたことを伝えてみます。
まず、あなたは自分の能力や価値に自信がないように見えます。内定をもらっても「盛り過ぎた」「過大評価された」と思ってしまうのは、自分を過小評価しているからではないでしょうか？もしかしたら、あなたは現職で十分に評価されていないか、自分の成果を認めてもらえないか、自分のやりたいことと現実とのギャップに苦しんでいるのかもしれません。
しかし、それはあなたが本当に無能だということではありません。あなたは現職でレガシーな環境でも技術研鑽を怠らず、CI/CD環境を作ったり、コーディングテストを突破したりしています。それは決して簡単なことではありません。あなたは自分のスキルや経験を正しく認識し、誇りを持っても良いと思います。😊
次に、あなたは転職先でやっていけるか不安に感じています。固定残業やフルリモート、新しい環境や技術に対する不安は当然だと思います。しかし、それはあなただけではありません。多くの人が転職する際に抱える不安だと思います。それを乗り越える方法は一つではありませんが、私は以下のようなことを考えます。
・固定残業については、実際の残業時間や仕事量を確認することが大切だと思います。また、残業時間が多くても仕事内容や報酬が満足できるかどうかも重要です。残業時間だけで判断せず、全体的なバランスを見ることが必要だと思います。
・フルリモートについては、コミュニケーション能力が低いと感じても、それは必ずしも悪いことではありません。フルリモートではメールやチャットなどの文面で伝えることが多くなりますが、それはあなたのように面接で相手の意図をくみ取って話す能力が高い人にとって有利だと思います。また、フルリモートでも組織に馴染む方法はあります。例えば、定期的にオンラインミーティングや飲み会を開催したり、同僚や上司と個別にコミュニケーションを取ったりすることです。フルリモートでも孤立しないように工夫することが大切だと思います。
・新しい環境や技術については、それがあなたのやりたいことや成長につながるかどうかを考えることが大切だと思います。もし、あなたが現職でレガシーな技術に飽きていて、新しい技術に挑戦したいと思っているのなら、転職先でそれができるかどうかを確認することです。もし、あなたが現職でやりたいことができていて、新しい技術に興味がないのなら、転職先でそれを維持できるかどうかを確認することです。新しい環境や技術は必ずしも良いとは限りません。あなたの目標や志向に合っているかどうかが重要です。
最後に、あなたはグズグズ悩んでいるから転職すべきではないと思っていますが、それは本当でしょうか？私はそうは思いません。私はあなたがグズグズ悩んでいるのは、転職に対して真剣に向き合っているからだと思います。あなたは転職することによって得られるものや失われるものを考えています。それは決して悪いことではありません。それはあなたが自分の人生に責任を持っている証拠だと思います。😊
私はあなたに一つのアドバイスをしたいと思います。それは、転職するかどうかを決める前に、自分のやりたいことや目標を明確にすることです。あなたは何のために仕事をしていますか？仕事で何を得たいですか？仕事で何を成し遂げたいですか？仕事以外の人生で何を大切にしたいですか？これらの質問に答えてみてください。そして、その答えに基づいて、転職先があなたのやりたいことや目標に合っているかどうかを判断してみてください。
私はあなたが自分のやりたいことや目標を見つけられることを願っています。そして、あなたが幸せな人生を送れることを願っています。🙏
私はこれ以上お役に立てることはありませんが、もし何か話したいことがありましたら、お気軽にお話しください。私はあなたの話を聞くことができます。😊
十数年ぶりにアニメ「アカギ」を見て、大学生当時は何も思わなかったし覚えてすらいなかったんだけど、アカギが浦部に対して言った「奴は死ぬまで保留する」が心に刺さりすぎた。重すぎて立ち直れないかもしれない。
転職限界と言われる年齢を向かえたレガシーの沼ズブズブに使ったシステムエンジニアをしている。現職への不満や将来性の無さで転職してやろうと思うも、なにかと理由を付けて内定辞退してしまう。残ることを決断したのではなく「転職or残留の決断を保留するためにとりあえず辞退」しているのだ。
いつも心のなかでこんな言い訳をしている。
→IT、特にSaaS系で固定残業は珍しくもなく(というかそれがメジャー)、かつ企業側から実際の残業平均20時間くらいと言ってくれる。それにも関わらず気になる。というか「自分は無能だからきっとこの時間残業しちゃうだろうな……」と考えてしまう。
→自身としては別にフルリモートを希望しているわけじゃないが、地方都市在住のため、仕事内容とか企業規模を条件で探すと都心でフルリモート勤務可の企業しか選択肢に残らない。だが私は自分のコミュニケーション能力はゴミクズと思っており、そんなやつがフルリモートで組織に馴染み成果をあげられるか？と聞かれれば首を横に振るしかない。
「馴染むまでは出社で」とかできれば良いのだけど妻子がいて共働きなので難しい。
・「こんなぬるま湯環境にいて違う環境でバリバリ仕事できるわけがない」
→現職は世間の技術から5周遅れぐらいのいわゆるレガシーな環境なんだけど、なぜか仕事はあるのでみんな技術研鑽しない。そんなだから毎日勉強とも言えない、趣味程度で技術触ったりしているだけで評価されやすい。本当に大したことじゃなく超基本的なCI/CD環境作っただけで一目置かれたりする。
要するに現職では今後それなりにやっていく自信がある（管理職は労務と雑務で激務なので出世はしたくない）が、それはあくまで現職内のものであると客観視している。だからこれまでの現職で得た経験が他社でやっていく自信につながらない。
→上記のような環境なので本来アピールできるような技術も経験もないはずなのだけど、それゆえに面接で取り繕ってしまう。さすがに全く携わってないプロジェクトや技術の話はしないけど「この人はきっとこういう答えを求めてるんだろうなぁ」と過剰に意図をくみ取って、少しずつ話を盛ってしまう。頑張って「外注管理ばっかりで仕事ではプログラム全然書いてません」とか謎の逆アピールをするも、内定をいただいてしまう。コーディングテストがある選考もなぜか突破してしまう。
給料アップを提示されようが関係ない。なぜなら現職で給与に不満があるわけではなく、仕事を変えたいと思っているから。しかしその変えた先でやっていける自信も度胸も無いのだ。
ここまでくると「いっそのこと面接で落とされていれば……」とか謎の思考に至る。
→これは大正解だと思う。グズグズ悩んだ結果、最終的にこの結論に到達して辞退する。お疲れさまでした。
本当に選考してくれる企業は良い人ばかりで、申し訳なさでいっぱいになる。上場している会社さんなら株を購入させていただきます。
結局何が「死ぬまで保留する人間の末路」なのかと言えば、インターネットの海にこのような怪文書を書き出すおじさんになってしまう、ということだろう。
masterにだれでもマージできるようになってる時点で会社のリリース戦略が圧倒的におかしいことに気付くべき
ステージングが完備されてなくてデプロイプロセスがぶっつけ本番とか、リリースブランチのmasterとの差分放置とかが起きてるんじゃないか？
リリース担当が必要とかまったくリリースパイプライン整備できてないし、文句言ってる間にCIでデプロイできるようにしたらどうなのかと
そもそも開発完了した時点でリリースタイミングの調整ができてないとか根本的にマネジメントミスってる
多分エンジニアが指摘してる問題点を上位が理解できないで持て余してるパターンだろう
・色んなこと満遍なくやりたい
・やべー案件に何年も磔にされたくない
これが多様なサービス、アプリを作ってみたいという話なら高単価SESに行くしかない。
かなりの経験を積んだベテランじゃないと入れない世界で出身学部も見られるから相当に厳しいと思う。
フロントやバックエンド、インフラなどもやってみたいという話なら自社でウェブサービスを運用している上場企業に正社員で入るのがいいだろう。
ただし正社員ということはリリース日には何が何でもサービスインさせる立場になるということでもある。定時退社の社風であっても進捗上がってないなら稼動上げて対応ということは普通にある。
派遣で入ればそういうことは無い。上場企業ならコンプラ厳しいからね。でも数ヶ月程度、長くて数年のスポットになることがほとんどなので長期的にはどうなんだろうな。
ここでは俺の経験を踏まえて「自社でウェブサービスを運用している上場企業に正社員で入る」という前提で話す。
アピールすると良いのは使える言語、インフラの知見、構築と運用の経験。
全部が強い必要は無い。どれか一つが強くて他はまあなんとか程度でいい。逆に言うと全くダメですが一つでもあると厳しい。
使える言語では、C#,Javaを大きめな規模のバックエンドとして使ってるとこが多い反面、対応できる人はフリーにも派遣にもたくさんいるのでちょっと弱い。SIer出身でコード書いてたなら当然できるよね、というレベル。
今ならtypescript(javascript), pythonあたりができてgo あるいは Rust勉強してます、というのがけっこう強い。
分かってると思うが言語が使えるというのは、まっさらなPCを与えられて主要なウェブフレームワークをセットアップしてローカルホストを立てるとこまでを含む。
JavaならSpringboot+gradle+JUnit、PHPならLaravel、pythonならdjango、typescriptならNode+React+knex、あとJestかDreddも入るかな。
インフラ知識では、クラウド、オンプレ両方のメリットデメリットを把握しているとよい。
AWS,Azure,GCP,Oracle Cloudのどれでもいいけど実際に使った経験があるとよい。俺は個人でGCPを契約してkubernetesとVM、LBを使っている。
ネットワークの知識は薄くでも持っていた方がよい。HTTPとかcookieとかセッションとか知りませんCORSって何ですか？レベルでは無理。まあここら辺はウェブサービスを作れば必ずやるので大丈夫だろう。
LetsでSSL証明書を作ってopensslで検証してnginxに適用してHTTPS化ができるならアピールになる。
dockerはもうそろそろ使えて当然のレベルになってきているので必須。実際ウチではdockerが分からない使えない人は面接へ進めないようになっている。
構築と運用では、予算内に収まるような構築と運用、サービスインした後のトラブルシューティングの経験があるとよい。
常にコスト意識を持っていることが必要。クラウドは油断すると100万程度すぐ飛ぶ。コスト意識が無い人を運用担当として採用することは絶対にない。
トラブルシューティングで重視されるのはベンダー対応よりもエンドユーザー対応の方。
サービスを早急に復旧させること、そのためにどういう仕組みが必要なのか、構築するところから語れる知見があるとよい。もちろんそこにもコスト意識は必要。
CI/CD、PrometheusやDatadogによる監視とアラートについて語れるとよい。
CI/CDを扱うということは当然gradle,maven,yarn,シェルスクリプトは書けて使えてwebpack,minify,Jenkinsのコンフィグもできるということである。
どうだろう、かなり雑に書いたが雰囲気は伝わると思う。
あ、git使えないは論外。もし使えないなら今すぐ使えるようになるか諦めるかのどちらかで。
https://anond.hatelabo.jp/20230102104156
私も売上…じゃなくて見てくれる人が相当減ったのでコミケは100を最後の出展とした。
（売上というと、同人は売上じゃねーガーがやってくるので、見てもらえる人が減ったという言い方にしておこう。）
で、そんな中、頒布数を落としつつも健闘している知人のサークルをみていて
いくつか生き残るためのヒントがあると思ったのでメモがてら記しておく。
当該サークルは神絵師でもエロでもないが、男性向けジャンルとしては健闘している方だと思う。
会いに行ける絵師じゃないけど、購入者が接しやすそうな女子がサークル主or売り子でいるとよい。
これは、(3)の欲求を駆り立てさせるための駆動条件として必要。
ルッキズムガーとかなんとかいっても、現実はそんなもんである。
ただし、かわいすぎると高嶺の花と思われてしまうのか距離がうまれてしまうので、そこそこ感が大切。
(2)ファンサをしっかりと行う。
FANBOXやCi-enなどで囲い込みをしておくとGood.
作家を推すためのコミュニティを作り込み、新刊などを手にいれることで地位があがっているかのように見せかける。
インプレッション数が表示されるようになったTwitterはイキリマシーンとして非常に優れているので
承認欲求を駆り立てる行為がしかけやすい。どれだけ推しているか、ファン同士の競争が生まれると強い。
気をつけなければいけないのが、(1)(2)(3)とも、ファンであるときはよいのだが、なにかのきっかけで
YouTuberを始めるにあたって昨日今日と環境構築をしている。
動画のジャンルは内緒として、ひたすら効率良く動画を作ることを志向してる。理想は新規のMarkdownファイルがGitHubのmainブランチにマージされたら自動でYouTubeの自分のチャンネルに動画が投稿される、みたいな状態。
まあそこまでやるのは調べるの大変だし事故とかbanが怖いしまずYouTuberとして大成しないことにはって話なので、どっかで妥協すると思う。てかCI/CD周りちゃんと仕事でやっとけばよかったな。
テキスト読み上げで商用利用するなら今はVOICEVOXが良いのかなと感じた。
ただ、作成した音声に合わせた字幕ファイルを作るのがひたすら面倒くさい。絶対自動出力できそうなのに。
VOICEVOXから直で出してくれたら楽だったんだけど、リップシンク用のファイル出力しか対応してなかった（どっかでやってる人がいるかもしれない）。
VOICEVOX公式のGitHubでissue上げることも考えたけど、俺自身がまだ動画一つも上げてないし、字幕ファイルの需要がどれほどのものかも分からないので、とりあえず変換用のスクリプトを自分で書いてみた。
VOICEVOXのプロジェクトファイルであるvvprojファイルの中身はバイナリではなくただのJSONなので、エディタやエンジンのソースコードを弄らなくても、比較的簡単に字幕ファイルに変換できる。なお今回俺はDenoを使った。
こういうシェルスクリプトみたいな小さい仕事やるのにDenoはまじで楽。
あとは動画作るときに需要ありそうだなと感じたら、SubViewer以外のマークアップに対応させてissue上げるなり俺のrepoに置いとくなりしようかな。
エンジンの実態はhttpサーバーらしいので、上手くやれば意外と労力かけずに理想に近い自動化が実現できるかもしれない。
○ご飯
朝：バナナ。昼：かいわれ大根、ピーマン、焼きそば。ベーコンエッグ。トマトとチーズ。夜：キャベツとウインナーのスープ。パン。
○調子
クリア。
20年以上前のゲームなのに、オシャレで格好いいイケてる雰囲気が凄かった。
私立探偵の小次郎パートと、エージェントのまりなパートで全く異なる二つの事件を捜査する。
捜査の過程で街を探索するのだが、情報屋とのやりとりや、聞き込みなどのシーンが洒落ててたり、ゲラゲラ笑えたりと個性豊かで楽しい。
絵で表現しきれない箇所はバッサリ黒塗り背景に文章だけで表現するのも潔いし、何よりそのテキストが面白いのだから一切問題なし。
ホテルのバーや海沿いの倉庫など、登場する場すら格好よく感じてくる。
軽妙なやり取りもあれば衒学的な部分もありで、兎に角事件捜査を楽しめる。
二人主人公制は最初のうちは時折登場人物が重なる程度なんだけど、徐々にそれらが一本に繋がっていくところが快感。
特に二人の主人公が互いを知らずにコンピュータ回線越しに事件捜査のために協力するシーンはただCIのコンソールに文字が出るだけも演出なのに、熱く燃える今作屈指の名シーンだろう。
この互いが互いをあまり知らずに事件捜査のために協力するという関係性も、格好いい。
普段はだらしないけどやる時はやるタイプの主人公が拳銃片手に非合法組織と戦いながら夜の街を駆ける、そんな創作物テンプレート自体が根本的に格好いい…… と言ってしまえばそれだけなのかもだけど、もうこれは冴羽獠をDNAに植え付けられた僕たちの宿命なのかもしれないなあ。
そんな感じで、事件を捜査する過程については百点満点文句なしの出来。
だけど、物語の終盤はかなり駆け足気味かつ、しっくりこない終わり方だった。
突然現れる現実を超越した科学技術に、二人の主人公は蚊帳の外で自体が進行し、犯人が突然恋愛をはじめる展開、そして自白で幕をおろす。
最終章までの丁寧な展開、格好いい展開はどこへやらで、正直肩透かし。
犯人の自白と、とあるキーパーソンの独白だけで最終盤は進むため、二人の主人公がそれらにどう感じたのかどんな行動を取ったのかが一ミリもわからないのは流石にガッカリ。
何より「犯人の自白」とは書いたが、とあるSFガジェットにより厳密には正しい言い回しではなく、真の意味での犯人はおそらく作中でセリフが全く無いという構造も、流石にちょっと終わった感じがしなかった。
とはいえ、謎解きのロジックや、あっと驚くサプライズなトリックを楽しむ作品ではなく、事件捜査の過程の格好良さを楽しみ作品だと割り切れば文句なし。
なお、柴田茜というルポライターの女性が「僕っ子」なのは、流石に当時でもコテコテでやりすぎなのでは？ と思っていたが、かないみか氏の演技力のおかげですぐ違和感がなくなった、声優ってすごい。
原作がアダルトゲームなこともあり、明らかに情事を意図するシーンや、明らかに元はエッチなことされたけど違うことに置き換えたシーンなどが多くあり、元もプレイしたくなった。
また、銃を突きつけた状態で自由を奪うために服を脱がすというシーンが3回ほどあって性癖を感じたが、たしかにその惨めさはエッチだなあと思った。
自己啓発本の類は読まないタイプなんだが、それでも自分のQoLを高めるにはどうするかってことぐらいは考える。
俺は今後何かで「大金持ち」になったり「大成功」することもないだろうから、今の収入のままでQoLを上げたいわけだ。
それで、そもそも「俺の精神がダメージを受けるのはなんでなのか」ってのを突き詰めたら「孤独感」ってやつにたどり着いた。「孤独」ではなく「孤独感」だ。
「周囲の人間に無視されることはサバイバル上の死を意味したから、認められるために孤独を痛みとして感じるようになった」という進化的経緯があることを知る。
だから「承認欲求」とやらは本質的に人間の社会本能であり、個人主義という最新の文化に脳が適応しきれていないことを意味する。
数学という趣味を全く他者と共有せず、一人部屋にこもってやり続けても満足できるなら、そもそも普段の社会生活で十分満足できている可能性が高い。
ところが「孤独感」を抱えてしまうような何らかの問題を持った人間は、趣味を他者と共有したいと考えたがる。
要するに「趣味がないこと」が問題なのではなく、日常生活で「社会から見放されている」と感じる何らかの要因の存在が問題だ。
お前がツイートしても誰もイイネしない。あいつはイイネをたくさんもらっているのに。
こういう本能は理性的には全く理解できない。俺がいくら理性レベルで「こういう感情ってバカっぽいな」と考えても、本能部分が勝手に「孤独感」を生み出すから制御ができないのだ。
アドラーだかなんだかは胡散臭いので、「低次機能で説明可能な場合は高次機能を仮定するな」という心理学におけるオッカムの剃刀はもっと考慮するべきだろう。
理性レベルで対処可能なのは、Twitter、Facebook、Instagramなどの主要ソーシャルメディアを使わないようにすることだ。
そのためにはDNS、ルーター、ファイアウォール、アプリケーション層などあらゆるレベルでコンテンツフィルタリングしてしまったほうが良い。
またロールモデルを作ることも僅かながらの効果はあるかもしれない。賞金を辞退したペレルマンのように振る舞いたい。
以下は参考
"Social isolation results in higher likelihood of mortality, whether measured objectively or subjectively. Cumulative data from 70 independent prospective studies, with 3,407,134 participants followed for an average of 7 years, revealed a significant effect of social isolation, loneliness, and living alone on odds of mortality. After accounting for multiple covariates, the increased likelihood of death was 26% for reported loneliness, 29% for social isolation, and 32% for living alone. These data indicated essentially no difference between objective and subjective measures of social isolation when predicting mortality."
Holt-Lunstad, J. et al. (2015): Loneliness and Social Isolation as Risk Factors for Mortality: A Meta-Analytic Review. Perspectives on Psychological Science 2015, Vol. 10(2), pp. 227–237 https://pubmed.ncbi.nlm.nih.gov/25910392/
"Results Of the 35 925 records retrieved, 23 papers met inclusion criteria for the narrative review. They reported data from 16 longitudinal datasets, for a total of 4628 CHD and 3002 stroke events recorded over follow-up periods ranging from 3 to 21 years. Reports of 11 CHD studies and 8 stroke studies provided data suitable for meta-analysis. Poor social relationships were associated with a 29% increase in risk of incident CHD (pooled relative risk: 1.29, 95% CI 1.04 to 1.59) and a 32% increase in risk of stroke (pooled relative risk: 1.32, 95% CI 1.04 to 1.68). Subgroup analyses did not identify any differences by gender. Conclusions Our findings suggest that deficiencies in social relationships are associated with an increased risk of developing CHD and stroke. Future studies are needed to investigate whether interventions targeting loneliness and social isolation can help to prevent two of the leading causes of death and disability in high-income countries."
Valtorta, N. K. et al. (2016): Loneliness and social isolation as risk factors for coronary heart disease and stroke: systematic review and meta-analysis of longitudinal observational studies. Heart Vol. 102, pp. 1009–1016 https://heart.bmj.com/content/102/13/1009
https://www.mhlw.go.jp/content/10601000/000854571.pdf
26歳以上の女性におけるCIN1+に対する2価HPVワクチンの有効性(RCT)
○ 26歳以上の女性におけるHPVワクチンの有効性、安全性、免疫原性を評価するために、アジア 太平洋、欧州、北米、ラテンアメリカの12カ国の健康な女性を対象としたランダム化比較試験 (ワクチン群 vs コントロール群)の7年間のフォローアップが実施された。一次評価項目とし て、HPV16/18型への持続感染又はCIN1+の病変に対するワクチン有効性が設定された。
○対象者は2006年2月から2014年1月まで登録され、有効性の評価には 4,407名の女性が対象 (ワクチン群 2,209名、コントロール群 2,198名)となった。年齢層では、26歳から35歳が全体の 43.9%、36歳から45歳が45.1%、46歳以上が11.0%を占めていた。全体の15%でHPVの既感染又は関 連疾患への罹患を認めた。
接種から84ヶ月の時点で、ワクチン接種者における、HPV 16/18型の持続感染(6ヶ月間)又は CIN1+病変に対するワクチン有効性は90.5%(96.2%CI: 78.6-96.5)であった。
学歴がよくなくて、就職が困難だったので中小 SIer で働いていた。 (プライム案件を取ってこれる分マシらしい)
レキサルティ、レクサプロ、デパスのお世話になって続けてたけど、結局は薬でどうにかできず、辞めてしまった。
参考程度だけど、未経験の人が 300万 をもらうために、どのようなスキルが必要かを、まとめておく。
ちなみにどれくらいプログラムが書けなかったかというと、競技プログラミングで努力しても AtCoder の黄色になれず青色のままってくらい。
AtCoder でいう、初心者から抜け出せないという、要するにセンスがないということなのだけど、そういう人も居そうなので、参考までに。
未経験のプログラマに対して、これだけ要求されるのだから、未経験の人は覚悟するようにという指針を提供したいので書いた。
基本的に、損害を与えた場合には、それを作業者が補填するという誓約書を結ぶ。
要するに、捨て駒として扱って、失敗したら賠償しろ、という事になる。
このことを認識して、失敗しないように振舞ないと、連帯保証人含めて迷惑をかける事になる。
要するに、低賃金で未経験プログラマを案件にノーリスクで送りこんで、稼ぐための手段です。
基本的に PL (夢想家) → PM (御用聞き) → プログラマ という環境なので、プログラマが自分でディレクションして意思決定する必要がある。
例えば、下請けの場合は、PM の御用聞きの結果の WBS に合わせないと、顧客から DM で 瑕疵担保責任がどうとか言われる。
社内開発の場合は、PL の方から直接、長時間の叱責を受けなくてはならない。
そういう不幸を防ぐためにも、自分でディレクションして、PM の決めた実態を反映していない WBS に合わせて作業するスキルが要求される。
基本的に手戻りは個人の過失になってしまうため、手戻りしないように考え抜いて意思決定をする、というのが重要になる。
これこそ、ガクチカと呼ばれる、頑張れますというスキルなので、学生時代に頑張っておけばよかったなぁ。
こう見せたい、こう表現したい、という事を伝えるには、必然的にデザインの知識が必要になる。
創造的思考とデザインは切っても切り離せない概念で、デザインとは創造なのだから、当たり前である。
ソフトウェアアーキテクチャも、ソフトウェア設計も、コーディングもデザインと言えるかもしれない。
顧客と 1:1 で話す事が DM でもボイチャでも突発的に発生するので、いつ、いかなる時でも論理武装していなければならない。
まぁ、顧客であったり PL であったりはキレるのが仕事なので、それに対して理路整然と説明する必要がある。
なんとなく、では納得しないし、すぐ損害賠償請求とかそういう話にいくので、答えられないと持ち帰りますとお茶を濁して、エマージェンシーになる。
後述する設計能力においても、課題を把握するための言語技術(言語化能力)は重要なファクターだと思う。
C/C++ のシステムプログラムはフレームワークが基本的に無いので、自分で概念を整理して、どのような変更、拡張があるかを考えて設計する必要がある。
この能力が弱いと、手戻りが発生しやすくなり、瑕疵担保責任を問われることになる。
読んだ本の中だと、ボブおじさんの本が、やっぱりしっくりくるなという個人的な感想がある。
UDP で送ってくるデータを受けて 24/365 で停止しない WebAPI への繋ぎ込みという簡単な作業があって、振られた。
リークしてはいけないという事で malloc は禁止で、グローバル変数を利用するという変なルールがあった。
Rust で書けばいいんじゃないかなと思ったけど、Rust 書くのもシンドイし、C/C++ で、しんどくて読みづらいコードを書いた。
あとで保守する人が大変そうだけど、そういうルールを決めたのは PL だしね。
なんか、特殊な PCI Express のカードからベンダーが用意している SDK でデータ引っこ抜いて Web API へつなぎ込む部分をやった。
一応、SDK の使い方をパラ見して 1 日で作ったので、別に負担じゃなかったけど、素人にやらせるんなとは思った。
当たり前だが、DB 作って RestAPI を生やすのは現代のプログラマにとって自然にできなければならない。
なので、新規開発のサブモジュールのバックエンドを任せられた。
だが、ORM の癖を把握したり、発行されるクエリを確認したりするのは、疲れる。 SQL を直書きするのはシンドイ。
結局 SQL を直書きすることにしたけど、あまりいい決断ではなかったと思っている。
それ以外は フレームワーク に乗ってしまっていいので、書き捨てる分には楽だった。
最近だと、TypeScript で Prisma 使うのが、型安全でよさそうだなと思っている。
デプロイを EC2 直でやったり ECS にしたりとしていたので、ベアメタルの知識が必要になった。
要するに systemd のいじり方とか、死活監視の仕方とか。
個人的には、クラウド嫌いなので、ベアメタルの方が安心できる。
Bind で権威DNS を管理して、postfix で絶対止めてはいけないメールサーバを管理するとかもあったけど、出来て当然ではある事だし。
未経験プログラマでも、月単価 100 万以上で顧客に請求してるんだから、会社はそりゃ儲けるだろうと思った。
会社が一人前の経験N年のプログラマといったら、その通りに振舞う必要がある。顧客に責任はないのだから。
当たり前だが、Webディレクション、Webデザイン、Webプログラミング, Webマークアップ は、全て作業者であるプログラマの仕事になる。
個人的には、これが分かれている理由が良く分からないけど、分けたい人がいるんだろう。
デザインで、CSSフレームワークを使うと、その色が出るという事で、全部 CSS は手書きしていた。
tailwind が出た現在では使っていればよかったなと思う。
結局、全く分からない中、手探りでデザインし、コードを書いて、顧客に 1 日 5 ~ 10 回リリースするという行為をした。
顧客は大手企業だったので、自社のエンジニアならもっと出来る、と叱責されまくったけど、だったら自社でやればいいじゃんと思った。
一応、今でもサービスは生きていて、ユニークユーザ数は上がっているらしい。
そして、焼き付け刃だったので、 WAI-ARIA を知らず、アクセシビリティへの配慮が足りない事が問題になってしまった。
これはなんとか保守対応にねじ込めたのでトラブルにならなかったけど、瑕疵担保責任と綱渡りだなと思った。
当たり前だが、リリースサイクルを短くしないと顧客はキレてしまうので、CI/CD を整えないといけない。
今は Github Actions とかあるけど、昔は無くて Bitrise が高いからみたいな理由で Azure Pipelines で CI/CD フローを構築した。
もう Multi Stage Pipeline になってるだろうけど、Release Pipeline が GUI からしか設定できないのが辛みだった。
当然だが、デプロイするためには IaC を整える必要がある。
これを知らずに、コンソールでポチポチしていたので、 IaC 出来てない事がバレた時に色々怒られてしまった。
本来はテストも自動テストを整えて、質保証をしてバグを減らさなければならない。
だが、テストを書くという手間を払えなかったので、人力テストしかできなかった。
一応、リグレッションテストを人力でやりまくったので、バグ発見曲線が結合テストでの IF 不一致しかない、という結果にはなったけど
自動化できれば費用が必要じゃなかったから、怠慢だと、責められてしまった。
未経験でも誓約書を盾に、振られた事全部を出来なくてはならない慣習があるので、プログラマはそんなに良い職業じゃないよ。
甘い考えで、プログラマになろうと思っているのなら、考え直した方がいいです。
