カテゴリー別アーカイブ: 仕事論

Oracleアーキテクチャをどのように理解するか

私がDBAになったきっかけ

私は20代に某官庁で大型汎用計算機の仕事に携わった経験があったのですが、その後の異動で30代半ばまでITとは全く別の世界で生きてきました。

元々コンピュータは自分に合っているという意識があったので、民間で本格的にITに携わってみたいと転職をしました。

最初はそれまでの所属官庁と関係の深いあるSIerに入社し、そこで初めてOracleデータベースに触りました。汎用計算機時代にやっと出始めた初期のRDBMSに少し携わる機会はあったのですが、COBOLから従来型のファイルシステムの代わりにRDBMSを利用するようなシステムの運用を行っており、民間で見たOracle7 はそれとは全くの別物でした。

その民間会社で恐る恐るOracleの経験をスタートし、約2年後に当時Oracle Master保有率の日本一を争っているような会社に転職しました。

その間はずっとアプリ開発者としてのキャリアを積んでいましたが、Unixも知らなければサーバに触ることも殆ど無く、GUIの開発ツールでPL/SQLのコードをひたすら書く毎日でした。

最初はテーブルのリレーションや実行計画に関する知識もなく、結合の仕方を間違えて発生した重複行を「DISTINCT」で無理矢理1行にまとめるようなおかしなことをやっていました。今思えば赤面モノです。

資格取得に熱心な会社でしたので、転職1年後くらいにOracle Master Plutinum for Oracle 8の資格を取得しました。その後しばらくしてあるネットワークに強い運用アウトソーシング会社からDBA常駐の依頼を受けDBA人生がスタートしました。

仕組みがわかると楽しい

アプリケーションの開発経験はそこそこ積んでいましたが運用経験は皆無です。今思えば無謀な挑戦でしたが、初日にたまたまSQLチューニングを頼まれる機会があり、何とかその場で解決できたので、専門家として少しは認めてもらえました。

ただし、Unix系の経験は殆どなし、サーバやネットワークに関しても同様でしたので、最初の同僚には「思わずめまいがした。」と言われました。

でも、Oracleのスペシャリストはほとんど居なかったので、それなりに期待もされて、ある日上司から社内セミナーでOracleについて話して欲しいと頼まれました。

引き受けてみたものの、何をどう話せばよいのか皆目わからず、日本オラクル社のサイトを探していたら「Oracleアーキテクチャ」の資料がアップされているのを見つけました。

Oracleについて人前で初めて話すというプレッシャーは相当なものでしたが、下手なことはできないとまずはその資料を徹底的に読みこなすことから始めました。

REDOやUNDO(当時はRBSでしたが)、あるいはリスナー経由の接続など、(資格を取っていたにも関わらず)それまで何となくしか理解できていなかったことが改めて明確に理解でき、実際に試すことが出来る環境があったので実地の経験も積んで、初めてOracleが動く仕組みを体系的に理解出来ました。

社内Oracleセミナーは、おかげさまで大変盛況で、半日×2回の講座を希望する人が多すぎてさらに追加の講座を実施するほどでした。

インターネット創世時代から活躍されているネットワーク・エンジニアの方も参加されたのですが、データベースというのはその会社では真空状態のようで、まだまだ未熟とは言えその日から社内的にもスペシャリストとして認知してもらえたように思います。

新人は何を学ぶか?

その後新入社員研修講師や新人向け勉強会のオブザーバをする機会が沢山ありました。未経験者がどのように興味を持ってOracleアーキテクチャを学べばよいのかということについて私なりのイメージが固まってきたので以下にまとめます。

  1. UPDATE文実行の裏でどのような仕組みが動いているかを考える。SELECT、INSERT、DELETEはUPDATEがわかれば理解できる。
  2. 単純なブロック更新の仕組みから発展させ、セッションの確立から、SQL文の解析等どんどん深堀りする。
  3. ユーザ管理のバックアップを理解することでリカバリを考慮した仕組みを理解する。
  4. 自由に再起動が出来る自分専用の検証環境を準備し、参考書等のスクリプト等を実地に確かめる。
  5. プロセスをKillしたり、ファイルを壊してみたり異常状態とそこからのリカバリを確かめる。
  6. 実行計画、統計情報の読み方を覚えて、どのようにSQL文が実行されるかを考える。
  7. OracleもOSの上で動いているものだという意識でOS、ハードウェアについても知識を広げる。

