考え中

  # PIPSにおける自己完結性と環境依存の扱い

## 1. 基本思想

PIPSでは、一般的なWebアプリケーションで暗黙に信頼されている外部環境を、できるだけ無条件には信用しない。

これは「一般的な構成が悪い」という意味ではない。

PIPSが想定するのは、

- 特殊なレンタルサーバー
- 設定を自由に変更できないサーバー
- Apache以外のWebサーバー
- `.htaccess` を利用できない環境
- サービスだけを別のサーバーへ移動する環境
- 一部の依存ファイルやディレクトリが存在しない環境

など、必ずしも理想的ではない環境である。

そのため、

> 「この環境なら普通はこうなっている」

という前提よりも、

> 「PIPSが必要とする条件が、本当に成立しているか」

を確認してから利用することを重視する。

---

## 2. 非公開領域を `.htaccess` に依存させたくない理由

Webアプリケーションでは、例えば次のような構成が考えられる。

    pips/
        index.php
        private/
            session.key

そして `.htaccess` によって `private/` へのWebアクセスを禁止する。

これは一般的な方法の一つである。

しかしPIPSでは、この構造を基本構成にはしたくない。

理由は、`private/` が安全である理由がPIPS自身のファイル構造ではなく、

    PIPS
      ↓
    Apache設定
      ↓
    .htaccess
      ↓
    「このディレクトリは公開しない」

という外部設定に依存するからである。

PIPSだけを別のサーバーへ移動した場合、

    pips/
        index.php
        private/

というファイル群をコピーしただけでは、安全性まで移動したことにはならない。

`.htaccess` がコピーされなかったり、そもそも`.htaccess`を使用できなかったりすれば、秘密情報がWebから取得可能になる可能性がある。

つまり、

> ファイルを移動しただけでは、ソフトウェアが成立するための安全条件まで移動できない。

ここに問題がある。

---

## 3. そのため、秘密情報をWeb公開領域の外側へ置く

PIPSでは、可能な限り秘密情報をDocumentRootの外側に置く。

例えば、

    /var/www/
        private/
            pips/
                session.key

        html/
            pips/
                index.php

のような構造である。

この場合、PIPSから見れば、

    ../private/pips/

という場所に秘密情報を置くことになる。

この方法では、

> 「privateという名前のディレクトリだから非公開」

というサーバー設定上の約束ではなく、

> 「そもそもWeb公開領域の外側に存在する」

というファイルシステム上の境界を利用できる。

ただし、これも無条件に信用するわけではない。

---

## 4. PIPS自身が必要条件を検査する

PIPSでは、秘密領域を定数などで明示的に指定する。

例えば概念的には、

    PRIVATE_DIR = "../private/pips"

のようにする。

そして起動時などに、その場所について確認する。

### 確認する条件

1. 指定されたパスが存在するか
2. それが期待するディレクトリであるか
3. 実際の解決先がどこなのか
4. Web公開領域の外側に存在するか
5. PIPSが秘密情報を保存してよい場所として利用できるか

これらの条件を満たさなければ、秘密情報を保存する処理を実行しない、あるいは必要な機能を停止する。

重要なのは、

> Apacheに「ちゃんと非公開にしてください」とお願いして終わらない

ことである。

Apacheの設定を前提として利用するのではなく、

    Apache / ファイルシステムの環境
                ↓
          PIPSによる検査
                ↓
        条件が成立している
                ↓
          秘密情報を利用

という流れにする。

---

## 5. これは「二重確認」である

この設計では、環境に対して一つの前提だけを置かない。

例えば、

    「この場所をprivateとして指定した」
                ↓
    「実際に存在する」
                ↓
    「ディレクトリとして利用できる」
                ↓
    「DocumentRootの外側にある」
                ↓
    「秘密情報を置く条件を満たしている」

という複数の確認を行う。

したがって、

> 設定値が正しいこと

と

> その設定値が実際の環境でも安全条件を満たしていること

を分離して考える。

これは一見すると遠回りである。

しかし、PIPSにとってはこの遠回りそのものが設計上の意味を持つ。

---

## 6. なぜそこまで確認するのか

一般的なWebアプリケーションでは、

    Webサーバー
      ↓
    DocumentRoot
      ↓
    Apache設定
      ↓
    PHP
      ↓
    アプリケーション

という環境全体を、ある程度正常に構成されているものとして扱う。

