マネックスの長所?!

マネックスグループは2011年にトレードステーション社と合併 し、その後様々なプロジェクトを共同で行っています。


今ではマネックスもグローバルな人材が増えていますが、 合併当時はまだまだ海外とのやり取りは少なく、 英語で実施するプロジェクトも数えるほどしかありませんでした。

 

そんな中とある開発とは全く関係のない部署にいた私は、 会社の偉い人によばれ、
偉い人「○○くんさあ、確か英語できたよね?」
私「はい、10年以上つかってないですけど」

偉い人「 トレードステーションの開発プロジェクトにはいってくれる?」
私「えっ!!??」
偉い人「大丈夫、大丈夫、精鋭チームの中でのサポートだから」
というながれで、いきなり開発に携わることになりました。


マネックスの長所、柔軟性。


開発の「か」の字にもかかわりのなかった私の転換点でした。
初めての電話ミーティングでは震えました。


言語の問題もそうですが、 トレードステーション社の本社はフロリダ州。 日本との時差は13時間あります。(冬は14時間)
今でこそ大分体制や環境が整ってきており、 コミュニケーションも取りやすくなっていますが、 当時は時差の関係もあり、 実際に電話等でのミーティングをする時間も限られていました。


できるだけお互いに歩み寄り早朝や夜間のミーティングをセッティングしますが、プロジェクトが佳境にはいると時間が足りません。
テストついでに会社に泊まり込み、 結果について真夜中からミーティングということもありました。


海外のミーティングでは歯に衣を着せませんので、 要件等の認識が違う場合はバンバン攻めてきます。
初めのころは1時間のミーティングで45分間向こうの怒鳴り声をおとなしくきいている、ということもありましたが、 慣れてくるとこちらからも攻めるようになります。


テストの結果について意見が相違する場合など、 夜中の2時に真っ暗なオフィスの中の会議室の電話ミーティングで 英語で怒鳴りあいをするというなかなか貴重な経験もしました。
でもお互いに怒鳴りあっていいたいことをいっているせいか不思議 とわだかまりなく、翌日には普通に話すことができました。


マネックスの長所、喧嘩をしても仲がいい。


今では日本のオフィスにもエンジニアが常駐するようになり、 真夜中のミーティングはほぼなくなりましたが、 今ではいい思い出ですね。


現在トレードステーションとの合併を機に、 私の周りではグローバルな人員が増え、 今では英語で定例ミーティングしている横で、 中国語で問題対応をしていたり、 その横でスペイン語でネットワークの設定の電話をしている社員が いたりします。

また機会があれば、会社間の文化の違いや小話をご紹介できれば、 と思います。
本日のブログでは証券会社では珍しいグローバルな一面をご紹介し ました。

 

マネックスの長所、グローバル。

信頼度成長曲線の成り立ちを思い出してみた(前編)

f:id:monex_engineer:20190318165158j:plain
こんにちは。
最近こちらの会社に参りました、システム開発部の小田切と申します。

私の担当する開発が結合テストフェーズに入りました。

結合テストフェーズでは、横軸にテスト時間、縦軸に累積バグ発見数をとったグラフを作成することがあり、信頼度成長曲線と呼んでいます。S字のカーブを描くことが多いです。

形状について考察した理論があり、以下に挙げる2つが基本のモデルと解釈しています。会社によっては40年も前から、以下のどちらかやその拡張式を用いて、バグの発生状況を推定・評価しているところがあります。しかしながら、学校の授業では行わない内容の為、一部の方にしか知られていない事実もあります。

また、先に結論の式だけを提示されて、難しいと敬遠されることも多いので、昔勉強したその成り立ちを今一度書いてみようと思いました。

 

1) ロジスティック曲線モデル式

f:id:monex_engineer:20190318154218p:plain
もともとは、1800年代に人口増加のモデルとして考案された式

2) ゴンペルツ曲線モデル式

f:id:monex_engineer:20190318154240p:plain
同じくもともとは、1800年代に年齢と死亡率の関係を表した式


今回は、上記の式がどのような仮定で出てきたかの説明をしていきたいと思います。

終結果の式だけでそれぞれのパラメータを変化させると、どのように変化するかを示すサイトなどもありますが、それぞれの式が導出される微分方程式とセットにしてイメージしておく方が、より良い対応ができると思います。どのような考えで、不具合検出に対応しているかも説明したいと思います。

紙面の長さの関係から、今回はまず、ロジステック曲線モデルについて説明していきます。

ロジスティック曲線モデル

ロジスティック方程式は、1800年代に生物の個体数の変化の様子を表す数理モデルとして始まったのですが、応用として累積バグの変化の様子を表すモデルとして用いられています。


 最初に挙げた式では関数として判りやすいように、変数が発見バグ数 , 時間が となっていますが、今後は、式をイメージしやすくするため、発見バグ数を Bug 、時間を として表現してみます。


考えは単純です。バグの総数を 個(定数)として、
バグ発生の伸び率 d(Bug)/dt / (Bug) は、
未発見のバグ k - Bug に比例するとする考えです。

 バグ発生の伸び率とは、バグの時間当たりの発見率 d(Bug)/dtを、現在発見のBug数で割ったものと定義します。

比例定数を w とすると、
 f:id:monex_engineer:20190318155601p:plain

と、すごく簡単な式になっている事が判ります。
なんと、バグ発生の伸び率がバグ数の一次式で減少しているだけの式です。

α= k * w とおいて、この微分方程式を解くと、最初に挙げた

f:id:monex_engineer:20190318155800p:plain

が得られます。上記の式をよく見ると、 

