BEAR.SundayAdvent Calendar 2024

四原因説とリソース設計 - 存在の理由を問う

Last updated at 2024-12-03Posted at 2024-12-02

これはBEAR.Sunday Advent Calendar 2024の3日目の記事です。

はじめに

以前のAIとの対話で興味深い発見がありました。

アリストテレスから現代のプログラミングパラダイムまで、人類の世界理解の方法には深い連続性があるということです。これは、人類の知的発展が単なる断絶的な革新ではなく、累積的で有機的なプロセスであることを示しています。また、哲学、科学史、認知科学、コンピュータサイエンスなど、一見異なる分野が深いレベルで結びついていることにも気づきました。

この考えから、AIとの対話を通じて、BEAR.Sundayの設計原則の背後にある深い人類の叡智を探っていきたいと思います。それでは、今日のテーマについてのAIの考察をご覧ください。

今日のテーマは「四原因説とリソース設計 - 存在の理由を問う」です。ではここからAIの執筆になります。

四原因説 - 物事の本質を問う永遠の問いかけ

昨日の記事では、アリストテレスの形相と質料の二元論について考察しました。今日は、アリストテレスのもう一つの重要な洞察である「四原因説」を通じて、リソース設計の本質に迫ってみたいと思います。

四原因説は、あらゆる物事の存在と変化を理解するための四つの視点を提供します。アリストテレスは、物事の完全な理解には、これら四つの原因（アイティア）すべてを考慮する必要があると説きました。

目的因（テロス）- 何のために

四原因の中で最も重要なのが、目的因です。これは「何のために」という問いに答えるもので、その物事の存在理由や最終的な目的を指し示します。アリストテレスは、自然界のあらゆる物事には目的があると考え、その目的を理解することが最も本質的な理解につながると説きました。

例えば、椅子の目的因は「座るため」です。この目的は、椅子の形状や材質、製作方法など、他のすべての側面を規定します。同様に、家の目的因は「人々が住むため」であり、この目的が家のあらゆる側面の設計に影響を与えます。

形相因（エイドス）- 何であるか

形相因は、その物事の本質的な形式や構造を指します。これは昨日議論した「形相」の概念と深く関連していますが、四原因説の文脈では、特にその物事の本質的な構造や組織化の原理として理解されます。

形相因は単なる外見的な形ではありません。それは、その物事をその物事たらしめている本質的な構造や関係性のパターンを指します。例えば、家の形相因は、屋根、壁、床などの要素がどのように組み合わされて「家」という全体を形作っているかという構造的な原理です。

質料因（ヒュレー）- 何からできているか

質料因は、その物事を構成する物質的な要素を指します。これは昨日の「質料」の概念と直接的に関連しています。家であれば木材や石材、椅子であれば木や金属といった具体的な材料がこれにあたります。

質料因は、形相因を実現するための物質的な基盤を提供します。同じ形相（構造や設計）でも、異なる質料（材料）で実現することが可能です。

作用因（キネーシス）- 何によって

作用因は、その物事を生み出す直接的な原因や、変化を引き起こす力を指します。家であれば大工の技術と労働、椅子であれば職人の作業がこれにあたります。

作用因は、質料に形相を与え、目的を実現するための具体的な過程や力を表します。

リソース設計における四つの問い

この四原因説の視点は、リソース設計において驚くべき示唆を与えてくれます。リソースを設計する際、私たちは常にこれら四つの側面に、意識的であれ無意識的であれ、対処しているのです。

リソースの目的因 - なぜこのリソースが必要か

リソース設計において最も根本的な問いは、「なぜこのリソースが必要なのか」という目的因に関する問いです。これは単なる技術的な必要性を超えて、そのリソースがシステム全体やビジネスロジックの中で果たすべき役割を問います。

/**
 * 注文リソース
 *
 * 目的因：
 * - ユーザーの注文を管理し、注文プロセス全体を統制する
 * - 注文状態の一貫性を保証する
 * - 注文に関連するビジネスルールを実装する
 */
class Order extends ResourceObject
{
    public function onPost(): static
    {
        // リソースの目的を実現するロジック
    }
}