そのため、

> 「このディレクトリは非公開設定になっている」

という時点で話を終えることもできる。

しかしPIPSでは、

> 「なぜそれが安全なのか？」

をもう一段掘り下げる。

例えば、

- その設定が存在しなかったら？
- `.htaccess` が使えなかったら？
- 別のWebサーバーだったら？
- PIPSだけ別サーバーへ移動したら？
- 管理者が設定を変更したら？
- 指定したディレクトリが存在しなかったら？
- 秘密情報を置く場所そのものが公開領域だったら？

という条件まで考える。

つまり、

> 「正常な環境だから安全」

ではなく、

> 「安全に動作するための条件を確認し、その条件が成立した場合だけ動作する」

という考え方を採る。

---

## 7. ライブラリにも同じ問題がある

この問題はPIPS本体だけでは終わらない。

例えばPIPSが、

- account
- session
- encryption
- private storage

などのライブラリを使用するとする。

これらのライブラリも、それぞれ秘密情報を必要とする可能性がある。

例えばsessionライブラリが暗号鍵を必要とするなら、

    session/
        session.php

だけをPIPS内部へコピーすれば終わりではない。

そのライブラリには、

> 「暗号鍵をどこに保存するのか？」

という別の問題が存在する。

そこで、

    PIPS
      ↓
    検証済みのprivate領域
      ↓
    sessionライブラリ
      ↓
    session専用の秘密情報

というように、PIPSが確認した安全な保存領域をライブラリへ渡す設計が考えられる。

つまり、

> ライブラリの移植性と、ライブラリが秘密情報を保存する場所の移植性は別問題ではない。

この二つは一体として設計する必要がある。

---

## 8. 「ライブラリが存在するか」も同じ考え方になる

外部ライブラリについても、

    require "../account/account.php";

のように、外部ディレクトリが当然存在すると仮定する構造は避けたい。

重要なのは、単にパスを正しく計算することではない。

例えば、

    __DIR__

を使えば、PHPファイル自身の場所を基準としてパスを計算できる。

しかし、

    require __DIR__ . "/lib/account/account.php";

としても、そのファイルが存在しなければエラーになる。

つまり、

> `__DIR__` はパスを正しくする仕組みであって、依存関係を存在させる仕組みではない。

そのため、

    依存関係を確認する
            ↓
    存在している
            ↓
    読み込む
            ↓
    存在していない
            ↓
    適切に処理する

という仕組みそのものが必要になる。

---

## 9. 開発単位と配布単位を分離する

ここから、ライブラリの扱いについても同じ思想が適用できる。

開発時には、

    account
    session
    encryption
    PIPS

を別々に開発してよい。

しかし配布時には、

    pips/
        index.php
        bootstrap.php
        dependencies.json
        dependencies.lock

        lib/
            account/
            session/
            encryption/

のように、PIPSが必要とするものを自身の中へまとめることができる。

つまり、

> 開発上は分離する。
>
> 配布上は自己完結させる。

という考え方である。

これならPIPSだけを別のサーバーへ移動させても、外部の共通ライブラリディレクトリを必要としない。

---

## 10. インターネット上の配布元にも依存しすぎない

ライブラリを必要に応じて取得する場合も、

    PIPS
      ↓
    インターネット
      ↓
    配布サーバー
      ↓
    ライブラリ

という依存だけにしてしまうと、配布元が消滅した場合に問題になる。

そこで、

    ライブラリ本体
    バージョン
    ハッシュ
    必要なら署名

などを記録し、取得した成果物そのものをPIPS側へ保持する。

そうすれば、

> 「配布サーバーが存在するから動く」

のではなく、

> 「一度取得して検証した成果物が手元に存在するから動く」

という状態にできる。

更新機能と動作に必要な依存関係を分離することが重要になる。

---

## 11. 目指しているのは「普通の環境」ではない

この設計思想では、

> 危険だから、その環境では使わない

という結論を最初から採らない。

むしろ、

> 危険になり得る環境なら、何が危険なのかを特定し、その条件をソフトウェア自身が検査できるようにする。

という方向へ進む。

例えば、

    秘密領域がない
        ↓
    作れない
        ↓
    安全に秘密を保存できない
        ↓
    その機能を停止する

という動作も許容する。

「どんな環境でも動かす」ことが目的なのではない。

