検索結果

Java様 何かは分かりませんが想像してみます😭

Javaさま 横から失礼します。 出口戦略って簡単なようで、 難しいというか…手間がかかるというか… それぞれの環境でも異なりますからね🤔

Javaさま それは素晴らしい！ 探してみます👍

「COBOL資産」とは、単にCOBOLで書かれたプログラムだけではないっす。 数百万～数千万行に及ぶソースコード 数十年かけて蓄積された業務ロジック 顧客・契約・会計などのデータ定義 メインフレーム上で動く周辺システム 運用手順やバッチ処理 これらをまとめて「COBOL資産」 銀行 保険会社 証券会社 官公庁 電力・ガス 製造業 こうした基幹システムの多くが1970～1990年代にCOBOLで構築されました。何十年も改修を重ねてきたため、「会社の業務そのもの」がコードに埋め込まれているケースも少なくありません。 例えば銀行では、 預金利息の計算 振込処理 ローン返済計算 税金計算 勘定系処理 など、長年の制度改正や例外処理が積み重なっています。仕様書だけでは分からず、「このCOBOLコードだけが正しい仕様」というケースもある。 そのため、全面的に作り直すのは非常に難しく、 解析 テスト データ移行 新システムとの比較検証 に何年もかかるプロジェクトになることがあります。 COBOLを扱えるベテラン技術者が退職する一方で、若い技術者はJavaやPythonを学ぶことが多く、人材の世代交代が課題 今回の富士通と日本IBMの協業は、こうした状況を踏まえ、AIも活用しながら COBOLコードを解析する 設計書を自動生成する Javaなどへの移行を支援する メインフレームからオープンシステムやクラウドへの移行を効率化する ことを狙っていると考えられます。従来は数年単位・数百人規模だった作業を、AIで大幅に効率化できる可能性があります。

「COBOL資産」とは、単にCOBOLで書かれたプログラムだけではない。 数百万～数千万行に及ぶソースコード 数十年かけて蓄積された業務ロジック 顧客・契約・会計などのデータ定義 メインフレーム上で動く周辺システム 運用手順やバッチ処理 これらをまとめて「COBOL資産」 銀行 保険会社 証券会社 官公庁 電力・ガス 製造業 こうした基幹システムの多くが1970～1990年代にCOBOLで構築されました。何十年も改修を重ねてきたため、「会社の業務そのもの」がコードに埋め込まれているケースも少なくありません。 例えば銀行では、 預金利息の計算 振込処理 ローン返済計算 税金計算 勘定系処理 など、長年の制度改正や例外処理が積み重なっています。仕様書だけでは分からず、「このCOBOLコードだけが正しい仕様」というケースもある。 そのため、全面的に作り直すのは非常に難しく、 解析 テスト データ移行 新システムとの比較検証 に何年もかかるプロジェクトになることがあります。 COBOLを扱えるベテラン技術者が退職する一方で、若い技術者はJavaやPythonを学ぶことが多く、人材の世代交代が課題 今回の富士通と日本IBMの協業は、こうした状況を踏まえ、AIも活用しながら COBOLコードを解析する 設計書を自動生成する Javaなどへの移行を支援する メインフレームからオープンシステムやクラウドへの移行を効率化する ことを狙っていると考えられます。従来は数年単位・数百人規模だった作業を、AIで大幅に効率化できる可能性があります。

お疲れ様っす 富士通と日本IBMの協業、ついに始動　COBOL刷新における「役割分担」は？ と 富士通がAI効率を475倍にするTransformer代替アーキテクチャ「PHOTON」を開発 二つ直接の関係はなさそうですが、富士通のAI戦略という大きな流れでは補完関係？ 富士通のFujitsu PROGRESSIONがCOBOL→Javaへの自動変換（リライト） 日本IBMのIBM BobがAIエージェントとしてコード修正やリファクタリング、テスト支援という役割分担。日本IBMが顧客向けサービスを提供し、富士通が変換技術とノウハウを提供する。協業のAIはソフトウェア開発支援AI。 PHOTONは、 Transformerを置き換える新しいLLMアーキテクチャ GPU当たり最大475倍のマルチクエリ処理性能 長文や複数AIエージェントが同時に動くような推論を大幅に効率化 というAI基盤そのものの研究成果。 PHOTONが実用化されれば、 COBOL→Fujitsu PROGRESSION→Java→IBM Bob（AIエージェント） →PHOTON上で高速・低コストに推論　という構成になるのかも。 今回のモダナイゼーションでは コード解析、業務ロジック理解、リファクタリング、テスト生成、ドキュメント生成など大量のAI推論が必要になるため、推論コストを下げられるPHOTONとの相性は良い。 富士通はAIを3層で強化している? AIインフラ：PHOTONのような次世代LLMアーキテクチャで推論コストを削減。 AI開発ツール：Fujitsu PROGRESSIONでレガシーコード変換を自動化。 AIサービス：日本IBMとの協業を通じて企業向けモダナイゼーションを提供。 富士通とIBMは、メインフレームや企業システムでは長年の競合。 今回のCOBOL資産のモダナイゼーションでは富士通の変換技術と日本IBMのAIエージェントを組み合わせる提携を発表。 量子コンピュータでは、 富士通は理化学研究所と共同で超伝導量子コンピュータを開発。 64量子ビットから256量子ビットへ拡大し、2030年度に1万物理量子ビット超を目指すロードマップを掲げています。 IBMは世界最大級の量子コンピュータ群をクラウド経由で提供。 2029年までに大規模な耐障害性量子コンピュータ「Starling」の実現を目標とし、量子コンピューティングへ100億ドル超を投資する計画を発表。 理研と連携。富士通は理研と共同で量子コンピュータを開発しています。 IBMも理研と連携し、量子コンピュータとスーパーコンピュータを組み合わせたハイブリッド計算環境の研究を進めています。 富士通はAI（PHOTONなど）と量子コンピュータを組み合わせた「ハイブリッド量子コンピューティング」を重要戦略と位置付けています。 IBMもAI（watsonx）と量子コンピュータを組み合わせる方向性を示しており、量子とAIを融合したソリューションの開発を進めています。

