コードと資本主義がつくる私たちの身体ーなぜエンジニアに批評と人文学が必要なのか

2025年1月6日 00:31

あなた：
Q. 批評の意味について解説してください

chatGPT 4o：「批評」という言葉は、主に以下のような意味で使われます：

上記の1.～3.を素直に読むと生活のあらゆる事物に対して本来批評は可能だと言えるはずなのに、哲学や芸術、映画、建築や文学を対象としてしか行われていないのはなぜなのだろう。

生権力、生政治とITの親和性

スマホアプリによる日々の経済活動、データでのヘルスケアに支えられている私たちの現代の生活において、とくにセキュアなITシステムをいかに安定的に実社会の活動で運用するか、ということを考えるとき、哲学者のミシェル・フーコーが提唱した生権力や生政治（人々の生そのものを管理・統治する権力形態）による統治ということと、ビッグデータや監視・計測技術によって人々の行動データを包括的に扱うITシステムや技術はかなり親和性が高いにも関わらず、ＩＴ業界ではほとんどそのことについて言及されていない。
技術的議論や新しいツールとモダンスタックのトレンドについての議論は日々活発に行われており、JJUGやPyConなどのカンファレンスは年２回とかのスパンで開催されている、にも関わらず技術が社会構造と人々の集団意識にどう影響しているか・し得るか、といった批評的議論は皆無であるし、そのような空間はSNSにも、QiitaやZenのような有名テック系記事投稿サイトにもまだない。
WIREDのような批評的メディアには技術哲学の特集は組まれているが、エンジニアやWebデザイナーの当事者からの発言はほとんどない。
（あったら教えてほしい）

なぜなら、ＩＴ業界に建築や美術、映画、哲学、人文学にあるような批評の文脈がまったくインストールされていないからだ。これは推測だが、IT業界は戦後の高度経済成長期以降に”効率化とビジネス価値”を最優先した結果、急速に発展してきた経緯があり、芸術や建築のように批評や思想を共有する学術的空間や、「美術手帖」「新建築」のような批評を載せる媒体も育たないまま、ここまで来てしまったのではないか。

さらに言えば、批評もまた、いくら儲かったか、何人から「いいね」されたかといった商業主義的メディアとデータ資本主義、同調圧力と空気を読むSNS的空間のなかで力を失って久しい。

生権力と生政治って何？

ここで「生権力」と「生政治」とそれに伴う「統治性」というワードについてchatGPT o1による解説を置いておこうと思う。
これを指摘したミシェル・フーコーの哲学は難解で有名なので、もし「ちがうよ！」というご指摘があればぜひご教授ください。
筆者は学生時代にフーコーの著作「監獄の誕生」を読んで２ページで「むっず！！・・・挿絵見よ」と挫折した経緯があり、本来ここで偉そうに記事書ける立場にないビギナーです。
（ビギナーだからこそ向き合いたいのです）

「買う」ことがマゾ的になっている

石田
別の言い方をすれば、この資本主義社会はサド・マゾでできていて、人々は、生産者としてはマゾになり、消費者としてはサドになるという分裂した生活を生きているわけですね。そして、生産者としての生活は消費社会の裏側になっていて、そこで起きていることの情報はきわめて粗く、メディアに出てこない。社会全体が、アマゾンのサイトと配送センターのような関係になりつつある。世界についての情報も、人々の意識も、消費者視点に収斂してしまっている。
　ところが、感染テクノロジーに囲まれている現在では、消費者というポジションもじつはどんどんマゾになっている。消費者として振る舞っているつもりでも、じつは SNS では知らず知らずにデジタル労働をさせられている。情報をせっせとミツバチのように生み出しているのだけど、その密は吸い上げられて、プラットフォーム企業によってデータとして売り買いされているわけです。おまけにいろいろな情報が大量に押し寄せてきて、自分の欲望が情報の流れに押し流されていく。消費の裏側で生産をがんばれば、消費では報われることになっていた生活も怪しくなっている。消費の主体になるとは欲望の主体になることだったはずなのだけど、いま欲望の主体になるという手触りはあるんだろうか。
　その時に消費者は、マゾとしてははたして生きつづけることができるのか。生産者であることと消費者であることのふたつのバランスをどう考えたらいいか。20世紀的な意味ではもはや消費者としての主体になれないのではないか。そういう風に突き詰めていくと、アマゾンの配送センターの内側にまで想像力が及ぶようになると思うんです。そして政治や社会を問うというようなモメントも出てくるように思う。

