フューチャー株式会社の有志が作成する良いアーキテクチャを実現するための設計ガイドライン
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 の思想をフロントエンドにも取り入れることが必要だと考えました。
【IIJサイバー攻撃 Active!mail】
記事には掲載できなかった発覚の経緯
https://nikkei.com/article/DGXZQOCD16BSF0W5A410C2000000/
IIJ「セキュアMXサービス」のサーバーで「異変」を検知するアラート（2025年4月10日）
↓
サーバー内で不正プログラムの形跡が確認される
↓
ログなどをもとに横展開された上流をたどっていくと…
↓
Active! mailのWebサーバーにたどり着く。初期侵入が2024年8月3日であることが特定される
↓
検証の結果、ある長大なリクエストを受信するとスタック領域があふれる現象が確認される
↓
開発元のクオリティア側も知り得なかった、いわゆる「ゼロデイ脆弱性」と判明
↓
クオリティアが「緊急告知」不具合の修正版をリリース（2025年4月16日）
↓
（以下は全て2025年4月18日）
「Active! mail 6の脆弱性に関する重要なお知らせ」を公表（クオリティア）
「Active! mailにおけるスタックベースのバッファオーバーフローの脆弱性」公表（JVN#22348866）
「Active! mailにおけるスタックベースのバッファオーバーフローの脆弱性に関する注意喚起」公表（JPCERT/CC）
IIJのインシデント覚知と調査がなければ、今回のゼロデイは今も見つかっていない可能性があります。
加えて、クオリティアの対応の速さは特筆すべきものがあります。
一方で、初期侵入から発覚まで８カ月近くが経過しており、その間、今回のゼロデイが悪用された攻撃がIIJ以外にも行われていることは十分考えられます。
今も多くの組織がActive! mailを採用していると思われ、影響の広がりが予想できません。
まずは複数の関係者の証言をもとに、いち早く記事を配信したのはそんな背景があります。
今後も取材を続けていきます。
2024年におけるソフトウエア業の倒産数が223件と2015年以降、過去10年間の調査で最多となった。
これ未経験が入れるタイプのIT企業だろうね
もう未経験からプロになる道は閉ざされつつあるのに、いまだに30代未経験です仕事ありますか。みたいなノリで起死回生できると思ってるやついるけど
インターネットイニシアティブ（IIJ）がサイバー攻撃を受けた問題で、同社のメールサービスに採用していたクオリティア（東京・中央）のソフトウエア「Active! mail（アクティブメール）」から侵入された疑いがあることが分かった。複数の関係者によると、クオリティアも把握していなかった未知の欠陥が攻撃されたとみられる。
エンジニア目指してSES企業に転職
↓
コールセンターにアサインされる
↓
めげずにCCNA、LPIC、AWS-SAA取得
↓
ITの実務経験が欲しくて派遣登録
↓
休日にPCキッティングの日雇で働く
↓
一年経過
↓
ケルンに転職
↓
サーバ設計構築を経験
↓
AWS設計構築を経験
↓
IaCを経験
↓
クラウドエンジニアとして活躍
↓
今年から年収600万予定
強すぎる弊社エンジニア。どんな環境でも前向きにやれることをやる。そして、経験を得るために、休みや自分の時間を犠牲にできる。こんなんウチじゃなくても成長してたはずだけど、にしてもすごいよね。
アプリケーション開発において、私たちエンジニアは通常、パッケージ構成やレイヤの依存関係、ロギングなどの観点からアーキテクチャを設計します。
しかし、実装との不整合やチーム内での共通認識が不十分なまま進むと、品質課題として潜在化し、やがて本番障害や開発者の疲弊といった形で問題に発展します。また、DevinやClineなどのAIエージェントに適切に実装してもらうにはプロンプトやドキュメントで設計を伝える必要がありますが、相応の準備が求められます。
このような課題を解決する手段として、設計と実装の整合性をテスト可能にするJavaライブラリ「ArchUnit*2」があります。JUnitのフレームワーク上で動作し、設計ルールを宣言的なコードで定義してテストとして実行できるため、普段の自動テストと同様の迅速なフィードバックが得られます。
こんにちは、東京大学の三輪敬太です。
私は2024年度に未踏IT人材発掘・育成事業として「ニューラル言語モデルによる個人最適な日本語入力システムの開発」というテーマで採択され、早稲田大学の高橋直希さんとともにmacOS上の日本語入力システムを作りました。今回はこの中でも中心的な開発テーマの1つであった「ニューラルかな漢字変換システム」の開発と、その成果について紹介します。
Model Context Protocol (MCP) とは何か？
MCP は、AI アシスタント（チャットボットや自動化エージェントなど）が、さまざまな外部データやツールにアクセスするための 共通のルール（プロトコル） です。
従来は、AI にデータベースやウェブサービス、ローカルのファイルを使わせたいとき、それぞれ違う接続方法をいちいち作り込む必要がありました。すると、AI を拡張するたびに「新しいツール用の独自コード」を用意しなくてはなりません。
MCP を使うと、「AI ⇔ データやツール」 の接続方式を 標準化 できるため、同じ仕組みでいろいろなデータソースや外部サービスとやり取りできます。これは、AI の開発者とデータ管理者双方にとって、大きな手間削減や再利用性の向上につながります。
Anthropic が策定したこと、そして OpenAI を含む他社が採用を始めていることから、MCP は今後の AI アプリケーション連携の業界標準として大きな注目を集めています。
テーブル設計時に考慮が足りておらず、その結果、データベースが高負荷になり、担当しているWEBサービスに影響を与えてしまいました。
今回は、そのサービス影響を与えたテーブルの問題確認と対策について検討してみました。
トラブルの原因は、リアルタイムでの参照用のインデックス、バッチでの集計用のインデックスがあり、月初1日は対象月のデータが少なく徐々に登録されてくるという特徴から、意図しないインデックスが使われるようになったからではあります。
PostgreSQLではないですが、アナライズが動いて逆に意図しないインデックスが使われるようになってトラブルになったこともあります。
今回のようなトラブルになりにくくするためにも、作成しようとしているインデックスが本当に必要か？特にバッチやデータ分析用のインデックスなど作成しなくても対応できる方法がないか？を見直すことは重要だと思います。
KADOKAWAが運営する小説投稿サイト「魔法のiらんど」が3月31日をもって、単独でのサービスを終了する。4月以降はWeb小説サイト「カクヨム」と合併し、同サイトの1ジャンルとして運営が続ける。
組み込み用のスクリプト言語として使える Lua はライトな反面、動的型付けや 1-based index といった仕様がボトルネックになりがちです。そうした状況の中、相応の短所も抱えた Lua の代替となりえる C/C++ 開発用組み込み用のスクリプト言語が多く開発されています。しかしながら、それらを横並びで比較及び評価した記事をあまり見かけませんでした。そこで、本記事では AltLua となりうる言語を取り上げ、それぞれの特徴を検証していきます。
むかし米国人の書いたコードをレビューした時のこと。データ量が少ない時は問題なくても増えてきたら必ず遅くなる箇所があったので直すようにコメントした。すると相手曰く「なあ、それは今やる必要があるか？」。もちろん、今やっておかないと後で大変なことになる。「当然だ」と答えた。
すると「どれくらいの確率で問題になると思う？」と聞いてきた。まあ正直分からない。サービスが当たるかどうかなんて事前には分からない。そう答えると「そうだよな。だったら今やる必要はない。日本人てのは起きていない問題まで見つけてくるから大したものだ」。嫌味というより素直に感心している。
「心配事の大半は起きない。だったら期待値の低いことにリソースを振り向けるのは非効率だろ。もっと優先度の高い問題がある」。確かに機能面でもかなりの重大なバグが山積みになっている。非機能はどうしても後回しにされがちなのは日米共通だ。もうこうなると良し悪しというより価値観の問題だ。
結局、客とも相談してコードは直さないことになった。問題になったらまたその時対処しよう、ということになった。リリース後、心配していた性能問題は出なかった。でもその理由はサービスが当たらなかったからではなく、重大なバグが見つかって全面的に処理を作り直すことになったからだった。
日本語だと「不確実性」という一語しかないが、英語ではriskとuncertainty という言葉で区別する。riskは確率がある程度分かるもの、uncertainty はそもそも確率が分からないもの。riskの方は期待値で合理的に対処が出来るがuncertainty は扱いにくい。我々2人とも後者に翻弄されてしまったのだった。
risk管理は米国人も真面目にやる。といっても日本人みたいに全部潰すわけではなく期待値の大きものから優先度をつけて対処する。uncertainty については、ある種の諦念を持っているように見えた。「想定できないものは想定できない」という感じ。
過つは人の常、赦すは神の業。
ちなみに予測可能なriskと不可能なuncertainty の区別は、経済学者フランク・ナイトが行ったもの。これ豆な。
Googleは、Android OSの開発を今後完全に非公開化するそうです。Googleに確認をとったAndroid Authorityが、独占情報として伝えました。
これまで一部のコンポーネントは、オープンソースプロジェクト（AOSP）を通じて公開開発されていましたが、来週からすべての作業を社内の内部ブランチに一本化するとのこと。
今回の決定は、Googleが現在抱える2つの開発ブランチの統合が目的。これまでは社内の非公開ブランチと、公開されるAOSPの2系統で開発が進められており、両者の間で発生するマージ作業の負担が大きな課題になっていました。開発を内部の一本のブランチに絞ることで、開発プロセスの簡略化やスピードアップが狙えるとしています。
一方で、今回の変更による一般ユーザーへの影響はほとんどないそうです。アプリの開発者に関しても影響はなく、これまで通りのアプリ開発が可能。 OSのソースコードも引き続き各バージョンのリリース時には公開となるため、Androidが完全な非公開ソフトウェアになるわけではありません。あくまで開発の非公開化です。
ただし、Androidのプラットフォーム自体をカスタマイズしている一部の外部開発者やROM開発者には影響が出る可能性があります。開発状況がリアルタイムで確認できなくなるため、情報の取得が遅れることになります。ただ、一般的にカスタムROMなどを開発する場合は安定版をベースに行われるため、影響は軽微にとどまるだろうとしています。
Googleは今回の決定について「開発効率化を図るための現実的な選択」と説明していますが、透明性の低下も懸念されます。続報を期待したいところです。
最近DHHがonce.comでのCampfireをはじめとしたプロダクトで、NULL制約やDB制約で防げるようなRailsのモデルのバリデーションを積極的には利用しないでいるという主張をしている。
自信がなくて「どうすればいいと思う？」って聞くくらいなら、Railsのバリデーションを書くコストは高くないから書いた方が良い。バリデーション書いても、DB制約はつけておくべきだし、ユニットテストもするべき。上級者がサービス作成のフェーズで僅かでも工数削減したいから利用するテクニックであり万人に勧められるものではない。また、無理してシンプルなバリデーションをDB制約に置き換えたりということも現場レベルで困っていることがなければしなくて良いように思う。
時代は巡るといいますが、「ググる」という行為に対しても昔同じ感想を抱きました。
「こんな、検索一つで関数やコードの書き方がみつかっていいのか！？全然考えてないのでは？」
でも、今の時代、ググらずにコードを書く人なんかいません。
ググれるようになる前は、WindowsやMac OSのコードブックがオフィシャルからリリースされててそれを死ぬほど読み込んだり、言語の手引書を発狂するほど読んだりしてコードを書いていました。
それしか手段が無かったからです。
ただその行為もさらに昔の開発からすると、かなり充実した環境に感じられました。
昔はOSやCPUの仕様書だけで開発をしていて、必要であればリバースエンジニアリングを行って動作を確認し、コードに組み込んでいたこともあります。
今からの時代はどれだけAIを活用してコードを組むかが重要になってくると思います。
そのうち開発ツールにも組み込まれると思いますし、どんどん活用して上達することをお勧めしますね。