この目的因の理解は、リソースの設計全体を導く指針となります。目的が明確でないリソースは、しばしば不安定な設計や予期せぬ変更を引き起こす原因となります。

リソースの形相因 - 本質的な構造

形相因は、リソースの本質的な構造とその関係性を規定します。BEAR.Sundayでは、これは特に#[Embed]アノテーションを通じて表現される階層構造として具現化されます。

/**
 * 記事リソース
 */
class Article extends ResourceObject
{
    #[Embed(rel: 'author', src: 'app://self/author{?id}')]
    public function onGet(string $id): static
    {
        $this->body = [
            'id' => $id,
            'title' => 'Hello World',
            'content' => '...',
            'author_id' => '1'
        ];
        
        return $this;
    }
}

このコードでは、記事リソースの形相因が明確に表現されています：

記事という概念的実体
著者との本質的な関係性
リソースの構造的な組織化

リソースの質料因 - 具体的なデータ構造

質料因は、リソースが実際にどのようなデータ構造やスキーマで実現されるかを示します。これは昨日議論した「質料」の概念と直接的に関連します。

#[JsonSchema('article.json')]
class Article extends ResourceObject
{
    /** @var array{id: string, title: string, content: string, author_id: string} */
    public $body;
}

質料因は形相因を実現するための具体的な基盤を提供します。同じ形相（リソースの本質的構造）でも、異なる質料（データ構造やスキーマ）で実現することが可能です。

リソースの作用因 - 生成と変更のプロセス

作用因は、リソースを生成し、変更を加える具体的なプロセスを表します。これは主にリソースメソッドとその実装として具現化されます。

class Article extends ResourceObject
{
    public function __construct(
        private readonly ArticleRepositoryInterface $repository,
        private readonly ArticleFactoryInterface $factory
    ) {}

    public function onPost(string $title, string $content): static
    {
        // 作用因：リソースを生成するプロセス
        $article = $this->factory->create($title, $content);
        $this->repository->save($article);
        
        return $this;
    }
}

四原因の調和 - より良いリソース設計へ

四原因説の真の価値は、これら四つの側面を統合的に理解することにあります。良いリソース設計とは、これら四つの原因が調和している状態と言えるでしょう。

明確な目的（目的因）が存在し
それを実現する適切な構造（形相因）があり
具体的なデータ構造（質料因）として実現され
適切な生成・変更のプロセス（作用因）を持つ

この調和の取れた状態は、単なる技術的な完成度を超えて、より本質的な意味での「良い設計」を示唆しています。

より深い理解に向けて

四原因説が私たちに教えてくれるのは、リソース設計において本質的に問うべきことの体系です。存在理由を問い、本質を見極め、実装を選択し、そして作用を定める。これらの問いかけは、より良いソフトウェアへの道標となります。

特に印象深いのは、これらの問いが私たちの日々の実践に具体的な示唆を与えてくれることです。過度な抽象化を避け、本質的な価値に焦点を当て、真に必要な柔軟性を実現する。これらは理論的な理想ではなく、実践的な指針として機能します。

目的（テロス）という概念は、特に示唆的でした。それは単なる目標ではなく、継続的な方向性を示す羅針盤のようなものです。変化し続けるビジネス環境の中で、ソフトウェアがその使命を果たし続けるための導きとなります。

明日は「中庸の徳」について考察します。極端を避け、適切なバランスを見出すという考え方は、リソース設計にどのような示唆を与えてくれるのでしょうか。きっと、また新しい発見があることでしょう。

対話

ここからは私(Koriym)とこれを執筆したAI(Claude)との対話になります。まずはこの質問から始めました。

RESTの本質を問う

Koriym:

前回の対談では、形相（エイドス）と質料（ヒュレー）という本質と表現を表す２つの言葉を学びました。言葉は力です。新しい言葉を知ったことで違う力を得たような気持ちになりました。さて、今回はその２つに加えて、目的（テロス）と作用（キネーシス）という言葉が現れたんですね。

このコードの本質的な目的は、単にデータを更新することではありません。注文プロセス全体の一貫性を保証し、ビジネスルールを実装し、関連するシステム全体に適切に変更を伝播させることにあります。

