■ [開発][プログラミング]ソフトウェア開発とカオスの縁 
- 変わりつつあるソフトウェア開発の価値観 - 4 要素還元論から混沌の縁へ
ソフトウェア開発の工程は非線形の複雑系であり、開発を円滑に進めるためには系を「カオスの縁」に持っていかなくてはならないのではないか、という話。
まず，注目して欲しいのはXPの「4つの価値」です。
- コミュニケーション
- シンプルさ
- フィードバック
- 勇気
この4つの価値をじっくりと見つめていただければ，これらが系をカオスの縁にとどめておくための奥義にもなっていることが判ります。 つまり，
- コミュニケーション → 相互作用そのもの
- シンプルさ → コミュニケーションをシンプルに保ち，系をカオス状態に陥らせないようにする
- フィードバック → コミュニケーションのフィードバックを行い，系を秩序（低エネルギー）状態に陥らせないようにする
- 勇気 → 系の自己組織化に躊躇しない
ということなのです（「シンプルさ」，「フィードバック」，「勇気」については，本来は作業に対する心構えだったはずですが，コミュニケーションに対する心得と解釈してもピッタリはまるので紹介してみました）。
XPのようなアジャイル的な開発手法は系をカオスの縁にとどめておくために有用な手段となっている。開発プロセスを全く適用しないで各人が好きなように作業を進めているような状態だとシステムは文字通り混沌のカオス状態に陥るし、アジャイルでない非人間的な開発プロセスを過度に適用してしまうと、秩序はあるものの低エネルギーで不活性な状態になりやすい。適切なバランス感覚を持ってプロセスを運用することで、システム自体が創発的にカオスの縁に向かって最適化されるような状態にできるはずだ、というのがアジャイルな考え方の根本にあるように思う。
非線形の系に対して何らかの組織化を外部から強制したとしても，系自体がカオスの縁に無ければその組織は秩序状態（予測可能であるものの適応不能）へと移行するか，カオス（予測不能かつ適応不能）に向かっていくかのいずれかになるのです。 この種の状態の変化にどれくらいの時間が必要かという点は，その系の置かれた環境に依存します。
例えば、チームの作業フローがうまくいっていないときに、
- 連絡の行き違いをなくすために定例ミーティングを行う
- 確実な連絡を行うために、何か修正を頼むときにはかならず発注書を書く事を徹底する
- コミュニケーションの維持のため、日報を掲示板に書き込むことを強制する
などのルールを適用して解決しようとすることがある。
しかし、そのルールが厳格すぎたり、形骸化してしまうと系が秩序状態（低エネルギー状態、悪い意味での停滞）に移行してしまうこともあるし、ルールが現場の実情とかけ離れていてそのルールを守らない人が増えてくると、作業フローが発散してカオス状態に移行してしまうこともある。
混沌状態に陥らないためにもルールを作らないわけにはいかないけれども、現実を無視した厳格すぎるルールの適用はチームの活性を失う原因となることもある。停滞状態に陥ったチームでは、開始当初の目的に沿わない状態に形骸化してしまった良くないルールであっても、それに疑問を持つことなく非効率な状態のまま運用されてしまう事が多い。（朝礼や定例全体ミーティングなどは特にこのような状態に陥りやすい・・・）
今は必要なルールであっても、それが明日もそのままの形で有効に機能しているとは限らない。作業の進行と共にチームの状態も変わっていくために、常にルールそのものを疑って、必要に応じて現状にあわせた見直しを行っていく必要がある。
また、開発プロセスと同様にゲームの内のルールも秩序とカオスの間にある「カオスの縁」のような状態に持っていくことが奥が深くてダイナミックな展開になるゲームを作るために重要なのではないか、と昔から思っていたりするけれど、その話はまた別の機会があれば。
