マネジメントシステムにソフトウェアの派生開発手法を適用して国際規格改訂に対応する

本記事は、以下のカンファレンスおよびシンポジウムで発表した内容を、口頭説明が無くてもわかるように「読み物」として編み直したものです。

・ 派生開発カンファレンス2018
    https://affordd.jp/conference2018_program.shtml
・ JaSST'18 Tokyo
    http://jasst.jp/symposium/jasst18tokyo/report.html

その際、次の方針で臨みました。

・実践のための内容に絞り、手法の比較や評価については必要最小限の記載に留める。
・「ソフトウェアの開発に携わったことなどない。ましてやその領域の技法であるXDDPとかUSDMとか、そんなの知らないどころか聞いたこともない。」という方にもわかるように心掛けました。

概要

法規制や国際標準規格等は次々と追加／改訂されていきます。各企業等においては、それに応じて組織標準の業務規程、マニュアル、SOP (Standard Operating Procedure)、ガイドライン等の文書の改訂が必要になります。
この作業を抜け漏れない品質で効率よく実施しようと工夫する中で、この取り組みが、以下の図に示すように、マネジメントシステムの派生開発になっていると気がつきました。

そこでソフトウェアの派生開発手法の一つの効果的アプローチとして人気のあるXDDP（eXtreme Derivative Development Process）が提供する技法であるUSDM(Universal Specification Describing Manner)を主に、このアナロジーを積極的に活用した方法論を考案し、実践してみたところ、期待した効果が得られました。

実践の場となった活動は一般社団法人IT検証産業協会(IVIA)に元々存在した協会組織における標準文書「IT検証標準工法」に、後に発行された国際標準規格(ISO/IEC/IEEE29119)を採り入れるためのものでした。
しかし、考案した方法論は特にこの国際標準に特化した部分は全くありません。ISO9000やCMMIなど、他のマネジメントシステム等についても適用可能な汎用性のある方法論になっており、広く参考にして頂けるものと思いますので、ここで紹介することにします。

課題の確認

既存の組織標準と採り込みたい国際標準規格の間でフレーム(文書体系や構成)の切り口が違ってしまっていることは良くあることだと思います。
これが作業を厄介なものにします。簡単に対応が付くように切り口を合わせてしまいたいところですが、それは出来ないと思った方が良いでしょう。
組織は既存の組織標準に則って活動しているわけですから、内実に変更が無い部分についてまで標準文書の構成を変更することで、余計な混乱を招くようなことはしたくないはずです。また、適合しなければならない規格がたった一つということはまず無く、複数の規格等に同時に適合しなければならないことが普通で、規格のどれかに合わせてしまえば解決するというものでもありません。
結局、組織標準と複数の国際標準規格等との間で、双方の対応関係を上手く管理しないと、改訂の度に大変に非効率な作業が発生してしまいます。そればかりではなく、要求事項に対する抜け漏れも発生し、組織標準の品質、ひいてはそれに従った全ての実務内容に問題が生じてしまうことになってしまいます。

また、改訂の際にある部分に手を付けようとした時に、「そこは〇〇規格の要求事項に対応するための実装だから、変更するなら代わりの実装が必要になる」といったような過去の経緯を教えてくれる知見者が居るうちは良いですが、それはいつまでも続くわけでもないと思った方が良いでしょう。
それゆえ属人性を排し、抜け漏れが起きにくく、効率的に管理できる方法論を確立させておくことが望まれます。

前準備）国際規格の読み方のポイント

例えば認証制度のあるISO9001やISO14001の認証を取得したい場合は、規格の要求事項をもれなく満たさなければなりません。
それらの規格の中では、用語として「shall（しなければならない）」は要求事項、「should（するのが望ましい）」は推奨事項を表すものとして使われます。

多くの皆さんには馴染みのない規格だと思いますが、ISO/IEC/IEEE29119から実例を見てみましょう。

上の表の1行目の7.3.4.2 a)の文には「shall」が含まれており、これにより「テスト測定量は収集され記録されなくてはならない。」は要求事項として明示されていることがわかります。

中には下表に示すように、一つの項の一文の中に、「shall」と「should」が混在するものもあります。

方法論紹介

それでは方法論の説明に入っていきます。

「組織標準の文書改訂活動は、マネジメントシステムの派生開発である」と位置付けて、ソフトウェアシステムの派生開発とのアナロジーを積極的に活用します。
具体的には以下の図に示すような手順で作業を進めます。

