時間が大事な理由・次元を超えて

ちら裏・厨二病シリーズ第二弾

思ったことをただ綴るだけの内容ですので、お暇な方はぜひお付き合いください^^

でも、最初に謝ります。

まとまりがありません。ごめんなさい!!

 

 いいたいこと

いつも、時間ってなんだろうって考えている。

時空って、重力ってなんだろう、って。

建物や様々な物体の曲率とか考えていても、「美しい」という感性を刺激されるのはやっぱり、3次元なんだよな、と。

二次元だと、個人的に「ものたりない」と感じる。

でも、これは自分自身に課している勝手な制約なのかもしれない。

時間を尺とするものに、価値を見出している。当たり前なことなんだけど、それは根拠を考えると実はものすごく壮大な流れでいうと、自然の摂理なんだろうな、と。

先を予測するなら、すごーくおおきな視野を持つと、もしかするとブレークスルーになるのかもと思う。

じゃぁ、制約の呪縛から出るにはどうしたらいいのかな・・・

と考えたときの思考の流れをブログにしてみた。

 

自由と制約

わたしたちの生きている世界

当然、地球です。

惑星のなかという限られた「空間」。

これは、もう3次元を超えることができません。

この中で、我々はもがき、よくありたいと願い、行動しています。

よって、行動の基本は空間にあり、制限を設けているし、制約があると思っている。

 

 

平等なのは時間

物理の時間に習った、3次元の次の軸は「時間」。

3次元で生きている以上、次の軸には行き来ができない。

よって、生きる上での制約でもあるけれども、過ごす長さは平等。

なので、なにか良い方向へ行くよう、試みを行うとすると、共通の尺は時間になる。

みんなで向かう先、それは「未来」「将来」。

現在のスナップショットではない。

 

 

次元のマジック

二次元と三次元

映画「ゼログラビティ」でも言及されていたけど、ワームホールの原理はすごく簡単。

二次元(紙)に線を描く。線の先端同志をくっつける(紙をおりたたみ、重ね合わせる)と、ワームホールの出口と入り口が一つになる。

これが、2⇒3のイメージ。

3⇒4のイメージも付くのかもしれない。

ときの旅人や、転校生なんかは、4次元世界からの旅人なのかもしれない。

 

体験するもの

 空間になにかの建造物なり、五感を刺激するもので我々は刺激される。

目に見える範囲のものを感じ取る。

当たり前ですね。

自分のいる次元より微分された面・線での表現に反応する。

美しいと感じるのは、こういう表現のものが対象になる。

 

 

望むもの

 自分の存在するスナップショットから積分されたところを表現されたものに反応することはあるのだろうか?

そこを見たい。感じたい。

 

 

まとめ 

制約を超えて

時間を尺とするものに、価値を見出す流れになっている。 

時間は平等だから、その平等なものに役割を設け、価値をつける。

 

時間より大きい次元は見えないけど、すごく簡単なところ・・身近なところに存在しているはず。すぐ隣に。

早く気が付きたいな、気が付かない大きな存在だけど、身近な隣人。

 

 

 

小並感満載なこんなエントリを読んでくださった方、ありがとうございます。

 

 

ゆーちゅーばーモデル(?)と、勉強し続ける理由

 

昨日の夜。

夕飯中に、子供たちと、ゆーちゅーばーの稼ぎの話をしていて、勉強し続ける理由に(いい方向に)オチがついたので、メモ書き。

 

チラ裏です。スミマセン。

別に、ゆーちゅーばーに限らず、ですが、子どもたちが、ゆーちゅーぶをよく見ているので取り上げています。

 

ゆーちゅーばーになるまで?

 

母「あなた達は、いつもゆーちゅーぶを見ているね。飽きないの?」

息子「だって、毎日違うものがあるんだもん!」

母「すごいね。。ゆーちゅーばーは本当にすごいね。毎日作るには、時間とお金がかかるね。おもちゃとかゲームとか毎日紹介するだけ買わないといけないし、ゲームもしなきゃいけないし」

