職人の技をデータにしたら、伝統は継承されるのか
SI事業本部 部長
お疲れ様です！SI事業本部部長の島田です。
今回は私が購読している中島聡さんのメルマガを読んでいて感じたことを言葉にしてみます。お題は「伝統の継承」です。ソフトウェアの会社が何を言うとんねん、と思われるかもしれませんが、最後はちゃんと自分たちの開発に戻ってきますので、少しだけお付き合いください！
ロボットのために、作業を撮影する仕事
メルマガ内の一節で、こんな話が紹介されていました。
ロボットを動かす AI を育てるには、「人が作業する様子」のデータが大量に要ります。ところが、文章と違って、そんなデータはインターネット上にほとんどありません。そこで、人が頭や手首にカメラを付けて、ふだんの家事や工場の作業を本人の目線で撮影し、その映像を学習データとして売るビジネスが伸びているそうです（参考記事）。触った感じや力の入れ具合を記録する、センサー付きの手袋まで開発されているとのこと。
そして筆者の方は、こう書いていました。日本こそ、これを真剣に考えていい。職人の高齢化で技が消えていくなら、手の動きをデータで残しておけばいい。その技を引き継ぐ後継者は、人型ロボットになるのかもしれないけれど、と。
なるほど、と思いつつ、何か引っかかりました。
最初に浮かんだ直感
伝統というのは、人に依存していて、継承が難しかったからこそ、伝統たりえたんじゃないか。
苦労したことや、ハプニングがあったことほど、よく覚えているものですよね。記憶の「見出し」になるというか。だとしたら、職人の細かな感覚を全部データにして、苦労なく取り出せるようにすることは、保存としては素晴らしくても、継承の邪魔になるんじゃないか。
そんな直感でした。
冷静に見たら、半分外れていた
この直感を Claude に投げて、批判的に見てもらいました。結論から言うと、半分外れていました。
1つ目。難しさは、いま継承を「妨げている」側にいる。
苦労して覚えたことが身につくのは、入門した人の話です。いま職人の技が消えていく理由は、そもそも入門する人がいないことだぞと突っ込まれました。何年も修業が要る世界には、入ってくる人が限られる。難しさは伝統を守っているどころか、先細りの原因になっているとのこと。
2つ目。「難しかったから残った」は、残ったものだけを見ている。
難しすぎて消えた技は、数えられていません。逆に、祭りや年中行事のように、継承が「比較的」易しいのに立派に伝統として続いているものもあります。
ここは突っ込んでもらってありがたかった部分でしたね。データで残して、入口を広げる。それで入ってくる人が増えるなら、妨げどころか助けになりますし。
それでも残った引っかかり
ただ、私の直感の全部が外れたわけでもありませんでした。
Claudeと対話しているうちに、自分が引っかかっていたのは「データにすること」ではなかったと気づきました。引っかかっていたのは、そのデータの行き先です。
たとえば、ロボットが寸分違わぬ漆器を作れるようになったとします。私はそれを「継承された」とは感じません。物と技はつながっているけれど、人がつながっていないからです。
一方で、人からロボットへ、そのロボットからまた人へと技が渡るなら、それはうまく継承されたと感じます。
伊勢神宮などは、20年ごとに社殿を建て直してるらしいです。建物を保存するのではなく、建て直すことで、技を人から人へ渡し続けている。この例を教えてもらって、残すことと、できる人がいることは、別のことなんだなと気づきました。
もう1つ気づいたことがあります。これまでの記録、、、文字も、楽譜も、業務マニュアルも、人が読むために人が残してきました。漏れもあるし、言葉も揺れるし、非効率です。でも、読み手は人でした。今回のデータは、読み手が機械です。機械には分かるけれど、人には読めない。ここが、これまでの記録と違うところだと思います。
誤解のないように書いておくと、機械に預けること自体が悪いとは思っていません。私たちはすでに、いろんなものを機械に預けて暮らしています。ただ、どこを預けて、どこを人の側に残すのか。それを決めるのは人であってほしいな。 残った引っかかりは、そこでした。
自分の現場ではどうしているか
ここまで来て、これは自分たちの開発の話でもあるな、と思いました。
弊社内で内製した営業本部向け・管理本部向けのアプリは、ガッツリ生成AIを使って、爆速で作りました。コードはほとんどClaudeくんに書いてもらいました。職人の話でいえば、「手」は機械に預けた状態です。
その代わり、意識して残すようにしているものがあります。
- なぜその構成にしたか。 技術の選定やアーキテクチャの理由を、README などに残す
- どういう経緯で決めたか。 Claude と対話して判断した過程を、GitHub の Issue に残す
- どう運用するか。 運用の手順を、Slack のキャンバスに残す
AI との対話は、放っておくと自分のマシンの中にしか残りません。それでは、後から来た人が辿れない。なので、「どう書いたか」ではなく「なぜそう決めたか」を、人が読める場所に、人が読める言葉で置くようにしています。
書くのは預けた、認めるのは残した
正直に書くと、そのREADMEやIssueの文章も、書いているのはClaudeくんです（もはやいち社員のように接しています）。私はそれらの文章を読んで、「おっけ間違っていないな」「これならまぁ後から参画してくれたメンバーにも引き継げるかな」と判断して、コミットしています。
さっき「人が読むために人が残してきた」と書いたばかりですが、ここは手放した部分ですね。 書く作業は預けて、判断と承認を自分に残そうって決めました。時間的にやり切れないって制限ももちろんそうですけどね。
弱点もあります。読んで確かめられるのは、自分がすでに理解している範囲だけです。自分が分かっていないことは、間違っていても気づけません。なので、次の話が大事になってきます。
最初の1件は、自分の手で
この記録が本当に役に立つのかは、自分以外の人が使ってみるまで分かりません。
以前の記事で書いたとおり、内製アプリは社内研修の題材に活用しています。研修に携わるメンバーには、残しておいた文書をベースにシステムやインフラの構成を説明した上で、新たなIssueを起票し、機能の改修からリリースまでやってもらいました。
このとき、明確に指示したことがありました。最初の1件は、生成AIに頼らず、自分で書いてみて！ と。
電卓があっても、小学校ではまず筆算をやりますよね。答えを出すだけなら電卓でいい。それでも筆算をやるのは、機械の出した答えが変だったときに、変だと気づけるようにするためだと思っています。
コードも同じです。AI が書いたものを認めるには、自分の手で書いた経験が要る。なので最初は自分の手で。そのうえで、生成 AI を使う力も伸ばしてほしいので、その後は五分五分くらいに上げていってもらいました。
完全な引き継ぎまでは、まだできていません。ただ、AI と作ったシステムを、判断の理由ごと記録に残し、次の人が自分の手で改修するところまでは回りました。人から AI へ、AI からまた人へ。小さいですが、一周はしたかなと思っています。
職人の世界のことをベラベラ好き勝手に言うんじゃない
職人の世界について、私は買い手としてしか関わったことがありません。なので、こうすべきだと言える立場ではないので感想しか申し上げることはできない...！（インターネッツ上で大っぴらに書くこと自体が失礼な気が）
それに、ソフトウェアと体の技は違います。ソフトウェアは、理由が残っていれば AI が作り直せます。体の技は、理由が分かっても、手が動くようになるわけではないだろうなって思うんですよ。私もクックパッドを1回みたらあと完全にトレースできるわけじゃないですし、同じレシピ何回かみることもありますしね。
ああそういえば、旨くて飛ぶ豚汁レシピは数回作ったら覚えられました。やっぱり何回か作ることを繰り返して、ああここ変えたらこう変わるんだっていう、揺らぎの範囲なんかも身体と舌を使わないと体得できないです。少なくとも私は。
さて締めくくりに、問いとざっくり未来予想を。
職人の手の動きをデータにするとき、その行き先は、ロボットで終わるのか。それとも、もう一度、人に戻ってくるのか。カメラや手袋で集めたデータで、AI が弟子の手の動きを見て直してくれる。そんな使い方ができるなら、それは継承の助けになるんじゃないかなと思います。
今回のポイント
- 最初の直感は半分外れてました。 難しさは伝統を守っているのではなく、いまは継承を妨げている面もある
- 引っかかっていたのは、データの行き先だった。 ロボットで終わるのか、人に戻ってくるのか
- 預けること自体は悪くない。 どこを預けるかを、人が決めていることが大事
- 自分の現場では、手は AI に預けて、判断の理由を人が読める形で残している。 書くのは預けた、判断と承認は残した
- 認める力を保つために、最初の1件は自分の手で書いてもらった。 電卓があっても筆算をやるのと同じ
記録を残すとき、その読み手は人か、機械か。預けると決めたのは誰か。自分の仕事でも、ときどき立ち止まって見直したいと思います。
それでは、また現場に出てきます！
