2014-04-29

Google Spreadsheet で条件付書式を使ってセルに色を塗る

Excel 使いの友人が「条件付き書式」でのセル背景色を変更する、ということが Google Spreadsheet で出来ないと嘆いていたのが一年ほど前のこと。Google Spreadsheet はその機能をサポートしたのだけど、そのやり方を伝え損ねていたので、ブログに書く。というか分かり易いように YouTube で動画を撮った。

30 以下のセルは背景色を「赤」に、70 以上のセルは背景色を「青」にする設定をしてみた。

やり方を文字にも落としておく。

  1. 条件書式付きの対象としたいセルを選択する
  2. メニューから「表示形式 > 条件付き書式...」を選択
  3. 条件を「次より小さい」、値を「30」に設定
  4. 背景色を「赤」に設定
  5. 「条件を追加」をクリック
  6. 条件を「次より大きい」、値を「70」に設定
  7. 背景色を「青」に設定
  8. 「条件を保存」

ちなみに条件書式に使える条件は以下の通り:

  • 次を含むテキスト
  • 次を含まないテキスト
  • 完全一致するテキスト
  • 空白セル
  • 日付
  • 次より前の日付
  • 次より後の日付
  • 次より大きい
  • 次より小さい
  • 次と等しい
  • 次と等しくない
  • 次の間にある
  • 次の間にない
  • カスタム数式

書式には「テキストの色」と「背景色」を選択できる。

Google Spreadsheet でセルをドラッグして数を増やす方法

Microsoft Excel ではセルに「1」と入力して、そのセルをドラッグすると 2, 3, 4,... とセルの数が増えてゆく。同じことを Google Spreadsheet でやると、数は増えず「1」の入ったセルが増えてゆく。けれど、少し手を入れれば Google Spreadsheet で同じことができる。

簡単な動画を作ってみた。

最初は Excel と同じ方法。当然 1 が並んで NG となる。

次が Google Spreadsheet のやり方。

セルに「=」を入力したら増やす前のセルを選択する。今回の場合 B2。次のセルは B2 に 1 加えたものだから、B3 セルは「=B2+1」となる。

B3 セルの値は 2 になった。この B3 セルをドラッグすると 3, 4,... とセルの値が増えてゆく。

計算式を一度作らなきゃいけない点が面倒だけど、一度やり方を覚えれば難しくない。やり方に気がつかないとハマっちゃうけどね。

2014-04-27

近況・会社が引越をしました

2014-04-01、チャットワーク株式会社入社した。

最近の ChatWork 社の動きで大きかったのは東京オフィスの引越を挙げられよう。

2014-03-28 (金) に、「旧LIGオフィスにChatWorkがお引っ越し!オープニングパーティー」を開催。4/3 に引越を行ない、LIG 社のブログにも取り上げられた。

ぼくの周りの会話

転職の話を持ち出すと、こんな会話が何度も起きた:

  • 友達: 最新どう?
  • ぼく: うん、会社が引越した
  • 友達: へえ、どこに?
  • ぼく: 上野のほう
  • 友達: 通勤は楽になった?
  • ぼく: ううん。遠くなった
  • 友達: なんで遠くへ引越したの?
  • ぼく: 引越したのは、ぼくじゃなくて、会社が引越したの...

「会社が引越した」と言っているのに、いつの間にか「ぼく」が引越したことになっている。そりゃ、会社の近くに引越したいのは当然の摂理だけどね。人は、どうやら、自分の信じたいものを信じるらしい。

なので、ちゃんとブログにちゃんと書いておく。

  • 4/1 (火) 入社した
  • 4/2 (水) 引越準備
  • 4/3 (木) 引越当日
  • 4/4 (金) 新オフィスで仕事開始

入社早々新オフィスへ引越という大イベントを経験した。自分の家の引越は大変だけど、オフィスの引越はみんなでワイワイやるので楽しい。

ブログ clmemo@aka、9 周年

2014-04-27 (日) をもって当ブログ clmemo@aka は 9 周年を迎える。

2013 年を振り返ってみると、2 月末に アクトインディに入社、翌 2014 年 4 月に ChatWork へ転職。挑戦の多い一年だった。

9 年間の記事投稿数を見てみたい:

  • 2005: 328
  • 2006: 659
  • 2007: 205
  • 2008: 202
  • 2009: 217
  • 2010: 139
  • 2011: 179
  • 2012: 223
  • 2013: 170

