Pages

2013-12-18

OS X 10.9.1 リリース — Dvorak ユーザーよ! 戻ってこい

昨夜、MacBook Air の OS を 10.9.1 にアップグレードした。

日本語入力問題が解決していたので、ここに報告する。

どんな問題?

キーボードの種類を「日本語」と「他のキーボード」で入れ替えた時に、「日本語キーボード」のキーボード配列が「前のキーボード」の設定に引きずられる。

これは日本語キーボードと US キーボードを使っている人には困らない現象。US キーボード以外を使っている人達には泣きそうな仕様変更だった。

US キーボード以外というと何があるのか? フランス語を使う人は、フランス語のアクセント記号を簡単に入力できる様にフランス語用キーボードがある。これは US キーボードと少しキー配置が違う (主に記号部分)。同様にイタリア語、スペイン語、ロシア語などなど同様の問題を抱えていた。

この対処法は一つだけ。US キーボードを入れて、日本語キーボードに移る前に一度 US キーボードを選択する、というもの。キーボード入力など息をするように行なっていた者には苦行以外の何ものでもなかった。

更に、一般の US キーボードとは違う配列を使う人間は泣きそうになった。

例えばぼくは Dvorak 配列を使っている。一般の US キーボードは Qwerty 配列というのを使っているけど、Dvorak 配列は全くキーの配置が違う。例えば、左手のホーム・ポジションには左から「aoeui」という風に母音が並んでいる。

英文を打つ時は Dvorak 配列を使うぼくも、日本語ローマ字入力する時は Qwerty 配列を使う。そもそも、キーボード配列とインプッド・メソッドは別レイヤーの存在。これを一緒にしてしまったので、一部の (そして少なくはない) 人達が困り果てた。

問題解決

OS X 10.9.1 では、このキーボード問題が解決された。喜ばしい。これで Mac で入力するのが辛い日々からお別れできる。OS X 10.9.1 の改善点は色々あるけれど、この問題に悩まされていた人達にとっては、この修正こそ最大の改善と言えると思う。

ref.

2013-12-15

社員として自宅勤務をやってみた体験談

ぼくが今、勤めているアクトインディ株式会社ではエンジニアとデザイナーに自宅勤務が許されている。自宅勤務は、リモート勤務・在宅勤務とも世間では言うのかな。最近では米 Yahoo! が在宅勤務を禁止にして話題になった。

ぼく自身の視点から、在宅勤務制度を利用してのメリット・デメリットを書く。

基本的なルール

自宅勤務を行なうに当たって、社内ルールがある。

  1. 自宅で勤務を行なうに十分な環境を整えていること
  2. 上長に許可を得ていること
  3. 他の人との作業に支障が出ないこと

自宅勤務制度は、ぼくが入社した時に既にあった。「自宅勤務で 2、3 倍のパフォーマンスを出す」というエンジニアが始めたのがきっかけと聞いている。彼は十分な成果を出すことで、自宅勤務する権利を得た。後から入ったエンジニアやデザイナーは、彼の成果を継承する形で「自宅勤務」が使えている。

自宅勤務は大低、入社 2 か月くらいの経って、その人の仕事振りを見て許可が下りる。人によって自宅勤務を選ばない人もいる。「自宅勤務に自分は向かない」「自宅勤務より会社の方が集中できる」等々、自分でジャッジしている。

仕事振りが良くても自宅勤務が出来ない場合もある。それは、自宅に勤務する環境が整っていない場合。開発用のアプリが入っていない、環境構築が出来ていない、セキュリティ・ソフトが入っていない等々。セキュリティ・ソフトなどは会社側が用意できるけど、自宅マシンがデスクトップの場合は環境構築の段階でつまずくケースもある。

周りから認められ、開発環境も整ったら、大低週頭に誰がどの日に自宅勤務するかを話し合う。基本、週二回の自宅勤務が認められている。仕事の進捗と周りとの関係から自宅勤務する日は多くなったり少なくなったりする。自宅勤務でパフォーマンスの上がる人は、突発的に忙しい時に一週間丸々自宅勤務に当てるケースもある。社内でのコミュニケーションが多く必要な場合は、自宅勤務する日を一日に減らしたり、0 にする場合もある。そこら辺は、各自の作業内容と状況に応じて変えている。

ぼく自身の自宅勤務

