生成AIがコードを書く今、改めて考えたい「ソフトウェアを作る」ということ

はじめに

名古屋からこんにちは。名古屋支社の北河です。

梅雨が明けてから異常に暑くなりましたね。名古屋は40℃近くの日もあります。昔はそんなに暑くなくて、ほんと最近からだなーと思います。

…最近といえば、生成AIが普通にコードを書いてくれるようになりました。魔法の一言で、画面を作って、データを保存して、それっぽいアプリまで作ってくれます。いやーすごい、すごいですよね。私自身も生成AIを使っていますし、無くては生きていけないジャブジャブな体になっています。

そんな中、「生成AIがあれば誰でもソフトウェアを作れる」「ソフトウェアエンジニアはいらなくなる」といった話もSNSとかブログで見かけるようになりました。

この手の話を見ると、なんか引っかかるんですよね。いやね、生成AIは素晴らしいと思っていますよ。私が引っかかっているのは、生成AIよりも「ソフトウェアを作れる」という言葉の方です。

これは生成AIが出てきてから感じ始めたことではなく、もっと前から「ソフトウェアを作れるって、どういうことなんだろうなー」と、モヤモヤはしていました。

ということで、今回はそのモヤモヤが増してきたので、ちょっと言葉にしてみます。

建築とソフトウェア、なんだか似ている関係

ソフトウェアのことを考えていたら、建築が頭に浮かんだんですよ

ソフトウェアを「作る」ってなんだろう、と考えていたら、なぜか建築が頭に浮かびました。

アプリと建物。ぜんぜん別ものですよね。でも、ちょっと抽象度を上げてみると、なんだか似ているところがあります。

建物には、住む、働く、お店を開くなどの目的があります。その目的に合わせて設計して、見積もって、施工して、検査して、利用する人へ引き渡して、使い始めてからも、点検や修繕や増改築があります。

ソフトウェアにも利用する人や業務があって、設計して、見積もって、実装して、テストして、リリースする。その後も運用しながら、機能を追加したり修正したりします。

この辺りを整理してみると、こんな感じでしょうか。

建築	ソフトウェア
建物を利用する人、用途	システムを利用する人、業務や目的
建築設計	要件整理、ソフトウェア設計
構造設計	アーキテクチャ設計
耐震・耐火・防水	可用性・性能・セキュリティ
施工	実装
建築確認・検査	設計レビュー・テスト・品質確認
点検・修繕・増改築	運用・保守・機能改修

建物の耐震性や耐火性は、ソフトウェアでいう可用性やセキュリティのような、いわゆる非機能要件に近いのかなーと思います。

もちろん、まったく同じではありません。片方は物理的な建物で、片方はソフトウェアですからね。ちょっと強引な比較だと理解しています。

それでも、目的に合わせて設計して、作って、検査して、長く使えるようにする。いや、こうして見ると、同じじゃない？と思えてくるわけです。

建築には、逃れられない制約がある

建築もソフトウェアってもしかして一緒じゃん？と思う一方で、建築は物理世界にあります。

どれだけ新しい工法や材料が生まれても、重力や材料の強度の呪縛から逃れることはできません。そこを無視すれば、そもそも建たないか、建って危険なものになっちゃいます。

しかも、こうした物理法則はそうそう変化は起きません。建築技術や法律は変わっても、重力まで数年ごとに別物になるわけではありません。だからこそ、長い時間をかけて知識を積み重ね、学問や設計基準、検査の仕組みにしやすかったのかなーと思います。

だからこそ、建築では制約が外から強制されます。でもソフトウェアは、自分たちで制約を置かない限り、そのまま先へ進めることが出来ちゃいます。

この違いが、「作れる」の境界を曖昧にしているのかも。

「作れる人」の扱いは、かなり違う

さらに、この違いは「作れる人」の扱いにもつながっていると思います。

建築では、建物の規模や用途に応じて、資格や法令、確認・検査の仕組みがあります。

たとえば、ホームセンターで木材を買って小屋を作った経験があったとしても、それだけで他人の家や大きな建物の設計を仕事としてできるわけではないですよね。まあ、当たり前ですが。

一方で、ソフトウェアは誰でも作り始められます。資格がなくてもコードを書けますし、アプリも公開できちゃいます。

これはソフトウェアの良いところですよね。特別な設備がなくても始められるし、自分が困っていることを、自分で作ったアプリで解決することもできます。入口が広かったからこそ生まれたサービスやアイデアも、たくさんあると思います。

ただ、その自由さを認めつつも、どこかしっくりこないこともありました。

チュートリアルを見ながら、初めてアプリを作った。自分や友人で使う便利ツールを作った。何百人、何千人が利用する業務システムを設計・開発して、何年も運用や改修してきた。

