Oracle

JPOUGの小田さんのセッションに参加しました

セッションを担当された小田さんから、資料などがアップされました。当日参加できなかった人は確認してみてもいいと思います。また、私も参加したので、会場の雰囲気とか気軽に参加できるのか、などを知りたければお伝えします。
スポンサーサイト

Oracleのユーザー会に参加しました

オラクルの日本のユーザー会(JPOUG)に参加しました。

バーン!オ・ラ・ク・ル!!
JPOUG001

13階、いや青山に来ること自体久しぶりです。少なくとも休日にこのビルに入るのは初めてですね。まあ、見慣れた景色です(笑)
JPOUG002

会場はこんな感じ。結構な人数が参加してました。200人くらい集まってました。なかなかの賑わいです。おっこの前に立って話すの?って広さと人数です(笑)
JPOUG003

さて、小田さんのセッションにパネリストとして参加させてもらいましたが、いろいろな意見が出ていました。参加者の多くはエンジニアという感じで、なんらかの形でオラクルに関係がある感じでした。

一番感じたのは、みなさんそれなりにスキルも持っていてさらなるアップを望んでいる人が多かったです。そりゃ休日にわざわざ時間を使ってセミナーに参加するので志しの高い人が多いはずです。ただ、そういった方にもそれぞれ悩みがありました。例えばオラクルマスターでplatinumを持っていればそれで満足してしまう人も多いですが、それだけで満足せずに危機感を感じて頑張っている人もいました。私なんかオラクルマスターも三世代くらい前のものだし、今のplatinumのほうが余程難しいと思いますが、志の高さがすばらしいなあと思いました。大体こんな私がアドバイスしていいのかも疑問です。お前そんなに偉いの?って(爆)

最後に少しだけ思ったのはユーザー会とはいえエンジニアの集まりという感じでした。オラクルの社員ではなくボランティアで成り立っていて素晴らしいとは思いましたが、ユーザー会というよりはOTNの延長という印象もありました。もう少しユーザー視点があっても面白いかなあと思いました。ってかお前がセッション受け持って話せよ!ってことかもしれませんね(笑)

JPOUGに参加します

前からお話がありましたが、JPOUG(オラクルのユーザー会)に参加します。小田圭二さんのセッションでパネリストとして参加(いろいろ面倒なので会社名や名前は非公開)させて頂きます。結構凄い人が沢山参加するようなので、私のような人間でどんな話ができるのか気になります(どうしよう???)。

ところで最近気になった英語は調べているのですが、パネリストが正しい英語なんですね。よくパネラーともいいますが、間違いだそうです。パネラーだとパネル(板状のもの)を取り付ける人になってしまいます。例えば巨大な鏡を取り付ける人です。まあ、会場でパネラー(大道具さん)として活躍するのもありか?(笑)むしろそっちのほうが得意か?(爆)

話を戻して、一応題材はそれなりに聞いていますが、打ち合わせもまだなのでこれから考えます。ただ参加する前に、そもそもデータベースのエンジニアってなんなんだ?と思いはじめました。あまり疑問に思ったこともありませんでしたが、DBAという職種は異色です。情報処理試験を見ても、データベースの資格だけ異色です。極めて閉じられたら世界で、レイヤーも狭いです。ネットワークやセキュリティと比べてかなり限られた感じがしませんか?ミドルウェアスペシャリストではなく、データベースなんですよ?

もちろん自称データベースエンジニアなんでモデリングからハードウェア、オプティマイザ系のチューニングの話など多岐に渡ることは知っています。でも、データを保存することと、使いたい時に取り出すということだけのためのエンジニアってやはり狭いと思います。特に現在ではデータベースエンジニアエンジニアといえば、RDBが中心ですし。

そこで、そもそもデータベースエンジニアっていつまで必要なのかを考えてみました。データベースのエンジニアがこれだけ重要視されるのは、データベースが複雑で求められるものが多く、ビジネスに直結しているからです。求められる大きな軸は可用性と性能だと思いますが、現状ではどちらも手軽に実現できません。OSやAPサーバーなどのミドルウェアはこの2つの要素を比較的手軽に実現できるようになり、相対的にエンジニアの単価も下がった気がします。