娘「いくらもうけてんのかな」

母「ヒカキンは年間1億くらい、と聞いたことがあるけど」

息子「すげー!!」

 

ゆーちゅーばーになるための三大要素?

 

ここで、ゆーちゅーばーになって、多くの人から見てもらえるようになると、スポンサー契約があったり、そこで契約金などが入る話をする。

そして、流れは契約がない人の話に。

 

息子「けいやくしてないときはどうするの?」

娘「最初にいろいろ自分で買ったりしなきゃいけないから、大変そう。でも、そのおもちゃとかは売れるって自信があるからやるんだよねー。」

母「そうだね。自信と蓄え。あとは、紹介する能力かな。面白いと思う番組と、ちょっと残念な番組ってあるでしょ?」

二人「うん」

母「能力も、お金も、自信もはじめる前にある程度必要だね。そのために勉強するんだねえ。自分がやりたいことをやれる地面を作るために、やるんだねえ」

 

娘「学校行かなくなっても、勉強は終わらないね。新しいことをはじめるための自信をつけるために勉強するのかぁ。私も警官になるために勉強してるから、同じだあ。」

 

母「商品を紹介するには、大事なことが3つ必要なんだね。

自分で商品を買うお金、紹介して見てもらえるという自信、紹介して面白いと思ってもらえるための技・スキル。」

 

息子「ドラクエと同じ!」

 

まとめ

 

業務外の勉強やら、お金がどうのこうのと色々考えた時期があったけど、結局はこのゆーちゅーばーもでるが、基本形なんじゃないかと思った。

  • 自分で商品を買うお金…義務教育などで得る知識、基本セット
  • 紹介して見てもらえるという自信…自己肯定感などの自己スキル、対人スキル、コミュニケーション
  • 紹介して面白いと思ってもらえるための技・スキル…継続的インテグレーション

 

子供との会話はいつも発見が多い。

自分の考えがまとまるからかなあ。

 

通勤電車内で10分でかきあげた10分チラ裏劇場でした。

ここまで読んでお付き合いくださった方、ありがとうございましたm(_ _)m

 

 

 

 

オオカミ少年 ベイズ更新(理論の手書き)

年末にちょっと触れたオオカミ少年の考え方にちょっとふれてみた。

 

okandayo.hatenablog.com

 

 

シミュレーションすると、わかりやすい。

でも、全部手書きw

 

 

便図をつかって表現

 

f:id:okandayo:20180102114501j:plain

f:id:okandayo:20180102114512j:plain

 

 

 

ベイズの定理をつかってみる

 

f:id:okandayo:20180102114533j:plain

 

 

 

 

f:id:okandayo:20180102114539j:plain

 

 

 

シミュレーションするとこうなる

 

 

f:id:okandayo:20180102114554j:plain

 

 

次回は本当にscarabつかってやってみようかな。

 

ベイズ統計、小並感導入編

このエントリは、以下の本を参考に書きました。

「岩波データサイエンス vol1」

https://www.amazon.co.jp/岩波データサイエンス-Vol-1-岩波データサイエンス刊行委員会/dp/4000298518

 

わかりやすくて、薄くて内容の濃いとてもいい本です♪

今回は、数式は書かずに導入だけ触れることにします。

自分の頭の整理のために・・・。

 

 

ベイズ統計とほかの統計の大きな違い

簡単に言うと、下のようなイメージになる。

 

ベイズ統計は、データだけではなくてデータの背後にある要素も確率的に生成されると仮定する。

 

オオカミ少年

ベイズ統計を理解するのによく使われる例は、

オオカミ少年」の事例でしょうか。

  • 少年が嘘つきである
  • 少年が正直者である

上記を「仮定」の条件にして、次に起こりうることを推定する。

嘘つきならば、次に本当のことを言う確率や、うそをつく確率などを用いて求める。

これを考えると、「人狼」というゲームがありますが、データを取得していけば、予測できそうですね~。

 

結局、一般化すると、

