私は並列的な業務システムを構築した経験があります。
その際感じたのは「全てを並列処理用にする必要がある」という事です。
プロセスはもちろんの事、要求段階から並列用の情報が必要となります。
直列的な考えに染まっているのが原因で、正しい仕様書が出来ていないケースが多いです。
しかしながら、そもそも現実は並列に起こっており、業務に並列的に行われているので、本来は並列的に物事を考えるべきだと思います。
あと、プログラミングの方でもまだまだ難易度が高いようです。
TPLを使えば、表面上は簡単に使えると思いますがそれが落とし穴になりかねません。
無闇に使えば、パフォーマンスが下がり、酷い場合には発見し辛いエラーとなります。
つまり並列処理も他の技術と一緒で、深く知る必要があります。
OS・ハードウェア・コンパイラ・設計技法・並列処理関連のデザインパターンの全ての知識が必要です。
並列処理の抽象化が進んでも、入口の難易度が下がっただけ、というのが実際のところだと思います。

並列実行するためには、適切な排他処理が必須です。
そもそもDBMSのロック機能なども処理が並列に行われることがなければ必要無いですからね。
>>業務系アプリケーションは、レスポンスなどUXが劣っているイメージを持たれていると思いますがどうでしょうか。
業務アプリでは複数の人間が同じデータを操作する場面が多いため排他処理が一つの原因でしょう。

インドリさん、ベンダーSEさんコメントありがとうございます。

>しかしながら、そもそも現実は並列に起こっており、業務に並列的に行われて
>いるので、本来は並列的に物事を考えるべきだと思います。

実業務が並列的に、という部分は私も同意です。
むしろ並列ではない事の方が珍しいのでしょう。それをいかに上手くシステムとして反映させるかという点が、私達エンジニアに求められていることの一つなのだとも思います。

入口の難易度が下がっている、もありますね。ただ以前よりも全体的な難易度は下がってきているようにも感じます。それが原因として別の問題へと波及することがある、というのも同意です。

>業務アプリでは複数の人間が同じデータを操作する場面が多いため排他処理が
>一つの原因でしょう。

排他処理が一つの原因というご意見、非常に納得でその通りだと思います。
性質上マルチアクセスとなることが必然となりますので、その分レスポンスに影響を及ぼしている点はあると思います。

ただ、まだまだ工夫できる箇所は多いのではないか、とも思っています。

心なしか、「並列処理」と「平行処理」が一緒に語られているような感じがしますが・・・
個人的には「並列処理」は「業務システムにおいて有効活用できる場面が少ない」と思っています。