を無限大にするとm * exp(-α*t) が 0 に近づくことで、分母が1になり、Bug (発見バグ数)が、k (バグ総数)に近づいていくことが判ります。

f:id:monex_engineer:20190318153111p:plain


先ほどの方程式は、
f:id:monex_engineer:20190318155933p:plain

とも書けます。この式では、バグ発見の増加率 d(Bug)/dt は、Bugの発見数に比例する項と、発見バグ数が大きくなるほど増加率を減らす項 1 - Bug/k の積に比例すると読めます。初めの頃は、Bug/kが0に近いため、Bugに比例した発見率となり、発見バグ数が k に近づくと、d(Bug)/dtは、0に近づき、Bug=k で遂に0となり、これ以上 Bugが増加しないこともイメージできます。

 
 mは先ほどの微分方程式の初期条件を与えることで決まります。しかしながら、 t=0 とすると、Bug=k / (1+m) となり、0にはなりません。テスト開始時に既にBugが発見されている事に数式上はなっていますね。

テスト前から既知のバグがあるとわかってテストを始めるのは、実態と合っているような気もしたり。。。。


さて、考えのもととなった微分方程式を見て、信頼度成長曲線のひとつのロジスティック曲線モデルが少し身近になった気がしたでしょうか。

私は信頼度成長曲線を開発で用いた後、しばらくして、元の微分方程式を見ました。こんな簡単なモデルであの難しそうな式がでたのかと驚き、かつロジスティック曲線への親しみがわいた気になりました。ゴンペルツ曲線も同じです。

ここまで書いて、昔々、私が大学生の授業で受けた教授の言葉を思い出しました。

『日本の教科書には、光は直進性があるので、影は光源と反対側にできます。』
と記述することが多いが、
アメリカの教科書には、影は光源と反対側にできています。従って、光には直進性があることが判ります。』と書かれている。

アメリカの方がより良い説明だと思う。
(昔のことで国名の記憶があやふやですが、イギリスかもしれません。)

 

与えられた理論をそのまま使用するのではなく、現象・事実から理論が生まれていることを再認識しようということですね。

皆さんも、与えられたものの起源を振返らず、こういうものだと信じていることがありませんか?チコちゃんにも叱られてしまいます。
今の環境は、開発を行っていても、今までが何となくということを振り返ることのできる会社と思っています。
これを読んでなるほどと思った方、うちに来ませんか?

次回はゴンペルツ曲線について、その元となった考えを説明したいと思います。導出方法がロジステック曲線モデルとは違った概念で、これもまた興味深いです。

 

私が昔勉強し、今回参考にした本(微分方程式の出ていた本)は、以下です。
改めてみると1981年発行でした。

参考文献:
 ソフトウェアの品質評価法(統計的管理へのアプローチ)
 三觜 武 著  日科技連出版社 1981年刊

ということで、顔写真も私の80年代の写真を使用してみました。 

 

田切 貴秀システム開発部 開発グループ エンジニア

パフォーマンス測定ツール「俺の投資力診断」

f:id:monex_engineer:20190318094816j:plain


俺の投資力診断は2019/1/31にリリースをした株式パフォーマンス測定ツールとなります。

マーケットは相対的なものであり、例えば、みんなが10%儲かっている状態で、自分が5%しか儲かっていない場合は、嬉しいかもしれないですが、相対的には負け(投資力が低い)ということができます。

逆に、みんなが10%損した状態で、自分は1%のみの損ですんだ場合には、その状態は悲しいかもしれないですが、相対的には勝ち(投資力が高い)ということができます。

しかし、過去には、そのような情報を知る術はありませんでした。

俺の投資力診断は、絶対的な収益率や標準偏差(=リスク)だけではなく相対的な収益率等も知ることができるツールになります。

俺の投資力診断でできること

俺の投資力診断では、自分の収益率、標準偏差をしることができます。以前、紹介したラボツールの1つであるMONEX VIEWβでも、資産推移を知ることができます。

しかし、MONEX VIEWβでは、入金を行うとその分パフォーマンスが良く見えてしまうという問題点がありました。

俺の投資力診断では、入出金の影響を除外して収益率等を算出しており、簡単にそれらを把握することができます。

 

計算された収益率、標準偏差は以下のように表現されています。

 

f:id:monex_engineer:20190312184349p:plain

 

上に行くほど、収益率は高く、右に行くほど標準偏差が高いことを表しております。

小さな点は、その他の投資家を表しており、この情報から相対的な位置を把握することができます。

また、TOPIXのアイコンは、もしTOPIXETF保有していたと仮定した場合の収益率、標準偏差を表しております。

TOPIXの収益率を安定的に下回っている場合には、個別株投資は諦めて、ETFを素直に購入した方がよいのかもしれません…)

 

他人の銘柄や指標も確認できます。

f:id:monex_engineer:20190312184718p:plain

 

ほかの人がどのような銘柄を持っているのか、どのような投資行動をしているのかをしることもできます。

例えば、自分と同じような標準偏差だけれども、収益率が高い人のデータを選択すると、その人の投資行動を理解することもできます。

 

最近では、インフォグラフィックの考え方を活用して、データを視覚的に分かりやすく表現することが増えていると思いますが、なかなか金融という固い業界においては、投資家の個人個人の情報を分かりやすくまとめることは少ないと思います。

例えば、時価評価額等の情報はただ数字として置かれており、そこに視覚的な表現をされることは少ないと思います。

このサービスが金融業界における、表現の一つの転換点になればよいなと思っています。

 

また、ただ眺めて終わりではなく、自身の投資行動も改め、投資成績も上がるとよいですね!

 

斎藤 翔太システム開発部 シニアマネージャー マネックス・ラボ長