ものづくりの時間が変わった――「文明の夜明け」を感じた
――SharePoint版への第２章、そのとっかかりで「文明の夜明け」を感じた
この記事の要点
私はいま、Digital Supporters Clubという会員制クラブサイトをつくっています。
前回は、Microsoft Power Pagesを使った会員サイトの設計に挑戦し、 AIとの対話を繰り返した結果、 要件定義書から１２３件のテストケースを持つテスト仕様書までつくりました。
そして次は、SharePointを中心に、 もっと小さく実際に動くものをつくってみよう、と方向を変えました。
今回の出来事は、その第２章へ踏み出した、とっかかりでの体験です。
SharePoint版の運営を少し楽にするために、 会員ごとのフォルダ作成や権限設定を支援する 「DSC Builder」という小さな管理ツールを、 AIと一緒につくることにしました。
そこで私は初めて、 AIに実際に動くコードを全面的に書いてもらいました。
驚いたのは、それだけではありません。
AIは、そのコードを確かめるためのユニットテストまで用意し、 実際にそのユニットテストまで実行したのです。
さらに、テスト用の模擬SharePointまでPythonコードとしてつくっていました。
コードを書く。
テストを書く。
テストする。
問題があれば直す。
またテストする。
そのサイクルが、 私が現役のころに接してきたシステム開発とは、 まるで違う速度で回っていきました。
私はその様子を見ながら、
「自分はいま、文明の夜明けに立ち会っているのではないか」
と本気で感じました。
ところが、ユニットテストが通ったコードを 本物の日本語版SharePointで動かすと、 それでも問題が見つかりました。
そこで見えてきたのは、
AIがつくり、人間が現実に当て、その結果をまたAIへ返す
という、新しいものづくりの姿でした。
- AIはコードを書くだけでなく、ユニットテストをつくり、実行するところまで進んでいる
- AIによって「設計 → 実装 → テスト → 修正」の速度が大きく変わった
- ユニットテストが通っても、本物の環境でなければ分からないことがある
- AI時代の開発では、人間は「現実との接点」という重要な役割を持つ
今回の経験で強く感じたのは、 AIが単にコードを書くようになったのではなく、 ものをつくり、試し、直し、もう一度つくる時間の流れそのものが変わり始めている ということです。
１．第２章へ踏み出したところで、驚いた
前回の記事では、 Digital Supporters Clubの会員サイトをPower Pagesでつくろうとして、 AIと一緒に要求仕様や設計を考えていったことを書きました。
最初は、もっと簡単につくれると思っていました。
ところがAIと対話を続けるうちに、
「この場合はどうしますか」
「途中で失敗したらどうしますか」
「他の会員から本当に見えませんか」
と、一つ決めるたびに次の問いが出てきました。
その結果、要件定義からデータ設計、画面、権限、運用、 そして１２３件のテストケースまでつながっていきました。
そして最後に、
Power Pagesへの挑戦が第１章。
次はSharePointを中心に、まずはもっと小さく動くものをつくる。
そう書きました。
今回の出来事は、 その第２章へ踏み出した、とっかかりでの体験です。
SharePoint版をつくり始め、 その運営を少しでも楽にするための小さなツールを AIと一緒につくろうとしました。
その過程で、私は初めて、
しかも、それだけではありませんでした。
AIはユニットテストまでつくり、 実際にそのテストまで実行したのです。
これには、本当に驚きました。
２．残っていた、地味だけれど気の抜けない作業
SharePointとTeamsを使った小さな会員サイトをつくり始めると、 サイトの骨組みは少しずつ形になっていきました。
自分だけが見られる原稿の場所。
クラブの仲間に公開する作品の場所。
作品について感想を届ける場所。
Power Pages版で考えた、
「保存することと、公開することは違う」
「本人の非公開原稿は、他の会員から見えてはいけない」
という考え方も、そのまま引き継ぎました。
ところが実際に運営することを考えると、 一つ地味な作業が残りました。
↓
会員専用のフォルダをつくる
↓
原稿を書く場所をつくる
↓
届いた感想を保存する場所をつくる
↓
公開作品のフォルダをつくる
↓
それぞれに正しいアクセス権を設定する
作業そのものは、それほど複雑ではありません。
でも、間違えてはいけません。
本人だけが読めるはずの原稿が、 別の会員から見えてしまったら大きな問題です。
公開作品についても、 他の会員は読むことはできても、 編集できてはいけません。
会員が増えるたびに、同じ設定を行い、 最後に間違いがないか確認する。
地味ですが、かなり神経を使います。
そこで、この作業を支援する小さな管理ツールをつくることにしました。
名前は、
です。
たとえば、
とGPTに伝える。
すると、
↓
権限を設定する
↓
本当にその通りになったか確認する
ところまで支援する。
そんな道具を目指しました。
３．最初は、大きくつくりすぎた
ところが、最初に考えたDSC Builderは、 かなり大きなものでした。
新規会員の準備だけではありません。
- 長期間利用していない会員を見つける
- 利用継続を確認する
- 退会時にはアクセスを停止する
- 一定期間データを保持する
- 最後にはデータを削除する
入会から退会まで、 かなり広い範囲を自動化しようとしていました。
設計をレビューしていく中で、
「今の段階で、そこまでつくる必要があるだろうか」
という問いが出てきました。
以前、Power Platformのライセンス費用で立ち止まったときと、 よく似ています。
技術的につくれるか。
それだけではありません。
そこで範囲を大きく縮めました。
まず試すのは、 新しい会員１人を迎えるときのSharePoint設定だけ。
休眠管理も、退会処理も、削除の自動化も、 いったん将来へ送る。
そして設計に、
「効果が確認できた部分だけ次へ進める」
という考え方を入れました。
実際に試す。
本当に楽になるなら続ける。
効果が小さければ、そこで止める。
前回は、仕様書をつくることで、
「このシステムを本当につくるべきか」
を考えることができました。
今回は、AI自身を使った開発にも、 同じ考え方を適用することになりました。
４．本当にコードができた
設計を何度も見直したあと、 AIに実際のコードを書いてもらいました。
ここは、はっきり書いておきたいと思います。
私はプログラムを一行も書いていません。
私が行ったのは、
- 何をつくりたいのか
- どこまでつくるのか
- どんな場合には処理を止めるのか
- どんな結果なら成功なのか
そうしたことをAIとの対話で考えることでした。
設計が決まると、AIがコードを書きました。
それまでも、
「AIはコードを書ける」
という話は知っていました。
だから、ここまではある程度想像できました。
でも、本当に驚いたのは、その先でした。
５．AIが、ユニットテストまで実行した
AIは、コードを書いて終わりではありませんでした。
そのコードが正しく動くかを確かめるための ユニットテストも用意しました。
そして、
↓
ユニットテストを書く
↓
ユニットテストを実行する
↓
結果を確認する
↓
問題があればコードを直す
↓
またテストする
そこまでが、 ひと続きの開発作業として進んでいったのです。
私は、その様子を見ながら本当に驚きました。
自分がAIと話し合って決めた設計がコードになる。
そのコードを確かめるテストコードもできる。
そして、実際にテストが走る。
「AIはプログラムを書けるらしい」
と外から眺めていたときとは、 まったく違いました。
そのコードに対するユニットテストまで実行されていく。
その体験の重さは、 想像していたものとは違いました。
６．ものを作る時間の流れが変わった
そして、私が一番強く感じたのは、その速さでした。
↓
設計する
↓
コードを書く
↓
テストコードを書く
↓
テストする
↓
問題を調べる
↓
コードを直す
↓
またテストする
それぞれの工程に、人の作業時間が必要でした。
もちろん、AIを使っても、 こうした工程そのものが全部なくなるわけではありません。
違ったのは、
私が、
「この場合はどうなる？」
と問いかける。
AIが設計を確認する。
コードを書く。
テストを書く。
テストを実行する。
必要なら修正する。
そして、また次へ進む。
これまで別々の工程だったものが、 対話の中で次々につながっていきました。
私が現役のころに接してきたシステム開発の時間感覚とは、 明らかに違いました。
私は、
「便利になった」
とか、
「少し速くなった」
という感覚では受け止められませんでした。
そう感じました。
７．AIは、模擬SharePointまでPythonでつくった
さらに驚いたことがありました。
ユニットテストをするとき、 毎回本物のSharePointへ接続していたわけではありません。
たとえば、
- このフォルダは存在するか
- フォルダをつくったらどうなるか
- どんな権限が設定されているか
といったSharePointの振る舞いを、 テスト用のPythonコードの中で再現します。
そして、その模擬SharePointを相手に ユニットテストを実行する。
いわば、小さな「模型のSharePoint」です。
つまりAIは、
↓
そのコードを試すための模擬SharePointをPythonでつくる
↓
ユニットテストを書く
↓
ユニットテストを実行する
ところまでやっていたのです。
私はここでも、
と感じました。
コードをつくる。
そのコードを試すための世界までつくる。
そしてテストする。
だからこそ、
↓
試す
↓
直す
↓
また試す
というサイクルを、 ものすごい速度で回すことができるのだと思いました。
８．ところが、本物のSharePointでは違った
ところが、これだけテストしていても、 本物のAzureとSharePointで動かすと問題が見つかりました。
その一つが、SharePointの権限でした。
最初のコードでは、
「Full Control」
「Edit」
「Read」
という英語の名前を使って、 SharePointの権限レベルを設定しようとしていました。
ところが、私が実際に使っているのは 日本語版のSharePointです。
本物のSharePointから返ってくる表示名は、 日本語でした。
では、なぜユニットテストでは、 この問題を見つけられなかったのでしょう。
９．テストも、同じ前提でつくられていた
理由は単純でした。
「権限の名前は英語で返ってくる」という同じ前提でつくられていたからです。
プログラムは、
「Full Control」
を使おうとする。
模擬SharePointも、
「Full Control」
を返す。
だから、ユニットテストはPASSします。
テストの中だけを見れば、何も間違っていません。
ところが、本物の日本語版SharePointでは、 権限の表示名が日本語で返ってきました。
そこで初めて、
現実とは違っていた
ことが分かりました。
これは、 ユニットテストが役に立たなかったという話ではありません。
ユニットテストは、
「こちらが想定した条件の中で、コードが正しく動くか」
を確かめることには、とても役立ちます。
ただし、
本物の環境で動かしてみなければ気づけないことがある。
今回、私はそれを実際に体験しました。
そこでAIは、 英語や日本語といった表示名に頼るのではなく、 言語に左右されない方法で権限を判定するよう コードを修正しました。
さらに、日本語環境でも正しく判定できることを確認する ユニットテストも追加しました。
↓
本物で動かす
↓
現実との違いが見つかる
↓
結果をAIへ返す
↓
AIがコードを直す
↓
テストも直す
↓
また試す
最初のテストで見えていなかった現実が、 本物のSharePointで見つかる。
その現実を、今度はテストの中にも取り込む。
こうしてテストも、 少しずつ現実に近づいていきました。
１０．「やり直す」ことにも問題があった
もう一つ、 途中で処理に失敗した場合にも問題が見つかりました。
途中までフォルダができる。
その後で処理が止まる。
初めのコードでは、 その処理を同じ番号でもう一度実行しても、 失敗した結果を返すだけで、 その先へ進めない場合がありました。
そこで、
↓
安全に再開できる状態か判断する
↓
再開できる場合は、その続きから進める
という形へコードを修正していきました。
この修正コードもAIが書きました。
実際のAzureやSharePointで動かすための コードやコマンドもAIが用意しました。
私は、それを実行します。
返ってきた結果やエラーをAIへ伝えます。
AIが原因を調べます。
コードを直します。
私はまた実行します。
ここでも同じ往復が続きました。
１１．AIがつくり、人間が現実に当てる
今回の開発を振り返ると、 人間とAIの役割について、 前回とは少し違うものが見えてきました。
前回は、
↓
AIが設計案を出す
↓
AIがレビューする
↓
人間が判断する
↓
設計を直す
という関係でした。
今回は、その先へ進みました。
↓
AIと設計する
↓
AIがコードを書く
↓
AIが模擬SharePointをPythonでつくる
↓
AIがユニットテストを書く
↓
AIがユニットテストを実行する
↓
人間が本物の環境で動かす
↓
現実との違いを見つける
↓
結果をAIへ返す
↓
AIがコードとテストを直す
↓
もう一度、本物で試す
コードを書いたのは、AIです。
でも、完成品をAIから受け取って終わりではありませんでした。
そんな共同作業になりました。
１２．「もう一度、つくり直そう」のコストが下がった
前回の記事で、私は、
AIが変えたのは「考え直すコスト」だった
と書きました。
人間のチームで、
「要件まで戻りましょう」
「設計をやり直しましょう」
と言うのは簡単ではありません。
でもAIとの対話なら、
「待って。この場合はどうなる？」
と思ったところから、 すぐ前へ戻れます。
今回、その先を体験しました。
コードを書いたあとでも、
「この場合は？」
と聞く。
AIが直す。
テストする。
もう一度直す。
つまりAIは、
と言えるコストまで、 大きく下げ始めていました。
↓
試す
↓
失敗する
↓
直す
↓
もう一度試す
この循環そのものが、とても軽くなった。
私はそこに、 前回とはまた違う大きな変化を感じました。
１３．文明の夜明けに立ち会っている
今回の経験を、私は単に、
「初めてAIにコードを書いてもらった」
という出来事としては受け止めていません。
コードを全面的にAIが書いた。
テスト用の模擬SharePointまでPythonでつくった。
ユニットテストを書いた。
そのユニットテストまで実行した。
問題があれば、コードやテストを直した。
その一連のサイクルが、 驚くほどの速度で回っていった。
私はそれを、 ニュースでも、誰かのデモでもなく、 自分が本当につくろうとしている Digital Supporters Clubの開発で経験しました。
そして、その速度を目の前で見たとき、 私が現役のころに接してきたシステム開発との違いを、 頭ではなく実感として感じました。
だから私は、本気で、
そんな実感を持ちました。
AIによって、 単にプログラミングが便利になったのではない。
私はそう感じました。
私はプログラマーではありません。
プログラムも一行も書いていません。
それでも、
↓
AIと設計する
↓
AIがコードを書く
↓
AIがテストする
↓
自分が本物の環境で動かす
↓
違いを見つける
↓
AIへ返す
↓
また直す
その「ものをつくる世界」の中に、 自分も入ることができました。
もちろん、AIが常に正しいわけではありません。
今回も、本物のSharePointへ当てたからこそ 分かったことがありました。
だから、人間の役割がなくなったとは感じません。
むしろ、
現実に当て、違いを見つける人間の役割が、よりはっきり見えてきた。
そう感じています。
Digital Supporters Clubのクラブサイトは、 まだ完成していません。
今回の出来事は、 第２章の本当にとっかかりです。
でも、そのとっかかりだけで、 私はこれまでとはまったく違う ものづくりの速度を経験しました。
↓
使う
↓
気づく
↓
改善する
前回、これからやろうとして書いたこの循環が、 もう実際に動き始めています。
AIと一緒につくる。
現実に当てる。
違っていたら、またAIへ返す。
そして、もう一度つくる。