１０月２７日・２８日・２９日・３０日～まぐれ２～

　確率統計の分散を考えると、分散投資はたしかにメリットが大きいし、証券化はリスクを分散させる。だが「万が一」失う０・００１%の発生した出来事で失う期待値まで考慮してリスクが分散されているわけではないようだ。不動産の証券化が始まったころは、リスクの分散と長期投資のメリットを兼ね備えた素晴らしい金融商品が出来たものだと思ったが、今回のサブプライムローンの騒動は、万が一にも起こるはずがないリスクの分散ができず、全体として景気低下を招く事態となってしまった。小さなリターンが９９・９９パーセント積み重なっても、万が一のケースで数兆円を失う結果になってしまった場合、その金融商品には欠陥があることになる。少なくとも期待値は一定範囲に納まっていなければ投資家はだれも投資しないはずだからだ。
　このような事態にはたして、日経平均株価が８０００円台を回復しようが７０００円台になろうがあまり大きな意味があるようには思えない。長期投資をするのであれば確かに今株式を購入したほうが良さそうだが、ＰＢＲもＰＥＲもまるで役に立たない状況が今の株式市場だ。（資産と負債の差額の時価評価額は時価評価を一部凍結したことで指標としては公正性を失ったことになるし、そもそも割引現在価値そのものも前の決算日よりも大幅に低下している可能性すらあるからだ）。こうした状況の中で生き残った金融機関、たとえば日本の金融機関はサブプライムの被害が少ないといわれているが、それはおそらく日本のトレーダーが優秀だったからではけっしてなく、サブプライムに手を出すほどの余裕がなかったせいだろう。現在日本の銀行が海外の金融機関に投資を始めているが、これも失う損失の確率をどこまで読み込めているのか、最悪の事態まで織り込んでいるのかは不明。マスコミがどういおうと、投資行動からは一切手を引いて定期預金にひたすら貯蓄する。それが一番賢明な投資行動（＝貯蓄）といえる。

１０月２６日～まぐれ～

　株式市場はバブル以来の安値を更新。先週末にはついに７０００円台へ。ＰＢＲという指標を１以下の水準に割り込んでいるので、たとえば今の時価で株式を取得してから、資産を売却すれば、資産売却益をあげることができるまで割り込んでいる。ＰＢＲはかなり重要な指標なので、これを割り込んだということは明日の月曜日は株価は当然上昇傾向になるだろうが、素人やプロも含めて「買い」から入るとしても、「売り」をいつにするかのタイミングはプロのほうがやはり情報量からして明らかにベストタイミングを選ぶだろう。素人がデイトレーダーとして株式市場に参入することの危険性をあらためて実感。ありえるとはおもえない出来事まで可能性として織り込むことができる投資家こそが本当に市場に参入する資格があるわけで、そうでなければ株式は長期保有を前提として１０年、２０年単位で持ち続けるのが素人投資家のあり方で一日の短期売買などには手を出さないのが賢明だ。

１０月２４日・２５日～ティッピング・ポイント～

　ごくごく少数の人間だけに愛好されていた商品が、ある日突然ブレイクして大ヒット商品になる…。広告宣伝のおかげとも思えず、説明がつかない現象というのは実際に市場でもよくみかける。そもそもＩＰＯＤ自体、少数の愛好者のみが使用していたものが、突如ブレイクして、それまで市場に並存していたＷｉｎｄｏｗｓタイプのＵＳＢメモリをかなり駆逐してしまった。ituneによるソフトウェアが秀逸などといった分析もあるが、Ｗｉｎｄｏｗｓにも同様の曲検索機能などはあるし、むしろ互換性の観点や音質はＩＰＯＤよりも素晴らしい商品はいくつかある。にもかかわらずＩＰＯＤファンの数は増すばかりだ。そうした現象がなぜ起こりうるのか、なぜ起こったのか…といったことを現在各種の本を読んで勉強中。コネクターという各種の人間関係の「キー」になる人間がＩＰＯＤの広告宣伝の役割を果たした…という仮説は当然成立すると現在では想像している。この手のＵＳＢメモリタイプのオーディオについては、まだＣＤプレイヤーが利用されている時代には「面倒なもの」というイメージが強かったが、おそらくアーリーアダプタとよばれる初期の利用者が、「そんなことはない」ということを宣伝してまわった…ということはありうるだろう。ただ、それはなぜかＷｉｎｄｏｗｓではなくＭＡＣだった…もしかするとコネクターのかなりの部分がＭＡＣユーザーだったからではないか…という仮説も成立するかもしれない。個人的には実は最初はＷｉｎｄｏｗｓタイプのＵＳＢメモリを使用していたが、途中からシャッフルを購入してすべてをＩＰＯＤに変換。そして現在に至り、いまや他のＵＳＢもしくはハードディスクタイプに乗り換える動機も意欲もないが…。しかしその「きっかけ」はどこかにあったはずだ。そしてそれは広告宣伝の力ではなかったはずで、その「自分自身の動機」もいろいろと解明もしくは仮説構築をしてみたいというのが、基本情報の旧試験制度最後を受験したあとの今の課題である。

