今年読んでよかった本の振り返り

今年読んで印象に強く残った本を振り返ってみよう。

懐かしい本をKindleで買い直すシリーズ

通勤で毎日40分ほど電車に乗るのだけど、だいたいTwitterしてるかKindleで本を読んでいる。

一時期ふと思い立って、懐かしい本をKindleで買い直して通勤時間に読む、というのをやっていて、これがなかなかよかった。

深夜特急1―香港・マカオ―（新潮文庫）

銀河ヒッチハイク・ガイド (河出文庫)

僕に踏まれた町と僕が踏まれた町 (集英社文庫)

そういえばこんなエントリも書いていたな。

daiksy.hatenablog.jp

完結したマンガを一気読みするシリーズ

blog.goo.ne.jp

このエントリを読んで、NARUTOが読みたくなったので全巻買って一気読みした。

ジャンプ連載時は、中忍試験くらいまでは覚えているけど、それ以降だんたんフェードアウトして読まなくなってた。

改めて読んで、なんで過去の自分が途中離脱したのか謎なくらいめちゃくちゃおもしろかった。なんか、「ちゃんとした少年漫画の主人公」に久しぶりに会えた、という気持ちのよさがあった。

[まとめ買い] NARUTO―ナルト― モノクロ版 (1-25)

ちなみになぜか今はアイシールド２１を読んでる。アメフト最高。

[まとめ買い] アイシールド21 (1-25)

シャーマンキング読みたいけど完全版がKindle化されてなくて読めないでいる。今更ジャンプコミックス版読んでも未完なのわかってるからな。。。

技術書的なあれこれ

Scala関数型デザイン&プログラミング―Scalazコントリビューターによる関数型徹底ガイド

今年はこの本がやっぱりよかったな。発売日前から楽しみな技術書って、久しぶりだった。読んでも楽しかった。

くわしくはこちらのエントリをどうぞ。

daiksy.hatenablog.jp

あとは身の回りでホットだったのは、実践DDDとか。

実践ドメイン駆動設計 (Object Oriented SELECTION)

daiksy.hatenablog.jp

1回読んだだけだとちょっと理解がしきれないので、2周目読むぞ、と思ってまだ読んでないので反省。

暗号技術入門 第3版 秘密の国のアリス

暗号技術入門は、めちゃくちゃわかり易い良い本だった。

daiksy.hatenablog.jp

大規模サービス技術入門は、自分の会社のインフラの様子を書籍で読む、という不思議な体験だった。

[Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ)

ちなみに今はScalaパズルの発売を楽しみに待ってる。

Scalaパズル 36の罠から学ぶベストプラクティス

ScalaMatsuriで竹添さんにサインを貰おう。

takezoe.hatenablog.com

その他

仕事で毎週、担当プロダクトの告知ブログを書いていて、同じテーマで毎週文章を書き続けるというのはとても大変なことだということを感じた。そんな中、この本が大きな手助けになった。

新しい文章力の教室　苦手を得意に変えるナタリー式トレーニング (できるビジネスシリーズ)

よく、ブログとか原稿とかを書いていて、「文章の神様が降りてこないから書けない」みたいな気持ちになるのだけれど、そんないつ降りてくるかもわからない謎の神の降臨に頼らなくても文章が書けるテクニックについて書かれていて、どんなに気が向かなくてもそれなりの文章を書ける、というワザを身につけられた。

他にもいろいろ読んだ気がするけど、Amazonの注文履歴に載ってない（書店で購入した）本は本当に今年読んだ本なのか自信がないので、来年は本を買う度にカレンダーに印でもつけようかな。

ちなみにこのエントリを書くためにAmazonの履歴を遡ったら、2015年の最初に買った本はこれだった。しかも1月1日に買ってる。

To LOVEる―とらぶる―ダークネス モノクロ版 1 (ジャンプコミックスDIGITAL)

正気か。。。。

2015年の社外活動を振り返る

