10秒で鼻づまりを治す技術

今日は新書っぽいタイトルです。内容も10秒くらいで読めそうです。

いきなり核心ですが、鼻の周りをグリグリとマッサージすると、鼻腔の腫れが引いて鼻づまりを治すことができます。自分ではやりにくいので、家族にやってもらうのが良いでしょう。

さて。この方法、すごくよく効くのですが、誰かやってくれる人がいないと使えませんでした。例えば、電車に一人で乗っているときや、家族が先に眠ってしまった夜などは、この技を使えません(使ってもらえません)。

しかし! この技は、なんとイメージするだけでも効果があるのです。目をつむって、思いっきりグリグリされている感触を思い出すだけで、あら不思議! 鼻腔の腫れがみるみる引いていきます。実際にグリグリしてもらうのと同じくらい効くんですよ〜。鼻づまりって気合いで直せるんですね!

以上、昨晩思いつきで試してびっくりした報告でした。

仕事が好きでいられるコツ

たまには真面目な話も…。

私は仕事が好きです。
嫌いではない、という意味ではなく、本当に好きなのです。

自己紹介の時に、そう言うことが多いのですが、だいたいいつも驚かれます。
「いいですね~」とか「そんな風に言う人は珍しい」だとか。
(でもひょっとしたら皆、思ってても言わないだけなのかもしれません)

私も実際のところは、「退屈だな…苦痛だな….」と感じる仕事も時々あります。
でも、そういう仕事のほとんどを、最終的には楽しめるのです。

なぜでしょうか?

仕事が好きではない人と私のような人との違いは、そこにあるのかなと思ったので、今日は仕事を好きじゃないけど好きだったらいいのに、と思っている人向けに、「仕事を好きでいられるコツ」=「退屈/イヤな仕事を楽しむコツ」について書いてみようと思います。

コツ1.苦痛が減るように仕込む
コツの1つめは、今回が無理でも少なくとも次回からは、その仕事がイヤでなくなるように工夫をします。より楽々とこなせるようにするということです。

「それが出来れば苦労しない」という方のために、簡単な例で順を追って説明してみます。

ややこしい月報を毎月書かなければならない場合は、どうすればよいでしょうか。

まず最初に、「その仕事の何がそんなにイヤなのか?」をよく考えます。
この点を、本当にちゃんと考えるのがポイントです。何がイヤなのかを見誤っていると、その仕事がイヤにならないように対策を立てられないからです。

人によっては単に「考えなければならないのがイヤ」とか「忙しい月末に生産的でないタスクを強制されるのがイヤ」とか色々あるんじゃないかと想像しますが、私にとっては、その仕事の苦痛すなわち"イヤなところ"とは、「ややこしいので何度も見直さなければならず面倒くさい」です。
本人にとっては「そんなの○○が××なところがイヤに決まってる!」と簡単に決めつけてしまうような事でも、他の人にとっては全然違うことがありえるのと同様に、自分でも苦痛の本質を勘違いしてしまうことは結構あるので、よくよく注意しましょう。

その仕事の苦痛ポイントが分かったら、次のようなことを考えます。

  • その苦痛を少なくするには?
    • ややこしくなくする
      • 複雑なルールのうち、明らかに無駄と思われるものがあれば、上司に直訴してルールを減らしてもらう。
      • なぜそのようなルールになっているのか考えてみる・上司にきいてみる。理由がわかればルールを理解しやすくなるかもしれない。背景を理解できれば、よりシンプルなルールを提案できるかもしれない。
    • 何度も見直さなくてよくする
      • 誰かに見直してもらう。(相手の何か別の、出来れば自分の得意な仕事と交換するのが良いでしょう)
      • 簡単にチェックする方法を考える。チェックを助けてくれるソフトが無いか探す、作ってみる。

考えるときのヒントも書いておきます。

  • 自分自身ではなく、自分の上司ならどんな方法を採れるのか?
    • 視点を上げることによって、より良いアイディアが浮かぶかもしれません。ただし、あなたの上司が、今現在なぜそれを実行していないのかについて、上司の立場で一度考えてみましょう。
    • あなたが未だ右も左も分からない新人ではないのなら、実際に何かを上司に提案しても、それほど的外れなものにはなりません。(上司によっては、せっかくのあなたの提案も邪険に扱われてしまうかもしれませんが、そういうときの対処方法については、ここではアドバイスできません)

そして実行します。

最初は思ったように行かなくて当たり前です。「余計なことしなきゃよかった…」と後悔することも時にはあるかもしれませんが、何か新しいことを試すのは楽しいものです。たとえ結果がよくなかったとしても、経験値が増えたことを喜びましょう。エジソンの言葉を借りれば、上手く行かない方法を一つ学んだのです。

