フロントエンドカンファレンス北海道2025実行委員会の実行委員長を務めております、n13u（西村航）です。この度は当実行委員会が運営する公式ウェブサイトの乗っ取りにつきまして、皆様に大変ご心配をおかけいたしました。
現在、公式ウェブサイトでは対応を行い2024年度開催分のページが公開されています。また、後述する原因に基づき、各種設定の見直しを行い再発防止策を実施済みです。公式ウェブサイトへのアクセスについて問題なく行えることを確認しておりますが、DNSレコード設定の反映等で一部の環境にて正しくない、または不正なウェブサイトが表示される可能性もございます。反映が完了する数日程度は継続してウェブサイトの閲覧をお控えいただくようお願いいたします。
まとめ
- Go におけるエラーハンドリング冗長性は長年の課題である。
- Go チームは check/handle → try → ? と三度の大規模提案を試みたが、いずれも広範な合意に至らず撤回された。
- 構文変更にはメリットもあるが、デバッグ容易性や設計哲学、移行コストなどマイナス面も大きい。
- 当面は構文をいじらず、ライブラリやツールでの支援に軸足を置くという結論に落ち着いた。
窮屈で仕方ない。決められたものを、決められた日までに作るだけ——プロジェクトの成功とは、そういうものなのか。
そんな疑問が頭をもたげるスクラムチームは、自らを “もどき” だと感じるようになります。スクラムで開発しているはずが、気づけば違うものに変わってしまっていた、と。
はじめから “何を作るか” にばかり集中すると、そうなります。そして、チームは次の四段階を経て、静かに侵食されていきます。
- はじめから全体を詳細に詰める
- 決定を開発へ一方通行で流す
- すべてのパーツを作ってから組み上げる
- スプリントレビューを進捗報告の場にする
優れたアイデアやデザインがあっても、それだけではソフトウェアプロジェクトを成功させることはできません。プロジェクトを円滑に進めるためには、ステークホルダーの理解と支持を得て、チームが協力できる環境を作ることが重要です。本書では、そのために不可欠で効果的なコミュニケーションの方法を解説します。具体的な例やパターンを通じて、適切にメッセージを伝えるためのドキュメントや図の作成方法を紹介します。
まず、ソフトウェアアーキテクチャの視覚表現を活用し、受け手にわかりやすくメッセージを伝える方法を解説します。次に、書面・口頭・非言語コミュニケーションの技法を用いて、相手に意図が正しく伝わるように工夫する方法を紹介します。また、ナレッジマネジメントを強化し、チームや組織の集合的な知識を最適化することで、生産性と革新性を向上させる手法についても解説します。さらに、アーキテクチャに関する重要な意思決定を的確に記録し、関係者と共有する方法を学びます。そして、リモートやハイブリッド環境において、同期・非同期の手法を適切に使い分けながら、円滑に連携するためのアプローチについても詳しく説明します。
『Five Lines of Code — How and When to Refactor —』(Christian Clausen著、MANNING刊)の日本語版。
リファクタリングはソフトウェア開発やプログラミングの世界においてコードの品質向上や保守性の確保のために重要です。 何をリファクタリングすべきかは、問題の兆候を示す「コードの臭い」で説明されてきましたが、この概念は抽象的で、経験の浅いプログラマーには理解しづらいものでした。
本書では、「メソッドを5行以内で実装する」といった明確なルールを用いてリファクタリングを行うテクニックをステップバイステップで解説します。ルールの解説後には、そのルールの元となった「コードの臭い」についても説明されており、効率的に「コードの臭い」への感覚も養うことができます。
第1部では、GitHubで公開されている2Dパズルゲームのコードを主要な題材としてリファクタリングのプロセスを示しながら、適用するルールやパターンを解説します。
第2部では、チームでの開発にも焦点を当て、ルールとリファクタリングパターンを実務でどう活用するかを掘り下げます。コンパイラの機能の活用や、コメントを極力書かないようにするためのコツ、価値あるコメントの見極め方、コードの安全な削除／追加方法、将来的なリファクタリングで見落とされないように悪いコードをさらに悪く見えるようにして品質レベルを明確にするテクニックなど、実践で役立つトピックを広範に扱っています。
新山祐介さんの投稿で知ったが、プログラミング技術に関するナレッジコミュニティ、共同創業者のジョエル・スポルスキーの表現を借りれば「ロングテールなプログラミングの質問のWikipedia」である Stack Overflow だが、「ほとんど死んだ」と評されている。
「投稿される質問の数はピーク時の1/10程度、黎明期の2009年あたりの数まで激減している」というのはショッキングである。
投稿される質問数でいえば、2014年～2017年あたりがピークで、コロナ禍が始まった2020年にも急上昇しているが、その後衰退期に入り、ChatGPT 開始とともにダメ押しのごとくガクッと下がっている。やはり AI が Stack Overflow の衰退を後押ししている。
AI活用が当たり前になる開発環境において、コードの「なぜ」を残すことは、技術的負債を防ぐ重要な実践だ。2年後により良いAIが登場したとき、過去の意思決定を理解できれば、真に価値のある改善が可能になる。
私たちエンジニアは、常に未来の自分や同僚のことを考えてコードを書いてきた。可読性、保守性、拡張性—これらはすべて「未来の誰か」のための配慮だ。AI時代においても、この精神は変わらない。むしろ、AIの進化速度を考えれば、より一層重要になる。
プロンプトは新しい形の設計書だ。コードレビューと同じように、プロンプトレビューが必要になるかもしれない。リファクタリングと同じように、プロンプトリファクタリングが日常になるかもしれない（プロンプトの可読性を議論する日も近い）。
PDRのような仕組みの標準化は、AI時代のソフトウェア開発における必須要件となるだろう。エンジニアとして、この課題に真剣に取り組む時期に来ているが、個人ではどうにもならない気もするので。頑張れ、Anthropic！！！
ソフトウェアテストには、対象とする品質要件に応じて様々な「手法」が存在します。しかし、個別のテスト手法を断片的に学ぶだけでは、プロダクトの品質を総合的に高めることはできません。本書は、複数のテストを補完的に組み合わせて、あらゆる側面から品質を検証するための技術・戦略を、体系的に学べる骨太なガイドブックです。
取り上げるのは、以下10種のテスト手法。それぞれについて、テストの原理原則・導入戦略・実践方法を、具体的なWeb／モバイルアプリケーションでの適用例を交えながら詳しく解説します。
□手動探索的テスト
□自動テスト
□継続的テスト
□データテスト
□ビジュアルテスト
□パフォーマンステスト
□セキュリティテスト
□アクセシビリティテスト
□モバイルテスト
□クロスファンクショナルテスト
本書は、各領域のテストを一貫した視点で解説するため、それぞれのテストの「役割」と「つながり」がよく理解できます。本書を通じて、広大なテスト分野を迷わず歩くための「体系的な知識地図」をインストールしてください。
【石破茂首相の発言】
「税率変更する時に、一体どれくらいの期間がかかるかということでございます」「スーパーを見れば分かりますが、そのシステムを変えるだけで1年はかかるということでございます」
（5月21日、立憲民主党の野田佳彦代表との党首討論で）
首相発言が「レジの変更に1年」と拡散 SNSで批判
石破茂首相は21日、立憲民主党の野田佳彦代表と党首討論をした。
物価高対策として、食料品の消費税を1年間ゼロにすると掲げた野田代表に対し、「減収が5兆円になる」と指摘。さらに、「スーパーのシステムの変更」に1年かかると述べた。
討論後、フジテレビが首相発言を「スーパーのレジなどシステム変更に1年かかる」などと伝えた上で、都内の商店街の小売店主らの「1日でできる」「一晩」などといった意見を報じた。SNS上では、首相の「1年発言」に対し、「1年もかかるわけねえだろ」「すぐばれる言い訳」などの批判が拡散した。アカウントの中には、投稿が見られた数や影響力などを示す「インプレッション数」が800万を超えたものもあった。
加藤財務相「短期間で可能とする事業者もいたが……」
首相が言う「スーパーのシステム」について財務省は、店内に複数レジがあるスーパーや小売りチェーンなどで導入されている、各レジの売り上げを集計する「POSシステム」としている。
加藤勝信財務相は27日、参院財政金融委員会で野党議員の質問に対し、複数の大手システム事業者への聞き取りの結果として「短期間で対応可能とする事業者があった一方で、少なくとも1年は要すると見込む事業者も複数あった」と答弁。「1日でできる」という声を紹介した一部報道については、「個人商店の場合は、割と簡易なシステムでありますから、そういった声も確かにある」などと述べた。
大手メーカー「1年以上でもおかしくない」
実際、POSシステムの税率変更にどれほどの期間が必要なのか。合わせて業界シェアの7～8割を占める大手システムメーカー3社（東芝テック、富士通、NECプラットフォームズ）に聞いた。
そのうちの1社の担当者によると、「個人商店などで使う単体の電子レジスターの設定変更なら別だが、POSシステムの税率変更はシステム改修が必要。過去の税率変更の際も、すべての顧客の対応が終わるのに1年はかかった」と話す。
別の社の担当者も、税率変更に伴いPOSシステムに関連する会計管理システムや在庫管理システムのチューニング（調整）が必要になると説明する。「期間限定かどうか、軽減税率をどうするかなどでも所要期間は異なるので一概に言えないが、1年以上かかったとしてもおかしくはない」という。
この2社によると、消費税をゼロにする場合は、「そもそもそういう設定を想定しておらず、新たなシステム開発に近い」ため、単なる税率変更よりも改修期間が長引く可能性があるという。
一方、「そこまで大規模な改修は必要ないので、数カ月から半年」とした社もあった。この社では、外食産業や小売りチェーン、企業の社食のシステムを多く担当しているという。
ただ、「あくまで、メーカー側で要する時間。小売り側の都合やスケジュールもあるので、実際は数カ月から半年より、もう少しかかるのではないか」と話している。
【判定結果=ほぼ正確（一部は不正確だが、主要な部分・根幹に誤りはない）】
スーパーやコンビニ、小売りチェーンなどで使われるレジの販売記録を管理する仕組みは、「POSシステム」と呼ばれる。システムメーカーの大手3社に取材したところ、2社はシステム改修などが必要になるため1年以上かかる見通しを示し、1社は数カ月から半年と回答した。
本書は、コードレビューに関する実践的なガイドブックです。「なぜコードレビューを行うのか」から始まり、ワークフローの徹底解説、最初のプロセスの構築と、段階的に解説します。さらに高度な要素として、「チームワーキングドラフト」「自動化」、そして最も大事な「効果的なコメント」について、じっくり説明します。「伝わるコメント」には、言葉遣いや文章のトーンが重要で、それを実現する著者の経験から生まれたメソッドが明かされています。
本書を通して、ソフトウェアテストの知識・技術を体系的に学びます。そしてその中でテストによって次の課題にどのように対応していくか学び、現代的なソフトウェア開発に対応するため総合力・基礎力を強化します。
- 開発成功や顧客満足実現をどう支えるか
- 開発の高品質と高スピードの両立を支えるアプローチとは
- アジャイルや継続的デリバリー、DevOpsの導入にどう対応するか
- テスト自動化といったテスト技術導入を成功させるには
- チーム全体でテストを推進していくためには
- 定番のテスト失敗要因に対しマネジメントでどう対策すべきか
総務省は2025年5月29日、情報流通プラットフォーム対処法第20条第1項に基づき、新たに4者を「大規模特定電気通信役務提供者」として指定すると発表しました。違法・有害情報の拡散防止や削除対応の迅速化を目的とした措置です。
今回指定されたのは、Pinterest Europe Limited（Pinterest）、株式会社サイバーエージェント（Amebaブログ）、株式会社湘南西武ホーム（爆サイ.com）、株式会社ドワンゴ（ニコニコ）の4社です。ドワンゴの「ニコニコ」については、同法施行規則に定める一部サービスを除外対象としています。
情報流通プラットフォーム対処法は、インターネット上での権利侵害の救済と表現の自由の両立を図る法制度であり、大規模事業者に対して削除申出窓口の整備や削除判断の通知、運用状況の公表などを義務付けています。これにより、利用者が被害を受けた際の対応を迅速かつ透明に行えるようにする狙いがあります。
総務省は今後も対象事業者の追加指定を検討しており、指定を行う際には改めて発表する方針です。
他人がAIに書かせた記事を読みたいと思います？
自分が読みたい文章を、いくらでもAIに書かせられるのに。
他人に教えて欲しいのは、有用なプロンプト(切り口、観点)だけでは？
それを自分好みにアレンジして、自分が読みたい文章をAIに生成させた方が自分好みの文章が読めますよね。
GoでLuaのユニットテストを書くモチベーション
端的に言うとGoで書いているアプリケーションサーバでValkeyを使っており、Valkeyの機能を拡張するのにLuaで処理を記述する必要が出たためです。
- ブラウザ上で動作するオープンソースのゲームエンジン「PlayCanvas Engine」、バージョン2.7.5にアップデート
- 3D Gaussian Splattingを用いた3DCGデータを圧縮する「SOGS」が導入
- 「SOGS」を活用したサンプルシーンも公開中。約1GBのデータを55MBに削減した結果を確認できる
SQLite-JS is a powerful extension that brings JavaScript capabilities to SQLite. With this extension, you can create custom SQLite functions, aggregates, window functions, and collation sequences using JavaScript code, allowing for flexible and powerful data manipulation directly within your SQLite database.
SQLite-JS は、SQLite に JavaScript 機能を追加する強力な拡張機能です。この拡張機能を使用すると、JavaScript コードを使用してカスタム SQLite 関数、集計関数、ウィンドウ関数、照合シーケンスを作成できるため、SQLite データベース内で柔軟かつ強力なデータ操作を直接実行できます。
1. WindowsはMicrosoftの優先事項ではない
2. Linuxが有力なゲームプラットフォームに
3. Linuxは使いにくいわけではない
4. Linuxデスクトップへのソフトウェアのインストールは容易
5. LinuxはWindowsよりもはるかに安全
とはいえ、Linuxデスクトップにも問題はある。Linus Torvalds氏（伝説の人物であり、Linuxの公式マスコット「Tux」の生みの親）の言葉を引用すると、「さまざまなベンダーの断片化がLinuxデスクトップの発展を阻害してきた」。現在では、270種類以上のLinuxデスクトップディストリビューションが存在するため、適切なものを選ぶのは本当に大変だ。「Ubuntu」の開発元であるCanonicalでさえ、Linuxデスクトップを最優先事項にしていないことも忘れてはならない。
(1) 収益性を重視し、設備投資が抑制された
(2) 基地局の調達を国内ベンダーに依存していた
(3) 「なんちゃって5G」を導入しなかった
販売管理システムのRFP回答をすべてのベンダーから辞退されてしまい、内製でやるしかないとコンサルから提案されるも弊情シスの誰も内製出来ないから詰んでる。
ニッチな業界のケースでパッケージは存在するものの魔改造＆短納期リクエストに変更してしまったため総スカン喰らってる。コンサルはベンダー選定までの支援契約で結局内製方針をぶち上げて「あとは知らね」のクロージングモードに突入。
■ Go に今逆風が吹いている
記事の冒頭では、フィンテック系スタートアップのエンジニア Yash Batra が半年で Go から Kotlin へ全面移行した体験を取り上げている。Batra は「 私たちはツールを作るためにツールを作っていた 」と述べ、Go の最小主義がプロダクト開発の速度を著しく低下させたと回顧する。
また、長年 Google で Go を率いてきた Ian Lance Taylor が 2025 年 4 月に退職したことも、コミュニティに衝撃を与えた。Taylor は「Go は“単なる一言語”の段階に到達した」と述べ、環境変化に合わせた言語進化の必要性を強調した。
Go は 2007 年に Rob Pike、Ken Thompson、Robert Griesemer が開発し、クラウド・インフラ向け言語（“C of the Cloud”）として脚光を浴びた。しかし 2022 年頃から、早期採用者の間で「プロトタイピング専用言語」「入門用言語」として位置づけ直す声が増え始めた。背景にはエコシステムの限界や AI ワークフローとの相性の悪さがある。
Go から離脱する開発者が挙げる代表的な不満点は次のとおりだ。
- エラー処理が冗長で、同じ if err != nil パターンが散在する。
- goroutine は強力だが、競合状態や静かな失敗を招きやすく、テストが難しい。
- “No frameworks” 文化により、共通機能を一から実装する負担が大きい。
- Go エンジニアの母数が少なく、採用・オンボーディングコストが高い。
- 生成 AI が慣用的な Go コードを出力しづらく、Python などに比べ生産性が劣る。
一方で、パフォーマンスとシンプルさを兼ね備えた Zig、豊富なツールチェーンを持つ Kotlin、安全性と速度で評価される Rust などの新たな言語は、Go言語への不満を解消する選択肢として、開発者たちの関心を集めているという。特に Zig は GC を持たず、async/await を標準搭載する点で注目されている。
フューチャー株式会社の有志が作成する良いアーキテクチャを実現するための設計ガイドライン
WebAPI設計ガイドライン
バッチ設計ガイドライン
DB設計ガイドライン
Terraform設計ガイドライン
データマネジメント設計ガイドライン
Gitブランチフロー規約
Markdown設計ドキュメント規約
コードレビューガイドライン
Slack利用ガイドライン
Joel on SoftwareにNetScapeを例に、古いプログラムを捨てて1から書き直したくなるのは戦略ミスだって書いてあるけど、あのとき書き直してなかったら続いてないんではって思ったので、1から書き直して続いてるソフトウェアを挙げてみる。
Joel on Softwareには、移行のための3年というのはインターネットの世界では非常に長いと書かれていたけど、それから20年たって動きも落ち着いて、3年はそう長くないようにも見える。 AIに関わらないプロダクトだと、3年のギャップはそこまで問題にならないんでは。逆にAIに関するプロダクトは3ヵ月の遅れが致命的になってる。
ただ、見返してみると、FirefoxもWindowsもmacOSも、20世紀のコードを21世紀に入って捨てたもので、それ以降は安定して書き換えるという話になってないですね。
はてなブログも、2012年くらいに稼働してると思うけど、それ以降はコードベースが古いという話になっていないです。
企業システムも、メインフレームからオープンシステム、自前サーバーからクラウドのようなアーキテクチャ変更がモチベーションにあるように思います。
インターネットの世界も落ち着いて、16bitから32bit、クラウドやスマホのような実行基盤の変更も起きないように見えるので、今後は新しい実行環境で動かすために1から書き直すということは減っていきそう。
創業期につくったシステムが成長が一段落したときにユースケースが変わっているので作り変える、といったことはあるのかもしれないけど。
Linux Foundation傘下でKubernetesを始めとする多数のクラウドネイティブ関連のプロジェクトをホストするCloud Native Computing Foundation（以下、CNCF）は、2018年に同団体に譲渡されオープンソースとして開発が続けられてきたメッセージングミドルウェアのNATSの開発元であるSynadiaが、NATSプロジェクトをCNCFから撤退させ、非オープンソースライセンスであるBusiness Source License（BUSL）を適用する意向であると通知してきたことを明らかにしました。
さらにSynadiaの法律顧問はCNCFに対して書面にて、NATSプロジェクトのドメイン名である「nats.io」とGitHubのリポジトリの完全な管理権を2週間以内に引き渡すことも要求してきたとのことです。
CNCFはSynadiaからの要求に対してこれを拒否し、GitHubには関連のIssueを提起、メンテナに連絡を取るなどの措置を講じていると説明しました。
後述するようにSynadiaは後日この要求を撤回し、CNCFとともにNATSのプロジェクトの発展に貢献することを表明。本件は落着しています。
一方で今回のNATSの例は、開発元からCNCFへとソフトウェアが譲渡され、コミュニティによってそのソフトウェアが育成された後に、開発元が自社都合でそれを撤回したいという主張です。契約面でも信義の面でも受け入れられるものではないでしょう。
もしこれがまかり通るようなことがあれば、Linux FoundationやCNCFのようなオープンソースの団体が築いてきた信用や、オープンソースソフトウェアに対する信頼に傷が付くことになりかねません。
CNCFがこの問題を明らかにしてから約1週間後の5月1日、CNCFはSynadiaとの話し合いの結果、NATSプロジェクトを引き続きCNCFがホストし、SynadiaはNATSの名称とロゴをCNCFに譲渡すること、同社が今後もNATSへの主要なコントリビュータとして活動を継続すること、などにより本件が無事に決着したことを明らかにしました。
Synadiaがなぜ要求を撤回したのか、などについての説明は行われていませんが、GitHubでの議論を見る限りNATSへの失望とプロジェクトのフォークを要望する声が多く見られました。
つまり、もしもSynadiaがCNCFからNATSを取り戻せたとしても、CNCFのプロジェクトとしてNATSのフォークが採用され、現在のNATSのコミュニティとエコシステムはそのフォークされたプロジェクトのものになる可能性が高いと考えられます。
そうなった場合、SynadiaがNATSを取り戻す価値は薄れてしまいます。あくまでも想像ではありますが、こうした状況がSynadiaの当初の要求を撤回させたことにつながったのではないでしょうか。
(1) 画面表示と画面遷移を記述する仕様書は機械可読にできる
(2) 仕様書が機械可読であれば仕様の静的検査ができる
(3) 静的検査によって自身の担当範囲の15%の画面から計40件弱の欠陥を発見した
(4) 機械可読な仕様書にはさらなる応用が見込める
負荷対策とかの話題に続いて、今度はバッチ処理を書く上での注意点。
普通のWeb APIなら書けます、って人にバッチを書いてもらうといろいろとやらかしちゃうことが多いので、バッチ特有の注意点みたいなのをまとめておく。
当方ゆめみ社員。
買収の話は発表からそこそこ前に聞いていた側の人間。
Xでふざけたポストをしているアホ代表に一泡吹かせたいので裏話を書く。
https://x.com/raykataoka/status/1921546847342285023
とはいえマジでやばいことを書くのは仲間に申し訳ないので、まあこれくらいはいけるやろってものだけに留める。
■ 雑多なネタバレ
1,2ヶ月くらい前からか一部メンバーに情報が情報が公開されてきた。
辞められるとインパクトがありそうなメンバーに少しづつ展開していくことで、ショックを抑えることや、事前の動きがやりやすいようにすることが目的のようだった。
Slackには珍しくプライベートチャンネルが作られ、丁寧に社内での開示リストも作られた。厳格な情報管理がなされていた。
この人にはさっさと開示した方がいいよねとか、ショックで倒れるかもしれないからやめておこうとか、みんな悩みながらも事前開示が進められた。
私も何名かを提案し開示したりしたが、中には今後を考えると話しおきたくても話せないメンバーもいて、もやもやを抱えた。
このプライベートチャンネルは特殊なチャンネルである。
正社員向けのプライベートチャンネルとは別の、一部メンバーへの情報共有を行う専用チャンネルだ。
このネタバレは私の精一杯の抵抗である。
とはいえ、社内でも大っぴらに言えないことがあるくらい、ゆめみ社員にも理解してほしい。
このチャンネルは以降コアメンバーチャンネルと呼ぶ。
コアメンバーチャンネルを辿るといろんなことがわかる。買収話を受け取った初期はアホ代表も迷っていたらしく、一部のメンバーと相談していた。
普段はえいやだとかで威勢のいい意思決定をする彼も人の子。彼もそれなりに不安だったようで、役員とかの中心メンバーの顔色は伺っていた。
独断で決めたわけではないわけだ。（そら当たり前だけどね）
情報の一般公開までの連携は見ていてとても丁寧な印象を受けた。
プレスリリース文のレビューや推敲は何度も行われた。
直前にあった PRTIMESの情報漏洩 も迅速に共有され、
直前でプレスリリース方法も変えたりしていた。普段ギュンギュン言うてるあの人 も、振る舞いはおかしいけどちゃんと仕事をする。
情報の一般公開がなされた後も、コアメンバーチャンネルでは社員のケアについての議論が続いている。
アホ代表は社員によるXを含む社内外の情報発信をみながら、気になった社員についてはギルドオーナー(いわゆる課長っぽい人たち)へのケアを要請した。
私もX含め社員の状況はウォッチしている。まあ大丈夫かなって思っていた人に対しても、やはりケアしてほしいとのことだった。
あのアホ代表はXでの振る舞いこそ害悪っぽいが、裏ではそこそこ神経質になっている。好きな子に素直になれない男子小学生かよ。
ケアといっても明確に残留の説得しろとは言われていない。
私の解釈では、とりあえず不安に押しつぶされないような精神的なケアを求めている認識である。
8日に開催された全社会で全社員への情報公開が行われた。
普段は芝居がかってて面白くないアホ代表が、今までになく緊張しながら喋っていた。誰が見てもわかるくらいには緊張していた。
あの様子の代表が見れただけでも今回の騒動はお釣りが来るかもしれない。
当日に開催された日本酒会では珍しくアホ代表も登場した。彼は普段そういう飲み会には出てこない。
アクセンチュア内部からと思われる怪文書に対しても、Xで発信する前には皆を不安にさせないためメッセージをアホ代表は発信していた。
具体的には伏せるが、彼は彼なりに良い状況を作るための努力をする宣言をしていた。
先にXへ怪文書を送らなかったのは評価する。
この文章はつまるところアホ代表へのフォローであり意趣返しである。
アホ代表含めて複数のメンバーが裏で多大な努力を費やし、社員のために何かを守ったり何かと戦っていることを伝えたい。
■ 最後に関係者へのメッセージ
転職エージェントや他IT企業の皆様へ。
私は可能な限り多くの人が船に乗ってくれるよう努力するのですが、それでも起きるミスマッチについては深追いしません。
たくさんスカウトやDMを送って、ゆめみのみんなに新しい可能性を提示して欲しいです。
アクセンチュアの方へ。
見ての通り私たちは結構不安です。もしよければ良いところについても発信いただけるとありがたいです。
そしてこれから仲良くして欲しいです。私たちから呑みに誘ったりしたいので、快く一緒していただけると幸いです。
ゆめみ社員へ。
あのアホ代表がいつまであの調子でいられるか見てやろうじゃあないですか。
我々が決別するのは、奴が泣いて逃げるのを見てからでも遅くないぞ。
怪文書だ
みなさん、新たな節目として弊社にJoinくださることを嬉しく思ってます
新しい環境に不安かとも思いますが、その不安を少しでも和らげるために、先んじて情報をお伝えしておこうかと思います。
■ みなさんの立ち位置について
報道にもある通り、みなさんはSongと呼ばれる部署への配属になります。
社内的には、「システムのできない人達」「bizとtechを分けたがる人たち」「どれだけ客の偉い人と話せるかが評価指標の人たち」といった感じです。
システム案件に偉い人主導で人が投入されつつ、コーディングするわけでもない（できない人たちが多い組織）ので顧客接渉や要件定義を頑張るなんて立ち位置に置かれることが多いです。
biz寄りですが、昨今の複雑化した社会では、顧客より業務に詳しくなるなんてほとんど不可能です。口八丁で色々頑張りつつ聞き出しつつ、謎の要件定義を量産し、techサイドから白い目で見られるのが主なお仕事となります。
なお、技術に明るい社員がとても少ないため、御社のことを知らない人がほとんどです。今技術が得意な人たちだとしても、口先仕事とお絵描き仕事を求められることが多いでしょう。
■ 社内環境について
報道にもある通り、週５出社です。
ただし、席が足りていないので、会議スペースを占拠したり、電話ブースを占拠したり、立ち席のカウンターを占拠したり、色々と頑張る必要があります。
ちゃんとした席で仕事をしたければ、パワーバランスの強いプロジェクトに配属されるか、朝早く出社すればフリー席も確保できるかもしれません。
なお、システム案件の主なオフィスである勝ちどきについては、駅から遠く、かつ勤怠システムに入力するためのPC起動に５分くらいは要するため、始業の30分前には駅に着いていることが望ましいです。
あとは、20時になるとエアコンは切れるため、これからの季節気をつけて下さい。
また、出社しているのに、会議室が足りないので、みな自席でTeams会議(Zoomは使いません)をしていてうるさいです。耳栓かイヤホンを持ってきましょう。
■ PCについて
グローバルで共通のPCとなるため、USキーボードになります。やったね。
前述の通り、起動するまでにすごく時間がかかります。社内標準ツールが満載(何をしているかなどもトラッキングされています)なので、そのせいかもしれません。
また、Windows Defenderを標準装備かつ自分で例外を設定できないため、今まで利用されていたPCと同じ様に使えるとは思わない方が良いです。
Macを使いたい？パワーポイント書くのが主であり、iOSアプリ開発者でもないあなたに割り当てられることは無いでしょう。
■ 開発環境について
運良くあなたのポテンシャルに気づいてもらい、システム開発を任されたとします。
前述のPCの説明の通り、今まで通り開発できるとは思わない方が良いです。
Defenderの例外指定などできないので、Node.jsを使おうものならものすごいストレスに苛まされることになります。
PCのスペックが人権を満たしていないのもありますし、謎のツールと設定のために、VSCode史上最悪のユーザ体験を経験できると思います。
OSS系製品がことごとく遅くなるため、git自体も遅いし、コミットログ書くのにvim呼び出すのも遅いです。こんなイライラするgitを入社して初めて触りました。
サクラエディタは読み込むファイルが少ないからか早いので、サクラエディタでコーディングしても良いかもしれませんね。
■ 時代はAIだよね
AIをやりたい？諦めて下さい。
弊社は大企業なので、許可されたツールしか使えません。Clineに全て賭けてしまった？残念です、その賭けはあなたの負けです。使えるわけがありません。
社内の謎ChatGPTもどきを活用してください。AIを活用するのである！流行りは使わせないし、具体は指示しないけど という意味では、AIに対するVives（雰囲気）なコーディングはできるかもしれません
■ 社内の技術について
システム開発案件に参画できた場合、Javaをやらされる可能性が高いでしょう。
社内の謎開発テンプレートがあり、それに沿って進めるため、まずはあなたの常識を捨てるところからスタートしましょう。
なんでこんな書き方をしているの？とか思ったら負けです。Node.jsを使いたい？我々は、実績あるJavaが好きなのです。
また、gitをちゃんと使えない技術者が多く、コミットログという概念がありません。何をレビューするんだコレでという単位のコミットや、何を言っているんだというコミットログを気にしなくなったら、あなたも立派な弊社の一員です。
■ 評価について
あきらめてください。
日本の業績がどうであろうと、世界での業績が悪ければ全部そちらに吸われていきます。
世界の状況については、ロイターなどで見てみるとわかると思います。トランプさんとマスクさんが支出絞ってるからね。公共系のお仕事そりゃなくなっちゃうよね。
ここ数年は基本的に昇給はありません（ニュースにもなっているので検索してみてください）。そして、昇進についても枠が狭すぎるのとキューが詰まりすぎているので、まず無理だと思って下さい。
残された戦略は、当面はがんばらず耐える のみですが、みなさんのJoinも含め、人が増えすぎている現状です。一定レベル以上のクラスは空きがないので、レイオフ待つしかないのかもしれません。
■ せめて英語ぐらい覚えてから転職しようかな
社内で飛び交う英語は、あったとしてもインド英語です。がんばってね。
そして、TOEICについては、昇進の基準にもなっているので、まずはそこから頑張りましょう。
■ 激務なんですか？
勝ちどきオフィスが何時まで電気ついてるか見てみてもよいかもしれませんね。
■ なんでそんな会社にいるんですか？
なぜでしょう？ただ、会社の名前に誇りを持っている人は多いですね。俺はアクセンチュアだぞ！みたいな。だっせぇ
今いる人は、私含めて今いるレベルな人だから かもしれません。
■ 最後に
みなさんのご活躍をお祈りします！
Qdrant（クアドラント）は、ベクトル類似性検索エンジン兼ベクトルデータベースです。ポイント（ベクトル）を保存、検索、管理するための便利なAPIを備え、実稼働環境でも利用可能なサービスを提供します。また、ペイロードも備えています。Qdrantは、拡張フィルタリング機能に対応しており、ニューラルネットワークやセマンティックベースのマッチング、ファセット検索など、あらゆるアプリケーションに利用できます。
Redisは昨年（2024年）3月に、それまでのオープンソースライセンスから商用サービスによる利用を制限するRedis Source Available License (RSALv2)とServer Side Public License (SSPLv1)のデュアルライセンスに変更しました。
ある意味で同社の狙い通り、このライセンス変更が発表された翌月の2024年4月には、AWSが中心となりLinux Foundation傘下でRedisのフォークとして「Valkey」プロジェクトが開始され、Google Cloud、Oracleなど多くのベンダが協力を表明。
こうした状況を受けて、Redis 8.0ではオープンソースライセンスであるAGPLv3が追加され、オープンソースライセンスに復帰することとなりました。
2024年3月にRdisの非オープンソース化を決断したRedis CEOのRowan Trollope氏は今回のオープンソースへの復帰に関して、Redisのオリジナル開発者であるSalvatore Sanfillipo氏（通称：antirez氏）が昨年11月にデベロッパーエバンジェリストとして同社に加わったことを紹介しつつ、同氏の当初のビジョンに従ってRedis を進化させながら、開発者が愛するプラットフォームを作っていくとしています。
株式会社ゆめみ（本社：京都府京都市、代表取締役：片岡俊行、以下ゆめみ）は、アクセンチュア株式会社（本社：東京都港区、代表取締役社長：江川昌史、以下アクセンチュア）による買収に合意しました。本合意に基づく株式譲渡の完了後、アクセンチュアとともに革新的なデジタルサービスを顧客とともに企画し、圧倒的なスピードで市場に投入するための体制を強化します。また、運用フェーズでも顧客に寄り添い、顧客インサイトに両社のデータ・生成AI活用の知見を融合させることで、デジタルサービスの継続的な進化を支援します。これにより、顧客の事業成長を一貫して支える仕組みを拡充させます。本合意の条件は非公開です。
Go言語製のMQTTサーバらしい
5月7日、Nue JSが「Hyper: Outperform React on every metric」と題した記事を公開した。この記事では、Hyperという新しいマークアップ言語が、Reactを凌駕する可能性があるという点について詳しく紹介されている。
■ Hyperの特長
- (1) シンプルな構文: Reactに比べて、必要なコードの量と認知負荷が大幅に削減される。
- (2) デザインとロジックの分離: HyperはCSSでスタイルを管理し、コンポーネントコードは純粋なロジックと表示に専念できる。
- (3) 軽量: Hyperのコードは非常に軽量で、ブラウザで直接動作し、コンパイルを最小限に抑える。
- (4) 再利用可能なコンポーネント: Hyperではコンポーネントの再利用が容易で、プロジェクト間でのスタイルや設計変更もシンプルに行える。
企業のプレスリリースの配信を手がける「PR TIMES」は、サイバー攻撃による不正アクセスを受け、利用者の氏名やメールアドレスなど、最大90万件余りの個人情報が漏えいした可能性があると発表しました。
会社の発表によりますと、4月25日、サーバーに不審なファイルがあることを検知し、調査したところ、外部から不正なアクセスがあったことがわかったということです。
漏えいした可能性があるのは、この会社のサービスの利用者の氏名やメールアドレス、所属している企業名や電話番号など、最大90万件余りです。
また、発表前の企業のプレスリリース1682件も漏えいした可能性があるということです。
会社は、すでに不正な侵入経路を遮断する措置をとるとともに、警察にも7日に被害を申告したということです。
「PR TIMES」は「皆さまには、多大なるご心配をお掛けする事態となりましたことを、改めておわび申し上げます。発表前の重要情報をお預かりする企業として、より一層のセキュリティー対策と監視体制の強化に努めてまいります」とコメントしています。
近年、ビジネスの意思決定にはデータの活用が重要だという認識が広まりつつあります。実際、データアナリストに関する求人やデータ分析の発表が増えているのを実感します。
しかし、現場では、異常かつ不十分なデータをデータアナリストが必死に処理しながら分析を試みている状況です。それによって、本来集中したいデータの分析に充分に取り組めていないのが現状だと思います。あっちこっちのシステムに散らばった中途半端なデータの数々を寄せ集め、微妙なフォーマットの違いに気を配りながら整形し、それぞれのデータの法的な契約状態に注意しながら分析を行うのは、非常に大変な作業です。データアナリストの方々は、データの収集と整形に多くの時間を費やしているのではないでしょうか。
この問題は、私たちアプリケーション開発者にとっても他人ごとではありません。データの源泉であるアプリケーションが適切に変更を記録すれば、このような問題は避けられるはずです。記録さえしておけば、今は忙しくても、後でデータアナリストへ必要なデータを取り出して配信できます。
しかし、一度失われてしまったデータを復元することは二度とできません。これは将来どうにかするべき問題ではなく、今すぐ取り組むべき問題だということを認識しなければなりません。そして、「今記録できていないから今さらやっても仕方がない」という考えは捨てるべきです。データが記録できていない状態を現在進行形の問題として捉えるべきです。
自社で評価に使うべく、エンジニアのスキルを体系化してスキルマップを作っていたのですが、作っているうちに、他者の意見を取り入れてエンジニアのスキル業界の共通認識ができたら面白そうだなと思ったのでQiita上で公開してみることにしました。
以下は叩き台と思って下さい。皆さんの意見をお聞きしたいです。
あくまで（私が考える）エンジニアスキルに絞っています。
- 所謂フロントエンド／バックエンド／アプリエンジニアを想定しています
- ITアーキテクトに分類されるスキルは一部入っています（ドメイン駆動設計に繋がるので）
- 自社サービスを作るプロパーエンジニアか、フリーランスや受託開発会社のエンジニアかというと、後者寄りです（主に上流工程部分が）
- PMスキルは省きました
- DB、インフラスキルは省きました（DBスキルは頑張ればマージできそう）
- 品質的なスキルは入れた方が良い気もしますが抜け落ちています
もしもこの記事を読むのが面倒であれば、以下の５つだけを覚えておけばよい。
1. ひとつの処理の単位はディスプレイで一度に表示できる範囲に収めること[1]。
2. 意味を持つデータには適切な名前をつけて変数化すること。
3. 意味を持つ処理には適切な名前をつけて関数化すること。
4. 同じ役割・意味を持つ変数や関数には一貫した名前をつけ、異なる役割・意味を持つ変数や関数には同じ名前をつけないこと[2]。
5. 2, 3, 4 を守ってもコードに反映されない「そのコードを書いた意図」はコメントとして残すこと。
Bambaは97.8億のパラメーターを持つ大規模言語モデルで、ベースとなるアーキテクチャが一般的な大規模言語モデルと少し違う点が特徴です。
IBMリサーチによると、一般的な大規模言語モデルはTransformerというアーキテクチャを利用していますが、応答の際に実行中のシーケンスをメモリに保持する関係上、プロンプトが長くなるにつれて生成のコストが指数関数的に増大するとのこと。たとえばコンテキストウィンドウのサイズが2倍になると、それを処理して応答を生成するコストは2倍どころか4倍になるそうです。
この問題は「2次ボトルネック」と呼ばれ、ユーザーがAIに質問をしてから答えを得るまでのタイムラグの原因の1つになっているといいます。
新しく登場したBamba-9Bは、Transformerアーキテクチャと、状態空間モデル(SSM)というアーキテクチャを組み合わせつつ、メモリに当たるKVキャッシュの管理をTransformerアーキテクチャから根本的に変えたモデルです。通常、Transformerが応答を出力する際、コンテキストウィンドウ内のすべての単語に注意を払うのに対し、SSMは過去の情報を要約した「隠れ状態」を維持するとのこと。情報を選択的に保持するこの手法を使うことで、メモリのオーバーヘッドが少なくなり、推論速度が速くなるそうです。
昔々、👁ｸﾞﾛの🈪#⃣ｲ主攵で出入りの開発をやったことあります
バンカーって開発を同じ人間だと思ってませんでしたね、対面一声目が「お前ら」でした
さらに間に入ってるИ本$研は全員イエスマン
社食すら社員と出入りで値段が違う中世のような身分制度
行きたくもない新入歓迎飲み会に社交辞令で行けば、なぜかバンカーにお酌をして回れと強制される開発メンバー
もちろんビール瓶のラベルは上向きに、こいつらは苦しんで死んで欲しいと思いながらお酌をして回りました
まともな協力関係なんて築けるわけがないです
そんなバカが思い付きで口出してくる開発現場でロクなもんできるわけがありません
むしろ現場が解決的アプローチなんぞとろうもんなら政治的な圧がかかります
色気出さずに永久にCOBOLと電文でやってろと思いました
大昔の縦割り 階層構造 日本大企業の悪しき風習を当時でも色濃く色濃く残してる業界の一つが銀行でした、今は知りませんが、あんま変わってないような予感がします
回答になります、技術の問題じゃなくて、組織そのものが腐敗してる可能性があります
先輩と後輩が関係者なので、少し遠回しな回答になるのをご了承願います。
■ 先輩の話 -> みずほ創業当時の大障害について
当時、第一勧業銀行、富士銀行、日本興業銀行の合併が決まりシステム統合の話になりました。しかしながら当時の銀行業界のシステムは１０～２０年プロジェクトは当たり前であり、各社ともシステムへの投資もそれなりの物になっていました。
そこで起きたのが内部闘争です。本来は一つのデータベースとして統合すべき物を今まで苦労して作って来たシステムを廃棄するのに、躊躇したと聞きました。
結果出来上がったのが、真ん中を取ってどのシステムへもアクセス出来るプログラムを作る方法でした（今までのシステムを流用する）
この時、起きた大障害は正に↑のプログラムが原因でした。
・・・元々無理が有ったんでしょうね。
■ 後輩の話 -> 数年前のみずほの大障害
元々銀行系のシステムの多くはメインフレームと呼ばれる大型コンピュータで行ってましたが、時代の流れと共にクラウド化する事になりました。
メインフレーム -> クラウドへの焼き直しをするのは良いのですが、如何せんメインフレーム系エンジニアの多くは、現在定年退職した団塊世代です。
当然、現役の技術者には荷が重く（↑に明るかった私に退職後相談に来た位）工数は読み間違えるは、仕様確認に追われるはで現場は混乱を極めたそうです。
業界では有名な話ですが、当時最大で８０００人のエンジニアが足りなくなったそうで、下請け会社や派遣会社は大量の「素人」を投入しました。
・・・結果は見てのとおり。。
〇 雑感
IT業界では有名な話なのですが、銀行・金融系の会社は
金払いは良いけど、意味不明な柵が多いのです。まぁ内部のルールや人の問題が凄く大きいんだと思います。
ソフトウェア開発技術者のコミュニティには、スライドシェアの文化*1がある。具体的には勉強会やイベント登壇の発表資料をプレゼンテーションツールで作成して、発表したあとにスライド共有サービスやコミュニティのウェブサイトなどに掲載するもの。スライドが共有されるので発表を見た人はメモ取りで慌てることなく発表を聞くことに集中できるし、発表を見れなかった人もスライドを見て雰囲気を楽しむことができる。
記憶の限りだと、翔泳社デベロッパーズサミット（デブサミ）の2006年くらいからはSlideshareというサービスを使った資料の共有が始まっていた。このイベントは平日開催だったので参加できない自分は職場でスライドだけを見ていたものだ。クラウドサービス登場以前の時代だったため、インターネットで情報を共有するのには金も手間もかかる時代に、無料でスライド共有可能なサービスが出てきたので、これは大変に流行ったと記憶している。
そしてこの文化は現在も（たぶん）引き継がれていて、常に大量の良質な発表が繰り返され、スライドが共有され続けている。
だけれども、それはどんどんと埋もれてしまっているように思うのだ。
Goエンジニアが取れないって会社、とりあえずPHPのコミュニティに投資しろって言ってるんだけど理解されないんだよなあ。GoとかPythonもPHPだから書いてくれるさ...
コピペ不能な画像でコードが渡されてひたすら写経→ちょっと解説みたいな授業が多くて辛い
多分写経プログラミングは向き不向きがあって、打ちながら意図を考えられるタイプだと伸びるんだと思う
でも俺は完成したコードをちょっと編集してどこが変わるか？ ってのを観察するとか、能動的に働きかけて変化を体感するタイプの方法じゃないと全然頭に入らねえ
まあ先生とやり方が合わないとかそういうの含めて勉強なのかもしれんけど……
4 月になると、多くのテック企業で「新卒エンジニア研修」が始まります。架空プロジェクトの開発、技術系の講義など、内容は企業によってさまざまです。一見すると「新卒に必要な学びの場」を与えてくれる素晴らしい制度。ですが、僕はあえて言いたい。
「新卒エンジニア研修、いらんくね？」
特に、いわゆるメガベンチャーや有名スタートアップのように、採用時点でかなりハイレベルなエンジニアを確保できている企業であれば、なおさらそう思います。
新卒エンジニア研修を、後輩エンジニアに勧められるかと聞かれれば、答えは No です。Absolutely no です。研修で足踏みしている新卒エンジニアを見ると、正直、気の毒に思いますし、時には憤りさえ感じます。
TypeSpec へ移行したことで次の恩恵を享受することができました：
- 移行後の TypeSpec ファイルの総量は約 2 万行になりました。手作業で管理するファイルの行数が減ったことは嬉しいポイントです。
- モデルやルート定義を分割できるようになったことでスキーマ全体の可読性と開発体験が大幅に向上しました。
- AI Agent のコンテキストを過度に圧迫することなく開発できるようになりました。
- エミッターで OpenAPI のバージョンを簡単にアップデートできるようになりました.
28歳/未経験からエンジニアになりたく2024年7月から資格勉強始めました！ 保有資格 :LPIC1/LPIC2/CCNAと基本情報目指して頑張ります！
フロントエンド DDD について説明する前に、我々がフロントエンド DDD を必要とした背景を説明します。
弊社、株式会社TAIANは婚礼業界向けの業務 SaaS を提供しています。我々は婚礼業界の未来のため、特定の領域・関係者にとどまらず、婚礼業界全体の広範な業務を対象とした SaaS を開発しています。また婚礼業界は様々な伝統や思いやりを背景とする複雑なビジネスルールが存在します。さらに関係者も多く「カップル」「式場」のみならず「参列者（ゲスト）」や「提携業者（パートナー）」などドメインロジック（そのソフトウェアが使われる業務固有のルール）に関わる様々な関係者が存在します。
つまりドメインロジックが複雑なのです。私はいままで様々な SaaS の開発に触れる機会がありましたが、その中で一番ドメインロジックが複雑なプロダクトだと感じています。大変ではありますが、ソフトウェアエンジニアとしてそのような複雑なドメインロジックに向き合うのはとても面白いです。またこのような課題に対する解決策を考えることができれば、それは婚礼業界のみならずこの国の発展に大いに貢献すると考えています。
その解決策の一つがフロントエンド DDD です。プロダクトの使い勝手を追求すると、フロントエンドにもドメインロジックの知識が必要になります。前述のように複雑なロジックを、我々のようなまだそこまで大きくない組織が把握・管理・制御するには、ドメインロジックを実装詳細から抽出できる DDD の思想をフロントエンドにも取り入れることが必要だと考えました。