いやまあ、未だに「採点ミス？　隣の人の答案じゃないの？」　とか疑ってたりもするんですが（w　さすがに普通に合格したと思います。今回は、DBスペシャリストを目指す皆様のため、私がやってきた勉強の記録を（僭越ながら、さらに言うとうろ覚えながら）列挙してみます。

10月～11月半ば

• 数年単位の大きな目標をでっち上げる
• 「応用情報」試験終了の帰りに、参考書を買う
• データベースそもそもについての知見を蓄える。僕は『楽々ERDレッスン』を買った

最初の「でっち上げる」ってところなんですが、僕はそもそも「XXXX年までにシステムアーキテクトとDBスペシャリストを取って、足元を固めておく」というゴールを打ち立てて勉強していたんですね。なので、応用情報に関しては、去年10月の時点で落ちていても受かっていても、その次の4月はDBスペシャリストを受けよう、と決めていました。ということで、応用情報の試験から開放されてすぐ次の試験に取りかかったのは自然なことだったんですね。

こういう大きな目標を立てるメリットの一つとして、「資格を目標ではなく手段の中に組み込みやすくなる」ということがあるのかな、と思います。「試験に合格する」ではなく「足元を固める」、というところを念頭に置くということです。

3つ目の項目のような動きもその流れで始めました。

で、これって特にDBスペシャリスト固有のtipsなんですけど、あの試験はDB設計と事例分析が配点の多くを占めます。DB設計って、別に試験のためだけの技術じゃないですし、一般の設計ノウハウ本を読んでおくことはものすごい為になった気がします。試験のための設計と実業務の設計はむろん違いますが、ことDB回りに関しては基本的な考えは一緒（具体的にはとにかく正規化）かな、と。

この本は、そのへんの「理想」と「実務」のバランスがすごくよく取れていて、また実際の例に即して（レッスンなので）設計手順を解説してますんで、業務経験を補うという意味でも勧めます。発行年は古いですけど、その間にRDBMSの考え方が劇的に変化したわけじゃないですから。僕にとっては充分役立ちました。

11月後半～

• 早期に、「範囲全体」の見渡しをする
• 見渡したら、最初に過去問第に「体当たり」し、「ショック」を受ける

全体を見渡す、というのは、基本情報を受け始めたときからの癖なんですけど、そもそも全体のゴールが分かっていないとモチベーションが保ちにくいこと、範囲が区切られているとはいえ、各分野は結局どこかでつながっていること、以上2点からまず全体像を把握することを勧めたいと思います。

応用情報ぐらい範囲が広いと逆に辛いかもしれませんが。。。でも、高度試験は特に、各分野が密接に関連しているわけですから。僕は一ヶ月ぐらいで参考書の全範囲を一通り読みました。

ポイントとしては、この「素読み」の段階では、別に問題を解かなくても、着実に一項目ずつ進めなくてもいいということです。マジで意味不明だったら飛ばせばいいという話です。そもそもこの時点で4ヶ月以上残ってるので定着には充分余裕があります。早い段階で全体が見渡せれば、余裕が生まれます。

それに、僕はSQLはほとんど勉強してないです。実務だけで充分な知識がついていたようです。こういう得意不得意が見えてくる、というのも全体を見渡すメリットですね。

で、全部見終わってから一旦実際に出た問題に飛び込んでみる。それも、午前から通しで解くのをお勧めします。

「実問題を解く」のが大事で、上記の得意不得意の分析というのもそうですが、多くの場合、実はそれ以前の問題で、そもそも解ける訳ないんですよね。全体が見えても定着してないんですから。「まだ解けない」という事実を体で理解しましょう。でも、分からないなりに考えてみるのが大事です。

この早期失敗の擬似体験は、試験であがいてみる感じをつかむということと、全体を見渡せたからと言って安心してしまわないようにすること、の二つが大きな狙いです。

僕は素直に、翔泳社の教科書シリーズをメインに使いました。皆さんは2011年度版ですね。。

12月後半～

• 午前問題はとっとと潰す、そして時間を取られ過ぎない
• 午後1を脚元固めする

一度一通り解いてみて、ようやく問題を解きまくるフェーズに入るわけですが……。

