このブログは2015年2月18日に更新を停止しました。すべての記事は https://chroju.github.io へ移行されています。
GitHub.ioとOctopressの組み合わせでブログを作成しました。
こちらのブログを消すことはしませんが、おいおい全部の記事をエクスポートしてgithub.ioに持っていくつもりです。はてなブログでもまぁ、不満はなかったんですけど、流行りのやり方に乗ってみようかなというのと、隅々までカスタマイズできるフォーマットが欲しいかなということでやってみました。
実際のところ、ブログの構成ファイルやエントリーをすべて手元に残しておける（それもMarkdownで）というのはどことなく安心感もあって良いものです。管理が行き届くという意味でも、Github.ioとOctopressによるブログ運営は良いんじゃないかなと。
そこそこにはてなブログ読者登録もしていただいていたみたいですが、よろしければ今後共よろしくお願いします。なお、ブログ名の「No intention」は大した意味がないですが、好きなボカロ曲から連想したりしてます。
![Software Design (ソフトウェア デザイン) 2015年 02月号 [雑誌]](http://ecx.images-amazon.com/images/I/51LB1O7gOIL._SL160_.jpg)
読んだ。身に覚えがありすぎるもので（震え声）
そもそもにして「運用でカバー」という言葉自体が思考停止しているというか、その実態は何で何が問題なのよ？というのをよくよく考えもせず「なんとなくまずそうだよね」状態で停まっている気がするのですが、そういうのをきちんと論理的に客観的に解きほぐして脱却していくってのは非常に重要なことだなと、この特集読んで思いました。たぶん、そういうこと他にもいっぱいある。
「運用でカバー」とはすなわち、「仕様外の依頼をなんとなくもやっと渡しても、運用現場の努力でなんかなんとなくやっちゃう」ってやつで、特集内ではその帰結として現場の高負荷、業務の属人化、費用対効果の不可視化といった問題が起きるとしている。これを続けていると正当な評価をしてもらえず、現場が疲弊して結局自分たちの価値を毀損してしまうのでやめた方がいいと。じゃあどうすりゃいいのかというと、いろいろ可視化しましょうよと。運用へ期待されていることの可視化により、やるべきことを明確化すること。運用業務自体を「サービスデリバリ」と捉えることによる、内容の可視化、ドキュメント化。それによる属人化や複雑化の排除。工数や納期も含めたQCDの可視化による客観的な運用成果の評価。そういうのをきちんとやっていこうという話。
実際自分の運用現場を振り返ってみて、これらの事柄をやっていないのかというと、実は結構やってるんですよね。運用業務に費やした工数はカウントして提示しているし、運用設計書を定めてもいる。ただ、確かに明示化がきちんと進められていない部分はあって。例えば運用業務の可視化においては、単なるドキュメントを作るだけではなくて、運用メンバーに求められる「スキルセット」も整備すべきだとあるんだけど、そこはやってないんですよね、弊社の場合。運用メンバー全員が一定のスキルセットを共有してはいないので、特定プロダクトの障害が起こると有識者だけが原因と対策を考え、責任もその人1人が被るような状態になってしまう。たぶん100%「運用でカバー」している現場は少なくて、カバーと言うぐらいだから可視化しきれなかった一部の例外をふちゃふちゃやってるんだと思う。でも、それが結構大きな傷口になってしまったり。
あと、お客さんの無茶ぶりというよりは、案外社内の方に敵がいることも少なくない。無茶ぶりに対して、サービスメニューと契約内容を元に本来は交渉をすべきなんだけど、そこを「仕方ないよね」といって引き受けてしまう風習とか。なぜ無茶ぶりを引き受けてしまうかというと、うちが引き受けなければ別の会社が引き受けてしまう、つまり機会損失になるから。「運用でカバー」が蔓延した結果、それをしないことが競争力の鈍化に繋がるような、ある種理不尽な現状が日本のSIer界隈にはあるような気がしている。そのへんはきちんと交渉して仕事を受けられるような、マネジメントとビジネススキルの世界の話なのかなぁと思うけど。
特に意識したいのは、運用は「サービスデリバリ」であるという視点ですかね。どうしてもシステムリリースが先行して、運用はそれに付随して発生する毎月の収益源みたいな見方をしてしまうのだけど、長期スパンで見れば金額的にも期間的にも運用、というかリリースしたシステムによるサービス提供が本番なわけであって。その「本番」で円滑に収益を上げるためにどうしようか？ってのが開発現場には求められるわけですな。ちなみに自分は運用に片足突っ込んだ開発メンバーなので、上手いこと橋渡しが出来たらいいなーと思います。
Exhibiの内部的な話を書こう書こうと思って忘れてた。とりあえずMechanizeについて。
Mechanizeはスクレイピングを楽にしてくれるRubygemsです。ExhibiではMechanizeを使ったスクレイピングのRakeタスクを作成し、それを日次で実行することで、各美術館のサイトから展覧会情報を抽出しています。抽出した情報がDB内に存在していれば無視。存在しないのならDBに追加。こういうクローリングに関しては、ちょうど時同じくしてRubyのクロール入門本が去年出たんですけど未読です。技術的な話のみならず、人様のサイトへ機械的にアクセスする際のお作法的なことも載っているらしく、いつかは読みたいところ。
Mechanizeは同じくスクレイピング用のGemであるnokogiriに依存しており、スクレイピング結果はNokogiriのオブジェクトとして扱われるみたいです。nokogiri使ったことないのでよくわかりませんが。例えばあるurlに対してgetリクエストをかけた際、そのレスポンスをpageインスタンスとして受け取った場合、この中身は単なるHTMLではなく、スクレイピング向きにアレンジされてます。page.linksでページ内のリンク一覧が取得できるし、page.search(XPath)でXPathを使った検索ができます。
まあだいたいスクレイピングでやることって、ページを取得してきて①その中のリンクをクリックする、②フォームを埋めて送信して次のページヘ進む、③ページ内の要素からデータを抽出する、というところだと思うので、これぐらい押さえておけばなんとかなります。ちなみにurl与えてページを持ってくるときはMechanizeのインスタンス（公式チュートリアル内ではagentという変数が振られてます）に対してagent.get(url)というメソッド使えば返ってきます。簡単ですね。
自分はXPathをよく使います。
page.search('//td[@class="hoge"]').text
タグでももちろんいけます。
page.search('h3')[0].text
こちらだと戻り値が配列になる点に注意。XPathだと対象を一意に特定できるけど、タグだと同一ページ内に複数存在する可能性があるからなんだと思います。他にもやり方あるかもしれませんが、自分はこれしか使ってないです。あと、タグ内のテキスト部分を取り出したい場合は上記のやり方ですが、タグの要素の値を取り出すこともできます。
page.search('img')[0]["src"]
こんな感じで画像のURLを抽出したいときなどに使います。
基本はaタグで挟まれたテキストの値か、href属性の値から特定してクリックします。
page.link_with(text: 'hoge').click page.link_with(href: '/fuga').click
これでリンク先のpageが返ります。が、クリックしたいのがテキストではない上に、href属性の値も特定できない場合もあります。Exhibiで必要な展覧会情報も基本的には個々の展覧会でパーマリンクが別なので、hrefから特定することはできないです。そういうときはXPathと上手いこと組み合わせます。
hrefs = page.search("//div[@class='hoge']/div/a/@href") links = Array.new hrefs.each do |href| links.push(page.link_with(href: href.text)) end links.each do |link| page = link.click ### なにか処理 ### end
またpage.linksですべてのリンクが呼び出せるので、イテレータで全リンクに対して何か処理したりってこともできます。
Exhibiではフォームの処理は使っていませんが、一応書き留め。pageに対してformメソッドを使うことで特定のフォームを取得し、値を埋めてsubmitできます。
f = page.form('LoginForm') f.name = "chroju" f.password = "password" page = f.submit
page#formの引数に与えているのは、取得したいformタグのname要素です。以下、inputタグのname要素がメソッドになっているので、ここに値を埋め込んでいき、最後に#submitメソッドを呼び出します。
基本的にやることはこれだけなんですけど、ものによっては単純なフォームの送信ではなく、送信ボタンをクリックした時にonClick要素でJavaScriptを呼び出して処理させていたりします。そういう場合は単純にsubmitしてもバリデーションが通らない可能性があるので、呼び出している関数の中身を解析して対処するしかないです。大抵はhidden要素に対して何かしら値をいれこむような処理をしていることが多いので、その内容さえわかれば、JavaScript内で行われている値の代入処理を手で書いてあげれば無事にsubmitできたりします。
あとリンクと同じように、フォームもpage.formsで全要素取得できます。
だいぶざっくりめに書いちゃいましたが、やっぱり公式ドキュメント読むのが一番いいとは思います。ここに書いている以外にもやれることはいろいろあるはずなので。
スクレイピング、API提供していないサイトであっても、すべてのネット上のデータを機械的に扱うことができるようになるので、結構夢が広がります。ただし、セマンティックウェブに則りきちんとしたHTMLを書いているサイトじゃないと上手いことコードが書けなかったりするので、ひとえに万能な魔法というわけではないのが悩ましかったりも。そういうときはウェブ上で簡単にスクレイピングが出来るらしいkimonoとか使うのもアリなのかもしれません。自分は使ったことはないですけど、kimonoの開発者が「セマンティックウェブは失敗した。ネット上のデータ構造化をウェブ製作者側ではなく、データの利用者側がやるべきだ」的なことを言っていて、これにはかなり共感を覚えたりしてます。
そういえばだけど手帳使うのをやめた。去年の10月ぐらい？ 2015年の手帳はどうしようかなと考えたときに「要らなくね？」って結論に達して以後使ってない。
そもそもここ数年は手帳を手帳としては使ってなくて。スケジュールは基本的にGoogle Calendarを使ってたし、タスク管理もtodo.txtで2年ぐらいは安定してたので、手帳の役割というと「日付のついたメモ帳」ぐらいの意味しかなかった。3年前と一昨年がほぼ日手帳、去年がEDIT。まぁこれはこれで良かったんだけど、別にメモにしか使わないなら単なるノートを持ち歩けばいい。それにEDITでもほぼ日手帳でも、当然ながら1日あたりの書けるスペースはすべて統一的に限定されている。でもメモの分量は日によって変わるから無駄が出る。あとEDITのスペースだとさすがにガリガリいろんなこと書き出して勉強したりって目的には使えなかったので、手帳とは別にA4サイズのノートも歩いていたのだが、よくよく考えたらこれも無駄だし。だったらもうメモ用途にもノート用途にも使えるの1冊持ってりゃそれでよくね？ということになった。
以後、使っているのはモレスキンラージサイズのEvernoteエディション。Evernoteエディションを買ってはいるが、実際にメモを撮影してEvernoteに取り込んだためしはこれまで1度か2度ぐらい。自分はいまいちEvernoteを使いこなしきれてないので、手書きメモをわざわざ取り込む意味が理解しきれていないという面がある。だからEvernoteエディションである必要はなかったといえばなかった。
ペンケースを持ち歩く習慣がなく、これまではEDITやほぼ日手帳のペン差しに多色ペンを挿していたのだけど、モレスキンにはペン差しがないので文具屋で見つけたベルトシールというものを使ってる。フェイクレザー？みたいなそれなりに硬めの材質で、結構良い。
あと書き物をしているとカレンダーが欲しくなるときがよくあるので、カスタムダイアリーステッカーというものも買った。スマホで見ればいいじゃねーかと思われるかもしれんが、まあ客先で打ち合わせ中にスマホ取り出してる時間が惜しかったりもするし、なんだかんだで紙のカレンダーって取り回しがよくて好きだ。
つわけで最近は以前より手書き環境充実した感じがあって良いのだけど、もうちょっとデジタルと上手いこと使い分けたりしたいなーという思いはある。日々のやることはルーチンと予定とタスクと余暇に分けられると考えていて、これを上手く回したいのだがあんまり上手くいってない。ルーチンは食事、睡眠から家事とかそういう日々を回す上で前提になるような定期的な「やること」で、予定は文字通り実施時間の決められているもの、タスクは決まった時間にやる必要はないけど、どっかでやらなきゃならんこと、余暇はそれら以外のあまりの時間、といったところか。
予定に関しちゃGoogle カレンダーがあるので良い。iPad miniから見たりとかでとても良い。タスクはtodo.txtをずっと使ってたけど、やっぱりまとまりのあるタスクを横断的に確認したりとか、そういう用途にはこの書式ってあまり向いてなくて、でもプレーンテキストのタスク管理は小回りが効くから好きでもあって、ちょっとどうしようか悩んでる。一番いかんともしがたいのはルーチンで、定期的にやることをタスクリストに入れてるとさすがにうざいのだが、だからといって頭の中だけで回してるとたまにしか掃除しない場所がずっとほったらかしになってたり、忙しいときにゴミを捨てるのを忘れたりとか結構ある。一番いいのはテキストファイル1つにもうタスクもルーチンも全部ぶちこんで入れておくことかなと思うんだけど、なんかそういうの上手くやってる人いないかなぁ（他力本願） アナログって選択肢は考えてない。タスクリストみたいなちょくちょく書き換わるものをアナログで管理するのは面倒。
前回GTD周りの記事を書いてから1年半ぐらいになるので、そろそろきっちり見直して考えなおそうかなぁと思う。まだ結論には至ってない。
あと冒頭の写真に映ってる「KEEP CALM AND READ ON」ってやつはiPad miniにスキンシール貼ったやつです。最近iPad miniのケースが割れてしまって、しばらく裸の状態で使ってたんだけど、ケースなしだとずいーぶん薄く感じることに改めてびっくりして、だったらもうシール貼っとけば傷は防げるし安泰じゃね？ってことでスキンシール買いました。オシャレっぽいし軽いし持ったときにつるつる金属面で滑らなくなったし、なかなか良い買い物でした。脱線、ただの自慢です。
前の記事がやたらポエミーになってしまったので、もうちょっと実際的なとこでVim使う上での注意点とか、今後覚えておきたいこと書いときます。
そもそも正規表現がきちんと修められていないので、これまで検索と置換はあまり使ってこなかった。が、これ使えないとVimの魅力半減だと思うので、ちゃんと使いこなせるようになるのが目標。
正規表現と一言に言っても言語やツールによって書き方が違う場合があって、Vimについても一部の正規表現用の特殊文字を使うとき、エスケープが必要なことがある。これについてはvery magicというオプションを使うとエスケープせずに済むらしい。vimrcに書いたりできないのがちょっと煩わしいが、エスケープ必要な特殊文字を逐一覚えて1個1個処理していくよりは良い。
せっかく正規表現を使うならvimgrepもマスターしておこうと思う。というかカレントバッファだけを編集するんじゃなくて、ファイルを扱うツールとしてVimを使いたい。今使っているのはNERDTreeぐらいなものである。
vimgrepは名前通り:vimgrepで打ちたくなるが、:vim {pattern} {files}の書式で使える。{files}にはフォルダパスやワイルドカードの他、標準出力も渡せるらしく、例えばgit ls-filesでGitにインデックスされているファイルだけを対象にしたりできるらしい。よくコード中に「TODO」とコメントしていく場面があるみたいだが、IDEではなくVimでも一斉検索して処理したりできるってことか。なるほど。vimgrepで探し当てた候補は:cpreviousと:cnextというちょっと面倒なコマンドで選択するようなので、ここはマッピングしときたいですね。
去年読んだ『実践Vim』にこのあたりのことはガッツリ書いてあった。.を有効活用せよ、繰り返しができるような操作を心掛けよと。例えばhoge=fugaとあって、イコールの前後にスペースを入れたい場合どうするか。イコールにカーソル持って行ってi<Space><esc>la<Space><esc>とかでももちろんいいんだろうけど、『実践Vim』ではs<Space>=<Space>を進める。挿入モード1回だけで入力が終わるので、この操作は.で使いまわせるからだ。もっと言えばuによるアンドゥも可能。移動→挿入モード→<esc>という動き1回で何が出来るか考えろと、簡単にまとめるとそういうこと。もちろんマクロも使えと。自分は複数行に同じ処理をするときとかによく使ってます。一度記録したマクロを再編集するとか、そういう使い方もあるらしいけど、ちょっとまだそこまではできてない。
今はtmuxで画面分割して、一方ではVimでコードを書き、もう一方で実行してエラーを確認したりしている。でもこれはVim内で完結できるはずかなと。プラグインとしてvim-quickrunを入れているのに使っていないのが原因。すっごい単純な話、
:QuickRun
さえ覚えておけば、編集中のコードを実行させることができる。長いので何かしらマッピングはしたいが。最初はこれだけやってればいいかもしれない。物足りなくなったらオプションいじってみたり。あとは:!でシェルのコマンド実行できるってこともちゃんと覚えておけば、Vim上だけでやれることがだいぶ増えると思う。
:!echo $HOME
ぶっちゃけキーアサイン覚えるのが面倒なので、基本のhjklとgg,G,あとはft/?あたりによる検索でしか移動してなかった。行番号指定での移動もデバッグのときとか（エラーメッセージ内に行番号出るので）よく使うけど、いちいち移動したい先の行番号確認してコマンド打つのは面倒だなぁとか思っててあまり使ってない。
というわけで移動をもうちょっとハッピーにしようと思う。このあたり？
w 次の単語の語頭へ移動
b 前の単語の語頭へ移動
e 次の単号の語末へ移動
ge 前の単語の語末へ移動
{ 段落単位で戻る
} 段落単位で進む
C-u 画面半分単位で戻る
C-d 画面半分単位で進む
H 画面内最上の行へ移動
M 画面内中央の行へ移動
L 画面内最下の行へ移動
% 対応する括弧へ移動
wbeあたり、wの逆がbに対してeの逆がgeってのは気に入らないなぁ。。。WBEにもそれぞれマッピングはあるみたいだけど、覚えるの面倒だし逆移動にマッピングしちゃってもいいかもと思う。Shift付ければ逆操作になるってのは直感的で良い。あとbbにバッファウィンドウ開くようマッピングしてしまっている自分はbを多用できない問題もあったりする。他は比較的納得感のあるアサインなので覚えやすい気が。特に{}、Vimでブログも書いてる自分は重宝しそう。括弧に関しては自分Rubyをよく書くので、matchitの設定でdefからendとかにも飛べるようにした。
if !exists('loaded_matchit') runtime macros/matchit.vim endif
また移動系だとvim-easymotionを入れているけど使ってないので、使えれば使ってみようかなと。コンセプトとしては3wや4fa等と打つとき、いくつ先に行くのか数を数えなくてはならないという煩わしさがあるので、移動可能な場所候補にラベルを表示して、ラベルの打ち込みにより一発で移動しようというもの。s{char}で画面全体検索というキーバインドもあるみたい。感覚としてはVimperatorのFollow hintの動作に近いのか。ちなみに『実践Vim』では回数指定はやっぱり煩わしいので、.や;で繰り返した方が速いよってなことが書いてあった。
あとctagsとかマークの機能もちゃんと使いたいのだが。ctagsはVimの機能というより、元々あったプログラムを活用して楽に移動できるようにしましたという話なので、そもそものctagsに対する理解を深めなければと思う。マークは次のキーマップを覚えれば使えそうだが、使いこなすのが難しそうな気もする。
m{char} カーソル位置にマークを設定
`{char} 指定のマークに移動
`` 直前のマークに移動
:marks マーク一覧の表示
今まであまり使ってなかったけど便利そうなキーマップ、改めてピックアップ。
D カーソル位置から行末まで削除 C カーソル位置から行末まで削除して挿入モード
このキーマップに付随してYもy$に割り当てたいよねってのが↓の記事に載ってたので早速vimrcに追記してます。+で<C-a>,-で<C-x>というのも真似してみた。確かにこれ、今まで便利なのは知ってたけど、キーマップが覚えられてなかった。そういうのはガンガン割り当て替えるべきですね。
s 1文字消して挿入モード
S 1行消して挿入モード
c{operator} 指定範囲を消して挿入モード
sとcの違いが掴めてなかった。cはオペレーターを取る。
zf 折り畳み（folding）
忘れる。これ。あまり使ってないけど。foldingの展開は<Space>で。
ヴィジュアルモードでo 始点と終点を入れ替え
『実践Vim』に載ってた。始点間違えてv押しちゃってもモード抜けなくて済むのですごく便利。
"0p ヤンクレジスタから貼り付け
0はヤンクレジスタにあたり、ヤンクしたテキストが暗黙的に入力されている。ddなどで削除したテキストはこちらには入らないので、よくあるヤンクして数行後の行を削除してからペーストしようとしたら、ddしたものが貼り付けられてしまった、みたいな事象を避けられる。レジスタはこれ意外にもいろいろ奥が深そうなので、機会があれば調べたい。
![Software Design (ソフトウェア デザイン) 2015年 01月号 [雑誌]](http://ecx.images-amazon.com/images/I/51sv-OIQh%2BL._SL160_.jpg)
正月休みにSD読みました。今月からpdfで買うことにしたんだけど、表紙の見出しの文字がちゃんと中のページに対するリンクになっていたり、サンプルソース内のコメントに書かれているような細かいURLまでちゃんとリンクになっていたり、とても丁寧に作られている感じがして良い。問題はこれを何で読もうかということ。普段は電子書籍サービスとしてKindleを使っているので、Kindleパーソナルドキュメントサービスにメールして入れておこうと思ったんだけど、サイズが大きすぎて添付して送れず。仕方なくiBooksで読んだけど、これだと当然ながらAndroidからは使えないなぁという不満があったり。悩ましい。
特集は「超基本」と、用途別に「プログラマ編」「インフラエンジニア編」「文書作成編」に分かれている。超基本は本当にインストールから初期設定のあたりの話。自分はVimをウェブ検索で得た断片的な情報を元に使い始めてしまっていたので、このあたりも参考にさせていただきました。「プログラマ編」はIDE風の使い方を、「インフラエンジニア編」は運用作業を想定して素のVimをどう使うかという話を、「文書作成編」はVimによるmarkdown編集をそれぞれピックアップしてます。
自分が思うにVimは単にエディタというよりは、テキストに対する扱い方の概念というか、フレームワークみたいなものなんだと思う。テキストの捉え方そのものが違うというか。オペレータやテキストオブジェクトあたりの考え方がまさにそうで、テキストを効率的に扱うために、どういう単位でテキストを編集していくかという考え方がこのあたりには反映されている。だからdiwを単にカーソル下の1単語を削除するコマンドとして丸暗記しても本質ではなくて、d,i,wがそれぞれ何を表しているのかを理解して、身体に染み込ませていかない限りは多分「Vim便利！」とはならないんじゃないかと思う。
Vimのプラグインっていうのは、これは様々なVimmerが考えた「もっともテキストを扱いやすい方法」の塊みたいなもんで、そのうち自分にも合うものを1個1個組み合わせていくことで、「ボクが考える最強のVim」になるんだろう。自分が当初やってしまっていた「ウェブで検索して便利そうなオプションはプラグインを取りあえず入れてみる」というのは間違いではないのかもしれないけど、入れたものちゃんと理解してる？とか、使ってる？っていうのを今後は意識したい。
特にプログラマ編でも触れられてたvim-quickrunは入れたはいいけど全然使ってないので使う。あとctagsも概念的に理解できてなくて、ちゃんとわかって使えば便利そう。Vimスクリプトもちゃんと読み書きしたいんだけど、まずその前に今年はテクニックバイブル読もうと思います。
あと全然この雑誌と関係ないんだけど、最近知ったDiffOrigコマンドがすげー便利。編集中のファイルの編集前後をdiffってくれる。こういう発見がいつまで経っても尽きないのよなぁ。
世間には目標何十個立てるみたいなライフハックもあるみたいだけど、自分としては少し抽象度の高いベクトルを数個厳選しておく方が先の見通しが立ちやすいので、ここに書いておく。ちなみに去年は目標50個ぐらい書き出したりしたのだが、単なるタスクリストっぽくなってあんまり意味がなかったし、あとで見返したときやること多すぎてウンザリしたので今年はやめた。
日本において「就職」と言われているのは実際には「就社」だという話がある。職業に就いたのではなく、単に会社に入ったというだけではないかという話だ。エンジニアに置き換えて考えると、所属している会社の社内ルールだとか慣例の中で上手くやれるように振る舞ってしまって、一般的なエンジニアとしてのスキルが身に付かないみたいなことはよく聞かれる。自分も今の会社に入って今年で5年目になるわけだが、そろそろ社内のレビューを突破する方法だとか、どこに重きをおいて評価されるのかといったことが理解できてしまっているので、意識無意識に関わらず社内最適化されてきてると思う。
じゃあエンジニアが「就職」するにはどうしたらいいのかという話になるのだが、20代という年齢を考えると、汎用的に使えるスキルの確かな獲得を重点すべきだと思っている。日頃身に付けるスキルはどうしても直近のPJで必要なものに偏りがちで、自分の話をすると例えばLinuxを一切仕事で扱っていないみたいな致命的問題があるのだが、そういうのどうにかしたい。これまで仕事で身に付けたと思い込んでいるスキルに関しても、一旦棚卸しをして社外で通じるかを試したい。具体的にはLTとか社外の勉強会でやれるようになったらいいなと考えている。あるいは会社の枠を持たないエンジニアコミュニティで何らか貢献したり。転職するのかとかどの会社で働くのかという話を超えて、そういう心掛けは必要だと思う。
ここ最近は金と時間でなんとかなるならすればいいじゃんっていう考え方をしていて、取り敢えず興味をもった分野があれば本を買ってみたり、買ったり行ったりするか迷うぐらいならGoでいいだろという判断をしていたこともあったんだけど、闇雲に広範囲に手を出すことって結局各分野に掛けるパワーは少なくなってしまって、後に残るものが少ないなと思い始めた。Less is moreって言葉があるけど、今の世の中「とりあえず手を出してみる」ってのはあまりに簡単過ぎるので、本当に必要なものを見極めて削ぎ落とす方向に今年はシフトしてみたい。
きちんと極め切れている領域が少ないので、最近だとRubyだとか仮想インフラ関連、そのへんをまずは行けるとこまで行きたい。あと注力する分野を減らすことで時間的、金銭的、精神的なバッファが多少生まれると思うのだが、そこも大切にしておきたい。これまでは迷うぐらいならGoを是としていて、ひたすらコードを書く方に意識が向きすぎてブログに残してないだとか、そういうことも多かったので、手を止めて考える時間、判断する時間を重視する。思いつきをすぐに全部手をつけていくのではなくて、ある程度寝かせてみる。そのためにはこれまで好きではなかったEvernoteとかもちょっとは役に立ちそうかなと思う。
自分にとってのLessが何であるかは常に意識したい。いろいろ捨ててったときに絶対捨てられないものは必ず出てくるので、そこだけは死守する。そして深堀りする。技術面以外だともともと自分はボカロ中心にブログを書いていたのだが、徐々に単なるミクLoverになりつつあるので、いや曲も聴こうぜっていう話だとか。美術展によく行ってるなら、一度見に行った作家について30分でいいから図書館で調べる習慣をつけるとか。自分がどの領域で生きているのかをきちんと意識しておくと、おのずとその方向に対するアンテナも伸びると思う。
人間は基本的に怠惰なので、性格や精神面を叩き直して行動のトリガーとするより、モチベーションが低かろうと行動できるようシステム化した方がいいというのがポリシーではあるのだが、システムの起動にも結局意志が介在するので失敗する場面がよくある。GTDではやることリストを作ってそれさえ見れば次の行動が全部わかるみたいな状態を目指すけど、わかったところで「やりたくねーな」って思ったらお終いなわけで、自分の場合やることリストが単なるストレス発生装置と化しつつある。怠惰を責めても仕方ないのは確かかもしれないが、ならば怠惰であろうと自動でトリガーが入るシステムをもっとしっかり整備するべきだし、単にエクスキューズとして「怠惰」を用いてるようではさすがに生産性は生まれない。
自分は特にGTDが「怠惰」を原因として頓挫しつつあるので、身の振り方を考えなおす。そもそもにして複数のリストを作り、それらを定期的に見直して更新かけるというGTDのメソッド自体、怠惰向きなものではないと思う。あるいはリスト作成に重点を置きすぎていた自分が間違っていたのかもしれないのだが、怠惰マンにとってのGTDで重視すべきは、リストの完全性より、脳内から洗い出した事柄の整理と捨象にある。やりたいこと、やるべきことなんてのはあたりまえだけど際限なく出てくる。それを全部リスト化しておけば、はじめのうちは頭が空っぽになった感じがするし、これでもう何も忘れる心配がないってことで気が楽にもなるのだが、リストというのは往々にして消化速度より追加速度の方が速いので、単なる重荷と化してくる。リストアップした項目に対してはまずきちんと向き合う時間を作って、それが本当に必要なのかを見極めるべき。さっきのLess is moreの話にも繋がるが、怠惰を前提としたシステムとしてGTDを使うのであれば、やることの削減にこそ意識を割くべきだと思う。
あとGTDのメソッドの一つとして「優先度を決めない（リストの端からとにかくやってく）」ってのもあるが、自分の場合これだとリストの中のやりたいことしかやらなくなってしまうので、先にやるべきことを優先するように変える。具体的には半径85cmが腐る（ex:洗濯物ためる、家計簿つけてない、連休だからって髭そってない）と日常全体が腐り始めることに気付いたので、そういうところから手をつけていく。QOL上げる。
この言葉、映画『ソーシャル・ネットワーク』で見たような気がするんだけど、ググるとユダヤのタルムードの教えと出てくるので、出典は定かではない。好きな言葉ではあるのだが、最近結構蔑ろにしてしまっていたなと思うので、今年は改めて意識する。一つの領域に数年携わって、それなりに「わかる」ようになってしまうと、少しでもわかっていない人とか、新しく入ってきた人を下に見るようになってしまう自分がいる。でも他の領域ではその人の方が優れてるってことはもちろんあるし、外部からやってきた人の方が目が慣れていない分、自分の領域に対して別視点からの意見をくれることもあるし、すべての他者に対してリスペクトを持つぐらいの姿勢を思い出したい。たぶん入社直後ぐらいはそうだったはずなので。あと、もっと他人と話すこと。勉強会参加して、懇親会出ずに逃げてくるクセをやめること。
問題が起きたときにググって解決すること自体は悪いことではないが、どういう思考過程を経てその言葉をググり、どうしてそのエントリーを正解と判断したのかというところを残していないのはあまり賢くないなと思う。知識のストック化、思考の言語化を進めたい。
アイデンティティを追求するとき、自己の内面を探してもたぶん答えってなくって、結局人間は外部から仕入れたミームの塊なのだから、自己を構成するミームが何なのかを解きほぐさないと答えに行き当たらないというのが自分の考え方なんだけど、自分のミームはここにあるよね？って言える状態を作ることが「知識のストック化」なんだと思っている。何かしら琴線に触れたもの、調べたり考えたりしたことは全部自分を構成するミーム足りうるので、それを書き留めてあとから見直して検証できる状態にしておきたい。仕入れた情報が実は間違っていましたってことも往々にあると思うんだけど、その情報がじゃあどこで間違えたのかってのは記録がないと検証できなくなってしまう。雑多なソースをとにかく量あたって漁りまくるのではなく、蓄積して、検証して、腹に落ちたところで飲み込む。飲み込んだこと自体忘れてしまっても、どうにかしてそこに行きつけるようストックしておく。Evernoteがゴミ箱になるとかどう整理したらいいのかわからんみたいな話がよくあるけど、あれは自分が獲得したミームのストックだと考えると上手いこと飲み込めそうな気がしている。
