ひがやすを技術ブログ

電通国際情報サービスのプログラマ

エピソード3 シスの復讐

くーすは、ユースケースロバストネス分析して、コントロールの部分をステートレスなロジックに、エンティティの部分を振る舞いを持たないDTOで構成し、ロジックの部分はさらにFDDで分割するというところから、はじまっています。
これが、アーリーくーすで、ステートレスなロジック部分をDIコンテナで管理するようにしたのが、くーすです。荒削りだけど、大きなフォースを持っていました。
ロバストネス分析、ステートレスなロジック、振る舞いを持たないDTOというのがポイントです。たぶん、一般的に思われているくーすは、このバージョンのものでしょう。
この段階で、本が出ていれば、何の問題も無かったのです。
現実はどうだったかというと、くーすを実際に試してみる方が現れ、そのフィードバックも取り込みました。そして、私自身も会社で試して、くーす自身にフィードバックしました。くーすが変化(改良としていないのは人によって良いかどうかの判断は異なるためです)していったのです。この変化こそ、この先、くーすが暗黒面に落ちていってしまう原因になります。
私は、フィードバックの中で、ロバストネス分析を削りました。最もくーすを特徴付けていたものを削ったのです。実際に試してみて、UIモックがあれば、ロバストネス分析なしでも、コントロールやエンティティを洗い出すことができたからです。
頭を整理する意味で、お絵かきしてもいいのですが、できるだけ工数を減らしたかったので。
この段階で、くーすは当初の面影がかなりなくなっていきます。そして、この辺から、技術的なことよりもユーザの要件をいかに引き出すかという点にくーすのポイントが移っていきました。当初技術的な意味合いが強かったのがだんだん変わっていったわけです。
今のGoyaのユーザ中心の設計というのは、この辺のフィードバックが生かされています。
外から見るとどうなっていたか良く分からなかったと思いますが、内部ではユーザの要件をいかに引き出すかという点で執筆を進めていました。
もうこの時点で、オリジナルのくーすは、影も形もなくなっています。
また、このころから私自身いろんなイベントなどにおわれ、執筆する時間が取れなくなっていました。それに対する対応として、はぶさんを共著者として迎えることにしました。これが、くーすが暗黒面に落ちる決定的な原因になります。はぶさんが、悪いということではなく、逆に2人でいろいろディスカッションしながら考えて、くーすは、さらに洗練されていったのですが、オリジナルからの変化という点では、全然違うものになってしまったのです。
後は、シスの復讐により、完全に暗黒面に落ちてしまいました。
オビワンのように戦う手もあったのですが、今後は、オープンソース型で進めていった方がいいと考えていたこともあり、あっさりくーすからは手を引きました。
これがことの顛末です。