各ステップ毎に中間成果物をレビューします。品質の維持ということだけではなく、手戻りなく効率的に進めるという意味でもこれはとても大事なことです。各ステップでレビューの観点は重ならないので無駄なことは一つもありません。
属人性を排し、中間成果物の形も揃うので、レビューそのものも実施し易くなっているはずです。ぜひ実践されることをお勧めします。

さて、早速各ステップの作業内容の説明に入りたいところですが、その前にもう少し準備が必要です。
今回使用する特徴的なツールについて、必要最小限の説明で先に紹介することにします。
(既によくご存知の方もいらっしゃると思います。その場合は、「どの部分の特徴を活かしたのか」という観点で見て頂ければと思います。)

まず、今回紹介する方法論で最も特徴的なのは、改訂分の要求仕様書を作成すること、それもUSDMに従って作成する点だと思います。
「そんな面倒なことはしていられない」と思う方もいらっしゃるかもしれませんが、ちょっと待ってください。多分、これと似た作業はいつもやっているものと思います。
改訂にあたり、差分を説明するための文書を作ったり、抜け漏れチェックのための作業シートを作成したり、いろいろ付随する作業をやっているはずです。要求仕様書は、それに相当するものになるはずです。
このような作業を属人的なやり方に頼るのではなく、ソフトウェアの派生開発の世界で実績のある手法を採り入れる形で標準化してしまおう、という試みです。
つまり、いつもやっていることのやり方にちょっとした工夫を加えよう。USDMと呼ばれるマナーを採り入れてみよう。その程度のことだと思っていただければよいと思います。

さてそこで、まずはこのUSDMについて、今回活用した特徴部分に絞って紹介します。
清水吉男氏が提唱したもので、書籍の中で以下のような形式がテンプレートとして示されています。

清水吉男，『[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術』技術評論社，2010,  p.376 【付録】要求仕様書テンプレート より

このテンプレートを見ればわかる通り、「要求」と「仕様」を階層構造で表現するものです。
清水氏は以下のような説明をしています。

・要求とは依頼者が求めている“ソフトウェアで実現して欲しい動作（処理）”のことです。USDMでは、依頼者が求めているソフトウェアの動作の一連の流れ、すなわちソフトウェアの“振る舞い” を 文章にして表現します。
・要求には仕様を導出するという非常に重要な役割があります。
・仕様は、要求に含まれる動詞およびその目的語から導かれます。
・仕様とは、要求を満たすあるシステム／対象の外部から見た振る舞いや特性(非機能要素)を特定・規定するものです。
　・要求を満たすシステムは一通りとは限らない
　・要求に対応する仕様は一つとは限らない

ここで、国際規格等で十分に注意しなければならないのは要求事項である、ということを思い出してください。「shall」を含む文は、明確に要求事項を表すのでした。
さて、先の清水氏のUSDMの説明の「依頼者」を「規格」に、「ソフトウェア」を「マネジメントシステム」に、「要求」を「要求事項」に、「仕様」を「（組織及びその活動への）実装」に置き換えて読み直してみてください。特に違和感なく読めると思います。
USDMの特徴と整合性が良いことがわかります。

「要求事項」には必ず応えなければなりませんが、「実装」については、場合によっては（少なくとも規格に適合するためというだけであれば）他のやり方でも問題ないわけです。
さらに、このテンプレートを詳しく見ると、「要求」項目について、要求本体と、「理由」や「説明」を区別して記載するようになっていることがわかると思います。
この考え方も非常に役立ちます。
規格の文書には、背景の説明があったり、用語を定義したり、目的を示したり、他の項目との関連性を説明したり、事例を示したり、といったいろいろなことが記載されています。
それらの中に「要求事項」が埋もれてしまうので、十分に注意しないと見落としが発生しかねません。
それに対して、USDMでは「要求」項目に要求事項そのものだけを記載し、リスト化するので、チェックリストとしても使用でき、見落としを防ぐことができます。

さて、「要求事項」が重要であることはもちろんですが、その一方で、その「仕事を実施する理由」「目的・目標」を伝えることも大切です。そこで、それらの情報は「理由」の項目に残します。この方法によって効率良く内容を整理でき、その後の見通しも良くなり、抜け漏れ無く品質が保証できるものを効率良く作成できます。

もう一つ、USDMの重要なマナーの一つで、ここでも大変有効に活用できるものがありました。それは先のテンプレートの中に項目別に情報を分けて納める、というようなこととは異なり、要求本体の表現の仕方に関する次のマナーです。

USDMでは、やってほしいことを「要求」と呼び、それが必要な「理由」を明記します。
「要求」には目的でなく、“振る舞い”を文章で表現します。
“振る舞い”を文章で表現するときは、動作を目的語と動詞のセットにします。
要求中に含まれる動詞をすべて書ききります。そして目的語と動詞をセットにします。
具体的には「～を～し、～を～し、… ～を～する。」と表現します。

「開始イベント」は、例えば「役割/責任の割り当て」に対応します。

このマナーがどうして有益なのかというと、最初に確認した課題の一つに上手く対応できるからです。
規格の一項目は、その規格の中では一纏まりのものとして全く自然なものに見えます。しかし、取り込み先の既存の組織標準のフレームの切り口から見ると、しばしばいくつかの別のことが混在した大きな固まりに見えます。
この場合、切り口を合わせるよりも、固まりを分解してそれぞれ相応しい場所に納めた方が全体の体系の統一性を維持できます。
実際、複数の規格を取り込まなくてはならないことも多く、その全てに切り口を合わせることなど出来ないと思った方が良いでしょう。
では、どういう方針で分解すれば良いのでしょうか？
ここで先のマナーが活用できるのです。
マナーの適用により出来上がった目的語と動詞の対が、使い勝手の良い分解の単位になるのです。

手順説明

さてそれでは先に示した手順のそれぞれのStepについて説明していきましょう。

Step1) 規格等から今回改訂分の要求仕様書に必要な情報をUSDMの構造として抽出