さて。2015年もあとわずか。1年を振り返ろう。

コミュニティ活動

今年もいろいろなイベントに登壇したり、イベント自体の企画に参加したりできた。

daiksy.hatenablog.jp

daiksy.hatenablog.jp

daiksy.hatenablog.jp

daiksy.hatenablog.jp

daiksy.hatenablog.jp

来年のScalaMatsuri 2016 のスタッフ活動もやっていて、ぼくはPRチームとしてニュースリリースの配信やブログ記事を書いたりした。

blog.scalamatsuri.org

その他のアウトプット

専門学校で講演

2月に専門学校で講演をした。今年の対外活動でもっとも良い経験になった。

daiksy.hatenablog.jp

冊子への寄稿

アジャイルジャパンの企画で制作された冊子に寄稿。 電子書籍の執筆経験はあるが、自分の文章が紙の本になったのは初めてな気がする？

shop.manaslink.com

2015年のまとめと来年の抱負

去年の11月に転職して、今年は新しい会社で1年を過ごした。 新しい仕事や環境で、戸惑うことや難しい局面も多かったけれど、この1年で自分の立ち位置やこれからのことを深く考えることのできた、とても良い1年だった。

今年は環境の変化もあって、いろいろ恐る恐る進んだ年だったが、来年はちょっとアクセルを踏み込んで勢いよくいろいろなことにチャレンジしたい。

さだまさしの曲のYoutube再生回数を可視化してみる

Scala勢がさだまさしでにわかに盛り上がっている。

qiita.com

なるほどさだまさし。

世の中的にさだまさしの曲が、毎日どのくらい聴かれているのか気になったので、Youtubeの再生回数をMackerelで可視化してみよう。

Youtube APIで再生回数を取得する

Youtube APIを利用するには、まずGoogle Developer ConsoleでAPIキーを発行しよう。

Developer Consoleでプロジェクトを作成し、"YouTube Data API v3" を有効化する。するとYouTubeからデータを取得するためのAPIキーを発行できるようになる。

APIキーには、ブラウザ用やサーバー用などいくつかの種類がある。これは、リファラーやIPアドレスによってAPIアクセスを制限するための使い分けで、ぼくはサーバー用を選択して自分が利用しているEC2インスタンスのIPアドレスを通した。

APIキーさえ取得できれば、動画の再生回数は以下のURLから取得できる。

https://www.googleapis.com/youtube/v3/videos?part=statistics&id={動画のID}&fields=items%2Fstatistics&key={APIキー}

たとえば、この記事を書いている今、『関白宣言』の情報を取得すると以下の様な結果がかえる。

$ curl -X GET 'https://www.googleapis.com/youtube/v3/videos?part=statistics&id=tsXkp9FVzgg&fields=items%2Fstatistics&key={APIキー}'
{
 "items": [
  {
   "statistics": {
    "viewCount": "786716",
    "likeCount": "1436",
    "dislikeCount": "105",
    "favoriteCount": "0",
    "commentCount": "121"
   }
  }
 ]
}

このviewCountが再生回数だ。これをMackerelにポストしよう。

Mackerelのサービスメトリックへのポスト

Mackerelにはサービスメトリックという機能があって、これはホストに依存しない任意の値をポストしてグラフ化できる機能だ。

Mackerelの画面からサービスを作成すると、以下のAPIを使ってそこにメトリックをポストできる。

http://help-ja.mackerel.io/entry/spec/api/v0#service-metric-value-post

さて、YoutubeのAPIから取得したviewCountをMackerelにポストしてみよう。雑にコードを書いてみた。

post_uri = URI.parse('https://mackerel.io/api/v0/services/masashi/tsdb')
https = Net::HTTP.new(post_uri.host, post_uri.port)

https.use_ssl = true
req = Net::HTTP::Post.new(post_uri.request_uri)