「母数の事前分布」+「検査データ」 ⇒ 「母数の事後分布」

ということになります。

 

 

予告

2018/2/17に、川崎でベイズ統計の勉強会をひらこうかなと思っております。

ご興味のある方は、connpass立てますので、ぜひご検討くださいませ♪

 

では、よいお年を~。

 

 

2017 振り返り(NaITE&ちょっと個人)

もう2017年もあと1日と半分。

はやいなぁ、と・・・。

NaITEのスタッフになってから2年がたとうとしています。はやいなぁ。

ということで、個人的に振り返ります!

 

年間振り返り

今年は、勉強会を7回も開いていました。2か月に1回のペースで企画していたのですが、なんだかんだで7回。スタッフも頑張っています!

 

NaITEは、AgileJapan長崎サテライトや、秋~冬にかけて長崎QDGという大きなイベントも開催しています。

主査の池田さんをはじめ、スタッフのしょーごさん、くまきちさん、つのだくん、ふじさわくん、まつやまくん、てしまくん、うじたくんと皆でがんばっています。

みんな、それぞれの想いを持って活動をしています。

仲もよいけど、礼節もきちんとしている。そんな仲間と出会えてよかったです。

 

個人的にも、数学勉強会を開いていくことにしました。

ただ数式を追いかけるだけだとただの苦行にしかならない。どうすれば数学を楽しめるかな?これは何に使われているんだろう?どうつながっているんだろう?

そんな目線から、いろいろとご紹介していけるといいなぁとおもっています。

一緒に勉強したい方、声をかけてくださいね!

 

 

 2017年1月

2017/1/21 NaITE#19 「数学を学ぼう ~数学の知識を利用したソフトウェアテスト勉強会

  数学のパート。ただ、数式を展開するだけの勉強会ではなく、何に使うのか、どういう場面で何(数式・考え方)が使えるのか、というアプローチでの勉強会を開催しました。

 

naite.swquality.jp

 

2017年2月

JaSST TOKYO 2017 で、コミュニティブースをだしました!

こういう試み初めてでした。NaITEを多くの人に知ってもらえる機会を得ることができて、本当に感謝です。

 

JaSSTソフトウェアテストシンポジウム-JaSST'17 Tokyo

 

ちなみに、ここで事例発表を行いました!(自社の事例発表です)

「品質予測モデルの構築およびプロジェクト管理への適用事例」

 

 

 

2017年4月

2017年4月8日 NaITE#20「プロセスモデル CMMI にまつわるちょっと深イイ話」 勉強会

CMMIというプロセス参照モデルのご紹介をしました。

プロセス参照モデルを使うには、道具(CMMI)を知っている必要があり、詳細を中村こーじくんが紹介してくれました。そして、そのプロセス参照モデルを組織でちゃんとまわしていくためにはどうするか?という視点でのご紹介もさせていただいております。

 

naite.swquality.jp

 

2017年4月22日 NaITE#21「PSP概説&体験ワーク(おかわり)」 勉強会

メトリクスのすべての親となるフレームワークPSP

これをしっているかしらないか、で、業務の改善度は格段に違うと思います。

その内容のご紹介を、くまきちさんがしてくれています。

naite.swquality.jp

 

2017年5月

2017年5月20日  NaITE#22「はじめてのバグ票システム~導入実践ガイド」 勉強会

ソフトウエア開発にかかわる人は、バグとはきっても切り離せない。そんな情報を取り扱うためには、何が大切なの?バグ票ってなんのためにあるの?といったところからも、バグ票システム導入実践ガイドご紹介しています。

この回には、細川さんが来てくださいました!

医療とソフトの近さを感じるご講演をいただきました。

 

 

naite.swquality.jp

 

2017年7月

2017年7月16日 NaITE#23 「Scrum入門&Agile Japan 2017 長崎サテライト参加報告」 勉強会

アジャイルしばりの勉強会。AgileJapanの参加報告と、Scrumとは?について、きんじさんにご紹介いただきました!

 

