残業を 当たり前だと 思うなよ・・・2026年09月01日 23時05分32秒

昨日に続いて今日も遅くまで残業を強要させられてうんざりとしている。
それも定時過ぎになって銃弾名問題が発生したとか言い出して、何かと思えば本来なら対象外となるデータを無理矢理に一括処理へ掛けた結果、想定と異なる動作をしたと言い出したから呆れるばかりだ。
もっとも設計者が離任しているので、問題となっているデータが本来なら対象外であるはずと思い出すのに時間が掛かって、不具合かも知れないと言ってしまったのが運の尽きだった。

上記の件とは別に昼頃から意味不明な調査依頼を振られていて、情報が足りないからと詳細な情報を要求してみたら、現状では正常化していると判明する始末だ。
要するに存在しないエラー状態を探し回った挙げ句に、訳が分からないと嘆いていた状況となっていて、無いデータを探しているだから痕ワンするのも当然なのだ。
問題の根底は例によってサーバスペックの不足と旧システムからの移行データにあって、また同じ原因じゃないかと呆れるばかりだ。

そろそろ付き合いきれないと離任したいと要望すべきレベルに達して居て、本格的に嫌気が差してきた今日この頃だ。

振り出しへ 戻るだけだと 説得を2026年09月02日 23時03分36秒

今週は毎日に夜20時以降まで残業させられているので、今日こそ早めに切り上げようと思った矢先に意味不明な問い合わせが来て、何だかんだとやっていたら処理するのに70分ほど掛かってしまった。
頭に血の上った利用者からの問い合わせだから、例外処置を執って早々に状況を解消したいと言っていたのだが、有り得ない話をしていると理解したら溜め息しか出てこなかった。

しかも、状況を調べてみたら例外処置とやらが実現できたとしても、利用停止状態へ巻き戻る条件が整っているので完全に無意味だと判明した。
外部の決済システムが支払方法の無効だとするエラーを返していて、こちらのシステムでどんな細工をしたとしても、外部システムの動作に関与できるはずもなくて、対応した矢先に振り出しへ戻ることが確定していた。

そんなわけで利用者が有り得ないと主張する状況そのもので、素人の発言を真に受けて例外処置なんて検討するものじゃないと、馬鹿げた事例として記録しておいた。

原因が 選定ミスで 確定か・・・2026年09月03日 22時48分23秒

並列処理でデータベースのロック解除待ちが大量発生していて、本来なら数ミリ秒で終わるはずの処理が数十秒も掛かっていたりする。
文字通りの桁違いな遅さとなっていて問題となっているのだけど、単純な処理しかしていないはずなのに何事かと思ったら、予想だにしない仕様が絡んでいることが判明した。

行ロックはトランザクションとして定義された処理群が完結するまで、同じ行へ対する他からの操作を禁止する機能となっていて、同じ行へ対する更新を行うアクションが幾つも重なると、ロック解除待ちが発生する。
今回は1つのアクションに4つのトランザクションが存在する状態になっていると思っていたら、実は大きな1つのトランザクションになっていると判明して驚かされた。

使用しているライブラリの仕様でそうなっているらしく、何とか回避する方法が無いものかと調べてみたけれど、どうにも並列実行するようなシステムに不向きなライブラリのようだった。
こうなってくると対処法が殆どなくなってくるので、大量の行ロックが発生している処理を完全に分離する方向で検討する事となり、何パターンか試しに実装して試してみていた。
久しぶりにプログラマらしい作業をしていると思いつつ、試せそうな施策を3つほど試して報告してから修正方針が確定するまで、のんびりと過ごさせてもらった。

簡単と 思っていたら 泥沼に2026年09月04日 23時23分22秒

今日は比較的に簡単な修正の結合テストが行われたのだけど、何やらエラーが発生して確認したらパラメータ不足だと判明した。
テストデータの作成ミスかと思っていたら、テスト手順の中で実行する修正対象外の機能が問題のパラメータを消していると判明した。
どう考えても消す必要のパラメータであり、手順など考慮しても意味不明な処理だったので既存の不具合と判定できたので、別件の不具合として欠損したパラメータを復元して試験してもらうことになった。