これ、どれも「ソフトウェアを作った」と表現できるんですよね。最後のはソフトウェアというよりシステムを作った、と言った方が正しいかもですが。

作られたものも同じで、動きを確認するためのデモ、止まると仕事に影響する業務システム、どちらも「ソフトウェアを作った」と言えてしまいます。

いや、未経験者がソフトウェアを作ることも、個人開発をしている人を否定したいわけでもないんです。

見ている領域も、求められる能力も、成果物の状態もかなり違う。それなのに、同じ「作れる」で会話出来てしまうことが、なんとなくモヤモヤしていたんだと思います。

「よっしゃ！できた！」が早すぎる

デモでは見えないもの

ソフトウェアって、画面が表示され操作できると、もう完成したように見えちゃいますよね。

ログインして、編集して、一覧に表示され、よっしゃ！できた！と。

思った通りに動いた瞬間はテンション上がります。たぶん私も「できた！」とテンションアゲアゲになると思います。でも、この時点では見えていないものが、かなりあるんです。

利用者が増えたときに遅くならないか。権限やセキュリティは大丈夫か。半年後に機能を追加できるか。

こういうことをあまり考えていなくても、ソフトウェアは動いちゃいます。 ところが、利用者が増えたら急に遅くなった。最初の機能追加で、なぜか関係ないところが壊れた。作った人がいなくなったら、誰も変更できなくなった。

だからソフトウェアの問題は、完成した瞬間より、その後でバレるんだと思います。

建物の耐震性も、外から見ただけでは分からないのかもしれません。でも建築には、作る人が「今回は考えなくてもいいや」と簡単には外せない基準や確認の仕組みがあります。

もちろんソフトウェアにも、案件ごとの非機能要件や開発標準、セキュリティ基準などはあります。ただ、何をどこまで確認して、どの状態を完成とするかは、発注する側や開発する側に任されている範囲が広いように感じます。

結果、見た目では同じように動いて見えるソフトウェアでも、中身や、その後の扱いやすさにはかなり差が出てくるんです。

誰でも作れる自由と、作りのばらつき

さきほども書きましたが、ソフトウェアは誰でも作り始められます。この自由さがあるから、新しいサービスが生まれたり、ちょっとした業務改善が進んだりします。もし資格や許可制だったら、生まれなかったものもたくさんあるはずです。

しかし、その自由さの横で、作れるものの幅もとんでもなく広くなっています。自分だけで使うツールも、会社全体の業務を支えるシステムも、同じアプリです。一回だけ動けば役割を終えるコードも、何年も変更しながら使うコードも、同じソフトウェアです。どこまで品質を求めるかも、案件や組織によって違います。

こう考えていくと、ソフトウェア業界ってかなり自由というか寛大というかザルだなーと思います。

じゃあ、建築と同じように資格を必須条件にして、検査を義務にすればいいのか…うーん、それも自由を知っている身からするとちょっと違うと感じます。

建築にも新しい工法や技術はありますが、物理法則が変わって重力が急になくなることはありませんし、材料の強度という物理的な制約もあります。

一方、ソフトウェアは、言語、フレームワーク、データベース、クラウド、アーキテクチャ、運用方法など、とにかく選択肢が多い。しかも、どんどん増えて変わっていきます。

対象も、個人用の小さなツールから、社会や企業活動を支えるシステムまでかなり広いです。これを全部、一つの資格や基準で扱うのは、たぶん無理があります。建築士にも一級、二級といった区分があるみたいですが、ソフトウェアだと細分化しても駄目な気がします。

ゆるくてザルに見える。でも、網を細かくすれば解決するとも思えない。この辺りが、ソフトウェアの難しいところなんだと思います。

もちろん、資格がないことだけが品質のばらつきの原因ではありません。予算や納期、契約、発注方法、チーム体制など、いろいろな事情があります。

一つの資格や基準で全部を扱うのは難しくても、案件やチームごとに「できた」の基準を決めることはできます。たとえば、プロジェクト計画書で進め方や品質の基準をそろえたり、スクラムでいう「完了の定義」で、何を満たしたら完了なのかをチームで共有したりします。

ただ、そうしたものの存在を知っているか、知っていても実際の判断基準として使えているかで、「できました」の基準は変わってきます。動いたら「できた」とする人もいれば、決めた基準を満たして初めて「できた」とする人もいます。

仕事として何を満たせば「ソフトウェアを作れた」と言えるのか。その境界が曖昧なだけでなく、境界を決める方法を知っているかどうかも、作りのばらつきが大きくなる理由の一つなんじゃないかなーと、私は感じています。

そして生成AIは「できた！」をもっと早くした

作れる・作れないの話がかみ合わない

