あーありがち

過去の日記 2019-05 2019-04 2019-03 2019-02 2019-01 2018-12 2018-11 2018-10 2018-09 2018-08 2018-07 2018-06 2018-05 2018-04 2018-03 2018-02 2018-01 2017-12 2017-08 2017-07 2017-06 2017-05 2017-04 2017-02 2017-01 2016-12 2016-10 2016-09 2016-08 2016-07 2016-06 2016-05 2016-03 2016-02 2016-01 2015-12 2015-10 2015-09 2015-04 2014-10 2014-07 2014-06 2014-05 2014-02 2014-01 2013-12 2013-10 2013-09 2013-08 2013-07 2013-06 2013-05 2013-04 2013-03 2013-02 2013-01 2012-12 2012-10 2012-09 2012-08 2012-07 2012-06 2012-05 2012-04 2012-03 2012-02 2012-01 2011-12 2011-11 2011-10 2011-09 2011-08 2011-07 2011-06 2011-05 2011-04 2011-03 2011-02 2011-01 2010-12 2010-11 2010-10 2010-09 2010-08 2010-07 2010-06 2010-05 2010-04 2010-03 2010-02 2010-01 2009-12 2009-11 2009-10 2009-09 2009-08 2009-07 2009-06 2009-05 2009-04 2009-03 2009-02 2009-01 2008-12 2008-11 2008-10 2008-09 2008-08 2008-07 2008-06 2008-05 2008-04 2008-03 2008-02 2008-01 2007-12 2007-11 2007-10 2007-09 2007-08 2007-07 2007-06 2007-05 2007-04 2007-03 2007-02 2007-01 2006-12 2006-11 2006-10 2006-09 2006-08 2006-07 2006-06 2006-05 2006-04 2006-03 2006-02 2006-01 2005-12 2005-11 2005-10 2005-09 2005-08 2005-07 2005-06 2005-05 2005-04 2005-03 2005-02 2005-01 2004-12 2004-11 2004-10 2004-09 2004-08 2004-07 2004-06 2004-05 2004-04 2004-03 2004-02 2004-01 2003-12 2003-11 2003-10 2003-09 2003-08 2003-07 2003-06 2003-05 2003-04 2003-03 2003-02 2003-01 2002-12 2002-11 2000-08

_ blog に限らず、書くこと交わすことの難しさかな

Blog論2005年バージョン(2)

この話は blog 全般に広げて解釈する場合と、サラリーマン技術者の blog に限定して考える場合であれこれ思いつくことが違うな。

自分はその中間くらいで、

1. 社会そのものの文化の違い
2. 書くトレーニング、議論のトレーニングの違い

の二つをよく感じる。

文化の違いは、今回の文脈で言えば「会社と個人の関係の違い」が大きいように思う。要するに「日本では会社にバレると面倒くさい」のである。個人と会社の関係が日本の方が密で、これが blog についてはマイナスに働きやすいのではないだろうか。

（技術情報がクローズドなのかどうかは、自分は都会のサラリーマン技術者ではないのでよく分からない。よってその点は無視。）

しかし個人的にはトレーニングの違いの方が大きいように思っている。これは書くスキルについてもそうだし、議論についてもそう。手っ取り早く言えば多くの日本人は「ロジカルに書くことと議論が苦手」ということである。

例えば今回の楳田さんとこのコメントは楳田さんじゃなくてもガッカリする。あれこそ脊髄反射ではないだろうか。たぶんああいう言葉が出るのは「自分がケチつけられたように感じたから」だと思う。だからつい過剰反応してしまったという感じではないか。この辺が「トレーニング不足」と表現する部分である。*1

「批判」を「非難」や「否定」と捉えてしまってはそこから生産的、建設的な議論に結びつけるのは難しい。しかしこれは感情的な性格か否かに関わらずトレーニングでほとんど解決できる問題である。特に face to face でない、文章による議論は自分で読み直しができるのだから。*2まずは夜中に書かない ;-) そこから始める。もちろんそれと対をなす、建設的な批判をするトレーニングも必要なんですが。

