『ユーザビリティエンジニアリング(第2版)―ユーザエクスペリエンスのための調査、設計、評価手法―』読んだ

ゼロから調査・分析，設計，評価を行う必要があったが，これまで経験がなかったため，非常に困っていた．

そんな僕に対して，この本を先輩から紹介してもらった．とてもいい本で感動しまくっていた．

この本に書かれているそれぞれのトピックについて，散文的な書籍やブログ記事はたくさんあるのだけれど，この本は，開発者に向けてブレなく開発を進めてもらうために書かれた本という点で，網羅的で実用的であり，その他のものとは異なる．

ユーザー中心設計(UCD)の基本的な考え方から，ユーザビリティ評価に参加する方への謝礼の額の目安まで書かれていて，ここに記載されていることをベースに，仕事を進めることができるため，手元においておいて損はないかなと思う．

ユーザビリティエンジニアリング(第2版)―ユーザエクスペリエンスのための調査、設計、評価手法―

『ネットを支えるオープンソース ソフトウェアの進化』読んだ

読んだ． 全体の感じとしては，以下に近いかもしれない．

『ソフトウェアの匠』読んだ - Somerset::Technology::Memo

Matzの話は，今までのエッセイを好んで読んでれば変わってない印象を受けるけど， 2014年最新の考えが読めるという点で良さがある．

インターネットを支えるソフトウェアの説明やプログラミングの話は， 情報系大学を出ているわけですから，軽く流せる． プログラミング初心者に向けてブックガイドで『はじめてのRuby』を挙げるのはいただけないけれど， 間違ったことは書いてないしノーコメント． ライセンスについては 知る、読む、使う！ オープンソースライセンス - 達人出版会 のほうがわかりやすいかもしれない．

プログラミングと教育については， 知らないことが結構書いてあったので新鮮だったし読み返したい． ハッカー精神については読みごたえがあったし， Mozillaの事例や企業とOSSについても，あまり知識がなくてもさっくりと読めてよかった．

ということで，図書館で借りたものだけど，書籍を購入しました．

角川インターネット講座２　ネットを支えるオープンソース　ソフトウェアの進化

角川インターネット講座 (2) ネットを支えるオープンソース ソフトウェアの進化

『失敗から学ぶユーザインタフェース』読んだ

毎日ちまちま読んでた．

ユーザインタフェースの本をよく見かける． この本は，世の中・街中にあふれる失敗したユーザインタフェース， ここでは"BADUI"という名前が付けられているけれど， そのBADUIの事例を紹介した本． とにかく券売機や水道の蛇口，トイレのマークなど，写真が沢山載っていて，みていて楽しい．

例えば「扉」だったり，「個人情報を書き込むシート」だったりの悪い例が載っているのだけれど， 自分には関係ないと思っても，意外とそういうものを作る機会はある． セブン-イレブンのコーヒーメーカーなんかは，テプラで修正されていることもあるけど， ものを作ることよりも，修正することのほうの多くなるかもしれない． その時，どうすれば良くなるかということを当然考えると思うのだけれど， 日々ユーザインタフェースに思いを巡らさないと， どうもうまく考えられないのではないかと最近は思っている． あるいは，「こうすると○○の理由で誤解を招くよね」と言えると良いかもしれない． 実現したい機能について，定石とも言えるものは当然多くあると思うのだけれど， 無意識に使ってるからいざ作ろうと思っても難しいし， こうやって失敗の例を知っておくことで歯止めになるかもしれないと思って読んでいたのだった．

作ってみてどうもうまくいかないときに，うまくいってないことに気づくことは最低限としても， なぜうまくいかないか気づかない・知らないと改善のしようがないと思う． 一番早いのは実際にたくさん作る・失敗をすることなんだろうけれど， 次点としてこの本を読んで， 出てきた各章のタイトル

1. 手がかり
2. フィードバック
3. 対応付け
4. グループ化
5. 慣習
6. 一貫性
7. 制約
8. メンテナンス
9. 人に厳しいBADUI

だったり， 「シグニファイア」「行為の7段階理論」「グループ化の法則」あたりを思い出せたら， まぁ悪くないUIが作れるのではないかな?と思う．

失敗から学ぶユーザインタフェース 世界はBADUI(バッド・ユーアイ)であふれている

鳩の巣原理

印象的な例

「ロンドンに髪の毛の本数が同じ人がいる」ということの論証に利用する．

たとえば「ロンドンには、同じ本数の髪の毛を持った少なくとも2人の人間が存在する」。証明してみよう。ふつう、髪の毛の本数は15万本ほどであるから、100万本以上の髪の毛を持っている人間はいないと考えることができる。ロンドンの人口は100万を超える。もし、髪の毛の本数ごとに鳩の巣を割り当て、巣にロンドンの人々を割り当てるなら、（当然の下限である0本から上限として置いた99万9999本までの巣に100万を超える人々を割り当てるのだから）少なくとも同じ髪の毛の本数を持った2人の人間が必ず存在する。