では、データベースが同じようになるのはいつでしょうか。個人的にはRDBの安定性は5~10年くらい前から比べると飛躍的に高まったと思います。しかも前回書いたハードの性能も高まったので性能も得やすくなりました。つまり、個人的にはデータベースがコモディティ化される時も近いのではないか、と思います。

さて、そうなると相対的にデータベースエンジニアの価値は下がります。最も一部のスペシャリストはそのままでしょうが、中間層は価値が下がってしまうでしょう。では、今からデータベースを学ぶのはあまり意味のないこと(時間の無駄)なんでしょうか?私はそうは思いません。。。おーっと続きを書こうかと思いましたがあまり書いてしまうとJPOUGの私のネタバレにもなるかもしれないのでこの辺で書くのをやめておきます。知りたい人はJPOUGで会いましょう。なーてね(笑)

なんか宣伝みたいになってしまった。。。

即戦力のOracle管理術

「あうふさん、ヤマトさんから宅急便が来たみたいですよ」、「ん?何それ?俺に???」というのが5月末日のある日の出来事でした。私はコンビニ弁当を食べていたので「なんだろ、めんどくせーなー。最近会社に配送されるものなんてないはずなんだけどなぁ」と思っていたら、それを察したできる後輩が「私が受け取ってきましょうか」と言ってくれたので「よろしくー」とお願いしました。持ってきてくれて見てみると送付元が技術評論社になっています。「日経さんならまだしも知り合いいないしなあー」と思っ開けてみると「即戦力Oracle管理術」という本が入ってます。「あー随分前に小田さんと飲んだ時に話したこの本出たんだ。おー!近藤くんも立派になったもんだ」と思いながら本を開きました。

即戦力のOracle管理術


いきなりですがこの本はべた褒めできるほどの出来ではないと思いました。先日出版された絵で見てわかるOracle設計と比べるとちょっともの足らない感じがします。問題は2つあるのですが、その前に良かったところを紹介します。

良かったのは第4章でトラブルの予防と対応が書かれています。ここに着目した本はあまり無いと思います。特にケースごとに書かれている部分もあり内容も書き方も面白いと思います。私も自分のプロジェクトで同じようなまとめ方をして苦労したので面白いと思いました。本の構成もあるのでしょうが、もっと書いて欲しい内容です。極端なことを言えば、この内容だけの本で良かったと思います。

さて、逆に良くないところですが一つ目は本のターゲットと目次がよくわからないところです。一つ一つの内容は非常にいいものも多いのですが、この本で何を言いたいのかが伝わってきません。読者ターゲットって誰だ?というのがイメージできませんでした。私なら思い切って、運用のべからず集や、ORAエラーの逆引き解説、運用を大切にしたシステムのベストプラクティスなど、直感的にわかる書き方にします。そういう切り口で運用を語れば面白いと思います。この本の構成を考えた時に誰に読んで欲しい本なのかをもっと明確にすべきだったと思います。一応裏表紙にも書いてありますが曖昧だと思います。。。

二つ目は、本の視点がオラクルコンサルタントとしての視点になってしまっています。システムの利用者目線ではありません。オラクルの人間かオラクルが大好きなDBAにはいい本かもしれませんが、恐らく読んで欲しい人はそういう人ではないと思います。ほんの少しの違いなんでかなりもったいないです。

とはいえ、書いているコンサルタントが日々全力で仕事しているのも目に浮かぶし、それらのノウハウがまとめられているのもわかるので、なんとも歯がゆい気持ちで読みました。

最後に、本を発売前に頂いておきながらこんな記載になってしまい申し訳ありません。正直どうするかかなり悩みましたが、私の率直な感想をあえて記載させて頂きました。

OracleOpenWorld二日目