「新記号論　脳とメディアが出会うとき」石田英敬、東浩紀「第3講義書き込みの体制 2000」p316より

『消費者というポジションもじつはどんどんマゾになっている』とはつまり、どういうことか。
実際、20～30代の同世代からよく出てくる話を生々しくすれば、どんなに頑張って働いても給料は頭打ち、好きな服、漫画、アニメ、自分の生活を豊かにしてくれているはずのものへ、汗と血反吐で稼いだお金をつぎ込んでも「何にもならない」という感覚が残り、これでいいのだろうかとなんとなく悶々とする。消費しても何かにつながるわけでもなく人生こんなもんかで納得するどころか「これがあと50～60年続くのか・・・」と日常について回るゆるい絶望感のことだ。
この絶望感が起こる背景には、欲望の対象を買ってつかの間あたかも自由な選択をしたように感じられるのに、まわりまわって資本主義というシステムに金をつぎ込んでいるという原理がある。
この逃れられなさに誰もが薄々気づいている、けれども気づいていない振りをさせられる、なぜなら最低限物質的に不自由ない暮らしを確保していたいから。これが絶望感の正体だ。

テック系議論に批評の文脈をマージする

よく言われる「なんだか不機嫌そう」な多くの人にとって否定的、攻撃的に感じられるらしい批評は本来、この私たちをその内側に取り込んで離さない資本主義というシステムに対して行われるべきではないだろうか？
言い換えれば、「資本主義に強制参加させるための諦観をいかに持たせるか、その集団意識がどこで醸成されているか」はスーパーマーケットや１００円ショップで売られている洗濯ばさみ、在庫管理や決済システムのコードからも議論できるし、されるべきだと思う。あらゆる角度から、議論されるべきなのに、哲学人文学、芸術や美術、映画、建築や文学しか対象にしないのはなぜなのだろうか？と問うべきではないだろうか？

そして、DXやICT、AI以後の時代、あらゆる消費行動をデータにし、アルゴリズムによってさらなる資本主義システムという私たちの「痛み」を強化する環境やエンジニアリングにこそ、技術的な議論に「批評」の文脈をマージすべきなのではないか？

クローズドなテクノクラートとアルゴリズム

なぜなら、資本主義の養分となる消費行動や欲望に関するデータ収集元となっている大手検索エンジンやSNSのプラットフォーム、そこで使われているアルゴリズムはほとんどがクローズドな形で運営、実装されているからだ。仮にオープンだったとして、そのコードを読解できるのもエンジニアである技術者だ。
ユーザーから吸い上げられたデータがどこに提供され、どのように変換され、あるいはレコメンドとして再帰的にインタフェースに表れるか、そのときのラインナップは絶望感を強化するものが推されていないか、さらに本来自由であるはずのユーザーの無意識の領域にどう影響を与えるか。ここを問えるのも、技術者であり、技術の開発、設計と実装を担っているIT業界全体にその責任があるのではないかと思うからだ。

データサイエンスとアルゴリズムを利用した技術的暴力はすでに可能なのだ。最近聞いたなかで最もぞっとした話は、関西のある有名私立大学が大学内の学生の日常行動データを地元に「先進事例」の名のもと売っている、という話だ。私たちはすでにスマホによって生体データを吸い上げられている。しかし、そのあとを知らなすぎるし関心も持っていなさすぎると思うのだ。

在庫管理システムのコードから”私たち”を読み解く

コードから資本主義社会に生きる私たち自身を読み解いてみたい。
ChatGPT o1に在庫管理システムのサンプルコードを書いてもらった。

あなた：
Q.　１００円ショップで使われることを想定した在庫管理システムの仕様を簡単な機能概要にまとめ、システムとなるコードをjavaで記述してください。
１００円ショップで使われるので、以下の機能を想定してください。
・「洗濯ばさみ」など１つの品目では１個～５個程度でも、品目数が多いため、大量に発注する可能性がある
・発注タイミングの頻度が多い可能性がある
・発注に必要な情報をリスト化し、金額や総数を帳票として出力する必要がある
・POSレジとのリアルタイム連携 (API連携やファイル連携など)
・高度な需要予測ロジック

