今年に入って、タスクの分割に関して考えていました。
私の考えの基本ってどこにあるかっていうと、プログラミング理論、主に構造化プログラミングのお話がベースになってます。もっと言うとUNIXという文化や哲学から来ています。もう一つはDOA(データ中心アプローチ)かな。当然オブジェクト指向設計だったりプログラミングの考え方もそうです。
プログラムする際に、サブルーチンや関数をつくる。極限までシンプルに作る。正規化された状態を作る。
ここらへんは、どちらかというと、分割するアプローチでした。
しかし、意外に分割された物を管理する視点はなかなか無いです。
分割統治が重要。 http://ja.wikipedia.org/wiki/%E5%88%86%E5%89%B2%E7%B5%B1%E6%B2%BB%E6%B3%95
なんで分割するかというと、複雑な問題を複雑なまま理解するのではなく、分割する事で、理解しやすくする為に分割する訳です。
しかし、分割して理解したからといって、そのままでは、本質的な仕事は複雑なままです。
分割された沢山の関数やAPIが用意されているからといって、これですべての問題が解決するわけではありません。
統合して、最終的な成果にする必要があります。
しかし、ここに対して、明確な回答は現在無い気がします。 いや、ある事はあるのだけれども、分割する方に比べるとフワッとした感じは否めなく、まだまだ経験のある人に頼っているのが実情かなと思います。
なので、ここの仕事は実世界では、管理職だったり、スキルの高い技術者の仕事になるわけです。まだ明文化されていないのが実情かと思います。
ただ、ヒントとしては、「パタンランゲージ」を始まりとするデザインパターン系のお話だと思っています。ユビキタス言語とかもかな。
あと、複雑さを複雑なままに放置するのではなく、表出させた後は、ゼロベースで本来実現したい事を実現する為のフローを再度見直す事も必要ですよね。ここらあたりは要件定義の領域になるでしょうか。
ここらへんの分野については、私もまだまだ勉強不足で、これからの研究テーマになるわけですが、ITの分野ではオブジェクト指向が流行り出した時期からこのテーマはみんなの話題に登り出すことが多くて、最近はアジャイル開発の広がりとともに、いろいろな人達の話題にも登るようになってきていて、きちんと勉強しないといけないなと思います。
