AI利用によって上がった作業効率の使い道

弊社でもコーディングにAIを活用するようになりました。

まだ完全自動コーディングは「おもちゃ」の域を出てないと言うか、それ以上の使い方をするにはコストがかかり過ぎるという感じがあるので、あくまでも「補助」としてしか活用していません。まぁ、たまにホームラン級の効率を叩き出してくれることがあるので、ある種の期待がありますし、使ってみたりしてますけどね。でも、主には「補助」です。

あくまで「補助」として使っていても、以前と比較すれば効率は爆上がりです。そうなると… さてどうしましょうかというのが、このエントリの主題です。

背景

ここ最近、ChatGPTを作業のアシスタントとして使うことが増えました。

「コーディング」ではなくて「作業」と書いたのは、それだけ色々な「作業」に使っているからです。また、それに味をしめて「汎用AIアシスタント構築フレームワーク」を作り始めました。これについては、いずれまた書きたいと思います。まぁとにかく、LLMを様々な使い方をすることにより、作業効率は非常に上がるようになりました。

たとえば、社長(mayumi)がCasaOSをforkして新しいOSを作っています。もちろんこの作業はChatGPTと協同作業になっています。

いずれまた詳しく書きますが、これは結構難物でもあるので、私は「いっそ書き直そう」と思ったりもしています。ふとそこでChatGPTに聞いてみたら、「そんなのわけない。モジュール(CasaOSは複数のモジュールで構成されています)単位で2人1週間程度あればできるさ」とか言い出しました。そこでまたふと、「Gemini-cliで雑に作業させたらどうなるだろう」と思って、現状の

API仕様書(backendのモジュールなので)
動作の仕様書
テスト仕様書
移植の手順(GolangからNode.jsへの書き直しなので)

等を作らせて、「じゃあこれを元にあらためてコード書いて。その途中で作った仕様書に不足があれば追加して」という指示を出しました。

そうしたら、晩飯の準備をしている合間に「じゃあやって」を時々入れるだけで、何となくそれっぽいものを作ってくれました。まぁ、できたとは言え最後のテストで苦労してる感じでしたが、こちらとしては「足場にできるとりあえず動かせそうなコード」が出ただけで十分ですから、結構結果に満足しています。

これは極端な例ですが、プログラミング作業の自動化や補助が急速に進んでいます。元の社長の作業のしかたでも、「かつて」のことを思えば恐しいくらいの速度で作業できています。このプロジェクトで私は何度も「え？もうそこまで？？」と言ったか知れません。そもそも彼女、このプロジェクト始めた頃はGoなんて知らなかったですし。

弊害

このように、作業時間はおそろしく短縮されるようになりました。お陰でどんどん作業が進みます。現状弊社は2人だけですが、多分以前であれば5〜10人くらい必要だった規模の作業が片付けられるようになっていると思います。開発に関してだけ言えば、「しばらく人増やさんでもいいね」と会話しています。

それはいいのですが、恐しく疲れます。「恐しく」は言い過ぎかも知れませんが、以前と比べると確実に疲労が増えていることがわかります。この疲労、肉体的にどうこうではなくて、脳のオーバーヒート的なものです。定時(弊社には厳格に定時が存在します)になったらヘロヘロ… どころか、15時くらいには「お昼寝」が必要になります。そうしないと、脳内で何かが飽和してしまって思考ができなくなってしまいます。

ついでに言えば、精神的にも結構厳しい感じになっています。

何しろ「思いつきレベルの改善」をChatGPTと議論すれば、「いけるいける。いつでも実装するぜ」みたいなことを言って来ます。そして、それを反映させると(方向性はどうあれ)確実に「結果」が出ます。要するに恐しい速度でPDCAが回ります。

それはいいことなんですが、そうすると「一瞬たりとも作業から離れられない」状態になってしまいます。自分の脳内が作業のことで一杯になってしまいます。これは精神的な健康には非常に有害です。実際、二人共ちょっと厳しい感じの精神状態になりました。