req["Content-Type"] = "application/json"
req["X-Api-Key"] = "{api_key}"
payload = [{
  "name" => "masashi.kanpaku",
  "time" => Time.now.to_i,
  "value" => view_count.to_i
}].to_json

req.body = payload

res = https.request(req)

こんな感じでMackerelにポストするスクリプトを作り、毎分動かしてみよう。10分くらい待つとグラフが描画されはじめる。

グラフが平坦すぎる！！！！

とはいえずっとメトリックをとっていると、1時間で50回ずつくらい再生回数が伸びているのがわかった。 意外と再生されてる。

Mackerelにはグラフを1分ごとの差分値で表示する設定がある。

この設定に切り替えてグラフをみてみると、、、

なるほど。けっこう定期的に再生回数が伸びてる。

diffを取りつづけることで生き残っていくということ

この記事はDevLOVE Advent Calendar 2015 の20日目の記事です。

www.adventar.org

今年のテーマはdiff。

エンジニアとして生きている中で、ぼくが感じる大きなdiffがある。

スマートフォンの存在だ。

今でこそ当たり前に存在し、スマートフォンエンジニアは身の回りにもたくさんいる。しかしぼくが新卒でこの業界に入ったとき、このような端末はまだ影も形も存在していなかった。

2001年に大学を卒業し、あれから14年。ITの世界ではとても大きなパラダイム・シフトがあったということだ。

仮に65歳で定年するとして、それまでぼくの現役人生はまだ20年以上ある。と、いうことは人生の中であと1回か2回は、このようなパラダイム・シフトが起こりえるということだ。そのときぼくは何をしているだろう。 10年後の、まだ想像すらできない世界で生き残るために、なにが必要だろう？

必ずしも過去の経験が未来に当てはまるとは限らない。「わしが若い頃はこうやって生き延びたものじゃ」なんていう言葉は完全に老害っぽい。しかし未来が不確かである以上、過去から学べることはあるはずだ。

今までの10年くらいを振り返ると、本当にいろいろなことがあった。で、これまでなんとなく順調に生きてこれたのは、身の回りのさまざま事柄のdiffをとりつづけた結果なのかな、と思う。

• 凄腕のエンジニアと自分とのdiff
• 憧れの業界と自分の仕事とのdiff
• 過去の良い経験と悪い経験とのdiff

こういった様々なdiffをとって、その差分をよい方向に縮めるには何をすればいいか、そういうことを考え続けてきた結果なのかな、と思う。

さて、ここで問題になることが1つある。diffをとる相手先を的確に選ばないといけないという問題。 下手をすると、diffをとった結果、自分が圧倒的にイケてる、と勘違いしてしまったり、逆に自分には価値など無いと卑屈になりすぎてしまったりする。そうではなくて、「自分はまだまだダメだ」と心が折れないレベルの相手とdiffをとろう。そうでないと現状にあぐらをかいてしまったり、逆に圧倒的な力の差に絶望してくじけてしまったりする。

職場の身近な先輩。コミュニティで仲の良い優秀な人。そういう「身近にいるちょっと自分よりすごい人や物事」との差分を埋め続けていくと、気づいたらずいぶん遠くまできていたなぁ、というくらいのペース配分でdiffをとりつづけよう。

今年行ったライブを振り返る

今週のお題「今年見に行ってよかったもの」

毎年年末になるといろいろ1年を振り返るエントリを書いてるので、今年も書く。 2015年ふりかえり、第1弾は、はてなブログのお題ともからめつつ「今年行ったライブ」。

去年はこんな感じだった。

daiksy.hatenablog.jp

1月18日 World Order (オリックス劇場)

今年を最後に、須藤元気がパフォーマンスから抜けるらしくて寂しい。

WORLD ORDER　”THE NEXT PHASE”

2月15日 ストレイテナー (KYOTO MUSE)

ストレイテナー - 俳優 千葉雄大出演「DAY TO DAY」ミュージックビデオ（フルバージョン）