鳩の巣原理 - Wikipedia

しかし，髪の毛の本数が同じ人が何人いるのかとか，髪の毛の本数が同じ人のその本数は?とかの問には答えられない．

前述した「ロンドンには、同じ本数の髪の毛を持った少なくとも2人の人間が存在する」ということの証明の面白いところは、同じ本数の髪の毛の人が存在することを証明しているにもかかわらず、具体的にどの2人が同じ本数の髪の毛を持つのかは分からないということである。鳩の巣原理を使った証明にはこのような特徴をもつものが多く、何らかの性質を満たすものが存在することを証明するにもかかわらず、どれがその性質を満たすのかについては何も分からない。 もちろん100万人以上いるロンドン市民の髪の毛の本数を全員チェックすればどの２人が同じ本数の髪の毛を持つのか分かるが、このような非効率的なことをしなくても定理が証明できるのが鳩の巣原理の利点である。 (チェックが多項式時間でできないにもかかわらず、鳩の巣原理により存在性のみが言える例もある)。

鳩の巣原理 - Wikipedia

実用

ハッシュテーブルが必ず重複してしまうことの証明．

感想

鳩の巣のような格子状の物体を眺めていて思い出した．

半年間の間に確実に読んだ記事なのだが， 人に説明できるレベルまで詳細は思い出せなかったのが 悔しかった ので，記録しておく．

『ソフトウェアの匠』読んだ

2章のシステム開発編はところどころ読んだので，完読というわけではない． 今から10年前に発行された書籍であるため，それを差し引いて読まないと混乱する． 雑誌の一記事でもあったようで，散文的にかかれているものの，面白い記述がいくつかあったのでメモ．

プログラミング言語

Matzの書いた文章はいくつか読んでいるつもりだったけれど， 他の文章では書かれていない基本的なことが書かれていて，面白かった．

プログラミング言語の分類として，

1. コンパイラ型orインタプリタ型
2. 型の扱い
3. ベースとなる考え方（計算モデル）

の3つの視点を導入していた．

1.に関しては言わずもがな．2.に関しては「型なし」，「静的な型」，「動的な型」の三種類． 「型なし」は意識していなかったので，言われてみればそうかという感じになる． そして，やはり動的型付け言語を支持するのね，という感想． 3.については，「手続き型」，「オブジェクト指向型」，「関数型」，「論理型」を主要な例としてあげていた．あとの章では別の人が，「手続き型」と「構造型*1」を分けて記述していたのも興味深い．

そして，プログラミング言語の譜系についての記述． COBOLやFORTRANなどの，古い言語が当時も生き残っていることについての記述． Perlのスクリプト言語の形勢逆転について．

ニールセンのユーザビリティの5つの構成要素を， プログラミング言語に当てはめて考えてみるというのは，彼らしいなと思った． 最後にプログラミング言語の進化のスピードは遅いというのも興味深いが，心あたりがあるという感じ．

アスペクト指向について書かれていて，びっくりした．

オープンソース

この一年間でOSSについての歴史について，結構読んだつもりだったけれど Debianコミュニティからの記述は恥ずかしながらあたったことがなかったので， 一つのフックができた気がする．

• The Open Source Definition | Open Source Initiative
• オープンソースの定義 - Wikipedia

システム開発編

実は一番仕事に近い部分ではという気にもなっていたのだけれど， そもそもの知識がなさすぎて散文形式では読めなかった． 「オブジェクト論」と「デザイン・パターン論」そして，「システム・アーキテクチャ論」を流し読み． 「開発プロセス論」については，2014年の時代に則したものか，古くてもまともな一冊を読んだほうが良さそう．

検索技術論

結構，全文検索に寄った記述が多い文章を見かける事が多いけれど， これはライトに，「文字列検索」「情報検索」「検索インタフェース」について書かれている．

もともとこの本を読もうと思ったきっかけが，高林さんの記事を追ってみようと思ったからで， 実際はpre-printネットに書いてあるので，こっちを読んでも悪くなさそう． 高林哲の検索技術論

あと

キーボードの話と，特許の話は良かった． キーボード配列についての記述はよく見ていたけれど， 歴史的な側面から始まり，キーボードをハードウェアとして捉えているのが面白かった．

特許については，現状を考えると，はい．

ソフトウェアの匠

*1:ダイクストラの構造化プログラミングを指す

『インフラエンジニアの教科書』読んだ

学生時代は，用意されていたLinuxサーバが動いていて， 基本的にはスクリプト言語で書かれたコードを動かすというような生活をしていた． 会社に入るまでは，本格的な仮想化環境も，ファイバーチャネルで外部ストレージに結ばれているサーバを眺めたこともなかったように思う．

学部時代に少しばかり小規模Linuxサーバの構築をして， 研究室内に閉じたWebサーバを立てたこともあるが， 必要なものだったわけではないので，いつの間にか終息してしまった記憶がある． 研究室で運用されてたのがRHELだったため，その周辺には若干詳しくなったが......