コツ2.チャレンジを仕込む
コツの2番目は「チャレンジを仕込む」です。これは退屈な仕事に特に効きます。退屈な仕事はいつもと同じだから退屈なわけで、そこに何か新しいルールを持ち込むと刺激が増えて退屈ではなくなります。ルールによっては余計な手間が増えたりするので非効率な気もしますが、よほどすごいチャレンジをしない限りは、かえって効率があがったりするのです。

ホーソン実験をご存じでしょうか?

1924年から1932年までシカゴ郊外の工場で、作業能率と物理的な条件の関係を分析する目的で、一連の調査実験が行われました。そのなかの一つ、照明実験では、工場の照明と作業能率の相関関係を調査することが目的の実験でした。結果は、照明を明るくした場合に従来より高い作業能率となっただけでなく、照明を暗くしても従来よりも作業能率が高くなることが計測されました。

常識的に考えると、照明を暗くすると作業効率は落ちそうですが、そうはなりませんでした。他の実験結果と照らし合わせて導かれた「作業効率を高める要因」は、観測者が居ることだったのです。たったそれだけのことで作業効率って変わるんですね。これはホーソン効果と呼ばれています。

例えば、このホーソン効果を自分の現実の仕事に応用してみます。誰かに観測してもらうことは難しいので、ちょっと工夫が必要です。

およそどんな仕事でも、誰かのためになることをやっているので、その人がいつもより嬉しいと感じるような工夫をしてみます。つまり、いつもと違う仕上がりでお客さんや上司が喜ぶ様子を想像しながら作業するのです。するとそれだけで作業効率はあがります。

※良い上司/お客さんなら、その努力の痕跡を見つけて、きちんと褒めてくれます。次回以降も自分が努力を続ける助けになるし、良い上司/お客さんをもてたことに感謝して、ちゃんとお礼を言いましょう!

その他のチャレンジのヒントをあげておきます。

  • タイムトライアル。「アレ頼むよ」「できました」「速っ!スゴイ!」
  • 言われる前にやっておく。「アレ頼むよ」「もうできてます」「スゴイ!」
  • 自動化する。「アレ頼むよ」「ポチッ….。できました」「自動化されてるっ!スゴイ!」

楽しそうでしょ?

技術と魔術

今日は随筆的な事を書いてみます。

SEという仕事をやっていると、いろいろな物事の「仕組み」が気になるようになります。

あれはどういう仕組みで動いているんだろう? 
どうしてこんな規則があるんだろう? 
なんでこうなってないんだろう?

仕組みが分かれば、それは技術になりますが、仕組みが分からないとマジックショーと区別がつきません。

��,2,3と唱えることで不思議な力が働いてハトが現れるのか、大気中の分子から瞬時にハトを合成する装置を備えた帽子だからなのか、何か他の想像を超えた仕組み(タネ)があるのか分からないのと同じです。

そして、そういうものを見ると気になって仕方ないのです。

対象がソフトウェアでもそれは同じなのですが、何年もITにまみれて仕事をしていると、どうやって動いているのか想像もつかないソフトウェアというのは、とても少なくなってきます。

なぜならコンピュータの動く仕組みは、究極的には、ビット演算の論理とそれを実現するハードウェアが全てで、あらゆるソフトウェアの仕組みというのは、その応用に過ぎないからです。

しかし、全てのソフトウェアの基本原理を理解したつもりでいても、時には「どうやって動いてるんだこれ…」とか「やられた…その手があったか…」ということがまだまだあるのがこの業界のおもしろいところです。

そんな中でも最近多いのは、

  • 地道な(それでも他分野に比べれば数倍速い)技術革新によって、これまでアイディアはあったけど実用化できなかったことが実現できるようになった系。
  • ソフトウェアから構成されるシステムに、人間という素材を組み合わせることによって大化けする系があります。

前者は、コンピューターグラフィックによるエンタテイメント全般、非接触ICカード、SSHD、マルチタッチUI、Eye-fi、少し古いところでMMORPGなど。

後者では、Wikipedia、SNS、ブログ、(これもブログかもしれませんが)Twitter、Flickr、YouTubeなど。MMORPGはこっちにも当てはまるかもしれません。

結構ありますね。

これらはどれも仕組みをおおよそ想像できるので、私にとっては魔術ではなく技術です。しかし、それらの製品・サービスが登場するタイミングや、核となるアイディアを産み出した思考、ビジネスとして成功させた手腕などは、私にとって未だ未だ魔術なので、すごいな~と驚きつつも、自分にも出来るかな~、と思う毎日です。

