プロセス（というかライフサイクル）として、アジャイルの人気が出てからずいぶん
経ち、言葉自体はほとんどの人が聞いたことがあると思う。
　ゲーム業界では、ウォーターフォールどころか、それ以前の無プロセス状態で開発し
ているところも、いまだに多いと思われる。設計もせずに、いきなりコーディングする
ような手法だ。
　無プロセス状態は、ある意味、アジャイルに似ていると言えなくもない。
　ゲームは、非常に高度なプログラミング技術が必要ではあるが、トラブルの要因とな
りやすい入出力が、出力が画面・入力がパッドのみと、非常にシンプルであるため、間
違いに気づきやすい。
　したがって、無プロセスでも意外と失敗しない。がんばって月200時間ぐらい残業すれ
ば、なんとなく終了する。しかし、無プロセスとアジャイルの決定的な違いは、プログ
ラマーが５人以上になったあたりから出始める。そして、今までと同じやり方でなぜう
まくいかないのか悩むことになる。
　密なコミュニケーション・すばやい提供(目的意識)・優先順位の高い作業からやる、
というようなアジャイルでは当然のプラクティスを、無プロセスでは意識しておらず、
人が増えればコミュニケーションが減り、作業分担が得意分野での分割ではなくなり、
統合が疎になる。人数が少ないと、統合が密なので、すばやい提供が出来るが、もとも
とそれを意識して実行しているわけではないので、統合が疎になれば、すばやい提供が
自然に出来なくなっていく。
　ゲーム業界も、プロジェクトメンバーが１０人以上、プログラマーが４人以上という
のが当たり前になってきている。アジャイルにこだわる必要はないと思うが、なにかし
らのプロセスやライフサイクルを持つべき時期に来たのではないだろうか。

　プログラマの思索さんで紹介されているリーンソフトウエア開発～アジャイル開発を実践する22の方法～。まだ、読んでいませんし、買ってもいないのですが、非常に前から気にはなっていました。

　プログラマの思索さんによると、計画主導のプロセスとアジャイルをブリッジするような、計画主導の欠点やアジャイルの利点･問題点などを、ツールや理論などを使い説明してあるとの事だった。

　非常に面白そうである。今度買ってこよう。買って積みっぱなしで読んでいない本がいっぱいあるが、とにかく読んでみよう。

　リトルの法則なるもののリンクもあって、見てみたが、これは待ち行列的に考えると、結構違うんじゃないのとか思ったが、考えてみると、満席で座れないときは、飲み物だけ買って出ちゃうので、来客数が平均を上回った分平均利用時間も下がるし、来客数が減ったときは、空席が目立ち、その分利用者は時間をゆったりと過ごし、平均利用時間が上がる。と、考えると、意外と合っているのかもと思った。
　もちろん、レジの個数・平均レジ利用人数・平均注文時間で考えると、ずれてきちゃうとは思いますが。

　話はずれましたが、リーンソフトウエア開発です。とにかく読んでみようと思います。ヨドバシのポイントで買いたいけど、売ってるかな～