chatGPTo1：
以下に、想定される機能概要とサンプル実装コードを示します。実装コードはあくまでサンプルレベルであり、実運用で使用する際にはデータベース連携やネットワーク接続、例外処理など、さらなる拡充・調整が必要です。

1. 簡単な機能概要

1.1. 品目管理機能

商品ID、商品名、価格、現在在庫数、1パックあたりの数量（1～5個程度の場合も）、発注点、発注数量などを管理。
- 例: 「洗濯ばさみ」商品ID=1001, 在庫数=200, 発注点=50, 発注数量=300 など

1.2. 在庫更新機能

POSレジや入出庫作業からの在庫数の変動をリアルタイムで更新。
- API連携やファイル連携を想定。
- 在庫変動履歴(トランザクション)を管理し、過去販売実績に反映。

1.3. 発注支援・需要予測機能

現在在庫数と発注点を照合し、発注が必要な品目をリスト化。
過去販売実績、季節要因、AIによる高度な需要予測ロジックを導入し、適切な発注数量を提案。

1.4. 帳票出力機能

発注が必要な品目の合計数量や金額を帳票として出力。
- 発注リスト、必要金額の総計など。
CSVやPDF、画面表示など、運用に合わせて出力形式を選択。

1.5. POSレジとの連携

API連携：HTTPリクエストやJSON形式などでリアルタイム連携。
ファイル連携：定期的にPOS側が吐き出す売上データファイルを取り込み、自動で在庫を更新。

2. サンプル実装コード (Java)

以下のサンプルコードは、便宜的にシンプルなコンソール出力のアプリケーションとして、クラス構成のイメージを示しています。
実際に導入する際は、データベース接続・トランザクション管理・ログ出力・例外処理などを適切に行う必要があります。

import java.util.ArrayList;
import java.util.List;

/**
 * 在庫アイテムを表すクラス
 */
class InventoryItem {
    private String itemId;
    private String itemName;
    private int price;          // 1パックあたりの価格 (100円ショップの場合は原価など?)
    private int currentStock;   // 現在在庫パック数
    private int packSize;       // 1パックあたりの商品個数 (例: 洗濯ばさみ1パック=5個入り など)
    private int reorderPoint;   // 発注点(パック数)
    private int reorderQuantity;// 発注数量(パック数) - デフォルト値や需要予測結果を適用
    private int demandForecast; // 需要予測結果(今後の販売予想パック数)

    public InventoryItem(String itemId, String itemName, int price, int packSize,
                         int currentStock, int reorderPoint, int reorderQuantity) {
        this.itemId = itemId;
        this.itemName = itemName;
        this.price = price;
        this.packSize = packSize;
        this.currentStock = currentStock;
        this.reorderPoint = reorderPoint;
        this.reorderQuantity = reorderQuantity;
        this.demandForecast = 0;
    }

    // ゲッター/セッターなど省略

    public String getItemId() {
        return itemId;
    }

    public String getItemName() {
        return itemName;
    }

    public int getPrice() {
        return price;
    }

    public int getCurrentStock() {
        return currentStock;
    }

    public void setCurrentStock(int currentStock) {
        this.currentStock = currentStock;
    }

    public int getPackSize() {
        return packSize;
    }

    public int getReorderPoint() {
        return reorderPoint;
    }

    public int getReorderQuantity() {
        return reorderQuantity;
    }

    public int getDemandForecast() {
        return demandForecast;
    }

    public void setDemandForecast(int demandForecast) {
        this.demandForecast = demandForecast;
    }
}

/**
 * 需要予測機能を担うクラス (AI導入や季節要因などはここで計算する想定)
 */
class DemandForecastService {
    /**
     * 過去の販売実績や季節要因などから、今後の需要を予測し設定するメソッド(サンプル実装)
     * @param item 需要予測を行うアイテム
     */
    public void forecastDemand(InventoryItem item) {
        // 実際にはAIモデルや機械学習などを用いて算出する
        // ここではサンプルとして適当なロジックを記述
        // 例: (在庫の3割 + 定数) を需要予測とする
        int predictedValue = (int) (item.getCurrentStock() * 0.3 + 10);
        item.setDemandForecast(predictedValue);
    }
}

