2010/10/28ハードウェアの進歩はとどまるところを知らずに日々進化しています。最近ではコンシューマ向けにおいてもヘキサコアが登場して結構な月日が過ぎていることもあり、サーバ系のみならずどこにおいてもメニーコアな環境が一般的になったように思えます。UMPCなど比較的ロースペックな環境でさえマルチコアは割合を増やしています。このようなメニーコア環境が台頭するにつれ、重要視されてくるのが「並列化技法」ではないでしょうか。マルチスレッドなどにより並列制御を行うことは過去からも存在していましたが、利用される場面はかなり限定されていたように思えます。難易度の高い技術のため、マルチスレッドの習得にかける時間やコストをかなり要求されていたところがあるかと思います。このあたりが利用するにあたり障壁となっていたのではないでしょうか。利用される割合が低かったもう1つの理由として「業務システムにおいて有効活用できる場面が少ない」という意見を聞くこともあります。本当に業務システムでは並列化を有効活用できないのでしょうか。難しい問題ですが、わたし個人として「そのようなことはない」と考えています。業務システムでは一部にシングルユーザー向けシステムがありますのですべてとは言い切れませんが、わたし個人の感覚的に、ほとんどが「マルチ」ユーザー向けとして作成されていると思います。マルチユーザー向けであるということは、どこかで並列処理が行われる可能性が高くなるものです。それはアプリケーション上かもしれませんしデータベース上かもしれません。設計・実装者が意識できる領域かもしれませんし、意識していない領域かもしれません。データベースシステムは当然並列化が行われています。OSも並列化は当たり前のように行われています。言い換えるとこの場合は、業務システム以外がすでに並列化されている環境だと言えます。そのような環境にすでに変化している以上、業務システムであろうと並列化を上手に扱っていくことは今後必須になるのは、ほぼ間違いのないことでしょう。実際に並列処理を設計された方であればご存じと思われますが、処理を並列に動作させるには設計が非常に重要です。業務システムを主に扱う場合、必要となるケースになかなか遭遇できないことも手伝って並列に動作する処理を設計するスキルに乏しい方が、わたしも含めて多勢ではないでしょうか。用いた設計・開発ですので限定されることですが、近年になり並列化を行うことのコーディング難易度は劇的に下がっています。Frameworkに含まれた形で並列化ライブラリが標準提供されていますので、非常に簡単に利用できます。これまでも並列化を行うためにはThreadクラスを利用するなど、いろいろな方法が用意されていました。そこに新しい選択肢が追加された形になります。このように並列化を利用するためのハードルは下がり、アプリケーションがハードウェアの恩恵にあずかりやすくなりました。現実に見回してみると、かなりの数の業務システムでは並列化を有効活用できてはいないのではないかと思います。これは一体なぜでしょうか。わたし自身も業務システム構築などを行っていますので、理由についてはわたしなりの心当たりがあります。業務システムを設計する際には、プロセスを重視した設計が多く、その思考方法と並列化が相性が悪い、というところなのではないでしょうか。登録」というような流れになり、このプロセスを順番に実行していかなければならない設計を行います。各プロセスの内部で並列動作させることはできますが、プロセス自体を並列に動作させてしまうと、極端に言えば在庫引当後に在庫チェックが行われてしまう、などというおかしな状況になってしまいます。このあたりの制約が業務システム上では多いので、上述したように「業務システムにおいて有効活用できる場面が少ない」という意見が多勢なのではないでしょうか。技術的に未熟なわたしなので、目指すべき方向性についてはまだはっきりと理解できていません。それを踏まえた上で現状できることと言えば、プロセスを細かく分割し並列動作できる部分をいかに増やすか、という点に注意して設計を行うことではないか、と考えています。このあたりは有識者の方の意見をぜひ聞いてみたいところです。実際に業務システムを構築されている方はかなりいらっしゃると思いますが、世間一般的なアプリケーションと比較して業務系アプリケーションは、レスポンスなどUXが劣っているイメージを持たれていると思いますがどうでしょうか。処理量的にもそれほど多くのことは処理していないにも関わらず、想像していたよりもレスポンスが発揮されない、シンプルな形でプロセスに沿ったアプリケーションを作成しているのだけれども操作感が芳しくない。そのような場面では一度そのプロセスを見直してみるのも1つの手段だと思います。ハードウェアは時代の流れに沿うような形で進化してきました。OSやフレームワークなどミドルウェアも同様に進化してきました。あとはわたしたちが作り上げるシステムが、進化したそれらを有効に活用できるよう、今までの経験に囚われず考えたり設計手法自体を見直すなどを行い、わたしたちが合わせていく必要があるのではないでしょうか。並列化の話題はわたしたちが合わせていく必要のある多くの事柄、その中の1つなのだとわたしは思います。09:41私は並列的な業務システムを構築した経験があります。その際感じたのは「全てを並列処理用にする必要がある」という事です。プロセスはもちろんの事、要求段階から並列用の情報が必要となります。直列的な考えに染まっているのが原因で、正しい仕様書が出来ていないケースが多いです。そもそも現実は並列に起こっており、業務に並列的に行われているので、本来は並列的に物事を考えるべきだと思います。あと、プログラミングの方でもまだまだ難易度が高いようです。TPLを使えば、表面上は簡単に使えると思いますがそれが落とし穴になりかねません。無闇に使えば、パフォーマンスが下がり、酷い場合には発見し辛いエラーとなります。並列処理も他の技術と一緒で、深く知る必要があります。デザインパターンの全ての知識が必要です。並列処理の抽象化が進んでも、入口の難易度が下がっただけ、というのが実際のところだと思います。16:45並列実行するためには、適切な排他処理が必須です。そもそもDBMSのロック機能なども処理が並列に行われることがなければ必要無いですからね。>>業務系アプリケーションは、レスポンスなどUXが劣っているイメージを持たれていると思いますがどうでしょうか。業務アプリでは複数の人間が同じデータを操作する場面が多いため排他処理が一つの原因でしょう。20:12インドリさん、ベンダーSEさんコメントありがとうございます。>しかしながら、そもそも現実は並列に起こっており、業務に並列的に行われて>いるので、本来は並列的に物事を考えるべきだと思います。実業務が並列的に、という部分は私も同意です。並列ではない事の方が珍しいのでしょう。それをいかに上手くシステムとして反映させるかという点が、私達エンジニアに求められていることの一つなのだとも思います。入口の難易度が下がっている、もありますね。以前よりも全体的な難易度は下がってきているようにも感じます。それが原因として別の問題へと波及することがある、というのも同意です。>業務アプリでは複数の人間が同じデータを操作する場面が多いため排他処理が>一つの原因でしょう。排他処理が一つの原因というご意見、非常に納得でその通りだと思います。性質上マルチアクセスとなることが必然となりますので、その分レスポンスに影響を及ぼしている点はあると思います。工夫できる箇所は多いのではないか、とも思っています。個人的には「並列処理」は「業務システムにおいて有効活用できる場面が少ない」と思っています。業務システムは「平行処理」されていることが多いのではないでしょうか?「平行処理」されている部分は、マルチコアのハードに載せることで、なんの変更もなくハードの恩恵を受けます。勝手に「並列」に処理されてしまうので無理に「並列処理」を意識する必要はないわけで(^^;最近話題の「並列処理」は、CPUのハード的な限界からくる問題のソフトウェア的解決策ですね。クロック上昇に技術的な問題があり、単独コアの性能を上げるのが困難になったために、複数のコアを搭載したわけです。そのため、ソフト側で高速化させるためには、複数のコアを意識する必要がでてしまったと。長時間かかる演算を、複数のコアに分散させることで、1つのコアの演算量を減らすというのが主な「並列処理」だと思います。綺麗に分散させるには、それぞれが干渉しないようにする必要があるので、利用できる場面はさらに狭くなります。業務システムでそのような場面がどれぐらいあるか?ということですね。業務システムでは長時間演算する場面は少ないのではないでしょうか?いや、頻繁に発生するならレスポンスが悪いシステムだと思うわけで(^^;さらにいくら演算が速くなっても、I/Oが足を引っ張る可能性もありますね。長時間演算するということは、それなりのデータを扱う場面が多いんじゃないかな?そのデータがメモリ内になければ演算時間よりもI/Oの時間のほうが長いかもしれません。すると、「並列処理」させても高速化できないかもしれませんね。「並列処理」や「並列処理」自体は昔からある技術で、処理速度が必要な場面ではマルチCPUを使われていました。CPUの速度が凄い速度で上昇してそのようなハードを見ることは減っていったわけですが・・・また昔に戻っているから面白いですね。「クラウド」もクライアント/サーバーシステムに戻っていくような感じで面白いです。昔のように、タイムシェアリングシステムとかに還っていくんですかねぇ。ソフトはハード依存しないような書き方が良いという流れから、マルチコアというハード依存したものへと変化していくのも面白いです。08:14また生半可な知識で語っていますね。常識なので省略されているだけだと思います。それに、ハードウェアに合わすのだから並列処理に決まっています。それはデータの並列化で、タスクの並列化もある。処理するべきデータ量は増加する傾向にあります。経験と知識がないのに、下手に語ろうとするからそういう事になる。I/O云々言っているけど、それは誰でも考えることで、下手な設計をした結果の話しです。設計が大事なんだけどな。それに、集中と分散の繰り返しは今に始まった事ではありません。いつ来るかもわからない、単一コアの時代を待っている余裕はない。それに、単一コア化する可能性よりも、性能アップした複数個のコアを使う時代になる可能性の方が高いでしょう。なにはともあれ、「時代に合わせる」のはプロとして当たり前の事です。万が一、単一コア化の時代が来たら、またそれに合わせればいいだけの話しだと思います。12:05>処理量的にもそれほど多くのことは処理していないにも関わらず、想像していたよりもレスポンスが発揮されない、シンプルな形でプロセスに沿ったアプリケーションを作成しているのだけれども操作感が芳しくない。これは「お待ちください」を表示したまま(応答なし)になるというお行儀悪い業務アプリで日常的に見かける光景のことかーーーで、Refresh()やDoEvents()だらけのコードになるところまでがお約束。18:30ここは攻撃する場ではありませんが、>「また」生半可な知識で語っていますね。根拠を示してください。いつぞやも争ったのですか?なんで攻撃的な発言になるのでしょうか?一応物書き自称しているのですから、節度のある発言をすべきでしょうね。>話しこれ、送り仮名いらないんじゃ・・・>下手な設計をした結果の話しです。>だから設計が大事なんだけどな。すべて設計どおり、というわけにはいきません。工数と予算の兼ね合いで下手な設計をとらざるを得ない場合も多々あります。10:22この人は常に、同種の人間と党を組み・文章を読まない・知識がない・経験がない・人の話しを聞かないそのくせ人を誹謗中傷や荒らし行為を2年以上繰り返しています。並列である事と設計が大事である事も明記されています。業務システムで並列化は使えないと無茶な理論を展開しています。見苦しいので、その様な人として恥ずかしい行為は止めるべきです。>一応物書き自称しているのですから、節度のある発言をすべきでしょうね。>すべて設計どおり、というわけにはいきません。工数と予算の兼ね合いで>下手な設計をとらざるを得ない場合も多々あります。設計者も時代に合わせるべきだと思います。しないのであれば、設計者がボトルネックになります。いうよりも、要求段階から並列化について考慮しておくべきです。実際に並列化の時代が来ているのにも関わらず、学習しないから提供しないではプロ失格です。10:41兎に角、人として恥ずかしい行為で@ITを荒らさないで下さい。@ITの記事を楽しみにしている者にとって、その子供じみた行為は非常に不快です。19:33お世話になっております。編集部の岑(みね)です。コメント欄にて他者への非難に当たると思われる言動はお控えいただけますと幸いです。ご理解の程、よろしくお願いいたします。02:24面白いテーマですね。>私は並列的な業務システムを構築した経験があります。>その際感じたのは「全てを並列処理用にする必要がある」という事です。インドリさんのこちらの話に非常に興味あります。差支えなければどういった方法がいいのか見解や勘所をお聞かせ頂けますか。技術面でのマルチコアへの対応というのは私の方も思うところがあります。業務システムでの画面表示では利用できるのではないかなと思います。現状、直列に次のような処理手順になっていたとします。ユーザー入力可能この場合、画面ロードと並列でDBから取得を開始することは可能かと思われます。画面にロードしなければならないコントロールが多いほどユーザーが入力可能になるまでの時間を短縮できると思います。画面がタブで分かれているなら最初に表示されるタブとそれ以外のタブという切り口でも並列に処理させれると思います。データの取得やバッチ処理の手順を見直す、データも変化の少ない多い、マスタデータかトランザクションデータと今後は切り口をおいて再考する必要がありかもしれませんね。業務システムでは並列処理についてあまり話題にならないのでこういった場があるのは貴重だと思います。実際にマルチコアを生かすような設計、コーディング、もしくは今後こうしたいと意見を持つ人の話をお伺いしたいですね。04:46>実際に並列化の時代が来ているのにも関わらず、学習しないから提供しない>ではプロ失格です。今来ている並列化の波は意識せずとも並列化の雰囲気を味わえるしろものであって、意識して出来るものではないと思うのだけど。いうインドリさんが詳しいCPUが入ったパソコンがあります。論理で4つCPUがあります。ワンセグ付けると4つとも満遍なく使います。雨の日、VB.NETやEclipse起動すると、画面が一瞬止まります。4つのうち1個独占してくれればとまることは無いはずです。雨だから受信障害(駒落ちとか)が発生するのか、画像が乱れます。使ってないメモリは2G近くあります。小さくすれば受信障害の駒落ちも、数秒先の先読みで回避できるはずです。ゆー一般人が考えそうな仕組みは既にワンセグ見るソフトに実際に実装されているのでしょう。したら、1CPU独占じゃなくてマルチを満遍なく使うのも頷けなくはありません。Eclipse起動した時に、1つ解放して、残りの3つでやりくりしてもそう速度低下はおこりえないと思います。なんたって出たばっかりの最新CPUですから。速度は折り紙付きです。並列処理と言われるものはソフトがやっているのではなくて現状、ハードが意図的にやってるものです。勝手に並列化しちゃうから、マルチCPUの恩恵すら無い。買った本人は、CPU一杯載ってればDBは2番目、アパッチは3番目、Eclipseは4番目、OSは全体を満遍なく使う、とか夢見ちゃいます。余った1番目は当然ワンセグです。それぞれのCPUカテゴリの中でマルチスレッド・マルチプロセスどんと来いです。現実は出来の悪いCPUが一杯あるように見えるくだらんパソコンですよ。CPUとメモリをパーティションで区切ることがプログラム上で可能になれば本当のソフトウェアによる並列化時代の到来でしょう。メモリや使うCPUなんぞ考える必要無しに、ハードが仕事量に応じて適切に優先的に作業振り分けをしてくれれば。>設計者も時代に合わせるべきだと思います。自分が社長ならやりたい放題ですよね。僕は自分が社長じゃないのでしがらみが多いです。自分の意見や空想論よりも、現実問題に囚われ、縛られています。>要求段階から並列化について考慮しておくべき並列処理は並列処理を意識しなければならない局面でのみ意識すべき問題です。本当に並列させて動かす仕組みを構築するのは一人では無理。なせばなる、かもしれんけど、たぶん無理。仕事でそういうことに関わったら、意地でもやるけど;;普通にコーディングしてれば粒度の細かい部分はすべて並列処理になりますから。大局的に見ると現状並行処理でしょう。関わってる仕事内容が並列とは無縁なのも一因ですがね。スレッドにしても、意識するのは非同期ソケット通信くらいだし。>その子供じみた行為は非常に不快ですこれ、誰を指しているのですか?仮に私だとしたら心外です。面識も無い、2~3回しか書き込んだことが無い、貴方に絡んだことも今回は初めてなのに、注意しただけで子供扱いですか?馬鹿に馬鹿にされるのはしょうがないのですが、貴方が馬鹿じゃないなら謝りなさい。>・人の話しを聞かないだから「し」は要らないって。あなたの本業はあなたと身近な人しか知りません。私はWebを通した貴方の片鱗しか知りません。私が知っているのはあなたは物書きであるという部分だけです。>業務システムで並列化は使えないと無茶な理論を展開しています。うーむ、、、本文読んだけど、並列じゃなくてやっぱり並行だよね。インドリさんの提唱する並列の定義って?CPUがどーのこーのってレベルの話はしないでね。インドリさんが思う並列化を意識した業務システムって?僕の考えも、今のコンピュータ構成では、粒度の大きい並列処理は無理なんじゃないかと思う次第です。18:32Sodaさん、Choirさん、とくめいさん、ももんがさん、インドリさんコメントありがとうございます。並列と並行についてですが・・・個人的にあの定義はどうにもしっくりこないところを感じているんですよ。昨今「CPUリソース」という観点で考えることに染まってしまったのもあり、もう今ではあまり狭義に考える必要性は薄くなったと思います。クラウドの世界とかでは単位としても「1CPU≒1コア」が多いのかな、と感じています。必要に応じて仮想プロセッサ数を増やしていく事を考えると、並行も並列もあまり意識する必要はなくなってくるのかな、などと浅はかながら考えたりもします。Sodaさんの指摘にドキッとしたのは事実です。ありがとうございます。>さらにいくら演算が速くなっても、I/Oが足を引っ張る可能性もありますね。(Sodaさん)全くその通りですよね。I/O構成については見逃されていることが多いのではないか、と感じています。ハードウェア構成をしっかりしていないために発生する問題も数多いと思います。規模の大きくない企業ですと、こういった問題をかなり抱えている可能性は高いと私は思います。>それに、集中と分散の繰り返しは今に始まった事ではありません。>いつ来るかもわからない、単一コアの時代を待っている余裕はない。(インドリさん)この点非常に重要ですよね。IT業界全体としてスパイラル的に過去の技術が更に昇華してお目見えすることも多々あります。そこを考えると今後、また違う方向に進むこともあるやもしれませんが、それを待っていてはいつまでたっても何も出来ないですし。>これは「お待ちください」を表示したまま(応答なし)になるという>お行儀悪い業務アプリで日常的に見かける光景のことかーーー>で、Refresh()やDoEvents()だらけのコードになるところまでがお約束。(Choirさん)ありますよねぇ。処理を行わずに待ち状態なのだけどプロセッサ使用率を100%にしてしまっていたり・・・。私も勤め先ではよく見・・・ゲフンゲフン>すべて設計どおり、というわけにはいきません。工数と予算の兼ね合いで>下手な設計をとらざるを得ない場合も多々あります。(とくめいさん)業務として行っている以上、外的要因が関係することは非常にあると思います。わかっていても・・・というケースを出来るだけ減らすことができれば、私達エンジニアも幸せになっていくことができるとは思いますが、残念ながら非常に難しい問題ですよね。>まだまだ業務システムでは並列処理についてあまり話題にならないので>こういった場があるのは貴重だと思います。実際にマルチコアを生かすような>設計、コーディング、もしくは今後こうしたいと意見を持つ人の話を>お伺いしたいですね。(ももんがさん)私もそう思います。コメントにて提示してくださったUIのロード時における処理など、使いどころは色々あると考えていますので、先人の知恵というのを是非伺いたいと思います。今回のコラムで少し描きましたが、新しい技術により「最初の一歩がやりやすく」なったこともありますので、これからこのような話題をもっと色々な人とやりとりしてみたいですよね。18:49もう少しだけ追加します。双方が存在していると考えます。ある程度までは簡単に事が運ぶと思いますが、もう少し上を目指そうとするともっと考える必要のある箇所が出てくる。それが業務システムではまだまだあるのではないか、というところです。ハードやOSが行ってくれているだけではまだ生かし切れていないところがある、それが私の考えでした。私も企業勤めですので色々なしがらみはあります。そこで諦めていてもなんだかなぁ、という気持ちが強い変わり者です。今回の内容においても、現実社内で取り組むとした場合には「他メンバーのスキル」ですとか「予算と工数」ですとか多くの事を踏まえたうえで取り組む必要があります。一人で仕事をしている訳ではありませんので。言って何もしないのでは、どこかで回復不能な状態に陥ってしまいますよね。なりたくないので、少しでも進むことができるよう色々企んで・・・提案・進言したりする事を行うようにしています。ここを読んでくださり、なおかつコメントしてくださるような方々であれば、自分たちの環境で同じようにやっていくことができる、と私は思います。00:38並列、平行は合わせて並列と表現されていることも多いですねぇ。実際には、平行の特殊形態を並列と呼んでいると思うので、両方を表現するなら平行が正しいはずですよねぇ。日本語固有の感覚なんですかね。私自身、平行というと数学とかの線が2本並んだ状態をイメージしますし、並列というと理科の乾電池の並びをイメージします。イメージだと同時に動いてるってのは並列なんですよねぇ(^^;ももんがさんの例などは、シングルコアでも体感速度の向上を期待されて採用することもありますね。いうか、どちらかといえば、その目的で設計されることが多くて、マルチコアだから採用するということのほうが少ないような・・・サーバー側の処理はもともと平行処理が主ですし、ヘタに並列化しようとすると並行処理している分のCPUリソースを使ってしまうので微妙かなと。クラウド時代が来るなら、サーバー側の負担が増え、クライアント側の負担は減っていきますよね。クライアント側でも、工夫される部分は、並行処理がほとんどじゃないかな?並行処理はコア数を意識しなくてもいいと思うというか、意識してもしょうがないかなと(^^;結局コア数を意識して設計した、並列処理が使える部分は、限定されるのではないかと思うのですよ。最近注目を集めている1つの仕事を分散させて処理するような並列プログラムは、シングルコアでは改悪にしかならないですからねwコア数を意識するということは、そのプログラムがそのコアを占有したいということにもなります。このへん、とくめいさんが例を出していますね。結局ハード依存する並列設計というのは、イロイロな制約のもとで初めて性能を出せるのではないかと思うわけです。時代に合わせるのは大切ですが、自分のお客にとってためになる技術なのかどうかなどの判断のほうが大切ですね。お客のためだと思っていたはずが、単なる自己満足だったということは、結構あると思ったり。19:55私は業務系エンジニアで多くのCPUを明示的に使用することは今までほとんどありませんでした。いった計算処理、ゲームを作られている方には必須なのかなぐらいにしか思っていませんでした。Ahfさんのおっしゃるようにハードウェアの性能向上し、それにより言語レベルでのサポートがますます充実してきていると思います。私も同じことを感じていました。さんは意識されず活用している場面があるのではないでしょうか?目的はマルチコアを使うというよりPCのリソースを有効に活用して、処理時間の短縮やスループットの向上最終的には利用者のメリットにつながることだと思っています。それを実践していらっしゃればきっとそこには何かしらの工夫、設計のポイント、今まで取り組まれたことがあると思います。さんは意識されず活用している場面があるのではないでしょうか?これは、「コア数を意識してないけど、コアを活用している場面」ってことでいいのかな?その手のものは、2次的なことだと思うのですよ。良いハードを使えば効率もあがるってな感じです。大切なのは、同時に進んで欲しいかどうかです。先にも書きましたが、業務システムで時間がかかりレスポンスが悪い部分があるというのは操作する側からみるとイマイチなシステムですよね。もって、そのような場面ものは、できるだけ早い段階で入力が可能になるように入力と処理を分離していくわけです。いまどきの業務システムでは既にそのようになっているのではないかと・・・または、そんなことをしなくても十分な速度で処理されているのではないかと思うわけです。どちらかといえば、速度的に満足されていることのほうが多いのではないか?とも思ってます。レスポンスをあげる目的で、マルチスレッドを導入し、平行処理を行う価値がどれだけあるか?私は、体感で効果を感じなければ使う意味は薄いと考えています。データを入力し、結果が出るまでの時間が0.1秒かかるシステムだったとします。この結果を人間がみて、OKかNGかを判断していた。この場合、結果がでるまでの時間を平行、並列処理により2倍の0.05秒になったとして、どれぐらいの価値があるかというとーまぁ、ほとんど無いと思うわけです。技術者としては価値ある改良ですし、すばらしい努力結果でもあります。処理時間を2倍にまで引き上げれないですよね。使う側からみたら、その価値は皆無です。これが私の考える、技術者の自己満足です。余分な工数かけて、バグの発生率をあげた改悪とも考えられます。処理速度向上こそがお客のためになるはずだ!そして、技術者としてのステータスでもあるはずだ!・・・と思い込んでいた昔の私でもあります。コストやメンテナンス性ってのが抜けていたわけです。逆で、体感速度が大幅に上昇するのならば、コア数関係なく、検討したいとこですね。コア数を頭にいれて考えるのもありだと思います。そのパソコンでそのプログラムしか動作させないという条件がつけれるのなら、選択の幅は広がりますね。全てのプログラムがマルチコアを前提で設計されていたら・・・マルチコアを前提としていないプログラム郡のほうが効率がよかったという悲しい落ちもあるわけですw複数のコアを期待したプログラムってのは、そういうリスクもあるわけです。23:29ももんがさん、Sodaさんありがとうございます。Sodaさんの話はかなり考えさせられますね。>例えば、データを入力し、結果が出るまでの時間が0.1秒かかるシステム>だったとします。この結果を人間がみて、OKかNGかを判断していた。(Sodaさん)この例で価値が出るかどうかというのは言われるようにあまり価値がないのかも知れません。ケースバイケースというか、元々の処理時間によって価値が変動すると思います。一概に「あまり価値がない」と言われるのも少々乱暴かと。>むしろ余分な工数かけて、バグの発生率をあげた改悪とも考えられます。(Sodaさん)この点は非常に同意です。業務として開発を行う以上は、(あまり好きではない言葉ですけど)保守性を考えた上で行うのが前提としなくてはならないと思います。>みなさんそれぞれ立場は違うと思われますが、それぞれお仕事で活用できる>可能性を感じことはありますでしょうか?(ももんがさん)私は可能性を感じる、感じて欲しいと思う側です。多くの話を聞く、目にすることができるようになると「こういう使い方もできるかな?」と考えるエンジニアも増えてくると考えます(希望も込めて)個人的には仮に一つ一つが微々たる処理時間の向上であったとしても、トータルでみたときにはその合計というのがバカにできないのではないか、と考えています。1回0.1秒の処理だとして、それは一日にどの程度行われる処理なのか、一週間では?一月では?と、少し見方を変えてみる必要もあるのではないかな、等と考えています。考えないといけないことは多いので、非常に難しいと思います。私は考え続けていきたいですね。14:26私の場合、並列処理を100%意識した開発は負荷試験用ツールを作成したときくらいですね。ま、組込系の開発のときは、マルチタスクを意識したコーディングとかしてましたが。時代に合わせるといっても、よりハードウェアに近いソフトウェア技術者が意識することであって、業務アプリケーションを開発している技術者には、特に関係ないと思います。そもそも、業務自体に並列(平行?)することがないのですから。22:56遅くなりましたがCMPさんコメントありがとうございます。>業務アプリケーションを開発している技術者には、特に関係ないと思います。>そもそも、業務自体に並列(平行?)することがないのですから。現時点では私もそのように感じます。使いどころはあるとも感じていまして、全くもって利用場面がないとは思いません。個人的にワークフロー関係にも興味があるからなのかもしれませんが、業務システムでも並行・並列というのは利用できると思います。本当に業務は並列・並行に行えないのか、という疑問を抱えながら色々考えてみていますが、まだまだ方針を考えられるほど私は物を知らないのが難点です。名前を記憶しておくコメント:SpecialPRスポンサーからのお知らせPRAhf「試される大地」で働くエンジニア。貪欲に前へ進もうとやみくもに生きています。久しぶりの対面研修で思ったことよく学びよく遊びよく寝る、頭の回転が良い子供がたくさん育つ国になるといいな。新着記事SpecialPR@ITメールマガジンのお申し込み新着記事をいち早く知りたい、オリジナルコラムを読みたい――メールマガジンに登録して、@ITを120%使いこなそう。ITmediaはアイティメディア株式会社の登録商標です。