naite.swquality.jp

 

 

2017年9月

2017年9月17日 NaITE#24 「テストカタマリー ワークショップ&解説」 勉強会

テストカタマリーのワークショップを、みずのりさん、くっきーさんに開催していただきました。

テスト設計時にモデリングをして、テストをする人・開発をする人・顧客の視点などからの気がかりなところもそのモデルに関連付けておけば、なんでそのテストをしたの?というところの根拠にもなるなぁと個人的には思っております。

naite.swquality.jp

 

2017年11月

2017年11月11日 NaITE#25「欠陥モデリングワークショップ&解説」 勉強会

森りゅうじさんに、欠陥モデリングのワークショップをしていただきました。

5月に開催いたバグ票とあわせて、バグの内容をモデリングして抽象化すると組織の資産としてかなり有用性の高いものになるので、両方をしっておくとすごくいいなぁと思います。

 

naite.swquality.jp

 

 

来年に向けて

来年は 1/20にNaITE#26、2/2に長崎QDGを開催予定しています。

ぜひぜひご参加下さい!

来年もどうぞよろしくお願いいたします。

 

 

 

ワークプロダクトレビューの技術とプロセス ~レビュー技術・事例と標準化最新動向の紹介~

2ヶ月ほどまえに参加したセミナーについて、ブログってみました。

有料だったのでどうかなと思ったのですが、にしさんから許可(?)もらったので、掲載しちゃいます。

 

www.ipsj.or.jp

 

所感 

非常に費用対効果が高いセミナーでした。こんなセミナー、もうないんじゃないかなぁと思うほどの満足度の高さです。ありがとうございました。

 

森崎さんの講演で、「チェックリストは「やり方が」書かれていない。どうやってそれを確認するのか?が書かれていない。」というお話がありました。

社内でも、「ツール」を使った、そのツールが**です、という報告はあるが「どう使われたのか、使った目的は何か」というところに触れられていないことがあるのとリンクするなぁと思いました。手段・方法は、プロセス・目的と一緒にセットで情報を持っていないと意味がない。そう思いました。

 

細谷さんの講演では、グランドルールありき、チームビルディングありきの改善かもしれない、とおしゃっられていたことが印象的でした。

個人ではなくチームでルールを作り、自分たちで決めたことは守る、ということを厳しく貫いているところがおおきな成功要因なんだなぁ、と思います。

パネルディスカッションを見ることが一番の目的でした。ここだけで、もう本1冊分の価値があったのではないかなぁと思うような内容でした。「レビュー」と「テスト」って、似て非なるもの。そこを痛感するパネルでした。

 

開催概要

  • タイトル:ワークプロダクトレビューの技術とプロセス ~レビュー技術・事例と標準化最新動向の紹介~
  • 日時: 2017年 10月18日(水) 13:15~18:00
  • 会場: 機械振興会館 地下3階 研修1号室
  • 概要:

ソフトウェアの品質向上のため、要件定義書や設計書などワークプロダクトのレビューは重要です。2017年2月にISO/IEC 20246:2017 (ワークプロダクトレビュー)がレビュー技術やプロセスを定義する国際標準として発行されました。
 本セミナーでは、このISO/IEC 20246:2017発行を機会に、レビュー技術や事例、また標準化最新動向を紹介・解説します。まず、レビューの技術やプロセスについて一般的なものから最新情報など、また、産業界での適用事例を紹介します。さらに、ISO/IEC 20246:2017の解説を行います。最後に、パネルディスカッションを行い、レビュー技術の事例や国際標準の意見交換を行います。

 

 

●ソフトウェアプロダクトレビューの基礎と研究動向(森崎さん(名古屋大学))

