あいそるニュース

クローズアップ　生命保険、シンプルに　滞納による契約解除に注意

Wed, 18 Apr 2012 18:09:21 GMT

「生命保険に入りたいが、仕組みが複雑でわからない」。こうした声を受け、生命保険をシンプルにする動きが広がっている。日本生命が４月に発売した商品はその一つ。従来はセット契約が条件だった保障を、それぞれ単独で買えるばら売りに変更。保険金をもらう条件も簡素化した。
　大手生保では終身保険などの「主契約」に医療や介護などの保障を「特約」としてセットにした商品が一般的。セットでないと買えない保障もあり、複雑だった。そこで日生は必要な保障を単品で自由に買えるようにした。

　似た商品は朝日生命も販売している。ネット生保や外資でもばら売りは一般的だ。
　保険金を受け取る保険契約の仕組みもシンプルになりつつある。一例は最初の保険料支払い前でも保険金を受け取れる商品だ。
　保険金は「契約申し込み」「健康状態の告知」「初回の保険料支払い」をすべて終えた後でないと受け取れないのが普通。最初の保険料を払う前に被保険者が亡くなると、保険金がもらえないため、わかりにくいとの声も出ていた。ソニー生命や富士生命、東京海上日動あんしん生命、日生などは保険料払い込み前は保険金から未払い保険料を差し引いた金額を支払う仕組みを導入した。

　ただ、シンプルな半面、注意点もある。日生の新商品は、保険料支払いが滞ると従来より簡単に保険を失う恐れがある。これまでは保険料を滞納しても、解約返戻金から自動的に貸し付ける形で保険料が払い込まれる仕組みがあった。失効しても数年以内に未払い分を払い健康状態の診査をやり直せば、同じ保険を復活することも可能だった。
　だが、新商品ではこれらの仕組みを廃止。保険料が滞った場合、郵便や営業員の訪問などで催促。２カ月以内に払わないと保険契約は解除となり、復活もできなくなった。
　シンプルになったとはいえ、保険は安い買い物ではない。営業員らに納得できるまで質問し、本当に必要な保障を選ぶべきだろう。

出典：日本経済新聞　平成24年4月18日朝刊

株式会社プロフェッサ
http://isol.pro-s.co.jp

生損保が保育所直営（金融庁、13年度にも解禁検討）

Wed, 11 Apr 2012 14:13:04 GMT

金融庁は保険会社が子会社を通じて直接、保育所を運営できるようにする方向で検討に入った。保育所に入りたくても入れない待機児童問題が深刻になる一方、保険会社の間で保有する不動産を使った保育サービスへの参入意欲が高まっているためだ。金融庁は11日に開く金融審議会（首相の諮問機関）で議論を始め、早ければ2013年度にも保険業法を改正する。

　金融審は09年に保険の基本問題に関する中間報告をとりまとめた。その後、保険金の不払いに伴う経営問題が一服。少子高齢化が一段と進む状況を踏まえ、保険会社が提供する商品やサービスのあり方について本格的に再検討することにした。

　業務範囲の見直しはその一環。保険業法は保険会社が子会社で参入できる業務を限っており、保育所運営は対象に入っていない。都心の駅前などに優良な不動産物件を多く抱える保険会社が保育サービスに直接参入できれば、保育所に入れない待機児童の解消につながる可能性がある。子供向けの医療保険や傷害保険など本業の保険事業との相乗効果も見込める。

　一方、保険会社が保険金の代わりに医療や介護などのサービスを提供する「現物給付」の是非についても検討する。現物給付は07～08年にも議論したが、反対意見が多く、解禁を見送っていた。

　厚生労働省によると、待機児童の数は昨年４月時点で約２万5000人。需要に対し、保育所の供給が追いつかず、高止まりが続いている。
　保険会社では第一生命保険が自社の不動産を活用し、保育サービス大手のＪＰホールディングスとポピンズに業務委託する形で保育所運営に乗り出している。