問題の不具合だけど誰にも気付かないで放置されていたようで、めったに使われない機能だからという話もあるけれど、ちゃんと試験をしてほしいものだと呆れるばかりだ。
修正内容は不要な更新処理を省くだけなので、数秒で終わるような不具合だったけれど原因究明に90分ほど掛かっていて、複雑な仕様と読みづらいプロジェクト構成の悪影響を受けた格好となった。

ひとまず原因が究明できたから良かったけれど、鼻歌交じりに終わるはずだった修正が火を噴いたから酷く焦った。
別件の不具合だったので事無きを得たものの、なかなか心臓に悪い時間を過ごす羽目となった。

痒くても 我慢しなけりゃ 駄目だとさ・・・2026年09月05日 21時44分40秒

今日は土曜で気温も低めとなっているので蓄積した疲労を取るためにも遅くまで寝ていたいのだけど、残念ながら常用薬の在庫が切れているので耳鼻科へ通院しなければならない。
診療受付を早めないと待ち時間が長くなる恐れもあって、朝8時に起床して朝食とソシャゲの日課をザックリと片付けて、出掛ける準備が整ったと思ったら9時半を過ぎていた。

この時点で出遅れ気味だったのだけど、混雑具合によって利用可否の変動するネット予約を確認してみたら、受付可能となっちたので診療予約を行ってから移動を開始した。
ネット予約のできる状況となっている時点で長い待ち時間が確定するのだけど、延期する選択肢がないので頑張って自転車を走らせて診療予約を完遂させた。
自分がネット予約を行ってから病院へ到着するまでに20人ほど追加されたようで、90分ほどの時間短縮となったはずだと安堵しながら、待合室で60分ほどスマフォを弄って過ごしていた。

診察で最近に頻発する耳の痒みについて、カビが原因となっているようで下手に触ると悪化する一方なので、我慢して堪えきれないなら洗浄などの処置を受けに来るよう言われた。
仕事のストレスと睡眠不足の影響が大きく出ていると想像できるし、頻繁に診察を受けに来られる余裕もないで溜め息しか出ないけれど、どうにか通院頻度を上げる工夫が必要そうだ。
それと耳掻きを我慢する精神力も大切なのだけど、集中すべき場面で耳の痒みが出てくると非常に煩わしくて、我慢とかそういう話でなくなるので非常に困りどころだ。

高そうな 傘は捨てずに 保管され2026年09月06日 23時46分11秒

昨日に外出時の玄関で念のため雨具を持っていこうとしたら、傘立てに自分の傘が入っていなくて何事かと焦ったのだけど、先週も持ち出したはずだけど帰宅時に戻した記憶がなかった。
記憶を更に遡ってみると本屋へ立ち寄った際に傘立ての脇に置いて、帰り際に回収した覚えがないことまで行き当たった。

入店時の傘は自転車のハンドルへ引っ掛けていて、駐輪スペースに屋根のない場合だけ持ち込むか傘立てに置いていて、ここ最近で行く店だと本屋以外は全て屋根付きなだったりする。
そのため、手元から傘の離れる場面が本屋しかないこともあって、入店時に傘の置き忘れがなかったかと聞いてみたら、骨の本数が多いなどの特徴的だったおかげで改修して保管してくれていた。

高そうな傘だったからと保管してくれていた節もあって、風の強い地域だから丈夫さを重視して選んでいる事と、間違えて持ち出したと言わせない特徴で選んだ甲斐があった。
店として簡単に処分対象とし辛かったと聞いたので、狙ったわけでないけれど次の買い換え時に参考としようと思った。

不具合に 見える実装 周知せず・・・2026年09月07日 22時52分23秒

試験要員の不足深刻さを増しているのだけど、ただでさえ人数の少ない我がチームから引き抜こうとしないでもらいたい。
それに脾機能とされたメンバーしか知らない機能もあるので、そこでトラブルが発生した時に対応できなくなるから、致命傷となりうることを理解してもらいたい。

