[使ってみようPSLX] 「仕様策定の意図を伝えることの難しさ」 JBF第29回研究会の感想

|

こんにちは、山崎です。

今回は、2008年8月1日に開催されたJBF第29回研究会にAPSOMメンバーとしてオブザーバーとして参加させていただいた感想を書きたいと思います。

少々長くなりますが、あらかじめご了承ください。

はじめに

この研究会ではS88というバッチシステムの設計のための標準を現実のプロジェクトに適用した事例の報告が行われました。そして報告された事例においてS88がどのように役に立ったか、あるいは逆にどこにギャップを感じたかが具体的かつ詳細に検討されました。

バッチプロセスの設計に実際に携わっている訳ではない私としては、残念ながら有益なコメントをすることはできなかったのですが、非常に刺激的な意見のやりとりを目の当たりにすることができました。

興味深い話題を提供してくださったプレゼンテーターの企業の方は勿論のこと、このような素晴らしい研究会を企画・運営され、外部の人間にもオブザーバーとしての参加を許可してくださった諸先生方に、この場を借りて御礼申し上げたく思います。

そういうわけで、私がこの研究会に参加して感じたことは多岐に亘りますが、ここでは特にAPSOMのメンバーとして、PSLX仕様を策定し、多くの方に使っていただくべく努力する立場からの感想を書いておきます。

S88仕様の具体的な細部にはできるだけ言及しないで書くようにしたいと思いますが、限界もあるので、必要に応じ、JBFで作成された「S88入門」、あるいはS88仕様そのもの(JIS化されていて、JIS C 1807として参照することができます)をご覧になっていただければと思います。

 

論点の私なりのまとめ

まず無理を承知で、私なりに当日の論点をまとめると以下のようになります。

  • S88ではプロセスモデル、物理モデル、手順制御モデルという3つのモデルを区別し、3つのモデルの関係を意識しつつ、設計を進めていくことになります。3つのモデルの区別は本質的で、例えば手順制御モデルと物理モデルが独立していることにより、実行処方手順と設備制御を分離して扱うことが可能になります。
  • 各モデルはその中に階層を持ちますが、階層構造は下位のモジュールの組み合わせによって上位のモジュールを構成していく、いわゆるビルディング・ブロック的な考え方を可能にするだけでなく、独立した2つのモデルそれぞれのどの階層間でリンクを持たせるかに応じて、非常に多様な生産管理方式を記述することが可能になりますが、こうした柔軟性は現場で現実にすでにある製品・設備・装置を相手に設計をする利用者にとっては、必ずしも見通しの良いものではないようです。
  • 階層は任意に利用者が設定できるものではなく、例えば物理モデルには、設備、装置、機器、計装機器といった層が識別され、それぞれについて何ができて何ができないかが標準仕様で定義されています。ところが実際に設計にあたってS88の物理モデルに現実の設備を対応づけしようとすると、なかなか一筋縄ではいかないようです。S88でも、implementation guideなどを通じ、例を挙げるなどして説明をしているわけですが、それでも判断に迷うことが多々あるようです。
  • また、物理モデルにはプラントの物理要素であるハードとそのハードに対するアクティビティである設備制御に関する業務が含まれ、それゆえその両者を包含する概念としてエンティティという用語が用いられているのですが、訳語の問題などもあって、日本語の「設備」がその両者を示すいわば多義語のような状況になっていて、そうした部分がわかりにくくなっているようです。
  • 結局、上記のような困難もあり、S88はユーザー、プロセスエンジニアや制御エンジニアを擁するプラントメーカー、DCSサプライヤといったプラント設計プロジェクトの参加者のコミュニケーションのプラットフォームとしては有益であっても、S88のモデルの意図を汲んだ設計をするのは困難である、というのが現状のようでした。

 

PSLX仕様策定の経験と照らしての感想

上記のような議論を伺って私が最も痛感したのは、仕様の意図を利用者に理解していただくことの難しさ です。

 

1.まずは使ってもらうこと

標準的な用語の提供により、当事者間の意思疎通を改善することは標準の持つ大きな意義の一つであるわけですから、S88はその点では、設計の現場で実際に効果的に使われているということができるでしょう。けれども、見方を変えれば、今回のケースでいけばプラントメーカーとDCSサプライヤが共同で、ユーザーにS88の利用を提案するというアクションがあってそれが可能になったわけで、それが可能になったのは、まさにJBFのような団体の活動があればこそであると考えられます。