_ 酔っぱらった

昨日、酔っぱらって帰ったらうちの前に酔っぱらいが寝ていた。

同じマンションに住んでるのは知ってたので、肩を貸してうちを探して回った。

今朝お礼にお菓子もらった。

Amazon から『RailsによるアジャイルWebアプリケーション開発』が届いた。ぱらぱらと眺めた。

今日はだらだらと寝て過ごした。

平和ってすてき。

※ 結城さんの日常とのこのギャップはなんだろうとか悩んじゃいけない。

_ 身体に染み付いたテンポ

※ いやぁビックリした。13時間近く寝てしまった。相当にキテいた模様。

シャーロックホームズの DVD をのんびり見始めているんだけど、オープニングの音楽が妙に早いなぁと感じていた。自分が鼻歌で歌う曲と結構テンポが違う。

なんでかなぁ、おかしいなぁと思っていたら、自分の身体の中にあったものは NHK が放送していた日本語翻訳版のオープニングで、これは本家のものよりテンポが遅いのだ。細かく言うとディレクターや原作者のクレジットがカットされていて、全体的にオープニングの映像は短くなっており、これに合わせて曲をカットしてある。で、帳尻合わせのためにテンポをいじってあるというわけだ。（てゆうか日本語版は弦の数が減ってないかい。改めて聞くとえらい軽いぞ。）

あと日本語版は意外に本編もカットされている。これも尺が違うんだな。ホームズが壁にぶっ放した跡とか意外に（ファンにとっては）重要な描写が落ちている。セリフ回しも露口さんの吹き替えはとても合っていると思っていたけど、やはり本人の声の方がホームズの気性の荒さがよく出ているような気がする。露口さんの方が more gentle だ。

ま、なんてなことをのんびり考えることができて何よりな日曜だ。

_ 時間ができたのであれこれアップグレードとか

• Firefox 2
• Thunderbird 2

テーマは Bible にした。なかなかかっこいいぞ。

あと Windows の方で

• Adobe Reader 8
• OOo 2.1
• Gimp 2.2.14
• iTunes

とか大物を次々と。

CotEditor 0.9.2 をあれこれテスト

• MacOSX 10.3 対応で
• Cocoa でサクサク動いて
• 日本語の自動判別がタコでなくて
• プレインテキストに特化している

エディタって意外となくて、なんべんもなんべんも探して全然見つからなかったのに、見つかるときは結局有名人の blog からってのがなんだか情けないというか非常に負けた感があるんだけど、それはともかく。

いいところは上に挙げた以外にも

• 通常の文書用のエディタとしても文字数のカウント表示が便利
• OgreKit ってすごいなぁ
• スクリプトでの補助が簡単にできそう。あーこれはよい。elisp 書けないエセ Emacs 使い、クライアント管理もサーバ管理もやらされる田舎の何でも屋としてはこれは助かる。Perl とか Ruby で強化できるならこんなに嬉しいことはない。
  • 選択文字列がなかったら文書全体を渡すって書き方がないようなんだけど、もしかしてそういうのは AppleScript 経由で書けってことかしら。ブログでそのように返事をいただいたので頑張ってみるか。

惜しいのは

• 桁折り位置を数字で指定できないのは不便なのと、プレインテキストを相手にするエディタなのにデフォルトフォントが monospace じゃないのはどういうことだろうか。
  • あ、Monaco で補完されるフォントが Osaka っぽいな。うーん、M+IPA でうまく表示できればそれにするか。
• ルーラとかアンダーラインとか表示できると嬉しいな
• キャレットじゃなくてカーソルを表示してくれると嬉しいな

そんな感じ。コード書かない人たち向けの OSX 用のエディタでオススメってはっきり言ってなかったんだけど、これなら薦められると思った。（次点は mi。）スクリプトで編集支援を追加しやすいのもいい感じ。これは標準で様々なスクリプト言語が組み込まれている OSX ならではですな。Windows のエディタでこういうことやられてもたぶん喜ぶ人はあんまりいないだろう*1。