2006 年の 659 記事は別格として、一年 200〜300 本の記事を書いてきた。去年は 170 本と平均より少ない記事数に留まった。特に 6 月を過ぎてからの記事数減は残念につきる。

ブログを長年書いている身として、インプット、アウトプットが少ない日は仕事も乗らない。去年はインプットは多いものの、アウトプットできる日が少なかった。今年は小ネタでも良いので記事数を増やしたい。

9 年目の clmemo@aka もどうぞよろしく。

ref.

2014-04-24

iphone_dev_jp feat. Ben Zotto の講演まとめ

2014-04-22、iphone_dev_jp において Penultimate の開発者 Ben Zotto 氏の講演が開かれた。

  • 日時: 2014-04-22 (火) 19:00-21:30
  • 場所: アーク森ビル 31F 株式会社ドコモ・イノベーションベンチャーズ ラウンジ

Penultimate は iPad 用の手描きアプリ。Evernote に描いた絵を保存できる。

講演では、Penultimate のパフォーマンスでボトルネックとなった「画像」の内部処理が語られた。

iOS と Evernote

Penultimate は特定のタイミングとイベントで Evernote と同期 (sync) する。Evernote API は画像のデルタ保存 (差分だけを保存する技術) をサポートしていないので、全て上書きになる。

iOS には画像を扱うメソッドが 2 つある。

  • UIImagePNGRepresentation
  • UIImageJPEGRepresentation

PNG と JPEG のメソッド。PNG は可逆圧縮で、JPEG は不可逆圧縮。

2.5 MB の RAW データをそれぞれの方式で圧縮した場合のデータが示された。使う画像は、メモのような書き物、画像的な図、そして書き物と図を一緒にした dense。

結果は、メモや図では PNG に運配が上がる (メモ: 145 KB < 155 KB; 図: 110 KB < 136 KB) ものの、dense では JPEG の方が良かった (dense: 251 KB > 191 KB)。

PNG-8

Dense を考えれば PNG より JPEG の方が好ましいか。

ここで Penultimate が扱うデータに注目してみる。Penultimate では 32bit の PNG 画像など扱わない。せいぜい使う色の数は 256。ならば、256 色のカラー・パレットを持つ PNG-8 形式を使えば画像サイズは 1/4 になる。

PNG-8 には pngquant というツールで変換できる。その結果は次の通り:

PNGJPEGPNG-8
メモ145 KB155 KB61 KB
110 KB136 KB36 KB
Dense251 KB191 KB91 KB

このように、Dense であっても PNG-8 の方が JPEG よりサイズが小さい。

補: Quantization

PNG (32bit) から PNG-8 に変換する手順を簡単に書いておく。

  1. 元の画像から色のヒストグラムを作成する
  2. 最適化されたカラー・パレットを決定する
  3. 各ピクセルに対して、カラー・パレットから最適な「色」を決める

3 番目の手順は、コードで書けばこんな感じになる。

for (pixel in image) {
  for (color in palette) {
    // 元の色に対して color が合うかどうか判定する
  }
  // 選んだ色をピクセルに貼り付ける
}

第 1 試行

Mac では 0.7 ms で実行できた。

iPad では 6 秒かかった。

遅すぎる!!

プロファイルを取ると、Quantization の手順 3. で時間を喰っていることが分かった。

第 2 試行

上記コードの内側のループを SSE のアセンブラで、外側のループを OpenMP で処理したい...

のだけど、どちらも iOS にはない。

ので、SSE の代わりに ARM NEON を、OpenMP の代わりに Grand Central Dispatch を使う。

その結果は... 5 秒だった。

The fastest implementation of a slow algorithm is still slow.

遅いアルゴリズムを最速にチューニングしても、遅いものは遅い (意訳)

第 3 試行

内側のループを外してみる。

pngquant は「どんな画像」に対しても「良い」カラー・パレットを作成する。けれど、Penultimate は手描きアプリだから描ける画に制限がある。だから、事前に「ある程度良い」カラー・パレットを作成可能なはず... というアイデア。

具体的には pngquant をオフラインで実行し予めパレットとテーブルを作成する。これらを最初からアプリの中に保存。必要な時に (都度々々作成するのではなく) ロードする。

これで実行速度は 0.5 秒になった。

第 4 試行

そして、最後の試み。予め作ったカラー・パレットを 3 次元表示してみる。

Color palette in 3D

これはまるで、立方体にテクスチャーを貼ったもののように見える。3D テクスチャーと言えば OpenGL。

3 次元を 2 次元に展開すると (ref. ボロノイ図) こうなる。