ソフトウェアプロダクトレビューは実行可能なプログラムが存在しない時点でも実施できる欠陥検出技法です。本講演では、ソフトウェアプロダクトレビューの基礎と研究動向を紹介します。ソフトウェアプロダクトレビューの基礎として、目的、参加者の役割、欠陥の検出例を示し、ソフトウェアプロダクトレビューの原理を理解いただきます。次に、検出した欠陥を早期に修正することによって得られる欠陥の修正コストや欠陥の見逃しリスクの低減といった効果を解説します。最後に、これまで研究分野で議論されてきたソフトウェアプロダクトレビューの技法や技術を紹介した上で、近年注目を浴びているModern Code ReviewやArchitecture Tradeoff Analysis Methodを紹介します。

 

  • レビューは、ソースコードがない状態でも欠陥を検出できる。
  • だれがやっても同じようにできる必要がある。レビューは準備が大事。
  • レビューは、「どのような条件がそろうと、達成されるとやった意味がある、と思われるか」を考えよう。
  • テストの場合は、あまり属人性があると聞いたことがないけど、レビューは人のスキルに依存することが非常に多い。
  • レビューで、特殊なタイミングや競合、バッファオーバフローやセキュリティなどはレビュー時点で検出したほうが良い。⇒ 病気と一緒
  • チェックリストは「やり方が」書かれていない。どうやってそれを確認するのか?が書かれていない。
  • モダンコードレビューというものがグーグルで行われている。
  • 目的は協調であり、欠陥検出ではない。ペアプログラミングの代替手段となっている。

 

 

●狙いの明確化によるレビュー改善事例(細谷さん(三菱電機(株)))

ソフトウェア開発において、ドキュメントやコードのレビューは、品質向上のために重要な活動ですが、開発現場では、レビューに投入したコストに見合った効果が得られている実感がないという課題がありました。そこで、レビューで検出したい欠陥を明確化し狙いに合わせたレビューの実施時期、実施方法を定めることにより、開発現場が効果を実感できるレビューに改善しました。本セッションでは、レビュー観点の分類、レビュー技法の使い分け、実施シナリオなど改善活動の中で定めた実施方法について紹介します。

  •  産学連携して行ったカイゼンで、Melcoグループ内のガイドラインとして作成した内容を紹介。
  • レビュー技法は使い分ける。
  • 序盤は、例えば運用シナリオ、ユースケースなど、多く記述しそうなものであれば、最初でやり方・書き方の合意をレビュー内で行う。
  • 残りのものに水平展開する。後半は工数を削減することができる。
  • 中盤は、重要と思われる機能の部分など、ピンポイントで見るべきものに絞ってレビューを行っていく。
  • レビュー観点とレビューの仕方を関連付ける。
  • 4象限で観点を明確化することは効果がある。
  • プロジェクト内で合意を得ながら実施する。
  • ナレッジメンバーを任命。ナレッジメンバー=レビューの有識者
  • 有識者だからといって、レビューができるとは限らないので教育をする。教育の中には、演習も入っている。
  • いくつかシナリオを用意して、人格攻撃をしない、とかディスカッションを交えた教育を行っている。
  • グランドルールありきの改善かもしれない。チームビルディングありき。

  

●パネルディスカッション「レビュー技術の研究と活用」

パネラー:森崎さん(森)/増田さん(増)/細谷さん(細)/西さん(西)


1.V&V V字の左側でもやるべきだということが言われているが、妥当性確認について どう考えているのか?レビューで妥当性確認ができるか?どうやればいいのか?

  • 森:最後に言われても困るので、途中でいうことに意味がある。スクリプトテスト・探索的テストに代わるものがレビューにもあると思っている。終盤にいわれても直せない、ということになってしまう。どのタイミングでどういう指摘を行っていくか、をレビュー計画で合意することは大事。 ⇒細谷さんの事例に重なる
  • 細:事前にレビューしてほしい観点を渡してレビューしてもらったりした。
  • 増:ただしくつくったか?つくったものはただしかったか?を確認するのがV&V。正しく作っているか?というところにたいして、定義しているのが20246である。つくったものはただしいか?という観点でのチェックまでは言及していない。
  • 西:V&Vは時代遅れ。妥当性確認としてどういう観点で確認したらいいかを分解しておいて、テストでは何を確認すればいいのか、を合意していくべきである。