新曲のDAY TO DAYが良すぎるので絶対来年も行きたい

5月16日 ゲスの極み乙女 (大阪城野外音楽堂)

アンコールでキラーボール2回演奏してくれて最高だった

www.youtube.com

5月23日 岡村靖幸 (Zepp Namba)

ずっと生で聴きたいと思ってた"あのロン"聴いた瞬間、イントロで泣いた。

www.youtube.com

7月4日 京都大作戦

2日チケット買って、数年ぶりの参戦。雨に打たれて風邪をひいて翌日不参加という悲しみ。

でもここでtricot観てドハマリしたのでした。

tricot『99.974℃』MV

8月14 〜 16日 ライジングサンロックフェスティバル

とにかく最高のフェス。毎年行きたい。

daiksy.hatenablog.jp

8月29日, 30日 RUSH BALL

今年のメンツは俺得すぎた。今年唯一のHIATUSチャンスだった。

the HIATUS - Horse Riding 【日本語字幕入り】（Music Video）

10月1日 toe (KYOTO MUSE)

今年のベストライブは絶対これ！！！

ライブ後の数日間、余韻がすごすぎてtoe以外の音楽聴けなかった。

TOE LIVE AT THE REGENT: Goodbye

10月27日 the band apart (大阪 Music Club JANUS)

昔の曲がメインのセトリがやばかった。

the band apart / TENNIS CLUB e.p.視聴用

12月3日 MONOEYES (Zepp Numba)

アンコールツアーでようやくチケットゲット。

今年もなんやかんやでHIATUSと両方観れてよかった...。

www.youtube.com

レディクレ落選...

4年くらい毎年行ってたRADIO CRAZYは今年とうとう落選。。。。行きたかった。。。。。

はてなにおけるリモートワークあれこれ

こんにちは。このエントリは、はてなデベロッパーアドベントカレンダー2015の11日目です。

developer.hatenastaff.com

昨日は id:tarao によるこちらのエントリでした。

developer.hatenastaff.com

はてなでは、東京と京都にそれぞれオフィスがあります。また、宮城と愛知のそれぞれの自宅からリモート勤務をしているスタッフもいます。 今まで何度かはてなにおけるリモートワークについて書かれたブログエントリがありましたが、今日はその最新版をお届けしようと思います。

全社的なリモートの仕組みについて

まずは、全社的な仕組みについて。

はてなでは、ポリコムのテレビ会議システムが導入されています。

ポリコムは東京と京都のそれぞれの会議室やセミナールームなどに設置されていて、拠点間の会議はこれを使って行われます。 また、はてなでは始業時に全員参加の朝会があり、全体周知や前日のリリース情報の共有、当番制の3分スピーチなどをして1日の仕事を始めます。

朝会は東京と京都のセミナールーム同士をポリコムで繋ぎますが、ここで問題となるのは自宅でリモート勤務をしているスタッフについてです。

はてなでは、朝会だけでなく毎週木曜日の技術勉強会など、拠点間のセミナールームを繋いで開催される多人数のミーティングがいくつかあります。

そこで、最近になって自宅からのリモートスタッフもこうした全社的なテレビ会議に参加できるよう、新しいサービスが導入されました。

BlueJeansというテレビ会議サービスです。 bluejeans.com

BlueJeansの大きな特徴は、ポリコムのシステムとPCとが接続できるというところにあります。

これにより、東京と京都のセミナールームからはポリコム、自宅環境からはPCをBlueJeansで接続することで、全員が1つのテレビ会議に参加することができます。

また、朝会のような全体イベントだけでなく、通常の会議でも会議室のポリコムと、リモート勤務スタッフのPCをBlueJeansで接続して利用できます。

BlueJeansの導入により、自宅でのリモート勤務がぐっと楽になった印象があります。

開発チームのリモートワークについて

次に、開発チームにおけるリモートワークについてご紹介します。

