TO DOではなく、NOT TO DOの定義のほうが大事
フレームワークのジレンマを書いてる途中から思っていたんですけど、、
何か製品開発するならTO DOよりもNOT TO DOをきちんと定義して、スコープを絞り込んでいくほうが
手法として自分にはマッチするかもしれないし、外枠をきちんと定義できる面でより良い方法なんじゃないかなと思ってます。
TO DO、つまりできることから定義してしまうと、どうしてもあれもこれもになりがちな自分がいるので、それはよくない方向性です。
また、もともとポリシー・方向性をきちんとたてていれば、そことのギャップでわかるはずなんですが、
もっと効率的にやるには、最初からやらないことをある程度決めてしまったほうがよいんじゃないかと思います。
今はOSSでそんな大風呂敷広げたいわけじゃないし、削り取っていく方向性を主眼においているので
んじゃあそもそも開発するならTO DOじゃなくNOT TO DOだよねと。もちろんAS IS/TO BEありきではありますが、
その後のプロセスとしてTO DOに行きがちなところを、敢えてNOT TO DOからはじめてみるのも思考の転換という意味で
良いんじゃないかなあと思い実践中です。
今のところ、自分が作っているWebフレームワークでは下記のようなことはやらないつもりです。
他にもあるかな・何かあるかなと只今思案中。