結局これは「作業密度」が上がってしまって、脳内が仕事のことだけで一杯になってしまったせいだろうと思います。元々我々は自分の手掛けている仕事が大好きですから、ついつい脳内をそれで一杯にしてしまいがちです。そうすると、いつも仕事が脳内から消えません。

何しろAIはすぐ「結果」なり「ヒント」なりを出してくれます。そうなると、すぐそれを反映させたくなります。その結果が出ると嬉しいです。

でも、その 「結果」を評価して、次に何をするか考えるは人間です。

自明なことについてはAIがやってくれますし、仮にそれが下手くそであっても時間が解決してくれるでしょう。「結果」についても「テストもやっておいて」と言えば、「テスト」はできます。

しかし、自明でない「私の方針」に類するものは、結局人間がやらなければなりません。そして、AIはその前段階についてはどんどん片付けてくれてますから、「思考が追い立てられる感覚」や、「ついていかねばという焦燥感」を感じてしまいますし、仮にそれを感じなくても「どんどん処理をする必要がある」ことは同じです。

これは「優秀過ぎる部下や外注」がいる時に同じようなことを感じた人もいるのではないでしょうか？まぁ、幸いにして「優秀過ぎる部下や外注」はなかなかいないので、「別の苦しみ」を経験した人の方が多いとは思いますけど。

作業に必要な「時間」

実は開発系の仕事を長くやっていて気がついたことがあります。それは

「プロジェクトに必要な時間」はいくら作業効率を上げても作業者を増やしても、ある時間以下にはできない

ということです。

しばしば「人月」の馬鹿らしさを説明する時に、「妊婦が10人いれば1ヶ月で赤ちゃんが生まれるか？」という話があります。これは「人月」という単位が「作業者と作業時間の積でしかない」というナンセンスさを語る材料ですが、これをもうちょっと考えれみれば、「妊娠して赤ちゃんが生まれるまでは、何をどうしようと10ヶ月かかる」ということを前提としているとも言えます。

つまり、「プロジェクトに必要な時間」は、どれだけ工夫しても「本質的に必要な時間(期間)」よりも短くはできないということです。

他方、並列処理のアムダールの法則というものがあります。これは、ある計算機システムとその対象とする計算についてのモデルにおいて、その計算機の並列度を上げた場合に、並列化できない部分の存在、特にその割合が「ボトルネック」となることを示した法則— つまり、並列処理は結局ボトルネックの部分で律速されるという法則です。

ですから、いくら作業者を増やしても(つまり並列度を上げても)、どこかで時間がかかる要素が存在していれば、そこで律速されてしまうということですね。

これらのことは、チャートでも描けば自明とも言えますが、そこまでしなくても考えてみればわかることだと思います。

ところが、目の前でどんどんタスクが捌けて行くのを見てしまうと、ついうっかり「この速度で全体が進む」と誤解してしまうのも、「あるある」でしょう。

この問題、ミクロなプロジェクトでもそうですが、巨大プロジェクトでも同じです。と言うか、巨大プロジェクトとなれば一番の律速要素である「人々の納得」が絡みますから、一気呵成に物事を進めてしまえば(= 本質的に必要な時間(期間)よりも短い時間で進めてしまえば)、上手く行くものも上手く行きません。業界ネットワーク系プロジェクトが死屍累々になりがちなのは、こういったことも絡んでいると言えます。いや「ことも」ではなくて主因なのかも知れません。

結局のところ、AIがあろうが「優秀な部下や外注」があろうが、そして目先の作業がどんどん進んでいようが、「必要な時間は必要」であって、「余白(熟慮の時間)」や「ムダ(不要な時間)」を頑張って削ったところで、「完成」までにかかる時間はそう大差ないという話だろうと思います。

AI利用によって上がった効率はどう使うか

そういったことを踏まえて、効率が上がった分はどう使うか考えたいと思います。

今までの「時間＝労働の単位」という発想では、「余った分、さらに詰め込め」なってしまいますし、多くはそれを期待されていると思います。 AI使って作業効率が上がったのであれば、その分早く仕事が片付くから、「次の仕事」を入れてしまうと金になるよと。