情報処理の高度試験では、一番大事なのは「午後1」です。午後2は、午後1が完璧に出来ればその知識とコツで解けます。ただ、午前2はちょっと範囲が違ったりするんで（DBスペシャリストなら、セキュリティやネットワークの問題も出てくる）、専用の対策が必要になります。

そうは言ってもあくまでメインディッシュは午後1です。午前2はぶっちゃけ同じ問題を使いまわしているので、ちゃんと対策すれば数週間で8割は安定して取れるようになるでしょう。そうしたら、もう対策は要りません。6割でいいんですから。むろん、直前にもう一度解いてみるのはアリですが、時間を掛けすぎる必要は全然無いですよね。

あと、午前1を受けざるを得ない状況の人は、いっそ思い切って応用情報技術者を取りましょう。午前1の問題範囲は、DBとほとんどかぶらない一般的な内容で（というか、全高度系試験共通）、ここを対策するのは結構な負担です。それならば、どうせ多くの試験は1年に一度しか受けられないのですし、秋の時間で応用情報の浅くとも広い知識を押さえた方がいいんじゃないでしょうか。応用情報処理資格取得者は午前1免除です。これは大きいということです。

午前2が安定してきたら、午後1の対策に入りましょう。まずは無心で、3～4年分の過去問を解いてください。

1月～

• 午後1のパターンに慣れる
• 午後2からも逃げ出さない

午後1を3～4年分解けば、以下の事実に気づくと思います。つまり、パターンがあるよね、と。

1. 事例分析（これは第何正規形？とかをしつこく尋ねる）
2. DB設計（E-R図とかを書かせる）
3. SQL（穴埋めとかスクラッチとか）
4. 何だか訳の分からないことをさせる問題（インデックスとかリカバリとか）

これ、午後1が4問だったころのパターンなんですけど、3問になってからをふりかえって、2009年度は「1, 2, 3」、今年は「1, 2, 4」でしたね。パターンがまったく無になったということは無いです。

4はDBというか、多分旧アプリケーションエンジニアやシステムアーキテクト的なセンスが要る感じがするんで、ちょっと対策し辛い気がします。1、2、3は対策すれば結果が返ってくる問題形式です。DBスペシャリスト独特の変な作図も慣れればつっかえない程度には書けるようになります（はず。。。）。

過去問は4問時代のものをやるウェイトが増えるでしょうけど、中問1つあたり30分を切る、を目標に頑張りましょう。

同時に、午後2も少しずつ問題を解いていきましょう。何せ全然形式が違うし、大問一つ解くという形式も慣れが必要ですから。理想は午後1は6~8年分、午後2も5年分はやっておきたいところ。

3月～

• ちゃんと、使いやすい問題集を買う。資料や書籍をケチらない
• 毎日何かする

翔泳社の教科書もよかったんですけど、過去問がPDFだったりしたので、印刷とかいろいろ面倒でした。なので、思い切って、改めて問題集を買いました。

この問題集は、午後1、午後2がテーマごとに固まっていて、僕の勉強法では使いやすかったです。特に午後2、印刷したペラペラのハンドアウトでやるのは辛い。。。冊子がいいです。

3月ぐらいになるともう基本知識を一から付けようとか無理なんですが。でも、ちょっとずつでも毎日何かを積み上げましょう。小手先な知識を少しでも付けるのはすごく大事です。59点は不合格ですが60点は合格です。

そして何より、毎日何かしてきた、という実績を積むことで、本試験での精神的余裕が生まれます。

あとは……対策しても落ちる時は落ちます（w　対策不足だ～とかクヨクヨしてても意味ないです。どうせ数年掛けて取るつもり、と割り切って、本試験では余裕の態度で受けましょう。

全体のふりかえり

Keep

• 「しないこと」を決めたのはよかった。午前問題はもうやらない、とか
• 全体を最初に見通したのは、プレッシャーの軽減につながった気がした
• 勉強の目的は「合格＝３」：「知識、知見の取得＝７」の割合で

何だかんだで範囲が広いですから、優先順位を付けましょう。午前問題は後半はほとんどやりませんでした（直前ぐらい）。　この「やらない」って勇気が要りますが、実際午前2が100点でも65点ぐらいでも通過点は通過点なのですから……。大事なこと、よりハードなことにリソースを集中させるべきです。

全体を見渡すことの重要性は、前述の通り。