2.オフショア・ニアショア 品質確保(検証)の良いやり方を教えてほしい。

  •  森:共同研究内容。発注工程の前工程でのQ&A(=ドメイン知識)の内容に着目する。前提知識が同じになっているかどうかでわかってくる。受注側からの質問の質で受注側のスキルを測るとよい。実績も大事。技術力がない受注側をレビューで何とかするのはむり。発注先を変える勇気も必要。ドメイン知識と技術両方ないとうまくいかない。オープンクエスチョンで聞いてくる人は、ちょっと危ない。YES/NOで聞いてくるところは安心できるかも。
  • 細:契約の序盤でレビューしたりする仕組みを入れないと難しいと思う。そういうことを盛り込めるような契約にしていくべきだと思う。ワークショップ的なものを一緒にやる。ユースケース的なものを一緒に作ったりして、やり方を教えたりしている。内部品質に着目するのであれば、機能設計を一緒にやるとかを考えないといけない。
  • 増:レビューのトレーニングとしてレビューを捉えることも大事。有効な手段。ツールで効率化するなども、選択肢の一つである。国際標準規格は、受注側の技術力が低い場合にも、「こうやるとうまくいくよね」というものを想定して作られている。重量級の国際標準は発注側の視点で考え方や技術などが細々と書かれているので有用である。

  

3.再現性・・・属人性排除、次回も同じようにできる、などについて

  •  増:できる。そのために規格を作成している。再現性があるのか、品質があがるのか、という条件に関しては、組織それぞれでの前提条件などがあるとおもうので、それを文書化していくとよい。
  • 細:属人性の排除。レビューの仕方はやり方があるので、できる。役割の設定、レビュー技法も取り入れられるはず。その人たちの能力の範囲でできると思う。能力の質の属人性は別の話。組織としてのいいところは狙えるけど、ひとのスキルに依存するばらつきは排除できないと思う。「組織のスキルの限度において」よい仕事ができる。
  • 森:着眼点が一緒、属人性の排除。前提条件の抜けが認識できていなければ無理。 結果を予測できるようなものになるというのも、属人性の排除には重要。技術力が低いのであれば、「ないものねだりをしない」のが大事。 

 

文化、マインド・・・の話:
  • 森:素質、再現性、プロセスを定義する、マインドの話・スキルの話。マインドがあるけどスキルがないからうまくいかない、スキルがあるけどマインドが低いからうまくいかない・・四象限的。
  • 細:細かく繰り返すというのに重要視している。どこを目的としていて、どう改善していくか、が大事と思っている。  
  • 増:F2Fでやったほうが効率が高いと聞いて、実行している。すべてがトップダウンで行っているわけではなく、プロジェクトのアウトプットが高まる行為であればOK。ツールであろうが、マインドにかかわる話であろうが、上記の効果が期待できるものであれば実施する。

 

4.レビュー文化:個人主義の国(欧米とか)・組織・エンジニアは、レビューのような皆のための仕事はしないので、枠や型が必要なのではないか?

  •  森:レビューを手伝った人は人事評価をよくするなどの仕組み的対処が必要。レビューで後ろから打たれるような状況を作ってはいけない。
  • 増:自分が書いた試験に自分で回答して自分で丸付けして100点というのは本当かどうかわからないから、確認が必要。欧米ではテスト専門の職業などがあるけど、日本ではなかなか受け入れられない。   
  • 西:組織の方針と仕組みは国とか個人の考えをオーバーライドするので、そういうマネジメントをしてしまっているだけなので、マネジメントの怠慢だと思います。

   ⇒森:レビューは社風が出る。けん制しあって向上するという文化とか。文化が異なる同士のレビューはそれぞれ違和感を感じるだろう。

 