１０月１９日・２０日・２１日・２２日・２３日～見直し～

　１９日に早稲田大学キャンパスで基本情報を受験。午前の部については８割近くが正解なのでおそらく６００スコア（基本情報技術者試験は他の資格試験と異なり問題にウエイトをつけてスコアが午前と午後の両方で６００スコア以上だと合格する仕組み）は確実にとれている。問題は午後の部だが、スコアは単純にはいえないかもしれないが、５割５分程度の出来具合なので、６００スコアに少し足らないのではないかと思われる。いずれにしても発表を待つしかないが、次の試験からは新試験制度に変更になるのでこれまでに取得した初級シスアドがＩＴパスポートという国家資格になるほか、基本情報の試験内容もかなり変化しそうだ。今回も擬似言語が２問出ていたことからアルゴリズムの重要性は落ちないが、言語関係の知識はやや重要性が低下しそう。要はアルゴリズムは理解して、しかしプログラミング言語は状況によっていろいろ使う場面もある…という実務の状況を考慮した試験になるようだ。確かにＪＡＶＡで受験しても人によってはＣ言語のほうが必要なケースなどいろいろ出てくるだろうから、重要なのは仕組みそのものということかもしれない。
　とはいえ第１問、第２問、第３問、第９問重視というのは間違っていなかったが、第４問は一見難しそうで実は相当に易しい問題だった…というのがショック。春の試験もそうだったわけで、第１問～第４問、第９問で得点をしっかりとってから、第５問と第１３問で部分点を稼ぐという作戦が妥当だったようだ。ちょっと戦略をミスったのかもしれないが、まだまだ諦めないでがんばるつもり。

10月17日・18日～解く順序～

　とりあえずプログラム設計までの部分は問題を解き終わる。さて午後の試験問題だが、問１→問２→問３→問９→問４→問５→問１３という組み合わせで解いていったほうが良さそうだ。問題１～３、９はそれぞれ各10点なのでこの4問を完答しても、１０点×４で４０点。後は問題４（擬似言語）と問題５（プログラム設計）、問題１３（ＣＡＳＬ）で稼いでいかなければならないが、残り3問で5割得点を目標にしていけばなんとかなる…かもしれない。少なくとも空欄は多いが最初の部分は問題の条件文を素直に理解していけばとれる問題なのでそこでなんとか得点を稼ぐ…という作戦に出るしかなかいだろう。擬似言語もそれほど難しい問題がでなければ全部を埋めることはできるはずだが、あとは午後の2時間半の中でどこまで問題１～３を自信をもって埋めれるかが勝負になりそうだ。

10月16日～浮動小数点の変形～

　IEEEの浮動小数点だと定番問題だが、これが16ビットの浮動小数点になると飛躍的に難しくなるのはなぜか…。自分の解きなれたスタイルで一度2進数に変換しないと解けないというのもあるが、16ビットの加減乗除にやはり抵抗感があるのかもしれない。それほど仕組み自体は難しくないのだが、どうしても構えて時間がかかる…φ（．．）

10月15日～ビットの反転～

　やはり午前の問題の論理積と論理和の学習を。さすがに午前の足きりというのは勘弁してほしいので最低でも600スコアをクリアできる程度には復習をしておいたほうがよさそうだ…。

１０月１４日～基数変換～

　なんといっても基数変換は基本中の基本。今日はいまひとつモチベーションがあがらないのでアルゴリズムではなく簡単な基数変換の計算問題を解く。やる気がでないときには午前、ある程度ばらばらでも時間がとれるときには午後問題…どうもこれが一番のようだが…もう少しプランニングをしっかりねって工夫をいろいろ積み重ねたほうが良さそうだ…。

10月12日・13日～リスト構造～

