AI駆動開発カンファレンス 2025秋の登壇資料となります。 https://aid.connpass.com/event/367697/ 登壇用資料のため、一部ハイコンテキストな内容や厳密性を欠いた表現がございます。 あらかじめご了承ください。
2025年10月20日の僕が考えるAIコーディング（バイブコーディング）プロセスです。 個人的な結論としては、1ミリでも気に食わないコードを生成してきたら、そのタスクは最終的には破棄すべきというものです。「このコード気に食わない」「この設計気に食わない」の直感がAIコーディングで品質を維持する生命線です。 バイブコーディング時代ではコードレビューのお局ビリティが鍵です。 レビューに全時間を割こう。レビューに時間がかかりすぎるというより、レビューに時間をもっとかけるくらい 1ミリでも知らないことをなくそう 断片的なAIコーディングでいえば1年弱、本格的なコーディングエージェントを使い始めて半年以上の僕がたどり着いた結論です。 よろしければ、皆さんのTipsや感想も知りたいです。アップデートしていきたいところです。 前提 僕は実装だけじゃなくて、設計もさせることが多いです Codex使いましょ
こんにちは。Findy Tech Blog編集長の高橋（@Taka_bow）です。 2025年7月3日、ファインディ主催の開発生産性Conference 2025にて、エクストリームプログラミング(XP)の提唱者として知られるKent Beck氏による基調講演が行われました。 本記事では、Findy Conferenceで公開された講演動画とともに、全文の日本語文字起こしをお届けします。前編では、グッドハートの法則の本質と、それが開発現場でどのように機能するのかを解説します。 後編はこちら tech.findy.co.jp 講演動画 ※ 視聴には Findy Conference へのログイン、並びに視聴登録が必要です。ご登録頂ければ、他の講演アーカイブも視聴できます。 講演について Kent Beck氏は、アジャイル開発の礎を築いた開発者として世界的に知られています。 1999年に出版さ
「ITエンジニアを辞めました」──そんな投稿を目にする機会が増えています。あるときはXでの報告、あるときは顧客の採用担当から、そしてまたあるときは人材系事業の中の人から話を聞くようになりました。今、IT業界で何が起きているのかを整理してみます。 辞める人が増えている背景共通しているのは、2019〜2021年頃にプログラミングスクールを経てITエンジニアになった人たちです。しかし、いざ入社してみると現実は想像以上に厳しいものでした。 不況が変えた未経験・微経験採用近年、受託開発会社、事業会社、スタートアップを中心とした不況感の高まりにより、未経験・微経験層の求人が大幅に減少しています。 景気が後退局面にある中で、企業は「教育コストをかけて育てる層」よりも「即戦力として成果を出せる層」を優先するようになりました。これにより、スクール卒のエンジニア志望者が転職活動で行き詰まり、キャリアチェンジを
AI楽観派にとって、「動く」ことがすべての証明。 AI慎重派にとって、「なぜそう動くか」がすべての理由。 両者が同じコードを見ても、 前者は「成果物」を見ており、後者は「思考の痕跡」を見ている。 視点の深度が違うのだ。 5. 設計＝抽象、コード＝具象 コードを書くとき、頭の中には「構造」がある。 それは最初から完璧ではなく、書いて、動かして、違和感を覚えて、直していく。 命名、依存、責務、階層を少しずつ整える。 この「書きながら考える」行為こそが設計であり、 設計書よりもコードの構造そのものが本当の設計書になる。 AI楽観派の前提は、「設計と実装は分離できる」。 AI慎重派の前提は、「設計と実装は不可分」。 この一点が、AI時代の開発を分ける境界線だ。 6. バイブコーディングの議論が噛み合わない理由 バイブコーディングをめぐる議論は、 実は技術論ではなく認識論の衝突だ。 AI楽観派：AI
ヒンドゥーに、二つの体が抱き合う姿をした神がいる。 一体は魔王で、もう一体はそれを鎮めるための観音菩薩だという。その神は障害を取り除き、莫大な富をもたらすが、祀り方を間違えれば、あるいは、捧げるものを怠れば、あらゆるものを奪い去っていく。 富と破滅。聖と俗。歓喜と絶望。極端が同居するその神のことを私が思ったのは、オフィスの壁に真新しいお札を見つけたからだった。 その冬に中途入社したばかりの私は、深夜、缶コーヒーを片手に、天上近くの壁に貼り付けられたお礼を見ていた。梵字のようなものが複雑なパターンを描いて、一見すると禍々しくも見える。 「なんですかこれ？」 ディスプレイに向かっている古株の社員の背中に問いかけた。 「それね、触らないほうがいいよ」古株の社員は、こちらを見もせずに言った。そして警告するように作業の手を止めた。 「毎年大晦日になると社長が東京からわざわざやってきて貼り替えているん
はじめに こんにちは！楽楽勤怠開発チームのoo_yoshiです。 勤怠管理システムは「打刻して残業時間や休暇を計算すれば終わり」と思われがちです。しかし、実際にシステムを開発・運用してみると、その裏には複雑なルールと例外が山ほど存在します。 勤務体系は企業ごとに違い、法律や就業規則も定期的に改正されます。有休の付与や消化ルール、代休や振休の扱い、残業の丸め処理など、ひとつひとつのルールが微妙に違い、組み合わせると膨大なパターンになります。 私たちのチームでは、そうした複雑さに対応するために9年前にDDD（ドメイン駆動設計）を採用し、勤怠システムをリニューアルしました。本記事では、その9年間で感じたこと、分かったことを振り返りたいと思います。 はじめに 旧勤怠管理システムで直面した課題 リニューアル時にDDDを導入して変わったこと 属人化の解消 9年経って実感したDDDの価値 まとめ 旧勤怠
Unixは1969年にAT&Tのベル研究所で誕生して以来コンピュータ技術の歩みそのものを変え，今日，その派生物は社会に欠かせない数多くのシステムの中核にある． 本書はUnixの起源に目を向け，Unixとは何であり，どのようにして生まれ，なぜ重要なのかを説明しており，コンピュータあるいは発明の歴史に興味のある人なら誰にでも読んでもらえるように書かれている． Unixの物語は，ソフトウェアの設計と構築，そしてコンピュータの効果的な使用方法について多くの洞察を与えてくれる． また，技術革新がどのように起こるのかという，関連した興味深い物語もある． なぜUnixはこれほど成功したのか？ それは二度と起こりそうにない特異な出来事だろうか？ これほど影響力のある結果は計画しうるのだろうか？ コンピュータの歴史において特に生産的な形成期にあった時代の素晴らしい物語のいくつかを本書で伝えたい． まえがき
今年に入ってやたらレビューの時間が増えた。これはコードもそうだしドキュメントもそうだ。 そして、これによる疲れも急激に増加している。 もちろんこれは、LLMによる支援によってアウトプットの速度と量が増加したからだ。 そして、必ずしも質が向上しているわけではなく、むしろ下がっているように感じる。 当然、自分の生産性も下がっている。 自分の頭をダンプし、どういう課題があるか、そして、どう向き合っているかを書いていこうと思う。 他人を経由したプロンプティング私は、機械学習のプロジェクトのテックリードとしてしばらく働いている。 その仕事として、Engineering Requirement Documentsなどの技術文章を書くことも多いが、レビューする機会も多い。 機械学習で難しいのが、プロジェクトが変わり解く課題がちょっと変わると、がらりと全然違う知識が必要になり、新規に論文を読む必要が出てく
リモートワークは通勤時間もないし、集中した時間を確保できるので個人としてはとても良いと思っています。 ただし、マネージャーや同僚から「ちゃんと働いてるのかな？」と疑われる可能性は常にあるという話を書きます。 「疑われている」と書くと信用されていないのでは？ と思っていまいますが、受け入れるべき前提だと僕は思っています。 オフィスなら椅子に座ってるだけで「働いてる感」が伝わる。でもリモートでは、見えない。 だからこそ「見えること」を意識して作らないと信頼関係は簡単に崩れてしまいます。 リモートワークは、意図的に見える情報を作ることが重要なんです。 見えないことの不安Slackの返事が数時間ないだけで「作業中」から「サボってる？」に変わる。Pull Requestにコメントがついても翌日まで無反応だと「気づいてないのか、無視してるのか」と思われる。 人は見えないとき、悪い方のシナリオを想像しや
枠組みを変えることで問題を再定義することを「リフレーミング」と呼ぶ。リフレーミングの見事な例は、孫正義のこれ。 髪の毛が後退しているのではない。 私が前進しているのである。 RT @kingfisher0423: 髪の毛の後退度がハゲしい。 — 孫正義 (@masason) January 8, 2013 頭頂部で起きていることは1㍉だって変わっていないのに、ネガティブからポジティブへ再定義されている。こういう発想って、どうやって生まれてくるのだろう？ おそらく、これを読んでいたのではないか？ 本書は、見方を変えることで問題を別の角度から捉えなおし、問題を「再発見」する本だ。ユーモア小話仕立てのエピソードを俎上に、「問題は何か」「それは本当に問題なのか」「それは誰の問題なのか」「それを本当に解きたいのか」を分析していく。 「エレベーター問題」は誰の問題か 有名なやつだと、「エレベーター問題
いわゆるエンタープライズ向けソフトウェア開発技術者向けにお勧めする本をまとめてみた、というか10年くらい前に書いた記事を見直したもの。後輩から「後輩に勧めたい本を教えてください」という相談を受けることがあって（白目）記事が古くなっていたことに気づいたのだった。10年前の記事と同様にSIer勤務でお固めのドメインの受託開発に従事しているエンジニア向けになっていると思う。なお学生、新人、初心者向けにはなっていないのであしからず。 10年以上前に書いた記事はこちら agnozingdays.hatenablog.com ソフトウェア開発ライフサイクル全般 IPA 応用情報処理技術者試験 プロジェクト管理 デッドライン 人月の神話 アート・オブ・プロジェクトマネジメント 見積もり ソフトウェア見積り ～人月の暗黙知を解き明かす～ アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と
こんにちは、kickflowでテクニカルサポートを担当している大谷です。 最近、多くのサービスでAIチャットボットを見かけるようになりました。kickflowでも、お客様の疑問をより迅速に解決し、顧客体験が向上することを目指し、AIヘルプデスクの構築に取り組みました。 今回のプロジェクトでは、テクニカルサポートチームが中心となり、CRE (Customer Reliability Engineer) と協力してAIヘルプデスクを構築しました。 この記事では、非エンジニアである私が、DifyというLLMアプリケーション開発プラットフォームを使い、プロンプトエンジニアリングを駆使して技術的な課題を乗り越えていったプロセスをご紹介します。 技術的な詳細やより深い知見については、今後CREから発信される記事に譲るとして、まずは非エンジニアでもAI開発に挑戦できるということをお伝えできれば幸いです。
私はこれから数週間、このサイトの管理を離れる予定だ（半分は休暇、半分は仕事）。日々のルーティンから離れることを考えているうちに、LLMやAIの現状について、散漫な考えを共有したいと思った。 AIがソフトウェア開発に与える影響についての初期の調査をいくつか目にした。生産性は向上しているのか？コードの品質は上がったのか？下がったのか？などである。こうした調査の大きな問題は、LLMの使い方を考慮していない点だ。私が知る限り、LLMの使い方の大半は（主にco-pilotを使用した）「高機能なオートコンプリート」である。だが、LLMを使いこなしている私の知人たちは、オートコンプリートはあまり役立たないと考えており、LLMにソースコードのファイルの読み込みと編集を許可し、タスクを実行させるアプローチを好んでいる。LLMの使い方を無視した調査は、誤った方向へ人々を導くデータを生み出すのではないかと懸念し
アイスランドアイルランドアセンション島アゼルバイジャンアフガニスタンアメリカ合衆国アラブ首長国連邦アルジェリアアルゼンチンアルバアルバニアアルメニアアンギラアンゴラアンティグア・バーブーダアンドライエメンイギリスイスラエルイタリアイラクインドインドネシアウォリス・フツナウガンダウクライナウズベキスタンウルグアイエクアドルエジプトエストニアエスワティニエチオピアエリトリアエルサルバドルオマーンオランダオーストラリアオーストリアカザフスタンカタールカナダカメルーンカンボジアカーボベルデガイアナガボンガンビアガーナキプロスキュラソーキリバスキルギスギニアギニアビサウギリシャクウェートクック諸島クリスマス島クロアチアグアテマラグアドループグアムグリーンランドグレナダケイマン諸島ケニアココス(キーリング)諸島コスタリカコモロコロンビアコンゴ共和国(ブラザビル)コンゴ民主共和国(キンシャサ)コートジボ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く