**「動かしてよい環境かどうかを、可能な範囲でPIPS自身が判断できるようにする」**

ことが目的である。

---

## 12. なぜ「遠回り」に見えるのか

この設計は、一般的な設計と比較すると遠回りに見える。

例えば、

    「.htaccessで禁止すればいい」

なら一行で済むかもしれない。

しかしそれでは、

    なぜ安全なのか
    ↓
    Apacheの設定を信用しているから

となる。

PIPSが求めているのは、

    なぜ安全なのか
    ↓
    指定された場所を検査した
    ↓
    実際のパスを確認した
    ↓
    公開領域との関係を確認した
    ↓
    条件を満たした
    ↓
    だから利用する

という因果関係である。

そのため、他人から見ると「そこまでやる必要があるのか」と思われる処理が、自分にとっては必要になる。

---

## 13. もやもやの正体

この設計へのこだわりは、単なる神経質さや潔癖さではない。

おそらく根本にあるのは、

> **「動いている」だけでは納得できず、「なぜ動いているのか」を自分で追跡できる状態にしたい**

という要求である。

外部環境に、

    「たぶん存在する」
    「普通なら設定されている」
    「このサーバーなら大丈夫」
    「このフォルダ名なら非公開だろう」

という暗黙の前提が残っていると、そこが自分から見えない。

そして、その見えない部分が残っている限り、

> 「もしその前提が崩れたら？」

という疑問が残る。

そのため、多少遠回りになっても、

    前提
      ↓
    検査
      ↓
    成立条件
      ↓
    実行

まで明示したくなる。

それによって初めて、システム全体の因果関係が自分の中で閉じる。

---

## 14. PIPSの設計思想

以上をまとめると、PIPSの思想は次のように表現できる。

> **PIPSは、正常な環境を当然のものとして信用するのではなく、自身が必要とする環境条件を可能な範囲で検査し、その条件が成立した場合にのみ安全性を成立させることを目指す。**

そのために、

- Webサーバー設定への依存を減らす
- `.htaccess` に安全性を丸投げしない
- 秘密情報は可能な限りWeb公開領域の外へ置く
- 秘密領域を定数として明示する
- その存在と公開範囲をPIPS自身が検査する
- ライブラリの存在も前提にしすぎない
- ライブラリ自身の秘密情報の保存場所まで設計する
- 開発上の分離と配布上の自己完結を分離する
- 外部配布サーバーが消えても、既に導入したものは動作できるようにする
- 更新機能と動作に必要な依存関係を分離する
- 条件が成立しない場合は、無理に動かすのではなく停止・機能制限する

という構造を取る。

これは「何でも自前で作る」という思想ではない。

**外部に依存する場合でも、その依存を明示し、検査可能にし、必要なら代替できる状態にする。**

その結果として、PIPSは「普通の環境でだけ正常に動くソフトウェア」ではなく、

> **環境が普通でないことを前提にしても、自分が安全に動作できる条件を確認しながら動くソフトウェア**

を目指すことになる。

---

## 15. 最後に

この設計は、一見すると遠回りである。

しかし、その遠回りによって、

    「たぶん安全」
    「普通なら存在する」
    「サーバー側で設定されているはず」

という暗黙の前提を減らすことができる。

そして、

> **「なぜ安全なのか」をソフトウェア自身が説明できる状態に近づける。**

PIPSにとって、この確認処理は余計な処理なのではない。

それ自体が、PIPSをどのような環境でも扱えるようにするための主要な設計要素である。
  

  はい。ご指摘の方がかなり本質的だと思います。\
 前の回答で私は「アジャイル＝変更を歓迎する」という説明を置きましたが、**それをそのままアジャイルの本質として扱ったのは単純化しすぎでした。**

 むしろ、あなたが言う

 > **相対化するためには、まず絶対化された土台が必要**

 という見方をアジャイルに当てはめると、かなり重要な問題が見えてきます。

 ## 「変更を歓迎する」には、変更できないものが必要

 例えば日本企業で、

```
社長：
「この開発環境は絶対に変えるな」

現場：
「分かりました。その条件の中で開発します」
```

 となった場合、

 「環境を変更できないからアジャイルではない」

 とは言えません。

 むしろ、

```
【絶対条件】
開発環境は変更しない
        ↓
【相対化できるもの】
設計
実装
UI
データ構造
プロセス
優先順位
```

 という形で、**何を固定し、何を変数にするかを定義して初めてアジャイルが成立する**。

 ここが重要です。