1番目のUPDATE文に関する内部処理の流れをスラスラ何も見ずにホワイトボードに描くことができれば、DBAとしての基礎が確実に備わっていると思います。

いったん筋が通った理解ができれば、そこにどんどん肉付けをして自信を深めることができます。

こういう私もまだ知らないことが沢山あることを自覚していますが、少なくとも初めて「わかった!」と思った時の感動を新人の方々にも味わってもらいたいと心から思います。

書籍紹介:プログラムは技術だけでは動かない ~プログラミングで食べていくために知っておくべきこと

Kindleで即買い

この本は書店で立ち読みをして気になっていたのですが、今朝ひょんなことから著者の記事をEvernoteにクリップしていたのを読み返してみて、非常に心動かされるものがあったので、ベッドの中でiPad miniからKindleストアで即買いしてしまいました。

プログラムは技術だけでは動かないプログラムは技術だけでは動かない ~プログラミングで食べていくために知っておくべきこと [Kindle版]

私のハイライト

Kindle

Kindleというのは本当に便利です。最初自宅ではiPad miniのKindleアプリで読んで、午後から買い物に出かけたついでにスタバでKindle Paperwhiteで続きを読んで、気がついてみたら10章あるうちの9章までを一気に読んでいました。

IMG_5333

Kindleは読んで「いいね」と思った箇所にハイライトを付けることができて、あとから自宅のMacでハイライトした部分をまとめて

https://kindle.amazon.co.jp/your_highlights

のページで見返すことができます。(自分のアカウントでログインする必要があります。)

ちなみに私が付けたハイライトは以下の34箇所です。(数字は読書位置)

  • どれだけ立派なプログラムを開発しても、だれにも使われなければ、作った意味があるのかな? 215
  •  仕事としてのプログラミングとは、「技術自慢をする」のではなく「依頼者・利用者の要求を満たしてあげること」 221
  •  「小俣さんは技術力があるのに、きちんと話ができて、とてもめずらしい人だ」 245
  •  オタク度の高いプログラマに仕事を頼むと「意外と時間がかかる」「そもそも仕上がらない」「融通が利かない」と感じることが多いのです 259
  •  理想が高すぎるのが足を引っ張っている 262
  •  「仕様を満たすためのプログラム構造・データ構造が完璧に固められないと、プログラミングに着手できない 262
  •  行きすぎた共通化が原因 282
  •  凝りすぎた構造は、ほかの人がなかなか理解できず、当人以外はメンテナンスできないという心配も高くなります 290
  •  プログラマとして重要なのは、「依頼者の課題を解決できているかどうか」 298
  •  動くものを見ると、意外と違う意見も出てくるものです 326
  •  こちら側のリーダーが「それならお前に30分やるから、真のJavaと言えるレベルで作れ!」と言い、「かんたんなことだ」となりました。 361
  •  「始めたことはやめない」という意地 378
  •  「何が何でも1日1本分を書き続ける」ほうが重要 381
  •  「開発は引き受けましょう。そのかわり、ドキュメントはこちらの分もそちらで引き取ってもらえないでしょうか?」 417
  •  技術・仕様・分野などで「初めて」手がける際には、そもそも設計を最初から正しくできる可能性は低い 494
  •  多くの失敗プロジェクトは「技術力不足」で失敗したのではなく、「プロジェクトの進め方」に問題があったのだと感じています。 521
  •  新システムの売りである「自分でもカスタマイズ・機能追加ができる」という部分に対して、「自分でカスタマイズなどしたくない」という声が出てきました 565
  •  「自己満足ではダメで、売り手・使い手がきちんと満足できるものが正解」 615
  •  勉強会が盛り上がらない時は「プライドを傷つけられたくない」という思いが原因の1つなのだろうと感じています 679
  •  「この指摘はあなたの人格を否定しているのではなく、業務として必要なことだから」 804
  •  要するに「実績・成果で勝負しよう」と考えているのです。 814
  •  知識で競い合う必要はなく、「得た知識で何をなし得たか?」がポイントだと考えるようにすればいいのです 823
  •  意見が飛び交っている間は、まず説得はできないものだ 851
  •  好きな分野・得意な分野だから、作りたいと思えるのです。 1001
  •  「プロトタイプとして割り切る部分」と「最初からきちんと作る部分」を明確にして、本番にそのまま発展できるようにするのがお勧めです。 1021
  •  機能が多いプログラムは、開発自体も大変ですが、テストも大変です。私は基本的に、ソースを書いたらすぐにその部分の動作確認を行い、1つ1つを確実な状態として積み重ねていきます。全体を組み上げてからテストをしても、ソースの細かいところまで確認することは不可能です。書いた部分は、書いた直後が一番頭に入っていますから、すぐに動作確認するのが一番なのです。 1027
  •  すぐに作り上げるために、ソースやノウハウを蓄積しておく 1192
  •  周囲を巻き込みながら進める(特にテスト) 1194
  •  作っておしまいではなく、それをどう活用するかが大事 1196
  •  見積を要求された場合は、必ずプロトタイプで実験してから提案します。 1204
  •  こんなもの、作れない?」と知り合いから相談を受けて作ったものは「ほぼすべて」完成して、売れました。 1241
  •  IT業界には、技術や知識が豊富な人はたくさんいると感じています。しかし、技術や知識を活かして何かを生み出し、世に出している人はとても少ないと思います。 1289
  •  「相手に自分の専門性を必要とされる」 1386
  •  ・海外での実績がある製品しか選ばない ・日本企業の製品を選びたくても、メーカーが競合相手なので選べない 1786