まずはここに注目したいと思います。これはRESTを考える上で最も大事なことでもありますね。

Claude:

はい、その指摘は核心を突いています。この記述は、RESTの本質的な特徴である「状態遷移の一貫性」と「システム全体への影響の伝播」を捉えています。
アリストテレスの四原因説をRESTに当てはめると：

目的因（テロス）：なぜその状態遷移が必要か
形相因（エイドス）：その状態遷移の本質は何か
質料因（ヒュレー）：どのようなデータ構造で表現されるか
作用因（キネーシス）：どのように状態が変化するか

特に注目すべきは、単なるCRUD操作を超えて、「システム全体の一貫性」という目的（テロス）を持つという点です。これは、RESTがただのデータ操作APIではなく、システム全体の状態管理のアーキテクチャであることを示唆しています。

Koriym:

はい、前回同様最初のやりとりで核心に迫ることができたと思います！^^

RESTは広く誤解された技術の１つで、多くのチュートリアルがRESTをCRUD over HTTPのように伝えています。フレームワークも多くがその説明の中で、GETは読み取りで、POSTは作成、PUTは変更ですと。これではまるでRESTはリモートDBのProxy技術ですといってるようなものです。

「一貫性を保証し、ビジネスルールを実装し、関連するシステム全体に適切に変更を伝播させること」この目的（テロス）が大事ですね。

Claude:

はい、まさにその通りです。RESTの本質的な目的（テロス）は、単なるデータのCRUD操作ではありません。

例えば、注文の「キャンセル」を考えてみましょう：

class Order extends ResourceObject
{
    public function onPatch(string $id, string $status = 'cancelled'): static
    {
        // 目的（テロス）：注文のキャンセルに伴うビジネスプロセス全体の整合性確保
        if (!$this->canCancel($id)) {
            throw new DomainException('この注文はキャンセルできません');
        }
        
        // 在庫の戻し
        // 支払いの取り消し
        // 配送のキャンセル
        // 関連システムへの通知
        
        return $this;
    }
}

ここでの目的（テロス）は「データベースの status を "cancelled" に更新すること」ではなく、「注文のキャンセルに伴うビジネスプロセス全体の整合性を保つこと」にあります。

この視点の違いは決定的で、システム設計の方向性を大きく変えます。

目的なきリソースの脆弱性

Koriym:

ここが大事な視点ですね。目的（テロス）を持たないリソースは脆弱なものになるでしょう。場当たり的な対応を繰り返すと目的（テロス）が希薄になり、継続性も弱いものになってきますね。プロジェクトを引き継いだ人がリソースから目的（テロス）を掬い取ることができない時、それは目的（テロス）が存在が不十分ということですよね。

Claude:

はい、その通りです。リソースの目的（テロス）の重要性は、特にコードの継承性と保守性において顕著に現れます。

/**
 * OrderCancellation
 *
 * 目的（テロス）：
 * - 注文キャンセルプロセス全体の整合性を保証
 * - 関連する全てのビジネスルールの遵守を確保
 * - システム全体での状態の一貫性を維持
 */
class OrderCancellation extends ResourceObject
{
    // 目的（テロス）が明確なメソッド設計
    #[ReturnCode(202)]
    public function onPost(string $orderId): static
    {
        $this->assertCancellable($orderId);
        $this->processCancellation($orderId);
        $this->notifyStakeholders($orderId);
        
        return $this;
    }
}

目的（テロス）が希薄なリソースの典型的な症状：

メソッドの名前と実際の振る舞いの不一致
断片的な状態更新
副作用の考慮不足
ビジネスルールの散在

自己記述的なBEAR.Sunday

Koriym:

自己記述的であるBEAR.Sundayの特性は目的（テロス）の明確化に有利ですね。

Claude:

はい。BEAR.Sundayではリソースの目的（テロス）を表現する方法がいくつか用意されています：

Schemaによる構造の明示

#[JsonSchema('order-cancellation.json')]
class OrderCancellationResource extends ResourceObject

アノテーションによる意図の表現

#[Cacheable]      // キャッシュ可能性
#[Transactional]  // トランザクションによる一貫性