　自社で直接運営できるようになれば「収益事業としてスピーディーな拠点展開が可能になる」（大手生保）、「保険商品の潜在的な顧客と新たな接点をつくれる」（大手損保）と業法改正に期待する向きが多い。

　ただ現在は、企業が保育事業から得た収益を配当やほかの事業への投資に使うと、市町村からの補助金が減ってしまう。このため政府は保育サービスを拡充するための子育て支援新制度の関連法案を３月末に国会に提出した。
　法案が成立すれば、これまで事業主体が社会福祉法人か株式会社かなどで差があった補助金は一本化される。施設は市町村の指定を受ければ、運営費が給付される仕組みになる。金融審ではこうした新制度もにらんで、保険業法改正の議論を急ぐ。

　保険会社の保育所運営について、ＪＰホールディングスの山口洋社長は「保育事業の採算を確保するには一定の規模が必要」と指摘。法改正で保険会社が子会社を通じて保育所を運営できるようになっても、事業として成立させるのは難しい側面もあるとみる。

出典：日本経済新聞　平成24年4月11日朝刊

株式会社プロフェッサ
http://isol.pro-s.co.jp

日本生命：特約を廃止

Mon, 26 Mar 2012 10:18:18 GMT

日本生命保険は３月２３日、商品戦略を大きく転換すると発表した。主契約に追加する「特約」を４月２日から廃止し、顧客が必要とする保険のみを単品で販売する。
顧客の保険料負担を抑え、外資系などに対抗して幅広い層の取り込みを狙う。高額で手厚い保障を勧めがちだった戦略を大きく転換するもので、他の大手生保の戦略にも影響を与えそうだ。

　新戦略の最大の特徴は保険商品の単品化だ。従来、個人向けでは特約でしか契約できなかった３大疾病（がん、心筋梗塞（こうそく）、脳卒中）保障保険や介護保険を含む１１種類の主要な保険をすべて主契約商品として販売する。商品の簡素化で顧客の保険料負担を抑え、保険金の支払い漏れリスクを抑える効果も狙う。従来の契約に影響はしない。

　大手生保は、商品に複数の特約を付けることで保険料が高くなる傾向が強い。晩婚化による独身世帯の増加などで妻や子供のために掛ける死亡保険の需要が減少し、自らの将来に備える医療・がん保険の人気が高まるなど、構造変化が進んでいる。これらの保険を主力とするアフラックが０４年に保有契約件数で日生を抜いたほか、全国の代理店網を武器とする損保系生保、格安保険料のネット生保が存在感を高めるなど大手生保は後発組にシェア（市場占有率）を奪われていた。

出典：毎日新聞　2012年3月24日　東京朝刊

株式会社プロフェッサ
http://isol.pro-s.co.jp

損害保険ジャパンと日本興亜損害保険が合併

Mon, 26 Mar 2012 10:13:46 GMT

ＮＫＳＪホールディングスは３月２３日、傘下の損害保険ジャパンと日本興亜損害保険が２０１４年度上半期をめどに合併することで基本合意したと発表した。
損保業界を取り巻く環境が厳しくなる中、合併によって事業基盤を強化する。

存続会社は損保ジャパン。
合併会社の社名は損害保険ジャパン日本興亜で、会長に損保ジャパンの桜田謙悟社長が、社長に日本興亜の二宮雅也社長が就く。

出典：ロイター

株式会社プロフェッサ
http://isol.pro-s.co.jp

2012年の節分

Tue, 07 Feb 2012 11:19:33 GMT

毎年恒例の節分豆まきを行いました。
節分はみなさん御存じのように立春の前日を言いますね。
立春は春の始めです。

北陸地方は大雪で雪下ろしが大変とニュースが報道しています。
がんばってください。
もうすぐ春が来ます。

株式会社プロフェッサ
http://isol.pro-s.co.jp

