Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
|
||
| ## 私の実体験:小さい道具づくりに、ウォーターフォールはいらなかった | ||
|
|
||
| 私は普段、設計開発を支えるアプリケーション、テスト工程の自動化スクリプト、エビデンス収集スクリプト、レポート生成スクリプトを、**ほぼすべて AI に作ってもらっています**。要件定義書も設計書も書きません。AI Agent に要件を伝え、ツールが出てきて、E2E で動作確認する。それで完結しています。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/no-doubled-joshi> reported by reviewdog 🐶
一文に二回以上利用されている助詞 "も" がみつかりました。
次の助詞が連続しているため、文を読みにくくしています。
- "も"
- "も"
同じ助詞を連続して利用しない、文の中で順番を入れ替える、文を分割するなどを検討してください。
(ja-technical-writing/no-doubled-joshi)
|
|
||
| 一方で、私がプロジェクトで構築するシステムは、サービス・モジュール・機能ごとに**要件が大量にあり、それらが互いに依存して複雑な構造**を成しています。 | ||
|
|
||
| ここで「要件定義 → 設計 → 実装 → テスト」の各フェーズを工程管理せず、AI で一気に短縮しようとするのは、**リスクが高すぎる**と考えています。理由は単純で、 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/ja-no-mixed-period> reported by reviewdog 🐶
文末が"。"で終わっていません。
理由: 句点は文の境界を明確にし、読み手の理解を助けます
修正: 適切な文末表現で文を完結させ、句点を追加してください
例: 「〜です。」「〜ます。」「〜でした。」など (ja-technical-writing/ja-no-mixed-period)
|
|
||
| 工程名は同じでも、**中で起きていることがまったく違う**。これが現場の実感です。 | ||
|
|
||
| 骨格を維持する理由は、認知負荷だけではありません。**規模と複雑さに対して、判断の根拠と変更の履歴を残す**ためです。これがなければ、AI が出したものを誰も検証できず、改修も継承もできなくなります。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/no-doubled-joshi> reported by reviewdog 🐶
一文に二回以上利用されている助詞 "も" がみつかりました。
次の助詞が連続しているため、文を読みにくくしています。
- "も"
- "も"
同じ助詞を連続して利用しない、文の中で順番を入れ替える、文を分割するなどを検討してください。
(ja-technical-writing/no-doubled-joshi)
| 1. **エンジニアリングプロセスのデザインに組み込める(最大のメリット)**:契約という共通言語があるからこそ、Agent を工程の中に "部品" として配置でき、入出力を起点にプロセス側を設計し直せる。プロセスに組み込めないものは、いずれ属人運用に逆戻りする | ||
| 2. **責任分界が明確になる**:Agent が何をやって、何をやらないかが言語化される | ||
| 3. **改善サイクルが回る**:契約に対する充足率を測れるので、Agent の改善が定量的になる | ||
| 4. **置き換えが効く**:契約が同じなら、中身のモデル(GPT-x → Claude-x → ローカル LLM)を差し替えられる |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/no-doubled-joshi> reported by reviewdog 🐶
一文に二回以上利用されている助詞 "が" がみつかりました。
次の助詞が連続しているため、文を読みにくくしています。
- "が"
- "が"
同じ助詞を連続して利用しない、文の中で順番を入れ替える、文を分割するなどを検討してください。
(ja-technical-writing/no-doubled-joshi)
|
|
||
| L3 / L4 に踏み込むかどうかは、「**何のバイアスを排除したいか**」という狙いで決めるべきです。自己選好バイアスを潰したい、異なる知識ベースで補完したい、といった具体的な狙いがあれば L4 の運用負荷も元が取れます。一方、狙いが言語化できないまま「ベンダーを混ぜた方が良さそうだから」で構成すると、運用負荷だけが増えます。 | ||
|
|
||
| ポイントは、**検証の独立性は "あるかないか" ではなく "どこまで取るか"** という設計判断だ、ということです。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/no-doubled-joshi> reported by reviewdog 🐶
一文に二回以上利用されている助詞 "か" がみつかりました。
次の助詞が連続しているため、文を読みにくくしています。
- "か"
- "か"
同じ助詞を連続して利用しない、文の中で順番を入れ替える、文を分割するなどを検討してください。
(ja-technical-writing/no-doubled-joshi)
|
|
||
| **(3) Check は "重要ポイント" にだけ人間が介入する** | ||
|
|
||
| Component の自動検証を通過した成果物に対して、人間は全件ではなく**抜打ち検査**を行います。代わりに、Hard Gate(後述)では必ず人間が判断する。**人間の時間を、判断の難易度が高い領域に集中させる**のがポイントです。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/ja-no-redundant-expression> reported by reviewdog 🐶
【dict5】 "検査を行う"は冗長な表現です。"検査する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5 (ja-technical-writing/ja-no-redundant-expression)
| | カスタム性 | プロンプト依存 | OSS のモデルに従う | **行動方針・Script 挙動を自分で定義** | | ||
| | アウトプット再現性 | セッションごとに揺れる | 高い(ただし OSS の枠内) | **行動方針と固定挙動の合わせ込みで安定** | | ||
|
|
||
| ポイントは、**Agent / Harness の行動方針** と **Script に任せる固定的な挙動** を自分の言葉で定義できていることです。これがあるから、 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/ja-no-mixed-period> reported by reviewdog 🐶
文末が"。"で終わっていません。
理由: 句点は文の境界を明確にし、読み手の理解を助けます
修正: 適切な文末表現で文を完結させ、句点を追加してください
例: 「〜です。」「〜ます。」「〜でした。」など (ja-technical-writing/ja-no-mixed-period)
| - アウトプットの揺れが小さくなり、結果が安定する | ||
| - それでいて、必要なときに自分でカスタム可能なまま | ||
|
|
||
| という三立ちが取れています。AI ツールを場当たり的に使うと、自由度を上げるほどアウトプットが揺れがちですが、**行動方針と固定挙動を分けて定義する**ことで、揺れの原因を構造側で抑え、自由度はそのまま握れます。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/max-ten> reported by reviewdog 🐶
一つの文で"、"を4つ以上使用しています (ja-technical-writing/max-ten)
|
|
||
| Harness Agent を運用チームに引き渡すフェーズで、想定外に苦戦したのが**導入そのもの**でした。 | ||
|
|
||
| 前提として必要なのは、それほど複雑なことではありません: |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/ja-no-mixed-period> reported by reviewdog 🐶
文末が"。"で終わっていません。
理由: 句点は文の境界を明確にし、読み手の理解を助けます
修正: 適切な文末表現で文を完結させ、句点を追加してください
例: 「〜です。」「〜ます。」「〜でした。」など (ja-technical-writing/ja-no-mixed-period)
| ここから学んだ教訓は二つです。 | ||
|
|
||
| 1. **導入工数を技術的にゼロに近づけても、組織的なゼロにはならない**。導入のためのアサインを、上長を巻き込んで明示的に確保する仕組みまでがセットで初めて "導入可能" になる。 | ||
| 2. **AI 駆動開発の最大のボトルネックは、技術ではなく "最初の半日" を組織として誰が確保するか**である。これは Harness の設計では解けない。組織側の問題として、別の手段(経営層からのトップダウン、専任の導入支援担当の派遣など)で解決する必要があります。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/no-mix-dearu-desumasu> reported by reviewdog 🐶
箇条書き: "である"調 でなければなりません
=> "である"調 であるべき箇所に、次の "ですます"調 の箇所があります: "ます。"
Total:
である : 1
ですます: 1
(ja-technical-writing/no-mix-dearu-desumasu)
|
|
||
| AI は確率的に間違えます。これは仕様です。 | ||
|
|
||
| 問題は、**間違いをどう検知し、どう次の改善に回すか**です。人間レビューに全量を流せば速度が犠牲になり、ノーチェックで流せば信頼が犠牲になる。一回限りの "検証" ではこのジレンマは解けません。**検証を改善ループに組み込む**ことで、はじめて構造的に解けます。 |
There was a problem hiding this comment.
[textlint-fix] reported by reviewdog 🐶
| 問題は、**間違いをどう検知し、どう次の改善に回すか**です。人間レビューに全量を流せば速度が犠牲になり、ノーチェックで流せば信頼が犠牲になる。一回限りの "検証" ではこのジレンマは解けません。**検証を改善ループに組み込む**ことで、はじめて構造的に解けます。 | |
| 問題は、**間違いをどう検知し、どう次の改善に回すか**です。人間レビューに全量を流せば速度が犠牲になり、ノーチェックで流せば信頼が犠牲になる。1回限りの "検証" ではこのジレンマは解けません。**検証を改善ループに組み込む**ことで、はじめて構造的に解けます。 |
|
|
||
| そして、人間側の私の役割は 3 つ:**要件を出すユーザー**、**UAT 担当**、そして**キャリブレーター**です。 | ||
|
|
||
| ## Component の構成管理 ―― PDCA を回すための前提 |
There was a problem hiding this comment.
[textlint-fix] reported by reviewdog 🐶
| ## Component の構成管理 ―― PDCA を回すための前提 | |
| ## Component の構成管理 ── PDCA を回すための前提 |
|
|
||
| Claude Code や OSS で良いのでは？ という疑問が湧くと思います。 | ||
|
|
||
| 実際、Claude Code それ自体がタスク単位の Harness としては非常に優秀です。Sub Agent・MCP・Skill・Script を駆使し、結果を確認しながら成果物を返す ―― これは本稿で述べた Harness の振る舞いそのものです。 |
There was a problem hiding this comment.
[textlint-fix] reported by reviewdog 🐶
| 実際、Claude Code それ自体がタスク単位の Harness としては非常に優秀です。Sub Agent・MCP・Skill・Script を駆使し、結果を確認しながら成果物を返す ―― これは本稿で述べた Harness の振る舞いそのものです。 | |
| 実際、Claude Code それ自体がタスク単位の Harness としては非常に優秀です。Sub Agent・MCP・Skill・Script を駆使し、結果を確認しながら成果物を返す ── これは本稿で述べた Harness の振る舞いそのものです。 |
|
|
||
| ## 失敗談:導入の時間が捻出できない、という壁 | ||
|
|
||
| 最後に、現場でリアルに刺さった失敗談を一つ。 |
There was a problem hiding this comment.
[textlint-fix] reported by reviewdog 🐶
| 最後に、現場でリアルに刺さった失敗談を一つ。 | |
| 最後に、現場でリアルに刺さった失敗談を1つ。 |
|
|
||
| > 「やることは分かっている。でも、その半日を捻出できない」 | ||
|
|
||
| レポジトリをクローンすれば、導入作業自体も Claude Code がほぼ自動でやってくれる ―― **そういう状態を作ってあるのに、その入口に立つ時間すら取れない**。皮肉なのは、**忙しい現場ほど AI 活用でなんとかしたいと願っている**ことです。導入できれば楽になることが見えている。でも、その「楽になる前の小さな段差」を越える時間が、最も忙しい人にこそ存在しない。 |
There was a problem hiding this comment.
[textlint-fix] reported by reviewdog 🐶
| レポジトリをクローンすれば、導入作業自体も Claude Code がほぼ自動でやってくれる ―― **そういう状態を作ってあるのに、その入口に立つ時間すら取れない**。皮肉なのは、**忙しい現場ほど AI 活用でなんとかしたいと願っている**ことです。導入できれば楽になることが見えている。でも、その「楽になる前の小さな段差」を越える時間が、最も忙しい人にこそ存在しない。 | |
| リポジトリをクローンすれば、導入作業自体も Claude Code がほぼ自動でやってくれる ── **そういう状態を作ってあるのに、その入口に立つ時間すら取れない**。皮肉なのは、**忙しい現場ほど AI 活用でなんとかしたいと願っている**ことです。導入できれば楽になることが見えている。でも、その「楽になる前の小さな段差」を越える時間が、最も忙しい人にこそ存在しない。 |
|
|
||
| レポジトリをクローンすれば、導入作業自体も Claude Code がほぼ自動でやってくれる ―― **そういう状態を作ってあるのに、その入口に立つ時間すら取れない**。皮肉なのは、**忙しい現場ほど AI 活用でなんとかしたいと願っている**ことです。導入できれば楽になることが見えている。でも、その「楽になる前の小さな段差」を越える時間が、最も忙しい人にこそ存在しない。 | ||
|
|
||
| ここから学んだ教訓は二つです。 |
There was a problem hiding this comment.
[textlint-fix] reported by reviewdog 🐶
| ここから学んだ教訓は二つです。 | |
| ここから学んだ教訓は2つです。 |
|
|
||
| ## これからについて | ||
|
|
||
| これからのエンジニアリングプロセスの発展として、私が広げていきたいのは次の二つのカバレッジです。 |
There was a problem hiding this comment.
[textlint-fix] reported by reviewdog 🐶
| これからのエンジニアリングプロセスの発展として、私が広げていきたいのは次の二つのカバレッジです。 | |
| これからのエンジニアリングプロセスの発展として、私が広げていきたいのは次の2つのカバレッジです。 |
1 participant
No description provided.