「プロセス」を振り返ってみよう (T3:Pt2:Ch03)
「プロセスって何? どういうこと?」が今イチぴんときていない人のために
耳慣れているが故に知らない言葉
当たり前のように耳にするが
ソフトウェアの仕事をしていると、至るところで「プロセス」という言葉に出会います。テストの領域でも当たり前のように登場しています。
どれくらい当たり前かというと、ISTQB Foundation Levelシラバスv4.0日本語訳(Version 2023V4.0.J01)を「プロセス」でgrepすると、77ヶ所(以上)に出てきます(本文以外の出現箇所も含みますが)。
$ xdoc2txt JSTQB-SyllabusFoundation_VersionV40.J01.pdf | grep プロセス | wc -l
77
それほど頻出する用語ですが、FLシラバスには「プロセスって何?」という説明は全く出てきません。
ソフトウェアテスト標準用語集のVersion 3.3までは見出し語にありましたが、3.4以降は消えています。(正確を期すと、Version 3.4, 3.6, 4.0, 4.3で見出し語にありません(Version 4.3は2024年4月22日付))
もはや、「誰もが知っている用語」「(今どき)この用語を知らない人はいないでしょ」ということなのかも知れません。
耳にはしていても、知っているとは限らない
誰もが同じ意味/概念を思い浮かべるならよいのですが、ソフトウェアの世界の外でも当たり前のように使われている言葉ですから、それぞれが思い浮かべる意味が同じである保証はありません。
特に、ソフトウェア開発にまつわる経験も知識もない人向けにトレーニングを行なう時は心配になります。
教わる側は、①自分が知ってる「プロセス」と同じ意味ってことでいいのかな、②不安だし確認したいけど、当たり前のように使われてるし、みんなも知ってる風だから、訊きづらいな、……なんてことを思いながら話を聞いているかも知れません。
教える側も不安だったので、テキストの中で丁寧に説明し、解説でも時間を割いて話したりしています。
「なんとなく判った感じでいたけど、実はちゃんとしたことは知らない……」という人のために、ここで「プロセス」というものをおさらいしましょう。
「プロセス」の定義を見てみよう
文献を辿って定義を見る
用語集Version 3.3でのプロセスの定義は、こんな風になっています。
参照しているISO 12207はソフトウェアライフサイクルプロセスの標準です。
そこで、対応するJIS規格であるJIS X 0160(2012)を見てみると、
ISO 9000、品質マネジメントシステム(QMS)が出典であることが判ります。
ISO 9000でのこの定義は「ISOマネジメントシステム規格の共通用語及び中核となる定義の一つ」([3])ということなので、ソフトウェア関連の文脈に限らず、「なにかしらの仕事とそのマネジメント」全般において共通する考え方と見てよいでしょう(まあ、あくまで「ISO的世界観」における、ですが)。
ISO 9000(JIS Q 9000)まで辿ると
もう一段潜って、ISO 9000(JIS Q 9000)を見てみましょう。
ISO 9000におけるこの定義が(本文+注記で)、「プロセスって何、どういうもの」を丁寧に説明しています(判りやすいかどうかは別)。
注記1は、これが「汎用的」な定義であることからの注釈ですね。
注記2, 3, 4を含意した「プロセス」が、ソフトウェア開発の文脈で用いられる定義です。
で、プロセスとは
「プロセス」の噛み砕いた説明
参考文献[1]~[3]での定義を踏まえて、プロセスという概念は以下のように説明できるでしょう。
プロセスとは、(大きな)仕事を、複数の構成要素(活動/作業)のつらなりとして捉えたもの
順次(連接)、分岐、反復(繰り返し)、並行を含む
構成要素(活動/作業)もプロセスと呼ぶこともある
構成要素(活動/作業)が、もっと小さい複数の構成要素のつらなりからなることもある(=プロセスは階層構造を成す)
殆どの場合、あるプロセスの入力は別の(先行する)プロセスの出力であり、出力は別の(後続する)プロセスの入力となる
なにかしらの成果物(文書や情報等)がプロセスの間をつなぐ
大概の仕事(の結果の成果物)は、たったひとつの活動や作業でできるものではなく、いくつかの構成要素(活動/作業)の集まり(連なり)からなります。
その構成要素(活動/作業)を明らかにし、要素間の連なり方や、各要素の入力/出力に着目するのがプロセスという概念と言えます。
プロセスの図式的表現
仕事を構成する活動/作業には:
順序があるものがある (順序がなく、並行して実施できるものもある)
成果物のつながりがある (必ずしも直接つながるとは限らない)
これらの関係やつながり(順序のあるものはその順序)は、時として込み入ったものになりがちですから、図を使って表すと直感的に理解しやすくなり、全体像を把握しやすくなります。
プロセス(の中のひとつの活動/作業)は下のような図で表すことが多いです(Fig.01)。
これを組み合わせると、たとえば、焼きそばを作るプロセスはFig.02のように表せます。長方形は“成果物”で、入出力のつながりを破線で表しています。並行して実施できる作業がある場合は太線で分岐を示しています。
別にこう表さなければならないという決まりではありません。
図だけでは、詳細は判らない
全体像はこのような図式で表すのが便利ですが、個々の作業――「麺を炒める」って何分くらい? とか、キャベツはどの程度細かく切るの? とか――の詳細は図では判りません。といって、こうしたことを図に書き込むと、図が読みづらくなり、最悪の場合図にする意味がなくなってしまいます。
そこで、図の他に、以下のような情報を含む資料を作成し、図と併せてプロセスの定義とすることもよくあります。
入出力定義(成果物定義)
ロール定義。当該プロセスの担当者/責任者、担当部署、etc. とその説明
プロセス詳細。各プロセスの目的、担当者(責任者)や担当部署、入力、実施事項、出力、etc.
付随する各種ルール(成果物命名規則、etc.)
プロセス定義と現実との間
ISTQBが提示する「ソフトウェアテストのプロセス」は、“モデル”です。シラバスの記述をそのまま現場で実施するには大雑把過ぎます。
組織が自分たちのプロセスを定義する場合、①実際の仕事の現状を基にしたり、②ISTQBのような“モデル”を基にしたりします。②の場合、“モデル”のうち組織に合わない部分は変更されたり取り除かれたりします。①の場合は、いくつもある仕事の共通部分を抽出したり、現状で課題のある箇所を修正したりします。
こうして作られた組織のプロセス(定義)も、“モデル”です。現実の仕事はさまざまなパラメーター(ドメイン、規模、期間、顧客の要求、etc.)があるので、定義通りには実施できない部分がどうしても出てきます。
実際に仕事をする時は、組織のプロセスをパラメーターに応じて現実に合うように変更/調整して適用していきます。
しばしば「記述されたプロセス」を現実そのものと混同してしまいがちなので気をつけましょう。
プロセスを振り返るために
仕事をしていくといつかは「自分(たち)がやっている仕事を振り返り、改善する」というテーマ(プロセス改善、業務改善)に行き当たります。
今回は、プロセスそのものを振り返るのに先立って、「プロセス」という概念を振り返ってみました。
(「焼きそばづくりのプロセス」は、「オタフクソース フライパンでつくる 本格焼きそば レシピ /作り方」を参考にしました)
参考文献・参考情報
刊行文献
[1] International Software Testing Qualifications Board,
"Standard Glossary of Terms used in Software Testing Version 3.3" (2019)[2] 日本工業標準調査会(審議), 『JIS X 0160 ソフトウェアライフサイクルプロセス』 (2012)
[3] 日本工業標準調査会(審議), 『JIS Q 9000 品質マネジメントシステム-基本及び用語』 (2015)
(2024-05-31 R001)
この記事が気に入ったらサポートをしてみませんか?