心理情報学 其の五 20171110
基礎数理の続き、やっていきます。
正規分布の性質
心理テストで得られた結果は、たいてい正規分布に従うことが分かっている。なので、最も基礎的な正規分布からやっていきます。そのほか知りたい方は、「確率論」の講義を見直して。ポアソン分布とか何とか分布とか。
正規分布の式は
ここで、は平均、は標準偏差を表しています。さらに、この分布を、に(標準化)していきます。そのためには、
と置き換える。こうすることによって、をに置き換えることができる。また、
と置けば、
と表すことができる。は左の値が右の分布に従っていることを表している。得られた標準正規分布は、原点からまでで68%、までで95%、までで99.7%占めている。
得点の解釈
心理テストなどにより得られた得点を粗点と呼ぶ。得点が出た段階では、何もわからない。そこで、標準的な母集団の性質をよく表している規準集団(ノルム集団)のデータ(ノルム)と比べることで、粗点の位置づけや意味を分析できる。
この規準の取り方は、男女別・地域別・年齢別などさまざまある。その規準の性質をよく表している代表的集団のことを規準集団と呼んでいる。
得点の種類
パーセンタイル順位
粗点以下の被験者が何%いるのかを取ったもの。順位のこと。
標準得点(z得点)
俗称偏差(Z得点)
偏差IQ(DIQ)
就学時にこの値が70以下だった場合、発達障がいを疑われる。
等価
等しいことを表す言葉ではなく、「等しくすること」を表している。つまり、異なるテストを比較するときに、それぞれを比較できるようにレベルを等しくすることをいう。
テストの点数に下駄をはかせるとか、センター試験の得点調整もこれに当たる。線形変換などの方法で実現する。
ソフトウェア工学 其の六 20171130
面接について
やる気を見せても、そのようにみられないことが多々。注意せよ。自分自身についてのプレゼン能力が面接の場では試される。面接=プレゼンテーションだ。
課題の講評
「通信して、いい感じに儲けるシステム」の考案について、講評がありました。その中で出てきた話をいくつか。
機能だけではいけないとあれだけ言ったのに…
どうやら、「こんな機能があります!!すごいでしょう!!便利でしょう!!儲けるでしょう!!」というレポートが結構あったようです。セキュリティコースの方にその傾向がみられたようですが。
この課題では、現在ある問題はいったい何なのか。そして、その問題はどのような性質を持っているのか。これを踏まえたうえで、最も解決策に近いものを提案する必要がありました。「アルゴリズム」だけでなく、人間の感性・感情に基づいて。また、「みんなが使っているものを使いたがる」という人間の性質から、ネットワーク外部性に繋げて行くことも可能かもしれません。
ヒット商品はクレイジー
ヒット商品は発表された当初は受け入れられず、クレイジーだと思われることがあるようです。しかし、クレイジーであるというのは、「今はまだない概念」であるということ。技術や人の考え方が変わってきたときに受け入れられ、認められ、ヒット商品になる(ならないものも当然あります)。
何年か前の回答で、「バーチャル彼氏を育成していくサービス」というものがあったらしい。今でこそ、スマホアプリなどでその種のサービスは提供されているが、課題が出された当初はなかなかクレイジーだったそうです。
かゆいところに手を届ける
新しい製品を作るとき、何を一番に考えなければならないか。それは、「ユーザーの心」。これにダイブしていくのが重要になってくる。表面に見えているものではなく、ユーザーが持っている「もうちょっとこうならないかなぁ…」的な表に出ない声に耳を傾け、製品を作っていく。これこそが、「見えないものを見る」ということにつながる。
システム開発について
システムを買う側の企業を「ユーザ企業」、システムを作る側の企業を「SIer、ソフトハウス」と呼ぶ。今回扱った、システム開発の手順(途中まで)を以下に列挙していく。
- ユーザー企業がRFPを作成、提出
- 要求開発
とりあえず、この回で進んだのはここまで。
RFP(提案依頼書)
ユーザ企業が最初に提出するもの。中身は
- システム概要(予算が入札時の駆け引きで重要になる)
- 手続き
- 提案していただきたい事項
- 開発の条件(作業時間、勤務場所など)
- 保証要件
- 契約事項(瑕疵担保契約期間が重要)
- 添付資料
などなど。企業の採用情報に、「勤務地:○○、他」と書かれていたら、常駐を疑うようにするべし。
この項目の中で、特にネックになってくる事項は「予算」と「瑕疵担保契約期間」。少し説明を書き足します。
予算
言わずもがな、とても重要。ユーザ企業は複数企業に対して「こんなもの作ってくれませんか??」と呼びかける。考慮すべきなのは、その予算がシステム開発にかかるコストとして妥当なのか、自社は儲けるのか、他社はどのような動きを見せるのかなどなど。お金はいつだって大事。
瑕疵担保契約期間
簡単に言えば、作ったものに対してユーザ企業が訴えを起こせる期間。電化製品を買ったときの保証期間みたいな感じ。依頼を受ける企業側からしてみれば、この期間は短くしたい。
多重下請け構造
日本では、この仕組みでシステムを開発しているところが多い。ユーザ企業が200万でシステムを依頼したときの流れの一例を書いてみる。
- 1次受け(プライムともいう)が依頼を受ける
- 1次受けは150万で依頼を2次受けに投げる
- 2次受けは100万で依頼を3次受けに流す
- n次受けがn+1次受けに依頼を回す
このように、下へ下へと依頼を回していく。これが多重下請け構造。
こうなってしまっては、全体の進捗を把握することができない。伝言ゲームのようにめんどくさい手続きを経て、ようやくプライムに情報が共有されることになる。このラグは、仕様変更の際に殺人鬼と化す。仕様変更が即座に末端に反映されないので、反映されていない期間にやった作業がすべて水の泡に。現場は火の車と化す。
さらに、1次受け、2次受けくらいまではコードを書かないことがあるらしい。ただ依頼を横投げして、50万円ゲット。
コンサルタント会社がユーザ企業とプライムの間に介入するという変則パターンについても説明を受けた。コンサルタント会社の仕事は、「提案すること」。実際に作ることはまずない*1。また、ユーザー企業は多くの場合、専門の知識を持っていない*2。なので、構造上絶対にありえないシステムだったり、わけのわからないシステム仕様書が採用されてしまうらしい。現場は瞬く間に炎上。SEがブラックだといわれている一つの要因だ。
就職先を決める際も、この構造についてしっかり理解することが重要だ。最初にどこの位置にいる企業に入るのか。これによって、その後が変わってくる。プライムとn次受けでは、とんでもない単位で生涯年収が変わってくるのだから。
ただし、今時安定している会社はない。どこに入っても大変だろう。しかし、その中でも恵まれた職場環境に身を置くためには、スキルが必要になってくる。
要求開発
RFPが提出されたら、要求開発のフェーズに入っていく。詳しい話は次回なのだが、この「要求開発」において最も重要なのが、「何(what)が欲しいのかを決める」ということ。手段(how)は決めない。これは簡単そうに見えて、とても難しい。なぜなら、まだこの世に存在していないシステムについて話をしているから。存在していないものに何が必要なのか見極めるためには、スキルが必要になる。「見えないものを見るスキル」が。第1回目の課題とつながった。