　擬似言語のアルゴリズムでリスト構造の面倒な問題に取り組む。もともと擬似言語自体に非常に抵抗感があるのだが、擬似言語の仕組み自体は問題文に書いてあるので記憶することは少ない。あとはそれをいかにして流れ図的に解明していくか…ということだけなのだが…。本番だったらやはり擬似言語の問題の問題4はやはり飛ばしてＣＡＳＬか他の午後問題に取り組むことになるが、この問題4の配点が想定で20点。まるっきり全部落とすわけにはいかないというのが辛いところだ…。

１０月１１日～文字列一致のアルゴリズム～

　平成２０年春の午後は設問２で擬似言語、さらに文字列の一致だが、さほど難しくなく解答できた。共通問題の５問のうち、設問１から設問３はそれぞれ各１０点だが、やはりこの３問は全部とれるかとれないかでかなり違ってきそうだ。もちろん設問４と５の点数配分も大きいのでないがしろにはできないのだが…。どちらかというと設問１～３は午前の延長線で、設問４と５がやはりちょっと難しいという印象。ＣＡＳＬも問題９と１３とでは問題９はやさしめで１３でいかに部分点を稼ぐか…にかかってくるような印象

１０月１０日～午後の１問目～

　午後問題は必須５問と選択言語２問。平成２０年春の設問１はなんとか全問正解だが、なんとディスクの回転数といった設問とディスクキャッシュの問題。すでにパソコンの一部にはハードディスクにキャッシュをつけているので、それが早くも出題されたという形になる。ただそれほど難しい問題ではないのでここらあたりはなんとかクリア。問題は設問２だがまたも「文字列の一致」のアルゴリズムだ…これ、嫌なんだなあ…。

10月9日～ちょっとの～

　やっぱり疲れているのか、「ちょっと」横になろうとしたらそのまま2時間ほど寝てしまった…。気がついたら12時前になっているのがやや哀しい…。起きていたらこの2時間なにをしていただろうか…。

　一応60問まで問題を解いたが、あとさらに20問解いて、もう少し全体的な復習をしていこうと思う。この次は三連休だが、なんだかその実感がないんだよなあ…あまり休日出勤はしたくないが…。

１０月８日～データの冗長性～

　関係データベースの基本はやはり伝票の整理にあると思う。企業で伝票番号を用いない企業というのは実務ではかなりレアだろう。やはり手書きの伝票をパソコンに入力してそれから関係データベースの出番になるはずだ。第１正規形は伝票で考えれば「繰り返し」がないと定義されるが、それは同じ消費者が同じ日付で２種類の商品を購入したときに、伝票番号と商品番号を主キーにして繰り返しが発生しないようにする（通常手書きの帳簿でも繰り返しが生じないように書き込むようになっている）。

　次に主キーに従属するものをどんどん分離して別の表に分けていく。伝票番号と商品番号が決定していれば、商品番号に通常は商品名や単価は従属している。伝票番号にも通常、顧客名とその顧客番号は記載されているので、それを別の表にしてしまう。これが第２正規形だ。この第２正規形にすると、商品を廃品にした場合に別の商品名を商品番号に入れ替えればそのまま関係データベースを大幅に変更しなくて済むというメリットがでてくる。商品番号に従属する商品名や単価などがまさしく部分関数従属となるわけだ。

　さらに第三正規形で考えると、伝票番号・顧客番号・顧客名のうち顧客番号さえわかれば顧客名は別の表にして変更にそなえたほうがよい。そうして別の表にさらに分離して、主キー以外の項目の重複がなくなるとともに従属関係（推移的従属関係）がなくなる。いわば主キー項目以外に重複がないのが第３正規形で、一番環境の変化に強い関係データベース。データの冗長性をなくすとともに、現実の変化に対応しやすくなるというのがこの正規化のメリットなのだろう。伝票番号で考えていく…という発想はでも実務向けの考え方か…

１０月７日～第２正規化～

　午前問題５８問目まで到達。区切りのいいところまで行きたいがそうするとちょっとどれもこれもでワヤワヤになっちゃうので…。SQLについてはシスアドを受験するときにも勉強したが、部分的関数従属がない状態を突き詰めていくと第３正規化ということになるが、その一歩手前が第２正規化。なぜかその概念がないのに答えが出てしまうのが不思議だが、「何かおかしい」と考えているうちに表をみていると、矛盾が一番ない表が正解ということに気づく。ただそういう解き方だと今後の応用ができなくなるのでそれが難しいところではあるなあ…。