あと、「知識の足元固めをする」方でモチベーションをコントロールすべきなんですが、そうはいっても「資格を得る」ってでかいですし、何より合格すると気持ちいいですよね（w　合格のための小手先の技も積極的に身につけましょう。でもそっちに走りすぎても目的がブレます。なので、３：７。

Problem

• 最初から飛ばしすぎて、後半息切れした感がある
• 「何もしてない」期間がちょっと出てしまった

この二点は密接で、3月頭とかは息切れでほとんど何もしていなかった気がします。。。

継続性とか習慣性が大事な気がします。あと、建て直し。一週間ぐらいサボっても平気な顔で学習継続のループに戻っていけるといいですね。再起動を恐れないというか。

ダメループを自分の意志で断つのには気合が要りますが、重要です。何でもいいから再開してみる、例えば午後2の対策がとっくに終わっていても、とりあえず午後2を久しぶりに解いてみる、とかそういうのがコツでしょうか。

Try

• 自覚的なモチベーションコントロール
• 論文対策をする
• 進捗をメモ程度のものでも記録する
• 「直前対策勉強会」的なものに一回は行ってみる？

試験対策って要するに勉強なんですけど。でも、何のために資格という形で一つの体系立った知識を勉強するかっていうと、勉強したこと業務とキャリアに生かしたいからですよね。何が言いたいかというと、くどい感じですけど、僕等の仕事は勉強が日々の業務で、日々の業務が勉強だと思うんです。

資格勉強で覚えた正規化理論を仕事で使ったり、逆に実務経験で覚えたSQLで点を稼いだり、そういう感じだと思うんです。

勉強の自己目的化は一番避けたいことだ。

モチベーションコントロールというか、「何のために？」「どうやって？」「何を？」っていうのを念頭に置きつづけることが、最大のパフォーマンスを出すコツなのかなと思います。5W1H(2H)って大事ですけど、僕はその中でも「What」「How」「Why」が特に大事で、後ろに行くほどより大事、そう思っています。

精神論臭くなってしまいましたが。。。

一応常々気をつけてはいますけれど、この辺のモチベーションコントロールに自覚的になりたいんですよね。2010年度SA試験は、そこが一番のTryになると思ってます。

あとのTryは細々としたものですが、「論文」はいままで受けたことのない形式なので普通にチャレンジで、あと進捗記録も、前回はここはいい加減だったのでやってみたいということ。

それから、せっかく対策している人はたくさん居るんですから、同じ目的の人たちでなんらかの人のつながりを作れたらな～とも思います。論文対策勉強会とか、ちゃんと調べて行ってみたいです。

＊　＊　＊

うまくまとめられた気がしないし、参考になるのかはなはだ不明瞭ですが書いてみました。ぼちぼちと直すかもしれません。

取り急ぎ、右サイドバーに「バーンダウンチャート」が出現しています。。。どうなることやら。

複数の引数をとる関数を、引数が「もとの関数の最初の引数」で戻り値が「もとの関数の残りの引数を取り結果を返す関数」であるような関数にすること。

http://wiki.onakasuita.org/pukiwiki/?%E3%82%AB%E3%83%AA%E3%83%BC%E5%8C%96
http://ja.wikipedia.org/wiki/%E3%82%AB%E3%83%AA%E3%83%BC%E5%8C%96
など参考

最近は「関数が第一級のオブジェクト」、要は「手続きの固まり」を文字列や数字のようにモノ扱いできる、RubyやJavaScriptのような言語が普及しているが、そういう言語では「カリー化」の手法が使える。

例えばRubyで、x個の、yから始まる数の総和を求めるorigという関数を考える。

1
2
3
4
5
6
7

def orig(x, y)
  ret = 0
  for i in y..(x + y - 1) do
    ret += i
  end
  return ret
end

（※）

このorig(x, y)を元に、「3個」「4個」「5個」の、yから始まる数の総和を求める関数を作りたい。下の如し。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

def curried_orig(x)
  lambda do |y|
    orig(x, y)
  end
end
 
sum3 = curried_orig(3)
#=> #<Proc:0x0000002a955cf098>
sum4 = curried_orig(4)
#=> #<Proc:0x0000002a955cf098>
sum5 = curried_orig(5)
#=> #<Proc:0x0000002a955cf098>
sum3[10]
#=> 10+11+12 = 33
sum4[10]
#=> 10+11+12+13 = 46
sum5[10]
#=> 10+11+12+13+14 = 60

