【超シンプル解説】AGI駆動開発って、結局なにが楽になるの？
難しそうな言葉が続くと、
そこで読むのをやめたくなりますよね。
なので最初に、
一番大事なことだけ言います。
AGI駆動開発は、
「作り方」の話じゃありません。
「時間の使い方」を変える話です。
今までのやり方を、超シンプルに言うと
今までの開発は、だいたいこんな流れでした。
まず仕様書を書く
会議をする
また仕様書を書く
伝わってない気がする
直す
まだ完成しない
ここで多くの人が思っています。
「これ、いつ終わるの？」
私は一瞬システム部門で働いていたので
少し覚えてます。
① 見えない損失
→ 仕様書を書く時間で、一日が終わる
仕様書を書くこと自体は、悪くありません。
でも現実は、
書く
直す
直しても、また書き直す
一日が“文章”で終わる。
本当は、
もう動くものを見た方が早いのに。
② 先延ばしのツケ
→ 要件定義の会議が終わらない
「まず要件を固めましょう」
この言葉で、
何回会議をしたでしょうか。
でも実際は、
決めたことが、すぐ変わる
変わるから、また会議
まだ始まらない
決めるために、時間を使いすぎている。
それでも変わってしまう。
③ 取り返せない差
→ 作るのが早い人は、もう先に行ってる
今は、
口で説明する
少し待つ
動くものが出てくる
という世界にいる人たちがいます。
一方で、
書く
伝わらない
書き直す
をやっている間に、
差はどんどん広がる。
④ 小さな違和感
→ 本当に伝えたいことは、文章にできない
伝えたいのは、
こういう感じ
ここ、ちょっと変
なんか違う
でも仕様書に書くと、
固い
長い
本質が消える
言いたいことと、書けることは違う。
次々浮かぶ！
さらに他のツールを触っているので
手が慣れていて、
違和感もすぐわかる！
⑤ 無意識の習慣
→「まず仕様書」というクセ
なぜ、仕様書を書くのか。
理由はだいたいこれです。
そうしてきたから
その方が安心だから
でもそれ、
考えなくていい型でもあります。
⑥ 判断コスト
→ どう頼めばいいか、わからない
「これを作ってほしい」
と言いたいだけなのに、
どう書けばいい？
どこまで決める？
間違えたら怖い
結果、止まる。
頭が悪いからじゃない。
仕組みが難しすぎる。
⑦ 最悪の回避
→ 作業だけで一日が終わる
気づいたら、
修正
確認
また修正
で一日が終わる。
本当は、
「次、何やる？」
を考えたかったのに。
形になっていくのを見たかった。
⑧ 自尊心
→ 考える側でいたかった
作るのが嫌なわけじゃない。
でも本当は、
方向を考える
仕組みを考える
未来を考える
そっちをやりたかった。
時間を大切に使いたい。
⑨ 周りの目
→「これ、自動化できない？」って言いたい
本当は思ってる。
「これ、人がやらなくてよくない？」
でも、
作るのが大変そう
頼むのが難しそう
だから言えない。
⑩ 希望の具体像
→ 課題を言うだけで、形になる
AGI駆動開発は、こうです。
困っていることを言う
すぐ動くものが出てくる
見て、直す
文章より、体験が先。
AGI駆動開発って、すごい技術なの？
いいえ。
すごいのは、ここです。
考える人が、
ちゃんと考える時間を持てること。
おわりに
今まで奪われていたのは、
時間
余裕
考える力
AGI駆動開発は、
「頭がいい人のためのもの」じゃありません。
考えたい人が、考えられるようになるための仕組みです。