既に、業務システムは「平行処理」されていることが多いのではないでしょうか？
「平行処理」されている部分は、マルチコアのハードに載せることで、なんの変更もなくハードの恩恵を受けます。
まぁ、勝手に「並列」に処理されてしまうので無理に「並列処理」を意識する必要はないわけで(^^;

最近話題の「並列処理」は、CPUのハード的な限界からくる問題のソフトウェア的解決策ですね。
クロック上昇に技術的な問題があり、単独コアの性能を上げるのが困難になったために、複数のコアを搭載したわけです。
そのため、ソフト側で高速化させるためには、複数のコアを意識する必要がでてしまったと。
長時間かかる演算を、複数のコアに分散させることで、１つのコアの演算量を減らすというのが主な「並列処理」だと思います。
綺麗に分散させるには、それぞれが干渉しないようにする必要があるので、利用できる場面はさらに狭くなります。

業務システムでそのような場面がどれぐらいあるか？ということですね。
業務システムでは長時間演算する場面は少ないのではないでしょうか？
いや、頻繁に発生するならレスポンスが悪いシステムだと思うわけで(^^;

さらにいくら演算が速くなっても、I/Oが足を引っ張る可能性もありますね。
長時間演算するということは、それなりのデータを扱う場面が多いんじゃないかな？
そのデータがメモリ内になければ演算時間よりもI/Oの時間のほうが長いかもしれません。
そうすると、「並列処理」させても高速化できないかもしれませんね。

「並列処理」や「並列処理」自体は昔からある技術で、処理速度が必要な場面ではマルチCPUを使われていました。
CPUの速度が凄い速度で上昇してそのようなハードを見ることは減っていったわけですが・・・
また昔に戻っているから面白いですね。
「クラウド」もクライアント／サーバーシステムに戻っていくような感じで面白いです。
昔のように、タイムシェアリングシステムとかに還っていくんですかねぇ。
ソフトはハード依存しないような書き方が良いという流れから、マルチコアというハード依存したものへと変化していくのも面白いです。
これでまた、単独コアの性能が上がる技術が生まれると、「並列処理」をさせるようなコードは無駄なコードに変わるんですよねぇｗ

また生半可な知識で語っていますね。
いまさら、並列と並行なんて・・・
常識なので省略されているだけだと思います。
それに、ハードウェアに合わすのだから並列処理に決まっています。
それはデータの並列化で、タスクの並列化もある。
また、処理するべきデータ量は増加する傾向にあります。
実際に業務システムを構築していると分かる傾向だと思いますが・・・
経験と知識がないのに、下手に語ろうとするからそういう事になる。
I/O云々言っているけど、それは誰でも考えることで、下手な設計をした結果の話しです。
だから設計が大事なんだけどな。
それに、集中と分散の繰り返しは今に始まった事ではありません。
いつ来るかもわからない、単一コアの時代を待っている余裕はない。
それに、単一コア化する可能性よりも、性能アップした複数個のコアを使う時代になる可能性の方が高いでしょう。
なにはともあれ、「時代に合わせる」のはプロとして当たり前の事です。
万が一、単一コア化の時代が来たら、またそれに合わせればいいだけの話しだと思います。

＞処理量的にもそれほど多くのことは処理していないにも関わらず、想像していたよりもレスポンスが発揮されない、シンプルな形でプロセスに沿ったアプリケーションを作成しているのだけれども操作感が芳しくない。

これは「お待ちください」を表示したまま（応答なし）になるという
お行儀悪い業務アプリで日常的に見かける光景のことかーーー
で、Refresh()やDoEvents()だらけのコードになるところまでがお約束。

ここは攻撃する場ではありませんが、

＞「また」生半可な知識で語っていますね。
またの根拠を示してください。

いつぞやも争ったのですか？
なんで攻撃的な発言になるのでしょうか？

一応物書き自称しているのですから、節度のある発言をすべきでしょうね。

＞話し
これ、送り仮名いらないんじゃ・・・

＞下手な設計をした結果の話しです。
＞だから設計が大事なんだけどな。

すべて設計どおり、というわけにはいきません。工数と予算の兼ね合いで
下手な設計をとらざるを得ない場合も多々あります。

この人は常に、同種の人間と党を組み
・文章を読まない
・知識がない
・経験がない
・人の話しを聞かない
そのくせ人を誹謗中傷や荒らし行為を2年以上繰り返しています。
今回にしても、テーマは時代に合わせると明記され、
並列である事と設計が大事である事も明記されています。
それにも関わらず、この記事を「並列化と並行かを混合している」だとか、
マルチコア以前に誰でも考えるI/Oのボトルネックなどを挙げ、
業務システムで並列化は使えないと無茶な理論を展開しています。
見苦しいので、その様な人として恥ずかしい行為は止めるべきです。

＞一応物書き自称しているのですから、節度のある発言をすべきでしょうね。
私はシステム屋です。

＞すべて設計どおり、というわけにはいきません。工数と予算の兼ね合いで
＞下手な設計をとらざるを得ない場合も多々あります。
設計者も時代に合わせるべきだと思います。
そうしないのであれば、設計者がボトルネックになります。
というよりも、要求段階から並列化について考慮しておくべきです。
実際に並列化の時代が来ているのにも関わらず、学習しないから提供しないではプロ失格です。

兎に角、人として恥ずかしい行為で＠ITを荒らさないで下さい。
＠ITの記事を楽しみにしている者にとって、その子供じみた行為は非常に不快です。

お世話になっております。編集部の岑（みね）です。

コメント欄にて他者への非難に当たると思われる言動はお控えいただけますと幸いです。
何卒ご理解の程、よろしくお願いいたします。

面白いテーマですね。

>私は並列的な業務システムを構築した経験があります。
>その際感じたのは「全てを並列処理用にする必要がある」という事です。

インドリさんのこちらの話に非常に興味あります。
差支えなければどういった方法がいいのか見解や勘所をお聞かせ頂けますか。

技術面でのマルチコアへの対応というのは私の方も思うところがあります。業務システムでの画面表示では利用できるのではないかなと思います。
例えば現状、直列に次のような処理手順になっていたとします。

画面ロード→DB等からデーター取得→ 画面にデータを表示→ ユーザー入力可能

この場合、画面ロードと並列でDBから取得を開始することは可能かと思われます。
画面にロードしなければならないコントロールが多いほどユーザーが入力可能になるまでの時間を短縮できると思います。画面がタブで分かれているなら最初に表示されるタブとそれ以外のタブという切り口でも並列に処理させれると思います。

データの取得やバッチ処理の手順を見直す、データも変化の少ない多い、マスタデータかトランザクションデータと今後は切り口をおいて再考する必要がありかもしれませんね。

まだまだ業務システムでは並列処理についてあまり話題にならないのでこういった場があるのは貴重だと思います。実際にマルチコアを生かすような設計、コーディング、もしくは今後こうしたいと意見を持つ人の話をお伺いしたいですね。
みなさんは如何でしょうか？

>実際に並列化の時代が来ているのにも関わらず、学習しないから提供しない
>ではプロ失格です。

プロ失格ですか。今来ている並列化の波は意識せずとも並列化の雰囲気を
味わえるしろものであって、意識して出来るものではないと思うのだけど。
我が家には、Core-i3 というインドリさんが詳しいCPUが入ったパソコンが
あります。論理で４つCPUがあります。ワンセグ付けると４つとも満遍なく
使います。雨の日、VB.NETやEclipse起動すると、画面が一瞬止まります。
４つのうち１個独占してくれればとまることは無いはずです。
雨だから受信障害（駒落ちとか）が発生するのか、画像が乱れます。
使ってないメモリは２G近くあります。ワンセグが１G占有して、IOを極力
小さくすれば受信障害の駒落ちも、数秒先の先読みで回避できるはずです。
でも、こーゆー一般人が考えそうな仕組みは既にワンセグ見るソフトに
実際に実装されているのでしょう。だとしたら、１CPU独占じゃなくて
マルチを満遍なく使うのも頷けなくはありません。ならば、Eclipse起動
した時に、１つ解放して、残りの３つでやりくりしてもそう速度低下は
おこりえないと思います。なんたって出たばっかりの最新CPUですから。
速度は折り紙付きです。

並列処理と言われるものはソフトがやっているのではなくて現状、ハード
が意図的にやってるものです。勝手に並列化しちゃうから、マルチCPUの
恩恵すら無い。買った本人は、CPU一杯載ってればDBは２番目、アパッチ
は３番目、Eclipseは４番目、OSは全体を満遍なく使う、とか夢見ちゃいます。
で、余った１番目は当然ワンセグです。それぞれのCPUカテゴリの中で
マルチスレッド・マルチプロセスどんと来いです。

現実は出来の悪いCPUが一杯あるように見えるくだらんパソコンですよ。
ちょっと他所より速いだけ。

CPUとメモリをパーティションで区切ることがプログラム上で可能になれば
本当のソフトウェアによる並列化時代の到来でしょう。或いは、メモリや
使うCPUなんぞ考える必要無しに、ハードが仕事量に応じて適切に優先的に
作業振り分けをしてくれれば。

>設計者も時代に合わせるべきだと思います。
自分が社長ならやりたい放題ですよね。

僕は自分が社長じゃないのでしがらみが多いです。
自分の意見や空想論よりも、現実問題に囚われ、縛られています。

>要求段階から並列化について考慮しておくべき
並列処理は並列処理を意識しなければならない局面でのみ意識すべき問題
です。本当に並列させて動かす仕組みを構築するのは一人では無理。
なせばなる、かもしれんけど、たぶん無理。時間の無駄。
仕事でそういうことに関わったら、意地でもやるけど；；

普通にコーディングしてれば粒度の細かい部分はすべて並列処理に
なりますから。大局的に見ると現状並行処理でしょう。マルチスレッド。

まぁ、関わってる仕事内容が並列とは無縁なのも一因ですがね。
スレッドにしても、意識するのは非同期ソケット通信くらいだし。

>その子供じみた行為は非常に不快です
これ、誰を指しているのですか？仮に私だとしたら心外です。
面識も無い、２～３回しか書き込んだことが無い、貴方に絡んだ
ことも今回は初めてなのに、注意しただけで子供扱いですか？
馬鹿に馬鹿にされるのはしょうがないのですが、貴方が馬鹿じゃ
ないなら謝りなさい。

>・人の話しを聞かない
だから「し」は要らないって。あなたの本業はあなたと身近な
人しか知りません。私はWebを通した貴方の片鱗しか知りません。
つまり、私が知っているのはあなたは物書きであるという部分
だけです。

>業務システムで並列化は使えないと無茶な理論を展開しています。
うーむ、、、本文読んだけど、並列じゃなくてやっぱり並行だよね。

インドリさんの提唱する並列の定義って？CPUがどーのこーのって
レベルの話はしないでね。

インドリさんが思う並列化を意識した業務システムって？

僕の考えも、今のコンピュータ構成では、粒度の大きい並列処理
は無理なんじゃないかと思う次第です。

Ｓｏｄａさん、Choirさん、とくめいさん、ももんがさん、インドリさんコメントありがとうございます。

並列と並行についてですが・・・個人的にあの定義はどうにもしっくりこないところを感じているんですよ。特に昨今「CPUリソース」という観点で考えることに染まってしまったのもあり、もう今ではあまり狭義に考える必要性は薄くなったと思います。クラウドの世界とかでは単位としても「１ＣＰＵ≒１コア」が多いのかな、と感じています。必要に応じて仮想プロセッサ数を増やしていく事を考えると、並行も並列もあまり意識する必要はなくなってくるのかな、などと浅はかながら考えたりもします。

勿論Ｓｏｄａさんの指摘にドキッとしたのは事実です。ありがとうございます。

>さらにいくら演算が速くなっても、I/Oが足を引っ張る可能性もありますね。
（Ｓｏｄａさん）

全くその通りですよね。そしてかなりI/O構成については見逃されていることが多いのではないか、と感じています。ハードウェア構成をしっかりしていないために発生する問題も数多いと思います。あまり規模の大きくない企業ですと、こういった問題をかなり抱えている可能性は高いと私は思います。

>それに、集中と分散の繰り返しは今に始まった事ではありません。
>いつ来るかもわからない、単一コアの時代を待っている余裕はない。
（インドリさん）

この点非常に重要ですよね。IT業界全体としてスパイラル的に過去の技術が更に昇華してお目見えすることも多々あります。そこを考えると今後、また違う方向に進むこともあるやもしれませんが、それを待っていてはいつまでたっても何も出来ないですし。

>これは「お待ちください」を表示したまま（応答なし）になるという
>お行儀悪い業務アプリで日常的に見かける光景のことかーーー
>で、Refresh()やDoEvents()だらけのコードになるところまでがお約束。
（Choirさん）

ありますよねぇ。特に処理を行わずに待ち状態なのだけどプロセッサ使用率を100%にしてしまっていたり・・・。私も勤め先ではよく見・・・ｹﾞﾌﾝｹﾞﾌﾝ

>すべて設計どおり、というわけにはいきません。工数と予算の兼ね合いで
>下手な設計をとらざるを得ない場合も多々あります。
（とくめいさん）

業務として行っている以上、外的要因が関係することは非常にあると思います。
わかっていても・・・というケースを出来るだけ減らすことができれば、私達エンジニアも幸せになっていくことができるとは思いますが、残念ながら非常に難しい問題ですよね。

>まだまだ業務システムでは並列処理についてあまり話題にならないので
>こういった場があるのは貴重だと思います。実際にマルチコアを生かすような
>設計、コーディング、もしくは今後こうしたいと意見を持つ人の話を
>お伺いしたいですね。
（ももんがさん）

私もそう思います。コメントにて提示してくださったUIのロード時における処理など、使いどころは色々あると考えていますので、先人の知恵というのを是非伺いたいと思います。
今回のコラムで少し描きましたが、新しい技術により「最初の一歩がやりやすく」なったこともありますので、これからこのような話題をもっと色々な人とやりとりしてみたいですよね。

もう少しだけ追加します。

個人的に、並列・並行の技術については
・それほど意識しなくても恩恵にあずかれる部分
・意識しなければ有効に活用できない部分
双方が存在していると考えます。ある程度までは簡単に事が運ぶと思いますが、もう少し上を目指そうとするともっと考える必要のある箇所が出てくる。それが業務システムではまだまだあるのではないか、というところです。ハードやOSが行ってくれているだけではまだ生かし切れていないところがある、それが私の考えでした。

また、私も企業勤めですので色々なしがらみはあります。
ですが、そこで諦めていてもなんだかなぁ、という気持ちが強い変わり者です。
今回の内容においても、現実社内で取り組むとした場合には
「他メンバーのスキル」ですとか「予算と工数」ですとか多くの事を踏まえたうえで取り組む必要があります。そうそう簡単にはいきません。一人で仕事をしている訳ではありませんので。

だからと言って何もしないのでは、どこかで回復不能な状態に陥ってしまいますよね。そうはなりたくないので、少しでも進むことができるよう色々企んで・・・提案・進言したりする事を行うようにしています。

ここを読んでくださり、なおかつコメントしてくださるような方々であれば、自分たちの環境で同じようにやっていくことができる、と私は思います。

並列、平行は合わせて並列と表現されていることも多いですねぇ。
実際には、平行の特殊形態を並列と呼んでいると思うので、両方を表現するなら平行が正しいはずですよねぇ。
日本語固有の感覚なんですかね。
私自身、平行というと数学とかの線が2本並んだ状態をイメージしますし、並列というと理科の乾電池の並びをイメージします。
イメージだと同時に動いてるってのは並列なんですよねぇ(^^;

ももんがさんの例などは、シングルコアでも体感速度の向上を期待されて採用することもありますね。
というか、どちらかといえば、その目的で設計されることが多くて、マルチコアだから採用するということのほうが少ないような・・・

サーバー側の処理はもともと平行処理が主ですし、ヘタに並列化しようとすると並行処理している分のCPUリソースを使ってしまうので微妙かなと。
クラウド時代が来るなら、サーバー側の負担が増え、クライアント側の負担は減っていきますよね。
クライアント側でも、工夫される部分は、並行処理がほとんどじゃないかな？
並行処理はコア数を意識しなくてもいいと思うというか、意識してもしょうがないかなと(^^;

結局コア数を意識して設計した、並列処理が使える部分は、限定されるのではないかと思うのですよ。
最近注目を集めている１つの仕事を分散させて処理するような並列プログラムは、シングルコアでは改悪にしかならないですからねｗ
コア数を意識するということは、そのプログラムがそのコアを占有したいということにもなります。
このへん、とくめいさんが例を出していますね。

あと、クラウド化が進むと、クライアントは、消費電力が少ないシングルコアにもどるかもしれない・・・
結局ハード依存する並列設計というのは、イロイロな制約のもとで初めて性能を出せるのではないかと思うわけです。
時代に合わせるのは大切ですが、自分のお客にとってためになる技術なのかどうかなどの判断のほうが大切ですね。
お客のためだと思っていたはずが、単なる自己満足だったということは、結構あると思ったり。
まぁ、自分の苦い経験談だったりしますｗ

私は業務系エンジニアで多くのCPUを明示的に使用することは今までほとんどありませんでした。組込み系、OS、画像・動画・音声といった計算処理、ゲームを作られている方には必須なのかなぐらいにしか思っていませんでした。

ですが、Ahfさんのおっしゃるようにハードウェアの性能向上し、それにより言語レベルでのサポートがますます充実してきていると思います。私も同じことを感じていました。

みなさんそれぞれ立場は違うと思われますが、それぞれお仕事で活用できる可能性を感じことはありますでしょうか？
Ahfさんは如何でしょうか？

> どちらかといえば、その目的で設計されることが多くて、マルチコアだから採用するということのほうが少ないような・・・
Soda さんは意識されず活用している場面があるのではないでしょうか？
目的はマルチコアを使うというよりPCのリソースを有効に活用して、処理時間の短縮やスループットの向上最終的には利用者のメリットにつながることだと思っています。
それを実践していらっしゃればきっとそこには何かしらの工夫、設計のポイント、今まで取り組まれたことがあると思います。そのあたりをお聞かせ頂けませんか？

>ももんがさん
>Soda さんは意識されず活用している場面があるのではないでしょうか？

これは、「コア数を意識してないけど、コアを活用している場面」ってことでいいのかな？
その手のものは、2次的なことだと思うのですよ。
より良いハードを使えば効率もあがるってな感じです。
大切なのは、同時に進んで欲しいかどうかです。

先にも書きましたが、業務システムで時間がかかりレスポンスが悪い部分があるというのは操作する側からみるとイマイチなシステムですよね。
でもって、そのような場面ものは、できるだけ早い段階で入力が可能になるように入力と処理を分離していくわけです。
いまどきの業務システムでは既にそのようになっているのではないかと・・・
または、そんなことをしなくても十分な速度で処理されているのではないかと思うわけです。
どちらかといえば、速度的に満足されていることのほうが多いのではないか？とも思ってます。

レスポンスをあげる目的で、マルチスレッドを導入し、平行処理を行う価値がどれだけあるか？
私は、体感で効果を感じなければ使う意味は薄いと考えています。

例えば、データを入力し、結果が出るまでの時間が0.1秒かかるシステムだったとします。
そして、この結果を人間がみて、ＯＫかＮＧかを判断していた。
この場合、結果がでるまでの時間を平行、並列処理により2倍の0.05秒になったとして、どれぐらいの価値があるかというとー
まぁ、ほとんど無いと思うわけです。

技術者としては価値ある改良ですし、すばらしい努力結果でもあります。
なかなか処理時間を2倍にまで引き上げれないですよね。
でも、使う側からみたら、その価値は皆無です。
これが私の考える、技術者の自己満足です。
むしろ余分な工数かけて、バグの発生率をあげた改悪とも考えられます。

処理速度向上こそがお客のためになるはずだ！
そして、技術者としてのステータスでもあるはずだ！

・・・と思い込んでいた昔の私でもあります。
コストやメンテナンス性ってのが抜けていたわけです。

まったく逆で、体感速度が大幅に上昇するのならば、コア数関係なく、検討したいとこですね。
もちろん、コア数を頭にいれて考えるのもありだと思います。
そのパソコンでそのプログラムしか動作させないという条件がつけれるのなら、選択の幅は広がりますね。

でも、全てのプログラムがマルチコアを前提で設計されていたら・・・
マルチコアを前提としていないプログラム郡のほうが効率がよかったという悲しい落ちもあるわけですｗ
複数のコアを期待したプログラムってのは、そういうリスクもあるわけです。

ももんがさん、Ｓｏｄａさんありがとうございます。

Ｓｏｄａさんの話はかなり考えさせられますね。

>例えば、データを入力し、結果が出るまでの時間が0.1秒かかるシステム
>だったとします。そして、この結果を人間がみて、ＯＫかＮＧかを判断していた。
（Ｓｏｄａさん）

この例で価値が出るかどうかというのは言われるようにあまり価値がないのかも知れません。ケースバイケースというか、元々の処理時間によって価値が変動すると思います。ですので一概に「あまり価値がない」と言われるのも少々乱暴かと。

>むしろ余分な工数かけて、バグの発生率をあげた改悪とも考えられます。
（Ｓｏｄａさん）

この点は非常に同意です。業務として開発を行う以上は、（あまり好きではない言葉ですけど）保守性を考えた上で行うのが前提としなくてはならないと思います。

>みなさんそれぞれ立場は違うと思われますが、それぞれお仕事で活用できる
>可能性を感じことはありますでしょうか？
（ももんがさん）

私は可能性を感じる、感じて欲しいと思う側です。
もっともっと多くの話を聞く、目にすることができるようになると「こういう使い方もできるかな？」と考えるエンジニアも増えてくると考えます（希望も込めて）

個人的には仮に一つ一つが微々たる処理時間の向上であったとしても、トータルでみたときにはその合計というのがバカにできないのではないか、と考えています。１回0.1秒の処理だとして、それは一日にどの程度行われる処理なのか、一週間では？一月では？と、少し見方を変えてみる必要もあるのではないかな、等と考えています。

考えないといけないことは多いので、非常に難しいと思います。
でも、私は考え続けていきたいですね。

私の場合、並列処理を１００％意識した開発は負荷試験用ツールを作成したときくらいですね。
ま、組込系の開発のときは、マルチタスクを意識したコーディングとかしてましたが。
時代に合わせるといっても、よりハードウェアに近いソフトウェア技術者が意識することであって、業務アプリケーションを開発している技術者には、特に関係ないと思います。
そもそも、業務自体に並列（平行？）することがないのですから。

遅くなりましたがCMPさんコメントありがとうございます。

>業務アプリケーションを開発している技術者には、特に関係ないと思います。
>そもそも、業務自体に並列（平行？）することがないのですから。

現時点では私もそのように感じます。ただ使いどころはあるとも感じていまして、全くもって利用場面がないとは思いません。個人的にワークフロー関係にも興味があるからなのかもしれませんが、業務システムでも並行・並列というのは利用できると思います。

本当に業務は並列・並行に行えないのか、という疑問を抱えながら色々考えてみていますが、まだまだ方針を考えられるほど私は物を知らないのが難点です。