ぼくが所属するMackerelチームを例にしましょう。

Mackerel開発チームは、東京オフィス、京都オフィス、愛知からの自宅勤務スタッフの3拠点にまたがってチームメンバーが分散しています。

日常的なコミュニケーションは、主にSlackやGithubのIssueなどを用いて行われます。 Mackerelチームのコミュニケーションについては、ディレクターの id:Songmu によるこちらのエントリが詳しいです。

developer.hatenastaff.com

基本的にはチャットでのコミュニケーションがメインとなりますが、チーム朝会だけは全員顔を合わせて行われます。

チーム朝会はZoomというサービスを使って行われます。

zoom.us

朝会でZoomを使う理由は、自分の端末上でZoomを実行し、かならずチームメンバー全員がそれぞれ自分の端末でテレビ会議システムにログインするようにするためです。こうすることで、自宅からの参加者とオフィス勤務のメンバーとで、環境を揃えることができ、オフィス出勤者同士でワイワイしてるのを自宅から眺める、といった変な距離感が発生しないようにしています。

リモートワークをするにあたって、環境を揃える、というのはとても大切なことだと思います。特にオフィス勤務者は、なかなか自宅からのリモート勤務がどういったものかピンとこないものです。以前は「チームメンバー全員が自宅でリモートする日」などを設けて、自宅からのリモート勤務の雰囲気を全員で共有する、といった取り組みなどもやっていました。

こういったことを注意しておかないと、オフィス勤務者同士の口頭での決定事項が共有されず、他のリモートメンバーが置き去りになってしまう、といった問題が起きてしまいます。

一方で、スプリントの振り返りや、計画会議など多少込み入った議論が必要な場合は、自宅勤務スタッフもその日だけオフィスに出勤してもらい、なるべく同じ場所で議論するようにしています。やはりリモート越しに仕様についての深い議論をなどをするのは難しい、という印象があります。

Mackerel開発チームとは別のチームの話になりますが、リモートワークでは兼務が難しい、ということもあるようです。複数のチームの仕事を兼務していると、いわゆる割り込み作業が多く発生します。リモートワークの場合、こういった割り込み作業のコントロールが少し難しいようです。例えばオフィスで仕事をしていれば、割り込み作業に対して、それぞれの依頼者に声をかけて気軽に調整することが可能ですが、リモートワークだとそういった「それぞれの依頼者に声をかける」という作業が少し大げさになってしまいます（テレビ会議をセッティングしたり、グループチャットを立ちあげたり）。なのでリモートワークで兼務をする場合は、曜日によってどの仕事をするか明確化する、などの工夫をしているようです。

リモートワークでのコミュニケーションについて

ネットワーク環境が整備され、リモートワークは以前と比べて格段に楽になりました。 ソフトウェア開発において、GithubにIssueをたて、コードを書いてpushしてCIの結果を待ってプルリクエストを送る、といった日常の作業では、ネットさえ繋がっていれば場所の制約はまったくありません。こういったことから、開発の仕事はロケーションなど気にせずにどこでもできそうな気がします。

たしかに、コードを書くことは場所を問わずにどこでもできます。しかし、チーム開発となると少し事情は変わります。 いくらチャットや最新のテレビ会議システムを使おうとも、メンバー全員が同じオフィスで仕事をすることと、リモート越しに仕事をすることはまったくの別物です。

コミュニケーションでメンバー同士が意思疎通するためには、様々な情報が必要です。会話の際の声のトーンや表情、日常の所作。そういったところから、我々は非常に多くの情報を読み取りながら他者とコミュニケーションをとります。リモートワークにおけるコミュニケーションでは、こういった「言葉以外の情報」の多くが欠けてしまうことに注意する必要があります。