TeraStationファームウェアのアップデート

Sat, 09 May 2009 23:44:29 GMT

弊社の本社には40人弱の社員が作業しておりますが、ファイルサーバはTeraStationを使用しております。価格がリーズナブルな上、Active Directoryと連携できるので重宝していました。

先日、2年間使用していたTS-H1.6TGL/R5のHDDにエラーが検出された為、これを機会に新しくTS-X4.0TL/R5を購入しました。

ファイルサーバのデータ量が既に500GB近くに達しており、新ファイルサーバへのデータ移行の時間が予測できなかったのでゴールデンウィークを利用してファイルの移行を行ったのですが、バックアップ機能を利用して5～6時間でデータの移行が出来ました。

連休明けから新しいファイルサーバで運用していたのですが、ちょっとした不具合があって、原因を調べてみたらファームウェアのバグとのことで、本日は休日出社でファームウェアのアップデートを行いました。

ファイルサーバのファームウェアのアップデートなんてのは、自宅のファイルサーバなら簡単なことですが、会社の最も重要な機器の一つであるファイルサーバのファームウェアですから、やはり非常に気を使います。アップデート後に起動しなくなったなんてことになったら、血の気が引くわけです。
というわけで当然、事前に全てのデータをバックアップしてからファームウェアをアップデートしました。
今回はTS-X4.0TL/R5のファームウェアをVer.1.0からVer.1.04にアップデートしました。アップデートはＰＣから行うのですが、この瞬間に停電が起きないかと余計な心配をしてしまうものです。
幸いにして何事もなく無事に完了しました。

アップデート後に気づいたのは、上記のWebの管理ツールが改善されていたことです。ファームウェアVer.1.0の共有フォルダのアクセス権限の設定は、ハッキリ言って最悪でした。Active Directoryと連携してユーザのアクセス権限を設定しようとする場合、ユーザが多いと設定画面が遅くて使い物になりませんでした。しかしこの辺りは大幅に改善されてました。

しかし、逆に考えると購入直後の初期の状態では管理ツールの一部が使い物にならなかったり、明らかなバグが含まれているというのも考え物です。
いかなる製品も出荷直後はバグが多いもので、時間と共に次第に枯れた利用しやすい製品になるものですが、それでも出荷時点では最高の製品であって欲しいです。
私たちはソフトウェア開発者であり、お客様にシステムをリリースするときは常にその時点では最高の製品であり、バグは出尽くしたという気持ちで納品しています。（無論TeraStationの開発者の方もそんな気持ちでリリースしているとは思います。）

その気持ちを今後も忘れずに、がんばっていこうなんてことを改めて感じました。

というわけで上記の通り弊社ではTeraStationが3台ありますが、写真手前のTS-X4.0TL/R5はメインファイルサーバとして、写真後ろの2台のTS-HTGL/R5はバックアップ機としてがんばっています。

株式会社プロフェッサ
http://isol.pro-s.co.jp

開発サーバの導入作業

Mon, 12 Jan 2009 17:21:15 GMT

弊社で新しいサーバが必要となりまして、久々に開発用のサーバを新規に購入しました。

最近では弊社で開発サーバを購入するにはSupermicro社製を採用することが多かったのですが、今回は思うところがあってA.T.WORKS社製のを購入してみることにしました。

今回購入したのは写真にあるradservX(ラッドサーブＸ)というサーバです。私のようなガンダム世代では、どうしてもシャア専用に見えてしまいます。

開封して弊社環境向けに少々設定をカスタマイズしてから、下記の写真の通り弊社サーバルームのラックに収めました。

用途は開発サーバですが、最近流行りの仮想化技術であるXenの利用を前提として購入しました。メモリは4GBと結構積みました。さすがシャア専用です。