プロダクティブ・プログラマ読んだ

読みました。
プログラマ向けのユーティリティ紹介とか、tipsとか、各種自動化テクニックとか。
以下は、読むまで私が知らなかったもので、試そうと思ってるもののリスト。

  • CLCL
    Windows向けクリップボード拡張。
  • !キー
    bashのコマンド履歴を検索するhistoryコマンド。!の後に検索したいコマンドの最初の文字を入力する。
  • pushd, popd
    カレントディレクトリの履歴スタックを操作する。
  • OpenCommandWindowHere
    MicrosoftPowerToysのひとつ。名前の通りの機能。
  • KeyPromoter
    shortcut keyを使うようにしつこく勧めてくれるプラグイン。IntelliJとEclipseにある。
  • ローカル変数の抽出:Alt+Shift+L
    右辺になるところを選択状態、または、右辺だけを書いた状態で起動すると、変数の宣言と初期化をやってくれる。
  • 型の検索:Ctrl+Shift+T
    キャメルケースの大文字のところだけタイプしても検索できる。
  • AutoHotKey
    Windows向けのキーマクロ。
  • wgetのmirrorオプション
    サイト全体をミラーリングできる。
  • Pluse(Eclipseプラグイン)
    プラグインのインストール先を外部化して、SVNなどに保存可能にする。
  • リファクタリングではコメントの排除を目指す。(コメントがある=わかりにくさの補完。コメントが無い=補足が不要なほど分かりやすいコード)
  • Panopticode
    Emma, CheckStyle, JDepend, JavaNCSS, Simian, Panopticode Aggregatorを含むコード解析ツール。
  • SLAP
    同じメソッドに属するコードの抽象化のレベルをすべて統一する。
    それによってコードの抽象化レベルがそろうのであれば、1行のメソッドを作っても特に問題はない。
  • JEdit
    Java製エディタ。
  • eEditor
    MACのTextMateのWindows版。
  • Groovyのマークアップビルダ
    コードからXMLを生成するためのツール。既存XMLからコードを生成することもできる(アンビルド)

アジャイルな見積りと計画づくり

読書メモ。(ちょっと愚痴っぽくなったけど)

第一章 計画の目的

p034.
「変更されてもかまわない」というだけでなく、むしろ「積極的に変更したい」と思うのがアジャイルな計画である。変更そのものに価値があるわけではない。私たちが変更に積極的なるのはなぜかというと、変更が起きると言うことはすなわち、なにか学習したり過ちに気づいたりしたことを意味するからだ。

メモ:変更が多いということは、たくさん間違っていたということ。過ちに気づいたのは歓迎するべきだけど、それを計画段階で拾う方法が本当に無かったのかは、ちゃんと考えてみたい。

第二章 なぜ計画づくりに失敗するのか

p044
ユーザーが最終的に何を求めるのかには不確実性があり、はっきりとはわからない。この事実を無視すると、プロジェクトとしては期日を守れたとしても、ユーザーにとって本当に重要なフィーチャを取りこぼしてしまいかねない。というのも、計画を立てた後で明らかになった重要なフィーチャを反映させられないからだ。

メモ:最終的に求めているものと、今求めている(と思っている)ものが違う、ということをユーザーに自覚してもらう戦略について考えてみたい。

第五章 理想日による見積

p069
理想日で見積もるときには、以下のような前提を置く。

  • ストーリーに必要な作業だけを見積もる
  • 作業に必要なものはすべて、作業の開始前に用意されている
  • 途中で割り込みは発生しない

メモ:後でベロシティを計測できるように、見積の前提条件を統一しておくためのテクニック。

第六章 見積の技法

p074
まず、アジャイルプロジェクトでは誰がどの作業をするのか事前にはわからないことが多い。たしかに、複雑なストアドプロシージャのタスクはデータベースに詳しいメンバーがやってくれると期待していい。だが実際には、必ずその通りになるとは限らない。その人がたまたま他の作業で忙しく、他の誰かが担当せざるをえなくなるかもしれない。ある作業を担当する可能性は全員にあるのだから、見積にも全員が関与すべきだ。

メモ:ある作業を担当する可能性は全員にある…それはそうなんだけど、見積時にはチームメンバすら決まってなかったりする(だって納期がおおよそ決まっているのに規模は分からない状況で要員計画できないし)。 協力会社のメンバに作業してもらう可能性も排除できないから、かなり無理して全社員で見積できたとして実際に作業するメンバーの事前の合意を得る事なんて無理かも。
なので、「見積をコミットメントと捉える」従来型の計画づくりには適合できない。導入するならそこからやらないと、ギャンブルになるか、どこかにしわ寄せが行くか。