まず、規格の要求事項を漏れなく抽出することが重要です。「shall」を含む文を抜き出して、「要求」の項目に書き写します。

Step3で必要になるので、その「要求」を何処から抽出したか(規格の項番等)、備考欄にでもメモしておくと良いでしょう。（規格が要求していること自体も「理由」の一つと考え、「理由」の項目に規格名や項番等を記載しても良いと思います。その場合は別の「理由」も書きます。「理由」は一つでとは限りません。）
同時に「要求」の「根拠」となる記述を探し、「理由」の項目に書き写します。
「要求」を正しく理解するために必要と思われる説明があれば、「説明」の項目に書き写します。「説明」の項目内容については、無理に探す必要はありません。必要が無ければ空欄で良いでしょう。

以下の具体例で見てみましょう。「shall」の入った文が、例えば５つあったとします。

これをそのまま5項目の「要求」として書き写し、「根拠」となる記述等を探して書き写すと、以下のようになります。

要求事項を満たすためにどのようなことを実行すれば良いのか、その事例が示されているような場合もよくあります。そのような情報はその要求事項を書き写した「要求」項目の直下の「仕様」の項目に書き写します。

「should」が含まれる推奨事項をどうするかですが、事例と同様の扱いで最も関連の深い「要求」項目の直下の「仕様」の項目に書き写すと良いかと思います。
経験的に感じていることですが、推奨事項は推奨と言いながら、結局要求事項を満たすためにはやらなくてはいけないことになることが多いように思います。
ただし、別のやり方でやれるのであればそれで構わない、ということなのだと思います。
監査目線で考えてみると、要求事項の方だけチェックすれば、結局推奨事項として示された、あるいはそれに相当する活動が為されたかも同時にわかってしまう、そんな関係になっていることが多いように思います。
ですから、上記したように「仕様」の項目に置くのが相応しいものが多いのではないかと思います。
これで、規格の記載について「要求」「理由」「説明」「実装例」を分別し、USDMの構造として抽出できます。

注意）改訂にあたっては、今回作業分だけを抽出するのが基本です。ですから、規格の方からも今回の改訂分だけの差分情報を抜き出せば良いはずです。
また、この手法を２回目以降に実施するときには、Step4で示す通りのやり方をしていれば、既存の要求項目については既に組織標準文書の方にそのタグ情報が入っているはずなので、抜け漏れなく入っていることや、どこに入っているかを簡単に確認できるはずです。
しかし、この手法を適用する初回は、既存部分についてタグ情報が付加されていないことから、全体を一度見直す意味もあり、規格全ての要求事項について抽出して実施した方が良いかもしれません。

Step2) 「要求（要求事項）」の文をUSDMのマナーに従った形式に書き換える

「要求（要求事項）」に含まれる文を“振る舞い”を表す文に書き換えます。
抜け漏れが起きないように 「要求（要求事項）」に含まれる“振る舞い”の全てについて、“目的語と動詞の対”の並びで書き切ります。

先の具体例で、書き写した文を“振る舞い”を表す文に書き換えた図を以下に示します。