sum3やsum4に束縛されるのは、実際にはメソッドというよりProcオブジェクトなので、()ではなく[]で呼び出す。

Ruby1.9.1からは「Proc#curry」が導入され、よりすっきり書ける。

1
2
3
4
5
6
7
8
9
10

sum_x = lambda {|x, y|
  ret = 0
  for i in x...(x + y) do
    ret += i
  end
  return ret
}
sum3 = sum_x.curry[3]
sum3[10]
#=> 10+11+12 = 33

数学的な概念は良く分かっていないけど。

http://www.nslabs.jp/closure.rhtml

「カリー化」とは (A, B) -> C という関数をA -> (B -> C) という関数に変換することです。

http://www.khelll.com/blog/ruby/ruby-currying/

Check this function f which takes 3 params x,y,z

f(x,y,z) = 4*x+3*y+2*z

Currying means that we can rewrite the function as a composition of 3 functions(a function for each param):

f(x)(y)(z) = 2*z+(3*y+(4*x))

http://www.ruby-forum.com/topic/142699#633354

It’s not difficult at all,

1	proc {|x, y, z| x + y + z }.curry

returns the proc object equivalent to

1	proc {|x| proc {|y| proc {|z| x + y + z } } }

実際利用する時に「関数の部分適用」と「カリー化」を区別する意味ってあまり無いかもしれないんだけど。「Proc#curry」はこういう意味ですよ、というのは認識したほうがいいのかも。

その他のカリー化の使い方例　参考：「Fun with Procs in Ruby 1.9」
http://pragdave.blogs.pragprog.com/pragdave/2008/09/fun-with-procs.html

＊　＊　＊

※：　個人的に普段はこう書いてしまい俺気持ちが悪い。

1
2
3

def orig(x, y)
  (0...x).to_a.map{|v| y + v}.inject{|d, s| d += s}
end

Erlang

1
2
3

 qsort([]) -> [];
 qsort([Pivot|Rest]) ->
     qsort([ X || X <- Rest, X < Pivot]) ++ [Pivot] ++ qsort([ Y || Y <- Rest, Y >= Pivot]).

from http://ja.wikipedia.org/wiki/Erlang#.E9.96.A2.E6.95.B0.E5.9E.8B.E8.A8.80.E8.AA.9E

Haskell

1
2

qsort [] = []
qsort (x:xs) = qsort [y | y <- xs, y < x] ++ [x] ++ qsort [y | y <- xs, y >= x]

from http://d.hatena.ne.jp/salmonsnare/20090414/1239690094

OCaml

1
2
3
4
5

let rec quicksort = function
    [] -> []     (* base case *)
  | hd::tl ->
      let (lt, gt) = List.partition (fun i -> i < hd) tl in
        (quicksort lt)@[hd]@(quicksort gt);;

from http://www.i.kyushu-u.ac.jp/~bannai/ocaml-intro/first_use.html

Scala

1
2
3
4
5

 def qsort(list: List[Int]): List[Int] = 
   list match {
     case Nil => Nil
     case pivot::tail => qsort(tail.filter(_ < pivot)) :: pivot :: qsort(tail.filter(_ >= pivot))
   }

from http://en.wikipedia.org/wiki/Scala_%28programming_language%29#Functional_programming

所感

• 一つ読めればみんな読める（僕の場合まずErlangを一通りやったんだけど、他のもまあ、同じ考えかなって）
• 関数型だとQuick Sortって直感的な気がする
• リスト内包表現があると短い
• 再帰、パターンマッチング、carとcdr的なもの
• というか4つともシンタックスハイライトが効いてて驚愕

おまけ

• Rubyの場合

どうとでも書けるけど、こう書けますよね。

1
2
3
4
5

def quick_sort(*args)
  return [] if args.empty?
  pivot = args.pop
  quick_sort(*args.select{|v| v < pivot}) + [pivot] + quick_sort(*args.select{|v| v >= pivot})
end

「Array#pop」という明らかに副作用のあるメソッドを使った方が短くなる。。とはいえ、大体同じ考え方で書けてしまいます。

追記。もっとひどくて短い書き方を思いついた。。

1
2
3
4

