スイーツ（笑）と呼ばないで!!

ラピュタは何度でも蘇るさ(by ムスカ)

私は、マシンをリカバリ(クリーンインストール)するのが好きだ。

大きな案件が終わった時とか、年齢が変わった時とか、いろいろなタイミングでリカバリをする。

そのタイミングで断捨離もできるし、何よりクリーンな状態からの再出発は気持ちが良い。

昨日も深夜に手元のMac Book Proをリカバリしていて、ふと昔学生時代に友人から聞いた話を思い出した。

大学1年生の頃、同じように遠く離れた地方から来ていた同学年の女の子がパソコンを入学祝いで買ってもらって来ていた。

その子の話では、パソコンを買ってすぐ、父親の指導で5回くらいリカバリーの訓練をつまされたらしい。

当時、彼女は、新品のマシンなのになぜわざわざリカバリをしなければならないのか、それも何度も何度もさせられるのか、本当に意味不明、ということでとても不満を持っていたようだ。

もともと父と娘の会話もあまり無いような家庭だったらしく、理由もあまり説明されないまま、パソコン好きな父親から強制的にやらさせた経験は、本当に苦痛以外の何物でもなかったんだろう。

でも、自分はその話を聞いたとき、なんて素晴らしい父親なんだと感動した。

パソコンは、キーボード操作やマウス操作ではOSは死ぬことがあっても、物理的に壊れることはほぼない、この復活の儀式さえ分かっていれば、何度でも蘇る。

だから、どんどん使え、使い倒してどんどん壊せ、そして何度でも蘇らせろ。

そういうことなんだと思う。

入学までの残り少ない時間、普段から会話もあまり無い娘に対して、
壊さないための細かい操作を教え込むのではなく、どんなに壊しても蘇らせられる方法だけを伝授した父親。

たくさん転べ、でも、心配するな、お前は転んでも自分の力で立ち上がる術を知っている。

その友達のお父さんの教育方針は今でも私の中に生きている。

初心者は、なるべく想定外のことが起こらないように正しい手順を覚えてそこからズレないようにしようと努力する。でも、正しい手順なんて何通りもあり覚えられるわけがない。

だから私は何かを指導するときにはよくこんな言葉を使う。

「大丈夫、それをやったからといって死ぬ人はいない」
「最悪のケースでも、xxxがoooなだけだ」

ま、たまには、滅びの呪文「バルス」みたいにもそれやっちゃーお終いよ、というのもあるけどね(笑)

全てのものには歴史がある

突然、個人的な話をするが、私は過去を振り返るのは嫌いだ。
ついでに言うと、3年以上先の未来について計画を立てるのも嫌いだ。

ただ、今流行りの真田丸など歴史ものは好きだし、そもそも昔は考古学者になりたいと思っていた時もある。また、将来世界はこうなっているかもしれないなぁ、と言ったような空想はするし、技術を採用するにあたって将来の見通しを立てたりはする。

前者と後者の違いは何かと言うと、前者は私個人の過去と未来の話で、後者はこの世界の過去と未来の話である。

それで、まず個人的なことで言えば、私は今しか見ない。仕事上、半年から1年先くらいまでは計画を立てるが、書いても1行程度の計画で、より現在に近づけば近づくほど段階的に詳細化されている。

逆に、この世界の話で言えば、私は現在と過去と両方を行ったり来たりして、現在の姿をより正確に理解しようと試みる。

つまり、現在を理解するために、過去を見るのである。

例えば、最近私はAWSについて強い関心を抱いている。

AWSには数十を超えるサービスがある。

初めてAWSの世界に足を踏み入れた時は、その数の多さと複雑さに圧倒された。

そういった一見複雑なものに出会った時には、

過去に戻ってみましょう!!

そうです、全てのものには始まりがあり、歴史があるのです。

昨日は初心にかえり、深夜自宅で一人Macの画面に張り付きながら、AWSのWhat's Newページを古い順にひたすら読んでいきました。

まず、どこまでさかのぼれるか。

https://aws.amazon.com/jp/about-aws/whats-new/2004/

このページが現存する最も古いものになります。

URLの2004を2003に変えるともう404ページになりますね。

