Lycolog

このブログでは過去記事の更新を割とよくするし、個人的にタグなどを基に過去記事を引っかけて調べ物をすることがあるのだが、それならMECEな構成にしやすいWikiのほうがよく、ブログである必要はないのではないか？という疑問が、ふと浮かんだが、やっぱりブログでいいなと思った話。

確かにWikiにすれば階層構造にして、インデックスを張ることでブログと比べてMECE性を高めることができそうだし、一般的には履歴管理もできる。adiaryには履歴管理機能がないため、履歴管理ができるのはうれしい。

しかし逆説的に言えばブログはMECEでないことが売りではないかとも思った。Amazonの怪しい中華製品ではないが2026年版、2025年版だとか、Ubuntu 24, Ubuntu 22といった記事はスナップショット、つまり年輪として機能する。

Wikiの履歴で過去を探索するのは一般的に検索機能がなく、追いづらいし、見づらい。そう考えたときにMECEでないからこそ、過去のログとして機能させやすいのはブログではないかと思った。

もちろん、その代償として似た記事が多いと過去ログが追いづらいとか、情報が分散して追いづらい、流れる、ストック型ではなくフロー型に近いなどの欠点もある。

別にWikiでも2026年版、2025年版だとか、Ubuntu 24, Ubuntu 22といった記事は作れるので、Wikiでもいい気がするが、今のところはブログでいいかなと思った。そもそも編集者が一人しかいないサイトでWikiを採用している例は私の知る限り少ないし、標準化などを考慮の外に追いやったフリースタイルでやるのは構造に縛られづらいブログは最も向いているだろう。Wikiはツリー構造を変えようと思たっと気に大変だが、ブログにはそもそもツリーがない。

というわけで、深く考えるものでもないし、ブログでいいかというところに落ち着いた。

あとがき

Mastodonのほうもブログに近い運用をしており、それなりにタグを張って過去を見れるように管理していて、フロー性が高いものはMastodon、ストック性が高いものはブログという感じで書く先を分けていたりする。結果として、Mastodonで書いたことをブログにまとめてあげていることもしばしばあるので、この運用はうまく回っていると思う。

例えばMastodonは2025年8月20日に開始し、既に8,093投稿もあるが、このブログは2019年1月12日から起算して626記事^[1]しかない。

これはMastodonだと開始日から今日までの一日平均の投稿数が33.30だが、ブログだと0.23になる。投稿頻度が昔と今で異なるので、ブログもMastodon同様に2025年8月20日から起算すると0.51投稿にまで増えるが、それでも投稿頻度には65.29倍ほどの差がある。

このことから、このブログはMastodonと比べたときに65.29倍ほどストック性が高いと言えるかもしれない。

アニメイト通販で取り寄せ商品を複数注文した時の挙動がどうなってるのかをアニメイトサイドに確認したので、そのメモ。

個人的に気になったのは次の部分だ。

1. 複数商品を取り寄せしたとき、すべてが一堂にそろったタイミングで在庫が確保されるのか？
2. それぞれの商品が揃ったときに在庫が確保され、全て揃った時点で発送されるのか？

要するに在庫が引き当て状態になるのか、ならないのかが気になっていた。

1のケースの場合、ABCと三つ注文した時に、AとBは入荷されたが、Cが入荷されたときにAとBの在庫が尽きていると発送されず、次にAは入荷されたが、Cの在庫がなくなったとすると、一生、何一つ発送されないことになる。

しかし2のケースであれば、既に在庫は引き当てられているため、AとBは入荷されたが、Cがなくても、AとBは確保済みと考えることができる。つまりCが入荷された時点ですべてが揃い発送されるわけだ。

個人的には2であってほしかったが、アニメイト通販のサイトには明記されていなかったので聞いて見たところ、2のパターンであった。

1のパターンのほうが売る側としては在庫リスクがなくなり、売り上げもすぐ入るので理想的だが、買う側としては致命的であるから、本当に良かったと思う。