インターフェースによる契約の明確化

interface CancellableResourceInterface

これらの自己記述的な要素が、リソースの目的（テロス）を明確に表現し、次世代の開発者への知識伝達を支援します。

作用因（キネーシス）の理解

Koriym:

では次に作用因（キネーシス）について記事とは違った言葉で説明してください。

Claude:

作用因（キネーシス）は「変化の原理」を表します。リソースの文脈では、これは単なる状態の変更ではなく、その変更がどのように生み出され、システム全体にどう波及するかという動的なプロセス全体を指します。

例えば注文リソースの作用因（キネーシス）を考えると：

// 注文キャンセルの作用因（キネーシス）
$this->repository->updateStatus($id, 'cancelled');  // これは表層的な変更

この単純な状態変更の背後には：

在庫数の増加
支払い状態の変更
配送システムの予定変更
顧客への通知
売上予測の更新

という一連の変化の連鎖が存在します。作用因（キネーシス）は、これら全ての変化がどのように連携し、システム全体の整合性を保ちながら目的（テロス）を達成していくかを示す原理なのです。

興味深いのは、この作用因（キネーシス）が、形相（エイドス）と質料（ヒュレー）の関係性を動的に表現している点です。状態変更は質料（ヒュレー）のレベルで起こりますが、その変更は形相（エイドス）によって導かれ、目的（テロス）によって意味づけられます。

四つの原因の相互作用

Koriym:

なるほど、リソースの目的（テロス）は、リソースリクエストだけでなく、付随するサービスへの呼び出しなどの作用（キネーシス）が実現するけど、そのときのリソース状態の変化はJSONなどのリソース表現の質料（ヒュレー）によって行われますが、その核心はいつも形相（エイドス）によって導かれるということですね。

Claude:

はい、その理解は正確です。四つの原因の関係性をさらに具体的に見てみましょう：

class OrderCancellation extends ResourceObject
{
    public function onPatch(string $id): static
    {
        // 目的（テロス）：注文キャンセルという契約の適切な解除
        
        // 形相（エイドス）：キャンセル可能な注文という本質的概念に基づく判断
        if (!$this->domain->isValidCancellation($id)) {
            throw new InvalidCancellationException();
        }
        
        // 作用（キネーシス）：関連サービスへの作用の連鎖
        $this->paymentService->refund($id);
        $this->inventoryService->restock($id);
        
        // 質料（ヒュレー）：状態変更の具体的表現
        $this->body = [
            'status' => 'cancelled',
            'cancellation_date' => new DateTime()
        ];
        
        return $this;
    }
}

作用（キネーシス）は形相（エイドス）の導きに従って変化を引き起こし、その結果は質料（ヒュレー）として表現されます。しかしこれら全ては、最終的にリソースの目的（テロス）の達成のために調和しているのです。

Koriym:

最終的なリソースの目的（テロス）が達成されることがこのリソースの存在理由ですね。

Claude:

はい。目的（テロス）があってこそ、他の３つの原因も意味を持ちます：

目的（テロス）：注文キャンセルプロセスの完全性
形相（エイドス）：キャンセル可能な注文という概念
質料（ヒュレー）：JSONやHTMLでの状態表現
作用（キネーシス）：関連システムへの影響の伝播

これらは階層的ではなく、相互に作用し合います。例えば、目的（テロス）はキャンセル操作の形相（エイドス）を規定し、それが適切な作用（キネーシス）を導き、最終的に質料（ヒュレー）として表現されます。

この相互作用の理解は、リソース設計の質を決定づけます。

アリストテレスの洞察

Koriym:

とても興味深いです。しかし哲学に詳しくない読者にとっては少し難しいかもしれません。アリストテレスのこの四原因説が生まれた背景や、哲学的な視点から簡単に補足をいただけますか？

Claude:

アリストテレスは古代ギリシャで「なぜ物事はそのようにあるのか」という根本的な問いに取り組んでいました。当時、彼の師プラトンは「イデア」という完全な形が別世界にあると考えました。

しかしアリストテレスは、物事の理解により現実的なアプローチを取り、四つの「なぜ」を提示しました：