/**
 * 在庫全体を管理するクラス
 */
class InventoryManager {
    private List<InventoryItem> items;
    private DemandForecastService forecastService;

    public InventoryManager() {
        this.items = new ArrayList<>();
        this.forecastService = new DemandForecastService();
    }

    public void addItem(InventoryItem item) {
        items.add(item);
    }

    /**
     * POSレジなどから販売実績を受け取り、在庫を減算するメソッド
     * @param itemId  対象商品ID
     * @param soldQty 販売パック数
     */
    public void updateStockFromPOS(String itemId, int soldQty) {
        for (InventoryItem item : items) {
            if (item.getItemId().equals(itemId)) {
                int newStock = item.getCurrentStock() - soldQty;
                item.setCurrentStock(Math.max(newStock, 0));
                // ここで需要予測の更新や在庫変動履歴のログ出力などを行う
                break;
            }
        }
    }

    /**
     * AIや需要予測を行い、必要に応じて発注リストを作成する
     */
    public List<InventoryItem> checkReorderItems() {
        List<InventoryItem> reorderList = new ArrayList<>();
        for (InventoryItem item : items) {
            // 需要予測
            forecastService.forecastDemand(item);
            // 現在在庫 + (需要予測 - 再入荷リードタイム考慮) が発注点を下回る場合など
            // サンプルとして単純に「在庫が発注点を下回れば発注リストに加える」仕様とする
            if (item.getCurrentStock() < item.getReorderPoint()) {
                reorderList.add(item);
            }
        }
        return reorderList;
    }

    /**
     * 発注リストから帳票を生成し、コンソールに表示
     * (実際にはCSVやPDFなどで出力することを想定)
     * @param reorderList 発注対象のアイテムリスト
     */
    public void generateReorderReport(List<InventoryItem> reorderList) {
        System.out.println("=== 発注リスト帳票 ===");
        int totalCost = 0;
        int totalCount = 0;
        for (InventoryItem item : reorderList) {
            int cost = item.getPrice() * item.getReorderQuantity();
            int count = item.getReorderQuantity() * item.getPackSize();

            System.out.println("商品ID: " + item.getItemId() 
                    + ", 名称: " + item.getItemName()
                    + ", 現在在庫(パック数): " + item.getCurrentStock() 
                    + ", 発注数(パック数): " + item.getReorderQuantity()
                    + ", 発注金額(円): " + cost);

            totalCost += cost;
            totalCount += count;
        }
        System.out.println("---------------------");
        System.out.println("合計発注金額: " + totalCost + "円");
        System.out.println("合計発注個数: " + totalCount + "個");
        System.out.println("=====================");
    }
}

/**
 * メインクラス: サンプル動作
 */
public class InventorySystemSample {
    public static void main(String[] args) {
        InventoryManager manager = new InventoryManager();

        // アイテムを登録(サンプル)
        manager.addItem(new InventoryItem("1001", "洗濯ばさみ(5個入り)", 100, 5, 200, 50, 300));
        manager.addItem(new InventoryItem("1002", "使い捨てコップ(10個入り)", 100, 10, 80, 30, 100));
        manager.addItem(new InventoryItem("1003", "紙皿(10枚入り)", 100, 10, 120, 40, 150));

        // POS連携で販売在庫の更新(サンプル)
        manager.updateStockFromPOS("1001", 10); // 洗濯ばさみを10パック売れたと想定
        manager.updateStockFromPOS("1002", 5);  // 使い捨てコップを5パック売れたと想定

        // 発注要否をチェック
        List<InventoryItem> reorderList = manager.checkReorderItems();

        // 発注リストの帳票を出力
        manager.generateReorderReport(reorderList);
    }
}

実装上の補足