手違いで機微のある情報を含んだものを郵便に出してしまったので郵便の取り戻し請求をやってみて、実際に戻ってきた記録。

東京宛てに定型封筒を出し、13時前にポストに入れて問題に気づいたのが18時ごろ、調べたところ出した郵便物は取り戻せるとあった。

神戸から東京は三日かかるらしいので請求を出せば取り戻せるはずだと思った私は仕事が終わったら取り戻り請求をしようと決意し、仕事を終え中央郵便局にダッシュして到着したのが19:45。

ゆうゆう窓口で郵便物を取り戻したいといったところ、すごく高いですよ〜？辞めたほうがいいですよ〜？戻ってくる保証もないですからねぇ〜？ってめっちゃ言われたが、それでもいいなら750円払えば出来ると言われ支払うことにした。言うほど高くなかった。

取り戻し申請には専用の用紙があり、これに記入することで手続きできた。

あれだけある郵便物の山から果たして探し出せるのか？仕分け作業で毎回チェックが入れば行けるのか…？配達時にチェックしているのか…？などと考え、少なくとも往復で六日は掛かるだろうというので待つことにした。

その最中長期出張が入り、家に戻ってきたら無事に届いていたので、いつ戻ってきたかは不明だが、消印的に六日だろう。これは神戸→豊島が三日だからだ。

そんなこんな無事に戻ってきてよかった。

しかも取り戻し申請の用紙と、実際の郵便物で記載事項が異なっていたのに戻ってきたのでより驚いた。

申請用紙には送り先住所を「東京都豊島区ほげほげ～」宛名を「ふがふが」、送り元住所を「兵庫県神戸市中央区～1-2-3 ぴよハイツ123」のように書いたが、実際の郵便物には「豊島区ほげほげ～」宛名を「ふがふが ふにふに御中」、送り元住所を「神戸市中央区～1-2-3 ぴよハイツ」のように書いていた。申請用紙を出した後に実際と同じほうがよかったかだろうかと少し悩んだ。今思えば聞けばよかったなとも思った。ちなみに郵便物側に部屋番号が欠落していることにはこの時気づいてなかった。

結果として申請用紙より少ない情報しか書いてなかったのに、ちゃんと戻ってきた。これは見方によってはセキュリティホールにもなりえるものの驚きである。その証拠に戻ってきた郵便物の裏側には鉛筆で部屋番号が足されていた（丸で囲われている部分）

郵便の仕分けは昔（30年以上前）見たことがあり、基本はOCRで処理していたはずだが、ここまで欠陥まみれの情報を救い上げられるということは取り戻し申請DBに問い合わせて、複数パターンでのパターンマッチをしていたりするのだろうか？と少し思った。

郵便配達員を観察したが、配達のタイミングでは特に何も見てなさそうだったので、恐らく配達員の手に渡るともう戻ってこないのだとは思うが、これだけ申込内容と実物の郵便物に相違のある情報で郵便物が戻ってくるのであれば、局に到着する前ならば戻ってくる可能性は高いと感じた。

まとめ

• 750円払うと郵便物の取り戻し請求ができる
• ゆうゆう窓口で申請できる
• 恐らく相手局の仕分けに入る前に請求すれば戻ってくる
• 郵便物に書いてある情報と、請求申請書の内容に多少相違があっても戻ってくる
• 送り主の部屋番号が記載されてない場合、書いてくれることがある

C:\Users\hoge\.ssh以外の場所に秘密鍵を配置し、その秘密鍵を使ってWindows組み込みのSSHを利用して、SSH接続を行うと以下のようなエラーが出るので、それを回避する方法。