Slackで日常的にチャットをする場合、我々は絵文字を多用します。これは、言葉だけでは伝わらない自分の感情をチャット上で補完するためのテクニックです。たとえば、レビューなどで少し込み入った議論をする場合、どうしてもきつい文体になってしまうので、その場合「自分は別に機嫌が悪いわけではない」ということをチャット越しに伝える（感嘆符をつけたり、「〇〇ですー」と語尾を伸ばしてみたり）といった具合です。

チームで仕事をするには、それぞれの人となりを知ることも大切な要素なので、リモートワークがベースのチームであっても、定期的に顔をあわせる機会を作ってメンバー間の相互理解を深める必要性があるのではないかと思っています。

おわりに

リモートワークは、いろいろと難しい部分もありつつも働き方の多様性を拡げる大切な取り組みです。 とりわけリモートワークだけが難しいわけではなく、チームで仕事をするには様々な問題と対処する必要があります。リモートワークの工夫とはそういったチームで仕事をするための工夫の延長にすぎません。

はてなでは、多様な働き方を日々改善しながら開発に取り組めるメンバーを募集しています。

hatenacorp.jp

アドベントカレンダーの明日は id:dekokun です。お楽しみに！！

アリスとボブはパスワードつきzipをメールに添付したりしない - 暗号技術入門を読んだ -

パスワードつきzipの添付メールと鍵配送問題

ボブのもとに届けられたアリスからのメール。このメールにはzipファイルが添付されていて解凍にパスワードが必要だ。このパスワードは、添付ファイルの後、アリスから別のメールに記載されて送られてくる。この手順により、最初のメールをイブが盗聴したとしても、イブはパスワードを知らないので添付ファイルを解凍することはできない。

一見すると安全に情報をやりとりしているようにみえるこの形式は、実はまったく安全ではない。ファイルが添付されている最初のメールが盗聴できるのであれば、当然イブは次に送られるパスワードが記載されたメールも盗聴できるからだ。

zipに施されるパスワードの強度はとりあえず気にしないこととして、この情報のやりとりは暗号におけるとても重要な問題をないがしろにしている。それは鍵配送問題と呼ばれる。

暗号の中には、かなり早い段階で「絶対に解読不可能であることが数学的に証明されている暗号」が存在する。使い捨てパッド（ワンタイムパッド）と呼ばれる暗号である。ただし、この暗号を使って情報をやり取りするためには、送信者と受信者が同一の鍵を共有しなければならない。使い捨てパッドで暗号化した文章をボブに送ろうと思っているアリスは、暗号化された文章とともに、暗号化に用いた鍵を安全に（決してイブに盗まれることなく）ボブに届けなければならない。いかにして、安全に鍵を通信相手に届けるか。鍵配送問題は暗号技術における肝だ。パスワードつきzipのメールのやりとりは、この鍵配送問題がずさんすぎるために、秘密の通信としてはまったく意味をなしていない。パスワードが安全に相手に伝わるなら、そもそも暗号化などせずとも文章そのものが相手に安全に伝わるはずだ。

事前にミーティングの場などで、口頭によってパスワードを共有しておく、などの方法であれば若干安全にはなるが、今度はそのパスワードをいかに保存するか、という鍵管理の方法における問題もある。

暗号の歴史は鍵配送問題の歴史

数年前にサイモン・シンの『暗号解読』という本を読んだ。 とても良質なドキュメンタリーで、暗号作成者と暗号解読者の戦いの物語が、克明に描かれている。まるでスパイ小説を読んでいるような錯覚に陥るほど、その筆致は刺激的だ。また、この本は物語としておもしろいだけでなく、きちんとそれぞれの暗号の仕組みをわかりやすく解説してくれる。

暗号の歴史は、鍵配送問題をいかに解決するか、という歴史でもある。サイモン・シンの『暗号解読』で描かれる物語において、人類が獲得した「公開鍵暗号方式」のくだりは、ミステリー小説の解答編を読んでいるような痛快さがある。

この本で人類の壮絶な戦いの物語を読んだあとに、メールにパスワードを記載して送信しようという気持ちには絶対なれない。

