富士通x86サーバがいつのまにか99.999%の可用性を達成していた件

富士通は、メインフレーム、SPARC、x86など、多種多様なサーバを発売していますが、そのなかに高信頼性x86サーバPRIMEQUESTという製品があります。

この製品シリーズでは、マザーボードも含めた多重化を行い、高い信頼性を売り文句にしていましたが、最新機種ではXeon E7の高信頼性機能を使い、マザーボードやCPUに故障が発生しても故障したマザーボードを自動的に切り離して、停止せずに稼働を続けることができるという驚くべき機能を搭載しています。

さらに、動作を継続したままマザーボードやCPUの交換や追加を行うことができるという変態的な機能まで実現しています。

これにより主要な部品全てが完全多重化され、主要部品が故障してもそのまま動作を続けることができます。

それによって99.999%というIBMメインフレームと同等の高可用性を実現しています。

Intelが詳しい説明を出していますが、こうした機能がx86のLinuxで実現されるのは世界初ということです。

ヒューレット･パッカード社は、超巨大x86サーバのSuperdome Xを発売していますが、そちらよりも先に富士通が実装したということは驚きです。

これが特別なOSではなく、通常のRedhat Enterprise Linuxで実現されているというのだから、さらに驚きです。ハードウェアとOSレベルで実現された高可用性なので、ソフトウェアに全く改変が必要ないというのも魅力と言えるでしょう。

メインフレームなどいくら高信頼性といっても、ハードウェアの保守運用だけでも特殊な知識を必要としますし、さらにその高信頼性を引き出すために特殊なメインフレームOSまで使うとなると、ソフトウェア開発費用や保守費用が爆発的に増大してしまいます。

もちろん信頼性はハードウェアだけで担保するものではなく、ソフトウェア障害やネットワーク障害もありますから、このサーバを導入するだけで高可用性が得られるものではありません。しかし、それでもハードウェア故障が防げることによって、システム全体の高可用性を保つことが容易になります。

ソフトウェアによる冗長構成も必要ですが、フェイルオーバー時のトラブルを考えると、なるべくフェイルオーバーしないに越したことはないのが現状だと思います。

気になるお値段は非公開のようですが、過去のモデルなどから類推すると、ハイエンドx86サーバとしては一般的な数百万円から数千万円程度の価格設定なのではないかと考えられます。頑張れば手が届く金額となってくると、俄然欲しくなってしまいますが、そんな大金をサーバひとつに使うわけにはいきませんので、我慢我慢です。

表計算ソフトの正しい使い方について

弊社の皆さんへ、ExcelやGoogle Spreadsheetなどの表計算ソフトウェアを使う際に気をつけて欲しいことがあります。

最も大事なのは、表計算ソフトを使うときには、「表(テーブル)」を意識して使わなければいけません。

表とは、すなわち行(レコード)と列(カラム)の組み合わせによって、情報を整理する方法です。

通常は、行に各データ(人間や取引先や資産など)を割当、列にその項目(氏名や所属や売上など)を割り当てて、その交点となるセルに該当する情報を入力します。

氏	名	年齢(歳)	年収(万円)
田中	一郎	30	400
山田	花子	25	350
上野	剛	28	320

一行目は見出し、各行に一つのデータと憶えれば分かりやすいですね。

見出しを見れば、誰でもそのセルに何を入れれば良いか明確にすぐわかるようにしなければいけません。

一つのセルに複数の情報を入れてはいけません。セル内に注釈や備考をいれてはいけません。

一つの列のセルには、見出しで定められた同じ種類の情報しか入れてはいけません。そのセル内に記載出来ない情報は、備考や別のセルに記入します。

セルには、円や千やキロやメートルなどの単位を入れてはいけません。それは見出しに入れます。

他のセルから計算できる数値（合計、平均、消費税等）は、式を使って計算しなければいけません。計算した値を手入力してはいけません。

一つの表を複数に分割したり、途中で見出しを再度挿入したり、途中でセルの意味を変えたりしてはいけません、そうしたら一括で選択したり集計処理することが出来なくなるからです。

もしも表が縦に長くなり、見出しが見にくくなる場合は、見出しの行や列を固定表示して見出しはスクロールしないようにすれば良いのです。

表計算の使い道としては、情報管理、情報整理(プレゼンテーション)の二つがあります。

情報管理とは、他に元データがない情報(独自情報, オリジナルデータ, 元データ)を保存するために使うものです。これは複数人で共有･編集する必要があるので、必ずGoogle Spreadsheetのようなオンライン上の表計算を使わなければなりません。

情報管理を目的とする場合は、一つのシートに一つの表しか載せてはいけません。複数の表がシートにあると、追記や編集もしにくくなるだけでなく、プログラムによる自動処理ができなくなります。

情報整理とは、他の元データから転記した情報を整理して、計算を行ったり、見やすく整理を行ったりして、自分や他の人が情報を理解しやすいデータとして提示することです。

ログイン手段再考: OAuthよりもメールアドレス認証がいいんじゃない？

最近は色んなウェブサイトでOAuthを使った登録やログインが用意されるようになってきました。

それに伴い、OAuthを使ったサイトでID/パスワードとは違う別の不便さを感じるようになってきました。


確かにID/パスワードは、認証方法としてはセキュリティ的にあまり望ましいものではありません。なぜならパスワード使い回しによって、セキュリティが弱いウェブサイトでパスワードが露呈すると、全てのウェブサイトへのアクセスが破られてしまうという恐れがあるからです。

もちろんこれはパスワードを使い回すユーザが悪いのですが、しかしユーザがどのようなパスワードを設定するかを制限しなければ、使い回したり、異常に簡単なパスワードを設定されてしまうことは防げません。

そうした問題や、またユーザ登録の面倒くささなどを防ぐためにOAuthを使ったサイトが増えているのだとは思います。


しかしOAuthにも別の問題があります。

多くのウェブサイトではOAuthのサービスプロバイダとしてGoogle, Facebook, Twitterなどをサポートしていますが、こうしたウェブサイトは単なるID認証のためにOAuthを提供しているのではなく、API連携をするためにOAuthを提供しています。

そのためOAuthでログインしたユーザは、自分が単に認証するためだけのつもりが、不用意に個人情報をウェブサイトに渡してしまうことになりかねません。

また、私が個人的に困っていることとして、ログイン手段としてGoogle, Facebook, Twitter, メールアドレスなどが用意されていると、どれで登録したかを忘れてしまう場合があることです。この場合、アカウントへのログインはほぼ絶望的になります。

私としては、もしOAuthを認証手段として使うのであれば、思い切ってサービスプロバイダの種類を一種類に限定してしまい、ログイン手段を忘れないようにすることをお勧めしたいところです。

（それでもGoogleだとAppsのアカウントとgmailのアカウントの二種類があったりするので、どちらを使ったのか忘れてしまう危険はありますが）

ちなみにこれまで使ったOAuth対応サイトの中で最悪だなと思ったのはpixivです。OAuthを使って登録を促しているのに、実際に登録しようとするとIDやパスワードなどの登録フォームが出てくるという意味不明な作りです。こんなことをするくらいなら最初からメールアドレスを入れるようにすればいいのではないでしょうか？

マーケティング上の理由などで、メールアドレス確認の手順をなくして登録途中での離脱を減らしたいなどあるのかもしれませんが、ユーザにとってプライバシーを失うだけでメリットのないようなOAuthの使い方は避けるべきではないでしょうか。


私が最近思うのは、どうせメールアドレスという情報は必要であり、かつメールアドレスにパスワードの再発行などを送るようになっているのだから、メールアドレスに認証を委ねてしまえば良いのではないかということです。

ID/パスワードなどをユーザに管理させるのではなく、ログインするときにもしパスワードが分からなければメールアドレスにメールを送って、そこのリンクからログインしてもらえば良いと。

弊社では、いまはユーザが登録したときにパスワードをこちらで自動生成して送って、それをそのまま使ってもらうようにしています。ユーザがパスワードを設定しないほうがずっと安全であると思っています。

これまでは、メールで送信すると、どうしても平文で送られることになるので、セキュリティ上の問題があるという意識を持つプログラマは多かったでしょう。しかしどっちにしろ多くのウェブサイトではメールアドレスを最終的なアカウントの確認手段として使っているので、それが脆弱であると見なして仕様を決めるのは難しいです。

さらにインターネットのメールサーバ同士の通信が盗聴されるということは現実的にはかなり低いリスクでしょう。そう考えると実質的に脆弱なのは、ユーザが危険な通信路（公衆Wifiとか）を使って、暗号化していないPOPでメールを取得するような場合だけです。しかし、いまどき大多数のユーザは、ウェブメールかPOP over SSLを使っているのではないですかね？

今後、開発するウェブシステムに関して言えば、もうパスワードなどというものを全廃してしまい、メールのリンクからのログインだけに絞りたいくらいの気持ちです。実際にはモバイルやAPIのアクセスなどもあるので、単純なログインリンクだけでは駄目ですが、そこは工夫して乗り越えたいところです。

もしセキュリティを高めるのであれば、二因子認証(スマホやSMSを使うone-time password等)を併用する方がベターでしょう。

また、むやみにセッションを失効させるウェブサイトも考え物です。ユーザにログインを促せば、それだけ利便性が下がり、離脱率が上がってしまうわけですから、セッションはデータベースの能力が許す限り長期間保持するべきでしょう。

ログイン手段については旧態依然とした考え方がまかり通るこの業界ですが、そろそろ全面的な再考が必要ではないでしょうか。色々とご意見などもらえればありがたいです。

今話題のブロックチェーンとは何なんだ？ 部外者の技術者として考察してみる。

一行でまとめ: 暗号通貨は面白いけど、ブロックチェーンはそれ以外には使い道がないだろうと僕は思ってるよ。暗号通貨はダメでブロックチェーンは有用という奴らは何も分かってない。


最近、IT業界を取り巻くメディア（日経BPとTechCrunch等）ではブロックチェーンなる技術が話題です。

ブロックチェーンとは、bitcoinを構成する技術であり、それ自体が金融システムを変革するものなどと言われています。しかしメディアではブロックチェーンの本質について説明しない記事が目立ちます。

現状の大きな問題として、ブロックチェーンやbitcoinについて解説する記事の多くは、bitcoin関連の仕事をしている起業家や研究者などの利害関係者による記事が多いというバイアスがあります。また技術者ではないジャーナリストが書いた記事も、技術的な本質に突っ込めていないものが目立ちます。

本記事では、bitcoinに関して利害関係を持たない一技術者として、ブロックチェーンに関して考察を試みようと思います。私はbitcoinの専門家でもなんでもないので、認識等は間違っているところも多々あるかもしれませんので、ご指摘頂ければ幸いです。