比較的単純な、「AIを動かしてお任せで完成」が可能な仕事であれば、それでいいと思います。とは言え、そんなことは誰でも思いつく「簡単な答え」ですから、おそらく早晩そういった仕事は片付き尽されてしまうでしょう。

あるいは「お任せで完成させてしまうノーコードシステム」とかが出て来るかも知れません。そうなれば、そういったドメインの仕事は仕事として発生することすらなくなるかも知れません。今あるそういった謳い文句のものは「おもちゃ」の域を出てないように思いますが、実用的になるのは時間の問題でしょう。そうなると、結局「専門家」が片付けるべき問題は「AIを援用しつつ作業者が熟考する」という類の問題だけになって行くだろうと思います。

その時の最大の律速要素は「考えている時間」であり、それは「本質的に必要な時間(期間)」よりも短くすることはできないと考えるべきです。ほとんど作業が片付いてしまった時に「空いた時間」に見える時間は残りの作業をするための「ひらめきのための時間」です。つまり、いくら効率が上がったところで、ある程度以上の速度で作業をすることは

不可能

と思ってしまって良いと思います。

そうなると、そうやって出来てしまう時間のギャップ(実はひらめきのための時間)は、むしろ「ぼーっとしている時間」ということにしてしまうのが正しい使い方だと言えます。

「ぼーっとしている時間」だとイメージが微妙ですが、「間」と言っても良いかも知れません。お茶とか演芸、あるいは映画とかの「間」ですね。何もしてない瞬間であっても、重要な意味があるのが「間」です。

ですから、表面的にはその時間を“報酬”として受け取るという考え方をした方が、今の時代には合っていますし、もっと積極的浮いた時間を仮眠や散歩に使って

ぼーっとすることに使う

ようにした方が、疲労回復になるだけでなく、「ひらめき」を得るためにも有効だろうと思います。

もちろん、そうやって効率を上げたり、積極的にぼーっとしていたりすると、元々ムダでしかなかった時間も炙り出されます。そういった本当にムダだった時間はどんどん削ってしまって、「儲け」に足して行けば良いことです。

でも、「浮いた時間」に見えている部分の何割かは「熟慮」あるいは「熟慮のためにぼーっとする」ための時間であるということを意識して、表面的には「余暇」 ということにしてしまった方が、トータルの効率として良いと思います。

まとめ

そんなわけで、積極的にAIを使うようになった弊社は、定時を厳格化しました。 18時になれば、ぴったり作業を終わらせます。朝も11時くらいに来ますし、昼休みをがっつり取りますし、疲れたら「お昼寝」もします。

これは「時間 = 作業」という価値観の目で見ればダラダラしているように見えますが、今まで書いたように

仕事には「本質的に必要な時間(期間)」がある
「作業の完遂」が仕事なのであって、時間を費すこと自体には意味がない
そもそも作業はだいたいAIが片付けている

ということで問題はありません。

今かかっているタスク以外に面白そうなことを手掛けていれば、あるいはそれで「遊戯」をするかも知れませんが、原則的に「日常業務」はそこで終了です。今の季節ですと、18時はまだ明るいですし、当地は海も山もすぐそこですから、遊びに行くのも簡単ですからね。

↑徒歩で行ける近場の海(久手海岸)です。

そんなふうに、AIによって人の仕事が加速する今だからこそ、「その浮いた時間は、疲労回復や創造的活動のために使うべき」という新しい働き方が現実的になって来ました。かつては単なる夢想でしかなかった働き方が、やる気次第で可能な時代になりました。

そのパワーをただ作業を速く片付けるのではなくて、「速く終えたぶん早く帰る」「余った時間で深呼吸する」といった行動の変化こそが、AI時代の「正しい働き方」だろうと思います。そして、その方が現実に仕事の効率を上げてくれます。 AIの援用で作業効率を上げるということは、これもセットなのではないかとさえ思います。

もうちょっと大袈裟に言えば、「仕事をする」ということを再構築する時が来たのかも知れません。

前述のようにCasaOSのhackの効率が大いに上がったんで、今日はちょっと「レシピ本」の執筆でもしようかと思います(これは伏線です)。