/note/tech

Asahi Linuxのリードデベロッパがアップストリームメンテナーを辞任、背景に“C vs. Rust”対立に端を発した...

僕はもう、カーネル開発プロセスやコミュニティ管理アプローチになんの信頼も置いていない(I no longer have any faith left in the kernel development process or community management approach.)―2020年のプロジェクトローンチ以来、Asahi Linuxのリードデベロッパを務めてきたHector Martinは2月7日、Appleシリコン(ARM)コードのアップストリームカーネルメンテナーを辞任する意向をLinux開発者メーリングリストで表明した。突然の辞任の背景には、Cベースの古参メンテナーとRustコード推進派の対立とMartin自身によるソーシャルメディアを使った炎上狙いがある。

MartinはすでにLinus Torvaldsからメンテナーを外されており、今後、メインラインにおけるAppleシリコンコードのメンテナンスはMartinと共同メンテナーを務めてきたSteve Peterと、Asahi LinuxプロジェクトのメンバーであるJanne Grunauがともに担当することになる。なおMartinはメインラインのメンテナーは辞めたものの、Ashahi Linuxでの貢献は続けるようだ。

Linuxカーネル開発コミュニティに禍根を残すようなメッセージを残し、メンテナーとしての責任を放り出す格好で突然辞任したMartinだが、その直接の原因はAshahi LinuxやAppleシリコンコードではなく、メインラインカーネルへのRustコード統合の進捗に関する自身のいらだち(MartinはRustコード推進派)をMastodonなどのソーシャルメディア上でぶつけたことによる。それも感情的で突発的な行為というよりも、コミュニティ内での古参メンテナーとRust推進派(Rust for Linux / R4L)の議論をMastodonやReddit上で大げさに書きたて、内情に詳しくない一般人に「古参メンテナーはR4Lの活動を妨害している」というイメージを植え付けようとしていたようだ。

