Intellectual Property of Computational Architect
コンピューテーショナル・アーキテクトの知財について考える
＠AIS2024, Tokyo University, Japan 

0. Overview

The profession of 'Computational Architect' is practised, but its achievements and responsibilities need to be better recognised because what it does is a profession that did not exist in society. If we were to interact through individual contracts, we would be gripped by the logic of economic strength and weakness. There are new ways of being in copyright, such as the Creative Commons. Shouldn't we be discussing this at conferences and other forums, including improving the status of the profession?

0.概要

「コンピューテーショナル・アーキテクト」という職業を行っているが、やっていることが社会の中で存在していなかった職業なので、その実績と責任がうまく認知されていない。個別の契約でやり取りするなら、経済の強弱の論理で握りつぶされていしまう。クリエイティブコモンズなどの著作権のあたらしい在り方が、存在している。学会などの場で職業の地位向上なども含めて議論していくべきではないか？

1. Occurrence

I want to slap the title on them in a cowboy way and say, "I don't care about titles" However, as long as I do business things among people, I am sometimes asked what I usually do. So I started calling myself a 'Computational Architect', which is the name of the job I am currently doing. The word 'architect' is not limited to those who create buildings but also means a person who makes a system in the broadest sense of the word. I realised that if I gave my title a name that is not accepted in the world, it would not function as a title, which is a strange dilemma.

By the way, when I have had the opportunity to practice with clients from various industries, I have come to understand the somewhat different circumstances in different sectors regarding IP, such as copyright and technology. Professionals are responsible for what they submit. For example, a baker makes good bread and does not cause food poisoning, an academic creates an extraordinary theory and does not lie in his/her thesis, and a carmaker creates a dream mobile vehicle and does not cause any defects. As long as one is involved with the public, achievements and responsibilities are inseparable from back-to-back stories.

So, what are our achievements and responsibilities as a company with the above titles? In broad terms, achievements are what we have achieved and what we have worked with, and our responsibilities are to ensure that the system is flawless and that we follow up on any flaws to the best of our ability, even if they are limited.

By the way, as mentioned above, each industry has its way of doing things for better or for worse. Those educated in engineering are pulled towards that way of thinking, and those educated in informatics are pulled towards that way of thinking. My values are based on architectural design studies, but I was also educated in science. Nowadays, I make something with my hands and computer, sometimes I am the designer, depending on the object. Sometimes, I am classified as a researcher or a consultant, depending on the laws and licences in the respective countries. The discrepancies between these two categories need to be clarified.

１. 起

カーボーイ的に「肩書なんぞどうでもいい」とたたきつけたいところもあるが、人の間でビジネス的なことをするかぎりふだん何をしているのか聞かれることもある。そこで素直に現状やっている仕事をそのままに、「コンピューテーショナル・アーキテクト」となのりはじめた。アーキテクトということばは、建物を作る人に限らず、広義の仕組みを作る人という意味である。やってみて気づいたのは、肩書に世の中に通用しない名前を付けると、肩書として機能しないという変なジレンマもあるのだが。

ところで、色々な業界のクライアントと実務をさせてもらうと、著作や技術などのIPの考え方に関して、業界ごとにやや違う事情が分かってきた。プロというのは、提出するものには責任が伴う。例えば、パン屋ならうまいパンを作る＋食中毒をおこさない、学者はとんでもない理論を生み出す＋論文にうそがない、クルマ屋なら夢のある移動手段を＋不具合がないように、世間とかかわっている以上、実績と責任は切っても切れない背中合わせの話になる。

それでは、上記のような肩書を掲げる我々の実績と、責任は何なのだろうか考えるようになってきた。広い言い方をするならば、実績はできたモノ、ともに働いた内容、責任は瑕疵のないシステム、瑕疵があっても限度を持つが、できる限りフォローすることという感じになる。

ところで上述のとおり、よかれあしかれ各々の業界にはそれぞれのやり方がある。工学の教育を受けてそちらに引っ張られている人は、そちらの考え方に引っ張られているし、情報学の教育を受けた人はまたちがう。私は価値観は建築設計学をベースにしているが、理学の教育も受けた。いまは、手とコンピュータで何かを作っている、モノによっては実際に設計者であるときもある。また時には、それぞれの国の法律や免許などの関係で扱いとしては、研究者とかコンサルとかに分類されることもある。この辺りの食い違いについても、少し深めていかなければならない。

2) Develop topics in other industries, too