POSレジとの連携
- API 連携の場合: updateStockFromPOS の呼び出しを REST API や gRPC などの仕組みを使って行う。JSON形式のリクエストを受信し、販売個数を在庫へ反映するイメージ。
- ファイル連携の場合: POS から出力される CSV やテキストファイルを定期的に読み込み、販売個数を取得して updateStockFromPOS に反映。
需要予測ロジック
- 実際には、商品ごとの販売履歴(日次・週次)や季節要因(夏・冬などの売れ行き変動)を考慮し、機械学習やAIモデルを組み合わせることで需要予測精度を上げる。
- サンプルコードでは単純に「在庫の3割 + 定数10」というモデルを用いているが、プロダクション環境ではより高度なアルゴリズムを実装する。
DB連携・トランザクション管理
- InventoryManager が持つ在庫リストを、実際には RDB や NoSQL に保存・更新する。
- 発注や入庫・出庫といった処理時にトランザクション管理を行い、同時アクセスでも整合性を保つ。
帳票出力
- サンプルではコンソール出力をしているが、実際の業務では CSVファイルや PDF、あるいはプリンタに直接送る仕組みを作る場合もある。

このように、100円ショップのような品目数が多く、1品目の在庫や発注数自体はそれほど大きくない場合でも、頻繁な発注や在庫連携を行うには、リアルタイムの在庫更新と発注支援が非常に重要になります。
上記のサンプル構成をベースに、実環境に合わせて機能拡充や最適化を行ってください。

私たちはテクノロジーに書き込み、書いたテクノロジーによって私たち自身が書かれている

コード解説：商品ごとのアイテム情報のコード

コードはJavaというプログラミング言語で書かれている。
こうしたお金と物の関係を扱うシステムで多く用いられる言語だ。
Noteの埋め込みのシンタックスハイライトが見にくいのでパワポにした。

このコード例は、実際の社会でデータ化できる情報だけを拾い上げることで、人間や物から切り捨てられてしまう個体要素が数多くあることを示すためのあくまで一例である。（実際このまま運用はできない、どうやってシステムが物から情報を取るかをご覧いただきたい）

プログラミングが分からなくても大丈夫です。
ここで押さえてほしいのは、多くのシステムが「入力 → 出力」の関係で成り立っているということ。

画像右側の吹き出しにある通り、商品からは「商品名」「価格」などのデータが取られる。システムによって１０～１５項目の場合もあれば、規模によって２０を超える場合もあるだろう。
言い換えれば「物」の身体からは経済活動に乗る情報以外は零れ落ちるし、取引に必要な情報をもたない物は取引の対象にならない。
実際「洗濯ばさみ」というアイテムを取りとるとき悲しいかなポリプロピレン(PP)やポリスチレン(PS)などの合成樹脂が用いられ、プラスチックの棒を２本合わせ、間に金属製のバネをはさんだあいつだ。
それ以外の姿だってあり得るのに、あの形状を大きく外して持ち手が三つ又になっていたり、無駄にギラギラ発光したりするデザインにはならない、というか洗濯ばさみが参加させられている経済システムによってできなくなってしまっている。

これは私たち自身にも起こっている話で「取引の対象となる肉体とは何か？」という問いを、労働市場であるいはモノづくりの場面で内面化しているし、それは芸術やエンターテインメント、文化にも起きていやしないか？
私たちは「売れる」「いいね」がつく、というマーケティング感覚を内面化することによって無意識に人格、意識、身体を改造してやしないだろうか。

私たちは無自覚のうちにテクノロジーに書き込み、書いたテクノロジーによって私たち自身が書かれているという関係に気づくべきだ。

たとえば「映画化しそうなストーリーの〇〇〇」とか「バズりそうな〇〇〇」とか、、
美術館に行くと、やたら大型の作品しか置かれていなかったりする。取引されるがために画家には「とりあえずデカい絵を描け」ということが言われたり、ペーパーワークは売れない、ということが言われたりするらしい。

これは創造性〈クリエイティビティ〉の危機なんじゃないのか？？？？

であるならば、取引というシステムがまだ未経験の個性を実装すれば、もっとゆたかでユニークな文化が花開くのではないか？　と思うかもしれないが、この思考にこそ落とし穴がある・・・

本当に必要な情報は、何が生態系のダイナミズムを持続させているか

コード解説：発注伝票のコード

帳票システムとはシステム開発で、おおむね紙やPDF出力を可能にする機能のこと。これをまとめて「帳票」といったりする。

多くのシステムでは、データベース（情報の貯蔵庫のようなもの）にある履歴から入力情報を引っ張ってくる、このときまだすべての商品情報が物にぶら下がっているようなところをイメージしてほしい。
しかし「契約申込書」「発注伝票」など、書かれる帳票出力機能の目的によって、出力される項目はコードによって選択される。
ここでは在庫の発注システムなので、GPTは発注伝票に必要な項目を画像右の吹き出しの項目「商品ID」や「発注金額」と理解し、実装のために物の身体情報を取捨選択したようだ。