もう一つ残念な点。OgreKit って複数ファイルの検索に対応していない。最近エディタで複数のファイルにまたがって検索する、なぜか grep検索と呼ばれる機能は割とポピュラーなので残念。また、CotEditor 自身がフォルダをドロップして開くことができない。しかもフォルダをドロップして開こうとすると authopen というプロセスがプロセッサを食いつぶしてしまう。うーん、食いつぶしちゃうのは困るな。

_ フレッツ光プレミアムを約束した

NTTの代理店から工事費無料キャンペーンの案内*1がきてたんだけど、まぁ特に損はないかと思ってお願いした。電話の口約束しかない*2のが気持ち悪いが、いざとなったらゴネればいいと考えている。まぁゴネる予定はないけどね。

しかし

案内の際に光にするデメリットを説明しない

のはちょっと感心しないな。まぁこっちは知ってるからいちいち聞かないけどさ。最後の最後お願いしたあとには自発的に説明してくるわけで*3、ちょっとフェアじゃない感じ。

フレッツの良いところ悪いところは一応調べているけど、

さすがにどんな条件が絡んでも 数百kbps しか出ないってことはないだろう

と踏んでいる。うちの ADSL は遅いんだよ。この状態なら光にするのに悩む必要はないよね？

_ Evo標準のiWnnとOpenWnnとSimejiとSocialIME

• Android 端末では iWnn を搭載しているものが多い
  • iWnn でフリック対応している端末も多い
• Evo も iWnn を採用している
• Evo の iWnn はフリック対応していない（！）

ということで

• OpenWnn フリック対応
• OpenWnn PLUS
• Simeji

を入れた。

最終的に

• 四方向のカーソルキーを持つ Simeji

を採用した。Evo はすべてソフトキーでカーソルの移動に便利なトラックボールなどは搭載していない。

ところがどうもこの Simeji がおバカさんでとてもイライラする。具体的には連文節変換ができない。

自分には Android の先輩が何人かいるんだけど話を聞いていると

要するに辞書がバカ

ということらしい。現行バージョンの Simeji の変換エンジンは OpenWnn + SocialIME なんだけど、この OpenWnn 部分の辞書が弱いのではないかという結論に達した。iWnn では楽々変換できる日本語が OpenWnn 系のものでは軒並み変換できない。なるほど。

対策としては

どんどん SocialIME の候補を学習させる

ということになるらしい。SocialIME での変換結果も学習したものはローカルに保存されるので次回以降はネットに繋がなくても変換できるということのようだ。

ということは本当は普段から SocialIME を鍛えるべく PC(Mac) での変換も SocialIME を積極的に採用していった方がいいんだろうなと思いつつまだそこまでできていない。とりあえず遅いのを我慢して Evo からは積極的に SocialIME の候補を呼び出して学習させているところ。

_ UX Kanazawa Vol.2はガチ

※ 実際には 5/12(土) に書いてます。

• UX Kanazawa Vol.2 ― UX Kanazawa
• UX Kanazawa Vol.2 が終了しました。 ― UX Kanazawa

ガチだった。マジガチ無知。

久しぶりの開催の UX Kanazawa Vol.2. 前回は「こんな感じかなぁ？」とみんなでやってみた感じだったけど、

今回はガチ

でした。

終わってすぐ連休に入ってちょっといつもと違うモードに入ったためなかなか日記を起こせなかったことと、ポイントが多すぎて書いても結局トレースするだけ（というかそれすら難しい）になって、ちょっとこれどうなんだろうという感じになりそうで躊躇しているうちに時間が過ぎてしまった。

全体の構成

• 講義
  • Design の歴史、Human Centered Design と UX
• ワークショップ
  • HCD手法の中からオブザベーション(観察) -> 評価グリッド -> プレゼン

の2部構成。

オブザーバというとあぁ、と思う人がもしかしたら多いのかな。

全体の感想

時間足りなすぎ。開始を1時間早めてもまだ足りない感じだった。

そして濃密すぎ。これはね、いやすごいですよ。全力で参加しないとあっという間に置いていかれる。受け手思考だと完全に置いていかれます。UX Kanazawa ガチ。ガチ硬派。