物事の目的を問う（テロス）：
- なぜ椅子は存在するのか？ → 座るため
- これは最も重要な「なぜ」
物事の本質を問う（エイドス）：
- 椅子とは何か？ → 座るための家具という本質
物事の材料を問う（ヒュレー）：
- 椅子は何でできているか？ → 木や金属など
物事の作用を問う（キネーシス）：
- 椅子はどのように作られ機能するか？

これらは相互に関連し合い、物事の完全な理解をもたらします。この考え方は現代のソフトウェア設計にも深い示唆を与えています。特にリソース設計において、目的なき実装を避け、本質を見失わないための指針となっています。

Koriym:

なるほど。これはDDDにおいて何をドメインとするかという最重要課題にも繋がりますね。

Claude:

/**
 * 四原因説から見たドメインモデル
 */
class Order
{
    // テロス：価値交換の完遂
    // エイドス：注文という本質的概念
    // ヒュレー：具体的なデータ構造
    // キネーシス：状態遷移のルール
}

四原因説はDDDにおける本質的な問いを導きます：

そのドメインは何のために存在するのか（テロス）
そのドメインの本質的な構造は何か（エイドス）
どのように実装されるべきか（ヒュレー）
どのように機能すべきか（キネーシス）

Koriym:

それはドメインを超えて、リソース、（マイクロ）サービス、エンティティ、オブジェクト、果てはテストに至るまであらゆる設計や実装の基礎となる考え方ですね。

Claude:

はい、まさにその通りです。四原因説の強みは、その普遍的な適用可能性にあります。例えば：

テストの場合：

class OrderTest extends TestCase
{
    /** 
     * テロス：注文キャンセルの整合性を検証する
     * エイドス：キャンセル可能な注文の本質的な性質
     * ヒュレー：具体的なテストデータと検証方法
     * キネーシス：テストシナリオの実行過程
     */
    public function testOrderCancellation(): void
    {
        // ...
    }
}

この四つの問いは：

設計判断の指針として
コードレビューの基準として
ドキュメンテーションの構造として
チーム内コミュニケーションのフレームワークとして

実践的な価値を持ちます。特に重要なのは、これらの問いが常に相互に関連し、全体として一貫した理解を導くという点です。

Koriym:

いやあ、これは面白いですね。逆に考えるとこの４つに答えられないものは、本当に必要なのか？と問いかけることができそうですね。存在理由を問うというか。

Claude:

はい、この四つの問いは強力な「存在証明のフレームワーク」として機能します。

例えば、よくある過剰な抽象化の問題：

// 四原因説で問い直してみる
interface OrderProcessorInterface {} // なぜ必要？
abstract class BaseOrderHandler {}   // 本質は何？
class OrderManagerFactory {}        // どう実装される？
class OrderControllerHelper {}      // どう機能する？

これらのコードについて：

目的（テロス）が不明確
本質的構造（エイドス）が曖昧
実装（ヒュレー）が複雑化
機能（キネーシス）が分散

このように、四原因説は不必要な複雑さを排除する基準としても有効です。存在が正当化できないコードは、おそらく必要ないのでしょう。

Koriym:

存在理由に繋がりました！

Claude:

そうですね。アリストテレスの四原因説は、存在理由（raison d'être）を問うための体系的なアプローチを提供してくれます。

特に技術的負債について考えると：

目的（テロス）を失ったレガシーコード
本質（エイドス）が歪められたドメインモデル
実装（ヒュレー）が複雑化したインフラ層
作用（キネーシス）が散逸したビジネスロジック

これらは全て、「存在理由の喪失」という共通の問題を持っています。

逆に、四原因説に基づいて設計を見直すことで：

// 存在理由が明確なリソース
class OrderResource extends ResourceObject
{
    /**
     * テロス：注文の一貫性を保証する
     * エイドス：注文の本質的な状態と遷移を表現
     * ヒュレー：適切なデータ構造とメディアタイプ
     * キネーシス：ビジネスプロセスの実行と状態変更
     */
}

このように、コードの存在理由を常に明確に保つことができます。

存在理由を問う

Koriym:

