  |
はてなキーワード:カバレッジとは
というか、それ以外に思いつかないんだよな。
localhostが消えるとか、あまりに初歩的で致命的な不具合、今まで正しく動いていたところに発生する不具合は、ここ1、2年で経験がある。
というか、ここ1、2年にしか経験がない(もちろん主犯はおいらではない。居合わせただけ)。
これ。
あと、
サジェストによる書き換えが危険なのは、スコープ(フレーム)外での利用のされ方をAI が把握できない、部分(覗き穴/ピープホール)最適化しかできないと言う点と、こちらが本質的な問題なのだが、そこの処理の仕組み、文脈を理解してサジェストしているのではなく、学習元データで多く組み合わされているパターンを提示しているに過ぎない、と言う点だ。
これ、時間が経ってから致命的な事態を引き起こし、原因究明に手こずる原因になる可能性がとてもとてもとても高いのだよな。
レビューすると、「AIのサジェストがあったので」的な修正が入っていることがちょいちょいあるんだが、妥当でないサジェストを却下するだけの技術力がない場合、むしろLintとかパターンチェッカー的なのに留めておいた方が、思わぬ瑕疵を埋め込まずに済む。
できるエンジニア視点でも、スキャフォールドとして使おうとすると、細かく指定できそうで生成量が多いと見落としが発生しそうだし、確実なテンプレートで十分じゃん？ という気しかしない。開発が進んだ時点では、さらに使い所がない。なぜなら、「新しいものを作っている」ので、既存パターンが通用しないことが多いから。
AIの生成「量」が圧倒的なのは確かなんだが、このレベルのコーディング能力を「神」と考えるレベルのエンジニアからは実質制御不能で、これを使役できるレベルのエンジニアからは低能中途半端すぎて役に立たない、ってのが、呪術廻戦の摩虎羅やな、と感じる。
例えば絵の自動生成なら、登場人物の一人の指が6本になってようが、この線はどこに繋がってるんだ？ とか、この漢字はなんだ？ みたいなものが混じってようが、ぱっと見気づかないし、見直しておかしいのに気づいても、大勢に影響はしない。
けど、システムの場合、下手すりゃ1ビットで致死的障害を発生させてしまったりする。
その違い、ヤバさを理解できてないエンジニアがこんなにゾロゾロと存在する、という現実に絶望する。
加えて、「マジかよ……」ってなるのが、「既存のテストがないから、AI で追加してカバレッジをあげた」ってドヤ顔で語るエンジニア。
なんて言うか、なんとなく良さげなテストを理解しないでなんとなくマージしてるんだけど、何をテストしなきゃいけないか理解しないで、現状のコードを追認するだけだったりする。
それで必要十分かちゃんと検討できるだけの技術力がないと、「命綱、巻きつけたよー」と言いつつ、その命綱が宙に垂れてるのに気づいてない、って状態になってたりするんだよね。
で、不具合が表面化したら、それ用のスペシャライズドな監視の仕組みを追加して、手動テストを追加して、不具合が発生したら本番DBに接続して手動で修正するって、そんなのが日を追うごとにどんどん増えていって、仕事の大半が不具合対応、ってうんこみたいな現場があちこちで爆誕してるんよ。
でも、どのエンジニアも、自分たちの現場が異常であることに気づくだけの技術力がなくて、毎日みんなで奴隷が回している謎の棒を回し続け、経営者は、なぜこんなにエンジニアの数が必要で、お金が湯水のように浪費されているか理解できなくて、ストレスを溜めまくってる。
気づいた人はとっくにやめてるから。
炎上してないけど、針の筵だよね。
「品質管理が僕たちの責務です」
って、最近エンジニアリング界のライザップ的元テスト専門会社のQAエンジニアが、昔、言ってたなぁ……、と。
思い上がるなっ！
君たち如きに背負えるものでは、すでにない。
とあえて言おう。
いや、マジで、無理なんよ、もう。
例えば、キッチキチにエレベータを作り込んだとして、後から点検してくれ、と言われたら、まぁ、普通は困るよな。
モーター室がモーターが入るギリギリの広さだとしたら、箱の外に出る手段がなったら。
どうやって点検するんだよ。
実際には、設計時に点検方法を決定して、それができる余地を確保してから、施工するものだろう。
今時のEV車なんて、テスト用の仕組みがきっちりと、製品に組み込まれている。
検証不可能とまで言わなくても、検証困難な場合はちゃんと対策をとるもんです。
作りきってから、「E2Eテストお願いねー」とQAチームに投げるものじゃあないんですよ。
設計時に、テスト戦略から何から何まで検討済みになってるもんなんです。
別にユニットテスト書いて、カバレッジあげるのがTDDというわけではない。
検証可能なシステムを設計実装し、リリースのたびにシステムの健全性を検証できる仕組みを整える。
ってのが「テスト駆動開発」なんですわ。
テスト戦略をちゃんと練れば、マイクロサービスの分割の仕方、連携の仕方等々、多分、今、Web上でよく見る記事とはだいぶ様相が異なってくるはずだ。
で、プロダクトの中身である、設計や実装を理解できなければ、検証のしようがないのがここ10年ほどだ。
金槌を渡されて、「品質検査しろ」と言われたら、まだ何とかなるだろう。
けどボーイング787をポンと渡されて、「品質検査しろ」と言われたら？
マニュアルなしで。
モジュールがどう組み合わされてるか等、中身を理解できなければ、何をどうしていいかも分からんだろう？
扉の開け閉めができるとか、主電源入れたらなんか部屋の明かりがつくとか、そういう表面的な検査しかできないだろ？
これは、QAが、設計に飲み込まれることを意味する(10年以上前に、↑のQAエンジニアとした話)。
QAのテストに関する知見を、設計実装するエンジニアは当然持っておかなければならないということとともに、QAエンジニアは消えてなくなるということでもある。
お分かりだろうか？
同じ流れで、SREも不要になる。
Infrastructureas Code は設計実装エンジニアのためのものだと言っておこう。
決して、Terraformのファイルを編集して、SREの許可を、延々と待ち続けて、適応してもらうことをいうわけではない。
そこまで込みで、設計するのだ。
高負荷時にどうスケールさせるかなども、当然設計に入ってくるからな。
ってなわけで、ほとんどの現場では、そういう致命的な誤認識をしていると思う。
認識が古すぎている上に、大型化複雑化した現状を認識できていない。
開発初期はまだ規模が膨らんでいないから、何とかなりそうな勘違いを犯しているだけの話だ。
初回リリース前後で、「あ、やばい……」となっているところがあまりに多すぎる。
また、この誤認識によって、役に立たないエンジニアの頭数だけを並べて札束を燃やし、事業の拡大の足を引っ張っていると指摘しておこう。
ここら、どげんかせにゃならんのよな。
正直、AI に命令を出すリード、マネージャ、リーダーの能力が上がらないと、AI でコードを大量生産すると手に負えないスラムが根深く絡み合った構造で広がっていくことになるだろうというのが既に見えている。
というのも、AIほとんど影響ないちょい前の時点ですら「うちはDDD、TDD、クリーンアーキテクチャ、k8s、アジャイル、スクラム等々を採用して云々」ってプロダクトが、リリースから半年、1年で開発がスタックしている、という事例は一般が想像する以上に存在している。
リリース時は、CTOやマネージャが腕組みしてWebページで華々しい成果発表するものだが、その裏で手動運用のオンパレード、一箇所変更したらどこに影響が及ぶかわからない地雷原、不具合障害が発生するたびに増える監視サービス、手動運用マニュアル。
その前で、「圧倒的ではないか、我がプロダクトは」って悦に入る経営陣、の図。
それ見て「SaaS界のネズミー王国や〜」って妄想を迸らせる利用者側経営陣と、ブルシットな手数だけ増えて、業績給与はぴくりくらいしか動かないで悶絶する利用者側従業員。
この状態で、「いや〜、新技術の導入、失敗しましたわ〜。経費が5倍くらいに膨れ上がってます。ごめんちゃい」なんてリリース出せないでしょ。
それ見て教科書ガイドエンジニア、カタログショッピングエンジニアが「世界を変える！ 俺(の業務経歴書)が変わる！！」って初見手探りで導入して、連れション地獄。
これが現状よ。
ここにAI が入ってくると、ますます「中身も、他の処理との関係性もよくわからんけどプロダクトに組み込まれた謎プログラムの塊」が、「これ以上機能を載せるとバランスを崩して全体が倒れる」寸前のサイズまで育つわけよ。
ここまで行っちゃったら、どこをどうしたらどうなるか、「AI 使ってふふふふ〜ん」ってレベルのエンジニアでは太刀打ちできなくなってるだろう。
すっと
「動くな！」
となって、対策のための会議とドキュメントづくりが延々と半年とかいうオーダーで繰り広げられることになる。
その間やれること、というかやらなきゃならないことは、障害対応手動運用。
こういう状態に陥らせたリーダーやリードテック、CTOは「新しいことに挑戦したいので」と敵前逃亡、成果発表のWebページを担いで次の犠牲者の元へ。
ちゃんと設計したら、生成AIを駆使する必要、あまりないはずなんだよなー。
で、テストも書いてくれる、っていうけど、AI に全投げ似非エンジニアにその妥当性とか、判断できんのかな？
カバレッジを100％に近づけるためだけのテストを手動で大量に書くのを代替してくれるかもしれないけど、あのテストが品質保証、障害対策になってる現場が一つでもあるか？
今流行りらしい、業務ドメイン分割マイクロサービスだと、AI で辻褄合わせてテストとか、無理やぞ。
という地獄が、2、3年後訪れるだろう。
楽しみやなぁ〜w
という話をすると、AI使いこなせないオールドタイプの負け犬の遠吠え、みたいにいうてくるのがいるんだけど、むしろAI を効果的に活用するための構造、構成とか模索してんのよ。
これ
「推論する生成AI」は事前学習されていない課題を正しく推論することができない（共変量シフトに弱い）
https://tjo.hatenablog.com/entry/2025/08/27/173000
ChatGPT5-Thinking
まとめ
論文の核は「CoTは“訓練分布”の帰納バイアスに依存し、分布ズレで壊れる」という丁寧な定式化。ここからブログの「CoT=単なるパターンマッチング／未知問題を解く推論はしていない」まで一気に飛ぶのは、実験カバレッジの観点でやや言い過ぎ――というのが私の見立てです（知らんけど）。
俺も同意見だったのでよかった。
「学習済みデータから外れた話題（つまり非常識とか仮定の話）はLLMは苦手」はそうだけど
「全く推論しておらずパターンマッチしかしていない」は言いすぎだし、論文もそんなこと言っていない
「推論か、パターンマッチか」の話って、例えるなら「計算してるのか、計算結果を暗記しているのか」みたいな話だよね
人間だって1+1=2だったり、4x8=32であることは暗記で覚えてるだけで、数学的に計算してるかと言われれば微妙な話で
じゃあそれは間違ってるかと言われれば間違っていない、暗記だけでも割とどうにかなる
でも、じゃあ例えば「今から×の意味を変えますね」と言われれば確かに回答精度は落ちるわけで、それは人間もLLMも苦手なのは変わらない
じゃあ、「きみ、×の意味をかけたら点数落ちたね、つまり、きみは全部の計算を丸暗記してるってことだ」って言われてるのが今回のブログ主の主張なわけで、それは違うでしょう
「まったく解けなくなった」と「点数が落ちた」はぜんぜん違う
実際、推論の話に戻すと、簡単な推論はできてると経験則で感じている
ただ正直人間のほうがまだ推論は得意なんだと思う
ChatGPT5の意見
1. LLMはどの程度「推論」できているのか
• できること
• 与えられた前提から、既知のパターンを組み合わせて「もっともらしい」結論を導く。
•簡単な論理パズル、数学の基礎問題、文脈依存の推測（例：「太郎は次郎より年上です。次郎は花子より年上です。誰が一番年下？」）などは成功率が高い。
• これは統計的予測という枠を超え、有限の「形式的な推論」能力を備えていると考えられる。
• 苦手なこと
• 訓練分布から大きく外れた未知の課題（非常識な仮定や新しいルールの即時理解）。
• 長期的・多段階的な論理チェーン（例：複雑な数学証明や未踏の論理課題）。
だから、推論すらパターンマッチしてるわけなんだよね、推論を丸暗記してるってことで、結果を丸暗記してるわけではない
いうて人間だってそうだからね？論理学の勉強の最初の段階までは丸暗記だ
＿＿＿＿＿＿＿＿
以下、ChatGPT5-Thinkingのブログへの反応
DataAlchemy は人工ルール（文字列変換など）で “分布のズレ” を厳密に制御できるのが売りですが、ここで得た性質を「CoT一般」へ広げるには前提が強い。論文のコアは「CoTの有効性は訓練分布との乖離度に本質的に縛られる」という枠組みの提示で、外界の多様な現実課題まで即断するトーンではない（抽象は “inductive bias learned from in-distribution data” と表現）。ブログ側の「単なるパターンマッチングに過ぎない」への言い切りは半歩強い。  
ブログは「温度やモデルサイズを変えても効かなかった（図10）」と書くが、論文は “fromscratch での統制実験” がポイント。巨大モデル＋多様な前学習・手法（tool use、program-of-thought、process supervision 等）までカバーした結果ではない。ここから「LLM一般でサイズ・設定に依らずダメ」と読み替えるのは飛躍。  
論文は「CoTは訓練分布で形成された帰納バイアスに基づく生成」と述べるに留まる。一方ブログは「未知の問題を解く推論などしておらず単なるパターンマッチング」と断定的。分布依存である＝“推論がゼロ” とまでは論文自体は言っていない。  
ブログは「人ならルールが分かればこなせるはず」を前提にするが、実際に人間の学習曲線や誤り傾向と並置した比較は記事の説明範囲では示されていない。そこから「人のような推論はしていない」へ飛ぶのは論証として弱い。 
5. “丸暗記”論文の持ち込みの直結
Zhang+ (2017/2021) は「DLはノイズにも完全フィットできる＝表現力が高い」ことを示した古典だが、これは CoT の機構を直接に否定する証拠ではない。補助的根拠としては理解できるが、「だからCoT=暗記」と結論づけるには橋渡しが不足。  
一方で、筋の良いポイントもある：
• 共変量シフト下で性能が落ちるのは機械学習の一般的な性質で、CoTも例外ではない――という整理自体は妥当。今回の価値は、その“脆さ”を三次元（タスク種、長さ、フォーマット）で定量化するための統制環境を用意したところにある。
ChatGPT:
ChatGPTは、質問された言語に応じてその言語の学習データや文脈に基づいて応答を生成します。たとえば、あなたが英語で質問すれば、英語の文法、語彙、文脈、スタイルに基づいた知識や表現が使われます。つまり、英語で質問すれば、英語の学習データが応答の主な根拠になります。
逆に、日本語で質問すれば、日本語の学習データが主に使われます。
質問の内容が同じでも、使用する言語によって微妙に異なるニュアンスや表現の違いが生じることがあります。
ChatGPT:
その場合、質問の内容理解には英語の学習データが主に使われ、回答の生成には日本語の学習データが使われます。質問と言語指定の両方を考慮して処理されるため、回答の内容は英語での質問に基づきつつ、日本語として自然な形になるよう生成されます。
ChatGPT:
正確な言語別の学習データの分量は公開されておらず、OpenAI もその詳細を明示していないため、厳密なランキングを提示することはできません。
ただし、一般的な情報と言語のインターネット上の出現頻度に基づいて、おおよその推定として、学習データの規模が大きいと考えられる言語を以下に示します（順序は推定の精度が高い順）：
1.英語 (English) – 圧倒的に最大。インターネット上のコンテンツ量が非常に多く、技術文書、書籍、記事、会話データなどあらゆる形式で豊富。
2.中国語 (Chinese - 主に簡体字) –特にニュース、SNS、技術関連の情報などで多く使われている。
3.スペイン語 (Spanish) –母語話者が多く、多数の国で使われており、多様な分野のデータが豊富。
4.フランス語 (French) –国際的に広く使われており、公的文書・教育資料が多い。
5.ドイツ語 (German) –技術文書、学術論文、ニュース記事などで多く出現。
6.ロシア語 (Russian) –地域的には広範囲で使われ、フォーラムや技術資料も豊富。
7.ポルトガル語 (Portuguese) – 主にブラジルの影響でデータ量が多い。
8.日本語 (Japanese) –インターネット上の情報は多いが、英語に比べると限定的。学習データにはウェブ、書籍、Wikipedia、日本語SNSなどが含まれると考えられる。
9.アラビア語 (Arabic) –地域的に広く使われており、ニュースや宗教関連の資料が多い。
10.イタリア語 (Italian) –ヨーロッパの中では比較的使用頻度が高い。
これはあくまで一般的なインターネット上の言語分布と学習への影響をもとにした推定であり、正確なデータ量の比較ではありません。
元記事にジロ・デ・イタリア見ろってブコメ付いてるけど選手もチームも知らないカタギにレースデーが21日もあるグランツール追わせるのは無理だって…。
クラシックシーズンの4月なんだし今週末と来週末に丁度ワンデーレース最高峰のモニュメントが二連続であるので見ようぜ。
どちらも今世代最強ポガチャルと今シーズン絶好調のファンデルプールも出るよ。
ここ数年で急激にレース内容とカバレッジが充実しつつある女子のレースもありますよ。
4/6(日):ロンド・ファン・フラーンデレン
男子：https://www.procyclingstats.com/race/ronde-van-vlaanderen/2025/overview
女子：https://www.procyclingstats.com/race/ronde-van-vlaanderen-we/2025/overview
男子：https://www.procyclingstats.com/race/paris-roubaix/2025/overview
女子：https://www.procyclingstats.com/race/paris-roubaix-we/2025/overview
ヨーロッパのレースの日本でのライブ放送開始時間は大体18-20時くらいからで終わりは23-25時くらいになることが多いです。
同日に女子のレースがある場合は男子よりちょい早めに始まって早く終わる（距離も短い）ので、大体女子のレースが終わる頃に男子のレースが盛り上がる区間に入る感じです。
上のリンクのPro Cycling Statsというサイトでライブでレース状況を確認できるので頃合いを見ながらライブ放送を見始めるのもおすすめです。
モニュメントは距離がクソ長くて最初から見るのはきついんで終盤100kmくらい（ゴールから2時間半弱前）をながら見するのがいいかと思われます。
J-SPORTSに未加入の人はSBS（オーストラリアの公共放送、無料だが要VPN）で観るのがいいですよ…。
私はPM。要件決め、設計などは得意だが、細かい技術的な部分はよくわかっていない。
チームリーダーB：経験豊富。全体設計もできて、コーディング速い。顧客折衝もできる。
新人C：経験浅い。コーディング遅め。devopsやプログラム言語についての知識がある。こだわりが強い。SNSでもいろいろ発信。
私は板挟み。
チームリーダーBは頼りになる。新人Cも最新の技術的な動向を追っていて、いろいろ知っていて関心する。いわゆるベストプラクティスというのは新人Cが提案するやり方なのかな、と思う
たとえば、クラス設計はインターフェースを用いてもっと疎結合にコードを組むべきだとか、テストコードのカバレッジをもっと上げないととか、言ってることはもっともだと感じる。
チームリーダーBはそういった細かいところにわりと無頓着なのかもしれない。ずっとやってきたやり方に固執してる部分もあるだろう。
私が若かったころは先輩のやり方は絶対だったため、こういった揉め事は少なかったように思うが、
最近は新人も学生時代にネットで多くを学んでいるため、知識が豊富で理論武装もすごいため、先輩が言い負かされてしまうケースも多い。
私の意見としてはBもCも良い部分があるため、どちらの意見も採用したいところだが、相性がよくない。
BはCのやり方だと、他のメンバー（DやE）の面倒もBが見ることになり、自分の負担が増えると言う。
ただ、保守性の高いプロダクトにしておかないと、長い目で見たときにあとあとキツくなってくる気もする。
あと、CはCで時間を掛けてばっちりテストコードを書いてるはずだが、経験が浅いせいか、テスト環境にデプロイさせると、かなりバグを発生させている。。
どうしたらよいだろう。
ツッコミを入れておくと、既にROGDは「是非の分かれる」というより「まともな」研究レベルには到底達していない存在なので、肯定的に取り上げる時点でどういう偏見が背後にあるかを示す存在になっている。
その翻訳してる元でも"whichitselfwas subject to censorship efforts which, whatever the merits of the study, were scientifically deplorable."だけど、これは実際
https://link.springer.com/article/10.1007/s10508-019-1453-2
などで網羅的に指摘されている通り、調査手法の最初から問題外なレベルであって、あまりにもdeplorableな「研究」。
また、ROGDを引いてシュライアーが主張している感染による急拡大は、調査自体がないが、間接的証拠からは実際にはそもそも起きていない可能性が高いことと、
男女比の変化などはカバレッジの改善でほぼ説明できることを解説しているのがこちら。
https://sciencebasedmedicine.org/the-science-of-transgender-treatment/
ただ、その翻訳元（Dr C.J.Ferguson）が懸念している点である、
GD-ASDの併発が稀でない可能性が示唆するGDに対する予期せぬ過剰介入については、
まだ治療ガイドラインに反映されているとは言いがたく、さらなる研究が必要だが、
それについてあまりにも反応が極端ゆえに研究が進まないのでは、というのはあるし、
実質的な検閲によってそれがさらに阻害されるという可能性もその通りではあるけど、
"thenegativereactionithas garnered in the trans communityis entirely understandable. "
と書いてるように、このフォビア全開な内容を価値があるとするのは、それはそれで傲慢でしょってのもある。
学術的価値を優先するならフォビアを抜くのは造作もないはずなんだから。
とはいえ、抗議だけで差し止められるようになればそれは研究への間接的な検閲というのもその通りだから、懸念するのもわかるんだよね。
https://doi.org/10.1007/s10508-014-0285-3
※性差の研究でよく扱われるCRMP4がASDに関係している可能性を示した論文もあるので、
視床下部をターゲットにした非定型な遺伝子発現が場合によっては両方に影響するという仮説は立てられる。
ASDは元となる遺伝子異常があまりにも多岐にわたるもので、様々な原因が同じような症状を呈するために一つのスペクトラムとして扱ってるようなものなので、いつか個々の原因に分解できるようになればどれが原因ならば併発するかは分かるようになるだろう。その時はまた新たな社会的問題になるだろうけど。
この期間に、様々なプロジェクトに関わり、多くのことを学びました。
今回は、私が経験した技術的な話を中心に、はてなでの仕事について振り返りたいと思います。
はてなでは、主にRuby on Railsを使ってWebアプリケーションを開発していました。
はてなブログやはてなブックマークなどの有名なサービスはもちろん、社内向けのツールや新規事業のプロトタイプもRailsで作っていました。
Railsは、高速に開発できるというメリットがありますが、それと同時にコードの品質やパフォーマンスにも気を配る必要があります。
私は、テストやリファクタリング、コードレビューなどの技術的なプラクティスを積極的に取り入れることで、Railsの開発をより効率的で安全に行う方法を学びました。
例えば、私が担当したプロジェクトでは、RSpecやRuboCopといったツールを使ってテストカバレッジやコード規約をチェックし、GitHub ActionsやCircleCIといったサービスを使って自動化しました。
また、Pull RequestやPair Programmingといった方法を使ってコードのレビューを行い、バグや改善点を見つけたり、知識やノウハウを共有したりしました。
また、はてなでは、AWSやGCPなどのクラウドサービスを活用してインフラを構築していました。
私は、DockerやKubernetes、Terraformなどのツールを使って、コンテナ化やオーケストレーション、インフラストラクチャ・アズ・コードなどの技術を実践しました。
これらの技術は、開発環境と本番環境の差異を減らし、デプロイやスケーリングを容易にするという利点がありますが、それと同時に複雑さやトラブルシューティングの難しさも増します。
私は、モニタリングやロギング、アラートなどの技術的な仕組みを整備することで、インフラの運用をより安定的で信頼性の高いものにする方法を学びました。
例えば、私が関わったプロジェクトでは、DatadogやCloudWatchといったサービスを使ってシステムの状態やパフォーマンスを監視し、SlackやPagerDutyといったサービスを使って異常や警告を通知しました。
また、ElasticsearchやFluentdといったツールを使ってログの収集や分析を行い、原因究明や改善策の検討に役立てました。
## チームでの協働
はてなでエンジニアとして働くことで、私は多くの技術的なスキルや知識を身につけることができました。
しかし、それ以上に大切だったのは、チームで協力して問題を解決することでした。
はてなでは、エンジニアだけでなくデザイナーやプロダクトマネージャーなどの他職種とも連携してプロジェクトを進めることが多かったです。
私は、コミュニケーションやフィードバック、ドキュメンテーションなどの技術的ではないスキルも重要だと感じました。
私は、自分の意見や提案を積極的に発信することで、プロダクトやサービスの品質や価値を高める方法を学びました。
例えば、私が参加したプロジェクトでは、SlackやZoomといったツールを使って日常的に情報交換や相談を行い、BacklogやJiraといったツールを使ってタスク管理や進捗報告を行いました。
また、FigmaやMiroといったツールを使ってデザインやアイデアの共有やフィードバックを行いました。
私は、はてなでエンジニアとして働くことがとても楽しく充実していました。
しかし、私は自分のキャリアについて考える中で、新しい挑戦をしたいという気持ちが強くなりました。
私は、自分の興味や関心のある分野にもっと深く没頭したいと思いました。
## おわりに
彼らに感謝する気持ちを込めて、このエントリーを書き終えたいと思います。
全ての男の遺伝情報は，全ての男の全ての遺伝情報とは異なります．
技術的な話で恐縮ですが，父親を判別するのが目的ならば，全ゲノムを解析する必要はなく，ユニークな部分だけ解析すればよいです．
バーコーディング技術と超並列シーケンサーを用いれば，100万円で1000万人分くらい解析できてしまいます．この計算ではカバレッジ=3強ですので，大分手抜きなのですが，もしも容疑者が複数名になってしまった場合でも再解析すればよいので，実用上問題ないはずです．
サンプル採取はコストがかかりそうですが，新型コロナウイルスのワクチン注射やPCR検査の実績を見れば物理的に無理ってことは全くないですね．
それでデータ量は数百GBってところでしょうか．なんせ肝心要の部分だけなら一人につき56ビットですので，1億人でも56ギガビット，つまり8GBでお釣りが来ます．
つうわけで技術的には可能です．ただ，本番データを落っことしたりすると厄介ですので，そんなデータベースは当分作らないで欲しいと思っちゃいますが･･･
転職歴としては1社目は新卒で入った地元の零細受託Web制作会社→4年前くらいに転職し現在自社サービス企業に勤務中。
ちなみにまだ内定は0件。
コロナを機にフルリモート案件が増えたのと、リーダー経験とか積むにつれて市場価値と今の職場が合わなくなってきたのがあるのと、
今の年収だと婚活で戦うのはかなりきついということを実感したので動き出すことに。現年収は400万ちょっとくらい。
専門卒で経験はPHP/JS中心だから経験してきた技術スタックや学歴的にはあんまり上位狙えるようなアレじゃないんけど今回は心が折れるまでは初年度年収600万を目指すことに。
現職でのリーダー経験と、Saasを立ち上げから設計・開発全部8割型自分で進めて競合と戦えるサービスに成長させた経験とか、ゼロイチで既存案件をDDDに移行したりテスト駆動体制を導入したりとか、まあまあ個人開発もやってますよとかその辺をアピールポイントとして戦うことに。
肌感覚としては「500万までは余裕だけど600万はきつい」だわ。
まず某転職サイトに応募すると早速600万のスカウトが来たユニコーン系ベンチャー。フルリモート。
「貴方のSaas開発経験に魅力を感じ～」とか書いてたから誰でも送ってる風じゃないと思い応募。
結果はなんと書類選考落ち。いや学歴とか職務経歴とかほぼ転職サイトにそのまま書いとったやん。
恐らくだけど選考時にGithubアカウントとかTwitterアカウントを求められたときに仕事用のものはセキュリティ上渡せないとか渋ったのと、
渋々渡した個人用Githubアカウントはオープンソース活動とかはしたことなかったからこれがしょぼいって思われたのかな？って思った
ちなみにこの会社からは書類選考落ち後に各転職サイトから5回くらいスカウトが来てる。
大手っていうわけではないけど割と有名なSaas企業。こっちもスカウト。転職サイトの上の方でよく見る気がする。
結構近しい分野のSaasを立ち上げから関わったことがあるのでこちらを武器に面接へ。1次面接落ち。
面接は割とうまく行ったと思うけどなぁ、って思ったけどやっぱりフルリモートでこの給与帯の休日は倍率半端なさそうだからちょっと良いくらいだと全然落ちるんだなと実感。
立ち上げから3年も経っていないベンチャー、ただし既に利益率は割と凄い感じで業界的にも硬そうだから応募。
カジュアル面談のときにCTOに是非応募してほしいって直接言われた。
1次の技術面接のレベルがたけぇ。○○の設計思想の内容だとかDIコンテナとかReactの状態管理用ライブラリの運用とかの質問をクイズ形式っぽく質問される。
割とうまく答えられたと思ったけど1次面接落ち。
有名地元に拠点がある東証一部上場の自社サービス企業。600万の求人と450万の求人で分かれてて600万の方で応募したら書類選考で「600万は厳しいけど450万なら良いですよ～」って言われてる状態。
やっぱ相場観的にはそうだよなぁって思った。
今週1次選考だけど受かっても年収交渉時に450万しかもらえないなら辞退しちゃうかも。
有名医療系ベンチャーと車業界系のSaas。カジュアル面談の要請出すも音沙汰なし。
別の転職サイトで確認すると応募条件大卒以上って書いてたから多分それが原因。ちゃんと書いとけや。実質書類落ち。
少人数の建築系ベンチャー。HPの情報量も少なく恐らく資金調達のフェーズでは？って感じの企業。
なんとなく社長から与沢翼の匂いがする。まだマネタイズまで行けてないのに何百億とか何兆とかやたらでかい数字を言いたがる感じ。
技術スタックに対して年収が高すぎるのが逆に怪しい感じがする。
一応最終選考まで残ってるが、通ったとして行くべきかは悩みどころ……
スカウト来て応募。かなり好感触だが求人票と実態の下限年収に相違あって思ってた年収より100万くらい下がりそう。
去年末くらいから始めた転職活動。今週も面接面接面談面談面接。
自分の市場価値みたいなところは良くも悪くも痛感する。500万までのスカウトはよく来るけど600万になるとやっぱなかなかこない。これが相場観なんだろうなって感じ。
「テックリード」とか「シニア」とかのスカウトは全く来ないからまだそういうレベルではないんだなぁって。
「誰もが知る有名企業で年収600万」は多分俺のスペックだと無理ゲーで、あとはいかに穴場のベンチャー狙えるかっていうところにかかってる感じ。
それはそれで安定捨てて市場価値より高い会社に勤める感じになるわけだし将来トータルで考えるとそれはそれで大丈夫なの？って感じもある。
でも専門卒じゃ20代現年収600万くらい武器ないと婚活じゃ戦えないしなぁとも……はよ彼女作ってこの悩みから開放されたい……
エントリーする度にそこで働く未来の自分を思い浮かべるのに祈られた瞬間に全部がなかったことになるの辛い
あとカジュアル面談受けまくってるけど、これが割と面白かったりする。
「こんな有名企業だけどQAは俺がリーダーやってる案件のがカバレッジ率とかしっかりしてるんだー、バグったら人が死ぬタイプのシステムじゃないし逆に今の運用が過剰品質すぎなのかなぁ」「LeSSって開発手法あるんだー」「前職も現職もSelenium導入って微妙な感じになってるけどこのMablってテストツールだと割と良い感じかも」「今の職場みたいに運用フェーズのエンジニア部署でKPI設定を半期ごとに設定するのは粒度がでかすぎるよなぁ、この会社みたいに1ヶ月周期とかで設定した方がよさそう」「ワーカーサーバーの悩むポイントはどこも同じだなぁ、でもやっぱGoだとPHPよりも並列処理強いんだなぁ」
他の会社の運用とか技術スタックの話を深堀りして質問しまくれる機会とかなかなかないから、落ちたは落ちたなりに吸収できるものはある気がする。
あと社交辞令かもしれんけど「いやその経験と技術力で今の年収はどう考えてもおかしいっすよ」とか結構言ってくれるの嬉しい。
今地方の自社サービス開発企業に勤めててその中ではテックリード的な立場。
Saasのシステムを設計フェーズから1から構築したこともあるし、
他にもレガシー目なサービスにDDDやクリーンアーキテクチャ的思想を導入したりTDDの構築と運用へあたっての体制構築や教育を主導したりとか
メンバーのスキルに偏りがある状態でも品質維持するための体制をなんとか作ったりとか
小さい企業ながら割と経験詰めたし今なら転職とか余裕だよなーって思ったがなかなかうまくいかない。
今のところ3社受けて全部1次面接落ち。受けたのは転職サイトのトップページに一番大きく載ってるような人気企業だから倍率は結構高い気はする。
今のところフルリモートで初年度年収550万～600万くらいを目指してる。多分500万くらいまで水準下げれば求人めっちゃ増えるし余裕な気はする。
あっちからスカウトが来て、競合ではないけど似たようなサービスを俺も構築した経験があったから
御社の製品の○○機能(リリースされたらプレスリリース打つくらいの機能)と似たようなものを営業にほしいと言われてから2日後にはテストカバレッジ率100%の状態でリリースまで持っていきましたとか、
当時はリソース足りず自分一人でほぼ全部対応してたけど爆速でリリースサイクル回して1年で機能数的にも競合製品に負けないくらいまで成長させましたとかこれ以上ないくらいアピールしたよ。
なーにが行けなかったんだろう。やっぱコミュ障なのが影響してんのかなぁ。「えーっとまあ」とか「なんか」「えーーそうですね…」みたいなのが多いのは自覚してる。
フルリモートで給与も高水準だと倍率高いから、もしかしたら20人中の1人や2人採用で第3位だったとかかもしれない。
何をどう変えたらいかなぁ。
転職指南書に書いているようなHPの企業理念読んで面接官が喜びそうなことを事前に作文して頭に叩き込んでおくみたいなことはやりたくないんだよね。
俺会社じゃ面接官する側だけどポートフォリオとか職務経歴しょぼいのに口だけ凄いこといってると
「ああ、この人面接官喜ばすための言葉を事前に作文してきたんだろうなーーー」「この人は”面接が”上手い人なんだな」とかやっぱ内心思っちゃうし
まあ応募して落とされて凹んでまた応募してを繰り返すしかないのかな。
今ちょうど対処法に頭を悩ませてる、ここまでの人は正直人生初。
バグが多い、レビューの指摘数が多い、投げた仕事がわからない・できないで投げ帰ってくる、基本的なアーキテクチャが理解できてない、成果物が出てくるのが遅い
ざっくりとこんな感じ。
今のところこんな感じで対処してる。
正直「こんなに時間をかけて詳細に指示書いてこんな数の指摘を説明しなきゃいけないのだったらその人に振らずに俺が1から対応した方が数倍以上早いしこれは一体何を生み出している時間なんだろう」みたいなことを自問自答しながら作業してる状態。
これが新入社員とかだったら多分立ち回り方も結構変わると思う、できなくてもそれは経験不足から来るものだし、多分『教育』って形で結構時間かけて丁寧にペアプロして習熟度を上げてもらう感じかな。
2年目くらいでまだ戦力になれてない社員だったら多分3年目とか4年目くらいの誰かしら(できれば数人)と相談して教育係として俺との間に誰かを挟んでコミュニケーション上の距離を置いて負担をチーム内で分散する形にすると思う。
ただ経験年数長いで今更新人教育みたいなことをするとプライドを傷つけかねないし、ぶっちゃけこの経験年数でこれなら教育にパワーかけても効果薄そうっていうのもある。
あと単純に社内リソースが足りなくて俺がなんとかしなきゃいけない状態。
これどうすっかなぁ。プログラミングとはまた違う頭使うぞ。