---

 # アジャイルは「全部を変える思想」ではない

 アジャイルの有名な考え方には、

 > 「変化への対応」を重視する

 というものがあります。

 でもこれは、

 > **「何でも変更可能にしておけ」**

 ではありません。

 むしろ実務では、

```
変えられないもの
────────────────
会社の規約
法令
契約
予算
既存インフラ
顧客との約束
経営判断
セキュリティ要件
技術的制約
────────────────

その上で変えられるもの
────────────────
設計
実装
優先順位
UI
機能
リリース順
```

 という構造になります。

 つまりアジャイルには、**固定された境界条件が必要**です。

---

 # そして、ここがあなたの「絶対化」の話になる

 これは数学・物理・科学にも似ています。

 例えば、

```
座標系を固定する
       ↓
物体の位置を相対的に測れる
```

 座標系まで毎回変わったら、

 > 「何に対して位置が変わったの？」

 となる。

 あるいは、

```
基準点 A を固定
        ↓
B はAから +10
C はAから -5
```

 とできる。

 しかしAまで毎回動かしたら、

```
Aが+3
Bが+10
```

 という数字だけでは何も分からなくなる。

 だから、

 > **相対化には基準となる絶対が必要**

 というあなたの指摘は、かなり一般的な構造を持っています。

---

 # これを「ゲーム」に当てはめると、むしろ綺麗

 今回の人がやっていることは、

```
┌──────────────────────┐
│       絶対化されたルール    │
│                          │
│ DBなし                   │
│ Cookieなし               │
│ JSなし                   │
│ .htaccess変更不可         │
│ php.ini変更不可           │
│ 移植可能であること         │
└───────────┬──────────┘
            ↓
       その範囲内で
       相対的に最適化
            ↓
       実装A → 実装B
            ↓
       構造A → 構造B
            ↓
       次の問題
```

 なんですよね。

 つまり、

 **「ゲームのルール」が絶対化された土台**

 になっている。

 その土台を変えないからこそ、

 > 「じゃあ、この条件下ではどんな構造が一番いいのか？」

 という相対化ができる。

 これは実はかなりアジャイル的です。

---

 # だから「アジャイル＝変更を歓迎」は逆に危険

 ここは私の前回答を修正したいところです。

 「アジャイルだから変更を歓迎する」とだけ言ってしまうと、

```
問題発生
 ↓
制約変更
 ↓
問題解決
```

 もアジャイルになってしまいます。

 でも、それでは極端な話、

 > 「動かないので仕様を消しました」

 も「適応した」と言えてしまう。

 これはおかしい。

 本当は、

```
固定するもの
      ↓
変更可能領域を定義
      ↓
その領域を反復的に変更
      ↓
フィードバック
      ↓
再調整
```

 です。

 つまり、

 > **アジャイルは「制約がない状態」ではなく、「制約の内側で変化可能な領域を持つこと」**

 と考えた方がいい。

---

 # そして「社長が環境を変えるな」と言っても成立する

 ここはあなたの例が非常にいいです。

 例えば社長が、

 > 「うちは10年間このサーバー環境を変えない」

 と言ったとする。

 これは一見、アジャイルの敵に見える。

 しかし実際には、

```
サーバー環境
    ↓
【固定】

その上で

アプリケーション
設計
UI
機能
優先順位
リリース
    ↓
【可変】
```

 なら、十分に反復開発できます。

 むしろ企業ではこういうケースが非常に多い。

 したがって、

 > 「環境が固定されているからアジャイルできない」

 という考え方は誤りです。

 正しくは、

 > **「何を固定するかを決め、その固定された境界の内側でどれだけ学習・変更できるか」**

 です。

---

 # そして、ここでこの人の「ゲーム」がかなり面白くなる

 実は本人がやっていることは、

 **アジャイルに反しているのではなく、アジャイルのための「絶対」を自分で作っている**

 と解釈できます。

 例えば、

```
【絶対】
DBを使わない

        ↓

【相対】
ではどうデータを保存する？

        ↓

A案
ファイル

        ↓

問題発生

        ↓

B案
暗号化されたファイル

        ↓

問題発生

        ↓

C案
別の保存方式
```

 このとき「DBを使わない」という絶対条件があるから、

 **A/B/Cという相対的な設計比較が成立する。**

 もし途中で、

 > 「面倒だからDB使おう」

 としたら、