そんな事を言っていた今日だけど、試験が上手く行かないと言われたので見てみたらテストデータの不備が見つかり、次に予想外の動きをしたと言われて調べてみれば、最近に機能が改修された結果で不具合でなかった。
もっともデザインを変更していないから紛らわしい事この上ないのだが、設計と試験で指摘が入っていないなら合意されている事になるので、こちらからとやかく言うような話でもない。

強いて言えば、変な動作に見えるけれど仕様であるとしっかりと周知してもらわないと、今回のような事態となるので勘弁してもらいたかった。
もっとも改善なんて見込めない炎上プロジェクトなので、1日でも早く離任したいという希望以外に何もない。

限界を 越えた作業は お断り2026年09月08日 23時05分02秒

当たり前のように残業を強要してくるので嫌気の差している今日この頃、自社の事業部長へ一報を入れて「協力する」との言葉をもらったから、連日の残業も許容するとの言質を取ったかのような振る舞いを見せている。
恐らくは「出来る範囲での協力」であって、過労を前提とした業務を許可するなんて言っていないはずなのだが、何かの免罪符でも手に入れたと思い込んでいる節がある。

こんな調子で限界を超えた業務の連続となって、失明までのカウントダウンが一気に進む恐れもあって、そうなった場合の責任を取ってくれるのだろうか。
失明した不利益に見合う芭蕉を得られるわけがないので、責任を取ると言われても現状も今以上の業務もお断りなのだが、責任も取らずにリスクだけ背負わされる状況は論外と言える。

当初の設計になかった並列処理をいきなり実装して、その弊害で数々の不具合が発生している状況をこちらのせいにされても困るし、無理だと説得する努力をしないで開発者へ負荷だけ掛けてくるんじゃない。
サービスインできる状態でないのに押し切ったのだから、不具合が出て当然と諦める心を持てなってもらわねば困る。

横槍で 邪魔をするなと 泣き顔に2026年09月09日 22時44分44秒

軽く言われた機能が面倒な仕様となっていて、修正方針が定められなくて頭を抱えている状況なのに、ログ解析など押し付けられて手を付けられずに四苦八苦していた。
色々と検討した結果として、処理ルートによって設定と未設定のばらつきが出る状態が問題なので、設定済みに統一されるよう整理した上で機能制限も掛ける方針とした。
それ以外の方法では修正できないのだから仕方ないし、他で似た処理を実装している部分も機能限定を行っているので問題ないはずだ。

ひとまず修正方針が二転三転としたけれど、最終的に結論が出てくれたから良かったものの随分と頭を悩ませる羽目となった。
ただでさえ疲労困憊なのに追い打ちを掛けるような状況で心の底から疲れた。

脳内の 整理が出来ず 迷走へ2026年09月10日 22時25分14秒

ここ数日は面倒な横槍のせいで時間と精神力を削られていて、修正の必要な対応で修正方針が定まらずに酷い迷走状態となっていた。
構成が煩雑で何がどう絡んでいるのか把握しきれず、開発支援AIの解析を任せないと二進も三進も行かないので、必要な情報が頭に入ってこないから当然の結果でもある。

開発者としてスロースターターに分類されると自覚していて、出だしの遅さは対象システムが頭に入ってくるまで作業効率が悪くて、脳内整理が終われば最適解を早々に見付けて修正できるようになるからだ。
ところが、今回の炎上プロジェクトは異常なまでに可読性の低さを誇っていて、脳内にシステムが全く入ってこないから苦労させられている。

開発当初から時間に追われて作っていたので、コード整理が不十分な状況もあって尚更に脳内整理が滞っている。
そもそも早く離任したいと言っているので、今更に脳内整理を進める気持ちもないから、厄介な修正が入ってきた時に迷走する事態となっている。
そもそも可読性の高いシステムに作り直すという目標だったはずなのに、真逆の方向へ突き進んでいる気がしてならない。