Color palette in 2D

このデータを OpenGL から使うように再コーディング。OpenGL は CPU ではなく GPU を使うことができるので (特にこの手の処理では) 処理能力の向上が期待される。

結果... 0.025 秒。

圧倒的じゃないか!!

Morals of the Story

Zotto 氏は最後に開発の肝を紹介した講演を閉じた:

  1. Find your bottlenecks with profiling
  2. Use peculiarities of your data to find opportunities
  3. Put the platform to work!

(意訳)

  1. プロファイリングでボトルネックを見つけなさい
  2. 扱うデータの特異性を有効利用しなさい
  3. プラットホームで動くようにしなさい

あとがき

iOS の話だったけど、XCode とか、UI とか、NSObject とか全く出なかった。データ最適化の手法を見せつけられた。なんか、C の世界に戻って来た気がした。

OpenGL の高速化には舌を巻いた。

最後の質問タイムで、こんな質問が出た。「何をもって、最適化の『終点』としたのか? 何故 0.5 秒で満足しなかったのか?」。Zotto 氏は「自分はエンジニアで...云々」「でも、当時はプロジェクト・マネージャーもやってて...云々」と前置きを宣わって、こうとどめを刺した。

そこに OpenGL のパイプラインがあって、数時間でやれるんだったら、試してみたくなるだろう?

2014-04-23

ダンボーのモバイル・バッテリー — アクトインディ送別会でのプレゼント その 2

cheero power plus DANBOARD version

アクトインディの送別会でよつばとのマグカップを頂いた。実はもう一つプレゼントをもらっていた。それが、ダンボーのモバイル・バッテリー。正式名称は cheero power plus BANBOARD version -mini-。

モバイル・バッテリーで有名な cheero がキャラクター・ダンボーとコラボした製品。人づてに聞いて確認していないのだけど、このダンボーは、マンガ「よつばと」で生まれたのだとか。マグカップといい、「よつばと」繋がりでプレゼントは選定されたっぽい。

ますます、「よつばと」を読まなきゃな気分になる。ネット喫茶に置いてあったかな?

コンパクトなモバイル・バッテリー

ぼくは今、2 つのモバイル・バッテリーを持っている。cheero power plus と Anker astro M3 の 2 つ。cheero が 10,000 mAh で、Anker が 13,000 mAh。

ぼくが今回もらったのは、ダンボーは mini バージョンなので 6,400 mAh。

せっかく 3 つ持っているので、サイズの比較をしてみた。

モバイル・バッテリーのサイズ比較

上から、ダンボー、cheero、Anker。どんどんサイズが大きくなっていく。バッテリー容量で言えばダンボーは Anker の半分なんだもの。納得のコンパクトさ。ダンボーは、iPhone なら 2 回は満充電できるはず。使い勝手、良いよね。

もらったものは使ってナンボ、ってのはあるけれど、貰い物を傷つきやすい鞄の中に放り込むのは抵抗があって、ダンボー君は今で待機状態。メイン機は Anker になっている。白いのが Mac や iPhone と色のマッチングが良くてね (バッテリー容量はあまり気にしていない)。

おしゃれなお出かけがあったら、ダンボーを持って行きたいな。素敵なプレゼントをありがとう。あと、よつばと、読みます。

2014-04-14

よつばとのマグカップ — アクトインディ送別会でのプレゼント 1

よつばと! マグカップ (牛・300ml)

2014-03-31 をもってアクトインディ株式会社を退職した。3/28 に会社の人達が送別会を開いて下さり、プレゼントを頂いた。そのうちの一つがマンガ「よつばと」のマグカップだった。会社でコーヒーを飲んでいたのが印象に残ったのかな?

さて、ぼくは「よつばと」を読んでいない。なぜ「よつばと」のマグカップなのか。これは、マンガも読みなさい、というお達しなのかな?

サイズは 300ml ということで、ぼくが愛用している Amazon のマグカップ (380ml) より一回り小さい。

【Amazon.co.jp限定】Amazonオリジナルマグカップ白
【Amazon.co.jp限定】Amazonオリジナルマグカップ白

今回、記事にするに当たりネットで価格を見たのだけど、これ 2,680 円もするのね! びっくり。家用に置いておこ。家ではコーヒーは飲まないけれど、サイダーを飲みながら、音楽を聴きつつ、本を読むのがぼくの至福の時の一つなので、そんな時に活躍してもらう!

素敵なマグカップをありがとう!!

2014-04-10

複数の Github アカウントを使う方法