```
ゲームの問題を解いた
```

 のではなく、

```
ゲームのルールを変更した
```

 ことになります。

 だから本人にとってCloudflareやDBが「解決にならない」場合がある。

---

 # ただし、さらに一段深い問題があります

 あなたが言う、

 > 「絶対化の思想は不可欠」

 について、私は\*\*「何を絶対化するか」まで含めて考える必要がある\*\*と思います。

 ここがかなり重要です。

 例えば、

```
絶対：
「DBを使わない」
```

 は、単なる技術的制約です。

 一方、

```
絶対：
「利用者の個人情報を安全に扱う」
```

 は、目的です。

 この二つを混同すると危険です。

 理想的には、

```
【目的】
個人情報を安全に扱う
       │
       ├── DB
       ├── ファイル
       ├── 暗号化
       └── その他

【制約】
DBを使わない
       │
       └── この制約下で最適解を探索
```

 と分ける。

 すると、

 > 「DBなし」は絶対だが、「保存方式」は相対的

 になります。

---

 # これがアジャイルの難しいところ

 アジャイルで本当に難しいのは、

 **「変更すること」ではなく、「何を変更してはいけないのかを決めること」**

 なんです。

 例えば、

```
要求
 ↓
制約
 ↓
設計
 ↓
実装
```

 のうち、

```
要求
```

 まで毎回変えたら、プロジェクトは漂流します。

 逆に、

```
要求も制約も絶対固定
```

 なら、今度はウォーターフォール的になってしまう。

 だから、

```
                 絶対
                  │
        ┌─────────┴─────────┐
        │                   │
      目的                 制約
        │                   │
        └─────────┬─────────┘
                  ↓
              可変領域
                  ↓
              実験・実装
                  ↓
               feedback
                  ↓
             次の相対化
```

 という**階層構造**が必要になる。

---

 # そして「日本企業だから無理」という話でもない

 ここも少し違います。

 日本企業で、

 > 「社長が開発環境を変えるなと言っている」

 としても、

 **その制約が明確なら、むしろアジャイルの境界条件として利用できます。**

 問題なのは、

 > 社長が昨日「変えるな」と言ったのに、今日「なんで古いんだ」と言い、明日「やっぱりCloudflareにしろ」と言う

 ような場合です。

 これは、

```
絶対条件が存在しない
```

 ので、相対化する基準がない。

 その場合、アジャイル以前の問題になります。

---

 # 私なら今回の問題をこう表現します

 あなたの指摘を踏まえると、

 > **アジャイルとは「変化を受け入れる思想」ではなく、「固定された基準・目的・制約のもとで、変更可能な領域を反復的に探索する思想」と捉えた方が本質に近い。**

 と思います。

 そして今回の彼は、

```
「この条件だけは絶対に変えない」
             ↓
     その条件を土台に
             ↓
     あらゆる設計を相対化
             ↓
        実装して試す
             ↓
        また相対化
```

 をやっている。

 だから、**「ゲーム」という表現はかなり正確**なんです。

 ゲームにはルールがある。

 ルールは基本的に絶対。

 だからこそ、そのルールの中で、

 > 「どうすれば勝てる？」

 という無数の相対的な戦略が生まれる。

---

 ## そして、ここからが一番面白いところ

 この見方をすると、彼が今ぶつかっている

 **「単独移動可能性 vs 共通ライブラリ」**

 は単なる技術問題ではありません。

 これは、

 > **「ゲームのルールを守ったまま、ゲームそのものの攻略方法を変えられるか」**

 という問題になっています。

 つまり、

```
絶対：
「単体移動可能」

絶対：
「環境を選ばない」

絶対：
「共通ライブラリは重複させたくない」

       ↓

この3つを同時に成立させる

       ↓

現在の設計では無理

       ↓

では「どれを捨てるか」ではなく、

       ↓

「この3つを同時成立させる
  新しい抽象化は存在するか？」
```

 と考えている。

 **ここまで来ると、本人が「これはゲームだ」と言っている意味がかなり腑に落ちます。**

 そして私は、ここでは「アジャイル」という言葉より、むしろ\*\*「制約を絶対化した上で、その内部を相対化し続ける探索」\*\*と表現した方が、この人の思想を正確に捉えていると思います。