仮想化技術には以前から興味がありましたが、実際に社内の開発サーバに本格的に適用したのは今回が初めてです。私はJava技術者でもありますので仮想化自体は珍しい事ではありませんが、それでもサーバの仮想化は素晴らしく感動しました。

弊社にて開発したシステムは、そのシステムのリリース後も保守やメンテナンスでその開発サーバなどの環境が引き続き必要となります。よって開発するシステムが増えれば増えるほど、弊社のサーバルームには開発・保守用のサーバがどんどん増えておりました。

また１つのシステムで必要なサーバは１台ではなく、開発中はチーム毎に開発サーバを用意して開発効率を上げたり、またステージングサーバも必要だったりと、サーバ管理者としては今まで何台もサーバを構築するのが大変でした。

これがサーバの仮想化により、開発環境の構築が敏速且つ楽になり消費電力も削減できるなどメリットは沢山あります。

早速VNC経由で自分のPCから新サーバへログインし、Virtual Machine ManagerというXenの管理ツールを使用して、まずは試しにゲストＯＳとしてCentOSをインストールしてみました。

見慣れたCentOSのインストーラが、デスクトップ上に現れるのは少々違和感がありましたが、スムーズにインストールが出来ました。試しにインストールしてみたゲストＯＳのCentOS5.2は僅か15分でインストールが出来ました。あまりにも簡単で感動しました。

株式会社プロフェッサ
http://isol.pro-s.co.jp

広尾まで散歩

Fri, 09 Jan 2009 13:07:52 GMT

昼休みに広尾まで行ってみました。この散歩シリーズは基本的には駅を目的地としていますが、徐々に会社から歩いていける距離の駅が少なくなってきました。でも、いける駅がなくなるまでもう少し頑張ってみます。

さて、前回の品川から、散歩の経路で絵や文字を描くことを宣言しましたが、これがなかなか難しいです。

歌を作る順序として、「歌詞」を作ってから「曲」を作る場合と「曲」を作ってからそれに合わせて「歌詞」を作る場合があると聞いたことがあります。

というわけで、今回もまずは「歩いて」からそれに合わせて「絵・文字」を決めようと無理やり決め込んで歩いてみたのですが、下記の通り極めて微妙な絵になってしまいました。

とりあえず「万歳をしている人を横から見たところ」ということにしました。丁度「く」の字になっているところがオシリということで。。。

株式会社プロフェッサ
http://isol.pro-s.co.jp

休日に鍋パーティ

Mon, 29 Dec 2008 07:45:11 GMT

今回は季節に見合った鍋パーティを社員の自宅を借りて開きました。

人数が多いので、下記の通り水炊きとキムチ鍋の２種類を用意しました。

下の写真は今回のパーティの目玉食材である東京Xという豚肉です。購入したのはしゃぶしゃぶ用の肉でしたが、これは大好評でした。

若者が多いので肉がてんこ盛りの鍋となってしまいましたが、値段は店で食べるよりも破格の安さで済みました。

お腹いっぱいになった後はみんなでトランプに興じました。最近はトランプといえばオンライン上でのゲームばかりで物理的にトランプをする機会が少なくなってきましたので、久しぶりで新鮮でした。

トランプに負けた人はお酒の買出しに行ったりして罰ゲームも楽しみました。

がしかし、この頃になるといつもは冷静な男性が酒に酔って故障し始めました。
いや、故障という程ではなかったのですが、誤作動が多く生じていました。今回は独身女性の部屋を借りてのパーティだったので、テンションが上がり過ぎてしまったようです。ヤレヤレでした(ーー;)

次は新年会を予定しています。楽しみです。

株式会社プロフェッサ
http://isol.pro-s.co.jp

Webアプリケーションの排他制御

Sun, 28 Dec 2008 11:15:21 GMT

Webに限ったことではありませんが、オンラインシステムにて排他制御をしたい場合はよくあります。例えばWebオンライン上で複数のユーザが同じデータを更新することが出来るシステムは、なんらかの排他制御の仕組みを取り入れた方がよいでしょう。