このときに、もしも「目的」等のような「要求」とは別の情報の混入に気付いたら、その情報は相応しい項目に移します。

Step3) 「要求（要求事項）」を部品化し、「要求」の出処（情報源）を埋め込む

“目的語と動詞の対”毎にタグで囲い、分解した部品にします。

「タグって何ですか？」という方もいらっしゃると思います。順番に説明します。
今、「要求」に書かれている文は、次のような“目的語と動詞の対”の並びの表現になっているはずです。

～を～して、～を～して、～を～して、…、～を～する。

これを“目的語と動詞の対”毎に分解した部品にします。何処から何処までが一つの部品かわかるように囲みます。何を使って囲むかですが、"（ ）"でも良いですし、"「 」"でも良いと思います。
"〔 〕"を使って分解してみましょう。次のようになります。

〔～を～して、〕〔～を～して、〕〔～を～して、〕…、〔～を～する。〕

さて、このようにすれば、分解には困らないのですが、もう一つやりたいことがあります。それは各部品に名前のようなものを付けておきたいのです。なぜなら、次のStep4で、ここで分解した部品はそれぞれ別の場所に行く可能性があります。行った先で、これらの部品が何処から来たのかを知りたいからです。

"〔 〕"のような囲いには名前が付けられません。今、"XXX"という名前を付けたい場合、どうしたらよいでしょうか？
ここで登場するのがタグです。いろいろやり方は考えられるでしょうが、ここではWEBページを記述するときのやり方に倣い、以下のようなものを使います。

先の"〔"の代わりに"<XXX>"、"〕"の代わりに"</XXX>"のようなものを使います。こうすれば名前を入れることができます。
さて、どんな名前を付けるのが良いかといえば、情報源の規格やその項番がわかる名前が付いていると良いでしょう。
ここではもう一工夫して、次のようなタグを使うことにしています。

先の"〔"の代わりに"<ISrc id="XXX">"、"〕"の代わりに"</ISrc>"を使います。

結局、以下のようになります。

<ISrc id="XXX">～を～して、</ISrc> <ISrc id="XXX">～を～して、</ISrc> <ISrc id="XXX">～を～して、</ISrc> …、<ISrc id="XXX">～を～する。</ISrc>

ISrcは情報源(Information Source)を意味するシンボルとして導入し、名前はidの所に移しました。
この方がコンピュータプログラムで自動処理する際に何かと都合が良いのでそうしただけで、他のやり方でも良いと思います。とにかく部品の範囲がわかることと、それに情報源の名前が付けることができれば良いわけです。

さらに、同じ情報源で分割した何番目かを表すもう一つの名前を付けることもできるでしょう。
そこまでしなくても、後々、行った先での部品の数を数えるだけでも抜け漏れをチェックすることができます。

以上、ここまでがUSDM形式での要求仕様定義、つまり作業対象は要求仕様書でした。
下の図で確認してみてください。

ここからいよいよ組織標準文書を作業対象とした改訂に入ります。改訂する文書は元々ある組織標準文書ですから、それがどのような形式のものであるのかはそれぞれの組織によることになります。
ここで例示するものは、少し厄介なことになるので気を付けてください。何が厄介かというと、実はこれもUSDMの形式の文書になっているのです。（何で組織標準文書の方までUSDM形式なのかについては、後ほど説明します。）
先の要求仕様文書と混同しないようにして欲しいのです。また、例示においてUSDM形式の組織標準文書が選ばれているだけで、残りのStepの作業対象である文書の形式は実は何でも良い、と理解しておいてください。

Step4) 改訂対象の派生開発（必要に応じてリファクタリング）

改訂対象の文書にStep3で作成した部品を埋め込み、書き換えていきます。

以下の図の例は、元々の組織文書をUSDMの形式にしたものです。赤文字がStep3までで作成した部品で、 その部品を組織文書の中に埋め込んだ形になっているのがわかると思います。埋め込む場所によっては、日本語として自然なものになるように、語尾を少し調整する必要があるかもしれません。

最終的に、タグ情報は削除して、表ではなく文書形態にしたものを正式版としなければならないと思います。しかし、改訂を担っている組織の内部的にはタグ情報が入っているこれがオリジナルなるだとした方が、何かと都合が良いように思います。