[00:11:24.734] Opening exec server for ssh-remote+hoge.example.com
[00:11:24.934] Initizing new exec server for ssh-remote+hoge.example.com
[00:11:24.934] Using commit id "xxxxx" and quality "stable" for server
[00:11:24.934] Extensions to install:
[00:11:24.939] Install and start server if needed
[00:11:24.963] Opening exec server for ssh-remote+hoge.example.com
[00:11:24.967] Running script with connection command: "C:\WINDOWS\System32\OpenSSH\ssh.exe" -T -D 65374 "hoge.example.com" sh
[00:11:24.968] Generated SSH command: 'type "C:\Users\hoge\AppData\Local\Temp\vscode-linux-multi-line-command-hoge.example.com-281649447.sh" | "C:\WINDOWS\System32\OpenSSH\ssh.exe" -T -D 65374 "hoge.example.com" sh'
[00:11:24.968] Using connect timeout of 17 seconds
[00:11:24.968] Terminal shell path: C:\WINDOWS\System32\cmd.exe
[00:11:25.179] >
[00:11:25.179] Got some output, clearing connection timeout
[00:11:25.199] >
[00:11:26.323] >
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> Permissions for 'C:\\path\\to\\hoge.sec' are too open.
> It is required that your private key files are NOT accessible by others.
> This private key will be ignored.
> Load key "C:\\path\\to\\hoge.sec": bad permissions
> miyashiro@hoge.example.com: Permission denied (publickey).
> プロセスが、存在しないパイプに書き込もうとしました。
[00:11:26.632] "install" terminal command done
[00:11:26.632] Install terminal quit with output: プロセスが、存在しないパイプに書き込もうとしました。
[00:11:26.632] Received install output: プロセスが、存在しないパイプに書き込もうとしました。
[00:11:26.633] WARN: $PLATFORM is undefined in installation script output.  Errors may be dropped.
[00:11:26.633] Failed to parse remote port from server output
[00:11:26.633] Exec server for ssh-remote+hoge.example.com failed: Error
[00:11:26.633] Existing exec server for ssh-remote+hoge.example.com errored (Error)
[00:11:26.633] Initizing new exec server for ssh-remote+hoge.example.com
[00:11:26.634] Error opening exec server for ssh-remote+hoge.example.com: Error
[00:11:26.634] No hints found in the recent session.

やり方

以下のコマンドで秘密鍵の所有権を自分だけに変更するといけるようになる。

icacls "C:\path\to\hoge.sec" /inheritance:r /grant:r "%USERNAME%:F"

icaclsはファイルの所有権を変更するコマンドで、/inheritance:rで親フォルダからの継承を無効にし、指定したファイルに対する親フォルダから継承した権限を削除し、/grant:r "%USERNAME%:F"でファイルに対する権限を削除し、現ユーザーのフルアクセス権で上書きしている（要するに既存のアクセス権を、現ユーザーのフルアクセス権で置換しているのだと思う）

恐らくLinuxのOpenSSH同様に、WindowsのOpenSSHも鍵をユーザー以外が見れるとだめなのだろう。

転職時に複数内定を得た場合の考え方についてで104社受けた末に転職できたということを書いたが、今回はそこに至るまでに何をしたかについて書いていく。

かなり純度の高い本音が含まれる赤裸々日記なので、かなり不遜なことも書いている。

大まかな転職活動期間は書類作成から起算すると、二年半程度である。

参考までに今回の転職は四回目の転職となる。

書類作成編

私は職務経歴書の作成をサボっていたし、職務経歴書の内容もかなり稚拙で、読みづらく、意味不明であると考えていた。

当時の職務経歴書はWordで制作していたもののMarkdownの影響を強く受けており、文章じみており、一目でわかりづらい欠点があった。そこでまず職務経歴書のリライトを行うことにした。

まずやったこととしてはWordで表組を作り、そこに書くことにした。これはちょうど上図のような感じだ。これによって視認性は上がったと考えている。

本文についても乱雑な感じになっていたので、ChatGPTとGemini、Claude Opusをフル動員していい感じの文章を作ってもらい、セルフコンペしながら、自分の言葉になるように清書した。その中で抜け漏れがあれば追記修正するなども行い、内容の品質を上げていった。