ネットワークについては，基本的なハードウェアとサービスの役割を知ってるくらいで， 実際に構築運用したことはほとんどどなかった． また，依頼されて触ったとしても， 座学で学んだわけではなく場当たり的にWebを参照しながら行ったため， 知識が体系化されておらず，穴がある状態でしかも効率が悪いなどの問題があった．

この書籍をどこで知ったかはもはや覚えていないが， 新入社員としてインフラエンジニアの部署に配属された新人が知っておいてほしい内容を書いた，とのこと． 僕はインフラエンジニアではないのだけれど，サーバの調達やインフラも業務の一環としてふられることがあり， すべてがエンタープライズ向けとまでは行かないものの，無償・オープンソース以外のツールも使うことがあるため， 全体を俯瞰しておきたかったというのがある．

とても読みやすく，一歩を踏み出すために必要な知識がひと通り書かれているという印象． 現状の僕にとっては，手元に一冊あって良い本． 反面，これだけではどうにかなるかと言われるともちろん無理で， それぞれのソフトウェアやハードウェアの知識だったり， 経験がかなり重要になってくるのだろうなと思う．

この知識を使うときは，業務中なので，必要なアドバイスも部署の人からあるだろうが， 基礎知識として最低限の網羅ができていることで，自信を持って切り込むことができそうな気がする．

Hyper-VやVMWare vSphere，Xenなどの仮想化環境を利用することが多く， それぞれの差分やライセンスの仕組みなどは知らなかったため，調達時に役立つ気がする．

アプリケーションエンジニアにおいては， インフラ周りの話はしないに越したことはないという話はよく聞くけれど， 現状，その辺は全く知らないと仕事が回らなくなる危険性があるという事実もあるので， バランスが難しいなと思う． 学生時代に踏むべきポイントだったかもしれないけれど， 幸か不幸か踏まなくても良かった環境にいたので，ひと通り流して良かった．

技評の養成読本シリーズも気になっているが，こちらに比べるとより実際の業務，具体的な事例寄りだろうか． これが本業ではないので，あまり深追いはやめようと思うが，気にはなっている．

インフラエンジニアの教科書

『はじめてUNIXで仕事をする人が読む本』読んだ

学部の頃に「計算機科学入門」というような名前の講義があって， 座学でUnix*1の使い方を教えるというものがあった．

教員がTeXで組版した文書をコピーをまとめた本を教科書としており， 自力でC言語でプログラミングができるように， また，OSやネットワークの授業が理解できるようなものだったと思う． 残念ながらその教科書はどこかにいってしまって， 何を学習していたかということは忘れてしまっている． また，シラバスも参照できないため当時のことを思い出すことはできない．*2

この書籍は，情報系修士卒の社会人1年目は想定読者ではないだろうが， 目的として

• 再度の基礎固め(内心呆れられてると思ってる)
• 失ったポータルを再度作ること
• 主にUnixを業務で使う会社の新人社員の学習内容を知りたい
• 人に勧めるため

がある．

また，社内外問わず新卒の人と話していると， 結構な頻度で「えっ，これ知らないの」ということも起こるし， 加えて，新人がどういうふうに学習するのが良いのか， 鍛錬を詰むのが良いのかということにも興味を持っている． この本では大学の授業のように網羅性を持つことを理想としているので好感が持てた．

複数の大学の教員から「大学はプログラミングをすることを学ぶところじゃないよ」ということは耳にタコができるくらい聞いたし， しばしばそういう先生はUnixの話を軽視するのだけれど， 近年，研究で業績を出す人の多くは手が早いことも観測されていて， 開発の現場でも環境構築の素早さが開発効率に繋がることも観測される． 腕が立つこと，手の早さが車輪の片側になっているのではと思うこともある． 我々はアマチュアではないのだから，きちんとやる必要がある．

さて，本書の内容であるが，Unixの使い方一揃いという感じ． インストールの仕方などは別の書籍や情報源を利用すれば良さそう． ネットワークは他に比べるとあまり詳しくないので， 全体の分量にしては結構深堀りされてたのが良かった． 幾つかの箇所については知らないこともあり，恥ずかしい気持ちになる．

読み飛ばしたところは*3

• (C|Java)のプログラミング
• バージョン管理
• ソースコードからドキュメント作成(JavadocとかDoxygenとか)

一回通すことの大切さを最近は感じているのだけれど， 一回通したからというだけではすぐに忘れてしまうので， あの本には書いてあっただろうかと検索をかけたいと思う．

はじめてUNIXで仕事をする人が読む本 アスキー書籍

*1:学内環境はLinuxだったが

*2:学生時代に何を勉強したかということをきちんと保存しておくべきだったと後悔している．ぎりぎり製本されたシラバスも配られていたと記憶しているが，当時はWebで見ていた．

*3:時間や環境の関係．通勤時間に読んでいたので