こうした特定の個人やグループに対してソーシャルメディア上で攻撃する行為は「ブリゲーディング(brigading⁠)⁠」と呼ばれるが、LKMLでオープンな議論を重ねてきたLinuxカーネル開発コミュニティにとっては当然ながらあまり好ましいアプローチではない。LKMLの複数のメンバーからブリゲーディングを咎められたMartinは2月6日、「⁠もううんざりだ(I'm tired.⁠)⁠」としてCコード守旧派の古参メンテナーの“⁠妨害⁠”行為やパッチレビューシステムの煩雑さに対する不満を書き連ね、最後に「ソーシャルメディアで非難しても効果がないというなら、何をやれば効果があるのか教えてほしい。こっちにはもうアイデアがない」と挑戦的な内容を投稿している。

MEMO:

Single Responsibility Principle: The Art of Great Code

アジャイルっぽいプロジェクトの失敗する要因は「ストーリーポイントの不確実性」にある?:工数見積もりなしで...

「見積もりをしない」という考え方は簡単に実践できるように思えるが、実際にはもう少し複雑だ。見積もりをしないとしても、リリースのスケジュールや統合作業、マーケティング、フィードバックセッションの時期を把握しておく必要があるからだ。

#NoEstimatesムーブメントは「予測を放棄しろ」と言っているのではない。このムーブメントは、多大な苦痛の原因となってきた有害な慣行、つまり「個々のタスクにかかる時間の推測」をやめることに焦点を当てている。

では、推測なしで予測を立てるにはどうすればいいのか。それには、タスクの細分化、実績データ、確率的予測という3つの主要メカニズムが必要だ。

■ タスクの細分化

データを意味のあるものにするには、ばらつきや分散を抑える必要がある。ばらつきの大きさは不確実性を表す。ばらつきには未知の要素が潜むため、一見小さなタスクに思えてもタスクが膨れ上がる可能性を秘めている。

そのため、チームは定期的にタスクを精緻化、細分化し、タスクの複雑さを慎重に調べ、未知の要素を明らかにしようとする。そのタスクに設定した制限時間(例えば3日間)を超える可能性がある場合は、そのタスクをさらに細分化する。

これによって未知の要素による影響を大幅に軽減でき、チームは早い段階で複雑さを把握できるようになる。

■ 実績データ

タスクの進行状況や効率性を把握するため、タスクを開始したら、タスク完了までにかかる時間(サイクルタイム)とタスクの完了頻度頻度(スループット)に関するデータを収集する。このデータ収集にはさまざまな方法がある。

例えば、サイクルタイムやスループットなどの「フローメトリクス」を累積フロー図や散布図で視覚化することで、外れ値を発見して早期対応することができる。同時に、チームは個々のタスクがおおよそどの程度の時間で完了するのかという感覚をつかむことができる。

■ 確率的予測

まだ着手していないタスクについて、チームの推測に基づいて時間を割り当てるのではなく、過去のタスクのデータを使って特定の期間内にタスクが完了する可能性を予測する。これによって、見積もりによる「誤った確実性」の危険性を排除し、確率に基づいたより正直な議論が可能になる。

例えば、「最近完了したタスクを考慮すると、このタスクが2週間で終わる確率は50%だが、4週間なら90%の確率で完了する」といった形で予測できる。

このアプローチによって、チームは工数見積もりなしで予測ができる。これによって、タスクに関する議論の進め方が根本的に変わる。任意の期日に固執するのではなく、状況の変化に応じてリアルタイムで調整されるタスクの完了確率を提示できる。見積もりの精度を上げることに時間をかける代わりに、最もリスクの高い項目を見つけ、それらを分解することに集中する。

特に複雑なプロダクトの場合、従来の見積もり手法から離れ、確率的予測や#NoEstimatesを採用することを検討してほしい。

論理的思考の違いから考えた、日本でアジャイルが機能しない理由と解決

MEMO:

【頻出度付き】エンジニア中途面接でよく聞かれる質問リスト🚀

自分のOSSのマルウェア入り偽物を作られたので通報した

3行でまとめ

  • 自作の OSS、fujiwara/apprun-cli のマルウェア入り偽物を作られて GitHub で公開されました
  • 偽物には大量の新規アカウントがスターを付けていたため、検索でオリジナルのものより上位に表示される状態でした
  • GitHub に通報したところ、偽物を作ったアカウントはbanされたようです

MEMO:

データベースの固定パスワードをなくす

システムを捉える5つの視点

新規事業は社内ドキュメント戦略が大事な話

ゾンビ化ドキュメントを防ぐには・・・

・タイトルだけでドキュメントの中身を見つけやすくする

・同じ内容だが、重複した内容のドキュメントを作らない

・必要な情報が不足している場合は、ドキュメントが必要だった人が加筆していく

・使用されていないものは即時アーカイブする

・ドキュメントマネジメントを諦めない心(マネージャーが諦めない)

【図解】ストーリーでわかる!ソフトウェアアーキテクチャ13選

MP3の特許は切れているので自由に使える

未経験者に「Java開発5年」詐称強いたSES企業経営者に高裁判決、768万円の賠償命令

さくらのクラウド、コンテナをサーバレスで実行する「AppRun」製品版トライアルを開始。トライアル中は全機能...

さくらインターネットは、同社のクラウドサービス「さくらのクラウド」の新機能として、いわゆるサーバレスなコンテナの実行基盤である「AppRun」の製品トライアル開始を発表しました。

AppRunは現在ベータ版で、2025年中に正式リリース予定です。製品トライアル期間中は全機能が無料で提供されます。

関連:

NHK、日本IBMを提訴 システム開発中止で約55億円請求

NHKは4日、営業基幹システムの開発中止に伴い、業務委託していた日本IBMに支払った代金の返還や損害賠償を求める訴訟を東京地裁に提起したと発表した。請求額は約54億7000万円。開発方式の見直しにより納期を1年半以上遅らせる必要があるとIBMが申し入れたため、NHKは2024年8月に契約を解除していた。

NHKによると受信料関連の業務を担う現行システムが27年3月に使用期限を迎えるため、新たなクラウド型システムの開発・移行を目指して入札を実施。IBMが約80億円で落札した。22年12月に契約を結んだが、NHKの担当者は「24年3月に入って突然、(IBM側から)開発方式の見直しと、納期の大幅な延伸について申し入れがあった」と説明する。

契約の解除後も既払い代金31億円の返還がなされず、3日に訴訟を提起した。NHKは既に28億5000万円を減損処理している。開発中止を受けて、NHKは現行システムを開発した富士通に委託し、機械の更新という形で対応する。

日本IBMの広報担当者は「NHKには協議を重ねて申し入れてきたが、このような形になったことは非常に残念。訴状が届いていないため、現時点では詳細なコメントは差し控える」と述べた。

AIが進化すると、そもそも業務システムが不要になりそう

MEMO:

map / filter などの高階関数よりも古典的な for文の方が読みやすいと感じるあなたへ

JavaScriptツール群「UnJS」を5分で一気に駆け巡る!

リファクタリングについての彼此(あれこれ)

GoアプリのCI/CDを4倍高速化した汎用的手法まとめ【txdb】

MEMO:

Goのプラクティスまとめ: error handling

製造業とソフトウェアは本当に共存できていたのか?品質とスピードを問い直す

ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making

ソフトウェア開発の “見積り” と “計画” を混同するから話が噛み合わない

DeepSeek-R1の出現は「スプートニクショック」というよりも「Google登場に等しい」との評価

Linuxのコードをたった30行修正するだけでデータセンターの電力消費量を最大30%削減可能、実際にLinux 6.13から...

Facebookで「Linux」関連の投稿が禁止されコミュニティは「マルウェア扱いされた」と反発

MEMO:

分散型アーキテクチャとドメイン駆動設計

tag:

関数の多重下請けをやめよう。単一責任の原則と関数の"責任"について

ドメイン駆動設計 - 実践企業が語るBefore/After - に参加して

DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁

さよならベンチャー

転職して割と間もないけど、ばいばいベンチャー!!!!!!!!!!

ベンチャー本当向いてない、利益追求とか売上伸ばすとか、それはまぁいいが競争心とか闘争心とかはなから無いから、ノルマのために頑張るぞみたいなの自分の意識から全然出てこない。ノルマ達成しないとささやかなやりたいことも出来ない。いやそんな、ノルマ達成のために泥沼ベンチャー入るつもりなかったんだよな。内定を貰って受けた俺の見通しが甘すぎた。

組織内はすっかりギスギスして、というか疑心暗鬼で、出社しても誰も愚痴らないし、リモートなら余計に仕事以外の話はしない。個別に飲み会なんかするとポツポツ話されるが、誰がいつチクるか分かったもんじゃない。社内チャットでキラキラ交わされる合言葉は、「ポジティブ」「爆速」「アンラーニング」!

不定期に「自分/プロジェクトの良くないところ」を挙げたうえで「しかし組織の考え方を改めて捉え直して成功させました!」と発表させる会が行われる。情報統制。環境操作。マインドコントロールしてるつもりでじわじわ下がるエンゲージメント。結果が優先、エンゲージメントは後、って言っても言うほど結果出てないんだよな。

勤めたことのあるベンチャーの中でもダントツにノリが険しかった。裁量もなければ報酬も高くない。上位レイヤーは事業創出ごっこでキャッキャして遊んでる。人材開発? 自己研鑽をしない「他責思考」のやつに得られるスキルやマインドセットはないから。ノルマ達成できないのは自責思考が出来ないお前のせい。ノルマ達成のための商談・獲得はお前のコミットメントじゃねーから口出さないで黙って爆速で成長。

いやーもうベンチャーは懲りたんで、JTCに転職キメた。さよなら「熱量」、さよなら「圧倒的成長」、さよなら「裁量なき責任感」。この組織にいた事、秒で忘れます。ばいばい。

MEMO:

5分でわかる イミュータブル データモデル

tag:

イミュータブルデータモデルで始める実践データモデリング(WEB+DB PRESS Vol.130):読書メモ

tag:

プレミアムプランの状態管理と決済ハンドリングの難しさ

tag:

ドメイン駆動設計の実践により事業の成長スピードと保守性を両立するショッピングクーポン

大きな機能のコード分割を片手間で完了させることができた要因

大規模リファクタリングの一歩目の選択肢 ~コード分割~

字面が同じかどうかより 意図(目的)が同じかどうかで 共通化する

僕の結論は、字面が同じ、つまりコードの重複があるないだけでは、判断できない。意図や目的が同じかどうかも関わってくる、ということ。表にまとめると以下。これが原則的な考え方だと思う。

①字面が同じで意図が同じケース

②字面が異なるが意図が同じケース

③字面が同じで意図が異なるケース

④字面も異なるし意図も異なるケース

というわけで先に示した表を見たらわかるが、字面が同じかどうかというより、意図や目的が同じかどうかで判断するとよい。というか、「字面が同じなら共通化だ!」だと思い込んでると、事故る可能性あるので要注意。

テスト容易性のためのデザインパターン:Humble Objectパターンとは

テスト容易性の確保にかかわる責務設計、リファクタリングのためのデザインパターンに、Humble Objectパターン(Humbleオブジェクトパターン、質素なオブジェクトパターン)があります。

Humble Objectパターンは、ユニットテストのデザインパターン集であるxUnit Test Patternsで定義されたものです。近年は書籍「単体テストの考え方/使い方」でテスト容易性を確保する基礎的技術として紹介され、認知が広がっています。

Humble Objectパターンは自動テスト、特にユニットテストをターゲットとします。大まかな概要として、以下を実施します。

  • 自動テストで実行しにくいオブジェクトを、「自動テストで実行できるオブジェクト」と、「自動テストで実行しにくいコード」に分離する
  • テストすべきロジックの責務をなるべく「自動テストで実行できるオブジェクト」に集中させる。

このHumble Objectパターンはいくつかバリエーションがあります。以下にまとめます。

『改訂新版 良いコード/悪いコードで学ぶ設計入門』活用方法−爆速でスキルアップする!効果的な学習アプローチ

iPhoneが爆発的に日本でウケた理由は2011~2016年のAndroid端末がポンコツばっかだったからではないか?「本当に...

MEMO:

大規模スクラム×E2E自動テストへの挑戦で見えてきたこと

エンジニアの"港区女子化"問題

最近の若手エンジニアの金銭感覚、バグってませんか?という話です。

嬉しいことに、最近のスタートアップやフリーランス市場、外資企業などでのエンジニアへの報酬が明らかに高騰しているように感じます。

[...]

一方で、私みたいな老害おっさんからすると、彼らが高すぎるこの市場で何かが麻痺してしまわないか不安になってしまったのです。

私の個人的なエゴでしかありませんが、エンジニアリング技術は、もっと資本主義から離れて自由な世界線で生きていて欲しいです。

[...]

でも、私は稼ぐ以外にも大事なこと・楽しいことがIT業界にはあると思うのです。私のこれまでのエンジニア人生の中で、一番楽しかったのは、0→1で携わったアプリをリリースする瞬間でした。この瞬間ほど素晴らしいものはなかったと思っています。

お金も大事ですが、お金を稼ぐだけが人生じゃないとも思います。綺麗事のような気もしますが、バランスが大事だと思うのです。

エンジニアという素晴らしい職種に就いた最終的な着地点が「沢山稼いだ。だけ。」はあまりにも悲しいし、寂しいなぁと。

MEMO:

mixi2は「クローリング禁止」「生成AIのトレーニングに活用しない」

MIXIは新SNS「mixi2」で、「問い合わせを多くいただいていた」という生成AIについての考え方を「生成AIについてのポリシー」として1月14日に公表した。

「創作者の方の懸念に配慮」し、「mixi2上に投稿されたイラストを、生成AIのモデルのトレーニングに活用し、それを利用した新たなイラストコンテンツを生成するプロダクトを提供することはない」との姿勢を示している。

またmixi2では、第三者によるクローリングやスクレイピングなどの行為を利用規約で禁止していると説明している。

MEMO:

ブラキャニのサービス設計で考えた13のこと

未経験エンジニアなのに「Java開発5年」、経歴詐称を強要した経営者に賠償命令

非機能要件定義書の書き方について

AWS、コンテナに最適化したLinux OS「Bottlerocket」を米国政府セキュリティ標準「FIPS 140-3」に適合へ

Amazon Web Services(AWS)は、コンテナに最適化したLinux OS「Bottlerocket」を2020年9月にリリースしています。

Bottlerocketは一般的なLinux OSが備えるさまざまな機能のなかから、コンテナの実行に必要な機能だけを残して徹底的にスリムダウンし、セキュリティなどを強化したLinuxベースのOSです。Pythonなどスクリプト言語の実行系はもちろん、シェルやSSHも省かれています。

AWSはこのBottlerocketをベースに、同社が提供するコンテナサービスであるAmazon Elastic Container Service(Amazon ECS)に最適化した派生版や、Amazon Elastic Kubernetes Service(Amazon EKS)に最適化した派生版などをAMI(Amazon Machine Images)として提供しています。

オラクル、JavaScriptの商標を自主的に手放すつもりはないとDenoに通告

JavaScriptランタイム「Deno」の開発元であるDeno Landが、オラクルが所有する「JavaScript」の商標登録の取り消しを米国特許商標庁に申請した件について、オラクルはJavaScriptの商標を自主的に手放すつもりはないとDeno Landに通告したことを、Deno Landが下記のX/Twitterへのポストで明らかにしました。

MEMO:

Webアプリ受託界隈の品質有象無象問題を何とかしたい

Recoil 終了のお知らせ

MEMO:

思いつきで作ったAIツールが5000スターを獲得した話

「SMS認証、破られるリスク」 米政府機関が注意喚起

米国のサイバーセキュリティーを担当する政府機関は10日までに、ショートメッセージサービス(SMS)を使った認証について「外部から傍受される恐れがあり、強力な認証にならない」と注意喚起する声明を公表した。認証アプリなどの利用を推奨している。X(旧ツイッター)や日本のデジタル庁もSMS認証を廃止しており、見直しの動きが広がる可能性がある。

CISAは「SMSは暗号化されていないため、通信事業者のネットワークにアクセスできる攻撃者により傍受され、メッセージを読み取られることがある」と指摘する。SMS認証を使うユーザーに対し、米グーグルや米マイクロソフトなどの認証アプリに変えるよう求めた。

安全な通信手段として、米アップルの対話アプリ「iMessage(アイメッセージ)」といった「E2EE(エンドツーエンド暗号化)」と呼ばれる秘匿性の高いサービスを提示した。偽メールやSMSで認証情報を盗み取るフィッシング攻撃を防ぐため、テック大手が推進する生体認証などの「FIDO(ファイド)」を使うよう推奨している。

SMS認証を巡っては、フィッシングによる「スミッシング」が20年ごろから増えている。契約者になりすまして再発行したSIMカードを使ってスマホを乗っ取る「SIMスワップ」という手口も横行しており、国内でも23年に愛知県警や警視庁が容疑者を摘発している。

“針穴のへこみ”でデータ保存する新ストレージ 浅い/深いへこみで同じ面積に4倍のデータを記録 加熱で消去

現在の主流であるHDDや光ディスク、フラッシュメモリには物理的な限界があり、さらなる大容量化が難しい状況である。この課題を解決する新技術として、研究チームは原子間力顕微鏡(AFM)の探針を使って、ポリマー表面に微細なへこみを付けてデータを記録する手法を開発した。この技術の革新的な点は、硫黄を含む新しいポリマー材料を使用したことである。

MEMO:

ワンランク上のマネジメントの姿は、一緒に体験してみないと分からない

MEMO:

【要注意!】SES詐欺企業・代表者リスト発表

MEMO:

保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ~Software Design...

State of JavaScript 2024

MEMO:

NVIDIAが小型AIスパコン「Project DIGITS」を発表、1台当たり3000ドルで2台組み合わせて4050億パラメーターの...

MEMO:

30分でわかるデータ分析者のためのディメンショナルモデリング

tag:

プロジェクトの残業を50%削減したタスク管理手法を惜しみなく公開する

Entry-Task-Validation-Exit (ETVX)

MEMO:

ITエンジニアが遭遇する「摩訶不思議」な現象とその真相

使いたいから使うんじゃなく「必然」として使うCQRS+ES

MEMO:

テストコードのガイドライン 〜作成から運用まで〜

アクターシステムに頼らずEvent Sourcingする方法について

2年間の実運用を経て振り返るイベントソーシングの実際

【生成AIの学習ロードマップ】最近やたら羽振りのいいやつが生成AIを極めてた件について。

ytt(YAML Templating Tool)

ytt は、YAML ファイルのテンプレートとパッチ作成に使用されるコマンドライン ツールです。また、YAML の断片や山をモジュール チャンクにまとめて簡単に再利用できるようにする手段も提供します。

実際には、これらの YAML ファイルは、Kubernetes 構成、Concourse Pipeline、Docker Compose、GitHub Action ワークフロー ファイルなど、YAML 形式のあらゆるものです。

ytt は、これらのファイルを手動で管理するのが面倒になったり、面倒になりそうになったりする場合に最も役立ちます。

3年でバックエンドエンジニアが5倍に増えても破綻しなかったアーキテクチャ そして、これから

「デザインは誰のためにある?」で意見が真っ二つ→「銀杏のエスカレーター」「背景に溶け込んだ消火栓」は...

MEMO:

将棋AIの強化学習の基礎が根底から変わりそうな件

これはおそらくLLMなどの強化学習でも使えるテクニックで、強化学習での教師生成のために(探索を行って)質の高い教師を生成する必要はなく、既存の(質の低い)教師データで桁違いに大きなモデルに学習させて、そいつを蒸留するほうが低い計算コストで済む可能性がある。

Sensible SQLite defaults

MEMO:

reproio/columnify - 行指向データを列指向データ(Apache Parquet)に変換する

MEMO:

DuckDB メモ v2

MEMO:

Separating Storage and Compute in DuckDB

MEMO:

Design Doc でチームを跨いだ開発を円滑に行う

先程も述べたような差分が数百行、数千行規模の PR をいきなりレビューしてもらうのは、PR の description やコメントをいくら丁寧に書いたとしても、レビュアーの負担は大きいです。

そこで実装に入る前の段階で Design Doc を作成して、大筋の実装内容について合意を取るようにしています。

Design Doc は以下のようなアウトラインで書いています。

## このドキュメントの目的
## やりたいこと
// ここではビジネス的な視点でなぜこの施策をするのかを書きます
## 仕様
// ここでは上記のやりたいことを満たす機能要件を書きます
## 対応内容
// ここではシステム的な視点でどんな対応が必要なのかを書きます

箇条書きは無闇矢鱈にインデントしてはいけない

「評論家気取り」という作る人の行き着く先が怖い

ソフトウェア開発における「パーフェクトな意思決定」

2024年のLinuxカーネル開発を振り返る

揉め続けるBcachefs⁠、Linusはサポートを後悔!?

“開発者は殺人犯”のRaiserFSがついにメインラインから完全に削除へ

20年来の悲願⁠、リアルタイムLinuxのサポートが実現

ロシアの開発者12名がメンテナーリストから削除

7つのリニューアル!『改訂新版 良いコード/悪いコードで学ぶ設計入門』:新刊ピックアップ

こんにちは,リファクタリング大好きなミノ駆動です。『⁠良いコード/悪いコードで学ぶ設計入門』の著者です。このたび2024年12月25日に,本書の改訂新版を出版します。

私のさまざまな知見のアップデートを経て,このたび改訂新版を出す運びとなりました。改訂内容は主に以下の7つです。

  • 【変更】凝集度,結合度からカプセル化,関心の分離へ
  • 【加筆】インターフェースと実装の分離
  • 【変更】interfaceの解説を改善
  • 【加筆】インターフェースと実装の分離にもとづいたinterface設計
  • 【加筆】アンカリング効果
  • 【加筆】ジョシュアツリーの法則
  • 【加筆】説明による設計スキルアップ

順番に説明します。

GoのTestifyを使って独立したサブテストを実現する

OpenAI o3は,人間とは全く異質の汎用知能である危険性【東大解説】

DBテーブルのカラムを削除するときにやること・考えること

DMMからビットコインを盗んだのは北朝鮮だと日本とFBIが名指しで発表、これまでの北朝鮮による仮想通貨強盗まとめ

MEMO:

【本には書いてないオブジェクト指向⑧】Privateメソッド禁止

MEMO:

DNSにおける委任の構造が大きく変わる!? IETFの「deleg WG」が最近熱いらしい。再設計を目指し、慎重な議論

滋賀銀行が次世代勘定系システムの構築を中止、日立が和解金80億円を支払い

滋賀銀行は2024年12月20日、次世代勘定系システムの構築を中止することで日立製作所と合意したと発表した。日立は和解金として滋賀銀行に80億円を支払う。次世代システムの構築は一旦仕切り直しになり、滋賀銀行と日立の双方にとって痛手になる。

滋賀銀行は次世代システムについて「想定を上回るハードルの高さと銀行システムの安定的な提供という観点からサービスインの時期を延伸してきたが、早期の完成が見通せないため、プロジェクトの中止を決めた」(総合企画部)と説明する。

滋賀銀行は2020年9月、日立のオープン勘定系パッケージである「OpenStage」を利用して勘定系システムを刷新する計画を打ち出した。当初は2024年1月の稼働を見込んでいたが、稼働時期を2度にわたって延期した。

次世代システムの完成が見通せないことから、滋賀銀行は約61億円を投じて富士通製メインフレームを更改し、現行システムを使い続ける計画だ。更改時期は2027年1月を予定する。現行システムを継続利用し、次世代システムを構築する時間を確保する。

MEMO:

終了の危機にあった15年続くWebサービスを全力で存続させる

COBOL技術者の減少と、技術の「時限爆弾」に我々はどう向き合うべきか ~「昭和100年」を前に~【フォーカス】

MEMO:

北米ソフトウェアエンジニアのインタビュー選考ってこんな感じだよ

todo.txtを布教したい #Todoアプリ

MEMO:

テストコードの改革を進めている話

GoでUnion型/直和型をいい感じに表現する方法 #Go

オニオンアーキテクチャにおけるテストコーディングガイド

良いユニットテストを書こう

パスキーの本質

MEMO:

アーキテクチャを設計するといふこと

クレジットカードを使う時にアクワイアラーとイシュアーの間で通信されるメッセージの標準規格「ISO 8583」の...

NEXT