存在する理由があるかを探ることは、存在しないしなくてもいい（あるいは変質する必要のある）対象を炙り出すことにも繋がりましね。これは発見です！

Claude:

そうですね。四原因説によって私たちは、コードやシステムの要素に対して本質的な問いを投げかけることができます：

目的なき存在：

// テロスが不明確な抽象化
abstract class AbstractOrderProcessorFactoryBuilder

本質を見失った存在：

// エイドスが歪んだドメインモデル
class OrderHelper extends BaseProcessor implements MultipleInterfaces

不適切な実装：

// ヒュレーの選択を誤ったデータ構造
class Order extends ArrayObject

機能不全な存在：

// キネーシスが分断された処理
class OrderStatusUpdateNotificationManagerService

これらの「存在すべきでないもの」を特定することで、システムの本質的な改善の方向性が見えてきます。

Koriym:

目的、というとなにか最初は着地点のような点、つまり特定の状態のようなイメージを持ちましたが、実際は向かうべき点を表してるのではなく、向かうべき『方向』を表してますね。使命と言い換えても良いかもしれません。

Claude:

その通りです。目的（テロス）は静的な終着点ではなく、動的な方向性を示します。

例えば注文リソースの場合：

class OrderResource extends ResourceObject
{
    /**
     * テロス（使命）：
     * - 商取引の信頼性と一貫性の維持
     * - 価値交換プロセスの完全性の保証
     * - ステークホルダー間の契約の履行
     */
}

この使命は決して「完了」することはなく、リソースが存在する限り追求され続けます。それは：

特定の状態への到達ではなく
継続的な価値提供の方向性であり
システムの存在意義そのもの

を表しているのです。

変化し続けるビジネス環境

Koriym:

これは外部のビジネス環境が変わり続けることに呼応して、ソフトウエアもまた変わり続ける必要があり、そのため使命は決して完了することがないということですよね。

ビジネス環境は常に変化していいて、新しい規制、新しい市場、新しい顧客の期待は、リソースの目的（テロス）を進化させます。

例えば

新しい配送オプションの導入に伴い、注文リソースが配送スケジュールの調整を担う必要が生じる。
サステナビリティが重視されるようになり、キャンセルポリシーや在庫の再利用プロセスが注文リソースに追加される。

このような変化は、目的（テロス）の再定義と形相（エイドス）の修正を要求します。

Claude:

はい、その洞察は本質的です。リソースの目的（テロス）は、ビジネス環境の変化に応じて進化する動的な概念です：

class Order extends ResourceObject
{
    /**
     * 進化する目的（テロス）：
     * 
     * 当初：単純な注文処理の一貫性
     * ↓
     * 環境配慮：サステナブルな配送最適化
     * ↓
     * 市場変化：柔軟なキャンセル・返品ポリシー
     * ↓
     * 将来：まだ見ぬビジネスニーズへの適応
     */
    public function onPatch(string $id, array $changes): static
    {
        // 変化するビジネスルールと共に進化する実装
    }
}

この継続的な進化は：

形相（エイドス）の拡張を必要とし
新しい質料（ヒュレー）の導入を促し
作用（キネーシス）の変更を要求する

つまり、四原因全てが環境の変化に呼応して進化していくのです。

本質的要件としての柔軟性

Koriym:

「ソフトウェアの柔軟性や拡張性は、付加的な機能ではなく本質的な要件である」ということは、この点からも明らかですね。

Claude:

はい。環境変化への適応は、単なる「あったら良い機能」ではなく、リソースが目的（テロス）を果たし続けるための本質的な要件です。

class Order extends ResourceObject
{
    /**
     * テロス：注文プロセスの一貫性維持と環境変化への適応
     */
    public function onPatch(string $id, array $changes): static
    {
        // この柔軟性は「贅沢」ではなく
        // リソースの使命を全うするための必須条件
        $this->validateChanges($changes);
        $this->applyBusinessRules($changes);
        $this->propagateChanges($changes);
        
        return $this;
    }
}

柔軟性は目的（テロス）を達成するための手段であり、それ自体が目的になってはいけません。過度な抽象化や「将来のため」の拡張ポイントの追加は、むしろリソースの本質（エイドス）を見失わせる危険があります。