ブロックチェーンとは何を実現する技術なのか

さて、まずブロックチェーンとは何なのかですが、bitcoinを構成する技術であり、具体的にはbitcoinの取引履歴を記録した巨大な台帳ファイルのことを指します。

しかし、一般記事ではブロックチェーンという名称で、bitcoinを可能にしている分散P2Pトランザクションなどの幅広い技術を指すことが多いようですので、以下、本記事でもブロックチェーンという場合は、幅広くbitcoinの技術全般を指すことにします。

さて、そもそもブロックチェーンとは、科学的に見て何が新しいのでしょうか？

ブロックチェーンは、中央の特権サーバが決済履歴を管理することなく、さらに特殊な電子機器を用いることなく、決済(トランザクション)の二重実行防止を実現した点で画期的な技術と言えます。

電子マネーというのは、通常、支払を行うのに中央のサーバと通信して支払を指示する必要があります。なぜなら電子マネーを持っている人が、直接に他の人に支払を行った場合、その裏付けとなる電子マネーを二重に支払いに使っていないかどうか確かめる手段がないからです。（電子データは複製が自由に可能なので、二重支払が自由にできてしまう）

通常の場合は、サーバが決済データを一元管理して、同じマネーが二回支払われていれば拒否するようになっています。これが通常の電子マネーの実現方法です。要するに銀行振込と同じですね。

場合によっては、電子マネーは特殊な電子チップに格納され、支払を行うと、電子チップの中の電子マネー情報が消去されることにより、二重支払を防止する場合もあります。この場合は、電子チップが正しく製造され、第三者が改竄出来ないことを前提にしています。

この二重支払の防止を、中央サーバも特殊な電子機器もなく実現したのがブロックチェーン技術です。

（ちなみに単なる電子契約を行うのにブロックチェーンは不要です。契約書は裏付けとなる資産を保証するものではありませんから、公開鍵暗号方式を使えば普通に実現出来ます）

ブロックチェーンはどうやって二重支払防止を実現するのか

ブロックチェーンの二重支払防止技術は、基本的に多数決による認定に頼っています。多くのbitcoin参加者が取引を監視し、その結果として、二重支払がもし行われた場合であっても、取引を監視している人の採択結果により、どちらが正しい決済として認められるかが決まります。

そのさいbitcoinでは不特定多数の人が市場に参加出来ますので、多数決をする場合の投票権を持つ母集団が定められません。そのためbitcoinでは、コンピュータによる計算量を投票権として採用し、採決をした人に報酬を支払うというルールにより、多くの人が監視して正しい採決が行われるような仕組みにしています。