5.改善内容の適用スコープは、全プロジェクトに共通というわけではないとは思う。レビューの目的やプロダクトの特性などによって改善内容を変えるべきか?レビュー設計はしているのか?

  •  細:変えているが、全プロジェクトに適用しているものもある。(インスペクションに有識者を入れるというのは100%)。レビュー設計としては、目的・観点を決めるなどのレビュー計画は行っている。
  • 森:細かいレビュー設計は、細かくすればするほど形骸化しやすい。コストが下がらなくなる。
  • 増:チェックリストはどうやってつくるの?⇒過去の障害を一般化する一般化抽象化して、全プロジェクトに適用、とか。

 

6.国際規格などを隠れ蓑にして形式的に仕事に文句をいうひとにはどう対応すべきか

  • 細:内部品質に対する意識を組織的に共通にしていくとかに使う。レビューのタイプで使い分けましょう。
  • 森:バディチェックで回避できる。
  • 増:標準は厳密に従うものではない。良いところどりをすればよい。特に20246は意識を高めてやっていこうというもの。


7.この30年間でレビューは何が変わったのか?一言で。

  • 増:ほとんど変わっていない。ソフトウエアの複雑度・テクノロジーが高度になっているので、相対的には変わっていない。
  • 細:若い人に「変わっていない」ということが伝わっていない。若い人は、「はじめてききました」という。それを伝えていく手段として、標準化された規格は使えると思う。
  • 森:本質は変わっていないが、対象範囲が広くなり、考え方もいろいろ出てきている。反復型の開発が一般敵になってくると、レビューの役割も変わるだろう。未熟な自分を理解していこう。
  • 西:テストも同じ状況だった。この先、おカネや技術が流入してきたら、変わると思う。

 

 以上!

バグの妥当な検出率?〜IPAのデータ白書と信頼区間とR〜

ソフトウェアテスト アドベントカレンダー 12/21担当のあさこです。

qiita.com

  

はじめに

テスト実施時には、バグが想定通り(?)に出ているかどうかのメトリクス分析を行う方は多いと思います。

割と、そこでベンチマークとして使われるのが、IPAから発行されているデータ白書。

参考:SEC BOOKS:ソフトウェア開発データ白書2016-2017:IPA 独立行政法人 情報処理推進機構

  

ここで多く使われているのが、二つのメトリクス(変数)を散布図で表し、回帰分析結果とその信頼区間(50%、95%)を算出したグラフです。

多くの企業が協力しているデータなので、ベンチマークには最適です。

以下例です。

f:id:okandayo:20171221060150p:plain

出典:https://sec.ipa.go.jp/files/secbooks/000057880.pdf

  

自社にて、部門間ベンチマークを行う際にも同じようにできるといいですよね。

Excelで分析のできるツールがIPAで公開されており、サイトからダウンロードできますが、ツール内でどんなことをやっているか、気になりませんか?

 内容を一部ご紹介します。

ぜひ、自社のデータでも試していただけると幸いです。

  

基本のおさらい

 メトリクスを取得する目的と、メトリクスの間の関係式を微分方程式で示すことを簡単にまとめたブログです。

 

okandayo.hatenablog.com

 

 IPAのデータ白書で散布図を用いて分析・表現されているものには、いろいろなものがあります。

基本的には以下のメトリクスが挙げられます。

  • 工数
  • 工期
  • 製造量(SLOC実績値)
  • 累積不具合検出率

 これらそれぞれの数値同志の相関をみて、その相関係数にて、上記ブログ内にある4つのタイプからその現象を説明する式を選択します。

 今回ご紹介しようとする例は、

  • 累積不具合検出率
  • 製造量(SLOC実績値)

を使って考えていきましょう。

 

考え方

  1. 対象の二つのメトリクスの関係性をみる
  2. 1で求めた関係性を使用して回帰分析を行い、近似式を求める
  3. 2で求めた近似式をもとに、信頼区間式を求める

 

1.対象の二つのメトリクスの関係性をみる

「基本のおさらい」で取り上げました内容に従い、メトリクス同士がどの微分方程式の関係性の時が相関が高いかを見ます。

自社のデータをもとに試したときは、以下の4タイプのうち、4のものが多かったので、それをとりあげます。

 

