AI を使って内製すると、
開発の何が変わるのか

ピース・ビズで試した範囲では、同じ作業でも工程によって効き方がまったく違いました。

自社サイトと社内業務システムの内製・改善で、進め方として定着したものです。

1. 01

   先に「何を正とするか」を決めるようになった

   同じ情報が複数の場所にある状態のまま作業を始めると、生成された内容が古いほうを参照して食い違いました。どこを原本とするかを先に決め、そこから他が自動的に作られる形にしておくと、ずれが起きにくくなりました。業務システム側でも、同じ値がいくつもの画面に散っている状態から先に整理しています。

2. 02

   「何をもって完了とするか」を先に書くようになった

   受け入れ条件を決めずに着手すると、動くものは出てくるのに受け入れてよいか判断できません。誰がどの場面で使い、何ができれば終わりなのかを先に書いた変更ほど、手戻りが小さくなりました。

3. 03

   確認を人の目に頼らない形にした

   必須項目の欠落、リンク切れ、日付の矛盾のように機械的に判定できるものは、公開前の処理で落ちるようにしています。生成量が増えるほど、目視の確認は先に限界が来ると考えています。

4. 04

   変更の単位を小さく保つようになった

   一度に大きく変えると、うまくいかなかったときにどこが原因か分からなくなりました。速く書けるからこそ、意図の単位で区切って進めたほうが結果として早く終わりました。

5. 05

   作業を並行させるときは、触る範囲を先に分けた

   複数の作業を同時に進める場合、同じ箇所を同時に触ると衝突します。範囲を先に分けておくと並行の利点が出ましたが、分けずに走らせた場合は統合に時間を取られました。

生成物をそのまま本番へ出さないための、最低限の手順です。

1. Step 01

   前提と受け入れ条件を文章にする

   何を変えるのか、変えないのは何か、何ができれば完了なのかを先に書きます。ここが曖昧なまま実装に入ると、出来上がったものを受け入れるかどうかの判断ができませんでした。

2. Step 02

   機械で確かめられることを確かめる

   型の検査、コードの静的な確認、自動テスト、公開前の整合性チェックを通します。人が見るべき範囲を、機械で判定できないところに絞るためです。

3. Step 03

   差分を人が読む

   変更の内容を、意図に照らして人が読みます。動くかどうかではなく、意図どおりかどうかを見る工程です。ここは生成物であっても省いていません。

4. Step 04

   影響が戻せる形かを確認する

   実際のデータに触れる変更では、うまくいかなかったときに元へ戻せるかを先に確認します。業務システム側では、この確認を通していない変更を本番に出さない運用にしています。

5. Step 05

   実際の見え方と使われ方を確認する

   表示や操作を含むものは、実際の画面で確認します。文字の折り返し、モバイルでの表示、キーボード操作のように、コードを読むだけでは判断できない部分があります。

速く書けることと、出してよいことは別です。

原本（Source of Truth）

同じ情報が複数の場所にあるときに、どれを正とするかを決めたもの。ここから他の表示や生成物が作られる状態にしておくと、食い違いが起きにくくなります。

受け入れ条件

何ができれば完了とみなすかを、着手前に文章にしたもの。動くかどうかとは別に、受け入れてよいかを判断するために使います。

検証

作ったものが意図どおりかを確かめる作業。型の検査や自動テストのように機械で判定できるものと、実際の画面で見るしかないものがあります。

並行作業

複数の作業を同時に進めること。触る範囲を分けておかないと、あとで統合する手間が増えます。