(IPアドレスごとに票を持たせるような仕組みでは、IPアドレスを多数持つ人が有利になってしまうので、特定の人に投票権が偏らない仕組みとして計算量を採用している）

この「計算量」により投票権が決まるという仕組みがブロックチェーンの肝といえる技術です。これは暗号学やP2P分野の研究において大きな新発明と言えるでしょう。

但しブロックチェーンの大きな弱点として、計算量によって投票する仕組みなので取引ごとに膨大な計算量が無駄にされるという点と、採決が複数回繰り返されることによって決済が確定するので、決済が確定するまでに10分以上の時間を要してしまうという点があります。

この計算量が無駄にされるという性質はかなり致命的なものです。なぜなら計算を行うにはサーバ機器代と電気代がかかるのであり、貴重なエネルギーやサーバなどの資源を無駄に浪費していることになります。これは非常に困った性質です。

ではP2Pのメリットとは何なのか

bitcoinはそれほどまでに特殊な技術を用いて、中央サーバが存在しないP2Pトランザクションを実現していますが、そのメリットはなんなのでしょうか？

じつはbitcoinは匿名性を実現するためにP2Pにしているわけではありません。取引の履歴は全て公開されており、誰でも取引の履歴を追っていくことが可能なのです。これは通常の中央サーバを用いても実現可能です。

中央サーバがないことによるメリットは、主に規制に従う義務を負わなくなるということの一点に尽きると思います。

中央サーバがある場合、その運用者は、電子マネーの運用主体であると見なされ、様々な法的義務を負うことになります。すなわち規制にがんじがらめにされ、もし何か政府とトラブルになった場合には、最悪サーバが差し押さえられる危険があるということです。

しかし中央サーバがなく、さらにソフトウェアの開発もバザール方式で行われていれば、電子マネーの運用主体が存在しないということになりますので、法的規制を受けなくなります。事実、日本でもbitcoinビジネスを行うことは2016年1月現在では法的に自由のようです。

ここがbitcoinのとても面白い点ですね。開発者は無政府主義的な思想を持っていることが伺われます。実際にTorという暗号化インターネットの中では、bitcoinを使ったアングラ通販サイトが存在し、ヘロインの塊1kgなどを通販で売っているのを目にしました。

で、ブロックチェーンは金融機関などの一般社会で使えるの？

最近では、ブロックチェーンが金融機関や一般社会での取引に使えるという説を唱える評論家が数多くいます。しかし私はそうした説に極めて懐疑的です。

まず金融機関や一般社会での取引には、中央サーバがあってはいけない、P2Pが望ましい利用場面というのが全く存在しないというのが最大の理由です。

中央サーバによる決済は、ブロックチェーンを使った決済よりも圧倒的に速く安く確実かつ簡単に実現できます。

ブロックチェーンにより、決済システムがより安く高速に実現出来るという論を唱える評論家がいますが、そういう人が技術的根拠を提示しているのを一切みたことがありません。

そもそも、単純に通貨の価値を他に移転するだけのトランザクションなど極めて低コストであり、最近のサーバ費用を考えれば、わざわざコストを下げるような必要など一切ありません。

銀行のシステムが高額なのは、極めて複雑なビジネスロジックを実現しているからであり、bitcoinのような単純な価値移転とは比べものになりません。

P2Pや分散技術というのは、基本的に極めて高度な技術を必要とするものであり、それによる性能へのオーバーヘッドも多くあります。どうしてもP2Pや分散が必要となるやむをえない理由がなければ、単一のサーバで処理するほうがずっと楽に行うことができます。

とくにP2P技術（多数の信頼出来ないコンピュータが協調するもの）は、ほぼ現実社会で使い物になる技術ではないと私は考えます。あまりに複雑すぎて構築も運用も極めて難しいだけでなく、性能へのオーバーヘッドが大きすぎるからです。

一時期はWinnyなどのP2P技術が持てはやされましたが、今でも実際に使われているものはBittorrentくらいではないでしょうか？

残念なことに大学や研究所などの研究者にとっては、複雑で実現困難な技術であるほど、自分たちの研究論文を書きやすいので、往々にしてこういう「筋の悪い」技術をあえて推奨する研究者が多くいるのです。筋が良くて簡単に実現出来る技術はいくら優れていても彼らの飯の種にはならないのですね。

でもブロックチェーンはbitcoin形式だけじゃないのでは？

※本章で主に批判している対象はこちら → ブロックチェーンの正体 | TechCrunch Japan

ブロックチェーンの本質は「分散型台帳」であり、bitcoinとは違う使い方が出来るなどという人が最近増えていますが、それは全く計算機科学について知らない素人の妄言に過ぎません。

まず第一に分散型のデータベースに関して言えば、計算機科学においてこれまでもずっと研究されてきています。

分散型トランザクションにおいても、参加者が信頼できるのであれば、quorumなどという多数決による投票のアルゴリズムが昔から存在します。AmazonのDynamoDB分散データベースのようにquorum的な多重化で故障を防ぎ性能を向上しているシステムは既に存在します。[論文]

ブロックチェーンがこうした技術について新たに付け加える点は何一つありません。


で、参加者を中途半端に信頼して、弱い計算量のブロックチェーンを導入するということを提案する人もいますが、それはセキュリティの観点から見れば愚の骨頂です。

計算量を投票に使う方法は、あくまで不特定多数の参加者が、報酬につられて膨大な計算量を投入しているからできる方法なのです。特定少数のノードが中途半端な計算量を投じても、何の保証にもなりません。誰かが不正をする気になれば、そんな計算量など一瞬で破ることが可能でしょう。

もしどうしても特定多数の100%信頼出来ないノードで投票を行うのであれば、一人一票方式の方がずっとマシなのではないでしょうか。中途半端な計算量ならその気になればいくらでも投入可能ですが、特定のちゃんと身元が割れた参加者であれば一人一票以上を手にすることはできないのですから。わざわざ計算量を投票権に使う意味は全くありません。

（それでも不正のインセンティブがあれば、LIBOR不正事件のように結託して不正を行う場合もあるでしょうから、きちんと管理された中央サーバを使う方がずっと安心だと思いますが・・・）

ブロックチェーンというのは計算機科学における一つの基礎技術を指すのであり、それを専門外の評論家や弁護士などが表面上の点だけを捉えて、間違った情報を流布するのは良くない傾向だと思います。

ITについて専門外の人が論考する自体は良いことだと私は思いますが、計算機科学について知識のない人が、科学技術上の観点について憶測で論考するのは望ましくないですね。

とくにセキュリティに関わる場合は、致命的な事故を招く場合もあるので危険です。

IT技術者が立場にとらわれずに技術的な論考を表明をすることがもっと求められているかもしれませんね。


参考リンク:

1. ブロックチェーンをもう一段深く理解する
2. Busting 7 Blockchain & Bitcoin Myths - Crowdfund Insider 
3. BitCoinとBlockChainにまつわる誤解ーそんなことはできない - Qiita (2016/1/10追加)
4. なんでもかんでもブロックチェーン？何をもってブロックチェーン？ブロックチェーンの用語の混乱を整理してみる（議論たたき台） | ビットコイン＆ブロックチェーン研究所 (2016/2/15追加、大変優れた整理なのでお勧めします。私はこの整理でいうとフルコンボのブロックチェーンは面白いと捉えますが、他のものには極めて懐疑的です)
5. ブロックチェーンという言葉に騙されないために - いもす研 (imos laboratory)  (2016/12/10追加)

この記事が広まったので補足: (2016/1/7 15:45 バンコク時間)

私はブロックチェーンやbitcoin自体を否定するつもりでこの記事を書いたわけではありません。世の中で、技術的裏付けを全く提示せずにブロックチェーンが「ゼロダウンタイムのトランザクションを低コスト」で実現する技術だとか言うようなジャーナリストなどが目立つので、それに対して疑問を呈する意味で書きました。

一般的な（bitcoinに詳しいわけではない）技術者として見ると、bitcoinやそれに関連する技術が「ゼロダウンタイムのトランザクションを低コスト」で提供するような技術とは、そもそも目的からして全くかけ離れており、そうした紹介がされることには強い違和感があります。しかし世の中の記事では、その違和感を埋めてくれるような技術的説明が全くありません。それに一石を投じたかったということです。

ただし、現時点で技術的に説明されてないとしても、ベンチャー企業などがその技術を開発中であり開発成功する可能性はありますし、そうした可能性を否定する意図は全くありません。

ましてやbitcoin関連技術やブロックチェーンが単なる分散データベース以外のもっと新しい用途で使われることを否定する意図はありませんし、そのような記述をしたつもりもありません。私の筆の滑りもあるでしょうが、その点については、慎重に読んでいただければ理解していただけると思いたいところです。

流行のIT技術を追うのをやめたらプログラマとして成長した話

私はもともと普通のプログラマとしてキャリアをスタートしましたが、2007年くらいから脱プログラマを目指してソフトウェア起業家として経営に軸足を移してきました。

それから8年くらいが経過して思うのは、経営者として大きな成功をおさめる前に、自分のプログラマとしての実力がめきめきとアップしてしまったということです。

8年前の私は、プログラマとしては基礎力はあるものの全般的には未熟であったように思います。コードも荒削りで、とにかくかろうじて動くものを作ることに四苦八苦していました。が、いまはプログラマとしてずっと良い仕事ができています。

この8年間は、自分でコードも書いていたので、経験が増えたことによって、良いコードを書けるようになったという面も多々あるとは思います。しかし、そのあいだ技術書を読むことはすっかりやめてしまい、流行の技術などは完全無視してきました。

経営層の一員として働くので、プロジェクトマネジメント能力や総合企画力や折衝能力などがあがった面もありますが、それよりもシステム設計力やアルゴリズム力などのプログラマとしての基本能力が大きくあがったと感じています。

いま振り返って思うのは、バリバリのプログラマを目指して活動していたときは、流行の技術を追うことに必死すぎたなということです。

どうしてもプログラマというのは新しいツールやら言語やら方法論やらがでてくれば、ついつい調査してしまいますし、追いかけていないと不安になってしまいます。

その結果として、ひたすら技術書ばかり読みまくって勉強会にでまくるプログラマのできあがりとなります。

それは悪いことではないし、プログラマとしてそういうのが必要な時期もあるかと思うのですが、弊害としては、プログラマの基本能力作りがおろそかになったり、不安感にかられて軸足がふらついてしまうようなデメリットがあるかと感じます。

最悪の場合は「目の前にある現実の問題を解く」ということを軽視して、使ったこともない最新のツールや方法論ばかりを社内や顧客にむかってわめきちらす迷惑な意識高いプログラマとなってしまいかねません。

流行のツールや方法論のなかには、いろいろと筋の悪いものも含まれており、そういうものに下手にはまってしまうと悲惨なことになる場合も多々あるんですよね。また、そういった流行の技術には、変に思想性が強いものが多くて、そういう思想にかぶれることで問題解決の本質に目が行かなくなる恐れがあります。

私もバリバリプログラマ時代には、かなりの不安感を持って、押し流されるような気持ちでプログラミングをやってきました。Aという技術が理解できない自分はバカじゃないかとか、Bという技術が使えないのに生き残れるのか？ など不安でいっぱいでした。

今考えれば、そんなことはどうでもよくて、自分の強みと、解くべき問題にフォーカスすべきだったんだよ！ということなのですが・・・


さて、若いみなさんはこの記事を読んですっかり老害乙とおもわれたことでしょうが、ここからさらに老害力をあげて説教モード全開でいきたいとおもいます。

技術のなかには、すぐに廃れるようなものもあれば、長く生き残っていくものもあります。私は、流行のツールばかり持てはやされる現在のプログラマ業界にかなり不安感を抱いています。

例えば、以下のような技術はこの10～20年間、本質的にはほとんど変わっていません。昔に学んだことは、そのまま今でも使えることばかりです。

• リレーショナルデータベースのテーブル設計とSQLクエリの記述
• アルゴリズムとその他の計算機科学
• システムプログラミング (C言語によるプログラミングとか)
• 基本的な業務知識（たとえば簿記会計など）
• IPとイーサネットによるネットワーキング
• コンピュータセキュリティや暗号理論
• ユーザインタフェースとデザイン

これからあなたが流行の新ツール "SuperduperX"を学んだとしても、たぶんその知識は数年後には役立たずです。しかし、こうした基礎を学んでいれば、たぶん10年後もいくらか役に立つことでしょう。

そういうことに気付いてしまった私は、すっかり流行の技術を追うのをやめて、幸せなプログラマとして、毎日を目の前の問題解決に費やしています。

まあ、べつに流行のツールを積極的に学びたい人を止めるつもりはありませんが、不安感と焦燥感に駆られて、新技術ばっかりを追うことはないですよ、と。

あと自分が苦手なことがあったり、理解できないことがあったりしても、それをコンプレックスのように思う必要はないかと思います。全ての技術を使いこなせるスーパープログラマなんて、まず存在しないですからね。

流行の技術には、はっきりいって完全なデタラメみたいなものもあるので、「これ、わけわからないなー」と思ったら、自分の直感に従って無視するほうが良いかと思います。

そして、プログラムを書く目的は、あくまで問題解決のためですから、目の前の問題をどんどん解決していきましょう！

問題解決といえばワインバーグの名著「コンサルタントの秘密」ですね。唐突なアフィリンクですが、まあ、この本はなんど紹介しても足りないくらいの名著ですので・・・ やたら読みにくいですが、間を置いて三回くらい読めば分かるようになるでしょう。

プログラマー技術評価サイトpaizaについて

プログラマー技術評価サイトのpaizaというのを試してみたので、その話をします。

昔、私が思いついた事業アイデアの一つに、問題を出してプログラマーの技術評価をするウェブサイトを運営するというものがありました。そのため、こうした事業には強い興味を持っています。

このようなサイトは各種ありますが、paizaの特徴は

1. 明確にランク分けされており、分かりやすい。画像なども美しく、問題を解くモチベーションが高まる。いわゆるgamificationという奴ですかね。
2. ランクを上げるのには、一つだけ問題を解けば良く、暇人でなくてもランクを上げることができる。これは大変良いです。codeevalは多数の問題を解かねばならないようで、げんなりします。
3. 転職サイトが合体しており、「このランクならこの求人に応募できる！」というのがあり、さらにモチベーションが高まります。素晴らしい。
4. 同じ問題は一度しか挑戦できない。

などがあるかと思いました。とにかく完成度が高く、開発運営するのにいくらかかってるんだろ？と心配になってしまうくらいです。

いくつか実際に問題を解いてみましたので、そこから各ランクについて、どれくらいのスキル感かを考えてみます。

Bランクの問題では、「最遅出社時刻」というものを解きました。これは、アルゴリズムはシンプルなもので解けますが、問題文をきちんと把握して、それをプログラムに落とすには、気を遣う内容と思いました。この問題が解けるなら、プログラマとして即戦力で働けるレベルのコーディング力かなと思います。

Aランクの問題では、「ビームの反射」というのを解きましたが、これは簡単すぎるかなと思いました。Bランクの問題に比べてとくに難しいとは思わなかったです。というか「最遅出社時刻」より簡単でした。paizaの方式だと、一つ簡単な問題があると、ランクが取れてしまうのは問題ですね。

Sランクの問題では、「データヒストグラム」というのを解きましたが、かなり手強かったです。実務で同じような問題を解いたことがあるので46分で解けましたが、そうじゃなければ時間かかりすぎて諦めていたかもしれません。

Sランクの問題が解けるなら、一般のIT企業で普通にプログラマーの仕事をする分には、コーディング力で詰まるということはまず無いかと思いますね。これを「スーパープログラマー」と呼ぶのには抵抗がありますが、多くの企業にとっては十分すぎるレベルではないでしょうか。

ちなみに私はプログラミングコンテストみたいなものには一切縁の無い普通のプログラマーです。プログラミング歴だけはめちゃくちゃ長い(30年以上)ので、それなりには書けますけどね・・・

という感じで、問題も結構良く出来ており、プログラマを雇う参考にしたり、プログラマが自分のコーディング力のレベルを把握するには、すごく分かりやすいかなと思いました。

paizaは転職サイトとしても大変よいなあ、と思ったので、もっと普及してくれるといいですね。もし弊社が一般採用することになれば、是非利用したいものです。

あとは問題にバラエティが広がり、各種APIの利用やら、専門分野のプログラミングやら、果てはもっと大型の問題など、いろいろ増えると面白いでしょう。

各企業としてはデータベースプログラミング能力については是非知りたいところでしょうね。sqliteを使えば、データベースを設計して問題を解くところまで一気にできますので、面白いかと思いますね。

「プログラマが正しく評価されていない！」とか愚痴を言う人は大勢いますが、こうやって解決策を実際に提示する人は本当に素晴らしいと思います。

中小企業のための最低限度のITセキュリティポリシー

一般企業向けのITセキュリティに関する指針は各種あれど、現実離れした理念的なものや、細かいことにこだわるばかりで実用性のないものなどを多く目にします。

個人的にもITセキュリティを高めることは日本の企業にとっても大変重要であると考えています。

が、多くの中小企業にとって、費用や手間のかかるITセキュリティ対策を実施することは現実的ではありません。

そこで、現実的に「脅威度」と「対策の容易性」に応じて、優先順位の高いものだけを掲載したセキュリティポリシーを作成してみました。あまりセキュリティに費用や手間はかけられないが、最低限度のセキュリティだけは担保したいという企業にお勧めです。

免責条項： 本ポリシーに従うことでITセキュリティが担保されることを保証するものではなく、本ポリシーには重大な間違いや抜けを含む場合があります。本ポリシーは、利用者が自己の完全な責任のもとに任意に使用するものとし、著者は利用者が本ポリシーに従ったことにより生じた一切の責任を負わないものとします。

（個人的に作ったものなので、色々足りない点やおかしい点などあるかと思います。コメントやブコメなどでご指摘頂ければ幸いです！）

発注者側から「なぜ価値創造契約がうまくいかないのか」を考える

永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance

永和システムマネジメントさんでは、アジャイルらしいシステム受託開発の方式として、ソースコードを納品しないで、利用中も継続課金するという契約方式を試行しておられます。

それが実は苦戦しているそうだということが、永和さんの発表資料から話題になっています。

私もソフトウェア開発を外注することも良くありますが、たしかに発注者の立場からみると、開発中も利用中もずーっと継続課金させるという課金方法で発注するのは、かなりうまくできた仕組みでないと難しいかなと思います。

当たり前ですが、ソフトウェア開発･運用を考えれば、開発フェーズの方がずっと重く、運用フェーズの方がずっと軽いわけです。

ですから、通常の契約では開発フェーズは多くの費用を請求し、運用フェーズでは少ない費用を請求するということになります。それは理にかなったやり方だと思います。

もし納品しない方式であれば、「開発フェーズの金額は受注者が負担し、長期的に回収する方式」なら発注者にはリスク低減メリットがあるでしょう。もしそうではない（稼働時間分を全て請求するor請求金額分しか稼働しない）のなら、単に発注者に対して余計なコストを背負わせているだけということになります。

価値創造契約では、開発フェーズの負担は永和さんが負うように見えますが、その部分をどのような計算で、いくらくらいの開発費や工数を永和さんが負担し、その金額をどのように後日の請求に回していくのか、ということがウェブサイト上では明確ではないように見えます。

経済的に見て、誰がどのように開発費などを負担し、それをどのように償還していくのかということを、きちんと経済学やファイナンスの知見を踏まえて、経営者にとって分かりやすいように説明する必要があるかと思います。

「スモールスタートで」と言うことが書かれていますが、わざわざ支払を繰り延べしてリスク低減する必要があるシステムというのは、スモールスタートよりも社運を賭けた一大プロジェクトのようなものになるのではないでしょうか。

スモールであれば、べつに一括発注でも、普通に人月契約でプログラマを雇って作らせても全く構わんわけですから。失敗すればまたやり直せばよろしなので。

永和さんには、まずファイナンスやミクロ経済学の観点から（リース契約などに習って）契約形態を見直し、ウェブサイトの記述なども見直し、経営者から見てメリットがある形に整理する必要があるかと思います。

もちろん契約書などもかなり入念にレビューして、双方にとって妥当性のあるものにしなければならんでしょうね。

ではでは。

2014/9/19 追記: あと顧客にとって特定の契約形態を押しつけられて売り込まれても何のメリットもないので、プッシュ営業するのは無理だと思いますね。あくまで選択肢の一つという形で提示しておいて、引き合いがあれば提供するという形でないと無理かと思います。

3分でDKIMの概念が分かる実践的ガイド

迷惑メール対策の仕組みとしては、SPF、DKIM、DMARCの3種類が主に使われています。

このうちSPFは日本でも広く使われていますが、DKIMは情報が少ないために殆ど使われている事例を見かけません。DKIMは決して難しすぎるわけではないのですが、概念を把握できるような情報が日本語で存在しないため、概要を掴むのに苦労します。

さて、DKIMとは何でしょうか。

一言でいうと、メールに電子署名を付与するための手法です。電子署名を付与することで、正しい送信者から送信されていることを証明し、送信者を詐称する迷惑メールに対抗します。

ややこしいのは、「誰が署名するのか」「署名を検証したらどう使うのか」ということが利用者の裁量に任されており、そのせいで概念が極めて掴みにくくなっています。


署名する方法と、署名を検証する方法はシンプルです。DNSにレコードを追加して、そこにRSA公開鍵をおきます。送信者は対応する秘密鍵を使ってメールに署名します。受信者はDNSに問い合わせして公開鍵を取得し、その公開鍵を使って署名を検証します。

DNSに記載するドメイン名は、(selector)._domainkeys.(domain)という形式になり、そのselectorとdomainは署名中で指定することができます。gmail._domainkeys.example.comというドメインであれば、example.comの持ち主が署名しているということが証明されます。

selectorは鍵の名前と考えれば良いかと思います。DKIMでは、異なるサーバーから送信する場合など、同じドメインに対して複数の鍵を使うことが多いので、鍵に名前をつけて管理できるようになっています。

このことから分かるのは、SPFはDNSに記載があると強制的に検証されますが、DKIMの場合は、あくまで送信されたメールに署名が付与されている場合のみ検証されるということです。SPFとDKIMは大きく違います。


「誰が署名するのか」ということですが、基本的にはFromアドレスの持ち主が署名するのが最も効果的な方法です。Envelope Fromなどが署名しても良いと思いますが、Envelope FromはSPFで検証できますので、DKIMではFromのドメインで署名する方がベターでしょう。

「検証した結果どうするのか」ということですが、いまのところは目立つ効果はあまりありません。DMARCと組み合わせてFromアドレス偽装を完全に防いだり、Fromアドレスを証明することで迷惑メールと認定されにくくしたり、そういった効果が期待されます。

最近はgmailを始め、各社のメールサーバーが迷惑メール認定を極めて厳しくしていますので、こうした手法を取り入れて迷惑メール認定を防ぐことはビジネス上、重要だと思います。

DKIMを付与するだけで、メールの送信に計算量がかかるようになるので、単純な大量送信迷惑メールとは一線を画することができます。


さて、DKIMの具体的な導入方法ですが、以下の通りです。

自分でRSA鍵ペアを生成する場合は、opensslを使って以下のようなコマンドで生成します。

openssl genrsa -out rsa.private 1024
openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM

ここで注意する点は、鍵長を1024bitにすることです。2048bitにするとDNSの1レコードに収まらなくなり互換性の問題を生じます。512bitは短すぎて受信者に検証拒否されます。

gmailのようなメールサーバーでは、鍵ペアを生成する機能を持っていますので、それを使って下さい。

DNSでは、(selector)._domainkeys.(domain)という形式のドメインに対して、以下のようなレコードを追加します。

v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB

署名したり署名を検証する方法については、メールサーバーやライブラリによりますので、それらの製品のマニュアルを参照して下さい。gmailなどは容易にDKIM対応が可能です。


DKIMについてより詳しく知りたい場合は、残念ながらRFCを読むしかないかと思います。

http://tools.ietf.org/html/rfc6376

真の人月商売こそが受託開発産業を救う ― 請負契約ではITプロジェクトは失敗する

私は自分では受託開発を原則として請けないことにしていますし、受託開発という産業にはあまり興味がありません。しかし現実問題として日本のソフトウェアビジネスの大半は受託開発産業です。

また自分では受託開発を請けないけれど、他人や他社にプログラミングを外注することはあります。今日は、受託開発のお話です。


受託開発産業でよく言われることに「人月商売からの脱却」などというフレーズがありますが、そうした発言はまさに愚の骨頂と思います。経済やビジネスの原理原則を知らない愚かきわまりない発言です。

受託開発というのは、プログラマーという専門職の時間を使って作業を提供して、その成果物を納品する仕事なのですから、コストは当然プログラマーの作業時間となります。

商品の値段というのは、通常はコストに利益を乗せて売られますから、プログラマーがどれだけ働いたかで算出されるのは、きわめて自然な値付け方式です。

「そうではなく、そのシステムが顧客にどれだけ価値をもたらすかで売りたい」という人がいますが、顧客の注文で作るシステムなのですから、その価値は顧客しか知りませんし、その顧客の価値を開発者が得られる理由がありません。

もしソフトウェアの価値でお金を取りたいのであれば、受託開発をやめて、自分で製品を作るべきです。もしくは受託開発で作ったものを、他社にパッケージ販売すればいいでしょう。そうしてみればソフトウェアの価値は良く分かります。

マッキンゼーなどの戦略コンサルタントから、建設業界まで、顧客の注文に応じてサービスを提供する企業では、基本的には労賃＋材料費といった計算方法で価格を決めています。

その人月単価をいくらにできるのかは、プログラマーの能力と、企業のブランド力や交渉力/営業力次第でしょう。人月だからといって、プログラマが一律に同じ値段でなければいけない理由がありません。


日本の受託開発産業を悪くしているのは、人月計算ではなく、請負契約などによって受託企業に成果物への責任を負わせる契約慣行です。

あらかじめ完成品の総額を決めて、それから開発にかかるという方式の請負契約は、ソフトウェアのように細かい仕様が全て先に決まらない業界には全く適していない方式です。ソフトウェアの開発は、製造や工事よりも研究開発に近い性質のものであり、見積もりを前もって正確に行うのは極めて困難です。

そうして請負契約でプロジェクトが開始されれば、始まるのはお決まりのパターンです。

発注者は可能な限り多くの仕様を詰め込もうとし、様々な点で修正を求めてきます。それにたいして受注者は、リスク分を見積もりに大幅に上乗せし、仕様をなるべく簡略化しようとし、変更を拒否することを試み、なるべく安いプログラマを使って最小のコストで最低限動くものを仕上げようとします。

これはまさにlose-loseの状況です。

こうした契約形態のせいで、予算超過リスクを負える大企業がシステムを受注し、それを多重下請け形態で、プログラマのスキルとは無関係に、ただ大量の人を集めて、低い品質のシステムをでっちあげるという歪んだ産業構造が生まれました。

請負契約は、あらかじめ仕様を細部まで詰め切れるプロジェクトにしか適用できません。

数十万円の超小規模案件ならそれでも良いでしょうが、大きなプロジェクトになると、仕様策定自体が一大プロジェクトになってしまい、ウォーターフォールで多くの仕様の誤りが生じるので無駄過ぎますね。ルールの厳格な政府調達ならともかく、民間企業がそんな無駄をする理由はありません。


ソフトウェア開発というのは、建設業よりもコンサルティング業に近い産業です。

あらかじめ仕様と設計を細部まで定義して、それにもとづいて見積もりを立てるウォーターフォール方式が良い方法ではない以上、成果を約束させるのではなく、拘束時間に基づいてお金を払うしかありません。準委任契約/派遣契約などに切り替えるということです。

その場合、請負契約のように総額の予算や納期が契約で決まっているわけではありませんし、プロジェクトマネジメントは発注側で行い、発注側が予算や納期について責任を負うことになります。もし発注側にプロマネを出来る人がいなければ、ITコンサルタントなどを雇わなければなりません。

しかし、それにより、発注者と受注者は同じゴールに向かって歩むことが可能になります。「良いソフトウェアを作る」という共同のゴールを持つことができるようになります。

日本でも、いまどきのインターネット企業などでは、請負契約で業者にシステムを作らせているところはないでしょう。そんな方式では、開発速度も遅く、品質も下がってしまうので、競争を勝ち残れません。

一般企業にとってもITの重要性が増す中で、良いソフトウェアを作るためにソフトウェア内製化などに切り替える企業が増えているといった話もあるようです。


発注者側にとって、時間払いの新方式に切り替えるのは、そこまで難しい話ではありません。プロマネをしてくれるITコンサルタント企業さえ見つかれば、実現できるでしょう。

この新方式では総額が決まっていないので発注者にとって余分なリスクがあるようにも思われますが、実際は逆です。

できてもいないシステムの総額にたいして請負契約を結べば、受注者がへぼい仕事をしても途中でキャンセルすることもできず、結局はお金を払ったのにへぼいシステムしかできないというリスクが大きいのです。

それに対して、時間払い方式であれば、品質に満足できなければ合理的な予告期間のあとでいつでも契約を終了することができるでしょう。これはリスクを減らす方向に働きます。

とくに最近はシステムが完成しなくても、どんどん出来たところから動かしてみて、品質を顧客がチェックしていくことができるので、よりこうした方法は実現しやすくなりました。


受注側がこの方式に切り替えるためには、顧客側にも変化を要求することになるので、もっとハードルが高いです。

しかし株式会社ソニックガーデンのように、顧客にこうした方式を要求して、実践している会社もあります。

報われない、疲弊するといった悩みを抱えている受託開発企業は、契約形態を見直して、本当に顧客のためになる仕事をできるように変えていくしかないのではないでしょうか。

人月からの脱却ではなく、真の人月として、働いた時間に応じてお金をもらう、それがプロフェッショナルの働き方だと思います。ワインバーグは「コンサルタントの秘密」で何十年も前にそれを述べています。

では。

経営者にも分かるAmazon Web Services (AWS)の利点

IT企業の経営者といっても全員が技術者であるわけではありません。

そうした方々はAmazon Web Services (AWS)の利点があまり深く理解できず、とりあえず安いからと適当なVPS, ホスティングや他社のクラウドを選んでしまうことが多いようです。

しかし、よほど予算に強い制約がある場合や、特殊な要件を除けば、現在ではAWSがファーストチョイスであることに疑問の余地はありません。現時点でAWS以外のクラウドやホスティングを選択する理由はないでしょう。

AWSは、他社とは異次元の圧倒的な高性能クラウドなのです！

なぜAWSを選ぶべきなのでしょうか。その理由は３つあります:

1. メンテ費用が下がる
2. 高い信頼性が容易に実現できる
3. 多機能によるエンジニアリングコストの削減


まずメンテ費用が下がるということですが、OS陳腐化に伴うシステム移行費用(数年間で数百万円以上）を無くせること、日々の保守作業を容易にできることの二点があります。

Amazonは独自のAmazon LinuxというOSを持っており、それを使うことでAmazon EC2の仮想OSとの適合性が保たれ、利用を続けたままで自動的にOSのアップデートをしていくことができます。

そのため、OSが陳腐化することなく、OSのアップデートに伴う移行作業などのメンテ作業を大幅に減らすことができます。システムの移行作業はエンジニアが数人月かかりきりになることも珍しくなく、そうなると数百万円の支出になります。

またサーバーの停止や故障が生じたときもエンジニアの手を借りることなく、簡単にウェブ上からサーバーの再起動や別サーバーへの移行などが行えますので、保守体制も縮小することができます。

サーバーのフルバックアップというと、通常はエンジニアが頑張って手作業でやるか、高価なハードウェアやソフトウェア(数百万円クラス)を購入して行う必要があります。しかし、Amazon EC2ならそれもワンクリックで行うことができます。


高い信頼性が容易に実現できるという点ですが、AWSでは様々な信頼性向上の仕組みを用意しています。

Amazon RDSでは複数データセンターにまたがるデータベースの冗長化(リアルタイム複製)と自動切り替えを標準でサポートしています。

いまやデータベースを運用すること自体は難しい作業ではありませんが、データベースの冗長化と自動切り替えを実現するとなると、一般のエンジニアから見ると、手間のかかる厄介で難しい作業です。

またAmazon EC2ではAmazon EBSという仕組みでサーバーのハードディスクをサーバーから切り離して運用することが可能です。そうすれば、もしサーバーが故障しても、すぐに同じディスクの内容で別サーバーから起動することができます。

先ほど述べたようにサーバーのフルバックアップも簡単に行えますし、データベースのバックアップも自動で確実に行うことができます。これだけでもシステムの信頼性が大幅に向上することは明白です。通常の技術者によるオペレーションでは、必ずミスが付き物ですから。


AWSの持つ圧倒的な多機能性は、エンジニアリングコストの大幅な削減につながります。

DynamoDB, ElastiCache, Elastic Load Balancing, Auto Scalingなど、エンジニアが手放しで多くの機能を利用することができるため、貴重なエンジニアの時間を本来の価値ある業務に注力させることができます。

こうした機能は、とくにゲームやソーシャルや金融などの高負荷なサービスを開発するには必須といえます。これを自社でエンジニアが頑張って運用するのと、Amazonにお任せで運用するのでは、開発スピードに大きな差がついてくるでしょう。


AWSを他社クラウドやVPSと比較して「割高」というのは、全く間違っています。

AWSは他社と比較しようが無いほどの高機能を備えており、値段だけで比較の対象とできるようなものではありません。

AWSがもたらす中長期的なコスト削減効果と信頼性向上を計算にいれた上で比較検討するべきです。

Softether VPNを使って中国でインターネットを使う

【注意】たぶん中国で個人がVPNを使ってアクセスするのは犯罪です。(よくしらないけど)

さて中国に数日滞在してきたのですが、いつも中国で困るのはネットにアクセスできないということです。

日本人が日頃よく使うようなfacebook, twitter, google, gmailなどは金盾と呼ばれる国家ネット規制システムでブロックされており、全くアクセスできません。これでは友人と連絡もできないし、調べ物もできないし、仕事の連絡もできないし、大変困ってしまいます。

そこで今回はSoftether VPNを使って、VPN(仮想専用線)で日本のサーバー経由でインターネットにアクセスしてみることにしました。

VPNにはPPTPなど他のプロトコルもありますが、Softether VPNは高速で、かつSSLプロトコルを使うのでVPNを使っていることが判明しにくく、そのためブロックされにくいという利点があります。

以前は中国からPPTPで日本のデータセンターに接続を試みたことがありましたが、かろうじてつながるものの、速度が遅くて使い物になりませんでした。

Softether VPNは、他にも信頼できないネットワーク(公共のWiFiなど)からアクセスするときなど、幅広く使えますので、設定しておいて損はない製品です。Windowsに予め入っているPPTPと異なり、ソフトのインストールが必要になるのが難点ですが。

中国はネット利用者の情報を収集していると思われますので、セキュリティ上もVPNを使うことが望ましいでしょう。


結論から言うと、Softether VPNを使えば、2013年12月現在では中国でもある程度の自由なインターネット通信が可能です。facebookにもtwitterにも接続できます。なぜかGoogle社の運営するサイトはVPN経由だとアクセスが遅いように感じました。なぜでしょう。

但し、数日間なんども利用しているうちに徐々に速度が遅くなるようにも感じましたので、動的に通信制限などが行われている恐れもあります。ずっと同じサーバーを使い続けることはできないかもしれません。


Softether VPNの利用には、常時接続状態にあるサーバーまたはパソコンが一台必要です。可能な限り、固定IPアドレスを持つ物が良いでしょう。なぜなら信頼できないネットワークでは、DNSによって名前解決ができるかどうか、そもそも怪しいからです。

簡単な方法としては、ホスティングサーバーなどを一時的に借りてセッティングする方法があるでしょう。

インターネット上には他人が設置している自由に利用できるVPNサーバーなどもありますが、そういうものを利用すると全ての情報を盗み見られたり、不正ソフトを仕込まれたりする可能性がありますので、決して他人が設置したVPNサーバーは利用しないでください！

Softether VPNの設定には、GUIからリモートで行うことができる優れた仕組みを採用されていますので、ネットワークに詳しい人ならば誰でも設定が可能です。但し、ネットワークの基礎知識が無い人は、手引きなどがないと設定は困難でしょう。

パスワードなどをきちんと設定して、他人に勝手に使われないよう注意しつつ、設定を行って、まずは日本にいるうちに正しく通信ができるか確認してください。

「サーバー証明書を必ず検証する」という設定は必ずオンにして、サーバー証明書の仕組みを利用して下さい。さもなくば、中間者攻撃という方法によって通信が乗っ取られる危険性が多分にあります。中国政府くらいの能力を持つ組織であれば、それくらい簡単なことでしょう。


これで中国でも数日間なら何とかネット通信が可能になります。

私は中国語を習っていますので、中国に住めれば良いと思いますが、このようなネット規制の行われている国に住むのは難しいですね。正直言って、よく外国人がこんな国に住むよなあ、と思います。このような規制を続けたまま、中国が発展することは可能なのでしょうか？

中国という隣国が、強権的な政府を持っていることを残念に思います。早くもっと民主化してくれれば良いのですけれど。でも、もし中国が自由な民主主義社会になったら、中国はさらに発展して、日本やアジアはすぐにそのパワーに取り込まれてしまうでしょうね。

このような独裁強権国家である中国で検閲に協力してビジネスをするような外国企業は恥ずべきですし、そのような企業の行いを日本国民は許すべきではありません。Googleが中国政府の検閲を拒否して、中国市場から撤退したことは、まさに全世界の企業が手本として見習うべき行動です。

中国政府の検閲に協力することは、独裁国家の人権弾圧に協力することです。北朝鮮やシリアに武器を売ったりすることと大差ありません。将来的にはそのような人々は、国際刑事法廷で裁かれて投獄されることになる日が来ることを祈ります。

【注意】たぶん中国で個人がVPNを使ってアクセスするのは犯罪です。(よくしらないけど)

【免責事項】この記事に従った結果、公安に踏み込まれて銃殺刑になっても私は責任を負いかねますので、ご自分の判断でリスクを取って実行して下さい。

なぜ起業チームにはプログラマーが必要なのか

IT産業は起業にもっとも向いた産業とよく言われます。

当初の資本金はあまり必要でなく、無難なビジネスモデルを構築すれば、早期にお金が入ってきますし、とてもうまく行けば人数などを増やすことなく加速度的に売上を増やしていくことができます。

しかしITビジネスを作り上げるためには、創業メンバーにプログラマーがいなければうまく行きません。

ITビジネスにおいて、ソフトウェアシステムとビジネスは密接に結びついているため、ビジネスとシステムのすりあわせをできるプログラマが創業メンバーにいなければいけないのです。

単なる外注や、一従業員のように受け身の立場でシステムを構築する人は、システムの仕様がきっちり決まっていればちゃんとした仕事をしてくれるでしょう。

しかし、システムの仕様を決めるのは、ソフトウェアの高度専門家でなければできない仕事です。

かといって通常の会社に外注して仕様を決めてもらおうとしても、ビジネスに対するオーナーシップを持っていませんから、システムの必要性からビジネス自体を変更したりすることができず、中途半端な仕事に終わってしまいます。

システムの仕様決定には、ビジネスのオーナーシップを持つ創業者レベルの人が携わるのが望ましいのです。

またシステム作成と仕様作成は一貫して同時並行して行うことが望ましいのです。なぜならシステムを作っている途中で、新たに設計上、ビジネスを変更したりする必要が明らかになるからです。

しかし外注する場合は、予め仕様を決めて発注しなければ、予算が確定しませんので、契約を結ぶのが難しくなります。

予め仕様を決めて発注してしまえば、予算は確定しますが、こんどはできあがったものが思うようにビジネスに適合するとは限らなくなります。


そういうことから、可能な限り、プログラマを創業メンバーとして迎え入れて、給料ではなく志に共感してくれて、株式をシェアすることで一緒にやってくれる人を探すことをおすすめします。（なかなかそういう人はでてこないとは思いますが）

もちろん「給料がなければ嫌だ」という人でも仲間にいれて良いと思いますが、とにかく企画レベルから参加してもらい、プロジェクトのオーナーの一人として扱うことが大切です。

単なるシステム開発会社に外注してシステムを作ってもらうというやり方では、IT起業が成功する確率は大幅に下がることでしょう。

プログラマではない人が、優秀なプログラマを探したり、優秀なプログラマを見分けることはなかなか難しいので、そこは悩みどころですね。

とはいえ、きちんと責任をもってチームメンバーとしてプログラムを書いてくれる人であれば、平凡な能力なプログラマーだとしても、外注先の優秀なプログラマーよりもマシであると僕は思います。

私自身は現在プログラミングの仕事はお受けしておりませんが、ITビジネスの企画･戦略･仕様策定のお手伝いなどのお仕事や、優秀なプログラマを抱える会社の紹介などしておりますので、 arai@mellowtone.co.jp までお気軽にお問い合わせください。

あと最近ではソニックガーデンや永和システムマネジメントのように、プロジェクトのオーナーシップを持って共同開発という形でシステムを作ってくれる会社もあるようなので、プログラマがどうしても見つからなければ、そうした会社に依頼するのも一つの手かもしれません。

ではでは。

参考:

1. 助け合いの社会を作りたい！ 〜 AsMama甲田社長がソニックガーデンを選んだ理由 | Social Change!

oDeskで本格的な開発プロジェクトをやってみたよ

oDeskをつかって本格的なソフトウェア開発プロジェクト(1人月)をやってみたので、そのご報告です。oDeskをつかってみようと思う方には、かなり参考になるのではないかと思います。

oDeskとは、世界中にいるフリーランサーやアウトソース企業にさまざまな仕事を頼むことができるアウトソースサイトです。他のサイトと比べた特徴としては、作業内容の記録ツールを使った時給払いに対応していることです。クレジットカードで支払いできて送金も楽ちんです。

今回なぜoDeskを使ってみたかというと、純粋に海外アウトソーシングに興味があった点が一つ、もうひとつは少しでも開発コストを減らせないかという考えがありました。

開発コストの観点から言うと、oDeskで雇える人のうち、しっかりした実績があるような人の時給は$25くらいに設定されているので、人月40万円くらいの計算になります。

日本でもジュニアプログラマなら人月40～60万円くらいで雇うこともできるのではないかと思いますし、相当優秀なシニアプログラマでも人月80～120万円くらいなことを考えると、コスト削減効果としては、ちょっと微妙です。クラウドワークスを見れば、時給2500円くらいで働いてくれそうな人がごろごろいますし・・・

そういうわけなので、今回oDeskでの発注に踏み切ったのは、海外アウトソースの実情を知りたいという好奇心の点が大きいかもしれません。


使ってみて最初に思ったことは、プロジェクトマネジメントがしんどいということです。

英文でやりとりしたり、英文仕様書を書いたりする手間を考えると、プロジェクトマネージャーである私の作業時間が取られてしまいます。

そしてお互い外国に住んでいるわけなので、もしトラブルになったとしても訴訟などを通じて解決することは現実的ではなく、すべてを慎重に交渉して進めていく必要があります。また赤の他人に依頼するとなると、やりとりにもかなり気を遣います。

通常の開発案件であれば、国内の安いフリーランサーを見つけて、そういう人に頼むほうが楽なのかなー、と思いますね。そういう人が、うまく見つかればですけど。

もともと英語で開発してるとか、全世界向けに開発してるような会社であれば、oDeskはお勧めですけども、日本語でやってる普通の会社にとっては言葉の壁が厚いです。


今回の案件に関して言うと、かなりうまくいったと思います。

まず依頼した時点で、時給が高くても、きちんとした返事を返してきたウクライナの業者を選定しました。oDeskでは、雇う対象をフリーランサーに絞るよりも、業者に任せた方が安心感があると思いました。

彼らは、25ドルの時給の中で、プログラマーだけでなく、英語が上手な連絡担当者も担当者としてつけてくれました。なにか問題や不明点があれば、すぐに聞いてきますし、きちんと着実に仕事を進めていきます。こっちからいちいち突っつかなくても、向こうから主導的に仕事をしてくれます。

結果的に、日本で外注したときの予想価格に比べて、半額くらいの値段で、きちんとした品質の製品を完成させることができました。

日本のシステム開発業者と比べても、かなりそつのない真面目な仕事をしていると思います。この値段で、この品質でやってくれる会社があるのだから、アメリカなど英語圏のプログラマーは大変だろうなあ、と思いますね。


僕はあまり自分の仕事能力に自信を持っていないのですが、英語で一つプロジェクトを完遂させることができて、すこし自分の能力に自信が持てた気がします。

なぜAmazon Web Servicesを使うべきなのか

弊社では、ぼちぼちとAmazon Web Services (AWS)を試用してきておりますが、色々使ってきてみて思うのは、AWSは素晴らしいシステムであり、特別な用途を除けば原則としてこれからのシステムはAWSで構築するのが良いのかなと思いますね。

AWSが優れている理由は、とにかく運用やソフトウェア開発を楽にする機能が豊富に揃っており、運用までをフルサポートしてくれる垂直統合環境であり、APIやソフトウェア、ドキュメントの品質や使いやすさが極めて優れていることです。そのため、システム開発運用のコストが大幅に下がり、システム運用の品質を上げることができます。


まずAmazon EC2 (仮想マシンホスティング)から説明すると、一つにはAmazon LinuxというEC2専用のLinuxがあることは大きなメリットです。

Amazon EC2のインスタンスに最適化されていますので、簡単に安定利用できるだけでなく、OSアップデートもyum updateするだけで安心して行うことができます。そのため、サーバーが陳腐化してシステム移行が必要になることがありません。これにより、システム移行工数(数人日～数人月)が削減できるのは大変なメリットです。より大きいサーバーに変えることも一瞬でできます。

EC2の有用性はEBSという外部ストレージのサービスを使うと、さらに強化されます。インスタンスのスナップショットによるフルバックアップを１クリックで取ることができますし、スナップショットをひな形にして新しいサーバーを立ち上げることも簡単にできます。(自動で定期的にフルバックアップを取得する機能がないのは不可解ですが....)

Amazon Route53は、DNSのホスティングというニッチな領域ですが、非常に便利なサービスです。AWSの持つ信頼性や、グローバルな拠点を活かして、世界中の顧客に高速なDNS解決を提供できます。もう、わざわざ脆弱性だらけのBINDなどをDNS権威サーバとして使う必要はゼロでしょう。

Amazon S3は、システム開発を圧倒的に簡単にするという点で大きな価値があります。これまでは一つのサーバーの容量を超える多数のファイルを格納するためには、極めて高額なストレージ製品を使うか、独自で分散ファイルシステムを構築しなければ行けませんでした。それがS3では、圧倒的に簡単に運用を行うことができます。

Amazon S3とGlacierを利用すれば、ログやバックアップなども簡単かつ安価に保存していくことができます。

DynamoDBのような分散データベース環境は、素人が運用するのは極めて困難ですので、それが管理まで任せられるというのも大きなメリットだと思います。ただし現時点では、１クリックでバックアップを取るような機能がついていませんので、その点では運用性がまだいまいちかなと思います。

Amazon Cloudfrontは、コンテンツ配信システム(CDN)であり、ファイルや画像などを世界中に高速配信することができます。弊社では、一部サービスで海外からの表示を高速にするために使っています。Akamaiのような高額なCDNに比べて、無料みたいな値段で使えるので、ちょーおすすめです。


AWSを使う上で気をつけるべき点としては、EC2は他社レンタルサーバーより割高なことと、メール送信に許可が必要なので非常に面倒くさいことですね。

まずEC2から外部へメールを送るためには、基本的に許可を得ないと送れません。その時点でかなり面倒です。さらに不着率が高かったりすると許可を剥奪されます。

Amazon SES(バルクメール送信サービス)を使ってメールを送信すると30%程度の不着率で数千件メールを送っただけで、許可を剥奪されてしまい、英文で釈明するはめになりましたので、非常に使いにくいかなあという印象です。

メールサーバーは別のサーバーを利用するなり、他社のサービスを利用するなりしたほうが良いかもしれませんね。このあたり改善を期待したいところです・・・

ほかにAWSが不向きなシステムとしては、大量の計算資源を継続的に使い続けるものですね。やはりその場合は、自前で構築する方がずっと安くなります。但し、大企業や官公庁が大手システムインテグレーターに依頼して構築・運用するよりはAWSの方が安いと思いますが。

例えば、動画配信など、継続して大量のストレージや回線を使う場合があるでしょうか。またHPC(スーパーコンピューター)なども継続してずーっと使い続ける場合も同様ですね。この場合は、色々とハードウェアやデータセンターの調達を工夫することで、自社調達すれば、AWSよりもコストを下げることができると思います。

弊社でも動画のストレージは自社で運用してますが、S3よりもストレージコストは大幅に割安です。そのあたりは工夫次第かと思います。

うまくAWSを使いこなしていくことが今後のシステムでは基本となることは間違いないと思います。AWSは他社に比べると機能や技術力で圧倒的に上をいっていますので、しばらくはAWSの圧倒的優位は揺らがないでしょう。

クラウド以外ですと、市販ソフトウェアやオープンソースソフトウェアで、AWSと同じような機能を謳う物はいろいろありますが、あまり信用しないほうが良いかと思います。実際はうまく動かなかったり、操作性や運用性が著しく悪かったりと、品質問題が多発しますので。

学習の方法 / Courseraと拡大する格差

いま私の東京の友達の間ではCourseraというオンライン学習サイトが小さなブームになっています。これは、米国のトップ大学のトップ教授たちの講座が無料で受けられるもので、すごい面白くて役立つ授業がたくさんあります。

Courseraや学習について、とりとめのない話をいろいろと書いてみます。本当にとりとめがない随筆なので、軽く読み飛ばしていただければと思います。つまらなかったらごめんなさい。


私はCourseraでは、Machine LearningとAlgorithms: Design and Analysis Part1の授業を修了し、いまはPart2に取りかかっています。そこまでの感想などをまずお話しします。

Courseraは真に革新的なオンライン授業を提供していると思います。画期的である理由は以下の通りです。

1. (これらのコースでは)教授がものすごく教えるのが上手であり、熱意をもって、素晴らしい講義や教材を提供している。
2. 適切な試験や課題などを提供することで、講義を聞くだけにとどまらず、きちんと手を動かして学ぶためのコースとして成立している。
3. 修了するとpdfで修了証がもらえるので、ちょっと頑張ろうかなという気になる。
4. 授業のスケジュールが決っているので、いちど登録したらスケジュールに沿って学ばなければならない。そのため独習とちがって、ペースが遅くなりすぎて投げ出してしまうことが少ない。

私がとったコースは本当に素晴らしい授業内容であり、こうしたものが提供できるのであれば、大学で教授がライブで講義する必要というのはゼロですね。講義はすべてビデオにして、わからないところだけ教えてあげたり、試験や課題だけ大学においてチェックするような仕組みになっていくのではないでしょうか。

私は中卒で独学でプログラミングを学んだので、計算機科学もわかりませんし、数学もちんぷんかんぷんです。それが、これらの授業を受けたことで、プログラマーとしての可能性が大きく広がったと思います。弊社の事業にもいろいろと活かす方法が思いつき、とにかくわくわくします。

ただし、ビデオ講義だからといって優れているとは限らないのですよね。日本の放送大学は長年にわたってビデオ講義を提供していますが、その品質は「悲惨」の一言です。どの講義も、あまりに退屈で意味不明すぎて、とてもじゃないですが見られた代物ではないですね。なぜこれほど品質に差がでるのか、正直いって不思議です。Courseraでも、今後、コースが増えてきたら品質が下がってしまうのではないかと不安です。

もしCourseraがこの水準の授業を数百～数千コース提供できるとしたら、高等教育は完全に変わってしまうでしょう。英語圏の大学はすべてCourseraによる授業に切り替えるのではないかと思います。そうなれば、日本も政府が予算をとってCourseraを翻訳提供するなどの措置が絶対に必要になるでしょう。それほどレベルが高い授業です。

ちなみに社会人がCourseraを受けるなら、一度に一つの授業を受けるのが限界だと思います。一つに絞って、なんとしても修了する気概で食らいついてください。正直、Algorithm Part2は終盤かなり難しくなってきて、かなり苦労しております・・・


今月、東京でCourseraユーザーの小規模なオフ会を開きました。日本では、どういう人がCourseraをやっているのか、何の目的でやっているのか、興味があったからです。

結果から言うと、参加者は外資系超一流企業のエリートの方ばかりでした。

まぁ英語で大学レベルの授業を自主的に受けようという人は、そりゃエリートに決っているかもしれませんが、ちょっと厳しい結果だなと思いました。ちなみに、オフ会自体も英語でやったので、その点でもバイアスはあるかもしれません。

私のように高校にも大学にも行かなかった人間にとって、Courseraのような無料オンライン教育というのは、素晴らしい機会です。それによって社会の格差が縮まれば素晴らしいなあ、と思っていました。

しかし現実には、日本においてCourseraは格差を拡大する方向につながってしまいそうです。エリートほどCourseraの恩恵を受けて、スキルを強化していくでしょう。

残念ながら日本の中卒・高卒および二流大学卒の人の多くは、大学の授業が受けられるレベルで英語ができたりしないでしょうし、高校レベルの数学の知識なども欠いているでしょう。

なによりも、多くの非エリートの人に欠けているのは、自分の知識と学力でもって社会で成功してきた成功体験ではないでしょうか。

日本の教育制度や学習者の姿勢というのは、とにかく学歴と資格の二つに集中しています。学ぶことによって、それがどのような役に立つかということは二の次で、とにかく試験勉強ばかりです。

試験は「何を学べば良いか」「どれくらい達成できているか」について、大まかな枠組みを与えてはくれますが、やはり「どんな知識が得られるか」「どう社会で役立てるか」に比べれば、ずっと些末な達成目標です。試験勉強に偏重した日本の勉強法はいまの時代にそぐわないと感じます。

Courseraをいくら学んでも資格はもらえませんので、Courseraで学ぼうという人は、資格にもならない勉強を自力で学ぶだけの意欲があるということです。このような姿勢がこれからの社会ではとても大切になると思います。


じゃあ、エリートでもない人間が具体的に何をどう学べば独力で成功できるのか？

いま間違いなく役に立つのはプログラミングではないでしょうか。プログラミングができれば、中卒で地方在住でもなんとか家族を食べさせられるくらいの給与は得られますし、仕事に困ることもないでしょう。

そこそこの学歴と何らかのスキルがあるなら、英語もすごく役立ちます。大卒以上で英語とプログラミングが上級なら、東京ではすごく良い仕事が得られます。学歴やスキルがない人は、英語ができても良い仕事にありつくのはちょっと難しいかもしれませんね。残念ながら地方では英語ができても、まともな仕事はないでしょう。

ま、仕事に役立たなくても英語は学ぶ価値があると思います。英語ができなければ、文盲と同じですから。世界の99%を見ることも知ることもできずに生きていくというのは、あまりにむなしい生き方だと思います。井の中の蛙でよいのですか。

Courseraのようなものが、これからどんどん発展して、それが日本語に翻訳されないとするならば、英語を学ぶことは誰でも必須になってくるでしょうね。それくらいCourseraは画期的です。

学習法についてうだうだ書くつもりはありませんが、とにかく気合いをいれて学ぶしかないでしょうね。いまどき英語やプログラミングくらい誰でもできて当たり前という心構えで臨んでください。時間も根性も必要ですが、やるしかないのです。

ARM社のビジネスモデルとIntelの将来

現在のスマートフォンやタブレットの大半はARM社のプロセッサで動いているのをご存じでしょうか？ iPhone, iPad, Kindle, Nexus 7も例外ではありません。

ARM社は、製造設備を一切持たない半導体企業です。しかし、ただのファブレス企業ではありません。ARM社は、自社でプロセッサを製造販売することは一切なく、プロセッサの設計図を他社に販売して稼いでいるIP(知的財産)ベンダーなのです。

ARM社からCPUの設計図を購入したSamsungやTexas Instrumentsなどのメーカーは、CPUを自社で好きなようにカスタマイズして、自社や委託工場(ファウンドリ)でプロセッサを製造して利用したり外販したりします。


ARM社の強みは二点です。

一つには、ARMは低消費電力CPUに特化していることです。モバイル機器では、消費電力が最も重要な要素です。最近では、サーバーやノートPCでも消費電力が重要視されるようになってきました。

もう一つには、ARMは組み込み向けSoC(System on Chip, 統合型プロセッサ)に強みを持っていることです。SoCは、メモリ管理・ビデオ・ネットワークなどの周辺回路をCPUのチップに取り込むことで、実装面積の低減、消費電力の低減、コストの削減を実現します。これはモバイル機器に極めて重要な要素です。

ARMはカスタマイズ可能なCPUの設計図を販売していますので、購入したメーカーは独自の周辺回路や他社から買った周辺回路などを一つのチップにまとめて製造することができます。これはIntelのようにCPUを製造販売している企業には不可能な芸当です。

いくらIntelが強力な企業であっても、一社で全ての周辺回路を開発することはできませんし、多種多様なチップを製造販売することは困難です。

これがIntelのビジネスモデルを大きく脅かしています。


スマートフォンやタブレットは、PCの領域をどんどん切り崩していますし、今後もその流れは止まらないでしょう。そのうえ、ARMプロセッサは十分に進歩しており、今後はPC用としても使われるようになるかもしれません。

初心者ユーザーにとっては、複雑で使いこなすのが難しいWindowsやMacOSのPCよりも、AndroidやiOSのような使いやすいOSを好むのではないでしょうか。そうなれば、キーボードの付いたAndroidノートPCなどが市場に進出してくるのも時間の問題でしょう。

何よりIntelにとって恐ろしいのが、サーバー分野へのARMプロセッサの進出です。

先日、私がIBM BlueGene/Qの記事でも述べたように、サーバー領域においても消費電力や実装密度などが重視されるようになっています。System on Chipによる消費電力と実装密度の向上は、サーバー分野でもどんどん活用されていくでしょう。

サーバーは、PCと異なりWintelの牙城ではありません。Linuxさえ動けば良いという世界です。

数年後には、低価格サーバーというのはSoCのCPUとDRAMとSSDが一つの基板上に実装された、小さなカードのようなものになっていることでしょう。一つのサーバーラックに数千～数万のサーバーノードが実装され、仮想化というのは、サーバー資源の切り分けではなく、単なる管理用・可搬性向上の機能になるのではないでしょうか。(スケールアップよりスケールアウトが容易なことを考えれば、仮想化によるサーバー集約というのはコスト効率の劣る方法です。)

そのときに、サーバーでの勝者はIntelになるのかARMになるのか、興味深いところです。GoogleやAmazonのように大量のサーバーを必要とする企業はARM寄りになるかもしれませんね。

追記: (2012/10/21)

HPはすでにそのようなSoCサーバーを試作しているのですね。1Uあたり72ノードとのこと。おそろしや。

レンタルCTOはじめます

注: 写真はイメージです。

こんにちは、新井です。

個人の取り組みとして、新たにレンタルCTOという活動を始めてみようかと思います。すなわち非常勤の技術コンサルタントとしてベンチャー企業などにアドバイスを行う試みです。

昨今の経営環境では、IT技術の活用が必要不可欠となっていますが、一般企業が優れた技術者を見つけることは容易ではありません。しかし、経営陣にIT専門家がいなければ、ITを高度に活用してビジネスを行うのは難しいのが現実です。

そうした企業の技術参謀役として、ビデオミーティングなどによりアドバイスを行う「レンタルCTO」業をはじめます。


私は、日本を代表する著名技術者ではありませんし、最優秀の経営者でもないでしょう。しかし技術と経営の両方を分かっていて実践している人材という点では、日本では極めて稀少な部類かと思います。いわゆるコンサルタントなどと違い、いまもプログラミングや経営を自分で行っていますので、実用的な知見を提供できます。

これまで、有料動画配信モール、名刺管理ITサービスなどの企画・開発・運用までに携わってきました。動画配信モールは、現在では100TB以上のストレージ容量を運用する巨大なサービスとなっています。

この動画配信モールは、私に開発依頼があったときには、P2P技術を使って安価に動画を配信するという企画でした。しかし私がP2P技術のメリット・デメリットをお話しして、P2Pは今回の案件には適切ではないことをご理解頂き、最終的には通常のサーバーから配信する形式で開発することになりました。

日本でP2P技術で動画配信を行う事業は一つもうまく行かなかったことを考えると、この選択によってビジネスを失敗から救うことができました。

このように、適切な判断のできる高度な技術者を経営判断に活用することは、テクノロジービジネスにおいては必須であると考えます。「プログラムが書けます」というレベルの技術者と、経営判断をゆだねる技術者に求められる知識は全く別のレベルです。


私にとっても、レンタルCTO役をやることで、これから新規事業を手がけるにあたり、様々なビジネスから知見を得たり、新しく優秀な経営者の方々とお知り合いになれるのではないかと期待しています。

私自身の新規事業開発の時間もあり、コンサルティングに使える時間は限られていますので、先着３社までの限定でお受けさせて頂きます。

お互い相性が大切かと思いますので、まずは気軽にお問い合わせ頂き、チャットなどでお話しできればと思います。

お問い合わせは arai [at] mellowtone.co.jp まで。

レンタルCTO基本プラン
* 毎月10万円 (年商1億円以下の企業や個人事業主は毎月5万円に割引します)
* 4時間のビデオミーティングを2回/月
* メールとチャットは無制限 (回答までの時間は無保証)

お手伝いすること:
* IT活用ビジネスに関する企画のアドバイス
* 技術者の採用および、ITアウトソーシングに関するアドバイス
* 基本的な開発プロセスマネジメントに関するアドバイス
* 基本的なITセキュリティに関するアドバイス
* 技術基盤(アーキテクチュア)に関するアドバイス
* システム設計、開発、運用に関するアドバイス

得意な領域:
* ビジネスと技術にまたがる領域 (テクノロジービジネスの企画等)
* ウェブビジネス
* ITベンチャー企業 (受託開発業を除く)
* システム設計
* データベースアプリケーション
* システムの高速化

得意でない領域:
* 大規模エンタープライズシステム
* 大規模プロジェクト
* 市販業務パッケージの活用ノウハウ
* ゲーム開発
* ソフトウェア受託開発業
* 先進的な開発プロセスマネジメント (アジャイル、テスト駆動開発、継続的インテグレーション等)

Martin Fowlerの新刊 NoSQL Distilled を読んだよ

NoSQL Distilledは、Martin FowlerとそのThought Worksの同僚によって書かれたNoSQLへの簡単な概略書です。ページ数も薄く、150ページ程度しかないのですが、英語が苦手な我々日本人には、かえってありがたいですね。概略書といっても、日本の本とは違い、実際に実運用で使った人にしか分からない、深く突っ込んだ考察も随所で行われています。

本書では、なぜNoSQLを使うのか、という理由を、水平スケーラビリティ、プログラムの容易さ(プログラムに適したデータモデルの利用)という2つとしています。

NoSQLの水平スケーラビリティについては改めて言うまでもありませんが、プログラムの容易さというのは興味深い観点だと思いました。いわゆるリレーショナルモデルとプログラム言語のデータモデルとのインピーダンスミスマッチを解消する手段としてNoSQLを使うという考え方です。

キーバリューストアやドキュメントデータベースなどでは、一つのレコードをAggregateというひとまとまりのデータと考えることで、配列やハッシュなどのごちゃまぜになったデータ構造をうまく保存できるとしています。この部分については、NoSQLのデータ構造をうまく説明していますので、一読の価値ありです。

またNoSQLの持つスキーマの柔軟性は頻繁な変更のあるシステムと相性が良いのではないかと指摘しています。

また本書では、NoSQLといっても水平スケール指向のものだけでなく、Graph Databaseのように一つのサーバーだけで動かすことを中心にした種類のものにも言及されています。

ドキュメントデータベースなどは、JSONなどのデータにたいして柔軟なクエリを行うこともできるので、一つのサーバーだけで動かすのでもメリットがあるのではないかと考察されています。DynamoDBなどにも対応して欲しい機能です。

但し、本書では依然としてRDBMSがデータベースの第一選択肢に止まり続けるだろうと述べています。私としても、本書を読んだ限りでは、NoSQLの利用は一部の大規模システムなどに止まるのではないかという印象を受けました。より広く使われるには、NoSQLソフトウェアやそれを取り巻く環境がもっと成熟してくることが必要ですね。

本書は列指向データベースのようなOLAP用のデータベースには触れられていなかったのが残念です。私の読解力では、本書で触れられているColumn-Family Storeというものが、Key-Value Databaseとどのように異なるのか全く理解ができませんでした。

NoSQL、CAP定理、BASE、Eventual Consistencyについて深く考えてみた

最近はNoSQLなどといって分散データベースがやたらに流行です。私もDynamoDBを使ってみようと思って色々調べているところですが、学べば学ぶほど奥が深くて恐ろしくなってきます。

まず第一に言っておきますが、現在のところ、いわゆるKey-value store型のNoSQLのメリットは「書き込みのスケーラビリティ」であって、それ以外には大きなメリットはありません。

DynamoDBの場合は「管理不要」「高信頼性」というおまけが付きますので、また話は少し別ですけどね。

他のオープンソース製品を自分のサーバーにインストールするのであれば、RDBMSほどこなれていないNoSQLを運用するのは大変な苦痛と危険が伴うでしょうね。前の記事にも書いたように分散システムを運用するというのは困難かつ苦痛を伴う仕事ですから。

ですから、すさまじい数のアクセスがあるようなシステムでなければ、NoSQLを選択する意味はないでしょう。

データベースに関しては、高いサーバーを買ってなんとかなるなら、高いサーバーを買ってPostgreSQLでも動かしているほうがトータルではずっと安くあがると思いますよ。Xeonを80コア積んだHP DL980にFusion-IOを突っ込んでも1500万円あればおつりが来る時代ですからね。


さて、ここから先はだいぶ込み入った技術の話をします。私も専門家ではなく、Amazon Dynamo[1]の論文を読んだ程度で話をしています。間違っているところがあればご容赦を。

最近喧伝されているBrewerのCAP定理[2]という理論がありますが、一貫性(Consistency)、可用性(Availability)、ネットワーク分断耐性(Partition tolerance)の3つのうち2つまでしか同時に得ることができないという話です。

このPartition toleranceを誤って「分散」と捉えて、「クラウドでは分散は必須なのだから一貫性か可用性のどちらかを犠牲にするしかない」と言っている人たちがいます[3][4]。これは大きな間違いです。分断耐性とは、ネットワークが分断した場合にも動作できるかどうかという話であり、現実にネットワーク分断など滅多に発生しない以上、一貫性も可用性も問題なく確保できます。

ネットワークが分断した場合でもアクセスできるという特性は、DNSやCDNや巨大P2Pネットワークなどには必要な特性かもしれませんが、通常のシステムには不要と言えます。また、これはキャッシュやデータ伝搬の仕組みを使えばアプリケーション側で実装できます。従って、この定理は分散データベースとは何の関係もありません。

BASEはここでACIDと対比されていますが、このBASEもどちらかといえば、データベースのスケーラビリティの話というよりはキャッシュなどアプリケーションよりの話に思います。

この古い学会発表をもとに現代のNoSQLを語るのは、はっきり言って無意味ですし、有害だと思いますね。


NoSQLがしばしばconsistencyを犠牲にするのは決してCAP定理のためではなく、スケーラビリティを確保するためであると考えて良いでしょう。

DynamoDBではconsistent readをサポートしていますが、その場合、(Dynamoと同じquorumによる実装なら)特定の条件下では無限のスケーラビリティが失われるはずです。

Dynamoは、ハッシュキーによってデータを格納するノードを変えていますが、このとき同じハッシュキーに読み書きが集中したとしても、consistencyを犠牲にすれば、ノード数に比例した性能を得ることができます。なぜなら、その場合は同じハッシュキーのデータを格納するNノードのうち1ノードだけに書いたり読んだりすれば良いからです。

また、読み書きのどちらか一方がヘビーな場合にはconsistentでもスケールすることができます。書き込みヘビーなら、書き込みは1ノードに行い、読み込みは全ノードに行えば、読み込みがスケールしない代わりにconsistentです。読み込みヘビーならその逆ですね。

それに対して、consistentに読み書きの双方を行う場合には、最低でもNノードの過半数にたいして書き込みと読み込みを行わねばならず、ノード数に比例したスケーラビリティが得られないことになります。

そこでeventual consistencyという話がでてくるのであり、CAP定理とは何の関係もない話なのです。ハッシュキーが十分に分散していればconsistentでもスケーラブルで可用性ある分散データベースが作れるはずです。


しかしこのように一つの値についてconsistencyが確保されたとしても、残念ながらACIDが実現されるわけではありません。なぜならCAP定理やDynamoDBの言うconsistencyというのは、ACIDのconsistencyとはレベルが違うからです。前者は、最後に完了した書き込みのデータが常に読み出されるというだけの話です。後者では、複数のレコードやテーブルやインデックスにまたがる一貫性が必要です。

(ここから先は適当な推測で書いてます)

ACIDを実装するためには、基本的には、トランザクションマネージャが全てのトランザクションを受け付けて、順番を管理して、順番が入れ子になった書き込みなどが起きないように管理する必要があります。これはスケーラビリティを大きく損なう事態です。ですので、NoSQLではACIDを実装することは本質的価値を損なってしまうのです。

一貫性のある書き込みができなければ、データベース全体として不整合な状態が生まれてしまうこともあります。インデックスを管理するためにもatomicな書き込みが不可欠です。

NoSQLでSQLがサポートされないのは、実装の複雑さもさることながら、整合性のあるクエリを行うためにはスケーラビリティが犠牲になることが理由の一つかもしれませんね。

(適当な推測おわり)

システムのうち、80%くらいの動作は不整合性を許容できるかもしれませんが、残りの20%ではどうしても整合性が必要です。そのときにはアプリケーション側で排他制御や整合性の管理を行う必要がでてきます。それではアプリケーションの開発効率を著しく下げてしまいます。

それが、NoSQLは特別にアクセスの多い場合だけ有効であり、普通のシステムで使うことはあり得ないという理由です。


ということで私はNoSQL全般には懐疑的なのですが、Amazon DynamoDBのように管理負担を軽減してくれるものであれば、もう少し広い利用価値があるような気がします。

実用になるプログラムを書こうとすると、どうしてもデータベースを扱う必要性がでてきますが、RDBMSを使うのは初心者や趣味プログラマ等には重荷であり、小さなプログラムを書くモチベーションを下げています。

DynamoDBを使うことで、もうちょい簡単にシステムが作れるようにならないかな、と思って少しアイデアを温めています。

NoSQL Distilledという新刊や、牛の本などの名著を読みながら、もっと勉強していこうと思います。

[1] Dynamo: Amazon’s Highly Available Key-value Store, Giuseppe DeCandia, et al.
[2] Towards Robust Distributed Systems, Eric A. Brewer
[3] Cloudの技術的特徴について --- ScalabilityとAvailability ---, 丸山不二夫 
[4] 結果整合性（Eventual Consistency）についての分かりやすいプレゼン資料 － Publickey