　それにしても人間はいろいろ複雑で難しい生き物だと痛感することも。淡々としているのが一番なのだが、その淡々としている生き方ってなかなかまた難しい…。

１０月６日～４０問目～

　平成２０年春の午前問題を４０問解く。ちょっとペースアップが必要かもしれない。残りの時間でもう一度ここ３回分を解きなおして周辺知識を整理しておくのが大事かな…。

１０月５日～逆ポーランド記法～

　午前問題では頻出なので逆ポーランド記法の解きかたを喫茶店にて学習。正直、暗号のようだが、確かに加減乗除の約束を守って、しかも機械的に解ける方法はある（同じくポーランド記法にもあれば逆ポーランド記法から通常の表記に戻す方法もある）。でもそうした問題は旧試験制度の最後には出題されるかもしれないが、ストラテジーやマネジメントなど情報の活用方法が重視される試験制度に変革されればあまり重要性がないジャンルになるのではないか。結局、コンピュータに読みやすく著述する方法ではあるが、人間にとっては読みにくい記述であるのは確かなので、逆ポーランド記法という方法がある…ということさえ知っておけばそれで十分ではないかと思うのだが…。

１０月４日～バッカス・ナウア記法～

　じっと問題を眺めていたが、ぜんぜんわからず解答をみる。バッカス・ナウア記法の問題で、「こんなの知らない…」と一時呆然。ただコンピュータ言語の定義はこのバッカス・ナウア記法はコンピュータ言語の定義のデフォルトで、プログラムやデータ構造、XMLなどもすべてこのバッカス・ナウア記法もしくはその延長の拡張BNFで定義されているというから、まったく知らない自分のほうに問題があるらしい。正直なにかの暗号かと思ったが、「～定義する」「もしくは～(or）」などの意味ぐらいはちゃんとおさえておくほうがいいらしい。ただ対策の立てようがないのがまあ個人的な実感…

１０月３日～ひやひや～

　平成２０年春の午前の問題に取り組む…基数変換には慣れていると「過信」していた…ポロポロ点数を取りこぼす…。試験制度自体が大きく変化するが、最後の旧試験制度をむかえるにあたって、とにかく頑張るしかないと自覚。時間がない中で苦手なジャンルをいかに克服するべきか、というそのノウハウは別の分野でも活用できるに違いない。逆に知識そのものが多分、陳腐化が相当激しいだろうなあ…とつくづく思う…。必要がなければアルゴリズムの学習など必要性がさほどあるとはやはり思えず…。

１０月２日～行・列・対角線（３）～

　同じ問題をさらに追及。考えてみると１６×１６の二次元配列の「対角線」というのは当然２本しかない。だからその２本について右下がりの対角線と左下がりの対角線についてそれぞれ「１」のビットをずらして１つでも「０」が混じっていたら、最終的にそれぞれのデータを保持しているレジスタが論理積の結果、「０」かどうかだけ判別すればいいわけだから、対角線のビット判定はきわめて容易なわけだ。その一方で行はその行が「♯FFFF」かどうかを調べてSUBAが「０」であれば担当のレジスタを１つづつカウントアップしていけばよいということになる。そして列もまた論理積で最終的に「１」となっているビット列の「１」の数を数えていけば該当数が求められるということになる。縦・横・斜めで非常に難しいように思ったが、考えてみると当然の理屈を踏まえた問題だ…。あとは左シフトをオーバーフローを探していくだけなのでそれだけ理解すると設問１と２は軽く解答できた…。あと設問３…というところで電車は目的地に到着…。

１０月１日～行・列・対角線（２）～

　第１３問はやはり配点が２０点ということで設問も多い。行・列・対角線のビット調査はレジスタにそれぞれ、右下がりの対角線・左下がりの対角線・列の３つを調べるビットパターンを設定し、それぞれ左シフト・右シフトでビットを調査していく。対角線の場合にはどこかに０があれば論理積を取るので全部「♯００００」となるという仕組み。ただし、カウントアップしていく仕組みはそれぞれ異なるようで、「行」については別の仕組みでビット調査する。何をどこでどうやって調べて、どこにデータを格納するのかをちゃんと抑えておかないと設問２、３を全部落とすことになってしまう。アルゴリズムは短いのだが、ちょっとミスをするとかなり点数を落とす可能性があるだけに怖い…。