p081
2分計の砂時計を購入して、プラニングポーカーのセッション中にはテーブルの中央に置くのだ。セッション中はいつでも誰でも砂時計を使ってよい。砂がつきたら(つまり2分が経ったら)、次のラウンドに進む。議論が合意に達しなかった場合は、議論を続けてもよいが、そのときは再び砂時計を使う。こうすれば、次の議論も2分間に制限できる。一度の議論で砂時計が2回以上使われることは稀である。砂時計を使うことを通して、チームはこれまでよりも迅速な見積のやり方を学ぶからだ。

メモ:どんな会議にも応用できそう。

第七章 再見積り

p085
「自分でもよくわかっていないことを、厳密にしても意味がない」
– ジョン・フォン・ノイマン

第二十章

p244
個人のベロシティに反対する議論を続けるが、そもそも個人のベロシティは計算可能になっているべきではない。個人のベロシティが測定できる状態になっていること自体がおかしいのだ。基本的にユーザーストーリーは1人だけでは実現できないように書くべきだ。ユーザーストーリーは、ユーザーインターフェイスデザイナ、プログラマ、データベースエンジニア、テスト担当者のそれぞれが協力することなしには実現できないように書くのである。プロジェクトのユーザーストーリーが、1人で完了させられるような内容ばかりなのであれば、ストーリーの書き方を見直した方が良い。

メモ:そんなに専門家がそろっている会社って、あるんですね…。

Google Chromeはやいですよ

またもや新製品ネタですが…(新奇性追求なので仕方ないのです多分)

GoogleChrone速いですよ。

遠い昔、ADSL環境で初めてネット接続したときに感じたサクサク感を思い出しました!

毎日毎日、普通に使ってますけど、最近のWEBブラウザがやってくれてる処理って、大変なんですよ。知ってましたか?

ブックマークからか、直接入力からか、とにかくURLを指示されたらブラウザには仕事が一杯あります。

まずはHTMLというファイルをダウンロードして、そこに書いてあるプログラムみたいのを解析して、追加の画像ファイルやらCSSファイルやらを複数いっぺんにダウンロードして、ダウンロードしたCSSをまた解析して、どんな風にレイアウトするんだとか計算して、CSSファイルにまた画像ファイルのURLが書いてあったりして、しゃーないそれもダウンロードして、画像ファイルがダウンロードできたらどんどんそれも画面に貼って、忘れちゃいけない肝心の文字も表示して、おいおいFlash動画まであるのかよ! 広告のくせに生意気な…おっと画面に表示する前に走らさないといけないJavaScriptもあるんだった!

なんてのが、ほとんど毎回です。大変そうでしょ? 私がやってるわけじゃないけれど、大変なんです。だから、ちょっとくらい”もっさり”する感じは回避不能なんだと、ずっと思っていました。

でも、Chromeは速いんですよ。今までの、あのクリックするたびに待つ一瞬は何だったのかと思いました。

さすがGoogleです。

Google日本語入力!

ついに来た…!という感じの「Google日本語入力」。

昨日、Googleから「Google日本語入力β」が公開されました。

どこがGoogleなのかというと、WEB解析で得られる単語を辞書データベースに保存して皆に使ってもらう、という仕組みです。

日本語入力システムで似たような試みとして「Social IME」があります。

Social IMEは「辞書メンテを皆でちょっとずつやろう」という発想なので、いわば「Wikipedia的IME」。一方、Google日本語入力は「皆が書いたWebから自動的に辞書を抽出しよう」という発想なので、まさに「Google的IME」と言えます。

で、実際のところ、どうなんだ? ということで早速一日試してみました。

以下、その感想:

ネットワーク環境に依存するのだろうと思いますが、ちょっと反応が遅い時がありました。

��日使っていると慣れてきたせいか、ローカルに何かがキャッシュされるのか、だんだん気にならなくなってきました。

変換精度はMS-IMEよりは良いです。ATOKと同じかそれ以上な感じですね。

予測変換の候補は、便利というより面白くて気が散ります。

「大きな課題」の「おおきなお」までタイプしたところで「大きなお友達」とか。

変換精度を試そうとして「うらにわ」とタイプしただけで「裏庭には二羽庭には二羽鶏がいる」と先回りされるとか。

ベータ版でこの完成度というのは凄いと思います。

いつの日か変換候補に広告が入るのでしょうが、無料でこの変換精度なら、私は来年のATOKライセンス更新を考え直すだろうなと思いました。

そうそう。Linux版も開発が進んでいるとかいないとか。ぜひ対応してほしいと思います。