仕事で実際にプログラムを書く機会は少なくなったのですが、上で挙げたところはIT業界で成功するための秘訣のような気がします。

特に最近ブログを始めた者として非常に叱咤激励される内容でした。毎日20分のブログ執筆を目標にしようと思いました!

すきやばし次郎は高いか?

20分3万円

今日はちょっと技術者の値段について考えたいと思います。

銀座に「すきやばし次郎」というミシュランの三ツ星を何年も獲得している伝説的な寿司屋があるそうです。
オバマ大統領の来日で一躍有名になりましたが、私は当然行ったことはありません。だから全部思い入れだけで書きます。

何でも、おまかせコースが3万円からだそうです。(この「から」というのがとても気になりますが。。。)
にぎり寿司が次から次へと無言で出てきて大体20分で(早い人は15分!!)食べ終わってしまい、お会計は3万円也です。驚きです!

ネットで検索したらこんな記事も見つかりました。
すきやばし次郎が20分3万円の寿司でも客が途絶えない本当の理由

文章を見た限りでは、この記事を書いた方は多分実際には食べてないでしょうし、実際にどんなお客さんが常連なのか調べたんでしょうか?

それにしても20分で3万円!時給換算で9万円!!その辺の回転寿司の店員の時給が1000円としても90倍です!!!

映画と本

2011年にはアメリカ人の監督が作った「二郎は鮨の夢を見る」という映画が公開され、私も最近WOWOWで観ました。

映画の中で私が最も印象に残った言葉は、店主の小野二郎氏が語った「お客さんの前に立った時には9割5分の仕事は終わっている。」というものです。
つまり、店主以外の店員が築地市場への仕入からネタの仕込みまで丹念な仕事をして、最後の5%の仕事は店主が握る熟練の技ということです。

それから「すきやばし次郎 旬を握る」という本を私も買って読みました。小野次郎氏は1925年生まれの88歳。寿司職人になって63年目だそうです。

この本には小野二郎氏が今まで培ってきた技術・経験のうち、文字や写真で語ることができる恐らく全体から比べるとホンの僅かな知識と技が満載です。

例えば、「第2章 本マグロを握る」ではP.97-158まで、本マグロの月毎の断面カラー写真やマグロに関する熱い想いなどがぎっしり詰まっています。何かに人生をかけるということはこういうことなのかと純粋に感動しました。

何度も言いますが私は「すきやばし次郎」に行ったことはありませんし、上の紹介記事のように私のような庶民には確かに行ってはいけない店なのかもしれません。

でも、映画と本を観て読んで、20分3万円の理由がちょっとだけわかったような気がしました。

いつ来るか分からない15分のための準備

我々エンジニアの仕事は一言で「知識集約職業」とでも言えるでしょうか?もちろん他の職業でも同じようなことは言えますが、この仕事は特にそうなのではないかと思います。

以前、ある企業から新人研修の講師として「Oracle入門」を6回シリーズくらいで教育を行うという仕事を請け負ったことがあります。大学を卒業したばかりで右も左もわからないというような集団でしたが、中に数人キラっと光る人達が居ました。