GitHub は一人が複数のアカウントを持つことを良しとしていない。とはいえ、何らかの事情で複数のアカウントを取得する人もいると思う。例えば、個人と会社でアカウントを分けなければいけない場合など。

ここでは仮に ataka-private と ataka-work という 2 つのアカウントを取得した場合を考えてみる。

デフォールトは仕事用

仕事用アカウントで big-project リポジトリーを作成したとする。この場合、git clone/pull/push は次のようになる。

$ git clone git@github.com:ataka-work/big-project.git
$ git pull git@github.com:ataka-work/big-project.git
$ git push git@github.com:ataka-work/big-project.git

仕事用の設定は特に問題ない。ところが、同じ様に ataka-private アカウントに git でアクセスすることが出来ない。

プライベート用の設定

まず、プライベート用の ssh キーを作る。

$ ssh-keygen -C ataka@private

デフォールトでは id_rsa というファイル名になるけれど、ここは id_rsa_private という名前に変えておく。github の ataka-private アカウントに id_rsa_private.pub の中身を登録。

ataka-private アカウントにアクセスするのに、id_rsa_private を使う様、~/.ssh/config に次の設定を追加する:

Host github.com-ataka-private
  HostName github
  User git
  IdentityFile ~/.ssh/id_rsa_private

ataka-private アカウントにある misc プロジェクトを git clone してみよう。github が推奨するように remote を設定する。ただし、github が提示する URL に一つ変更を加える。

$ git remote add origin git@github.com-ataka-private:ataka-private/misc.git

これで、clone/pull/push が出来るようになる。

$ git clone git@github.com-ataka-private:ataka-private/misc.git
$ git pull origin master
$ git push origin master

アカウントの数が増えても、同様に対処していけばいいだけ。

あとがき

ここでは仕事用をデフォールトにしたけど、逆にしてしまっても良いし、.ssh/config に仕事用の設定を追加してもいい。ま、どうしても複数アカウントを作らなきゃいけない場合に参考にして頂ければ嬉しい。

ref

2014-04-02

最近の rbenv (2014-04)

rbenv を使うと複数バージョンの Ruby を入れられる。過去にも一度記事にしたけれど、最近、少し使い方が変わったのでもう一度書く。

準備

Debian 系では下記パッケージを事前にインストール。

$ sudo apt-get install build-essential libreadline-dev libssl-dev zlib1g-dev

OS X では XCode Command Line が入っていれば大丈夫... かな?

rbenv インストール

rbenv は git リポジトリーからインストールする。

$ git clone git://github.com/sstephenson/rbenv.git ~/.rbenv

Bash の場合、設定を .profile と .bashrc のどちらに書くか難しい。.profile はログイン時のみ読み込み、.bashrc は bash 起動時に読み込み。screen で複数のスクリーンを起動する場合、.bashrc に設定を書いておかないと、新しいスクリーンで rbenv の設定が読み込まれない。

ところが、Debian 系が用意している .bashrc には非対話で呼ばれた時に、後ろの設定を無視するコードが入っている。これは sudo で呼び出した時に rbenv の設定が読み込まれず困る。よって、設定を書くなら、.bashrc の最初に書くのが良い。というのが、今のぼくの結論。

export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"

ruby-build のインストール

最近の ruby-build は ~/.rbenv/plugins ディレクトリー下に入れるのが主流らしい。

$ mkdir -p ~/.rbenv/plugins
$ git clone git://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build

ruby と bundle のインストール

ruby をインストールする。

$ rbenv install -l
$ rbenv install 2.1.1
$ rbenv global 2.1.1
$ rbenv rehash

bundle もインストール。

$ rbenv exec gem install bundle --no-ri --no-rdoc

あとがき

rbenv の設定ファイルの書き方にハマったので説明を加えたのと、ruby-build のインストール方法が変わったので記事を書き直した。bundle を gem install bundle するのと rbenv exec gem install bundle するので、どう違いがあるのか実は分かっていない ^^;

2014-04-01

ChatWork に入社しました

2014-04-01 (火)、本日よりチャットワーク (ChatWork) 株式会社に入社した。チャットワーク社は「チャットワーク」というサービスを運営している。サービスとしては、Skype や LINE らと同種の「チャット」サービス。企業でも使える「使い勝手」「安心感」が本サービスの売りか。

退職前夜

前職アクトインディで iPhone アプリを開発していたことは、昨日の記事で書いた。

