Wondershake 開発者ブログ

LOCARI(ロカリ)の運営会社の開発者ブログです。

色の基礎知識と配色のコツ

この記事は Wondershake Advent Calendar 2016 15日目の記事です。

自分について

学生でデザイナーのアルバイトをしている板部良平です。これまでにはイラストレーション、グラフィックスデザイン、映像をやっていて、今でも定期的に映像編集の仕事もしてます。専門は3DCGのキャラクターアニメーションです。未熟ですがよろしくお願いします。

なぜこのテーマか

  • 今後Locariをリニューアルする際、色にも統一性を持たせたデザインが必要
  • 開発メンバーはエンジニアの方が大半ですが、感覚や先天的な才能だと思われがちな配色も知識があればサイドプロジェクトや趣味等でデザインをする際にも役に立つ

と思い取り上げました。

色の力

そもそも色ってどんな効果があるの?ということで、色を利用したデザインの例をいくつか挙げてみます。

映像の例

PIXARではスクリーン全体の色によって視聴者に与える感情をデザインしています。

ROYGBIV: A Pixar Supercut from Rishi Kaneria on Vimeo.

例えば、蛍光色的な緑を使い視聴者に不安な印象を与えています。PIXARではこの様な色の使い分けが全ての人間の本質に訴えるものだと信じられています。監督やディレクターにより多少異なりますがアニメーションに限らず他の実写映画などでも基本的に同じようなカラー表現が使われています。(もちろん人々の感情を変化させる要素は色だけでは無く、複数の要素を組み合わせることで乗算的に効果を引き出されます。)

Webサイトの例

医療系のサイトでは白をメインに緑や青のアクセントを使い清潔的なイメージを持たせるところが多いです。
MedicalNote
f:id:ryohei_itabe:20161214181615p:plain:w300
Dr.Note
f:id:ryohei_itabe:20161215010112p:plain:w300
MYCODE
f:id:ryohei_itabe:20161215010117p:plain:w300

ちなみに実際の病院では院内の壁を淡いピンク色にしてリラックスできるようにデザインしているところもあります。(真っ白だと逆に恐怖感を与えるようです。)


色は人の感情的部分に訴えることが出来る効果的なツールとして役割を果たしています。

今回必要な色の基礎知識

覚えておくべき知識はたくさんありますが今回使わないものは省略します。 今回大切なのは、色には明度、彩度、色相の3つのパラメーターがあることです。
f:id:ryohei_itabe:20161215043132p:plain:w300
明度は明るさの度合い
彩度は鮮やかさの度合い
色相は色の種類
まずその3つを頭の隅に置いておいてください。

色は相対的なもの