AWSの最古のサービスと呼ばれるSQS(Simple Queue Service)の紹介文がありますね。beta testingと書いてあります。

2006年になるとおなじみのS3(Simple Storage Service)やEC2(Elastic Compute Cloud) が登場して来ます。まだベータだったりアメリカだけだったりしますが。

2009年になると、ヨーロッパでも利用可能になったり、CloudFront、ELB、EBSと言う見慣れたサービスや、インスタンスの契約でもスポットインスタンスなど多様化して来ます。この年に一気にAWSの世界が広がったのがよくわかります。

ここからは、毎年かなりの機能やサービスがリリースされていきます。一つ一つ挙げるとキリがないのでここでは割愛します。

2011年になると、

https://aws.amazon.com/jp/about-aws/whats-new/2011/

今まで英語だったページが日本語に切り替わります。

ついに、アジアパシフィック東京リージョンが利用可能になったのです。

その後も、毎年さまざなアップデートがあるのですが、そこも割愛します。

そして、最後の2016年のページに来ると、まずその数に圧倒されます。

かなり新しいサービスや機能が一気にリリースされていることがわかります。

つまり、もうあと数週間で終わるこの2016年はAWSの歴史の中では、かなりホットな時代なんですねー

時間は同じスピードで流れていたとしても、歴史というのは各年ごとに濃淡があります。動く時もあれば、全く変わらない時もあります。

そんな中、我々は、今、このAWSの歴史の中で一番熱い時代の真っ只中に生きているのです。

何という幸運でしょう!!

すみません、ちょっと熱くなりすぎましたね^^;;;;

今回、ブログではこんなことがあったよー、と出来事だけを追いましたが、このニュースリリースの概要を読むと、なぜのその機能やサービスが必要だったのか、どんな課題を解決するためにそれの機能やサービスをリリースしたのか、が読み取れます。

そうすると、ただ何の脈略もなくフラットなアイコンの羅列に見えたサービス一覧も、全く違ったように見えて来ます。

より、現状のサービスについて理解できるようになるのです。

ということで、もし人生で一見太刀打ちするのが困難な複雑な事象に出会ったら、可能な限り過去の歴史を追ってみましょう。どんなものも、シンプルでわかりやすいところから始まっているはずです。

蛇足ですが、私はLinuxのカーネルの最初のコミットのソースを読んだこともあります。OSというものが何であるのか、そもそも何を実現しようと、どんな仕組みで戦いを挑んだのか、よく理解できました。その延長線上で最新のカーネルのソースを読んだ時、だいぶ理解が進んだ記憶があります。

今日は、

困ったら、タイムトラベラーになったつもりで、現在と過去と両方を行き来したら良いよ、

という話でしたー

DB設計者のバイアス

昨日、知り合いのSEからDB設計で初めてMySQL使うらしくデータ型について相談された。

小数点以下1桁固定のカラムは何型?

と聞かれたので、(何を悩んでいるんだ?と心の中で思いながら)DECIMALとかNUMERICとかで良いんじゃない?と答えたら、

3.8+4.2=8

の8を8.0ではなく、8にしたいんだと、言われた。

さらには、文字列で持とうかな、とかブツブツ言ってた。