実を言えば、ヘッドハンティング的なお誘いは数件来ていた。でも、iPhone アプリを開発していた時のぼくは、その誘いを断っていた。iPhone アプリ開発は決して楽しいことばかりじゃなかったけど、少しずつ改良されていく手応え、整っていく開発体制、何より一から育てたアプリの成長を見るのが嬉しかった。

作っている作品の質が悪くないことは自分が分かっていた。

認知率は低かったけれど、一つきっかけさえ在れば... という思いがあった。

そして運命の 11 月。隣でサービスを開発してたエンジニアが、メールで送られた「アプリ開発中止」の知らせを教えてくれた。心に穴が開いた。

その後、何度か保守目的で iPhone アプリのソースコードをいじった。

楽しかった。

iOS アプリの開発をしたい。

思いが強くなった。

転職活動をしてみた。

数社当たったところで、仕事の方が忙しくなり転職活動はなりを潜めた。それが去年の末のこと。

ChatWork との出会い

1 月に入って、ChatWork から連絡が入った。昨年末に面接を受けた結果だった。

驚いたことに面接に受かっていた。

次は二次。

ChatWork では二日間の体験入社を経てスキルと人柄とのマッチングを見る。初日午前中はセッティングや会社概要の説明ビデオ。そしてランチ。ゲストは食事が食べられない、と恐れられるランチ。エンジニア陣に囲まれて質問を受けながら食事を食べる。この時、用意されたお弁当を間違えて取ってしまったのはここだけの話。内容は、現職 (アクトインディ)、前職 (JVC ケンウッド) に及び、Emacs 使い・Dvorak 配列・T-Code と脇道に逸れたり、組み込み系のプログラミングの話に喰いつく人があったり、とこちらも随分楽しむランチとなった。もちろん、お弁当も完食。

午後からはプログラミング実習。課題を出されて、コーディングをする。そのリポジトリー名を見てひっくり返った。「deep-dive」。深く潜る者。

ぼくは...何をした? ランチでとてつもなくハードルを高くしてしまったらしい。

社内の雰囲気は良かったけれど、外は危険な天気となっていった。

いや、マジで。

体験入社二日目は 2014-02-14 (金)。あの東京大降雪の日。ChatWork に向かって電車に乗ったところ、一駅も進まない内に電話が鳴った。

「今日の体験入社はリモート作業でお願いします」

ですよね〜。

雪のおかげで、お昼に出かけるのも大変だったし、自作プログラムのプレゼンテーション時間が早まったりしたしで困った。今だから言うけれど、プレゼンが終わった後、落ちたと思ってほうけてた。「YES」という答えが信じられなかった。

最終面接を経て、ChatWork への転職が決まった。

あとがき

体験入社二日間。これはとても面白い試みだった。実際に社内に入って、仕事をしている姿を見せる・見る。ぼくもこれならば... と思えた。ChatWork もぼくを採ってくれた。

今、自分の実力を見るに、まだ経験値が低い。ちょっと作りたいアプリもあることだし、自作アプリも作って経験を増やしたい。願わくば、人がワクワクできるアプリを会社でも個人でも作っていきたい。

アクトインディの面白制度

2014-03-31 (月) をもってアクトインディ株式会社を退職した。半年で社員数が 3 倍に増える激動の一年を過ごせたことをありがたく思う。

さて、アクトインディで残念だと思ったことがある。それは、自分達のマーケティングが下手なこと。例えば、エンジニアの募集をする。募集要項を書く。その募集要項が他社と比べて魅力的に見えない。拙い筆ではあるけれど、アクトインディの面白い制度・便利な制度を紹介するとともに、ぼく自身のコメントも加えてみたい。

エンジニア向け制度

自宅勤務 (リモート作業) 制度

週に最大 2 回、自宅で作業できる制度。周りとの連携を考えて、大抵その週の初めに申請を行なう。もちろん、会社に出る方が効率の良い場合は、自宅勤務する権利を使わなくても良い。

ぼくは、この制度を少し変型させて、ゴールデン・ウィークに利用させてもらったりもした。お蔭で、普通の人より長期の帰省をすることができた。帰省先でも仕事が出来る仕組みは有難いものだった。

リモート作業については、過去に一つ記事を書いているので、そちらも参照して欲しい。

ちなみに、現在はママさんデザイナーが一人社員に居て、その方は週 4 程の自宅勤務をしている。

最新の Ruby と Rails