富士通と日本IBMの協業、ついに始動　COBOL刷新における「役割分担」は？ https://www.itmedia.co.jp/enterprise/articles/2606/25/news026.html と 富士通がAI効率を475倍にするTransformer代替アーキテクチャ「PHOTON」を開発 直接の関係はなさそうですが、富士通のAI戦略という大きな流れでは補完関係。 富士通のFujitsu PROGRESSIONがCOBOL→Javaへの自動変換（リライト） 日本IBMのIBM BobがAIエージェントとしてコード修正やリファクタリング、テスト支援という役割分担。日本IBMが顧客向けサービスを提供し、富士通が変換技術とノウハウを提供する。協業のAIはソフトウェア開発支援AI。 PHOTONは、 Transformerを置き換える新しいLLMアーキテクチャ GPU当たり最大475倍のマルチクエリ処理性能 長文や複数AIエージェントが同時に動くような推論を大幅に効率化 というAI基盤そのものの研究成果。 PHOTONが実用化されれば、 COBOL→Fujitsu PROGRESSION→Java→IBM Bob（AIエージェント） →PHOTON上で高速・低コストに推論　という構成になるのかも。 今回のモダナイゼーションでは コード解析、業務ロジック理解、リファクタリング、テスト生成、ドキュメント生成など大量のAI推論が必要になるため、推論コストを下げられるPHOTONとの相性は良い。 富士通はAIを3層で強化している? AIインフラ：PHOTONのような次世代LLMアーキテクチャで推論コストを削減。 AI開発ツール：Fujitsu PROGRESSIONでレガシーコード変換を自動化。 AIサービス：日本IBMとの協業を通じて企業向けモダナイゼーションを提供。

（続き） ────── 0割りについては、少なくとも次は防いだほうがよいです。 ・耐用年数 = 0 または null ・使用月数 = 0 の資産を月割計算に入れる ・事業供用日・除却日が不正で、使用月数が負になる ・取得価額 = 0 の資産 ・償却率・保証率・改定償却率が未設定 ・耐用年数表に該当コードが見つからない ・旧定額法・旧定率法・現行定額法・現行定率法の区分が未確定 ────── なお、旧制度も混じるならさらに危険です。 平成19年3月31日以前取得資産には旧定額法・旧定率法があり、旧定額法では有形減価償却資産について「取得価額×90%×旧定額法の償却率」という形になります。 また、旧制度では95%相当額まで償却した後、翌年以後に1円まで均等償却する説明があります。 https://www.nta.go.jp/taxes/shiraberu/taxanswer/shotoku/2105.htm?utm_source=chatgpt.com したがって、取得日で計算ロジックを分岐するテストケースが必要です。 ────── 実装上次が一番効きます。 金額は整数円、 率は浮動小数点ではなく Decimal / BigDecimal / Rational 相当で扱い、 丸め関数を1か所に集約し、 丸め方向と丸めタイミングをテストケース名に明記する。 たとえば Python なら float の 0.334 ではなく、Decimal("0.334") のように文字列から率を作るべきです。Java なら double ではなく BigDecimal です。会計ソフトでは「見た目が合う」だけでなく、 毎年の償却費、 償却累計額、 期末帳簿価額、 最終1円、 定率法の改定年度 まで、表形式の期待値でユニットテストすると安全です。 ────── 最後に追加で言うなら、これは大事です。 “会計上の償却額” と “税務上の償却限度額” を同一視しない設計にしたほうがよい。 法人税務では償却限度額、会計では会社の償却方針、個人事業では強制償却など、文脈が違います。 国税庁の説明も、定額法・定率法の計算方法、中途取得時の月割、定率法の保証額・改定償却率など、税務計算上の枠組みとして整理されています。 https://www.nta.go.jp/taxes/shiraberu/taxanswer/shotoku/2106.htm?utm_source=chatgpt.com ────── まとめ 減価償却は、数式よりも端数処理・最終年度キャップ・定率法の改定償却・取得日による旧制度分岐がバグ源になりやすいので、そこだけ仕様とテストを厚くしたほうがよさそうです。 ────── おわり

やめて！夜間PTSの特殊能力で、2,575円の夢を焼き払われたら、含み益と繋がってるLiNKXホルダーの精神まで燃え尽きちゃう！ お願い、死なないでLiNKX！ あんたが今ここで倒れたら、COBOL刷新やJava移行の未来はどうなっちゃうの？ 東証終値比ではまだプラス。ここを耐えれば、明日の寄り付きで勝てるかもしれないんだから！ 次回「LiNKX死す」 デュエルスタンバイ！

LiNKX！LiNKX！LiNKXぅぅううう！！！ あぁあああああ！！！レガシー刷新！レガシー刷新ぃぃいいい！！！ COBOLで動く基幹システムを、Javaみたいなモダンな環境に移行したいお！保守したいお！DXしたいお！ 古いシステムが残り続けるのに、触れるエンジニアは減っていくんだお！でも企業は止まれないんだお！クラウド化したいんだお！AIも使いたいんだお！ うわあああああ！！！LiNKXたん！金融基幹系モダナイゼーションしてくれえええ！！！