なんか、最近twitterで見かける、どこかの小学校の採点の話を思い出した。
(これとか、http://headlines.yahoo.co.jp/hl?a=20161129-00000081-it_nlab-sci)

ちなみに、

じゃ、結局どれが正解ですか?

という感じでこれだけの情報で判断しようとする人はDB設計者には向いていない。

これはケースによる。

例えば、文字列で持つのがナンセンスかというと、もう今後値の変更も計算もなく、単に表示にしか使われないのであれば、ある意味文字列で持てば最速で表現できるので悪くない。

後々、このカラムの値がSQLレベルでの計算に用いられて厳密に行きたいのであれば、やはり固定小数点型のDECIMALとかNUMERICが良いだろう。

例えば、整数部分の桁数がすごく大きくて、小数点以下なんて正直どうでも良いようなレベルの計算をするのであれば、浮動小数点型のFLOAT、DOUBLEでも良い。

他の視点として、そもそもSQLで計算するのか、例えばPHPとかで一度受け取って計算(つまり一度キャストされる可能性もある)あるいは表示するのか、でも話が違う。

これを、私は、DB設計者のバイアス、と呼ぶ。

DB設計では、DOAでデータにまず着目する、それに対して、設計者はバイアスをかけることで、現実のDB設計に落とし込む。そのバイアスをかけるためにはシステム全体の世界観を理解する必要がある。

だから、業務理解なくしてDB設計はできない。

弊社はいろんなスタイルのSEがいる。画面設計とか詳細仕様はプログラマにお任せするスタイルもあれば、その辺も細かく指示するSEもいる。

ただ、DB設計だけは、お客さんと直接話すSEが担当するというポリシーを採用している。会社としての理由はもしかすると別にあるかもしれないが、少なくとも私がそのポリシーに賛成する理由は、より良いシステム構築には上記のDB設計者のバイアスが必須だと考えるからである。

エンジニアの思考パターン

例えば

http://www.recordchina.co.jp/a155573.html

こういうニュースを見た時、エンジニアである自分が真っ先にする行動は、

炊飯するのにどのくらいの電力が必要なのかググる

ということ。

そりゃダメに決まっているっしょ、という笑いながら否定するのは簡単だけど、

実際それがダメな理由が

・電力の問題なのか
・湯気や匂いなどの問題なのか
・倫理的な問題なのか
・マナー的な問題なのが
・法的な問題なのか
・単にそれまでそのようなことをやる人がいなかったという問題なのか

その他、いろいろ考えられる。

例えば、今回の場合は単に電力の問題なのだとすれば、いくらでも代替案が浮かぶ。

そして、そう言った行動に出る人がいるってことは、そこに需要があるということで、きちんと問題をクリアすれば、それは画期的なサービスにつながるかもしれない。

エンジニアにとっては、OKかNGか、という結論だけではなく、その理由をきちんと理解することが大事だと常々思う。

結論が理由とセットで頭に入っていれば、別の状況でその理由となる原因が異なっているとわかれば容易にそれまでとは真逆の結論を導き出すことができる。

技術論だけでなく、例えば、「戦争(殺人)はすべきか否か」とかって問題も、ダメならばなぜダメなのかしっかりとその理論構造を分析してみたり、普段からそういう訓練すると良いと思う。そういうトレーニングが、今目の前で直面している技術的な課題をクリアするのに案外役に立つものだ。

iOS端末を簡単に業務アプリ専用端末にする方法

Swift使ってiOSアプリを趣味で作成したりするが、
業務で使用するほどには詳しくない。

逆に、Webアプリは業務でよく作成する。

そんな中以下のような要件のお仕事の依頼が来た場合、こんな選択肢もありますよ、という話。

【要件】

1. iOS端末を使って業務アプリを構築したい。
2. タッチパネルの機能を有効に使いたい。
3. フルスクリーンで利用したい。
4. その業務アプリしか使用できないようにしたい。
5. メンテナンスが大変なのでSwiftとか使ったネイティヴアプリは嫌

さぁ、皆さんどうでしょうか、最後の要件5を読んで「ん?」となったのではないでしょうか?

こういうアプリ作成の時には、よく

「じゃー、ガワアプリだけ作って、中身は普通のHTMLとかJSとか使ったWebアプリにしましょー」

という話がでる。

でも、「ネイティブアプリは嫌」と言われるとそのソリューションは使えませんね。

そんな時の方法をこれからご紹介します。

まず、WebアプリをSPA(シングルページアプリケーション)で作成します。

そして、作成したWebアプリのヘッダーに

こんな感じのmetaタグを設定します。

1行目がフルスクリーンにするための設定で、2行目はステータスバーの表示についての設定です。

これを設定したURLをSafariで開き、ブラウザの下にあるアイコンメニューの四角に上矢印的なアイコンをクリックしてホーム画面に追加を選択します。そうするとそのページへのショートカットがホーム画面に保存されます。

その際

こんなタグを仕込んでおくとアイコンが設定できるので、他のネイティヴアプリを見た目上全く違いが無くなりますね。

さあ、これで、ホーム画面上のアイコンを起動するとフルスクリーンのアプリが起動して如何にも業務アプリっぽくなりましたね。これで既にお客さんの要件のうち要件4を除いて全てクリアした状態となります。

要件4はどうしましょうか?

実は、上記の手順を踏んだことで、iOS内部における取り扱いにおいては、SafariでそのWebアプリを開いた時とは別の取り扱いになります。サーバサイドで取得されるUser AgentもSafariとは異なったりしますね。

少し回りくどい言い方をしましたが、これでいわゆるシングルアプリモードが使えるようになったということです。

設定>一般>アクセシビリティ>アクセスガイド

を開き、アクセスガイドの機能をオンにします。

パスコード設定のメニューより、シングルアプリモードを解除するためのパスコードやTouch IDの使用不使用が設定できます。

さあ準備は整いました。

ホーム画面から自作アプリのアイコンをクリックします。
フルスクリーンで立ち上がりましたね。
そこでホームボタンを3回押します。
これによりアクセスガイドが開始できます。
ちなわち、もう他のアプリに切り替えることは不可能になります。
(ちなみに、解除する際も同じくホームボタン3回押しでパスコード入れます)

さぁ、要件4も満たすことができましたね。

いかがだったでしょうか。

Swiftなど使ったiOSネイティヴアプリ構築のノウハウはない。でも、今ある技術でそれっぽく業務アプリを作りたい、特に端末固有の機能を使ったりする必要はないんだ、というあなた、早速今日からなんちゃってiOSアプリを作成してみましょー。

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

ネット投票に関する情報技術上の大事な論点

基本的に、選挙の際には相当の理由がない限り投票に行く。

その日に予定が入りそうだなと思うときは、事前に不在者投票に行くことにしている。

そんな私ではあるが、やっぱりネットで投票出来れば便利なのに、という気持ちになることは多々ある。

そうしたらもっと投票率も上がるだろうに、と。

で、それをやらない理由は、個人情報流出とか、他の人のなりすまし投票とか、横に誰かが付いてて無理やり投票させられるのを阻止できない、とかを気にしているのかなー、と思っていた。

まぁ、最後に挙げた、横に誰かが付いていて・・というのはパッとは解決策が浮かばないけど、でもそれ以外の情報技術上の問題は、なんだかんだで最近は個人認証の技術や暗号化の技術も発達しているし、なんとかなるでしょ、って思ってた。

作ろうと思えばウチの会社でもそのシステムは作ることができる。

でも、この前勉強していて、

なるほど、これはちょっと厄介な問題だなー

と初めて理解したことがある。

今日はそれを紹介したい。

日本国憲法の第15条の最後の方に

「すべて選挙における投票の秘密は、これを侵してはならない。」

というのがある。

これが実は厄介な問題。

つまり、

投票行為については、個人をきちんと認証しその本人が間違いなく投票しているという事実を担保しなければならない、

その一方で、

誰が誰に投票したか、については、投票の秘密は守られなくてはならず、遡って個人を特定できてはならない、

ということ。

もし、国家権力が投票データやアクセスログから誰が誰に投票したかを知ることができるとしたら、時の権力者が自分たちに反対する有権者に対して粛清をすることも可能となる。今の平和な日本では考えにくいが(お隣の国では行われているが)、憲法とはそもそもそういった国家権力の暴走を牽制するためのものだ。

と言うことで、一見簡単そうに思えるネット投票システムも、結構面倒なことのようである。

ただ、いま世界中でこの個人認証・暗号化と匿名性の確保の二つを両立させるための研究が行われているらしいので、そのうち、ネット投票が実施される日も来るだろう。

一見簡単に思えるが行われていない背景には、実は自分が理解不足で知らないだけで複雑な問題があることもある、と言うお話でした。

「技術的に可能か?」という質問について

立場上、時々別の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

で簡単に求められるね。目的が結果を得るだけなら計算機で足す実行プランがそもそも間違ってる。その可能性まで考えると・・・

「...という目的のために……というプランを考えています。そのプランを…という品質で、…くらいのコストで….までに実現することは、ウチの技術力的に可能でしょうか?」

ときいてくれれば、よりよい代替案を出すチャンスも得られるかもしれない。

クライアントの担当者は何をもって評価されるのか。

さて、今日はクライアント企業の人事考課制度とそれに合わせた営業戦略について話をしたいと思います。

我々がいるシステム開発業界のクライアントは、ほとんどが個人ではなく法人であり組織体であることがほとんどです。

つまり、実際に一緒にお仕事をさせていただくのは、その組織のいわゆる”中の人”です。
数人のチームの場合もあれば、1人の担当者のこともあります。

私は営業先に言って話をしている時、
「この担当者は何をもって評価されるんだろう」
と考えることがよくあります。

ざっくり言ってしまえば、どの会社でも「仕事をうまくやる」ことが評価される条件だとは思いますが、
これが実はかなり曖昧な基準だと思っています。

例えば、500万円の案件の見積もりを、300万円に値切ることに成功したらその担当者は評価されるでしょうか。
おそらく一瞬は時の人になれます。「よくそんなに値切れたなー、すごいなー」と。
ただ、その値切った200万円はその担当者のポケットに入るわけでありません。

さて、実際に大幅に値切ったプロジェクトが開始されるとどんなことが起こるでしょうか。
必ず起こるとは言い切れませんが、最終的に”安物買いの銭失い”になることも多々あるかと思います。
その時に一番苦労をし評価が下がるのは誰でしょうか?
その担当者ですね。

そんな経験をした担当者が次に別のプロジェクトを発注する時、どんなことを考えるでしょうか。
上の承認がとれないほど高い見積もりは困るけど、承認が通るのであればどんなに高くても構わない、そんなことを考えるようになるケースも多いです。

つまり、発注価格が高くて、組織は嬉しくなくても、その担当者の懐は一切痛みません。
それよりも、トラブルなく万事がうまくいく方が、担当者のメリットは大きいのです。
値切り名人の名声は一瞬ですが、日々の安心した毎日とプロジェクト自体の成功の利益は長期間持続するものです。

そんな担当者が相手であればアピールするのは価格ではなく安心です。

「安心してください。納期までに、ちゃんと御社で許容できる品質レベルのものを、最初に約束した予算で、制作して納品します」

このアピールの方が価格を下げることよりも、しっかり担当者の心をつかむことができるはずです。

ちなみに、熟練の担当者になると、プロジェクトによって、使い捨ての業者と、勝負業者を使い分けるようになってきます。

もろちん、世の中には、真逆のケースもあります。

どれだけ値切ることができたか、で担当者が評価される会社もあります。

たまに、業者への発注の際にはすごく細かく審査して価格を下げるわりには、
炎上したプロジェクトの対応に追われる担当者の残業代や、
そのことでクライアント企業のお客様に迷惑をかけたことで失われる信用の価値には無関心というケースもあります。

よく観察してみると、最終的な価格が低いかどうかよりも、
値切り幅が大きいかどうかを重視しているケースなども稀にあります。

世の中、いろんな会社がありますね。

交渉の相手が、聡明なオーナー社長であれば、むしろ話はシンプルです。
そのプロジェクトの費用対効果にフォーカスして話をすることができます。

同様に、個人の評価よりも、会社にとっての利益を考える担当者も、
オーナー社長と同じようなロジックで話をすることが可能です。

皆そうだったらとても良いのですが、
残念ながら現実は様々です。

昔、家庭教師のアルバイトをしたことがありました。
サービスの費用負担をする親と、サービスを享受する子供。

クライアント企業と、その担当者。
両者の関係でもなんだか似たようなところがありますね。

最後に大事なことを一応書いておくと、
これはあくまで営業的なとっかかりだけの話です。

実際に納品するシステムは、やはりそのクライアント担当者個人のものではありませんので、
その企業、あるいは、その企業のお客様といった、より多くの幸せを考えて作成しなければなりません。

そこを妥協しちゃうとシステム開発という仕事が嫌いになってしまいますからね。

正確には暗号化とメッセージダイジェストは異なる

さて、前回、「パスワードを一方向暗号化しても簡単なパスワードを使っていたら意味がない」という記事を書いた。

話をわかりやすくするために「暗号化」という言葉を用いたが、
専門用語で言えば、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とは別のアルゴリズムを使おうということで始まった試み。

ということで、誤解があるといけないので前回の補足として

正確には暗号化とメッセージダイジェストは異なる

というお話でした。