色には絶対的なパラメーター(#fefefeやR255,G100,B30など)がありますが、それと人間が実際に目で見て頭の中で認識する色は異なります。付近にある色によってその色の認識のされ方も変わるということです。この色は相対的なものという考え方は、重要なのでこれも覚えておいてください。後ほど説明

実際に配色する際のコツ(基本)

使用する色同士の力関係(バランス)を考える

先ほど述べたように色には色相、明度、彩度の3つのパラメーターがあります。
f:id:ryohei_itabe:20161215043132p:plain:w300
彩度が高いものが色として一番強い力を持ちます。最強です。このレベルの色をいくつも使うと色同士が激しくぶつかり合い喧嘩してしまう為、見た目もうるさく良くありません。複数の色を使用する際は全体のバランスを考えます。

みんなが主役にはなれないので色にもサポート役が必要です。サポート役は主役との間にコントラストを作り出して主役を立てます。 コントラストの種類は4つあります。
1. 明度のコントラスト(明るいと暗い)
2. 彩度のコントラスト(鮮やかと鮮やかじゃ無い)
3. 色相のコントラスト(緑と赤など)
4. 面積のコントラスト(大きいと小さい)


バランスを保ちつつ明度、彩度、色相コントラストを意識する

f:id:ryohei_itabe:20161215050345p:plain:w300
今回は例として上の画像を調整します。 どれも主役になりうるポテンシャルを持った色たちですが今回は左端の赤を主役に決めました。左の赤を彩度が一番高いものにする為にサポートの右二つの彩度と明度を落とします。色数が多い為、真ん中は彩度を無くしたグレーにし、右端は主役を立てる反対色の鮮やかさの無い青にします。

f:id:ryohei_itabe:20161215050347p:plain:w300
これにより先ほどくすんでいた赤も他の色のサポートにより綺麗に輝いてくれます。これが色の相対性です。
多数の色を使用するとあらゆる方向にベクトルが散らばってしまいとまとめるのが大変になるので、出来るだけ使用する色を限定するのが色を綺麗にまとめるコツです。

面積のコントラストを意識する

デザインに注目させる意図がある際はさらに面積のコントラストを調整する必要があります。主役の強い力を持つ色は面積がある程度小さければアクセントとなり、人々の目に止まるようになります。
f:id:ryohei_itabe:20161215102828p:plain:w300
アクセントにしたい色は面積が大きくなりすぎないように注意してください。アクセントとしての効果が無くなります。

暖色と寒色による色相のコントラスト(応用)

明度、彩度のコントラスト以外に色相(寒色と暖色)のコントラストをうまく使うことで、デザインが引き締まり深みのある魅力的な配色となります。世の中の素晴らしいデザインの多くにはこのテクニックが使われています。

現実世界での例

f:id:ryohei_itabe:20161215021549j:plain:w300
写真のストレージから掘り起こした1年前に僕が撮った夕日の写真です。夕日や朝日に人々を魅了する美しさがあるのは、明暗彩度のコントラストに加えて色相(寒色暖色)のコントラストがあるというのが一つの要因です。余談ですが君の名は。新海誠さんの作品には殆どのシーンにこの青→ピンク→オレンジの色相(寒色暖色)のコントラストが使われています。

絵画やイラストの例

f:id:ryohei_itabe:20161215020115j:plain:w300
f:id:ryohei_itabe:20161215020119j:plain:w300
© disney. all rights reserved
フェルメール真珠の耳飾りの少女スターウォーズフォースの覚醒のポスター絵は作られた年代が全く違うのですが、どちらも明暗彩度のコントラストと色相(寒色暖色)のコントラストが上手く取り入れられていています。
f:id:ryohei_itabe:20161215021713j:plain:w300
ゴッホの絵でもよく使われています。全体の7割ほど占めるくすんだ青のおかげでヒゲの鮮やかなオレンジが際立って見えます。

アプリの例

f:id:ryohei_itabe:20161215013124p:plain:w300
Musicは音符内の水色とピンクがコントラストになっています。Safariは文字盤の青とコンパスの針の赤が大きなコントラストになっています。

写真などで逆に締まりのあるパキッとしたデザインでは無くほんわかしたムードにしたい場合でも、明度彩度か色相のコントラストのどちらかは残すように意識した方が良いです。もしコントラストが殆ど無いデザインだった場合、単体では掴み所の無いためにそのデザインを眺める時間が減ったり、印象に残りづらかったりします。


綺麗なグラデーションの作り方

プロデザイナー向けSNSのdribbbleなど見ていてもグラデーションを美しく使った作品が多いです。 グラデーションは下手すると初心者感がモロに出てしまうため扱うのは難しいですが、綺麗にグラデーションがハマると透明感のある美しいデザインになります。寒色と暖色のコントラストを意識することで美しいグラデーションを作ることができます。

  1. 元の色から少し明度をずらす
  2. 元の色を見て寒色よりか暖色よりかに色相を少しずらす

f:id:ryohei_itabe:20161215025356p:plain:w300
先ほど紹介したSafariですが、実はもう一つ寒色と暖色のコントラストが使われている部分がありました。 コンパスの文字盤の部分は同じ青系統によるグラデーションですが、ただ単に明度の違うグラデーションではありません。上から下にかけて黄色寄りの暖色系の青から原色の青の方へと変化しています。

このように赤は暖色!青は寒色!と決まっているわけではありません。一番重要な概念色は相対的なものなので、片方と比較してもう片方はどうなのかで色の性質が変わります。
f:id:ryohei_itabe:20161215034852j:plain:w300
この犬がどちらも同じ色という目の錯覚の画像を見てもらえば色が相対的なことを理解して貰えるかと思います。周りの色によって決まります。

配色に便利なウェブサービス

ここまでのことが理解出来れば便利なカラーパレットサービスも正しく使えるようになります!

カラーパレットサービスというのはネット上にたくさんありますが、色に関する知識が無ければあれらのサービスは応用するのは難しいです。バランスとコントラストを意識すればカラーパレットも思うままに使えるようになるでしょう。 ウェブサービスたくさんありますので、主要なものを2つだけ載せておきます。

Coolors
f:id:ryohei_itabe:20161214192720p:plain:w300
Adobe Color CC
f:id:ryohei_itabe:20161214192722p:plain:w300
基本的にどのサービスもパレットには5、6色もありますが、全てを使い切る必要はありません。多すぎる場合は任意で減らして使いましょう。

まとめ

実際に使おうとしてもすぐには上手く行かないかもしれませんが、少しでもお役に立てれば光栄です。配色する際はバランスとコントラストを忘れずに。

明日はデザイナーの先輩のこけしさんです!よろしくお願いします。

LocariとOpsworks

この記事は Wondershake Advent Calendar 2016 14日目の記事です。

ワンダーシェイクのインフラエンジニアの@whiteray_19です。

Locariでは、最近 Opsworks を利用し始めたので、それについて書きたいと思います

はじめに

Locariでは、Batch, Job, API/Web サーバ群を扱っており、
各サーバの bootstrapping, provisioning は knife-solo を利用していました。

Opsworks 以前は、 API/Web に対して、EC2 autoscaling を利用し、
ロード、スケジュールに応じたスケール イン / アウトを行っており、
あらかじめ想定される負荷に対しては、しっかり対応できていました。

一方で、autoscaling で利用するAMIの変更管理だったり、
Jobサーバのスケールアウトや、Batchサーバのメンテナンスのやりにくさがありました。

他にも、アプリケーションのデプロイはCapistrano を利用していたのですが、
Capistrano の バージョンアップに追従するのが比較的大変で、
デプロイ整備に注力するならアプリケーション開発に集中したい


インフラはコード化されてるといっても、
コマンド実行でサーバを立てるより、GUIから操作できた方が楽だし、わかりやすいよね

というような経緯があり、Opsworks移行が始まりました。


状況は改善されたのか

Jobサーバのスケールアウトについて

Opsworks の GUIからクリック一発でサーバを提供できるようになりました

素敵。

Batchサーバのメンテナンスについて

こちらも同様、Opsworks の GUIからクリック一発でサーバを提供できるようになりました

少し脱線しますが、

新規に立てたサーバに対して、メンテナンスを施し、新旧入れ替える運用ができるようになり、
Immutable Infrastructure 的な考えが組み込めるのはうれしいところです。

autoscaling について

Opsworks の autoscaling は EC2 autoscaling と 異なり、少し使いにくい部分があります。
ですが、Locariは比較的ピークタイムがわかりやすいサービスなので、
負荷設計を行い、 Opsworks の Timebase autoscaling を利用することにしました

移行前より、autoscaling の柔軟さはなくなってしまいましたが、
イメージ管理がなくなり、逆にメンテナンスコストは下がったと思います

デプロイについて

Capistrano で行っていることを、chef に変更し、
こちらもクリック一発でデプロイができるようになりました。


blue green deployment の採用

LocariではRack webサーバとして、 unicorn を利用しているのですが、
高負荷時にデプロイを行うと、新旧のプロセスが共存し、CPU負荷が上がってしまい、
一時的にサービス提供できない時間が存在してしまっていました。
それを解決する方法として、
Layer層の blue green deployment を採用することにしました。

blue green deploy を 実装する方法は様々あると思いますが、
Locariでは、Opsworksだけでなく、EC2、ELBが提供している
APIを素直に組み合わせて、運用ツールを作成しています


移行についてのハードル

  • Opsworks 用に chef recipe を改修するのが大変。
  • Capistrano で行っているデプロイを chef recipe として、作成するのが大変
  • Opsworks上での chef recipe のデバッグが結構大変

結構大変なことがありました笑


Opsworks 運用の感想

やはり、GUIの操作だけで、サーバの調達から提供まで行えることはうれしいところです。

また、開発のメイン言語が ruby であることもあり、
chefをプロビジョニングツールとして採用しているOpsworksは相性が良かったです

最近では、chef automateも提供されたので、
ぜひ試してみたいものです。

明日はいたべさんの記事です!
お楽しみに!

asdfって知ってる?色んな言語のバージョン管理が出来ます!

この記事は Wondershake Advent Calendar 2016 13日目の記事です。

ワンダーシェイクのバックエンドエンジニアの@dykstraです。

今回はasdf version managerを紹介したいと思います。

asdfとは?

asdfはバージョン管理ツールです。RubyとElixirのコミュニティーでオープンソースに貢献している@HashNukeさんが作りました。 Rubyrvmrbenv のようなツールで、非常に導入しやすいツールなので、色んな言語にasdfを使えます!

なぜ他のバージョン管理ツールよりasdf使う?

使い方は本当にシンプルです。色んな言語で使えるので、他のバージョン管理ツールのようにそれぞれの言語管理ツールを使うのが通常ですが、asdfなコマンドが同じなので、asdfだけですべての言語のバージョン管理をすることができます。Toolingがいい言語(例えば、Ruby)だけ使ってたら、asdfに乗り換える必要がないと思いますが、tooling良くない言語使っていたり、同じサーバーに色んな言語を使っている場合は、asdf使えば、言語アップグレードする時にとても便利になります。この記事書いてる時点で、既に以下の20の言語がasdfでバージョン管理出来ます。

簡単に、どうやって使う?

  1. asdfインストールして、設定します。 https://github.com/asdf-vm/asdf
  2. asdf plugin-add <言語名> <git-url> (git_urlはここで見つけれます)
  3. インストールしたいバージョンを探します。 asdf list-all <言語名>
  4. そのバージョンをインストールします。 asdf install <言語名> <バージョン>
  5. グローバルでバージョンを設定します。 asdf global <言語名> <バージョン>
  6. プロジェクトのバージョンを設定します。(ホームディレクトリからこのコマンドやったほうがいいです) asdf local <言語名> <バージョン> (なかったら、$PWD/.tool-versions作ります)

すごく簡単ですね!もし操作がわからなくなっても、 asdf -h をすれば、コマンドの説明が詳しく表示されます。

僕の好きな言語のプラグインはない!どうする?

新しい言語を導入したい場合は、asdfのplugin APIで作ればすぐ使えます。

まとめ

開発に専念するためには、バージョン管理のことで時間を使いたくないですよね。asdfなら一つのツールで全部の言語のバージョン管理が出来るので時間の節約になり、エンジニア間のミスコミュニケーションもふせぐことができます。是非、asdfを使ってみてください!

明日はインフラのエンジニアつかださん書きます!ネタはまだ秘密なんですけど、楽しみにしてます!

Ruby の Refinements 使ってみた

この投稿は Wondershake Advent Calendar 2016 12日目の記事です。

mmyoji です。今日含めてあと3回、がんばります。

今日は Ruby の Refinements について、「こんな感じで使ってますよー」という紹介をできればと思います。

簡単にいうとクラスを「特定の箇所(ファイル)でだけ拡張したい時」に使うもの、と思っていただければいいと思います。もっと詳しく知りたい方は最後に挙げてある References を確認していただけると理解がしやすいかと思います。

自分も最近ようやく使ってみた、という感じなのでこれが適切な使い方なのかは怪しいです。。。ただ使ってみてかなり「気持ちよかった」のでやっぱり Ruby は最高ですね。最高です(大事なことなので(ry

具体例

LOCARI の記事1つ1つに対して、ライターが一人いて、それを記事一覧で表示するんですが、記事の状態などに応じて出し分けをする必要があります。その ライターの情報Post::ListProfile というクラスで表現するようにしていて、そのプロフィールに種類があります。

ListProfile を特定するために記事の状態をチェックする必要がありますが、そこでしか使われないため、単に記事クラス( Post )にメソッドを生やしたくない、と思い、 Refinements を使ってスコープを制限しました

(以下微妙に実際のクラス名、メソッド名とは異なります)

# app/models/post.rb
# 記事クラス
class Post < ApplicationRecord
  # ...
end

# app/models/post/list_profile_detector.rb
# 記事を元にライター情報を特定するクラス
class Post::ListProfileDetector
  attr_reader :post

  def initialize(post)
    @post = post
  end

  def call
    if post.show_username?
      return Post::ListProfile::External.new(post)
    end

    if post.shared?
      return Post::ListProfile::Shared.new(post)
    end

    if post.default?
      return Post::ListProfile::Default.new(post)
    end

    Post::ListProfile::Official.new(post)
  end
end


# こんな感じで使う
post    = Post.find(12)
profile = Post::ListProfileDetector.new(post).call
#=> #<Post::ListProfile::Default:0x007f983e757550

上記の ListProfileDetector 内で使った post に生えているメソッドを Refinements を使って定義します

# app/models/post/list_profile/detectable.rb

module Post::ListProfile::Detectable
  refine ::Post do
    def show_username?
      # ...
    end

    def shared?
      # ...
    end

    def default?
      # ...
    end
  end
end

簡単ですね 😁

で、実は Post::ListProfileDetector には足りていない行があったので一行追加します

# app/models/post/list_profile_detector.rb

class Post::ListProfileDetector
  # `using` で refine を使う宣言をする
  using Post::ListProfile::Detectable

  attr_reader :post

  # ...
end

これで一応は使えるようになりました。今度はテストです。

Post::ListProfileDetector はそのままテストを書いて問題ないですが、 Detectable モジュールはどうテストしましょう?(そんなに難しいものではないですが 😅 )

# spec/models/post/list_profile/detectable_spec.rb

require 'rails_helper'

describe Post::ListProfile::Detectable do
  ## これがないと有効にならない! ##
  using Post::ListProfile::Detectable

  let(:post) { create(:post) }

  describe '#show_username?' do
    # いつものように example を書く
  end
end

Refinements は ファイル毎 にスコープを指定するため、メソッド呼び出しを行いたい場合は各ファイルで using を宣言する必要があるため、テストでも上記のようにする必要があります。

気づいてないだけで意外と使えるところはたくさんあるのかなーと思うので、これからもガシガシ使っていきたいですね!

以上になります。明日は Eric さんがリモート以外のテーマで何か書いてくれるみたいです。楽しみ 😁 ❤️

References

デザイナーのリモート事情

こんにちは、業務委託でお世話になっておりますデザイナーのこけしです。(本名は長谷部えりです) この記事は Wondershake Advent Calendar 2016 の8日目の記事です。

普段はフリーランスとしてフラフラと出歩いていますが、アドベントカレンダーに参加させていただきました。 リモート記事が続いてネタに困りだすけど、私デザイナーなので楽勝だぜ!という雰囲気でお送りします。

話すこと

  • デザイナーの出勤/リモートの状況
  • リモート環境
  • リモート時にテンションを上げるには

Wondershakeデザイナーのリモート状況、あと私はリモート可の状況で働いている歴がおそらく短めだと思うので リモート初心者向けに、ゆる〜〜く自己流のリモート時のテンションの上げ方をお話します。

デザイナーの出社/リモートの状況

デザイナーもエンジニアと同様に出社は自由です。ミーティングがある日だけ出社でもOK。 でも私はなるべく出社したい派で、だいたい週2、3日くらいオフィスに出社させていただいています。

出社理由としては以下の通りです。

個人的な理由

  • 自宅に居すぎると気が滅入るタイプ
  • 太った(⌒▽⌒)(ので少しでも外に出たい)

仕事的な理由

  • デザインの目的確認のための細かいすり合わせがしやすい
  • 微妙なデザインの修正など口頭の方が早い場合がある(1pxつめて、とかとか)

とはいえ仕事的な理由はリモートでもカバーできると思うので、個人的な理由のほうが強いです。

リモートをする場合は集中して手を動かしたいとき、 または体調や家庭の事情で自宅に居たいときにしています。

もちろんデザイナーチームとしてもリモートはだめだとかそういう風潮もなく、 都合に合わせてのびのびとお仕事をさせていただいています。

リモート環境

PCはいろいろなところで作業することが多いのでMBP Retina 13inchを使っています。 自宅ではLGの27inchモニターを使ってデュアルディスプレイ化しています。

常に机の上が汚い・綺麗なデザイナーは優秀かどうかという議論がありますが 自宅の机はもっぱら汚い派です。ものがたくさんあります。 多分このまま生きていくのだと思います。

机や椅子は全くこだわってなくて両方ともIKEAの一番安いものを使っています。 椅子は変えたいのでamyroiさんの記事を参考にさせていただこうと思います!

リモート時にテンションを上げるには

自分は今年度からフリーランスになったので、最初自分のペースを作るのに四苦八苦しました。(未だにしてますがorz) リモート初心者向けに、いろいろ試してみてよかったなと思うもの、作業時にテンションを上げられる方法を話してみます。

  • 朝、動いてから仕事する
  • 仕事のスイッチを決める
  • ちゃんと休む
  • 作業のおしりは決めておく

朝、動いてから仕事をする

実践されている方が多いかもですが、家で仕事をする場合なにかしら動いてからやります。 洗濯物を干すのが好きなので、やるついでにおひさまを浴びてほっこりしてから仕事します。 健康な人間になった気がしてとても良いです(⌒▽⌒)

仕事のスイッチを決める

自分の場合、仕事するぞ!と意気込んで机に向かうタイプなので仕事を始める際に絶対にコーヒーを入れています。 これがスイッチになって集中できるし、メールやslackをチェックしながらコーヒーをいただくととっても優雅で自分がおしゃれだと錯覚できます(⌒▽⌒)

ちゃんと休む

リモートの最大メリットは、"自宅で自分のペースで仕事ができること"だと思っています。 そのため集中力切れたなー、単純作業眠いなーとなるとしっかり休憩します。 最近は「絶対に好きにならないぞ!」と思っていた星野源にハマっているのでYoutubeをでかでかと流して気分転換もしています(⌒▽⌒)

作業のおしりは決めておく

私は家庭の事情で8時前後くらいにはなんとなく夕ご飯な感じになります。 トラブルなど、どうしても急を要する作業でない場合はそこに合わせて仕事をやめるようにしています。 ちゃんと終わらせればお酒が最高にうまいぞー!と思うとダレないし、がんばれます(⌒▽⌒)これが一番だいじ。

また、細かい時間管理は皆さんやっているポモドーロも試しましたが、集中しているとアラーム音にびっくりするのでやめました。 基本的にちゃんとスタートできれば自分の意欲任せで案外いけています。

結構よくある内容になっちゃいました。でも当たり前のことを当たり前にできないとかなって思います。(どや?)

さいごに

明日はyosuke_kabutoさんのリモートについて北海道編です。 作業の途中でサッポロビール飲んじゃうとかかな?(すごく勝手なイメージ)楽しみです!

Wondershakeエンジニアのリモートワーク

こんにちは。佐々木です。
この記事は Wondershake Advent Calendar 2016 の5日目の記事です。
今週はリモートワークネタが続くようで、その2日目になります。

リモートネタ1日目のmmyojiさんの記事はこちら。

engineering.wondershake.com

この記事では普段私がどんな感じで働いているかを紹介します。

私の働き方

WondershakeではフルリモートワークOKな環境なので、ミーティングがある木曜日以外は基本的に家で作業しています。

実装レベルのタスクは Pivotal Tracker で管理されていて、1日の始まりにチケット一覧を眺めながら優先度の高いタスクを消化していく形です。
このチケットの優先順位を決めるミーティングが木曜に行われています。

開発フロー的には Github Flow が近いです。 チケット毎にブランチを作り、作業途中のものであっても1日の終りにはWIPを付けてpushします。

コミュニケーションツールにはSlackを使っていて、Githubの通知を通知専用のチャンネルに垂れ流すことであの人は今こんなことをやってるんだと分かるのが良いです。

自宅の作業環境

f:id:sskyu:20161205021019j:plain

参考までに自宅の作業環境をご紹介。

  • 椅子
    • Meda Chair
      • 座面が広くてあぐらしやすい
    • fantoni GT W140
      • 堅牢で揺れないし拡張性もあり良い
  • PC
    • MBP 15inch, 2014 Mid
  • 外部ディスプレイ
    • Dell 24inch FHD Display
      • 解像度足りないので買い替えたい
    • ♀ 2015/8/15 生まれ
    • 作業中に椅子の後ろをガリガリして邪魔してくる

とある1日のタイムスケジュール

午前中は仕事をしません。いつもギリギリまで寝てるか読書などしてます。
私の場合は夜のほうがパフォーマンスが出るので十分な睡眠をとって、仕事中に眠くならないようにしてます。
下手に早起きして睡眠不足で仕事を始めても集中できないし、思考にモヤがかかった状態で作業するとバグを含めるリスクもあります。
大体10時過ぎに起きて、12時頃に昼ごはんを食べます。 13時前後に仕事を開始して、21時前後に上がります。

ポモドーロテクニック

自分のパフォーマンスを測る目安としてポモドーロテクニックを使っています。
25分仕事して5分休憩を1ポモドーロとして、4ポモドーロ毎に15分休憩をとるやり方です。
私の場合、1日の集中が続く限界が14ポモドーロくらいで、12ポモドーロで結構な疲労を感じ、8~11ポモドーロだと無理なく仕事した感が得られるので、このあたりを目安に作業をしています。

Macアプリにはこちらを使ってます。

Be Focused Pro - 仕事および勉強用の Focus Timer を Mac App Store で

オフィスにある仕事用Macと自宅のMacでTODOを共有できたり、メニューバーに常駐して使い勝手が良く気に入ってますが、休憩時間になったことに気づかないことが多いのが難点です。
(ポモドーロタイマーをElectronで作りたいなぁ。)

Wondershakeでのリモートワーク

個人的にはリモートワーク最高なのですが、あえてメリット・デメリットを上げてみます。

メリット

  • 通勤時間がゼロになる
    • その分稼働時間にまわせて退社時間を早められる
  • 個人の裁量で働く時間を好きなように設定できる
    • 突然の用事にも柔軟に対応できる

デメリット

  • 存在感を出すのが難しい
    • 日報を書く、毎日コミットをpushしてやっていることをシェアする等を意識的にすると良いと思います
  • 運動不足になる
    • 平日はあまり運動しない+家でのリモートワークのコンボで運動不足になります
    • 結構深刻で、リモートワーク中の1日の歩数を数えたら1200歩前後でした..(1日8000歩が良いとされる)
      • 改善のためポモドーロの大休憩で散歩を取り入れてみます

おわりに

リモートワークによって時間に縛られず自由に働ける反面、自分を律して作業するためにポモドーロなどのルールが私には必要でした。
直近の課題は運動不足による身体の衰えを防ぐことです。

明日はamyroiさんで引き続きリモートワークネタです。楽しみ!

qiita.com

リモートワークで気をつけていること

この記事は Wondershake Advent Calendar 4日目の記事です

2日目に続き、 mmyoji がやっていきます。今日から一週間はなぜかリモートワーク話が続きます。

話すこと

  • Wondershake の労働環境(主にエンジニア)
  • リモートワークする上で気をつけていること

リモートワークの pros / cons 話そうかと思ったんですが散々話し尽くされているのでやめておきます。今回も短めです。

Wondershake の労働環境

開発者に限らず、全員がリモートワークをいつしてもおkな感じです。(たしか)

部署によっては上長の許可等必要かもしれませんが、少なくとも開発チームは特に許可を取る必要性はありません。

働く時間に関しても完全にフレックスとなっているので自由度は本当に高いです。僕はどちらかというと朝方なので早いときは6時ぐらいから仕事開始して昼過ぎぐらいには上がったりします。逆に夕方から働き始める方もいます。

僕は家がオフィスからそんなに近くないので基本リモートで仕事していて、ミーティングがある時だけオフィスに行ってます。(大体週1)

ただリモートワークもメリットばかりあるわけじゃないので、ある程度仕事回す上で自分が気をつけていることを以下ダラダラ書いておきます。

リモートワークで気をつけていること

  • プレゼンスを出す
  • 働きすぎない

プレゼンスを出す

要するに自己主張していきましょうということです。

ただでさえ「何やってるかわからない」と思われがちなので、 Slack には頻繁に顔を出すようにしたり、ウザいくらい github に push しまくって(もちろん常識の範囲内で)「俺ちゃんと生きてますよ」アピールをします。

これに関しては「オフィスに行ったら偉いの?」問題が絡んでくるのでリモートだからどうのこうの、という話ではなくお互いに気をつけるべきなのですが、未だにリモートワークしてる側が立場的に低いと感じるので仕方ないのかなーという気がしてます。逆にオフィスいる勢は何やってるか全然わからないので、苦しいところではあります。「リモートだから / オフィスに行ってるから」という不毛な対立関係がなく、お互いを尊重できる世界が早く来るといいなーと思ってます。

あと弊社は Qiita:Team を情報共有ツールとして導入しているのですが、そこに定期的にポエムを投げるようにしてます。 プレゼンスを出す、という意図のほかに、「Qiita:Team は日報を投稿するだけのツールじゃないんだよ」ということをアピールするためにもやってますが、まだ効果が出ていません。どんどん埋もれていきます。かなしみ

働きすぎない

(こんなこと書くとシメられそう)

これはフリーの時から共通して持ってた問題意識なんですが、時間を忘れて働きすぎてしまうのでそうならないように注意するようにしてます。

自分の場合早朝から仕事し始めるので、他のエンジニアと働く時間が割とずれます。なので夜遅くに Github が賑やかになってきて思わずつられて働きそうになるんですが、がんばってこらえてます。ここらへんは未だにさじ加減が難しいなぁと感じる部分です。

適度に休憩入れることも大事で、一時期ポモドーロを導入してました。が、自分は誰かに作業を中断されるのがかなり苦痛に感じるタイプだとわかって2~3ヶ月試した後やめました。

オフィスにいるとできないような方法で休憩を入れるようにしてます。カフェなどで仕事する場合は難しいんですが、家で仕事する日は筋トレしたり、ベースを弾いたり、散歩をしたりしてリフレッシュするようにしてます。オフィスにも筋トレ器具とかスタジオ欲しい...

ただでさえ日本人働きすぎなので1日8時間の労働で満足しましょうという話でした。

さいごに

明日はフロントエンドエンジニアの yutapon 氏です。多分 🐈 の話だろーなーと思ってます 😎