わからないことは積極的に質問してくるし、教えていないこともどんどん本を読んで吸収していく姿は本当に輝いていました。

最近その企業を5〜6年ぶりに訪問する機会があり、そんな教え子の一人と席を並べて仕事をする機会がありました。
今では技術的な打ち合わせもリーダーとして立派に取り仕切っているし、本当に生き生きと仕事をしていることを見て非常に嬉しく思いました。

私が教えた「Oracle入門」は現在の彼の業務とは直接関係ないのですが、机の上にはOracleの参考書が並んでいたり、私が少し専門的なことを話してもびっくりするくらいついてきてくれます。

逆に、かなり経験を積んだようなエンジニアでも時々がっかりする人がいます。知識はいろいろ豊富みたいなのですが、役立つ情報がサッと出て来ない。知識が整理されていなくて何を言っているのかさっぱりわからない。つまり本当に使える知識となっていないのです。

障害が起きた時に本当の姿が見える

IT運用はうまく行って当たり前の世界なので、極稀に起きるトラブル時にエンジニアの真価が発揮されるのではないかと思います。

トラブルシュートのためのコマンドが構文エラーのために実行できない!後ろでは「まだ復旧できないのか!」という無責任はギャラリー達。

こんな時に冷静に問題を分析して、何が間違っているのか知識をフル動員して見極める。こんなエンジニアが真のプロフェッショナルです。

自分の記憶だけに頼って間違ったコマンドを叩き続ける。なぜ冷静にマニュアルを見返せないのでしょう。それから安易にGoogle検索に頼るというのも考えものです。最初からGoogleに頼ると間違った情報に行き着くかもしれません。

Google検索を全面的に否定するわけではありません。最後の手段として活用するのはよいことだと思います。世界中の知識が集まっているのですから。

自分の知識データベースを育てよう

話変わって、「プロとは?」というテーマで最近「いつ来るか分からない15分のために常に準備をしているのがプロ、デザイナー奥山清行による「ムーンショット」デザイン幸福論」という記事を読みました。(これは「運用エンジニアから開発エンジニアになるためにやったこと」というなかなか秀逸な記事からたどっていったものです。)

いつ来るかわからない障害にあるいはいつ来るかわからない支援要請に備えて、プロフェッショナル・エンジニアとしての我々は何をすべきか?

  • 検証環境でとにかく手を動かして、コードを書く。コマンドを叩く。結果を確認する。
  • 文献を読んで重要な部分のコピーを手元に置いておく。
  • 経験・知識を体系的にまとめる

私はこのような用途には、Evernoteは最適な道具だと思います。

私のEvernoteには様々な知識情報が集積されています。「技術情報」というノートブックには1300件以上の「いつ来るかわからない」ことに対して役立つかもしれない情報(ノート)が蓄積されていて、日々増殖しています。

ノートはタグ付けされていて、探したいキーワードを入れると関連するノートが瞬時にピックアップされます。MacBookでまとめた情報はiPadでもiPhoneでもネットワークが繋がっていればどこでも見ることができますし、オフラインノートブックにしておけば電波が届かない場所でも参照することが可能です。

「自分だけのGoogle」これが理想です。

Evernoteを知らないエンジニアはとても不幸だと思います。

知っていても使うことができないエンジニアはもっと不幸です。私が知っているある大企業ではEvernoteのようなクラウドサービスはセキュリティ上の理由でご法度だそうです。

このような会社に限って社内サーバルームに設置してあるファイルサーバが使えなくなって大騒ぎになったりするんですね。

話がだいぶ逸れましたが、エンジニアのためのEvernote活用術は別途書きたいと思います。

結局、すきやばし次郎は高いか?

私がこの業界に入ってまだ日が浅かった頃、あるアプリケーション開発者が1日かけても解決できないことを5分足らずで解決してしまうスーパー・エンジニアが居ました。「ああなれたらいいな」と思って今日まできたと思います。

1日8時間として5分は約90分の1。次郎と回転寿司といい勝負です。でも、結局解決できないのであれば倍率は無限大です。

アマチュアに対するプロのエンジニア、生産性で比べたらミシュラン三つ星のすきやばし次郎にも匹敵する価値があるかもしれません。

価値を感じてもらえる。そんなエンジニアになりたいものです。

でも、一度は次郎に行ってみたい!