データベース・アーキテクト・サミットレポート

トムが説く、エンジニアがしてはならないこと

加山恵美
2010/3/2
Oracleエンジンそのものをデザインする男、トム・カイト。カリスマエンジニアが説明する、陥りやすい「ぼくたちの失敗」とは? 「Database Watch」の加山氏によるデータベース・アーキテクト・サミットレポート(編集部)

 2010年2月9日、日本オラクルは「データベース・アーキテクト・サミット - ask Tom Live -」を開催した。オラクル技術の中枢にいるトム・カイト氏が初来日し、エンジニアに技術解説から心構えなど多岐にわたりアドバイスした。

オラクル技術のカリスマ、トム・カイト

オラクル・コーポレーション
サーバー・テクノロジー部門
シニア・テクニカル・アーキテクト
兼エバンジェリスト
トム・カイト

 日本ではなじみが薄いかもしれないが、「オラクルのトム・カイト」といえば知る人ぞ知るカリスマ的な存在だ。「エバンジェリスト」と同時にオラクルで希少な「アーキテクト」の肩書きも併せ持つ。オラクル技術の頭脳である。1987年からOracle Databaseを使うようになり、1993年からオラクルに入社。同社「ask Tom」という有名なQ&Aサイトの立役者だ。多くのエンジニアが彼を慕っている。

 イベントではカイト氏は「What are we still doing wrong?」と「Top 10 Things about Oracle Database 11g Release 2」の2つのテーマで講演し、最後に参加者からの質問に答えた。冒頭の講演はエンジニアにありがちなよくない習慣を指摘し、役に立つWebページを多数挙げながら、どうすべきかを諭した。本記事ではエンジニアへの教訓を凝縮した冒頭の講演を中心にレポートする。

いつもの失敗パターンから脱却しよう

 カイト氏が取り上げたのはベストプラクティスならぬバッドプラクティス、ありがちな失敗パターンである。

●Underestimating Complexity
(複雑さの過小評価)

 単純そうに見えて、実は背後にさまざまな問題が絡んでいる場合がある。カイト氏はContrastというブログの記事「THERE ARE NO SMALL CHANGES(小さな変更なんてない)」を挙げ、プログラム変更時の工数を甘く見積もるなと警告した。

【関連サイト】
Contrast
THERE ARE NO SMALL CHANGES
http://www.contrast.ie/blog/there-are-no-small-changes/

 例えば「この記入部分(テキストボックス)を『140文字まで』に変えてもらいたい」と文字数制限を持ちかけられたとしよう。それで「なんだ簡単。記入する部分のコードを見つけ、140文字で切っちゃえばいいんだろ?」と思うかもしれない。

 とんでもない。

 これまでに入力された140文字を超えるデータはどうする? インターフェイスはそのままでいいか? エラーメッセージは何と書くか? 急に仕様を変更してユーザーが納得するか? どのブラウザでも正常に動作する? どういう処理にする?

 あらゆる問題が噴出する。これらを後手後手に対処すると問題がこじれてしまう。たとえ小さな変更でも甘く見ることなく、広範囲に目を配らせなければならない。簡単な修正と思えてもすぐにコードに手を出すのではなく、事前によく検討することだ。

●Not knowing how to ask for help
(助けてもらうための質問の仕方を知らない)

 「Ask Tom」サイトに限らないが、Q&Aサイトでは質問が下手な人がいる。困っているのは分かるが、質問が的を射てないなら問答が迷走するだけだ。ネットに助けを求めるなら、自分の問題を素早く解決するために効果的な質問の仕方を会得するべきだろう。

 ポイントはできるだけ状況や不具合を明確にすること。どういう状況でどんなエラーメッセージが出たのか、問題が起きる状況を特定する。すると読んだ人が何が問題か回答しやすい。そして判断に必要な情報も添付するのも不可欠だ。パフォーマンス上の不具合を質問するなら、サーバのスペックなども明示すべきだ。ただし無関係な情報は出す必要はない。よく考えて取捨選択しよう。

 加えて自分の目的を示すのもいい。「○○が使えません」より「こういうことを実現したいのですが、○○が使えません」と質問する方が、「それなら××を使うといいですよ」と読んだ人が別の方策を提案してくれることもある。ただし、何でも聞くのも迷惑だ。カイト氏はいわゆる「教えて君」に言及したブログを例に挙げた。

【関連サイト】
The Old New Thing
Programming means that sometimes you have to snap two blocks together
http://blogs.msdn.com/oldnewthing/archive/2009/08/04/9856634.aspx

 これは筆者の個人的な付け足しだが、アドバイスをもらったら、あとでお礼と成功したかどうか報告することをおすすめする。それは礼儀でもあるし、次に質問したときに回答を得られやすくなるからだ。書き逃げでは相手に悪い印象を与えかねない。

fig1
  1/3 次のページへ

Index
トムが説く、エンジニアがしてはならないこと
→

Page 1
オラクル技術のカリスマ、トム・カイト
●複雑さの過小評価
●助けてもらうための質問の仕方を知らない

Page 2
●無駄にコードを長くしてしまう
●うまくいっていると思わせがち

Page 3
●セキュリティは重要な問題
●データベース管理者と開発者は違いを乗り越えよう
●ベストプラクティスとは

Database Expert全記事インデックス


Database Expert フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

注目のテーマ

Database Expert 記事ランキング

本日月間
ソリューションFLASH