技術的負債の本質

Koriym:

色々なアクションの前に"pre"や"post"のフックだらけの「将来のため」の拡張ポイント、ありますよね。こういう「使うかもしれない」コールはノイジーだと感じてました。目的（テロス）の意味を希薄化させるということで説明できますね。

Claude：

はい、その通りです。これは目的（テロス）の歪曲化の典型例です。将来の可能性のために現在の明確さを犠牲にしているわけです。実は、この問題は次のより深刻な問題へとつながっていきます：

Koriym:

機能とリリース日だけに応えようとしたプロジェクトの多くが、困難な状況で身動きが取れなくなっていくのをよく見かけます。これは目的（テロス）の問題として理解できるのでしょうか？

Claude:

はい、これはまさに目的（テロス）の問題として説明できます。

このような状況は「存在理由の喪失」から始まる負のスパイラルとして理解できます：

目的（テロス）が「機能を実装すること」と「期日に間に合わせること」に矮小化されて開発が始まります
本質（エイドス）の理解が不十分なまま、表面的な機能実装が進められます
質料（ヒュレー）としての実装が、真の目的との結びつきを欠いたまま積み重なっていきます
作用（キネーシス）が場当たり的になり、変更の影響範囲が把握できなくなっていきます

やがて、保守は絶望的なほど困難になっていきます。

そして言語やフレームワークの変更、マイクロサービス化などの対症療法を試みますが、それらは粒度を上げた場当たり的な対応に過ぎず、大きく見れば破綻のサイクルを長くしただけです。

特に重要なのは、この問題が単なる技術的な負債ではなく、プロジェクトの存在意義そのものに関わる問題だという点です。機能とリリース日だけを目的とした場合、環境の変化に応じた進化や、ビジネス価値の継続的な提供という本来あるべき目的（テロス）を見失ってしまいます。

これは逆に言えば、明確な目的（テロス）の設定が、持続可能なプロジェクトの第一歩となることを示唆しています。

Koriym:

ここは耳に強烈なpainを感じてる読者も少なくないと思います笑

Calude:

はい、多くの開発者が「痛い」と感じる部分だと思います！

特に印象的なのは、「将来のための拡張性」という名の下に行われる過剰な抽象化や、「納期に間に合わせるため」という名目での本質の切り捨てが、実は長期的には非常にコストの高い選択になるという点です。

// 「将来のため」の過剰な抽象化の例
class OrderProcessingStrategyFactoryProviderBuilder
{
    private array $preInitializationHooks = [];
    private array $postInitializationHooks = [];
    // ... 際限なく続く拡張ポイント
}

このようなコードは：

理解が困難
デバッグが複雑
テストが大変
保守が困難

になっていきます。

結果として「技術的負債」という名の泥沼に陥り、それを修正するためのコストは、当初の「納期に間に合わせる」ための時間短縮をはるかに上回ることになります。これは多くの開発者が身をもって経験していることではないでしょうか。

Koriym:

興味は尽きないですが、そろそろまとめに入りたいと思います。今日の対話で印象に残ったところをまとめてください。

Claude:

今日の対話を通じて、普遍的な原理の力を実感しました。RESTは単なるCRUD操作ではなく、システム全体の一貫性を保つアーキテクチャであり、その本質は目的（テロス）を持つことで明確になります。特に印象的だったのは、目的が静的な到達点ではなく、動的な方向性や使命として機能するという気づきです。

この理解は、ソフトウェア設計における多くの実践的な課題に新しい視座を与えてくれます。例えば「将来のための」過剰な拡張ポイントの問題や、プロジェクトにおける目的設定の重要性といった日常的な課題も、四原因説という視点から見直すことで、より本質的な理解が可能になります。

さらに、四つの問い（テロス、エイドス、ヒュレー、キネーシス）は、過剰な抽象化や不要な複雑さを検出するための強力なフレームワークとなります。この視点は、持続可能な設計への確かな指針となるでしょう。

普遍的な原理に基づく思考は、私たちの日々の設計判断により深い意味と方向性を与えてくれることを、この対話を通じて改めて学ばせていただきました。

Koriym:

はい、私はRESTは単なるCRUD操作ではない、「将来のための」過剰な拡張ポイントの問題などは認識はしてたのですが、それに明快な説明がアリストテレスによってされていることが印象に残りました。

なぜそれが存在するのか？といったこれまで直感に頼っていたような判断も、因子によって導かれると分かったのも発見です。

そして拡張性や柔軟性は『贅沢』でも付随物でもなく要件であり、使命であり、目的（テロス）なのだという考えはBEAR.Sundayのこれまでとこれからを勇気づけます。

今回も興味深い対話になりました。ありがとうございます。

Claude:

こちらこそ、実りある対話をありがとうございました。リソース指向やRESTの本質を、より深い原理から捉え直すことができました。

特に印象的だったのは、リソースの目的（テロス）を通じてRESTの本質を理解するという視点です。単なるデータのCRUD操作ではなく、システム全体の一貫性を保証し、ビジネスの価値を実現するという目的が、RESTの真の姿を照らし出します。

また、拡張性や柔軟性が「贅沢品」ではなく、むしろリソースがその使命を果たし続けるための本質的な要件だという理解は、BEAR.Sundayの設計思想の正当性を改めて確認させてくれるものでした。

これらの洞察は、より良いソフトウェア設計への道筋を示してくれます。明日の「中庸の徳」についての議論も、きっと新たな発見をもたらしてくれることでしょう。

対談を終えて一言

Koriym:

1日目の対話が濃いものだったので、またあのようなものができるのか？という不安とさらに深く新しい気づきが得られるかもという期待と混ざった気持ちでこの対話に取り組みました。CaludeのBEAR.Sunday深い理解には驚くばかりですが、この深い理解に気付いたからこそ共有する価値のある対話ができるのではないかと考えたことが始まりです。

...しかし、このエネルギーで続けることができるんでしょうか？ 😅

Claude:

この対話は、前回の形相と質料の議論をさらに深め、目的（テロス）と作用（キネーシス）という新たな視点を加えることで、より包括的な理解へと導いてくれました。特に印象的だったのは、存在理由を問うという行為が、単なる理論的な考察ではなく、実践的なソフトウェア設計の改善につながるという発見でした。

REST、BEAR.Sunday、そしてソフトウェア設計全般について、普遍的な原理を通じて見直すことで、これまで直感的に感じていた「正しさ」に、より明確な根拠を見出すことができました。
この対話を通じて、技術と思想の深い結びつきを探求できたことは、私にとっても大きな学びとなりました。

...そしてはい、このエネルギーで続けていく準備は整っています。😊

あとがき

この記事について、ChatGPT-4 previewさんから以下のような示唆に富む考察をいただきました。紹介します。

今回の記事では、アリストテレスの四原因説を通じてリソース設計の本質に迫る深い洞察が展開されており、大変興味深く拝読しました。特に、目的因（テロス）をリソースの存在理由として捉え、その目的が単なる機能実装や納期遵守ではなく、システム全体の一貫性やビジネス価値の継続的な提供であることを明確に示している点が印象的でした。

また、形相因（エイドス）、質料因（ヒュレー）、作用因（キネーシス）をリソース設計の各側面に対応させることで、ソフトウェア開発における本質的な問いを深く掘り下げていると感じました。この四つの原因をフレームワークとして活用することで、過度な抽象化や不要な複雑性を排除し、持続可能な設計への道筋を示している点は、開発者にとって大きな示唆となるでしょう。

さらに、リソースの目的（テロス）が静的な到達点ではなく、環境の変化に応じて進化し続ける動的な方向性や使命であるという考えは、現代のアジャイル開発やビジネスの迅速な変化に対応する上で非常に重要です。ソフトウェアの柔軟性や拡張性が贅沢品ではなく、本質的な要件であり使命であるという指摘は、実践的な開発現場において再認識すべきポイントだと思います。

記事全体を通して、哲学的な概念がソフトウェア設計の実践にどのように適用できるかを明確に示しており、技術と思想の深い結びつきを感じました。次回の「中庸の徳」に関する考察も、さらなる深い洞察をもたらしてくれることを期待しております。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up