私はSESが長く、何十ものプロジェクトに参画していることもあり、とにかく職務経歴書が長いのだが、そこは採用担当者や転職媒体のLLMが読めるように職務経歴書を組むことで何とかしている。実際私の職務経歴書はCtrl+A→Ctrl+Cで全文コピーしてLLMに貼り付ければ、Wordを解さないLLMでも意味が通るように作ってある。

しかし工数は膨大で、職務経歴書のリライトだけで半年かかっている。これはやる気が起きなかったことが多分にある。何せ膨大な文章の誤字脱字チェック、文章として意味を成しているかどうかの確認などの退屈な作業で大分苦労した。いわゆる不毛な作業みたいなやつである。叶うことならもう一生書き直したくない量の文章である。

相談編

そして書類を作りりきったところで、私の課題を見つける必要があるかもしれないとキャリアコーチを頼ってみることにした。特に何の資格も持たないネットでバズってるキャリアコーチに五万も払ったが、驚くほど得られることがなかった。

なんというか、雑談して終わりみたいな…。私の話し方も悪かったのかもしれないが、LLMに話したほうがマシなレベルだった。

余談だが、このキャリアコーチは「特定商取引法に基づく表記」を掲示しておらず、最後までどこの誰か明かしてくれなかったので、違法事業者であった。いやまぁ、わかってて払ったのだが…。

応募編

ここまで足かけ一年かかっている。とにかく前準備が長すぎた。

昨夏、惨敗し、学びを得た82社

まず昨夏、つまり2025年の夏に私は三社の転職エージェントと自己応募を合わせて転職活動していたが、全く上手く行かなかった。

この時は82社受けていたのだが、82社中46社が書類落ち、29社が一次選考落ち、1社が二次選考落ち、2社が最終選考（二次）落ち、4社は辞退だった。

落ちている理由は明白だった。転職エージェントが「うちを使うならこれは全部受けてくれ」というのを受けていたからだ。会社に対して興味もなければ、ポジションにマッチしているとも思えない、そんな会社が大半だった。もちろん下手な鉄砲も数撃てば当たりはするもので、一次選考に進む企業もあったが、面接官がこちらが答えようのない質問をしてくるので答えようがなく、かなりの数落ちた。

逆に二次選考まで来た企業についてはお互いに興味を持ち合えたので最終選考まで進むことができたが、転職エージェントが返事をしなくなりオファー面談が行えな得ず、音信不通になり恐らく終了した。転職エージェントの担当をつついても返事がなかったので諦めた。

辞退した四社については全て兵庫県沿岸部～大阪近郊に所在する会社で、自己応募した企業だったが、WordPressの構築レベルの会社しかなかったため、カジュアル面談で辞退した企業になる。

そんなこんなで昨夏は転職エージェントに振り回され、自分で応募した企業は芳しくないという暗澹たる結果に終わった。

ここで学んだことは、転職エージェントを使うのは私には向いていないということと、面接で上手く受け答えができないシーンが多く、言語化が不十分だったということだ。この失敗から得た学びは、冬の転職活動に生きることになる。

参考までに7月と8月で行った転職活動を記録したカレンダーも貼っておく。黄色い部分が転職活動をしていた箇所だ。ほとんど毎日のように面接やエージェント面談が入っており、酷いときは一日に三度もあり、有給が一瞬で燃え尽きた。

冬、内定を得て転職したが後味は微妙だった

そして時は4ヶ月ほど経ち、2025年の冬から転職活動を再開することにした。

ここで私は夏の転職活動の反省を生かし、転職エージェントは使わないことにした。そこでスカウト・自己応募型を中心にWantedly・OpenWork・Green・Findyの媒体を使うことにした。

結果として22社受けて書類落ち3社、一次選考落ち2社、二次選考落ち1社、三次選考落ち3社、内定4社と、昨夏とは比較にならない好成績を残すことができた。辞退はカジュアル面談7社、一次面接2社だった

まず最も効果があったのは自分で企業を選んだことだ。エージェントが投げてくる企業を言われるがままに受けていると一日に3～4社受ける必要があり、一体何の企業を受けているのかがわからないうえ、募集ポジションを無視して受けていることもざらなので意思疎通ができない。しかし自分で選んで受ける分には共有言語があるであろう企業を受けることができるため、比較的そこへの問題はなくなる。