def quick_sort(*args)
  return [] if (pivot, *tail = args).empty?
  quick_sort(*tail.select{|v| v < pivot}) + [pivot] + quick_sort(*tail.select{|v| v >= pivot})
end

そんな日に資格について考えてみた。今日池袋のジュンク堂寄ってきたので、ついでにじろじろ見てきたこともあり。

データベーススペシャリスト

来年春受けるつもりで勉強してる。クソ難しいらしいが、制度が変わった去年は合格率が7～8％から一気に10％越えになったらしい。応用情報その他と同じく、「絶対評価で」全試験6割取れればいいらしい。

そうは言っても日本に1万人ちょっとしか合格者がいない（旧制度から数えて）。

過去問題をやり始めたのだけど、知識で落ちるというより（午前２大丈夫そう）、解答のノウハウで落ちる感じ。言ってる意味がさっぱり分からんことはないけど、意図するところを日本語にするのが大変困難。自分の頭でなくて、「データベーススペシャリスト」の頭で考えなければならない。

あと体力……（w

今んとこは半年先なので不明だが、やってて「不条理な試験だ！」　とかそこまでは思ってないので頑張りたいところ。

システムアーキテクト

来年秋に受ける予定だが、丸一年後なので今言ってもなあ、というところ（w

でも、最近気づいたけど、僕あんまコーディング好きじゃないっぽくて、むしろシステムアーキテクトの想定する所の仕事の方が楽しめる気がする。冗長構成とか？　パフォーマンスとか？　仮想化とか？　そういう知識をもうちょっと欲しい。

あと、プロマネは僕の年齢と業務経験的にやりすぎかなあとも思うし、セキュリティとか他のスペシャリスト系は、DBを取れば十分技術のアピールになる、ということと、あと色々持っててもアピールポイントがブレてしまう気がする。

ということでちょっとずつでも知識を付けていこうかと思う。

でもまあ、DBの方が優先順位高いです。

Ruby技術者認定試験

先ずもって意味があるのか、というところからなんですけどね（w　半年先の試験にずっと集中するのも何なので受けてみようかと考えている。なにしろCBTだから気軽に受けられそう。就活思い出すな。。

しかも今、無料リテイクキャンペーンなるものをやってるので、一回落ちて再受験しても、結果一回あたりの試験料は7,500円で済むし。国家試験並みだなー。相当盛り上げたいんだろうな。

最終的にSilver、Gold、Platinumの三段階があるらしい。今はSilverしか受けられない（これも微妙。Silverなんてすぐ価値がなくなっちまわないか？）。。

TOEICとか

無限に英語から逃げつづけるわけにも行かないので、どこかのタイミングでやりたい。うーん、とはいえ英語なんてすぐ思い出せそうな気もするし、大変な苦労をするような気もする（w

リスニング対策は今からでもやればいいんだけど。ちょっと気分が乗らないので何もしていない。ダメだわ。。

点数すら分からない、という状態が今なので、ずっとそれは避けたいんですよね。

まとめると、実務ですべての力が付けばいいんだけど、そういうわけにも行かないので勉強頑張りましょう。逃げてはいけません。

ところで、、、受験シーズン本格化ですね。

こういう風に一人で色々勉強していると、頑張っている受験生の姿とかは（何か変な立場だけど）勇気づけられたりもするので、何というか皆さんの成功をお祈りしています。僕も成功するよう頑張ります。

正直、僕の理解力では何度も読み直さないといけないし、でもそうするに足る本だと思う。

感想を羅列。

• 書籍全体にあふれる「RDBMSへの愛情」が素晴らしいと思った。愛に溢れる語りは、僕は読んでいてとても気持ちがいい（って技術書なのだけど)。。
• DB設計のとこのみならず、RDBMSのアーキテクチャとかSQLのしくみとか全体的に押さえてあるので、「データベーススペシャリスト」の勉強を本格的に始める前に読んだのは正解。
• 発行年が2006年4月で、古いのが気にかかる。。
• 最終章「楽々ERDレッスン」は内容濃厚。素読みでは理解できた気がしない。。

文章はかなり読みやすいので、DBで頑張ろうという方にはおすすめです。

まあ、僕が言うまでもなく、ウェッブ上たくさんいいレビューがあるんでそちらもご参照くださいね。。