今回は私たちがWebシステムを開発してきた中でのこのようなケースで有効な排他に関するテクニックをいくつかご紹介したいと思います。

前提

Webシステムで最も排他制御が必要な対象リソースはデータベースです。ここで申し上げる排他制御を行う対象はデータベースに存在するデータとします。

楽観的ロック

楽観的ロックとはデータそのものに対してはロックをせずに、更新するときにアプリケーションの方でデータ取得時と同じ状態であることを確認してから更新する仕組みです。

例えばWebオンライン画面にて下図のようにデータベースからデータを取得した後「編集」→「確認」→「更新」のように複数画面の遷移を伴う一連の処理では、この楽観的ロックを行います。

具体的には、左図の「編集」でデータベースからデータを取得する際に、そのデータの最終更新日も取得しておきます。

そして「更新」する際にデータベースに存在するデータの最終更新日を比較し、異なっていたら編集中に他のユーザが先に更新したと見なしてその更新は無効である旨をユーザに伝えます。

最終更新日を比較する方法で手っ取り早いのは、更新する条件に最終更新日を含めてしまうことです。SQLで表現すると以下のようになります。

UPDATE table SET field1 = 'date1', field2 = 'date2', last_update = SYSDATE
　　WHERE id = 1000 and last_update = '2008/12/25 23:41:11'

このように更新する条件に最終更新日を含めてしまえば更新した際に更新件数が0件であった場合は、他のユーザが先に更新（もしくは削除）したと判断できます。

また上記のように手動で実装しなくても、自動的に楽観的ロックを行ってくれるデータベース関連のＡＰＩやミドルウェアも存在するので、そちらを利用する方法もあります。

悲観的ロック

悲観的ロックとはデータを取得する際にロックをかけ、他のプロセスから更新を許さないという仕組みです。

例えば一度のトランザクションで、関連する複数のテーブルのデータを抽出し、その抽出結果を基にして更新する場合があります。その場合、複数のテーブルからデータを抽出し、各テーブルに対して更新が終わるまでは、それらのデータのまとまりは他のプロセスから抽出と更新がされていないと保障される必要があります。

具体的な例を挙げます。左図のような伝票テーブルとそれに紐付く明細テーブルを更新するアプリケーションがあったとします。

伝票テーブルの情報はWebオンライン上の複数の画面から同時に更新される可能性があり、併せてそれに紐付く明細テーブルのデータも自由に追加・更新・削除できる仕様とします。

また、伝票テーブルには明細の合計金額を保持する項目があるとします。つまり、明細の情報が変更されたり増減した場合は、伝票テーブルのレコードの合計金額もそれに合わせて更新する必要があるとします（このテーブル設計の良し悪しはまた別の話ということで。。）。
つまり、伝票テーブルと明細テーブルは常に整合性を取って更新する必要があるわけです。

更に厄介なことに、これらのデータはWebオンライン画面からだけではなく、日中に定期的に実行されるバッチ処理でも抽出・更新される可能性があるとします。

このような場合に、悲観的ロックを行います。

特にバッチ処理では先に申し上げた楽観的ロックを行うのは適切ではありません。オンライン画面での楽観的ロックであれば、競合を検出したエラー時にユーザに通知し再入力を促すことは出来ますが、バッチ処理ではエラーとなった場合は再実行をするなりの面倒な考慮が必要となるからです。

具体的な悲観的ロックの方法は、右図の通りアプリケーションが伝票または明細テーブルを処理する際に、Webもバッチ処理でも最初に伝票テーブルの対象レコードのロックを取得してから処理を行うというルールを決めます。

重要なのは更新する直前にロックをするのではなく、そのトランザクション内で伝票データを抽出する前に、伝票テーブルの対象レコードのロックを取得することです。