翻ってPSLXの仕様の普及について考えると、APSOMが中心となって、同様の活動を進めていく必要があるということが示唆されていると私は受け止めました。

2.用語の問題

またS88を理解することそのものの難しさについては、用語の翻訳の問題が控えているようです。この点についてはPSLXはS88と逆の立場にあり、日本発の仕様を英語に翻訳して国際化していく活動を行っているわけですが、だからといって、用語定義の難しさ、ある概念を適切に指し示す用語を選択することの難しさは変わりません。

3.できあがった仕様から意図を汲み取るのは大変

更に、モデルの背後にある策定者の考え方は仕様書という形態にまとめてしまうと非常に見えづらくなる、というのは私もこれまで折にふれ感じてきたことでした。

仕様を策定する段階では、色々な可能性が出され、それらを複数のメンバーが様々な角度から吟味し、評価していきながら、時間をかけて仕様を作っていきます。けれども、出来上がった仕様を後から見ても、その仕様に辿り着くまでの紆余曲折を知ることは困難なのです。

自慢できる話ではないのですが、業務多忙で仕様策定の委員会の打合せをしばらく欠席し、ドラフトのレビュー段階から参加させてもらったことがあります。

恥ずかしながら、受け取ったドラフトを読んでもわからないことだらけで、膨大な質問リストを作成した上で、ドラフトを作成したメンバーの方々に意図を説明をしていただき、やっと議論に追いつけました。

これはパブリックコメントをしていただく方と近い立場を経験するという点で非常に有益な経験だったと思います。

4.様々なバックグラウンドを持つ人に理解してもらうには

別の視点を取り上げてみましょう。

例えば、上記のS88におけるエンティティという用語選択の背後には、オブジェクト指向的な考え方があって、それがわかれば物理要素とアクティビティの両方を包含しているという点に思い至るのはそんなに難しくはないのですが、オブジェクト指向はソフトウェアの世界では当たり前でも、それ以外の領域では必ずしも自明の考え方ではない。

PSLXは情報システムを構築するための標準であり、コンピュータの世界との関連はより密接であるとは言っても、情報システムの外部にある現実と無関係でいることはできませんし、現実に生産管理やスケジューリングシステム構築のプロジェクトの参加者は、当然のことながらソフトウェア技術者だけではありません。PSLXの仕様を読む人が、誰でも同じ背景知識と経験を持っているわけではないということを、改めて認識する必要を感じました。

5.規範なのか道具なのか

標準仕様を策定するにあたって繰り返し議論になることの一つに、標準仕様が「こうすればうまくいきますよ」という規範を示すものなのか、それとも「色々な場合に使えて便利ですよ」というモデルの汎用性、道具としての柔軟性を示すものなのか、という点があります。

勿論、現実にはその両方のバランスをどこにとるかを決めていくわけですが、概して規範としての拘束力と、モデルの柔軟性による自由度の大きさは相反するものですし、利用者によって、どちらを求めるかの重点も異なるでしょう。両立を狙ってバランスをとることが、利用者から見れば仕様としての解りづらさの原因になることも考えられます。

S88の場合にも、モデルの独立性と各モデルの階層、その間の関連付けには、規範と道具のバランスをとる工夫のようなものがあるように私には感じられます。けれども、それが解りづらさの原因となっている側面もあるように感じられました。

この点についても特効薬というのはなくて、仕様策定者が自分の目指しているものを利用者に説明する努力をしていくしかないように思えます。

 

まとめ

ということで、PSLXにおいても、仕様の背後にある考え方を仕様書とは異なったフォーマットで説明する努力をしていくことが重要であることを改めて痛感させられました。

APSOMの中でも、PSLX入門のようなドキュメントを作成することが課題に挙がっていますので、自分に可能な仕方で今後、協力していければと思いました。

以上、長くなりましたが、JBFの研究会にオブザーバー参加しての感想でした。

 

このブログ記事について

ひとつ前のブログ記事は「はじめに:NDiSと制約プログラミング」です。

次のブログ記事は「fold村散策(その1)」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。