ぼく自身は、自宅勤務したからといって 2 倍のパフォーマンスを上げたりは出来ない。そんなスーパー・エンジニアじゃない。でも、自宅勤務するメリットは享受している。

第一に通勤時間の消滅。ぼくは今、朝、一番乗り換えが良い時間帯に出社しているけれども、それでも自宅・会社間で 90 分かかっている。帰宅時は、各駅停車や乗り換えの便の関係で 2 時間近くかかる。この通勤時間がなくなるのは大きい。普段よりもフレッシュに仕事を開始できる。開発効率は当然上がる。帰宅に体力を使わないので、翌日の出社が普段より少し楽になるのも嬉しい余録。

第二にリラックスした空間。会社には会社なりの緊張感がある。それはそれで良い。けれど、リラックスした空間で作業することで生まれるモノもある。それは思考の余裕だったり、集中力だったり、様々。ぼくのケースを言えば、ぼくは音楽が好き (see life@aka, 安宅の音楽日記)。BGM をかけながら作業をするのが好き。とてもリラックスできる (ちなみにヘッドフォンが苦手なので会社では音楽をかけていない)。このブログも音楽をかけながら書いている。リラックスした空間と、集中が高まることで音楽が耳に入って来なくなる瞬間、どちらも好き。

第三に邪魔されないエンジニア・タイム。最低限、Skype などで連絡は取り合っているけど、それ以外の接触がない。ロジックを考えたり、新しい事を挑戦するのに試行錯誤する時、誰にも邪魔されず集中できる時間が確保できるのは嬉しい。

iOS 開発での一例を挙げてみる。デザイナーに他の仕事が入っていて来週までこちらの開発に関われなくなった。その週、ぼくはデザイナー不在でも行なえるコーディングと、デザイナーの人が作業に入った時に必要と思われる下調べを行なった。そして自宅勤務に当てた二日間には Core Data 周りのコーディングを行なった (Core Data は iOS を始める人にとって最初の関門だと思う)。翌週、ぼくはデザイナーと一緒に仕事をした。下調べのおかげでデザイナーの要求に応えたり、逆にエンジニア側の要求をデザイナーに伝えることが、比較的スムーズに行なえた。その週はデザイナーとのコミュニケーションを多くする方が作業効率が上がったので自宅勤務は申請しなかった。

ぼくにとって、自宅勤務は倍とはいかないまでもパフォーマンス・アップに繋がる良い効果をもたらしている。ただ、振り返ってみると、ぼくは自宅勤務の日に、重いタスクの片付けや下準備を多くやっていたように思う。そうすることで、自宅勤務が明けた後、「普段の会社の業務」がよりスムーズになるように調整していた。逆を言えば、会社の中で途中の割り込みが入ると困る作業を入れていた。

変則的なリモート勤務

リモート勤務を自宅以外で行なったこともあった。

ゴールデン・ウィークや夏期休暇中のこと。連休と連休の間に平日が入ることがある。ここに全て休みを入れれば幸せなのかもしれないけれど、そこまで休みも取れない、仕事に軽くタッチしないといけない... なんて状況もあった。こういう時に、リモート勤務を使わせてもらった。

具体的には、ぼくは長期休暇に実家の新潟や生まれ故郷の香川へ帰省する。当然、長く休めれば休めるほど家族と過ごせる時間が増える。悲しいことに、大きめの休みが平日で泣き別れになっていた。そこで、休みが始まったら帰省。一日、休みをもらって、残る平日をリモート勤務。開発環境 (ノート PC) とネット環境 (モバイル WiMAX) があればどこでも作業はできる。そして後半の大きな休みに入って、余裕を持って帰省先から戻る。

大きなタスクがなかったのも幸いだったけど、大きな休暇を取りつつ、長期休暇特有の浦島状態にならないメリットは大きかった。

自宅勤務をしないという選択肢、自宅勤務のデメリット

今、ぼくは自宅勤務をしていない。これから数か月は自宅勤務をしないつもり。

というのも、仕事内容が少し変わった。

会社でコミュニケーションを取る方が、自宅勤務よりも捗る。だから、自宅勤務をしていない。

自宅勤務はエンジニアにとって「有効な手段」ではあっても、「最良の手段」とはならない。ケース・バイ・ケースで有効活用する時を選ぶのが良いと思う。