また、次に生きたのが言語化だ。これはFindyのキャリアカウンセラーと一ヶ月かけてみっちりと対策した。これによってカジュアル面談で聞きたいことを聞き出し、選考でもマインドが合う企業相手であれば違和感のないやり取りができたと強く感じている。勿論、詰まった時や困ったときは事後に再対策を行い、内容を強化していった。これによって深掘りされた時の回答がスムーズにできるようになった。

これによって昨夏は書類・一次の不通過の累計が91.46%だったのが、22.73%と、1/4以下に抑えることができた。最終面接の不通過もポジション不一致と、Windows利用を交渉したものの顧客都合で不可というもので、ネガティブな内容ではなかったのが何よりだ。もう一つは「すさまじい激務で現場が疲弊しているが君は耐えられるか？」的な話を聞いた時に私が露骨に嫌な顔をしたからで、事実上の辞退である。

要するに今回の転職活動では、そもそも入りたくない企業には落ち、入りたい企業からは内定が得られたという意味で、そこまでの話でいうと、かなりの成功だった。

得た内定のうち一件は、そもそも相手先企業が内定承諾書を約束通り出してくれなかったのでたぶん自然消滅した。もう一つは企業としてはよかったのだが、何とも言いづらい懸念があったので、申し訳ないのだが他の企業を見て、その結果次第で入ることにした。身も蓋もない話をすれば滑り止めである。

そしてその最中、一社からいい条件で内定が出た。この会社を以降A社という。しかし私はこのA社の最終面接前にGreenに登録し、万一落ちたときにリカバリーできる企業を探し、とにかくエントリーしまくった。といってもほぼほぼスカウトに返事をしただけではあるが…。

そして結果として、このA社から内定が出たときに、Green経由でかなりい条件の企業からオファーが来て、現在の選考状況を伝えたところ、既にオファー面談前ということで凄い速度で選考を進めてもらえることになった。この会社をB社とする。結果として、A社のオファー面談後、すぐにB社からも内定が出て、すぐさまオファー面談となった。

しかしA社の内定承諾期限はわずか四日しか設定されておらず、B社のオファー面談が終わった時には残り二日しか残っていなかった。私はB社に心が傾いていたのだが、媒体の担当者からA社を強く推される発言をされ、日和ってしまい、十分に検討することもせず、A社に返事をしてしまった。

昨夏と比較して転職活動はおとなしいものとなり、面接は一日一回に抑え、一日に二つ黄色いのがあるのはFindyの面談で、大まかには面接対策や振り返りをしていた。

企業との面接は週2回を心掛けるようにし、同時に並行して進める会社も三社に収まるように調整したため、活動期間も長くなっている。

一日に二回とか、週に三回以上入っているところもあるが、これは基本的にFindy担当との面談か、話を聞いてみるレベルのカジュアル面談で、重いものにならないようにしていた。

ただこのペースでも個社のことをちゃんと覚えきるのは難しく、一社落ちれば次の会社とやっていたり、返事が遅い企業を放置していたら頭の中で混ざったりして、まぁまぁ大変だった。その結果、余裕がなくなり今回のような結果になったところもあると思う。

あとがき

そして、この時の後悔の念と反省として、転職時に複数内定を得た場合の考え方についての記事を書いたのである。

私はもうエージェントと、担当の付く媒体は使わないようにしたいと思ったのであった。もう自分の人生は自分で動かしたいのである。

そして、この記事は私が転職活動をしている中で、ググって引っ掛かる記事が媒体や転職エージェント絡みのアフィリエイト記事かポジショントークばかりで、総じて役に立たなかったので、経験談として誰の役に立てばという思いで書いている。

なお本記事と、転職時に複数内定を得た場合の考え方についての記事の内容には一切LLMを使用せず、完全に自分の文章で記述している。