スイーツ（笑）と呼ばないで!!
|
| |||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
05/18/22:49 [PR] |
11/11/18:27 DBはまず学び、それから考えよ。==================== 【はじめに】 今日はこれから上から目線で偉そうなことを書きます。 最近、社外のPG仲間がダメなDB設計のせいで苦しんでいるのを見て、いつか言いたいなと思いつつ言わなかったことを書きます。 ==================== あなたの専門は何ですか? と聞かれたら、たぶん、私はデータベースです、と答えます。 社会人1年目の春、研究所時代に ・国家試験のデータベーススペシャリスト ・オラクルマスター ・SQL ServerのDB設計分野でのマイクロソフト認定プロフェショナル 等の資格をとり、 その後もデータベースを自分の専門分野として研究に勤しみました。 実戦も、アドバイザリー業務を含めれば、関与したDBは数百件。 理論面、実践面、共に一応専門家を名乗っても良いのではないかと無謀にも自負しています。 そんな私だからDBに関する技術談義が好きでいつもやっているかのような印象を持たれるかもしれないですが、理論的なバックボーンない方々とは、基本的にDBに関する議論はしません。 これは非常に驕り高ぶったように思われるかと思いますが、そのような方々と行うDBに関する議論は、単なる宗教論争になるからです。 実戦の中から経験則で帰納的に良い設計理論を構築しようというのは無謀だと思います。それでは圧倒的に参考事例の数が足りません。それなりのものが出来上がる頃には引退する年になっているのではないかと思います。 それよりも、世の中の数多くの専門家が研究に研究を重ねた結果導かれた理論を学ぶ方がはるかに効率が良いと思います。また、RDBのコアな理論は数学的に導かれるものなので、ブレはありません。 その上で、実戦では、ポリシーによって、どの理論をどこまで適用するか、ということを考えます。このレベルであれば、DBに関する議論も意味を持つと思います。 例えば、非常に初歩的ですが第一正規化というのがあります。 みなさん、正規化、非正規化という言葉、正規化には第何正規化というのがある、というくらいは知っているかと思います。ただ、その実際の中身、目的、制約事項などを理解していないと、”考える”ということはできません。 第一正規化であれば、繰り返しを排除するわけですが、時として状況によっては、非正規化(正規化崩し)をすることもありえます。 例えば、全く更新がない大量のログのようなテーブルで繰り返しの回数も確実に固定されていて、参照する際に経験豊かではないオペレータがDBを直接覗きに行くことが10年に1回くらいあるようなテーブルなどはこのケースに該当すると思います。 結局、第一正規化にはその目的があり、その目的よりも重視する別の目的があればそれを採用しないのは当たり前かと思います。つまり、第一正規化の目的をはっきり理解していれば、それを辞めた時のシステムへの影響も想像することができます、それで初めて非正規化してOKかどうかというのは判断可能なのだと思います。 別の目的というのは、パフォーマンスだったり、上記のような特殊な要件での視認性だったり、その他様々な必要性から来ることが多いと思います。それらのメリットが、非正規化した時のデメリットを上回れば、それは非正規化した方が良いです。 つまり、DB設計において、”考える”とは、いくつかの取りうる設計の選択肢のメリット・デメリットを計算し比較し、その案件では何を一番重視すべきかというポリシーのバイアスをかけた上で、”選択する”ことだと思います。 理論的な枠組みのある人は、あるシチュエーションにおいて、まるでレストランで席に着いた時にメニューを見るような感じで目の前に選択肢が見え、その中でベストなものを選択することができます。 将棋のプロは定石を学び、その定石を適用すべき状況を学び、メリット・デメリットを学び、その上実戦例としての過去の棋譜を読み、そして初めて、”考える”のだと思います。 DB設計においても同様のことが言えると思います。 DB設計で悩んでいる暇があったら、まずは一通りの基礎を学ぼう、と言いたいです。今後の長いDB設計人生で言えば、それはほんの一瞬と言えるほど短い時間です。その上で、初めて”考える”という旅に出ましょう。 DBはまず学び、それから考えよ。 全ての、PGからDB設計の勉強をせずにそのままDB設計する立場となった人々に捧げます。 偉そうですみませんでしたm(_ _)m
PR
|
10/28/19:18 ネット投票に関する情報技術上の大事な論点基本的に、選挙の際には相当の理由がない限り投票に行く。 その日に予定が入りそうだなと思うときは、事前に不在者投票に行くことにしている。 そんな私ではあるが、やっぱりネットで投票出来れば便利なのに、という気持ちになることは多々ある。 そうしたらもっと投票率も上がるだろうに、と。 で、それをやらない理由は、個人情報流出とか、他の人のなりすまし投票とか、横に誰かが付いてて無理やり投票させられるのを阻止できない、とかを気にしているのかなー、と思っていた。 まぁ、最後に挙げた、横に誰かが付いていて・・というのはパッとは解決策が浮かばないけど、でもそれ以外の情報技術上の問題は、なんだかんだで最近は個人認証の技術や暗号化の技術も発達しているし、なんとかなるでしょ、って思ってた。 作ろうと思えばウチの会社でもそのシステムは作ることができる。 でも、この前勉強していて、 なるほど、これはちょっと厄介な問題だなー と初めて理解したことがある。 今日はそれを紹介したい。 日本国憲法の第15条の最後の方に 「すべて選挙における投票の秘密は、これを侵してはならない。」 というのがある。 これが実は厄介な問題。 つまり、 投票行為については、個人をきちんと認証しその本人が間違いなく投票しているという事実を担保しなければならない、 その一方で、 誰が誰に投票したか、については、投票の秘密は守られなくてはならず、遡って個人を特定できてはならない、 ということ。 もし、国家権力が投票データやアクセスログから誰が誰に投票したかを知ることができるとしたら、時の権力者が自分たちに反対する有権者に対して粛清をすることも可能となる。今の平和な日本では考えにくいが(お隣の国では行われているが)、憲法とはそもそもそういった国家権力の暴走を牽制するためのものだ。 と言うことで、一見簡単そうに思えるネット投票システムも、結構面倒なことのようである。 ただ、いま世界中でこの個人認証・暗号化と匿名性の確保の二つを両立させるための研究が行われているらしいので、そのうち、ネット投票が実施される日も来るだろう。 一見簡単に思えるが行われていない背景には、実は自分が理解不足で知らないだけで複雑な問題があることもある、と言うお話でした。
|
09/20/15:46 「技術的に可能か?」という質問について立場上、時々別のPMから 「……というのは、技術的に可能でしょうか?」 と相談を受ける。 こういった質問への回答は一瞬戸惑うことが多い。 なぜならば、文字通り質問を解釈すべきでない時が多々あるからだ。 世の中で実現されている技術であれば、それは”技術的”には可能であろう。 ただ、その情報だけでそのPMが判断を下すことは適切だろうか? 技術的には可能でも、自社の得意分野と異なれば技術力的に不可能なこともある。 そこを意図するのであれば、 「……というのは、ウチの技術力的に可能でしょうか?」 と聞いてほしい。 さらに、技術力的に可能だとしても、現実の制約条件のもとでは不可能ということもある。 例えば、1から10万の数字を計算機で足していくというプランについて考えてみよう。 足し算するというのは、理屈上どんな数字であっても可能なので、技術的には可能だ。 また、大抵の人は、計算機を使って、足し算をする力はあるから、技術力的にも可能だ。 ただ、現実として、各種制約条件からその案を採用することは不可能かもしれない。 制約条件や目標を意識する上で、PMであればおそらく次の3つの視点はもっているだろう。 もともとは製造業の世界の用語だが、今では広くビジネスの世界全体で用いられているいわゆるQCDというものだ。 1.Quality(品質) 2.Cost(費用) 3.Delivery(納期) 前述のプランは、計算間違いが起きる可能性が高く品質的にも問題があるかもしれないし、単純作業ではあるが予想以上に人件費もかかるかもしれないし、正確に計算が完了するまでの時間も結構かかるかもしれない。つまり、どのような制約条件や目標のもとで考えるかによって答えは異なる。 そこを意図するのであれば、 「……というのは、…という品質で、…くらいのコストで….までに実現することは、ウチの技術力的に可能でしょうか?」 と聞いてほしい。 先ほどの1から10万の数字を計算機で足していくというプランであれば、例えば 「1から10万の数字を計算機で足していくというプランを、絶対に間違いないレベルで、アルバイトへの支払いを1,000円で、30分後までに完了することはウチの技術力的に可能でしょうか?」 と聞かれたら、不可能と答えるだろう。 そんなわけで、可能かどうかの話をする場合には、制約条件をどこに設定するかそれを共有することが大事だよ、という話。 ちなみに、蛇足だけど、もしも目指すところが、1から10万の数字を足した結果を単に得たいだけなら、 (100000*100001)/2 で簡単に求められるね。目的が結果を得るだけなら計算機で足す実行プランがそもそも間違ってる。その可能性まで考えると・・・ 「...という目的のために……というプランを考えています。そのプランを…という品質で、…くらいのコストで….までに実現することは、ウチの技術力的に可能でしょうか?」 ときいてくれれば、よりよい代替案を出すチャンスも得られるかもしれない。
|
09/01/17:37 クライアントの担当者は何をもって評価されるのか。さて、今日はクライアント企業の人事考課制度とそれに合わせた営業戦略について話をしたいと思います。 我々がいるシステム開発業界のクライアントは、ほとんどが個人ではなく法人であり組織体であることがほとんどです。 つまり、実際に一緒にお仕事をさせていただくのは、その組織のいわゆる”中の人”です。 数人のチームの場合もあれば、1人の担当者のこともあります。 私は営業先に言って話をしている時、 「この担当者は何をもって評価されるんだろう」 と考えることがよくあります。 ざっくり言ってしまえば、どの会社でも「仕事をうまくやる」ことが評価される条件だとは思いますが、 これが実はかなり曖昧な基準だと思っています。 例えば、500万円の案件の見積もりを、300万円に値切ることに成功したらその担当者は評価されるでしょうか。 おそらく一瞬は時の人になれます。「よくそんなに値切れたなー、すごいなー」と。 ただ、その値切った200万円はその担当者のポケットに入るわけでありません。 さて、実際に大幅に値切ったプロジェクトが開始されるとどんなことが起こるでしょうか。 必ず起こるとは言い切れませんが、最終的に”安物買いの銭失い”になることも多々あるかと思います。 その時に一番苦労をし評価が下がるのは誰でしょうか? その担当者ですね。 そんな経験をした担当者が次に別のプロジェクトを発注する時、どんなことを考えるでしょうか。 上の承認がとれないほど高い見積もりは困るけど、承認が通るのであればどんなに高くても構わない、そんなことを考えるようになるケースも多いです。 つまり、発注価格が高くて、組織は嬉しくなくても、その担当者の懐は一切痛みません。 それよりも、トラブルなく万事がうまくいく方が、担当者のメリットは大きいのです。 値切り名人の名声は一瞬ですが、日々の安心した毎日とプロジェクト自体の成功の利益は長期間持続するものです。 そんな担当者が相手であればアピールするのは価格ではなく安心です。 「安心してください。納期までに、ちゃんと御社で許容できる品質レベルのものを、最初に約束した予算で、制作して納品します」 このアピールの方が価格を下げることよりも、しっかり担当者の心をつかむことができるはずです。 ちなみに、熟練の担当者になると、プロジェクトによって、使い捨ての業者と、勝負業者を使い分けるようになってきます。 もろちん、世の中には、真逆のケースもあります。 どれだけ値切ることができたか、で担当者が評価される会社もあります。 たまに、業者への発注の際にはすごく細かく審査して価格を下げるわりには、 炎上したプロジェクトの対応に追われる担当者の残業代や、 そのことでクライアント企業のお客様に迷惑をかけたことで失われる信用の価値には無関心というケースもあります。 よく観察してみると、最終的な価格が低いかどうかよりも、 値切り幅が大きいかどうかを重視しているケースなども稀にあります。 世の中、いろんな会社がありますね。 交渉の相手が、聡明なオーナー社長であれば、むしろ話はシンプルです。 そのプロジェクトの費用対効果にフォーカスして話をすることができます。 同様に、個人の評価よりも、会社にとっての利益を考える担当者も、 オーナー社長と同じようなロジックで話をすることが可能です。 皆そうだったらとても良いのですが、 残念ながら現実は様々です。 昔、家庭教師のアルバイトをしたことがありました。 サービスの費用負担をする親と、サービスを享受する子供。 クライアント企業と、その担当者。 両者の関係でもなんだか似たようなところがありますね。 最後に大事なことを一応書いておくと、 これはあくまで営業的なとっかかりだけの話です。 実際に納品するシステムは、やはりそのクライアント担当者個人のものではありませんので、 その企業、あるいは、その企業のお客様といった、より多くの幸せを考えて作成しなければなりません。 そこを妥協しちゃうとシステム開発という仕事が嫌いになってしまいますからね。
|
08/02/09:34 正確には暗号化とメッセージダイジェストは異なるさて、前回、「パスワードを一方向暗号化しても簡単なパスワードを使っていたら意味がない」という記事を書いた。 話をわかりやすくするために「暗号化」という言葉を用いたが、 専門用語で言えば、md5 hashで生成されるものは暗号ではなくメッセージダイジェストと呼ばれるものだ。 確かに、両者ともに、特殊な関数を用いて平文を変換するという意味では同じではある。 しかし、メッセージダイジェストは世界中どこであっても、inputが同じで、かつ、同じ生成関数を用いた場合には同じ結果が得られるのに対して、暗号化というものはそもそも特殊な鍵を用いて行うのでその鍵(ロジックも)を知らない限り同じ結果が得られないという点で異なる。 メッセージダイジェストは、同じinputに対して、同じ結果が保証されているがゆえに改ざんされているかのチェックなどに利用されることも多い。 例えば、前回紹介したmd5は、どんな長さの平文のinputでも128ビットのメッセージダイジェストを生成する。このビット数が決まっていることによる利点は多い。 例えば、パスワードを平文ではなく、暗号化(正確にはメッセージダイジェスト生成)によって保存しようとした場合に、当然DBのパスワード保存用のフィールドを用意することになるが、これが仮にmd5でhashを作成すると決めている場合には、パスワードの長短に関係なく、128ビットを格納できる領域だけを確保すれば良い。DB設計を経験したものであれば、この利点には大きく頷けることだろう。 そのメッセージダイジェストだが、いろいろと種類がある。 代表的なものを書いておく。 (1) md5 これはRSA社が開発したもので128ビットのメッセージダイジェストを生成する。 他にもmd4とかmd2とかもある。 (2) SHA-1 160ビットのメッセージダイジェストを生成する。 最近、ハイスペックマシンの登場によりもう160ビットだと危ないね、と言われ始めている。 (3)SHA-2 SHA-1のアルゴリズムはそのままで、メッセージダイジェストのビット数だけ増やしたもの。 224,256,384,512のビットのいずれかでメッセージダイジェストを作成することができる。 (4)SHA-3 SHA-1とSHA-2とは別のアルゴリズムを使おうということで始まった試み。 ということで、誤解があるといけないので前回の補足として 正確には暗号化とメッセージダイジェストは異なる というお話でした。
|