実は個人的には認知科学の話やエスノグラフィの話は初めてじゃないのでまだ参加者の中では余裕あった方だと思うんだけど、もう10年以上前にかじった程度なので思い出す余裕もなかった。

で。

バックグラウンドや姿勢にもよるとは思うんだけど、懇親会から最後まで参加した人間として思うことは、これは

ぼくの知らない金沢が生まれるんじゃないか

という気がした。WDF や DA 方面には参加したことがないからそことの比較はできないんだけど、（前回からそうなんだけど）Web に噛んでない人もガンガンきてる。これがまず面白い。全体的には IT 関係の人が多いんだけど、懇親会で話すと全然分からない話がたくさん出てくる。

ここ 1年くらいは kanazawa.js への参加が最も多くて、エンジニア以外との接点増えたかなーなんて思ってたけど、おれの知らない世界のエンジニアまだまだいるよ！ もっと出てこいよ！

反省

あくまで自分の感じた反省であって、同じグループの他の人の反省とは違うかもしれないことをまず断っておきます。

• 観察から評価グリッドで順番に問題点、改善案のヒントに上がって行くはずなんだけど、それぞれの間にやや飛躍を感じた。

これやっぱ実に難しい。

まず問題点のもとになるものが観察の中にちゃんと入っていない感じがした。自分はオブザーバをやっていたので、つまりは観察力不足ということになるんだけど、自分の気づいていない問題点を観察対象者*1がそのまま書き出していたりして、ということはやはり本当はそのとき感じていたものを思考発話が出来ていないということだし、モデレータがそれをモデレーションできていなかったということだ。

オブザーバは手間は掛かるがまずは実直に作業すればタスクは遂行できる。しかしモデレータは違う。モデレータがオブザベーションの過程をちゃんと理解し、そのうえで観察対象者とある程度信頼関係を築いて、的確に観察対象者の行動をモデレーションしてあげる必要があるんじゃないか。

実はこれ本当に大変なのは観察対象者とモデレータだよなぁと思った。

• ペルソナについて最初に軽くジャブがあったんだけど、観察対象者とそこから導いたはずのペルソナが本当に合っていたのかなぁ？という疑問があった

• 最終的に考えたプロダクトの利用シーンがペルソナや観察から飛躍していた

最後はペルソナをベースに「予測」あるいは「マーケティング」の要素がたぶんに入ってしまった。つまり今回のオブザベーションワークショップでは扱っていない領域に踏み込みすぎてしまった。

やっている最中は「おぉこれは面白いぞ」と思いながら作っていたので満足していたんだけれど、改めて発表の段になった際に、観察、ペルソナ、ストーリーがどれも少しずつつ飛躍する感じになってしまった。

簡単に言うと「お題」優先で、その「お題」に対する意外で面白い「回答」を「考えて」しまっていた。これはオブザベーションワークショップの趣旨とは違うし、HCD ではないし、UX を考える根拠が不足している。

改めて今回のポイントと感想

合ってるかどうか分からないけど、今回の UX Kanazawa Vol.2 でやったことは「ユーザーからどうやってデザインを決定する根拠を集めて、何を導き出すか？」そのための流れを学んでいたはずだ。なのに、最後は根拠の足りない発表をしてしまった。

デザインの決定要素はとてもたくさんあって、現実の自分はデザイナじゃないんだけど、様々な要素によってデザインが流動してしまう現場を見ている。そこで自然と「先回り」や「バランス」を重視してしまうような思考ができてしまっているんだなぁということを感じた。

今回やったようなオブザベーションは思い入れの入るエンジニアやデザイナではなく、別な立場の人が実は得意なのかもしれない。観察は作り手も参加した方がよいが、実は作り手じゃない人が参加した方が話が脱線せずに粛々と進みそうな気がしないでもない。例えば開発に対して QA のような、そんなイメージ。もし自分の作ったものをユーザーがクソミソに言いながら使っていたら冷静な観察ができないかもしれないしね。