Although a bit old, a 2013 Nikkei report also said identifying product defects is now more challenging than a decade ago. The focus is on the increasing complexity of products and the increasing use of electronic and embedded software. If we broaden the scope of artefacts, they may include everything that looks like human-made objects, from ancient sundials to recent aeroplanes. As I wrote in another paper, there is still time to say that recent objects and computational artefacts are inseparable. It can be described as software and hardware in less precise but more straightforward terms. There is no shortage of examples of systems that have failed to function due to faults in the software and other system components.

A few matters have come to mind in the news in recent years due to problems with things and systems, but several hellish issues have taken years to resolve, even with a bunch of grown-ups involved.

An example is the systemic problems at Bank M in Japan. In particular, several glitches have occurred since 2021; E-Bank's erroneous transfers, inconsistent balances, and ATM failures are still fresh in the memory. Banking is, by nature, a numbers profession, and it may be more of a failure of computer algorithms.

The other impressive hell was the recall of the F(English model name is J) car, the backbone of the H company, which began around 2013. Among them were engine and transmission control programme failures, a combination of mechanical and electronic control issues, which are not mentioned here. The DCT area, which I know is very troublesome to open, as transmissions of this era are a mixture of hydraulic and electronic circuits, which means that a local car shop can only sometimes fix them.

(*There are examples where the problem appears to be a problem but is simply a hardware failure or a failure of the computer mechanism.)

Some say hell is hell, but it depends on how one perceives it. Take, for example, the Google Pixel smartphone, which I also own. As is typical of IT companies these days, the product is still ongoing when it is launched. They put it on the market with defects and gradually remove them with firmware and software updates. In the meantime, hardware has progressively decreased in number due to age and obsolescence.

There should have been product liability laws and so on, but... Is it good that what IT companies do is less lethal, or is it because the industrial structure and rules have been established around concepts for a long time and have yet to catch up?

２）承、他の業界でも結構問題になってるよ

少し古いが2013年の日経の報道でも、製品の不具合の特定が一昔前に比べて難しくなったという。ここで着目しているのは製品の複雑化や、電子化、組込みソフトウェアの増大のあたりの話にも関連する。アーティファクトの範囲を広げれば、太古の日時計などから、近年の飛行機まで人間のつくったモノらしきものすべてがそれにあたるかもしれない。別の論文でも書いたように、いまさらでもなく近年のモノとコンピューテーショナル・アーティファクトは不可分である。厳密さに欠けるが簡単な言葉で換言するとソフトとハードでもいい。ソフトなどで構成されるシステム側の不具合で、全体が機能しなくなったなどという例は枚挙にいとまがない。

近年のニュースなどでモノやシステムの不具合でいくつか頭に浮かぶ事柄はあるが、とにかく大の大人が束になっても、解決に何年もかかっている地獄のような件がいくつもある。

例えば、日本のM銀行のシステム問題である。とくに2021年から何回にもわたっての不具合；Eバンクの誤送金、残高不整合、ATMの故障など、記憶に新しい。銀行はもともと数字に関する職業であり、どちらかというとコンピュータアルゴリズムそのものの故障であるかもしれない。

他の印象的な地獄は、2013年ごろにはじまった、H社の屋台骨であったFというクルマのリコールである。そのうちでも、エンジンおよびトランスミッションの制御プログラムの不具合というものが、機械と電子制御の兼ね合いの問題で、ここで挙げているはなしとなる。わたしにでも多少内容のわかる、DCT周りについては開けてみると、とても困る、この時代のトランスミッションは、油圧回路と電子回路が混じっている、つまり町の車屋さんで治せないことが多い。

（※一見、この問題に見えて、実は単にハードウェアの故障、あるいはコンピュータ機構の故障という例もある。）

地獄は地獄でも、捉え方次第という話もある。例えば、私も持っているグーグルのピクセルというスマホである。最近のIT企業らしく、発売されたときに製品は完成していない。不具合を抱えたまま市場に出して、徐々にファームウェアやソフトウェアの更新で不具合を取り除いていく。そうしているうちにハードは経年劣化と時代遅れによって徐々に数を減らしていく。

製造物責任法とかはあったはずなのに、、、ＩＴ企業のやることは致死になることが少ないからいいのだろうか、産業構造や法律などが、一昔前の概念中心で確立されてきたこともあり、追いついていないのではないだろうか？

4）結

では、なぜ著作権やそれに準ずる権利はついてこないのか、その職業が、世の中にないからなのか？（５０％YES）問題がなければ、認識もないのか（50%YES）先日も何か漫画家先生とアニメ化の問題ののちに、事件があった。

契約で著作人格権を行使しないと書いてるから、行使しないのか、著作人格権が生まれた理由を上から押さえつけるのが、まともな企業のやることか？

ーもっとも、「まともな企業」というものは存在しえない。まともの定義がなされていないことと、企業というのが抽象的なアーティファクトであるからである。