悲観的ロックを実現するには、データベースのロック機構をそのまま利用します。例えば、Oracleの場合はFOR UPDATE句でありSQL ServerやDB2の場合は、更新ロック(Uロック)等が適当です。
以下はOracleのFOR UPDATE句でロックを取得する例です。

SELECT * FROM table WHERE id = 1000 FOR UPDATE

先の楽観的ロックの例に出た左図のような「編集」→「確認」→「更新」のように遷移するWebオンライン画面のシステムで、バッチ処理も存在する場合は、オンラインでの「更新」の際に悲観的ロックも併用するようにします。
またバッチ処理では常に悲観的ロックを使用して更新します。

このようにWebでもバッチでも必ず伝票テーブルの対象レコードのロックを取得してから処理をする、というルールを徹底すれば正常に排他制御が働き不整合データができることはありません。

ただし、悲観的ロックではデッドロックに注意する必要があります。先ほどからの例で言うと、一度のトランザクションで複数の伝票データを更新する可能性がある場合は注意が必要です。

具体的な例として左図の通り、①でWebオンラインが伝票テーブルのレコード1に対してロックを取得した後、②でバッチ処理が伝票テーブルのレコード3に対してロックを取得したとします。 ③でWebオンラインが同一トランザクションで伝票テーブルのレコード3に対してロックを取得しようとするのと、④でバッチ処理が伝票テーブルのレコード1に対してロックを取得しようとするのが重なり、デッドロックに陥る可能性があるということです。

デッドロックを防止する有効な手段としては、ロックを取得する際に順番付けのルールを決めるというのがあります。上記の例でいうと、伝票のレコード番号が小さいものからロックを取得するというルールを決めれば、バッチ処理は伝票テーブルのレコード3からではなくレコード1から取得しなければならず、デッドロックが発生しません。

上記のルールが徹底されればそれに越したことはありませんが、私たちがよくやる方法はロックを取得する際にタイムアウトを設けてしまうことです。こうすれば、上記のような状態に陥ってもタイムアウトが発生してデッドロックにはなりません。
以下はOracleのFOR UPDATE句でロックを取得する際に8秒のタイムアウトを設けた例です。

SELECT * FROM table WHERE id = 1000 FOR UPDATE WAIT 8

ただし、バッチ処理から行うロックにはタイムアウトは設けません。先に申し上げた通りバッチ処理でエラーとなった場合は再実行をするなりの面倒な考慮が必要であり、オンラインのように安易にエラーを発生させる事は出来ません。
よって私たちは、バッチ処理からのロックはタイムアウトを設けずに、オンラインからのロックだけにタイムアウトを設けます。つまりバッチ処理を最優先させるということです。
ただし、バッチ処理は複数同時に実行されることは無いというのが前提です。

まとめ

以上となりますが、私たちが排他制御を行う際のポイントをまとめると下記の通りとなります。

複数のユーザが同じデータを同時に更新可能なWebオンラインでは楽観的ロックを行う
Webオンラインと同時にバッチ処理で更新される可能性がある場合は悲観的ロックも併用する
悲観的ロックでは対象データの主となるテーブルのレコードのロックを取得する
同一トランザクションで複数のデータに対して悲観的ロックを取得する場合はデッドロックに注意する

株式会社プロフェッサ
http://isol.pro-s.co.jp

あいそるニュース

クローズアップ 生命保険、シンプルに 滞納による契約解除に注意

生損保が保育所直営（金融庁、13年度にも解禁検討 ）

日本生命：特約を廃止

損害保険ジャパンと日本興亜損害保険が合併

2012年の節分

TeraStationファームウェアのアップデート

開発サーバの導入作業

広尾まで散歩

休日に鍋パーティ

Webアプリケーションの排他制御

前提

楽観的ロック

悲観的ロック

まとめ

クローズアップ　生命保険、シンプルに　滞納による契約解除に注意

生損保が保育所直営（金融庁、13年度にも解禁検討）