OOW2012

今日はラリーエリソンの基調講演とNKSOLさんの事例を聞きました。

基調講演は率直にいうと少し残念でした。もっとコンセプチャルな話やビジネスビジョンの話をして欲しかったです。製品の数字の羅列は個人的にはあまり興味がありませんので。。。

そんな中から感じた部分を書きます。冒頭と最後でアップルの話をしていました。アップル製品はハードとソフトのオールインワンを達成し成功しましたという話です。オラクルも同じようにハードとソフトを融合させてEXAシリーズを出しました、と話していました。ただ、この話は一見似ていますが、根本は大きく異なる気がします。理由は2つあります。

一つはスティーブジョブズのこだわりとラリーエリソンの考え方の違いです。スティーブジョブズの根本にあるのは、「俺の造る製品は誰にもカスタマイズして欲しくない!俺の思い通りに使ってほしい」というこだわりです。昔からのアップル製品を見るとかなりそのこだわりが感じられます。逆にラリーエリソンはどうでしょうか?ハードにこだわるのはわかりますが、「俺が完璧なものを造るからカスタマイズせずに安心して使ってくれ!」という根本的なこだわりは無いように思えてしまいます。自分が感じるのはこの信念の違いです。強調するのがコストであるということから、製品コンセプトを愛しているというよりも、あくまでもビジネスとして考えていると感じてしまいます。

もう一つはバックグラウンドの違いです。アップルが目指したのはコンシューマー向けです。対してオラクルが目指しているのはエンタープライズ領域です。オールインワンを目指す場合コンシューマー向けのほうが圧倒的に有利です。何故ならエンタープライズ向けは完全な同一製品を使いずらいからです。コンシューマー向け、例えばiPhoneであれば多少のアプリケーションの違いはあれど、使い方はそこまで違わないものですが、会社の業務内容も規模も大きく異なるエンタープライズ向けではそもそもオールインワンを目指すのは大変です。そういう意味でオラクルの目指すオールインワン戦略はアップルよりも厳しいと思います。

最後の質問で面白いものがありました。オールインワン戦略はベンダーロックインにならないか?という質問です。その質問に対してラリーエリソンは多くのプラットフォームでオラクル製品が動くのでコストが安いほうを選べばいいという話でした。つまり、ミドルウェアとハードウェアを切り離して持っていけばベンダーロックインにはならないでしょうということです。しかし、この回答では元々のコンセプトを否定してしまいます。自分が最も期待したのは、「アップルのように抜群に良いものを造ります、それがロックインになったとしても」という回答でした。そこまでのこだわりがあるなら共感できましたが、なんとも歯切れの悪い回答でした。まあ、言いたくてもそんなことなかなか言えないでしょうし、求めるのが酷だとも思いますが(笑)そういう意味でも自分のこだわりを貫き通したスティーブジョブズは偉大だったんだなあと思います。


NKSOLさんの事例については、概要を伺ったこともあったので、内容は多少知っていました。ただ、改めて発表内容を聞くと、よくもここまで効率的にできているなあと思いました。

そこそこディープにオラクルを扱った人ならある程度思いつく内容ですが、実践するとなると話は別です。予算を取ってプロジェクトとして最後までやるにはパワーも忍耐力もまじめさも必要です。それをやり切った結果が障害ゼロなんでしょう。

あと、深く感じたのは障害をゼロにするというこだわりを強く感じました。最近、自分の中では少し感覚が変わってきていて、障害を起こさないよりもやりたい業務が継続できることが大事で、誤解を恐れずに言うと小さな障害が起きても業務に影響がないのであれば構わない、若しくは多少復旧までの時間がかかることが許されるシステムなら時間内に復旧すればいいという感覚があり、感覚のギャップを感じました。最近は可用性よりもコストを求められることが多いからなんでしょうかね。。。可用性とコストは反比例しますので。

ともあれ、二日目もなかなか面白い内容でした。知り合いとも何人かご挨拶できて良かったです。

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。