だから実はモノ作りに関わってはいるけど営業です、とかそういう人も入った方がいいんじゃないかな、これ。モノを生み出してユーザーに届けるのって大変だけど面白いねって、直接作り出していない人も感じられるんじゃないかなぁ。

なるほどな！

って思うもん。

もしかしたら次は読書会とかの方がいいのかね、これ。アンケートで課題図書を聞いてみたけど、超定番の本以外はやはりまだあまりこなれてきていないみたい。とは言え、あんまり適当にイメージを膨らませてもダメなのかなぁとか、ちょっと悶々としたりしながらとりあえず今日のところは飲んで寝ます。

ありがとう。またよろしく。

_ DB設計の3段階って必要なんだろうか

なんかぼんやり思ったので自分用にメモ。特に強い結論があるわけではない。

よくある

• 概念モデル
• 論理モデル
• 物理モデル

ってやつ。

物理モデルについては ActiveRecord + Rails-ERD などで作り方を逆転させることも可能。これに慣れると抽象的なモデリングってほんとに必要なのかなという気もするけど、それはたぶんプロダクトの特徴を熟知しているから可能なのであって、何をしようとしているのかさえ不明瞭な状態ではいきなりは無理。

概念モデル、論理モデルはコミュニケーションのためのものと割り切ればよいのかもしれない。

概念モデルはやりたいことに名前を付けて、必要そうなシステムを洗い出すためのもの。

論理モデルはその際に必要になるデータの制約に注目するためのもの。何と何が紐づいているので、とか、どういう変更がどのタイミングで入るのか、とか、絶対に欠落したらダメとか。

いずれもコミュニケーションのためなら母語で書かれてよい。ただ、論理モデルで考えてる制約の話は物理モデルから出てきている部分があって、やはりもやもやは残るんだけど、頭の中である程度の物理モデルが作れる人が論理モデルで会話できるようになる、ってイメージかなぁ。物理モデルの経験がある程度以上ないと論理モデルが挟まるのは単に面倒が増えるだけというか、逆に難しい感じがする。

物理設計はパフォーマンスまで考えるって話があるけど、正規化してる段階でパフォーマンス考えてますよね、とか、なんかもやもやを感じたもので。はい。

いや、はい。だから特に結論はないってば。

_ drawa.ioの使いどころを少し考える

draw.io – Online Diagramming

特徴

• 日本語も使える
• 開発者向きのドローツールとしてある程度利用可能なレベル（単に丸や四角や三角と文字が描けるレベルではない）
• Google Drive, Dropbox, GitHub (!) など様々なストレージを利用できる
• なんならローカルにも保存できる

カジュアルに使い始めるのに本当によさそう。

G Drive / Dropbox連携

当たり前だけど他のデータと同様、片付け場所に困る気がする。使い始めるのはよいけど、のちのち困るパターン。特にチームで共有するような場合。

逆に複数のチームに出入りするフリーランスのような立場だととりあえずこういう形ででも共有できると嬉しい気がする。

GitHub連携

branchには保存できないっぽいので、ドキュメント用のrepositoryがあった方がよいような感じがする。

GitHub ベースで議論する際に「設計図は G Drive」へ、と分断があると割とつらいんだけど、画像で export するとこの問題は回避できそう。保存形式は draw.io 独自の XML のようなものでもできるし、画像としての export もできる。ただまぁ、図だけ共有できてもダメなので、開発プロセスすべて GitHub に寄せてくれ、を実現することはたぶんできない。

とは言え、GitHub を中心に活動するエンジニアが自分たちのために図を残すには十分使えると思う。

参考

• draw.io で書いた画面設計書いてみたらストレスフリーになった 〜 続・gitbookで設計書を作成したら最高だった話 - フォトシンス エンジニアブログ
• gitbookで設計書を作成したら最高だった話 - フォトシンス エンジニアブログ
• Pegmatite

懸念

draw.io は今のところ confluence / JIRA connect 以外は無料で使えてしまう。サービスの永続性がどれくらい本気なのかよく分からない。とっとと課金させてほしい。

逆に無料ツールとして導入してしまうといずれ有料化した時にどうするのかを判断する必要がある。