はてなブックマーク

これらは、ゆるやかな文法でつながります。 アクターがコマンドを実行する → コマンドが集約に作用する → 集約がドメインイベントを生む → ポリシーがそのイベントに反応して、次のコマンドを呼ぶ。 たとえば「利用者が"支払う"（コマンド）→ 予約（集約）→"支払いが完了した"（ドメインイベント）→"確認メールを送る"（ポリシー）」という具合です。この流れを付箋で並べていくと、抜けている操作や、誰も気づいていなかった例外パターンが自然と見えてきます。 なお、イベントストーミングは、いきなり細かく描くわけではありません。ふつうは、粒度を変えながら3つの段階で深めていきます。 ビッグピクチャー：まずはドメインイベント（オレンジ）だけを時系列にざっと並べ、業務の全体像と論点を俯瞰する段階。関係者を集めて「そもそも何が起きているのか」を共有します。 プロセスモデリング：次に、コマンド・アクター・ポリシ

仕様は、最初から完全には決まっていない エンジニアが読む技術書では、仕様はあたかも「完全に決まっているもの」として扱われることが多いです。 入力があって、処理があって、出力がある。 条件分岐があって、例外があって、状態が変わる。 そして、それらは最初からきれいに整理されている。 もちろん、技術書としてはそのほうが説明しやすいです。 曖昧なままではサンプルコードも書きにくいし、学ぶ側も混乱します。 ただ、実際の開発現場はそんなにきれいではありません。 仕様は揺れます。 途中で変わります。 誰かの一言で前提がひっくり返ることもあります。 そして、そのたびにエンジニアは思います。 「早く決めてほしい」 この気持ちは、すごくよく分かります。 決まっていないものを作るのは怖いです。 あとから変わるかもしれないものに対してコードを書くのは、正直かなりストレスがあります。 でも、ここで一度立ち止まって考

AI時代の要件定義で、人間に残る一番大事な仕事 AIを使って要件定義をすると、かなり多くのことが楽になります。 議事録を要約してくれる。 論点を整理してくれる。 抜け漏れを指摘してくれる。 業務フローや画面案を出してくれる。 ユーザー課題や例外パターンもたくさん挙げてくれる。 正直、これまで人間が時間をかけてやっていた「整理する」「書き出す」「たたき台を作る」といった作業は、かなりAIに任せられるようになってきました。 では、AIがあれば要件定義はもう単純作業になるのでしょうか。 私は、そう単純ではないと思っています。 むしろAIによって、要件定義の中で人間がやるべきことが、よりはっきり見えてきたように感じています。 そもそも要件定義とは何か 要件定義というと、よく「システムに必要な機能を決めること」と思われがちです。 もちろん、それも間違いではありません。 たとえば、ログイン機能が必要で

はじめに：AIで無双できると思っていた時期がありました 最近、AIを使ったコーディングがすっかり当たり前になってきました。 AIに指示を出せばコードが組み上がり、開発効率が飛躍的に上がると感じています。 私自身も、要件定義から実装まで一気通貫でAIに任せる開発スタイルを試してきた結論を先にお伝えします。 本記事では、AI開発における「順調だったフェーズ」と「崩壊したフェーズ」、そしてそこから導き出した解決策について、順を追って整理します。 AIツール連携で「最強の布陣」が完成した きっかけは、kiro や spec-kit の登場と「仕様駆動開発」への取り組みでした。 AIによって実装が自動化されるのであれば、ボトルネックは「何を作るか」、すなわち要件定義にあると考えました。 しかし、kiroやspec-kit では、構造化された仕様は生成されるものの、量が多くなることで「最終的に何ができ

彼は、変わらなかった。 「人をくれ」 「時間をくれ」 「予算をくれ」 それが揃わない限り、彼は「何もできない」と言い続けていた。 変わらなかった理由 誤解してはいけない。 彼は無能ではなかった。 コードは書けた。 設計も分かっていた。 過去の失敗談も、成功体験も、山ほど持っていた。 「それ、前にもあった」 「このパターンは危ない」 「このやり方は後で詰まる」 彼の言葉は正しく、経験に裏打ちされていた。 だからこそ、彼は変わらなかった。 知識と経験が、彼の居場所だった 彼の価値は、手を動かすことではなく、知っていること にあった。 ・この構成はスケールしない ・この実装は後で必ず破綻する ・障害はだいたいここから始まる それを指摘できる自分を、彼は誇りに思っていた。 新しいものに触れなくても、自分は「分かっている側」だと信じていた。 AIが導入されたとき 会社にAIツールが入った。 コード生

それなりの期間、CTOや開発部の責任者を務めているが、いつも残酷な事実を突きつけられる。 それは経営層は「開発」そのものには興味がなく、興味があるのは、いくら投資して、いつリターンが得られ、どれほどのリスクがあるかという一点だけということだ。 コードが美しいかどうかも、テストが整っているかどうかも、ドメインモデルが正しいかどうかも、本質的には関心の外側にある。彼らの頭の中には、収支計算と事業リスクの勘定軸しか存在しない。 ところが、AIが一般化し「AIが人の仕事を代替する」という幻想が経営の意思決定に入り込むと、ここに危険な誤作動が起きる。 “AIがエンジニアを置き換える”という誤解が、組織を壊し始めている エンジニアは他業種に比べて人件費が高い。これは不都合な真実だ。サーバー代と合わせると事業上の固定費としての存在感も大きい。だから経営は、AIによって人件費が削減できるなら、それを魅力的