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を活用してコードを組むかが重要になってくると思います。
そのうち開発ツールにも組み込まれると思いますし、どんどん活用して上達することをお勧めしますね。
Linuxカーネルの開発者、リーナス・トーバルズ氏がLinux 6.14のリリースを「忘れていた」ことを明らかにし、「純粋に無能だった」と謝罪しました。
かつてSESの人たちは職業プログラマーが多く、休日に勉強するなんてあり得ないというカルチャーだったんですよね。その流れでWeb系の企業に面接に来た際、新しい技術について質問されると、必ず「入ってから頑張ります」といった回答をしてしまい、結果として面接に落とされることが多かったんです。
一方で、Web系の人たちは当時から休日に勉強会へ参加したり、趣味で新しい技術を試したりしていたので、そうした文化の違いが「カルチャーギャップ」として語られていました。ただ、今は未経験から勉強する人が増えたこともあり、業界間のカルチャーギャップは少しずつ縮まってきたように思います。
もともとWeb系の人たちは、勉強会で新しい技術ネタを仕入れ、それを趣味として試したり、社内勉強会で展開したりしていました。そして、それを実務にも活用することで、結果的にWeb系ではモダンな開発環境が整い、そうした取り組みを推進していた人が評価される流れが生まれました。そうした背景があるからこそ、「プライベートで勉強すること」が正しい行いとして定義されていったのかなと思います。
「休日も勉強しろ！」って言ってくる会社って...実はホワイト企業なの知ってましたか？
どういうことかというと...↓↓
エンジニアは休日も勉強すべきか？と質問をよくもらうけど、個人的な結論としては、アウトプットさえよければどちらでもいい。
で、実はこの意見を言う人ってかなり優しい考え方なんですよね。
なぜなら、この質問って先輩エンジニアや経営者が若手を評価するときに質問することが多いんだけど、
実際、エンジニアとしてのキャリアが進むと、部下が休日に勉強しているかどうかなんて関係ない。
「良いアウトプットを出せるか？以上」みたいな。いわゆる結果主義。
ですがもし「休日も勉強しろ」と言われる環境なら”過程”も評価してくれる会社かもしれないので、実はホワイト企業だったりします。
会社選びは表面ではなく本質で判断するのが大事。
今から新規にWebサービスを作るなら、そもそもパスワードは作らせずにメールアドレスで毎回認証させると思う。メールアドレスが盗まれるとログインされる問題はあるけど、そのレベルの人にこそパスワードを作らせるわけにはいかないので一番現実的だと思う。
金融系だとメールアドレスアカウントが盗まれているリスクが無視できないのでSMS認証が広く使われているけど、SMSの奪取は海外だと一般的で、日本でも通信会社によっては脆弱で実際事故があったわけで、しかもSMSは日本だとめっちゃ高い（1通数円程度）ので、そこまで価値があるとは思わない
ITエンジニアが最強だと思っている高度なアーキテクチャが技術力の高い企業に採用されてるのは「サービスが超絶儲かっているから」であって
お前らが担当する、そこそこしか儲からないシステムに高度なアーキテクチャは不要。
ITエンジニアの自己満足はビジネス上、害悪であると言い切った元上司。
梅林 たしかに「メンションの即レスを期待しない」という標語が全社的に使われていますが、それは仕事のコンテキストスイッチを入れないためでもありますね。集中してタスクにあたっているときにレビューやCSのサポートを依頼されますが、そのとき手掛けている仕事の切りのよいタイミングでやってほしいと考えているので。
逆に非同期のコミュニケーションが中心になると、いかにお互いのビジビリティを高めるかが課題になります。例えば開発においては、分からないことがあったら「分からない」と自分で発信できる方がいいんですよ。
コードを書くときに「何か分かんないけど、他のコードではこうなってるな」という状況があったら、黙ってコピーするよりも「何でこうなってるんでしたっけ？」って聞いてくれればその人の理解度も分かるし、なぜそう実装しているかもきちんと説明できます。
そのためには「何でそんなことが分かんないの？」という空気は絶対に作っちゃいけない。会社全体のバリューとして「100回同じことを聞かれても、100回笑顔で答える」というカルチャーでいこうと全員が本気で思っていますし、だからセールスやカスタマーサクセスの人もエンジニアにどんどん質問や相談をしてきます。
── さらにエンジニアの開発スタイルは「マルチタスクアサイン」「セルフサインアップ」「チケットに納期を設定しない」だということですが、これはどうしてでしょうか。
梅林 エンジニアは基本的に管理されたくないんですよ。朝会なんて誰もやりたくないですし、僕自身も管理したくない。僕自身が過去にICとして働いてきた経験から、これは不要だなと感じたマネジメント要素を取り除いた結果、このスタイルになっています5。
梅林 ちなみにチケットは納期こそ決めていませんが、プロダクトマネージャーが状況に応じてソートしていますから、基本的にタスクを上から取っていけばプロダクトにプラスになるようになっています。
その上でレビュー依頼だったり、開発以外のメンバーの相談だったりにはエンジニア個人の裁量で自由に対応できる方がいいですね。要望の本当のペインを確認した上で解決方法を考えるため、エンジニアが直接お客様とのミーティングに参加することもよくあります。
そうして使っているのは誰で、開発すれば誰がよろこぶかということが分かると開発しがいがあります。そうじゃないと何のために開発しているのかが分からなくなりますね。マネージャーのために開発しているんじゃないので。
頭悪そうなプログラマーやSEが軒並みみんな俺の仕事はAIで代替できないって言ってるから多分これは本当に大虐殺が起きるんだろうなと思う、次どんな仕事したらいいんだろうなあ
偽情報の問題が出ているが、インターネットがいろいろな意味で限界に近づいたと感じている。ＮＴＴは２０１９年５月に次世代通信基盤「ＩＯＷＮ（アイオン）」構想を発表した。インターネットの次をそろそろ考えるべきではないかということだ。
情報の概念は、２０世紀半ばにシャノンが定義した。それまでのコンピューターは単なる計算マシンだった。情報を扱うことになったのは２０世紀半ばくらいで、そこからコンピューターが進化してきた。情報の正しさを判別することが技術的に始まり、その後にインターネットが普及し、誰が情報を作ったのかを証明するデジタル署名の技術ができた。最近は、ブロックチェーンのような新しい分散型の仕組みで情報の正しさを証明する動きがある。
問題は、生成ＡＩ（人工知能）が出たことだ。それ以前のＡＩは、人間の勘や経験などを処理するのは難しいと言われてきた。それが、データを学習すればＡＩでもできるということになった。生成ＡＩは人間を超えたようなコンテンツを今後もどんどん製作する。本当に正しい情報なのかを判別するのは技術的に難しい。
インターネットは万能ではなく、欠点がたくさんある。大量の情報を処理するために多くのエネルギーを使うし、偽情報があたかも本物のように全ての人に行き渡ってしまう。新しいインフラ（通信基盤）を考えることが重要だ。
ＩＯＷＮは、光の技術を使っていこうと思っている。情報を遠くに飛ばす時、電気は大量のエネルギーを使うが光はほとんど変わらない。高い潜在能力を持っている。消費電力は１００分の１くらいになり、今までインターネットでできなかったことがＩＯＷＮでできるようになる。
今のインターネットも光を使っているが、使い方が問題だ。今、ＮＴＴは光の全てのリソースをインターネットに差し上げている。産業領域ごとに波長を分けていくことが技術的にできる。すでにオールフォトニクス・ネットワークの商用化を開始した。
インターネットはプロトコル（手順）が決まっているので、どこに情報があるかを明らかにしているのが弱点だ。この部分を一生懸命暗号化して守ろうとしているが、破られる。
国や産業ごとに、情報がどこにあるか分からない世界が技術的にできる。情報を全てインターネットにさらけ出す必要はなく、完全にクローズドなネットワークができ、セキュリティーレベルが上がる。最終的には量子通信と呼ばれる領域まで持っていければ、今懸念しているようなことはほぼ解決できると思う。
年末年始に大きな「ＤＤｏＳ（ディードス）攻撃」があった。ＤＤｏＳ攻撃はこれまで、２００以下くらいのＩＰアドレスが使われていたが、今回は３０００を超えた。攻撃者がＡＩを使ってきた。守る側もＡＩを使うしかない時代に突入した。
サイバー攻撃が進化している。今までは（攻撃で使われるネットワークの）ボットネットを発見して対処するアプローチを取っていたが、ＡＩを使ってボットネットがダイナミックにぐるぐる回るため、（対処が）本当に難しい。
これをどう防ぐか。ＩＯＷＮを使ってインターネットの世界から一歩外れたところで、ＡＩがボットネットを監視して対処するやり方しかないと思う。各国がインターネットの中で対処しようと一生懸命やっているが、限界がある。
今のＡＩはほとんどのことができると思われているが、唯一できないことがある。それは、自分の答えを否定することだ。唯一無二の存在になってしまっている。いろんな専門的なＡＩをたくさん作り、信頼できるネットワークで結び、時として協力して答えを出したり、チェックしたりする。民主的な形でＡＩを利用していくアプローチでいけば、人間社会に近い形でＡＩが進化していくのでないか。
パターン６：操作ログとリクエストIDでUPDATEを冪等にする
パターン７：最終奥義「トランザクション」
パターン２：エラーを区別してDELETEを冪等にする
パターン３：操作をまとめて冪等にする
パターン４：操作を細かくして信頼性を高める
パターン５：操作ログとリクエストIDでUPDATEを冪等にする
大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。
大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。
そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。
では、第1回は背景から：
パターン1：IDを付けてCREATEを冪等にする
パターン２：エラーを区別してDELETEを冪等にする
「Ubuntuらしい」チャレンジングな試みが開始されます。Jon Seagerによる『酸化』の試みのDiscourse上のポスト[1]では、coreutilsをRustベースの新実装であるuutilsで置き換え、可能であれば25.10でデフォルトにし、26.04 LTSでも同様にデフォルトとする方向が示唆されています。
coreutils（GNU core utilities）はLinuxシステムにおける基本的なコマンド群で、lsやmvやrm、cp、chownなどなど、「コマンドライン操作では必ず利用する」ツールキット群です。これを別の実装に置き換えるというのは非常に大きな変更といえます。
もっとも今回Ubuntuで行われるアプローチは、全体的にあくまで実験であり、「必ず達成する」性質のアプローチではないことが強調されています。現実的な問題が発見された場合は先送りされることが明言されています。coreutilsは暗黙でシステム全体から依存されており、この置き換えが成功するかどうかは現状では誰にもわかりません。現時点でこうした試みを試すには、oxidizrを用いて既存のコマンドを置き換えるという方法があります。
Ubuntuがこの挑戦を行う目的として、「スピードよりもRust採用による堅牢性（とレジリエンシー＝修正の容易さ）の確保」ということが示唆されています[2]。しかし、C言語ベースの実装からRustへの置き換えというものはどちらかというと「誰か（いずれかのディストリビューション）が試さない限りは未来がやってこない」タイプのチャレンジで、これを実施することで「未来がくる速度を加速する」ことが目的のように読み取れます。
システムにおける「区分」とはカテゴライズ可能な値の集合体を表すものであり、「区分値」とはその集合に属する個々の識別子を指します。
たとえば、あるアイテムの「ステータス」という区分には「下書き」「レビュー中」「承認済み」といった区分値が含まれます。
一見すると、こうした区分値は単なるラベルでしかなく、設計の検討余地があまりないように思えるかもしれません。しかし実際には、区分値の扱い方次第で、システムの柔軟性・拡張性・保守性などに大きな差が生まれます。
本記事では、この「区分値」の設計について、あらためて整理し、より優れたアプローチを再考していきます。
シンボル値による表現は、伝統的な業務システムにおいて長年にわたって広く使われてきた手法ですが、結論から言うと昨今のモダンな開発現場においては 「セマンティック値」での表現を第一に検討することが望ましい と考えます。
そこで本稿ではウォーターフォールやアジャイルなど従来型の開発手法をおさらいしたうえで現在のシステム生成AIプロダクトの問題点を考察し、AIを前提とした新たな開発手法を考えてみたいと思います。
ではAIを使った開発は中小規模のアプリケーション開発及びエディターのような補助的ツールにとどまり、メインストリームになることはないのでしょうか？
先述しましたがアプリケーション開発ツールが中小規模にとどまっているのは土台のないところに枝葉を加えていくことで全体の整合性を取れないことが原因です。
解決策はウォーターフォールのように土台を作ったうえで開発を進めていくことだと考えています。
ただし従来のウォーターフォールに回帰することでスピード感・柔軟性が失われては本末転倒です。生成AIによりさらに変化が激化するIT業界では致命的になるでしょう。
そこでAI時代の新開発手法として超高速軽量ウォーターフォールを提案したいと思います。
これは何かというと従来のウォーターフォールに必要なドキュメントをそのまま作成するのではなく、AIのインプットに必要なドキュメントをAIにより生成することでドキュメンテーション工数を軽量化し高速でウォータフォールを実行する開発手法です。
そもそもアジャイルがスピード感を持って開発できるのはドキュメンテーションをコミュニケーションで代替しているからであり、アジャイルでメンバーにクオリティが求められるのは空中戦になりやすいからです。 なのでアジャイルの方法論はアウトプット定義というよりもコミュニケーション定義及びプロセス定義にフォーカスされたものが多いです。
現状のLLMは良くも悪くも入力された情報を処理して出力する魔法の箱のようなものなので、入力情報が乏しいまたは人間間のコミュニケーションに特化されているアジャイルはむしろAI開発とは相性が悪いように感じています。
基本コンセプトは要件定義から運用までを高速で回すことで柔軟性を担保するという点でよく似ています。
異なる点はリリースポイントです。もちろんスパイラルのようにフェーズに区切って大きな単位でリリースするのもありですが、AIをフル活用する超高速軽量ウォーターフォールでは機能単位の実装が比較的早期に完了するので、機能ごとにリリースすることが可能です。
超高速軽量ウォーターフォールのプロセスは以下です。
(1) 企画・要求をもとに要件定義書を生成
(2) 生成されたアウトプットを人がチェックし修正
(3) 修正された要件定義書をもとに設計書を生成
(4) 生成されたアウトプットを人がチェックし修正
(5) 修正された設計書をもとにソースコードを生成
(6) 生成されたアウトプットを人がチェックし修正
(7) デプロイ
超大手JTCの中に入って実感してきたけど、ありとあらゆることを下請け会社が忖度してやってくれるので、新卒から超大手JTCで働いていたら、それが当たり前だと思うようになるんだろうなー。
外から見たら、尊大で何もできない人達なんだけど、本人達は一生気がつかずに幸せに生きていくのだろう。
解雇規制が厳しいからです。ある企業が「よし、来月から半年間50人体制でプロダクト作るぞー」と思っても、雇用流動性がないので50人の（ちゃんとした）プログラマーを短期間で雇用するのは相当給与水準が高くないと不可能です。しかも半年後には解散か縮小することが分かっていたら、解雇規制が厳しい日本だと更に雇用は難しい。
なので派遣とかSES業者に人出しを頼むことになります。でもそういう会社も空き要員って常にプールしてる訳でもなく、大体他の案件に人が張り付いています。人が空いてるかどうかって運なんです。空いてたとしても50人空いてることは稀なので、その会社で埋められない要員は更に別の会社に依頼することになります。
これが繰り返されて、孫請、ひ孫受け、その先までいってようやく客先の希望要員数が充足します。
案件が長く続いて少しずつパフォーマンスの悪い末端要員がスイッチされたり、案件縮小のタイミングで多少多重構造が改善したりすることがあります。でも納期が短いと難しいですね。長い案件でも、マイルストーン毎の納期が厳しかったりとか。
多重構造は悪、SIerがあくどい人月商売してるからだ、みたいに言われますけど、SIerもそんなに儲かってないです。やりたくてやってるわけでもない。本当は全部自分らで請けたい。客先もそれを望んでる。でも人がいないから外で調達して自分らで管理するという形にせざるを得ない。人月商売批判する人は、じゃあどうすればそれなりのアウトプットを保証できる50人のプログラマを1ヶ月2ヶ月の短期間で用意できると言うのですか。やってみたことありますか。ちなみに多重にしないでスコープ削ると、スコープ大きめで請ける他社に持ってかれて失注します。そりゃ客も楽したいから。
解雇規制がもっと緩くなれば、労働市場に出てくるプログラマーも増えて、チームリーダー含めそのプロジェクト用に直接プログラマーを雇い、完成したら縮小または解散、のようなことも出来るようになると思いますが、まあ当分は無理でしょう。
Xの日本法人は12日、同社のプラットフォーム運営に関して声明を出し、検閲は行なっておらず、シャドウバンも実施していないと説明した。
同社では、一部ユーザーから運営に関する誤解や懸念の声が上がっていることに対し、改めてプラットフォームとしての指針と運営方針を説明するポストをXに投稿。Xが言論の自由を推進するプラットフォームであり、これは国内においても同様だとした。
その上で、Xが安全で健全な環境となるよう常に取り組みつつも、プラットフォームの方針に基づき検閲を行なうことはなく、シャドウバンも実施していないと説明した。なお、Xの定めるルールに違反した場合は、アカウントの凍結やコンテンツの削除を求める場合があるとしている。
まず、容量の割に重くて大きいという点だ。また普及していないので価格が高く、ナトリウムイオン電池はPSE（電気用品安全法）対象外のため、PSE取得マークを付与できない。
モバイルバッテリーなど小型充電式電池を回収してリサイクルする団体「JBRC」の会員であるにもかかわらず、対象外（対象となっているのはニッカド電池／ニッケル水素電池／リチウムイオン電池）ゆえに、家電量販店などに設置してある回収ボックスを使えないというデメリットもある。
エレコムでは「地方自治体に問い合わせいただく、弊社サポートセンターへ問い合わせいただく、エレコムデザインショップへお持ちいただくことで、回収できる」としている。
中央集権的な管理に対して、データスペースは分散型のアーキテクチャでデータを管理します。データは通常、データ提供者が保持しており、そのデータをコネクタと呼ばれる通信モジュールを利用してコネクタ間でデータの交換を行います。
データスペースでは、あるデータ提供者のデータを管理するデータベース(あるいはクラウドストレージ)に障害があった場合でも、影響範囲は限定的され、それ以外のデータ提供者は影響を受けることはありません。また、サービスが終了や垢バンなどによる、サービスの利用継続が不可能などの問題からも開放されます。
また、システムを開発・提供する側としては、データをユーザ(企業・組織)側で保持することにより、各システムのスコープを絞ることができ、モノリシックなサービスを分割しマイクロサービス化を行うようなアプリケーションのモダナイズに似たメリットを享受することができます。更にはデータスペースによる標準化されたデータ交換方式により、データ連携部の開発をスムーズに行うことができます。これらのメリットにより、ユーザ毎のシステム開発速度が向上し新規ビジネスに柔軟に対応できるようになり、また、各システムがデータ利用者・提供者側に寄ることにより、よりユーザの要件に適合した無駄のないシステム開発が可能となります。
データスペースは、中央集権型アーキテクチャの問題を解決するだけでなく、サステナビリティやデータ主権といった、以下のような新たなユースケースでも注目されています。
内部からの告発によって動き出した内部調査委員会の報告が遅れている。
元々24年内予定だったのが遅くとも2月までと遅延し、2月18日には最終的な取りまとめを行なっているとしている。
PyCon JPにおける登壇者採択に関する内部調査委員会の設立
https://pyconjp.blogspot.com/2024/10/selection-view-3.html
なお、調査結果の報告は年内を目標にしており、遅くとも2025年2月までにはご報告できるよう進めています。どうか今しばらくお時間いただけますようお願い申し上げます。
2025年2月18日 現在最終的な取りまとめを行っております。当初の予定より報告が遅れていることをお詫び申し上げます。
経緯はこれら
https://b.hatena.ne.jp/entry/s/qiita.com/python_bokume2/items/7aa80b73010919007581
そして3月に入り休日も過ぎ、平日も過ぎた現在も特に進捗の報告もなく、先日動画配信の報告記事が更新されたが内部調査の進捗には文章中では触れられていない。
信頼が揺らいだ騒動についての報告が最終取りまとめから思ったとおりに進まないということは、単に問題はなかったという報告ではなく込み入った事情が絡んだ報告になるのか。
内容はわからないがともかく、当時の対応、二度の遅延、今の遅延の釈明なし、と現段階では不誠実と感じざるを得ず、報告が問題ないとしても疑わしいし、問題があったと断定してもよほど誠意ある内容でなければこの不信感は消えないものだろう
幾つか理由が考えられます。
1. 拡張性：データサイズには限界があるだろう。おそらくMSとしてはExcelで扱うには不満がある程度には大きなデータを対象にしてる。しかし巨大なデータサイズには対応しそうにない。MS Accessのサーバーを複数台へスケールアウトするのって、ちょっと想像できない。
2. 継続性：Officeファミリーの一部は新版からなくなるモノが多い。継続してくれるか不安。
3. 互換性：新版が出た場合、以前の物と互換性があるか不安。
4. 情報漏洩：セキュリティに不安がある。
.
わたし的には、1レコードのアクセスごとにロックされず、前後の数レコードまとめてロックされるのがいや(RecordLocks プロパティで、2人のユーザーが同じ1つのレコードを同時に編集しようとした時の動作の事ではない)。アプリの設計で、異なるレコードへの同時アクセスの動作が保証されてないとか、例外処理で悩みたくない。例えば、1000番目のレコードと1001番目のレコードを比較してその結果で更新して書き戻すプログラムは書けるが、動作させると（それらは同じ記憶領域の1つのブロックだから）デッドロックになって止まる…とか。
そういうバカみたいな制約から解放されるなら、無料のPostgreSQLを選ぶ。
ちなみに……やたらプロパティとメソッドの呪文がダラダラ長くなる悪癖を持っていても、VBAはロジックとして分かり易いからそれは（わたし的には）問題ない。
経営がDXを推進すべきなのは当然ですが「まずは経営が意識改革しなくてはダメだ」というのも誤認です。「会社でDXが進まないのは、経営|レガシーシステムのせいだ」というのは正しいですが、
- まずは経営が変わらねば
- まずはレガシーシステムを一掃せねば
- まずは内製エンジニア組織を作りSIerを一掃するのだ
という思考に向かうのは、非生産的です。屏風の虎は出てきません。
そんな解けない問題を前に腕を組んで批評だけしていても事態は一向に進みません。もう、2025年です。物事を自分の手で前に進める気がない人は黙ってていただきたい。害悪です。やる気のある若者でも、そういう言説に影響されて腕を組んでしまう。
そうじゃなくて、意識が変わりきらない経営層、色々な問題があるレガシーシステム、足りていない人材という中で「どうやったら会社のDXを進めることができるのか？」という視点に立つべきなのです。
20年前のweb開発、「みんな知らないけど…… HTMLに値を出力するときは………… エスケープというのをするといいらしい！！！！！」（一同感動）みたいなノリだった記憶がある。
本当にみんなエスケープという概念を知らなかったので、その辺のフォームに変な字を入れると30%くらいの確率でXSSできてました。さすがに偽の記憶では？
今回研究者たちが謎のコードを発見したのは、ATARI2600で1982年に発売されたゲーム『Entombed』です。
これは上から下へと画面が移動していく縦スクロールアクションゲームで、プレイヤーは画面に押しつぶされないようにルートを選んで迷路を攻略していきます。
後戻りはできないため、行き止まりにぶつかってしまうとゲームオーバーです（アイテムにより決められた回数だけ壁は破壊できます）。
このゲームの迷路はひどく単純なものに見えますが、当時のゲームカートリッジのメモリでは、予めデザインした迷路セットを保存し、後から読み出して表示するということができませんでした。
そのためこのゲームは、迷路を設定された「手続き」に従ってランダム生成しています。
問題は、このゲームの迷路がどうやって無用な壁の生成や、侵入できないようなエリアの生成を避けているのかという部分です。
このゲームでは、進行に合わせて迷路を連続生成しています。プログラムは現在描画されている迷路を解析し、次に現れるスペースそれぞれに壁を描画するかしないか判断します。
問題は、この壁の配置を決定する基礎理論が、どうやって作られているのか理解できないことです。
壁の配置決定に使われているパラメータテーブルの値が、どうやって導き出されたものなのか全くわからないのです。研究者たちは、テーブルに含まれる値のパターンを見つけようと試みましたが、無駄に終わりました。
しかし、このテーブルの値が僅かに異なったりすると、もう迷路は通行可能な形で描画されません。
研究者たちは後に、このゲームの開発者の1人と接触することに成功しましたが、その開発者も迷路生成のアルゴリズムは当時から理解できなかったと話します。
彼の話によると、担当したプログラマーは「酔って頭をぶつけた拍子に、このアルゴリズムを思いついた」と語ったそうですが、研究者らは問題のプログラマーと接触することはできなかったとのこと。