標準プロセスのさじ加減に悩む

1988年、プロセスを定義するという話を初めて耳にして、そんなバカなこと！と思いました。仕事のやり方は自分で決める！ そう思いました。いま思えば、Leon Osterweil のプロセスプログラミングに対する誤った理解に基づいて、プロセスというものを、自由度の全くない作業指示書のように捉えていたからなのだと思います。

プロセスは基本的に入力と出力と処理からなります。要求仕様という入力からアーキテクチャ設計という出力を作る仕事はプロセスと捉えられます。ではどうやって作るの？という部分が、処理になります。処理をどれだけ細かく書くかは、プロセス定義でのサジ加減になるのですが、ここが曲者です。細かすぎると、プロセス実施者の反発を買います。私がそうしたように（笑）。

プロセスは、プログラムと同様に、様々な抽象度で書けます。二つの違いは、後者はどこかで誰かが詳細まで書かないと使い物にならないこと。でも、プロセスを実行するのは人間ですよね（ツール実行の場合もありますけど）。人間には、既に獲得された仕事のやり方があります。プログラムだって、毎回共用ライブラリモジュールを書いたりしないでしょう。プロセス定義でも、実施する人にとって当たり前のことは、いちいち言われたくないし、まして違うやり方を指定してほしくはないのです。

ではどこまで細かく書けば「良いプロセス定義」になるのか？ 当然、唯一絶対の答えはありません。どうしよう？

アジャイル開発の促進で有名な平鍋健児さんは、JASPIC 主催の SPI Japan 2016 での基調講演で、「標準プロセスは抽象度を高くしておいて、具体的なプロセスは現場が決める」と言いました。標準プロセスのあるべき姿の一面を突いていると思います。つまるところ、プロセスは仕事をする人のものであり、必要なことが実施され、かつ、仕事がしやすくなるように組み立てられていなくてはならないからです。

やるべきことはやるようにし、でも現場の裁量も確保するには、多分、標準には絶対必要なことだけを書いておいて、詳細に関しては例示やガイドを用意するという形にすべきなのでしょう。

でも、「絶対必要なこと」は、お客様や案件内容によって変わってきます。一律に決めてしまう訳にはいきません。だとすると、「必要になるかもしれないこと」を軸に、それに必要なものやことを書いておいて一つのパッケージにしておいて、それが本当に必要なプロジェクトではそのパッケージを実施するようにすれば良いかもしれません。

それでも、あらかじめ「必要になるかもしれないこと」をすべて見つけておくことは難しいでしょう。技術は進歩しますし世の中の仕組みも変わっていきます。なので、必要なことからプロセスを作る方法、つまりメタプロセスも持っておくべきであると思います。

必要な要素や条件を基に、標準セットから個々のプロジェクト向けのプロセスを組み立て、足りないところはその時に用意して標準セットに加える。これは、プロダクトライン開発でコア資産（⊂標準セット）から個々のシステムをコンフィギュアするのと同じ考え方です。標準プロセスの開発維持や展開の仕方の参考になると思っています。実際、そういうアプローチが存在します。

…なんてことを考えている今日この頃です。

ワイズワークショップ
林　好一