サービスの開発は Ruby on Rails を使っている。この場合、Rails が枯れてきてからアップデートする派と、常に最新を追っている派に別れる。アクトインディは後者で、Ruby も一早く 2.0 を採用したし、今は 2.1 系に移行している。Rails も 4.1 系へ移行が進んでいる。

チケット駆動開発

Redmine にチケットを登録し、マイルストーンを管理している。

Redmine を使うと、どうしても「ウォッチャー」のメールが大量に飛ぶことになるけど、その解決策をぼくは見出せなかった。とはいえ、「チケットにない作業は闇作業」という文化は根づいているので、混乱は小さい。編集・営業・デザイナーといった人達も Redmine を使ってチケット起票してくれる文化が育っている ((プログラマーだけしか Redmine を使っていないのと、周りの人達全員が Redmine を使っているのとでは、随分と作業効率違うよね)。

テスト・ファースト

テスト駆動開発を採用している。

シナリオ系のテストは少ないかな? モデル系のテストはほぼ書いている。

Github フローとレビュー

チケットに対して 1 つのトピック・ブランチが作られ、trunk ブランチに取り込まれる際にレビューを受ける仕組みが出来ている。

これは最初のトライ。レビューはほぼほぼ良い感じに動いている。レビューを取り入れが前までは git flow を使っていたけれど、今は Github フローに変えようか... と移行作業中。

技術書購入

月三万円までエンジニアで技術書を購入できる。

この制度は、デザイナーさんも含んでいるのかな? ちょっと覚えていないや。

出勤時間の自由化

一応、コア・タイムはある。でも、コア・タイムは短め (10:00-15:00 だったかな?) で、8 時間働けるなら何時に出社しても構わない。ただし、事前に「何時に出社する」という約束をする必要はある。フレックス制度というよりも、社員一人一人に対して会社が出社時間の契約をしている感じ。

ぼくは、朝 7 時出社の 16 時退社で働いていた。会社から家まで遠いのと、田園都市線の (有名な) 混雑を避けるのを考えたら、出社時間がこんなになってしまった。朝型のぼくにはありがたい制度だった。もちろん、会社では一番出社。何故か掃除のおじさんと仲良くなってしまった。

定時退社する日に限って、帰りの電車の遅延に巻き込まれるジンクスあり。ちょっち涙。

リスペクト手当て

4 か月に一回、尊敬・感謝の言葉を伝える制度。ネガティブなことは書かないのがルール。コメントは匿名で対象者に知らされる。

言葉を伝えると伴にポイントも渡せる。持ちポイントは 1 人 100 ポイント。1 人に 100 ポイント上げても良いし、適当に配分しても構わない。ポイントに対してその期の業積に応じた手当給が付く。

部門間を越えた 360 度評価と言っても良いかもしれない。

人数が 10 人前後だった時は、とても良い制度だった。考えるコメントの数も 10 個で良かったし (書く書かないは個人の自由)、ポイント配分も楽だった。100 ポイントを 10 で割れば 10 ポイント。特にお世話になった人に 20 ポイント、その他の人は 5 ポイント... という風に傾斜を付け易かった。

人数が 30 人に増えると大変。30 人分のコメントを書くのは一仕事。コメントする言葉が見つからない人も出てきてしまった。そもそも仕事で絡まないと、リスペクトも何もない。ポイントも 100 ポイントを 30 で割ると 1 人頭 3 ポイント。傾斜を付けつつ、全員にポイントを上げようとすると、1 ポイントしか上げられない人とか出てきちゃった。

それでも、この制度。ポイントはなくても良いから、メッセージだけでも貰いたい・あげたい、という程人気だったりする。ぼく自身、部門を越えたメッセージをもらうと元気が出た。なくならないで欲しい制度だけど、一工夫必要な仕組みだとぼくは思っている。

お墓参り手当

アクトインディでは先祖・先達への感謝を大事にしている。墓参りもその一つ。

最近、墓参りに行く若者が減ってきたということもあり、こういう制度は面白いと思う。基本、自己申告制だけど、多くの人は、墓参りの様子を Yammer などに投稿している。そこから、墓参りの地方による違いなどに話題が広がったことも。

カフェ手当

作業環境を変えたい人向けの制度。忘れられた制度。

新しいオフィスになって、一人で立ち作業できるオシャレな空間が用意された。作業環境を変えたい人は、カフェなどに行かず、スタンディング・テーブルで作業している。

あとがき

以上、アクトインディの面白制度を紹介してみた。同じ制度を導入している会社もあると思うけど、こんな制度もあるのか。うちも取り入れてみようかな? なんて考えてくれたなら嬉しい。