granularity

職場で、granularityという単語が話題になりました。とあるドキュメントの翻訳作業をしている同僚から、granularityをどう訳すか？という質問を受けました。

即座に、granularityはとりあえず“粒度”という訳語があたるのでは、と答えたのですが、どうもしっくりきませんのでディスカッションが始まりました。

辞書を見ると一般に、“粒度”といった訳語が載っているこの単語、なかなか手ごわいです。

恐らくは物理学や工学の分野で主に使われてきたと思われる用語ですが、近年では様々な分野に使われて、単に物事を捉える場合の大小や程度（レヴェル）を指すのに用いられていると思われるふしがあります。

プロセスエンジニアリングの世界では、対象となる個々のプロセスの“細かさのレヴェル”を“Granularity（粒度）”という言葉で表現しています。

下記出典は、コンピュータサービスのGranularityについて記述したものです。抽象概念について、そのレヴェル（程度）の大小を表すのにGranularityという単語が使われている例と思われます。

原文
The word granularity is used in a number of different ways in SOA discussions. In this discussion of service design we consider the granularity of the services themselves, that is, the number of operations a service should have.

There can be no simple heuristic for determining service granularity. Rather, we offer two examples of factors that you should consider when designing services:
Services will usually be the unit of testing and release. If granularity is too coarse, if we group together a large numbers of operations in a single service, then we will tend to increase the number of consumers for the service. Hence if we make amendments to some aspect of a service, perhaps for the benefit of only a subset of consumers, we must re-release the whole service and hence potentially impact all consumers.

One challenge for the service consumer is to find the correct operations. Typically the consumer needs to browse a list of services and, having identified a suitable service, the list of service operations. We suggest that extremes in service granularity -- either many services with few methods, or few services with many tens or hundreds of operations -- will tend to impede consumability.

This indicates that in selecting service granularities we are likely to be trading off factors such as maintainability, operability and consumability. Any given SOA should provide guidance to service designers as they consider such trade offs. (SOA realization: Service design principles. David J.N. Artus)


和訳
SOAに関する解説の中で、『粒度（granularity）』という言葉は、幾つか別々な意味で使われます。サービス設計に関するこの記事では、サービスの粒度そのもの、つまり、ある1つのサービスが行いうるオペレーションの数について解説します。

サービス粒度を決定するために使用できるような単純な経験的方法はありません。代わりにここでは、サービスを設計する際に考慮すべき要因として、下記の2つの例を挙げます。

サービスは通常、テストとリリースの単位です。粒度が粗すぎると、多数のサービスを1つのグループにした場合、そのサービスに対するコンシューマーが増加しがちです。そのため、サービスの一部のみに修正を加えたい場合（例えばコンシューマー全体のうちの、一部のサブセットのみを修正する、など）、サービス全体を再リリースしなければならず、その結果すべてのコンシューマーに影響を与えてしまう可能性があります。

サービス・コンシューマーが直面する困難の1つは、正しいオペレーションを見つけることです。通常、コンシューマーは、サービスのリストをブラウズする必要があります。そして適切なサービスが特定できたら、今度はサービス・オペレーションのリストをブラウズする必要があります。極端なサービス粒度、つまり数多くのサービスがわずかなメソッドしか持たないサービス粒度や、あるいは、わずかなサービスが何十、何百ものオペレーションを持つようなサービス粒度は、使いやすさを制限しがちなことを助言として挙げておきます。
これはつまり、サービス粒度の選択に際して、維持管理の容易性やオペレーションの容易性、利用の容易性などといった要因をトレードオフしなければならないことを示しています。どんなSOAであっても、サービス設計者がそうしたトレードオフを考慮できるよう、指針を提供する必要があります。