f:id:okandayo:20171221042927p:plain

 

2.1で求めた関係性を使用して回帰分析を行い、近似式を求める

回帰分析して求めた結果を使用する。

近似式の求め方は、Excelだとこんな感じ。中に書かれている値は、例です。

 

f:id:okandayo:20171221050120p:plain

 

 

3.2で求めた近似式をもとに、信頼区間式を求める

 数式で説明すると、こんな感じ。

f:id:okandayo:20171221051410p:plain

  

Rでやってみた

  1.  回帰分析を行い、近似式を求める
  2. 1で求めた近似式をもとに、信頼区間式を求める

 

0. 準備

# ①データの読み込み
WhitePaper.data <- read.csv("testdata.csv", header=T)
head(WhitePaper.data) #読み込んだデータを確認
LIN <- WhitePaper.data$Line
TH <- WhitePaper.data$TotalBug

#②散布図のプロット

 plot(log10(LIN),log10(TH)) # 生産量(LIN)と総工数(TH)

 #③回帰分析

 # lm関数に、説明変数をLIN、被説明変数をTHとして代入

result <- lm(log10(TH) ~ log10(LIN))

 

1. 回帰分析を行い、近似式を求める

# 分析結果の要約
summary(result)
abline(result) # 回帰直線を描く

#④対数スケール(回帰直線)⇒もとのスケール(回帰曲線)にもどしてグラフを描く(データを重ねがき) #####
##summary(result) の結果から係数をもってくる。
# 回帰分析の結果 log10(y) = 2.4615 + (0.8331)*log10(x) より

x <- 0.01*c(0:7000)
prediction <- 10^(2.4615)*x^(0.8331)
plot(x, prediction , col=2,type="l", xlim=c(0,70), ylim=c(0,11000),
xlab="", ylab="", main="")
par(new=TRUE)
plot(LIN, TH, col=4, xlim=c(0,70), ylim=c(0,11000),
xlab="LIN", ylab="TH", main="")

 

2. 1で求めた近似式をもとに、信頼区間式を求める

 ###### 信頼区間
alp2 <- 0.05 # 有意水準alp/2 ⇒ 信頼係数1-alp ⇒ 95%信頼区間のとき alp=1-0.95

# 95% のとき alp2 <- 0.025
# 90% のとき alp2 <- 0.05
# 50% のとき alp2 <- 0.25

n <- length(LIN) # データ数
bar_log <- sum(log10(LIN))/n
y_hat <- 10^(2.4615)*LIN^(0.8331)

# 残差分散の平方根
s <- sqrt( 1/(n-2)*sum*1^2) ) 

### 信頼区間の計算
C <- sqrt( 1/n+(log10(x)-bar_log)^2/sum((log10(LIN)-bar_log)^2) )

K <- 0.8331*log10(x)+2.4615 + qt(1-alp2,n-2)*s*C
confidence_U <- 10^K

K <- 0.8331*log10(x)+2.4615 - qt(1-alp2,n-2)*s*C
confidence_L <- 10^K

plot(x, confidence_U, col=3,type="l", xlim=c(0,70), ylim=c(0,11000),
xlab="", ylab="", main="")
par(new=TRUE)

plot(x, confidence_L , col=3,type="l", xlim=c(0,70), ylim=c(0,11000),
xlab="", ylab="", main="")
par(new=TRUE)

 

結果

信頼区間95%の時と、50%の場合を両方求めてプロットしました。

f:id:okandayo:20171221052909p:plain

いろいろとアレなので、メモリの数字などはとっぱらてありますw

 

 さいごに

 メトリクスは扱いを間違えるとアカンことになります。

 

 

 

たまたま、この記事を書く前日にこんな感じのやり取りをしたので、参考までに。。

数値データの裏の背景などのにも目を向けて取得してつかわなきゃ~とおもいました。

 

ここまでお付き合いくださり、ありがとうございました!

 

*1:log10(TH)-log10(y_hat