最後に自宅勤務に向かないケースやデメリットを書いておく:

  • 他人とのコミュニケーションを密に取る必要がある場合
  • 仕事に対して自分が未熟である場合
  • 自宅での作業が向かない場合 (アパートの隣の家に友達が来たのか、騒がしかったことが一回)
  • オフィス街と違って、住宅街のランチは時間がかかる (ことが多い)
  • 一人で作業していると寂しくなる時がある
  • 社内に持ち込まれたお土産やおすそわけにありつけない!! (数に余裕があると残ってる場合もある)

2013-12-09

社内で chef-solo 勉強会を開いた

2013-12-09、chef-solo の勉強会... というか「入門の入門」をプレゼンした。

内容は伊藤直也氏の「入門 Chef Solo」をよりシンプルに噛み砕いたもの。

入門Chef Solo - Infrastructure as Code
入門Chef Solo - Infrastructure as Code

とはいえ、工夫もある。同書が発売されたのは 2013-03-11 (Amazon の書籍情報による)。それからまだ一年も経っていないのに、同書の内容は古くなっている。

同書の発売に少し先がけて、ruby 2.0.0 がリリースされた。Vagrant は gem ではなくパッケージ提供されるようになった。Sahara は今や gem ではなく Vagrant の plugin となっている。そして、ruby 2.0.0 で chef がインストールできないという困った事態。それも、現在最新の chef-solo 11.8.0 では解決してしまった。

chef は進化が早い。chef は専門用語が多い。

Chef Server や knife-solo といった上級編も魅力に映る。けれど、初めて chef-solo を触った時、そういった上級編の情報はぼくにとって混乱の元でしかなかった。

今回のプレゼンでは「入門の入門」とタイトルにうたった通り、本当に chef-solo を始める人向けに最小限の情報を伝えるようにしてみた。だから、レシピの書き方は書いても、attribute の説明はしていない。Template と File の違いは書いたけど、実際のコードは説明していない。

機会があれば「Chef-solo 入門」なんて勉強会を社内で開いて、Attribute の使い方や実践的なレシピのコードリーディングなどできれば... いいな。

chef-solo 関連のエントリー

2013-12-05

コミュニケーションが下手だよね、って話

先日、友達と話をしていて「コミュニケーション能力」について話題が及んだ。

コミュニケーションにも色々あって、場の雰囲気を左右するものから、プレゼンテーションで発表するモノローグ的なものまで幅広い。今回、焦点を当てたのは「自分の意見を言う」コミュニケーションについて。

ぼくは、「自分の意見」を言うのがとても下手。

理由を友達に尋ねてみたところ、ぼくは強めに意見を出すとき「何か固執しているように見える」という。思い入れの強さが、意見を偏光させてしまう。ぼくの態度がどういう反応を周りに引き起こすかというと、「公平な意見を述べているように見えない」。

なるほど。流石、高校時代からぼくを知っているだけあって、よく見てる。思い当たる節が沢山ある。

この手のコミュニケーション能力不足は、普段、あまり顔を出さないから性質が悪い。強い主張をしなきゃ、と思う時に悪癖が表に出る。周りの信頼を少し失う。自分の言葉が軽くなる。意見が、意図が、伝わらない。もっと強く主張する。更に周りの信頼を失う。負のスパイラルに入っちゃう。

かつて、あるプロジェクトでぼくが何度言っても方針転換できなかったことを、後からやって来た人の一言が変えてしまったことがある。思えば、彼の話し方は偏りがなく事実だけを言っていた。

自分をどう変えてゆくかはこれからの課題。自己啓発本の類で、「上手く上司を説得する方法」なんて沢山あるけれども、その歯車を壊してしまう要因が自分自身にあるのだから困っちゃう。自分がどうでも良いと思ってることに関しては公平な意見なんて普通に言える。でも、思い入れのある事案に対しては、「言葉」が歪む。プレゼンの様に準備するものなら、「固執」を排することもできる。でもミーティングの中などで話し合う時は、つい熱くなってしまう。

必要なのは客観性ある意見の出し方。

それが何時でも言えるようになりたい。まずは、常に自分の発言を意識してゆくことから始めるしかないのかな。

読者へ

自分の意見が通らない・軽く見られる・信用されていない、と感じているなら周りの人に聞いてみると良いかもしれない。自分の発言が公平性を欠いていることがあるか? と。まずは意識しないことには始まらない。