"Duration（持続時間・継続期間）"について思うこと

　連続・非連続を考えてきたついでに、"Duration（持続時間・継続期間）"について思うことを述べたい。
"Duration"を英英辞典で引くと、"the length of time that sth(something) lasts or continues"(Oxford Advanced Learner's Dictionary)とあり、「何らかのものが、（ある期間）継続・持続するまたは（動作状態がある時間まで間断なく）続く・続いている時間の長さ」という意味である。

【データ受信におけるDuration】
　私は、インターネット技術、XMLを使ったリアルタイム処理可能な企業間・企業内（注１）のデータ伝送を2000年頃から行なっているが、いろいろなことを学んできた。そのいくつかは、以前のブログでXMLを絡めて述べた（『言語としてのXML私論―企業間、企業内でのXMLの活用についてー』を参照）が、ここでは、データ伝送における受信能力をどう捉えるか考えてみたい。
　B2B（Business to Business）でのパートナー間のデータ 送受信において、大量のデータがある時間（Duration）送り込まれる場合を考えてみよう。 右図は、確定注文モデルの一例である。需要予測としてフォーキャスト情報がBuyerからSupplierに送られ、その後Buyerが確定注文を発行し、それに対してSupplierが納期回答をし、出荷して、最終Buyerから検収データをもらうというビジネス・モデルである。フォーキャストや月次検収データはバッチ処理基づく処理の場合が多いと考えられるため、1ドキュメント1品目（PN）の形をとるならば、一度に多量のドキュメントが送られてくることになる。1ドキュメント1品目（PN）の場合（注２）、取引品目が1000 品目あれば、1000 ドキュメントが送信されてくる。1秒間に10件のデータが送られてくるとすると、100秒の間この集中豪雨のようなデータを受けなければならないということになる。これらのデータは単純に受信するだけでなく、社内の仕組みに取り入れるために、社内のコードに変換・情報追加を行ない、Back-endに渡す必要がある。
当初、このような集中豪雨的なデータ受信で、私どものB2Bサーバーがダウンした。あるDurationの集中豪雨にサーバーが耐えられなかったのである。つまり、数秒間の集中的なデータに関しては想定していたが、受信側での大量トランザクション処理による高負荷対策が十分取れていなかったわけである。もちろん、送信側も送信間隔や受信失敗時の再送の一定間確保留など対策が必要だが、受信側も考え方を変える必要あったのである。カタログにあるような瞬間的な受信可能数だけでは、きちんとした受信が出来るかどうかわからない。ある継続した（連続した）時間（Duration）において、集中豪雨的なデータを受信し続ける能力が必要になるわけである。
　Throughput【単位時間当りの処理能力】×Duration【持続時間】＞必要受信能力　
を満たす必要がある。受信側の大量トランザクション処理による高負荷対策には、CPU、メモリ等のハードウェア能力の向上、ソフトウェア自体の能力を上げる必要もあるし（注３）、並列処理等の検討も考える必要があろう。また、取引件数がどのくらい増えるか当初からどのくらい予想しえるか、予想すべきかという問題もある。システムも、決していくらでもコストを使っていいわけでないので、尚更のことである。東証のシステム・ダウンも同じような課題を抱えて起こったことであろう。
　とにかく、私は上記の経験より、データの受信において、瞬間でいくら受けられるかというより、Durationという考え方を持つようになったし、物事をある一点で捉えるのでなく、Durationというある長さ、幅（期間）で考えることが大切であることを認識した。

（注１） 企業間・企業内（社外・社内）なんて区別をつけること自体ナンセンスなんでしょう。Public Lineを使うか、Private Lineを使うかや何処まで情報を開示して良いかによって、セキュリティをどう設定すべきか考える必要はあるが。
（注２） １ドキュメント複数品目（Multi-PN）の場合も考えられるが、この場合は１ドキュメントの容量が非常に大きなものとなる。つまり、相対的に小さめの容量のドキュメント（ファイル）が多数連続的に送られてくる場合と相対的に非常に大きなドキュメント（ファイル）が１つボンと送られてくる場合の二つのパタンが考えられる。今、例として挙げているのは前者の場合である。
（注３） システムによっては、相対的に小さめの容量のドキュメント（ファイル）が多数連続的に送られてくることに弱いものもあるが、逆に相対的に非常に大きなドキュメント（ファイル）が１つボンと送られてくることに弱いものもがある。システム自体の特徴を考慮して、仕組みを構築する必要があろう。

【物事の習得における持続の難しさ　－ThresholdとDuration－】
　また、何かを習得するときにも、"Duration"という概念が大切と感じている。たとえば、「プログラムを作れるようになりたい」、「英会話が出来るようになりたい」ということを考えてみよう。一部の天才を除いて、勉強し始めてすぐに、プログラムが作れるようになった り、英語が話せたるようにはならない。最初は簡単に上達するように思えても、しばらくすると、いくらやってもレベルが変わらない（上がらない）。多くの人はこの期間（Duration）がいつ終わるか分からず、嫌になってしまう。　本を何冊読めば、何時間勉強すれば、プログラムが書けるようになるかとか、何時間聴けば、何時間話せば英会話が出来るようになるということが、最初からわかっていれば、誰も悩む必要はない。つまり、それだけの時間をかけさえすれば良いわけだから。ところが、それが人によって異なり、また、その期間がどれくらいなのか分からないので、多くの人が途中で、続けることをやめてしまうわけだ。ここに物事の習得の難しさが存在する。
自分の経験から言って、ある程度の刺激を、ある期間与え続け、閾値（しきいち：Threshold）を超えないと、物事を習得することができるようにはならないようだ。しかもその閾値は人によって異なるので、ある期間（Duration）はひたすら我慢して続けることが大切である。続けていれば、必ずその一線を越えられるものだ。つまり、
　取得のための刺激（単位当たりの刺激）×期間（Duration）＞個人の閾値
になったときに、自分としても出来るようになったと感じると同時に、使いものになるものだ。
もちろん、ある程度以上の刺激が毎日（単位当たり）必要であろう。その毎日の刺激が少なすぎると、いくら続けても、反応は起こらない。また、取得時間を短縮するための触媒として、何のために取得するのかという「目的」と「論理的な思考」があると思う。（注４）

（注４）プログラムで、"Hello, World!"とか、円を書くプログラムはすぐに書けるだろうが、それで何になるのだろうか？　自分が何のためにプログラムを書きたいのか？　仕事でも、プライベートでも明確な目的・目標があってこそ、やる気もでるだろうし、何を学ばねばならないかも明確になるというものだ。また、「論理的な思考」ができないと、プログラムが組めないのは当然と思われる。言葉にしても、日本語で論理がはっきりした明確なことを言えなくて、英語や中国語で言えるわけがない。「英語」は流暢に話しているが、何を言っているのか、何が言いたいのか良くわからない人も今まで多く見てきた。

　上で、データ受信のDurationと物事を習得するときのDurationを考えた。物事を一点のみで考えるのでなく、時間の幅で考える必要があるということだ。文法で言うと、現在形（または過去形）だけでなく、現在完了形でも考えてみようということだと思う。つまり過去と現在を「つなぐ」という意味での現在完了であり、それは「飛躍」しているのでなく、「連続」しているのである。点で考えるのでなく、時間の幅で考えるということは、すなわち「連続」を意識して物事を捉えなおしてみようということに結び付いていくと私は考える。