ふう、やっとここで生成AIの話に戻ります。

生成AIは、ソフトウェアを作る工程の中でも、コードを書いて、動くものを形にするところを大きく変えました。

以前なら、プログラミング言語を学んで、開発環境を作って、ググりながらコードを書いて、エラーを一つずつ直して、やっと画面が表示される。それが今では、生成AIにお願いすると、その途中をかなり飛び越えられます。いやー、本当にすごい時代になったものです。

今までコードを書いたことがなかった人でも、生成AIと会話するだけで、動くアプリを作れる例も出てきています。

「未経験者のオレでもこんなすごいアプリを作れたぞ！」…こういったのはちょっと前によくSNSのタイムラインで流れてきましたね。

でも、「生成AIでソフトウェアが作れるようになった」という話を見ると、ここでいう「作れた」がどこまでを指しているのかが気になります。動くアプリが形になったところまでを指す場合もあれば、設計や非機能要件、テスト、運用、その後の改修まで含めている場合もあります。

どちらも同じ「作れた」という言葉で表せてしまいますが、見ている範囲はかなり違います。そりゃ、話がかみ合わないのも当たり前ですよね。

生成AIが、この曖昧さを生んだわけではなく、もともとソフトウェア業界にあった「作れる」という言葉の曖昧さが、生成AIによって、かなり目立つようになったと感じているわけです。

誰がやるかは変わっても、必要なことは消えない

さて、「コードは生成AIが書いて、人間は設計をする」と、きれいに分けてしまうのも少し違うと思っています。

今は人がやっている設計やテスト、運用も、これから生成AIができるようになると思います。それはそれでよいと思うし、誰がやるかは、どんどん変わっていくべきでしょう。

ただ、ソフトウェアとして何を満たす必要があるかまで、なくなるわけではないかなと思います。

性能が必要なシステムなら、性能を考える必要があります。止められないシステムなら、障害が起きたときのことを考える必要があります。長く使うシステムなら、あとから変更できる状態を保つ必要があります。

それを人がやるのか、生成AIがやるのか、人と生成AIで分けるのか。そこは、これから変わっていくと思います。

でも、「何をもって完成とするか」は、誰かがどこかで決めなければなりません。

組織で生成AIを使おうとすると、どのツールを使うのか、どの工程を自動化するのか、どれくらい開発を速くできるのか、といった話になりがちです。もちろん、その話もどこかで出てきます。

ただ、その前に、自分たちが「ソフトウェアを作る」ことについて考えを整理しておかないと、生成AIに任せる範囲もうまく決められないと思います。 設計やコードの生成を任せ、テストも作ってもらう。任せられるものは、これからもっと増えていくと思います。

その出力を見て「よっしゃ！できた！」とするのか、「いや、まだ足りない」と判断するのか。それは、自分たちがソフトウェアに何を求めているかで変わってくると思います。 動けば完成とするか、運用や変更まで含めて完成とするかでは、生成AIの使い方も、必要なチームも、かなり違うはずだと思っています。

おわりに

建築とソフトウェアは、まったく別のものですが、目的に合わせて設計して、作り、その後も手を入れながら長く使うというところは、なんだか似ています。でも、「作れた」と認める基準はかなり違います。

生成AIによって、コードを書き、動くものを形にするまでのハードルは、ものすごく下がりました。そのおかげで、ソフトウェアを作り始める入口も広がっています。これは、本当にステキなことだと思います。

ただ、コードが書けたことと、ソフトウェアが完成したことは、やっぱり同じではないんですよね。何をもって「できた」とするのかは、作るものや目的によって変わります。

これ、生成AIがこの曖昧さを生んだわけではないんですよね。昔からあった「作れた」の曖昧さが、生成AIによって、かなり目立つようになったんだと思います。

生成AIにできることが増えても、それだけで「作れた」の基準まで決まるわけではないんですよね。

うーん…アカンですね。。どうしても生成AIの話になると「何ができるようになったか」より、「何をもってできたとするのか」にビットが立っちゃうみたいです。
ということで今回は、そんな昔から抱えていたモヤモヤを、自分なりに整理してみました。
皆さんは、「ソフトウェアを作れた」と聞いたとき、どこまでを思い浮かべますか？

最後に宣伝です。私が所属するIIJ 名古屋支社のアプリケーションプラットフォーム課は、開発ベンダーでありながらアジャイルでお客様のビジネス拡大に貢献したい！と日々取り組んでいます。

アジャイルの実践やアジャイルに限らず開発現場のリアルな話をもっと聞いてみたい方は、個人やIIJのXでも大歓迎です。ぜひ気軽にご連絡ください！

---

執筆者X	@nk_tamago ※意見は個人のものです