注意） この手法を実施した２回目以降は、国際規格等の改訂時の差分以外、つまり元の規格から存在する要求事項に対応する内容は、既に埋め込まれているはずだということになります。そのタグ情報も既に入っていて、すぐに見付けることができるようになっているはずです。
しかし、初回は全てにタグ情報が未だ付いていないので、既存のはずの部品についても、それに相当する内容が何処に記述されているのかを文の意味を頼りに探し出し、そこを部品で置き換えるか、相当する部分にタグを付けるなどの処置を行う必要があります。

Step5) 組織の実情に合わせて要求を満たす仕様（実装方法）を決める

要求を満たす仕様（実装方法）を決めて、記載します。このとき、その実装方法を何処に記載するかについて、方針を明確化しておくと良いでしょう。何の方針のことなのか、わかり難いかもしれませんので、以下にもう少し詳しく説明します。

要求事項に対応する実装方法については、それが単に例示に過ぎないのか、その通りにやって欲しいのか、利用者が区別出来る必要があります。テーラリングをして良い範囲、その境界線が明確になっていないと困ってしまいます。

一つのやり方としては、以下のような方針があるでしょう。

・国際規格から見たら要求事項ではなく、単なる一実装方法であることでも、当該組織標準としてその通りにやって欲しい実装方法であれば、要求側に記載する。
・例示などは仕様側に記載する。

それとは別で、「組織標準として必ずその実装方法でやって欲しいことなのだが、あくまでそれは現時点での一実装方法に過ぎないので、要求側には書きたくない」という考え方もあるでしょう。
その場合は仕様側に実装方法を記載することになるので、その中で必ずその通りにやるべきものと、テーラリングして良いもの、単に例示に過ぎないもの、そういった区別がつくように、何か印をつけるなどの工夫を採り入れる必要があるでしょう。

ところで、組織標準としては、必ずしも実装を全て規定する(具体化する)必要はないので、無理に「仕様」の項目を埋めるようなことはしなくて良いです。テンプレートなどを用意すると、必ず何か埋めなくてはならないと誤解されることも多いので、「説明」の項目と「仕様」の項目は必ずしも必要ないことを、しっかりと共通認識としておくのが良いと思います。

結果

当たり前ですが、手順について迷うことがなくなると、本質的な作業に集中できます。また、中間成果物の形が揃ったので、レビューが進めやすくなるだけではなく、ツールも簡単に作成することができ、自動化も進みました。（タグを取り除いたり、各行のタグの名前を別の列に抽出したり、その情報に基づいて規格と組織標準の対応表を生成したり、Excelの表になっているUSDMをWordの文書形式に変換したり、そのようなツールを作成して使用しました。)
この方法論が確立してからは急速に作業効率が上がりました。

作成した要求仕様書は、作業用中間成果物に過ぎないように見えてしまうかもしれませんが、改訂前後の正確な差分情報なので、これ自体がいろいろと役立ちます。

また、USDMで作成してあるので、「要求(要求事項)」「理由(根拠)」「説明」「仕様(実装例)」が明確に分けられています。活用の場面に応じて重視して読むべき部分をすぐに見つけることができます。
「要求(要求事項)」のリストだけを見ていけば、新たにやらなければならないことの全体像が明確にわかります。
その要求事項の詳細についても、必ずやるべき事と出すべき成果が、「動詞」と「目的語」の対の並びで明確に表現されているので、抜け漏れ防止に役立つでしょう。
「理由(根拠)」の項目も、正しい理解をして確実に実行してもらうためには必要です。一般にも業務標準や業務マニュアルにおいて、その「仕事を実施する理由」「目的・目標」を伝えることは、とても重要なことであると指摘されています。

以上のように、この見易さは大変に魅力的です。そこで、我々はこの派生開発における成果物（改訂対象の組織標準文書）そのものも、まずはUSDM形式でまとめることにしたのです。
ここで、標準文書の使われ方をもう少し丁寧に考えてみましょう。実は下図のように規格と同じような形で活用されることも多いはずです。

上図のような認識から、改訂対象文書の方もまずはUSDM形式でまとめることにし、そこから通常の文書形式のものを自動生成するようにして、以下のように双方の形式を公開することにしました。

IT検証標準工法ガイド_Ver.2.0
https://www.ivia.or.jp/item121

このための作業についても自動化を進めました。USDM形式のExcelファイルから一度markdown形式を出力するツールを作成し、さらに既存のpandocというツールを呼び出してWord文書形式に自動変換するツールを作成して処理しました。2つの形式を作成することになりましたが、それほど手間がかかるようにはなっていません。
内容を理解するためにWord文書形式で読んでもらい、作業に入ったらExcelファイルの方をチェックリスト的に使う、といった運用が出来るようにしてあります。