暗号技術と、その周辺の人間たちのドラマは、それほどに鮮烈でおもしろい。

暗号解読〈上〉 (新潮文庫)

暗号解読 下巻 (新潮文庫 シ 37-3)

暗号技術入門 - 第3版 -

数学ガールの結城浩による『暗号技術入門 - 第3版 -』

以前から名著として知っていたが、版が新しくなったのをきっかけに読んでみた。 とても読みやすく、暗号技術の奥深さ、面白さがわかるよい本だった。

我々は、日常的に暗号技術を使って生活している。 Amazonでクレジットカードを使って買い物をしているときに、ブラウザに表示されているURLを見てみると、"https://"ではじまるURLが表示されている。 これは、SSL/TLSという暗号通信のプロトコルを使っている印だ。

なにげなくダウンロードして使っているスマートフォンアプリにも、デジタル証明書という暗号技術の一種が使われている。

ITエンジニアであれば、githubを利用する際に鍵ペアを作って、公開鍵を登録したりもしているだろう。

これらの技術は、詳細なアルゴリズムを知らなくても、ちょっとした手順やコマンドを知っていれば誰にでも使うことができる。

暗号技術は、「秘密の通信」を行うための技術である。秘密のやりとりをするための技術であるのだから、暗号化のアルゴリズムも秘密にした方が安全ではないか、と直感的には思ってしまう。ところがそれは間違いで、アルゴリズムが公開され、その強度が世界中の暗号学者によって検証されているオープンな方式の方がはるかに安全なのだ。秘密の通信を行うための技術が、実はオープンであるほうが安全、という一見すると直感に反するこの関係性が、暗号の難しさであり、面白さでもある。

これはとても重要なことで、『暗号技術入門』でも、オープンであることゆえの安全性が、繰り返し語られる。

暗号のアルゴリズムは難しい？

我々は日常的に"https" などで暗号通信を行っているけれど、それが本当に安全かどうかはどうやって判断しているのだろう。マイクロソフトやGoogleといった有名企業が実装しているブラウザだから、という理由で安心しているのだろうか。それも決して間違った判断ではないかもしれないが、どうせならアルゴリズムをきちんと知ったうえで、「自分が使っている暗号化方式は、こういう理屈だから安全」と納得したほうがよいのではないだろうか。

暗号技術は数学によって構築されているので、難しそうな印象がある。もちろん、暗号技術に用いられている数学的な要素をすべて理解するのはとても難しい。けれど、なぜその技術が安全なのか、という理屈を理解するのは、実はそれほど難しくない。というより、結城浩という人が、わかりやすく理屈を理解できるように丁寧に整理してくれている。『暗号技術入門』はそういう本だ。

結局は人間の問題

『暗号技術入門』は、「暗号学者の道具箱」として以下の6つの暗号ための道具を詳しく解説してくれる。

• 対称暗号
• 公開鍵暗号
• 一方向ハッシュ関数
• メッセージ認証コード
• デジタル署名
• 擬似乱数生成器

また、新しい版では、ビットコインの仕組みや、最近問題になったOpenSSLやSSL/TLSにおける脆弱性の解説など新しいトピックについても書かれている。

ぼくがこの本でとても良いな、と思ったのは、最後に「人間の不完全さ」に触れられていることだ。どんなに強力な暗号を施しても、それらを使うのは結局は人間である。情報を扱うのが人間である以上、「システム管理者になりすまして電話でパスワードを聞く」などの手段によって、いくらでも暗号を解読する手段は存在する。冒頭のパスワードつきzipの添付ファイルなどはまさにその典型で、zipファイルに充分な長さのパスワードを設定したところで、そのパスワードの運用によって安全性はいともあっさり崩壊してしまう。

この人間の不完全さこそが、暗号通信の難しさでもあり、暗号の歴史における物語の面白さでもある。

暗号技術入門 第3版 秘密の国のアリス