Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集していま
失敗を後悔する「恥」としてはならない。 学習する機会と捉え、次に活かせばいいのだ。 そのためのスキルが品質管理だ。 失敗から学んでダブルチェックだと ちょっと前にこのツイートが流れてきた。 失敗を成功に変える唯一の方法https://t.co/0rF2myVk5I pic.twitter.com/9o88CNqSgj— ゆうきゆう/マンガ心療内科/セクシー心理学 (@sinrinet) June 27, 2021 基本的な主張は賛成だ。失敗から学ぶのはコスパが良い。複雑で全てを理解することができない世界において、対処すべき問題を明確にしてくれるからだ。失敗には特定のパターンがあり、対策しなければ未来にも同じ失敗が発生する。だから失敗から学び対策することは、未来の成功を助けてくれる。そして最も学習効率が高いタイミングとは、記憶が新しい失敗した直後だ。 また、失敗を精神論で終わらせないのも正し
トラックの左後輪に限ってタイヤが脱落する事故の原因だが、これはこの10～15年くらいでタイヤに関する規格が色々変わったせいだ。 以前に整備と管理経験があるので説明したい。 ホイール脱落のメカニズムそもそも重量車のホイールが脱落する時、直接の原因はホイールボルトの折れに因る。だがこれはボルトに問題があるのではない。 ホイールナットはホイールをもの凄い力でハブ（車軸の端でホイールボルトが生えている部品）やブレーキドラムに押し付けている。これによってホイールの裏側とハブ/ドラムの間には巨大な摩擦力が発生する。この摩擦力が車の重量を支えているのである。 つまりボルトには引っ張る力だけしかかかっていない。 これが緩むとどうなるか？ ナットが緩むと先の摩擦力が低減する。そして摩擦力が車両重量を支えられなくなるとこの重さはボルトを切断する力になるのである。1.5cm程度の鉄の棒でトラックを持ち上げられる
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022 世界中のITエンジニアが悩まされている問題の1つに、テストが原因不明で失敗する、いわゆる「フレイキーテスト」があります。 フレイキーテストは、リトライすると成功することもあるし、失敗する原因を調べようとしてもなかなか分かりません。GoogleやFacebookやGitHub、Spotifyといった先進的な企業でさえもフレイキーテストには悩まされています。 このフレイキーテストにどう立ち向かうべきなのか、Jenkinsの作者として知られる川口耕介氏がその最新動向を伝えるセッション「Flaky test対策の最新動向」を、4月21日、22日の2日間行われたイベント「DevOps Days Tokyo 2
私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト
∃ナハセド🇳🇿🏳️🌈🏳️⚧️🇺🇦🇵🇸通知OFF @yonahasedo1 繰り返し言ってるけど、「人口100人の村で70人が結託して残り30人を奴隷にするよう多数決で決める」は民意と言えるし全体主義だけど民主主義ではありません。民主主義にはこの場合に「30人の人権に触れるので、この多数決は無効です」と撤回出来るフールプルーフの仕組みが存在します。 2022-07-21 00:10:23 ∃ナハセド🇳🇿🏳️🌈🏳️⚧️🇺🇦🇵🇸通知OFF @yonahasedo1 あえてフールプルーフって言っとくよ。「30人を奴隷にするのは民意です。この30人の中には奴隷になる事を望んでいる者もいます。民主主義では民意に逆らってはいけません」は完全にフールだもん 2022-07-21 00:16:50 ∃ナハセド🇳🇿🏳️🌈🏳️⚧️🇺🇦🇵🇸通知OF
太平洋戦争で日本軍と戦ったイギリス軍のある司令官は、日本軍の上層部の体質を次の様に喝破していた。 「日本軍の指導者の根本的な欠陥は、“肉体的勇気”とは異なる“道徳的勇気の欠如”である。彼らは自分たちが間違いを犯したこと、計画が失敗し、練り直しが必要であることを認める勇気がないのだ」（第14軍 ウィリアム・スリム司令官 ※タイトル画像の人物） 戦いの舞台となったのは、インパール作戦で知られるビルマ戦線（現在のミャンマー）。実は、太平洋戦争で“最も無謀”といわれたインパール作戦のあと、それをはるかに上回る命が失われていたのだ。 指導者たちのどのような体質が、さらなる“地獄”を作り出したのか。 77年の時を経て、私たちが直視すべき「道徳的勇気の欠如」、その実態をひもとく。 （NHKスペシャル「ビルマ絶望の戦場」取材班）
飛び交う怒号、やまない電話、不夜城と化した会議室。 集められたホワイトボードが衝立のように立ち並び、全員が立って仕事をしている（座る間が無いから）。週をまたぐとメンバーの疲弊が目に見えはじめ、月を跨げば一人二人といなくなり、仕事場はお通夜となる。 トラブルの無いプロジェクトは存在しない。炎上するかボヤで済むかの違いなだけで、大なり小なりトラブルは付きものである。 自分が所属する部署は大丈夫かもしれない。だが、隣のブースだとか、同期がいるチームで炎上しているのを横目で見ながら仕事する、なんてことがある。ホワイトボードは目につくし、大きな声はイヤでも耳に入ってくるので、プロジェクトが炎上⇒鎮火するパターンなんてものも、なんとなく伝わってくる。 消火作業のイロハとか、怒った客をあしらう方法、リカバリ計画の立て方なんてのも、肌感覚で分かってくる。 そして、トラブルの扱いが分かってくる頃には、「応援
質とスピード（2022春版、質疑応答用資料付き）
答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」（その1）。ソフトウェア品質シンポジウム2022 9月22日と23日の2日間、一般財団法人日本科学技術連盟主催のイベント「ソフトウェア品質シンポジウム2022」がオンラインで開催され、その企画セッションとして行われた和田卓人氏による講演「組織に自動テストを書く文化を根付かせる戦略（2022秋版）が行われました。 講演で、企業の業績はソフトウェアの開発能力に左右されるようになってきていること、その開発能力を高める上で重要なのがコードの「テスト容易性」や「デプロイ独立性」であると和田氏は指摘。その上で、それを実現させるような「自動テストを書く文化」をどうすれば組織に根付かせることができるのか、講演の後半ではこの本質的な議論へと踏み込みます。 本記事は、2時間におよぶこの講演をダ
※品質保証のエンジニアである筆者が自省・戒めのために書いた記事になります 品質管理（Quality Control）、品質マネジメントは国内では製造業を中心に発展し、プロダクトの競争力向上に貢献してきました。 JTCと呼ばれる旧来からのメーカーでは、その実績・年功の蓄積に応じて、独立性を保った品質管理・品質保証部門が権威を獲得し、今でもソフトウェア開発に強い影響力を保持するようになっています。筆者は複数のメーカーを転職やコンサルで巡って来ましたが、例えば品質保証部門が承認しないとマイルストーンで開発がブロックされる、プロダクトがリリースできないといった権限を持つ体制が、今なお普遍的に見受けられます。 この品質保証部門が権力を持ち、品質ゲートの門番として振る舞う体制は、今であっても、ある面で恩恵を提供しています。例えば次のようなものです： 法規制対応、標準化対応、その他公的なガバナンス要求へ
アメリカの構造エンジニアであるウィリアム・ルメジャーは、ボストン市庁舎やシンガポールのAXAタワーなど、さまざまな建築物の設計に携わった人物です。そんなルメジャーが、「自分が設計したニューヨーク市マンハッタンの超高層ビルが嵐で倒壊するかもしれない」と気付いた時、一体どうしたのかについてまとめた動画がYouTubeで公開されています。 The Most Dangerous Building in Manhattan - YouTube 1960年代、金融大手のシティコープ(現シティグループ)がマンハッタンに新しい本社を建設しようとしていました。 ちょうど付近の街区全体が売りに出されていましたが、その一角にはセント・ピーター福音ルーテル教会という古い教会がありました。シティコープが交渉したところ、教会は立ち退きを拒否。 その代わり教会側は、古い教会を新しいものに建て直し、シティコープのビルとは
GitHubでAIレビューを組み込む 〜Claude Code Actionデモ&AIエージェントの設計方針〜 / Claude Code Action for beginners
というのを使っていて思ったのでレポを書いていきます。 mabl とは - 基本的な機能 ざっくり言うと E2E テストをお手軽にメンテできるツールです。 こんな感じでポチポチ画面を操作していくと、それで実行したアクション(ボタンやリンクをクリックするなど)を自動で記録してくれて、E2E のテストを作成することが出来ます。 コードを書かずに E2E テストをサクッと作れちゃうのが魅力な訳ですが、それだけではありません。そんなすごいところを紹介していこうと思います。 mabl のここがすごい Auto Healing 何やら回復魔法みたいな感じでかっこいいですが、何かというと E2E テストがコケるようになった時に自動で修復してくれる機能です。 例えばボタンの位置が変わってしまっても、同じ文脈であろうボタンを自動で探して修復したりしてくれます。 E2E での辛さといえば、やはりテストのメンテナ
WACATE 2024 冬での発表資料です。 【参考文献】 ・『名著復刻 日本的品質管理 TQCとは何か』 …
Today we're introducing Code Review, which dispatches a team of agents on every PR to catch the bugs that skims miss, built for depth, not speed. It's the system we run on nearly every PR at Anthropic. Now in research preview for Team and Enterprise. Managing the review bottleneckCode output per Anthropic engineer has grown 200% in the last year. Code review has become a bottleneck, and we hear th
変化の激しい社会で成長を続けるため、新規事業の立ち上げに乗り出す企業が増えています。そんな中、タスクの進捗管理・日程調整・社内外との交渉など、多岐にわたる仕事を抱え、責任者としての重圧に悩んでいるプロジェクト担当者も多いのではないでしょうか。本記事では、DXサービスの新規事業を立ち上げた、エン・ジャパン株式会社の高橋淳也氏がゲストに登場。業務改善のためゼロからDXを勉強し、最終的にサービス化するまでに至った高橋氏が、プロジェクトマネジメントの課題を解決するヒントをお届けします。前編は、プロマネの仕事にまつわる誤解や、プロジェクトにおけるチームの重要性について語られました。 サイボウズ社員の4人に1人が受けた、人気のプロマネ勉強会 小林悠氏（以下、小林）：それではみなさま、こんにちは。「なぜプロジェクトは難しいのか ーチームで旅するプロジェクトマネジメントー」という40分間のセッションを始め
Developers Summit 2021 Summer［A-1］アジリティを支える品質特性 講演日時: 2021年07月30日（金） 10:00 ～ 10:45 概要: ビジネスにとってITは、「あると便利」から「有効」、「不可欠」を経て「中核そのもの」になりつつあり、柔軟かつ俊敏に…
けんけん @nekomimi999 沖縄出身、関東在住 30代 エンジニア10年目 最近は顧客調整ばかりのエンジニア 取得資格：FE/AP MBTI：ENFP けんけん @nekomimi999 技術技術ばっかり言ってるエンジニアと自分が合わないのは 「で、それで会社にいくら金が入ります？」 という考えが自分にはあって相手にはないからなのかね？ 端的に言うと、あなた1名が稼ぐお金より中堅エンジニアを3名増員して稼ぐお金のほうが多いし、コーディングよりも要件定義できる人のほうが単価は高くなるからねえ。 この考え、そんなに間違ってない気がするんですけどねえ 2024-12-22 07:22:15
ぎーち(ブレイク兄) @BREAK_BROTHER SEEの各症状の影響について調べてたんだけど、過去に読んで面白いなと思えた記事を久々に見た。 スーパーマリオ64のRTAプレイ中にマリオが急にワープしたってバグ技が8年の歳月を経て、人工衛星でも問題になる宇宙放射線によるSEU(Single Event Upset)が原因だったって話。 switchsoku.com/soft/mario_ody… 2024-03-27 20:19:54 リンク GIGAZINE スーパーマリオ64のRTAと宇宙線の奇妙な関係 ゲームをプレイしている時に急にバグが発生してプレイが続行できなくなるケースがありますが、これの原因はソフトウェア由来であったりハードウェア由来であったりとさまざまです。しかし、ソフトウェアとハードウェアの問題を修正した場合であってもバグが起こり続けるケースがあるもの。そんな場合のバグ
はじめに「AIは速度をフロントローディングし、失敗をバックローディングする」 Opsera社が25万人のエンジニアを分析した2026年版ベンチマークレポートに記されたこの一文は、AI時代のソフトウェア開発組織が直面している本質的な矛盾を的確に言い当てている（出典: Opsera AI Coding Impact Benchmark Report 2026）。93%の開発者がAIツールを使い、コーディング速度は30〜58%向上した。しかしその代償として、PR レビュー時間は441%増大し、本番インシデント数は242.7%増加し、開発者一人あたりのバグ数は54%増加した（出典: Faros AI Engineering Impact Report 2026）。 AIは組織を速くした。しかし、強くはしていない。 3つの独立した大規模調査が同じ結論を示すStanfordが10万人のエンジニアを対象
はじめに 「全エンジニアが Claude Code を 100% 活用する」 これは、ダイニーの今期の目標のひとつです。 正直、最初に思ったのは「何をもって 100% なんだ？」です。 手がかりを探るために、まずチーム全員にアンケートを取りました。 結果はバラバラで、「かなり活用できている」という人もいれば、「スキルやサブエージェントはほとんど使えていない」という人もいます。 中でも多かったのが、「他の人がどう活用しているのか分からない」という声でした。 実際、有志がスキルやサブエージェントを作っても、その存在自体を知らないメンバーがいます。知っていても中身が分からないから使えない。結局、作った本人しか使わないまま埋もれていく。そんな状態です。 これでは「活用度」以前の問題。 そもそも何が使えるのか、誰がどう使っているのかが見えなければ、活用度を定義できません。 そこで作ったのが、エンジニ
はじめに サマリー 記憶に対する自信過剰 対策 チームや組織で失敗を防ぐには？ 1. 読みやすいコードを書くためのコストを下げる 2. 読みやすいコードを書くことを（ゆるく）強制する まとめ 参考文献 ※三浦は退職していますが、本人の同意を得て、掲載を継続しています。 はじめに こんにちは。パーソルキャリア株式会社でデータアナリストとして働いている三浦です。 私はデータアナリストとしてこの会社で働いておりますが、それと同時に行動経済学の研究もしています。 行動経済学は端的に言えばより「人間くさい」仮定をとりいれて経済学的な分析を行う分野です。 例えば、先延ばしをするとか、楽観的な予想をするとか、情報を無視するとか、人の目を気にするとか、色々です。 修士から数えるとプログラミングは 9 年ぐらい行ってきました。 その過程で、様々な失敗もしてきました。 中には、誰もがしたことのある失敗もあるか
テスト自動化フレームワーク「Playwright」にAIエージェント機能。自動的にテスト計画とテストコードの生成、テストコードのデバッグなど マイクロソフトが主導して開発しているオープンソースのテスト自動化フレームワーク「Playwright」の新バージョン「Playwright 1.56」がリリースされました。 Playwrightはデスクトップ向けのWebアプリケーションやモバイル向けのWebアプリケーションのテスト自動化が可能で、Chromium、WebKit、Firefoxなどの主要なモダンブラウザのエンジンのヘッドレス、ヘッドありのいずれの環境でも実行可能です。 OSはWindows、macOS、Linuxをサポートします。 テストはJavaScript、TypeScript、Java、Python、C＃などで記述でき、ローカル環境での実行だけでなく、CI（継続的統合）環境での実
開発スピードの速い企業は品質が高く、遅い企業は品質が低い。和田卓人氏による「組織に自動テストを根付かせる戦略」（その2）。ソフトウェア品質シンポジウム2022 9月22日と23日の2日間、一般財団法人日本科学技術連盟主催のイベント「ソフトウェア品質シンポジウム2022」がオンラインで開催され、その企画セッションとして行われた和田卓人氏による講演「組織に自動テストを書く文化を根付かせる戦略（2022秋版）が行われました。 講演で、企業の業績はソフトウェアの開発能力に左右されるようになってきていること、その開発能力を高める上で重要なのがコードの「テスト容易性」や「デプロイ独立性」であると和田氏は指摘。その上で、それを実現させるような「自動テストを書く文化」をどうすれば組織に根付かせることができるのか、講演の後半ではこの本質的な議論へと踏み込みます。 本記事は、2時間におよぶこの講演をダイジェス
むへどるり @muhedoruri 現場猫は「茶化し」ではない。あらあゆる手段で人々に労災事例を知ってもらおうとした結果ちょっと可愛い絵柄になっただけで、あの絵の向こうにはたくさんの死者たちの無念がある。僕らは知らなければならない。 2022-08-29 19:05:51 むへどるり @muhedoruri 現場に出る人間は皆シリアスなテンションで労災事例を学習したことがある。だけどそれらの学習ビデオや画像はシリアスすぎて一般には全く広まらなかった。それを乗り越えたのが「現場猫」だった。 2022-08-29 19:13:59 むへどるり @muhedoruri 現場の人々による雑コラから始まり、うっかり原作者に認知され、消えてしまうかと思いきや「魂」の部分が原作者に理解されて公式化し、本当に現場ポスターとして普及するだけでなくキャラクターとして広く認知されるに至った。労災というファクター
Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest. →
サムソン高橋 @samsontakahashi 都心の死の街こと最寄り駅に唯一あるファミレスがサイゼなのでひさしぶりに行ったらエサレベルの味だった。私のバカ舌が進化したとも思えないので味は確実に低下してないだろうか x.com/DTH03597062/st… 2026-05-29 09:19:17 DTH 郝老师 @DTH03597062 めっちゃ同感。北京のサイゼは普通に美味しいイタ飯屋で感動したけど、日本帰国後にその感動を反芻したくて行ったらガッカリした。サイゼにネガティブなことを言うと叩かれるからちょっと怖いけど、少なくとも北京のサイゼの方が美味いというのは間違いないと思う。 x.com/b_mansion_no9/… 2026-05-28 22:38:26 掟ポルシェ @okiteporsche 我々サイゼ大好き民の願い虚しく、サイゼは2年程前に品質を落としてでも低価格を維持する方
【ヤマハ発動機×SUBARU×三菱電機】今こそ考えたい「開発プロセスの品質視点」登壇資料です。 https://techplay.jp/event/967093
ひとつのソフトウェアコンポーネントが多くの開発者によって変更されると、品質に悪い影響を与えると経験的に感じている。設計に一貫性が失われることや、知識の浅い状態で変更することによるバグ混入の可能性が高まるからだ。 2011年9月に公開されたマイクロソフト社の調査結果、"Don’t Touch My Code! Examining the Effects of Ownership on Software Quality" は、この「コードのオーナーシップはソフトウェアの品質を左右する」という経験則を裏付けるものだった。全体のコミット数のうち5%未満の貢献にとどまる開発者が多いコンポーネントは、リリース前後における故障が増加するというものだ。 本稿では、このマイクロソフトによる調査結果を紹介し、それを踏まえた上で、ソフトウェアプロダクトの品質悪化を抑えるための組織やプロセス、アーキテクチャについ
週4社員しながら個人開発にベットする / Betting on Personal Projects While Working a Four-Day Week
ソフトウェアアーキテクチャメトリクス - Forkwell Library #44 での発表資料です https://forkwell.connpass.com/event/309739/ 動画: https://www.youtube.com/watch?v=C52rYX_E9bA …
ソニーやカシオ、パナソニックなど、日本には世界有数のハードウェアメーカーが数多く存在している一方で、ソフトウェアの多くは海外製品に頼っていることが多く、日本のソフトウェアの品質の低さが指摘されています。その理由について、ポッドキャスト配信者のティム・ロメロ氏が解説しています。 The forgotten mistake that killed Japan’s software industry - Disrupting Japan https://www.disruptingjapan.com/the-forgotten-mistake-that-killed-japans-software-industry/ 日本製ソフトウェアの品質が低い原因は、明治時代に生まれた財閥にあるとのこと。大企業グループまたは家族経営の企業グループである財閥は、当時の政府に対して強い影響力を持っており、政府に
404Not Found 申し訳ありません。 指定されたページは準備中または削除されたため、現在ご覧いただけません。 このページは15秒後にHBCトップページへ移動します。 移動しない場合はボタンをクリックしてください。 HBCトップページへ
「トヨタの社長は部品加工の現場の状況をご存じないのだろうか。今や自動車や設備の部品のものづくりは、ほぼ加工メーカーが支えていると言っても言い過ぎではない」。トヨタ自動車や同社グループから自動車や設備の部品加工を請け負うある中小企業（以下、加工メーカー）の社長の言葉だ。トヨタの豊田章男社長は、新型コロナウイルス禍で先が全く見通せない中にあった2020年3月期決算発表（20年5月）の席で「日本には
小学生に複雑に見えることが、中学生にはシンプルに見える。中学生が頭を抱えていたことも、高校生になると「なんでこれで悩んでたんだろう」に変わる。 この構図を、そのまま先まで延ばしてみる。すると、ちょっと不穏な未来が見えてくる。 「人間に複雑すぎるものも、実は超知性にはシンプルに見えるのではないか」 仮にそうだとすると、Keep it simple, stupid という原則も別の顔を見せ始める。 ここでいう「シンプル」は、コード行数が少ないとか、人間に説明しやすいという意味ではない。ある目的に対して、例外が少なく、状態遷移が安定し、探索空間が小さいという意味でのシンプルさだ。 将来の超AIにとっての「シンプル」は、人類には複雑すぎて、もう手に負えない。 SFっぽい話に聞こえるだろうか。でも僕は、これはかなり実務寄りの論点だと思っている。なぜなら、この話は最終的に「AIが書いたものを人間がどこ
LayerX QAエンジニアの小山です。 昨今、AIコーディングアシスタント（特にClaude Code等）の進化により、コードの実装やテスト追加のスピードが飛躍的に向上しています。しかし、AIにコードを書かせる際に「どこまで厳密なエラーハンドリングが必要か」「テストはどの程度書くべきか」といったことに迷われた経験はないでしょうか？ 今回は、バクラク事業部の品質の定義やテスト戦略などを言語化し、Claude Codeが動く際にリスクの高い箇所を守るように動いてもらい、テストも同時に生成してもらう、早期テストで時間とコストを節約する試みについてご紹介します。 ソフトウェアテストの原則「早期テストで時間とコストを節約する」 筆者はJSTQB FLの公認コースのトレーナーを15年ほどしているのですが、JSTQB FLシラバスの中に「テストの原則」として７つの原則があります。その中の１つとして「早
前回の記事では、ベンチマーク特性の違いから「Claude Codeで実装→Codexでレビュー」というクロスモデル分業が合理的であることを検証した。 しかし、この分業を手動で回すのは現実的ではない。Claude Codeで実装が終わるたびにCodex CLIを別ターミナルで立ち上げ、計画やdiffをコピペし、レビュー結果を手動で戻す——この往復を繰り返せば、クロスモデルの品質向上分を人間の手間が相殺する。 2026年2月末時点で、このレビューループを自動化するアプローチが複数の開発者から独立して公開されている。本稿ではそれらを導入コスト順に整理し、「最短で動くもの」から「チーム運用に耐えるもの」までの3段階で解説する。 前提知識：Claude CodeからCodex CLIを呼ぶ際の制約¶自動化の実装に入る前に、1つの技術的制約を押さえておく必要がある。 Claude Codeのbash環
🚀 TL;DR AI（LLM）に生のソースコードを読ませるのは、実は効率の悪い「情報の暴力」である。 AST（抽象構文木）から「構造」だけを抽出したマップこそが、AIのIQを極限まで引き出す。 データの流入から破綻までをグラフ理論で定義すれば、理論上、脆弱性は100%特定可能となる。 1. はじめに：AIレビューの「限界」と「嘘」 最近、GitHub CopilotやChatGPTにコードを貼り付けて「脆弱性ある？」と聞く手法が定着しました。しかし、大規模なプロジェクトになればなるほど、AIは以下のような致命的な欠陥を露呈します。 コンテキストの霧：数千行のコードを前に、AIは「どの変数がどこから来たか」を見失い、平気でハルシネーション（嘘）をつく。 トークンの浪費：コードの「書き方」というノイズに注目してしまい、肝心の「ロジックの破綻」に辿り着く前にリソースを使い果たす。 そこで私は、
きっかけ：支援先のスプリント開発で見えた課題 技術顧問として入っている会社で、スプリント開発の現場を見ていてずっと気になっていたことがあった。 QAチームのテストケース作成がボトルネックになっている。 具体的にはこんな状況だった。 スプリント後半にQAの作業が溜まり、テストケース作成が間に合わない JIRAチケットの受け入れ条件からテストケースへの変換が完全に手作業 QAメンバーはコードを読めないので、エンジニアに「この変更、何に影響する？」と毎回聞く 新しいQAメンバーが入ると、テスト観点を覚えるまでに時間がかかる OpenObserveでも同じような課題があったらしく、Claude Codeで自動化したところ特徴分析が45〜60分から5〜10分に短縮、テストカバレッジも380から700以上に増えたという記事を見つけた。 これを参考に、Claude CodeのSkills・サブエージェン
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く