そもそもの「物」としての情報から、取引されるときだけ必要な情報を編集される。

それが実績となり、店頭に置かれる・置かれない、あるいはこの取引先は仕入れの総量が少ないから、取引しない、など経営に必要な意思決定の判断材料にされるのかもしれない。

ここには、どのくらい付き合いがあるかの時間や、その物を生み出すのにどのくらいの人がかかわっているのかなどの情報は乗っていない。物には短期的な経済活動以外にも文化的・地政学的な背景など、現在の一般的なシステム設計では乗らない情報がたくさんくっついている。

手前味噌で恐縮だが、筆者はエンジニアになる以前、ある法人の在庫管理をしていたことがある。システムには乗らない、在庫管理者しか知りえない情報もたくさんあることを知っている。たとえば、取り扱っている在庫の５割はA社、４割はB社から仕入れているが、残りの１割だけはC社から仕入れている。送料込みだと地方からの仕入れコストの割合が他の物より高くつくが、古い付き合いがあるから仕入れているということは実際やった。
そうしなければならない特別な理由はないが、突発的な国際情勢による輸送トラブルなどを考慮してC社との取引関係は持ち続けるべき、という判断をしていた。
イーロン・マスクのようなコストカッターに言わせれば、C社との取引は切る対象、切らない在庫管理者も切る対象なのだろう。

しかし、いま私たちが知るべき情報は今日明日決済に必要な情報ではなくて、何が生態系のダイナミズムを持続させているかというデータなのではないか。データドリブンでめざすべきは経済的合理性ではなく、いかに経営的体力という名の共同体の身体を細らせず太く持続させるかではないだろうか。物の関係を可視化することで、小さなひとつの店や事業所の経済活動が遠くの地域や文化を知らず知らずのうちに支えている、あるいはどこかの国の地域の事情とつながっているということが現実にはあるし、目にしてきた。そして、この消費の河の先には確実に戦争がつながっている。

そして今後考えていくべきなのは、文化や地域社会の多様な生活様式の在り方をそのままに認知し、支えるよう判断を促すようなシステム設計ではないだろうか。

しかし、この提案は諸刃の剣であることも自覚するべきだ。私たちはテクノロジーに書き込み、テクノロジーによってまた書かれているという関係を思い出してほしい。

IT業界は人文学の態度を活用した新たな技術的批評の在り方を探るべき

重要なことなので再度ここで言いたいのはデータサイエンスとアルゴリズムを利用した技術的暴力はすでに可能なのだということだ。
データサイエンスによるデータの可視化、これをメディアアートの業界の人は「魔術」と呼ぶ。この魔術によっていますでにある苦痛と絶望を強化するか、それとも日々の生活の命の営みを豊かにするために使うか、それは日々web空間で展開されるテック界隈の話題に批評という文脈を接続しマージできるかどうかにかかっているのではないか、と思うのだ。

いいなと思ったら応援しよう！

この記事が参加している募集

#AIとやってみた

47,684件

コードと資本主義がつくる私たちの身体 ーなぜエンジニアに批評と人文学が必要なのか

生権力、生政治とITの親和性

生権力と生政治って何？

「買う」ことがマゾ的になっている

テック系議論に批評の文脈をマージする

クローズドなテクノクラートとアルゴリズム

在庫管理システムのコードから”私たち”を読み解く

1. 簡単な機能概要

1.1. 品目管理機能

1.2. 在庫更新機能

1.3. 発注支援・需要予測機能

1.4. 帳票出力機能

1.5. POSレジとの連携

2. サンプル実装コード (Java)

実装上の補足

私たちはテクノロジーに書き込み、書いたテクノロジーによって私たち自身が書かれている

コード解説：商品ごとのアイテム情報のコード

本当に必要な情報は、何が生態系のダイナミズムを持続させているか

コード解説：発注伝票のコード

IT業界は人文学の態度を活用した新たな技術的批評の在り方を探るべき

いいなと思ったら応援しよう！

この記事が参加している募集

コードと資本主義がつくる私たちの身体ーなぜエンジニアに批評と人文学が必要なのか