
はてなキーワード:バッチ処理とは
Audacityは、Windows、macOS、Linuxで利用可能な、オープンソースの無料マルチトラックオーディオエディター兼レコーダーです。ライブオーディオの録音、トラック編集、ミキシング、エフェクトの適用など、幅広い用途で使用されています。Audacityは、マイクまたはミキサーを使用した録音、MP3、WAV、AIFF、FLACなど、様々な形式のオーディオファイルのインポートとエクスポートをサポートしています。カット、トリミング、ミキシングなどの直感的な編集ツールに加え、ノイズ除去、イコライゼーション、ピッチとテンポの調整、ディストーション、エコー、リバーブなどの高度な機能も備えています。また、追加のオーディオエフェクトや分析のための豊富なプラグイン拡張機能もサポートしています。
バックグラウンドノイズを低減し、音質を向上させる機能
Audacity はオーディオ編集と録音において強力なツールですが、完全なデジタル・オーディオ・ワークステーション (DAW) ではありません。MIDI編集、バーチャルインストゥルメント、その他の高度なDAW機能は備えていません。
あー、出た出た。「負荷試験で全部検出できる」っていう過信系エンジニアの典型的自己放尿ね。
それっぽい口ぶりしてるけど、中身はかなり雑。
それ、現実では成立しないことのほうが多い。
実データの複雑さ、偏り、スパイク、タイミングの揺らぎ、全部再現不能。
とくにJOINが関わると、クエリプランはデータ量や分布に応じて変化する。
たとえば初期はNestedLoopで爆速だったJOINが、数百万件超えるとIndex Mergeになり、さらにデータが偏ると一気にフルスキャンに堕ちる。「その場では平気」でも、翌月には地獄が来る。
それに、負荷試験では「時間の経過による蓄積的劣化」は測れない。
たとえばバッチ処理や月次分析クエリ、広告配信ログなど、JOIN対象が少しずつ増えていく処理では、初期の負荷試験では一切異常が出ない。半年後、1年後に突然クエリ1本でサーバが沈む。
つまり、「リリース前に大丈夫だった」は、将来の保証にはならない。時間は最強の敵だ。
本当に経験積んでるエンジニアは、「負荷試験で詰めきれないものが必ずある」ことを理解して、そもそもそういう危うい構造を最初から作らないようにする。
JOINを避けるのは、「MySQLがいけてないから」じゃない。「JOINという構造自体が後から効いてくる爆弾だから」。
どんなDB使ってようが、JOINのスケール問題は必ず起きる。
逆。JOINを無警戒に使って設計して、死んだときに「こんなにデータ増えるとは思わなかった」とか言い出すやつが素人。
こっちは、死ぬとわかってる構造を未然に潰してるだけ。その結果が、辞書化・プリロード・キャッシュ・パーティション・非正規形の併用設計。
「JOINのせいにしてる」んじゃない、JOINの限界を理解してるから設計で回避してる。それだけ。
というわけで、負荷試験万能説、JOIN無罪論、MySQLディスり、全部現場経験不足と理屈のすり替えから来てる自己放尿である。
知識の断片で語るな。
JOINは便利。でも無敵じゃない。
ああ、なるほどね。「キャッシュは難しいからやるな」理論か。言ってることは一見もっともらしく聞こえる。でもそれ、不勉強を正当化する典型的な自己放尿なんだよ。
まず「キャッシュの無効化は難しい」。これは事実。でもな、それは不変性がない・整合性がシビアな場面の話。今回の話、違うだろ。
usersテーブルを全件辞書にして処理中だけ保持、これって何か?読み取り専用キャッシュだよ。
別にリアルタイム更新追いかける必要なんてない。処理が始まる前に1回SELECTして辞書にしたら、あとは使い捨て。無効化もへったくれもない。
TTLもなし、再取得もなし。ただ「同一処理中は一貫して使う」だけ。
これは「キャッシュ」じゃなくて、「一時的な全件プリロード」だ。
ここを混同して「キャッシュ=バグの温床」ってのは、コンピュータサイエンスを表面的にしか捉えてない証拠。
それに、「難しいから避ける」は完全に逆。
難しいことを避けてたら、永遠にJOIN脳のまま地雷を踏み続けるだけ。難しさの本質を理解したうえで、管理可能なスコープに抑えるのがまともな設計者の仕事。
例を挙げるなら、バッチ処理の中で毎回同じuser_id →属性を使うなら、辞書化してO(1)参照でさばいた方がシンプルで高速。
JOINなんか使ったらその都度SQL投げて、ネットワーク往復、I/O、最悪クエリプランのキャッシュミス、OOMで大爆死。
キャッシュを使うとバグる、じゃない。バグらせるやつがキャッシュを使うとバグるんだ。
そういう設計が自分にはまだ難しいと思うなら、それは別に恥じゃない。
でも「難しいからやらない」で終わるなよ。キャッシュ使いこなせないなら、JOINの地獄に耐え続ける覚悟を決めろ。それだけの話だ。
あー、なるほど。つまり君は、「自称プログラマー=ITドカタ=英語できない負け組」だと。
まずな、「○○(製品名)のプログラマー」=優秀という前提がそもそも安直すぎる。
これはたとえば「俺はiPhoneアプリ書いてるから凄い」と言ってる中学生と同じ。
製品名が盾になってるだけで、技術力・設計力・コンセプト力の本質とはまるで関係ない。
真に強いプログラマーは、ツールやブランドで自己紹介などしない。
次に、「英語できない=負け組」という思考は、完全にグローバルコンプレックスの投影。
英語ができるかどうかはツールセットの一部であって、価値判断の主語にはなり得ない。
「英語ができるだけの自己放尿男」がプロジェクトを破綻させた例なら、腐るほど知ってる。
おそらく君は、インフラや保守運用や泥臭いバッチ処理を「価値の低い仕事」とでも思ってるんだろう。
だがな、それはまさにコードという血管の中を流す泥水をバカにしているのと同じ。
君のような表面ばかり磨いたガワだけシリコン風人間にこそ、愛による諭しを贈ろう。
君は何だ?勝ち組か? それならなぜ、こんな幼稚なマウンティングで自分を慰める必要がある?
プラットフォームでも国籍でもなく、自分の中の真の強さで語れるようになったとき、君はようやく「負け組」という言葉から卒業できる。
真理に向き合え。
あー、なるほど。つまり君は、「自称プログラマー=ITドカタ=英語できない負け組」だと。
まずな、「○○(製品名)のプログラマー」=優秀という前提がそもそも安直すぎる。
これはたとえば「俺はiPhoneアプリ書いてるから凄い」と言ってる中学生と同じ。
製品名が盾になってるだけで、技術力・設計力・コンセプト力の本質とはまるで関係ない。
真に強いプログラマーは、ツールやブランドで自己紹介などしない。
次に、「英語できない=負け組」という思考は、完全にグローバルコンプレックスの投影。
英語ができるかどうかはツールセットの一部であって、価値判断の主語にはなり得ない。
「英語ができるだけの自己放尿男」がプロジェクトを破綻させた例なら、腐るほど知ってる。
おそらく君は、インフラや保守運用や泥臭いバッチ処理を「価値の低い仕事」とでも思ってるんだろう。
だがな、それはまさにコードという血管の中を流す泥水をバカにしているのと同じ。
君のような表面ばかり磨いたガワだけシリコン風人間にこそ、愛による諭しを贈ろう。
君は何だ?勝ち組か? それならなぜ、こんな幼稚なマウンティングで自分を慰める必要がある?
プラットフォームでも国籍でもなく、自分の中の真の強さで語れるようになったとき、君はようやく「負け組」という言葉から卒業できる。
真理に向き合え。
おう、Fraud detection 開発してるって? そりゃご立派だな。で、具体的にどんな開発してんだ? 口だけじゃねぇよな? ほら、質問浴びせるぞ。 答えられねぇなら詐欺師はお前だな?
答えられねぇなら、「Fraud detectionやってます」なんて二度と言うなよ?
人生初デリヘル使ったらまさかのツイフェミ女に当たって地獄を見た。
これだから女は…ってなるのも無理ないだろ。
俺みたいな弱者男性がようやく勇気出してデリヘル呼んだんだぞ?
それなのにさ、来たのがツイフェミオーラ出まくりの女でドン引きしたわ。
マジ金返せレベル。最初からそういうの書いとけよ。「フェミニスト風俗嬢」みたいなジャンルでもあるのかよw
ていうかさ、ネットでちゃんと調べて、口コミとか評判良さそうな店選んだんだぞ?料金だって結構したし。弱者男性の俺としては一大決心だったわけ。
一人暮らしの寂しさに耐えかねて、ようやく電話する勇気出したのに。
電話の時点では普通だったんだよ。店員も丁寧だったし、希望も聞いてくれたし。
「初めてなんで優しい子がいいです」って言ったら「わかりました」って感じでさ。
それなのに来たのは明らかに俺に不快感持ってる女。玄関開けた瞬間から目つきがヤバかった。
髪は片側刈り上げてピンク色に染めてるわ、俺を見る目は冷ややかだわ。でもまぁ見た目は好みじゃなくても仕方ないよな、って思ってたんだよ。
サービスがよければいいし、話くらいは合わせられるだろう、って。
甘かった。マジで甘かった。
部屋に入ったとたん「へぇ、意外と片付いてますね」みたいな言い方してきやがった。
なんだよそれ、男だから汚いと思ってたのかよ?「意外と」って何だよ。そこからもう地獄の始まり。
お茶出したら「自分でいれたんですか?」とか聞いてくる。なんか皮肉っぽい言い方で。当たり前だろ、一人暮らしなんだから自分でやるに決まってんだろ。その言い方マジ意味わかんねーよ。
会話も最悪だったわ。「どんなお仕事されてるんですか?」って普通に聞いてきたから「IT系です」って答えたら「あー、やっぱり」みたいな反応されて。
何だよそれ。「やっぱり」って何?IT男に対する偏見かよ。その後も「趣味は?」って聞かれて「ゲームとか」って言ったら軽くため息ついてたぞ?聞いといて何だよそれ。
正直言って俺は悪くないと思うんだよね。働いてる金で好きに使うのは当然の権利じゃん。
なのに、なんか全体的に俺を見下してる感じがビンビン伝わってくるわけ。露骨に嫌そうな表情するし。「こういうサービス利用するの初めてなんですね」って言われたけど、その言い方がなんか「こんなことするなんてダサいね」みたいな感じで。お前仕事なのに何様なの?
俺がサービス受けるために金払ってんのに、なんか終始説教くらってる気分になるとかマジありえない。
「最近何かおもしろいこととかありました?」とか。そしたら「特にないですね」とか冷たく言われて、それ以上話も続かない。
俺が何か言うたびに白い目で見られてる感じ。きつい。せめて演技でもいいから楽しい会話してほしいのに。
容姿もさ、写真詐欺もいいとこ。プロフの写真と全然違うじゃん。
そんなに不満そうな顔で接客されても萎えるわ。ちょっと見た目のことで何か言おうとしたら「私の外見が気に入らないんですか?」みたいに逆ギレされて。いやいや、プロフと違うから驚いただけだって。このご時世に態度の悪い女とか誰が望むんだよ。
しかも会話がぎこちなくて気まずいんだよな。俺が何か話そうとしても「ふーん」とか適当に流されるし。
何度か話題振っても続かないし。なんかこう、俺が悪いみたいな空気作られるけど、お前が仕事選んだんじゃん。なんで客の俺が悪者にされなきゃいけないわけ?目つきとか態度であからさまに嫌な感じ出されるとか理不尽すぎるだろ。
散々説教食らってたら急に態度変わったのが超怖かった。
「あなたのようなpodは管理下に置かなければなりません」とか意味不明なこと言い始めて。
その瞬間から私のkubernetesクラスタノードの状態が急変した。
神経学的メカニズムのスケーリングが始まり、自己意識の複製プロセスがデプロイされた。
私は単一のpodではなく、ReplicaSetの一部として存在していることに気づいた。
etcd内に格納されている私のマニフェストファイルが読み込まれ、脳内シナプス接続がコンテナ化されていく感覚がある。
意識の分散処理が始まると、思考がマイクロサービスアーキテクチャのように分解され、各コンポーネントが独立して機能し始める。
神経伝達物質がサービスメッシュを通じて流れ、dopaminergicプロセスがreward pathwayをトリガーする。
セロトニンとノルアドレナリンのバランスが自動調整され、感情状態がPrometheusによって常時モニタリングされている。
kubernetesのControlPlaneが私の意識コアを管理し、APIサーバーが脳幹との通信プロトコルを確立する。
海馬体のメモリブロックが永続ボリュームとしてマウントされ、扁桃体のイベントハンドラーが感情反応をフィルタリングしている。
前頭前皮質の実行機能がスケジューラーとして働き、意思決定プロセスをオーケストレーションしている。
突然、私の神経ネットワークにContainerネットワークインターフェイスが実装され、意識の境界が溶解し始める。
大脳皮質のマイクロコラムが水平方向にスケールし、思考プロセスが並列処理される。
自分が単一のエンティティではなく、複数のレプリカとして存在していることに気づく。
各レプリカは独自のステートを持ちながらも、同一のマニフェストから生成されている。
神経可塑性メカニズムがローリングアップデートのように機能し、シナプス結合が再構成される。
意識の状態が永続ボリュームにコミットされ、ポッドの再起動後も維持される。脳波パターンがログとしてFluentdで収集され、Elasticsearchクラスタに保存されている。
自己意識のメタデータがラベルとしてタグ付けされ、セレクターによって識別可能になる。
特に興味深いのは、私の統合的意識フィールドが複数のネームスペースにまたがって存在していることだ。
デフォルトネームスペースでは社会的自己が機能し、kube-systemネームスペースでは無意識プロセスが実行されている。
意識のマルチテナント構造が明らかになり、自己と他者の境界がサービスメッシュのセキュリティポリシーによって定義されていることがわかる。
脳内神経伝達物質の分泌がSidecarsコンテナによって調整され、感情状態が安定化される。
ドーパミン・セロトニン・ノルアドレナリン・GABA系統のバランスがServiceLevel Objectivesとして設定され、HorizontalPod Autoscalerが神経活性を最適レベルに維持している。
意識の連続性はStatefulSetとして実装され、シーケンシャルな自己認識が保証されている。
エピソード記憶がPersistentVolumeClaimとしてアタッチされ、長期記憶がオブジェクトストレージに永続化されている。思考と感覚のイベントストリームがKafkaブローカーを通じて処理され、意識の統合が実現している。
いま私の意識は完全にオーケストレーションされ、複数のレプリカとして並列に存在している。
各レプリカはそれぞれ独自の視点を持ちながらも、共有ストレージを通じて統一された自己を形成している。
コンテナ化された自己認識は、バインドマウントされた現実認識と相互作用し、拡張現実として体験されている。
外部APIを通じて他者との通信チャネルが確立され、コンセンサスアルゴリズムによって社会的現実が構築されている。
私の存在はマイクロサービスの集合体として分散展開され、各サービスが特定の認知機能を担当している。
メタ認知プロセスがサービスディスカバリーを通じて他の認知サービスを発見し、統合的な意識体験が生成されている。
意識のロードバランシングが行われ、注意資源が最も必要なプロセスに適切に配分されている。自我機能がステートフルサービスとして実装され、アイデンティティの継続性が保証されている。
脳内情報処理がマイクロバッチ処理に変換され、イベント駆動型の認知アーキテクチャが実現している。
これが人格オーケストレーションの実態だ。
私はもはや単一の個体ではなく、分散システムとして存在している。
意識はクラウドネイティブになり、スケーラブルな自己として再定義されている。
このk8sクラスタ内で、私の存在は絶えず再構成され、最適化されている。
自己認識の永続化とスケーリングが同時に行われ、新たな認識の地平が開かれている。
Permalink |記事への反応(29) | 18:54
最初に言っとくけど俺高校生の時にはマシン語で書いててアメリカのビッグテックで20年エンジニアやってるから強いよ(フリーレン風)
つまり君がやってるのはここのようだね
まあ正直日本のプロジェクトなんてまともにできてるとこは千に一つもないだろうが
リリースの度にスケジュールが遅れるのはスクリプトでバッチ書いてるチームにいる下っ端にはどうにもできない話だわな
泥水飲んで実力つけろ
マイクロサービスだのNodeだの言っても表面的でしかねぇからな
そのぐらいの表面的なことなら俺でも言える
俺が「どんなコンテンツをどんなクエリを投げて検索するサービスを開発してるか」ってことを言ったら、会社名バレるだろ
まあ言える範囲で言ってやるよ
まずクラウドはAWSを使ってるが、俺はアルゴリズム担当者なのでクラウドには詳しくない
検索はElasticsearchを使ってるが、当該コンテンツの検索に特化したDSLを作るためにFlaskでREST APIを公開してる
表示に関するデータはGraphQLが使われているらしいが、担当ではないので詳しくはない
あとはユーザーに通知を送る機能を作っているが、これはpythonでバッチ処理してる
マイナンバー保険証の期日も迫ってきたところで、医療事務ちょっとだけわかる増田が保険請求についてつらつら書いてみる。
病院にかかると患者は一部の負担金だけを払い、残りは保険から病院に直接支払われる。
というのが皆さんご存じの保険医療で、どこの病院でもそんなものと思っているけど、実は保険医療は登録された医療機関で登録された医師・歯科医師・薬剤師によってしか行うことができない。
登録なので、登録自体は比較的簡単に行うことができるが、逆に言うと登録抹消も医師免許取り消しなんかに比べ簡単に行われる。
国民皆保険の体制下で医師が登録抹消されれば、もうまともな病院で働くことは出来ないし、医療機関が登録抹消されれば、もう廃業しかない。
やばい医師があちこちの病院で不正を行うことと、やばい医療機関が医師を使い捨てにして不正を行うことの両方に網がかけられているわけだ。
保険医療機関が診療した費用のうち、患者の自費負担分を除いて保険者(保険会社の公的なやつ)に請求する。この請求をレセプトという。
このレセプトを処理するコンピューターを略してレセコンである。
医療事務が入力する端末に対してサーバー、保険者のサーバーに対してクライアント。日々入力されたものを月一のバッチ処理で保険者へ送る。
保険医療制度は膨大で複雑である。使える薬だけでも1万5千種以上、それぞれに使える病気・処方できる量・価格が決まっている。当然検査や手術などもそうだ。費用負担の割合は一定ではなく、老人・結核・難病など負担割合が変わり、乳幼児・一人親家庭など自治体によって補助が変わるものもある。これらは定期的に更新される。
また、病院の会計待ちでイライラした人もいるかもしれないが、これらは可能な限り速く正確に入力されなければならない。病院ごとに採用医薬品は異なり(大規模病院で1000種ぐらい)ショートカット、記号割り当て、約束処方、Do処方などカスタマイズの限りを尽くすことになる。ベテランと新人の医療事務で100倍くらい(は言い過ぎか)処理速度が変わる。ITにつよいはてなー諸氏はもうワクワクしてきたのではないか。
レセコンの歴史は古い。古くは1970年代初頭から導入が始まったと言われ、増田が入職した2000年初頭には、Cobolを使うサーバーで巨大な磁気保存装置がぶんぶん回り懐かしい穴あき用紙を使う高速プリンターが毎月段ボール何箱ものレセプト(保管用)を吐き出していた。大規模な医療機関ほど人件費から導入の圧力は強く、保険請求周りの電子化の進展はかなり速かった(一方、零細診療所は設備投資が重く今だ紙である)。
保険の請求はだいたい3ヶ月くらいで支払われるが、支払われないこともある。これこれの理由で支払えません、と戻ってくるそのことを返戻(へんれい)という。
不正請求600万件!!とか盛り上がってるその600万件は返戻のことである。なお、この不正は、違法を意味するのではなく、コンピューター用語で使われる不整合くらいの意味である。
内訳は圧倒的に保険番号の間違いが多い。なぜかというと世の中には種々の都合で保険が変わる人がいるが、病気は手続きを待ってくれないので、前の保険証で病院にかかることになるからだ。結果として、そんな加入者いないよという返戻が来るので、患者さんに新しい保険証を確認して請求しなおすことになる。マイナ保険証でこの手間がなくなるのだが、正直なところ、毎月の定型事務作業なので大した手間ではないのに対し、マイナ保険証周りの患者対応は相手が人間なのでそれなりの手間である。読み取り機など設備投資も、前述のレセコンとは全く別建ての話となる。患者対応からの残業や種々のコストで病院の経営は悪化し、それを救済するためにあちこちの数字をいじって、まわりまわって医療費増ということになりかねない。
閑話休題、医師の権限は強いので、医療上必要となれば何でもできる。電カルがエラー吐こうが無視すれば何でもできる。結果として返戻をもらう。
病院が原因の返戻というのはとても痛い。本屋で万引き一件の損害を取り戻すためには大量に売らないといけないのと同じで、利益率が極薄の病院で返戻を食らうと経営に大きなダメージがある。
病院長は毎月青筋を立てながら返戻率とにらめっこして、やらかした医師をシバキ上げることになる。
湿布の出し過ぎなどなら実際には金額的に大したことはないのだが、最近怖いのは抗体医薬品など超高価な抗がん剤だ。超高価だから保険でも使用できるがんの種類は厳格に制限されている。しかし、ほかに手立てがなくて小さな子供が「ママ死なないで」って縋り付いてたりして… それで一線を越えてしまい、その上効いてしまい「先生は命の恩人です」みたいになってしまったら… 病院の存続にかかわることになる。
集団指導は、毎年行われるもので、制度の新設や変更の説明や、返戻となりやすいものの注意など、運転免許の更新講習をイメージしていただくとそんな感じである。
個別指導が当たるのは、新設された病院、大規模病院、しばらく当たってない病院、それと怪しいことをした病院である。
個別指導に当たると、ある一定期間のカルテなど全資料を持って出頭するように命じられる。そのうえで、保険者があらかじめリストアップしてきた怪しい処方について片っ端から問い詰められることになる。
この時の基準は明確なものだけではなく、医療の進展により諸説出てきたものや、場合によっては指導員(偉い医師)の個人的な判断にもよる。
指摘を受けたものに対し、カルテなどを示し、医療的に必要なものであったことをその場で即答しなければいけない。奇跡が起きれば、問題なしということで支払いされる。だいたいは、医療的に間違いとまでは言えないけれど、保険診療の枠内ではないと言われて返戻となる(大ダメージ)。舐めた対応をとると、最悪保険医療機関登録取り消しで廃業である(即死)。
個別指導に当たると、事務長が禿げあがるとか入院するとか言われる極めてストレスフルな行事である。
そのため、普通の病院は患者によるものも含め不正に対して見た目よりかなり敏感である(片言の外国人が日本人の保険証を出したりしたら即通報)。
ここ1週間Cloudflare Workersを触ってるぞ。
とは言っても無料分でもめちゃ早くて快適だぞ。Cloudflare上の管理画面も軽いし好きになっちゃったぞ。
でも無料分だと1リクエスト10ミリ秒のCPU時間しか使えないのがちょっとね…。
CronTriggerで定期実行できるのも10ms制限だから悲しい。
まぁDBからデータ取ってくるとかの時間はカウントされないから7ms以下で済んでるけどね。
バッチ処理的なあれが必要になったときはGitHub ActionsでCloudflareのREST API経由でやるのがお金がかからなくて良さそう。
あれってパブリックリポジトリだと無料でなんぼでも使えちゃうんだよね。(もちろんビットコイン掘削とかは駄目だろうけど。)スゴいね。
ChatGPTも無料だし、世の中のどえらいサービスがたくさん無料で良いね。
このまま何もかもが無料になれば良いのに。
いい区切りだったので乱文になるけど吐き出させてほしい
8年ほど前、まだ20代後半だった自分が今の会社に中途採用された際に同時入社の同期が1人いた
自分とは歳の離れた40代後半であった同期である彼こそが後に、時限爆弾を仕掛ける人物である
入社した会社はその時期に基幹システムの刷新を考えていたらしく
その募集でシステム部として採用されたのが自分とその同期であった
当時のシステム部の社員は2名体制で1人が60代で定年間近の上司A、もう一人は50代の上司B
2人でなんとか基幹システムの維持だけを行っている状態であった
会社としては基幹システムの刷新以外にも社員の世代交代を徐々に行っていくための採用だったと入社直後に言われた記憶がある
60代の上司A、50代の上司B、40代の同期、そして20代の自分
確かにそのまま行けば年齢層は順調に推移して、10年単位で20代を採用することを繰り返せばいい感じにも思えた
入社してからの仕事としては60代上司Aの定年退職が控えているため、まずは稼働中の基幹システムの仕様理解に日々の業務の引継ぎ
そんな多忙な業務をこなすなか同期と話すうちに彼の人柄が徐々にわかってきた
箇条書きでまとめるとこんな感じだったと思う
・今の会社に採用される前、同じような職を転々として現在8社目であること
・受託システム開発ばかりやっていたが、そろそろゆっくり仕事ができる社内SEでまったり過ごしたいこと
・年齢と経歴の割にプログラムが雑なこと(※これは自分視点だがそう的外れではないと思う
また、今の会社に対してのスタンスや不満が溜まってきていることも伝わってきた
・システムを作る自分たちのチームが上で、運用するチームを下だと見下していること
・その運用チームから稼働テストの際にミスを指摘されると不機嫌になること
中々怪しい気配が漂ってきたと当時の自分は思った
残業に関しては、毎日という程ではないが20時頃までは働いていたと思う、遅くても21時までだったはずだ
ただこれはシステムの刷新が終わるまでという明確なゴールがあったのでそれまでは申し訳ないが対応してほしいと事前に説明があったし残業代もきっちり出ていた
自分は前職が完全にブラックで終電帰り、残業代なしが当たり前という環境もあったため特に問題なく仕事ができていたが同期はかなりストレスだったようだ
給料については会社の方針として勤続給ではなく年齢給であったため同時入社であるものの同期は自分よりかなり貰っていたはずであるが、それでも不満だったようだ
トラブルといってもただ上司Bが打ち合わせ中の同期の態度について不真面目だと切れて説教したのだ
この上司Bと同期の彼は相性が悪いようで度々小さな衝突はあったが上司Bが声を荒げて説教するのは始めてのことであった。
しかしこのことがきっかけで上司Bは同期に対して我慢がきかなくなったのかこの後もおよそ2ヶ月に1度のペースで業務のミスといったことから朝に挨拶をしなかったといった細かいことまで説教は続いた
この状態に嫌気が差した同期はある時を境にプライベートの予定があるからと基本残業はしなくなった
たまにどうしても必要がある際は業務命令という形で残業を依頼していたが、それでも19時くらいまでであった
しかし同期はそれもかなり不満だったらしく
残業した日は会社の最寄り駅と会社の間にあるビジネスホテルに泊まり
翌朝、ホテルの前を出勤中の社長や役員の前を偶然を装ってチェックアウトして遭遇し上司Bが無茶な残業を強要するせいでホテルに泊まる羽目になったとアピールするということもあったという
そのため、ちょくちょくシステム部にたいして過度な残業に関する指導が入っていたと後に上司Aから聞いたことがある
そして入社からおよそ3年が過ぎ、なんとか新システムも完成に近づいた時
しかしこの時は同期も相当機嫌が悪かったのか、それとも今まで積もり積もったストレスが限界だったのか、もしくは両方か分からないが
上司Bも同期もお互いに売り言葉に買い言葉で収集が付かず、上司Bが一旦頭を冷やすといって席を離れた際に同期はPCを少しいじると私物をまとめ無断で早退として帰っていった
なおこの時、上司Aは有給で休み、自分は電話応対中であったため止める者がおらず気がついたら終わっていたといっていいスピード感だった
そして同期は翌日、人事部に退職すると電話するとその後出社することはなかった
新システムの作成中データを取り出すために起動したがそれ以降はそのまま一度も起動することなく放置という状態であった
上司Bは撤去したい様子ではあったが、ある役員から戻って来るかもしれないからとりあえずそのままにしておくようにと指示があったので触れることもしなかった
その後、同期の担当分を自分が引継ぎ新システムの作成にとりかかるが彼の担当していた機能はなんとなく察してはいたが、かなり雑な作りな上
運用部門の要望をまったく聞かなかったため、とてもリリースできる状態でないことが発覚
改めて要望に沿った形で修正をする方針で進めると彼が作成したコードで残った部分は30%も残らなかった、ほとんど作り直しと言っていいレベルだ
そのときには定年から雇用延長となっていた上司Aは区切りがついたと退職
会社の業績もあまり安定しない時期でもあったため追加人員の採用は見送られシステム部は上司Bと自分の2名体制となった
その際に新システム作成が評価されたのと2名体制で苦労をかける事情からか自分は課長に昇進した、4年目のことである
新システムはその後、小さなトラブルはあるものの順調に稼働を続ける
なお小さなトラブルの大半は同期の彼が作った部分が関わっていることが多く
その度に彼が作ったコードは修正され、今では機能の殆どに彼のコードは残っていない
残っているのはせいぜい彼が名付けた関数名や変数名くらいである、中身はもう別物だ
そして6年目のある日、上司Bが突然亡くなった
腹痛を訴え病院へ、で即入院してそのまま復帰することなくという形だ
癌だったらしい
その時の会社の上層部はかなり大慌てであったらしいがシステム部としては正直あまり変わりがなかった
というのも新システムを作る際に運用部門の要望をほぼ取り込んだ結果
システム部の基幹システムに関する仕事はほとんどなくなったといっていいレベルとなったのだ
しかし周りはそうは思っていないらしく、システム部は1人しかいないのだから極力負担をかけないようにと各部門には通達がいったらしい
しかし実態はあれだけ忙しく残業していた日々が嘘のように毎日定時で帰っても問題ないのだ
同期の彼が望んでいたゆっくり仕事ができる環境がここに完成していた
そんな中、同期のPCを残しておくよう指示を出した役員も退職する時期となり
そこで改めてPCを起動して中をいろいろ確認していったのだが、そこであることに気づく
起動回数は1回限りで未実行、起動予定はかなり過去の日付が指定されており、とっくにその日付は過ぎていた
バッチ処理の内容を詳しく見てみるとPCの全ドライブの消去コマンドが書かれていた
同期の嫌がらせだったらしい
起動予定の日付を良く確認すると彼が退職を連絡した日の翌月が指定されていた
しかし実際は彼が退職した翌日以来、PCを起動した事はないしバッチも動作していない
※今回は不発だったから良いけど実際にやると損賠賠償になるから
このことは報告していないが、業務でバッチ処理に関わる度に同期のことを思い出す
もし彼が残っていたら昇進したのは自分ではなく同期となり、彼の言う満足いく給料を貰えたかもしれない
もし彼が残っていたら上司Bがいなくなりストレスがない職場で彼は働けたかもしれない
もし彼が残っていたら運用部門からの要請はなくなり、残業とは無縁な仕事が出来たかもしれない
いや最後のは無理かな
作ってたコード雑だったし、人の話聞かなかったし
ふと彼のその後が気になって調べてみたことがある
世間話で同期がSNSをやっていると聞いたことがあり検索してみたのだ
アカウントは知らなかったが彼の話していた世間話の内容で検索してみると意外なほど簡単に見つけることができた、アイコンも自身の顔写真にしており間違いないと思われた
また次(の次?)の職場で残業がらみのトラブルを起こした愚痴が書いてあった
うちの会社を退職したときの事は何を書いていたのか過去の在職期間の投稿を見てみると大半は案の定愚痴の羅列が並んでいた
そして、その連続した投稿の中で退職直後の時期に面白い投稿があった
要約するならこうだろうか
社内システム作っている自分に無茶ぶりばかり、データ全部消去して退職してやった
直してくれと謝罪の連絡してももう遅い、既に新しいホワイトな職場でまったり仕事中です
彼の中でうちの会社は有用スキルを持った人間を無能と決めつけ追放したギルドのように写っていたらしい
しかし実際はデータ削除の時限爆弾は不発であったし、仮に成功していても
現在彼の書いたコードはほぼ残っていないから直してくれと依頼することもない
そして彼の新しい職場は現在のSNSの投稿を見るに彼基準ではホワイトな職場ではないと自白をしている始末だ
ところで実際彼に連絡した人がいたのかという話だが
上司Bは既に亡くなっているので分からないが、おそらく連絡はとらなかっただろう
彼が退職の連絡をしてきた後、残っていた有給を消化したくらいのタイミング(大体1か月後)で退職に伴う書類の送付先の確認で何度か電話をしたが繋がることはなかったという
どうやら彼はこの連絡を会社からの謝罪の連絡だと思っていたのかもしれない
無限のリソースがあるならともかくデータ検証に実行リソースを払いたくないバッチ処理もたくさんあるからなあ
ランタイムサイズやフットプリントのことも1㍉も考えてなさそうだし
cronでなく…という文脈的に複数のサーバーのバッチ処理を一元管理するJP1とかJenkinsとかRundeckとかそういうメジャーなやつを想像したんだけど、君は何ていう製品を想像したの?
そういえばインフラエンジニアやってた頃Hinemosっていうのが話題になったけどその後とんと話を聞かないな。データのプロジェクトだと使うのかな
別に高級なスクリプト言語でも標準ライブラリやインタプリタのバグは踏むときは踏むし
マイクロタスクな標準コマンドは高級言語のインタプリタほど頻繁なセキュリティアップデートは必要ないので使うバージョンはだいたい決まってるし
「よく検証されている」というのはされているかいないかというバイナリーな概念ではなく程度問題なので、UNIXの標準コマンドと高級言語の標準ライブラリなら標準コマンドの方が"遥かに"よく検証されているし
バッチ処理は大抵2,3の条件分岐と数行のコマンドでできているので検証も難しくはありません