木曜の夜はもくテク!!(Misoca冬のLT大会のご案内)

こんにちは。 @KawamataRyo です。
最近、ダイエットも兼ねてボクシング🥊をはじめました。(Fit Boxingではなくリアルボクシング)
「良いコードは良い筋肉から」ということで、頑張って行きたいです。

f:id:ba068082:20190918113348p:plain

皆さん、もくテク はご存知ですか?
もくテク は弥生株式会社が1年以上主催している勉強会です。
10月にもMisoca主催の「秋のLT大会」を開催し好評でした。

今回その第二弾として、12月5日19:00よりの「もくテク powerd by Misoca 冬のLT大会」を東京、名古屋、松江会場にて開催します!!
(公募LT枠もあるので、どしどしご応募お待ちしてます!! )

mokuteku.connpass.com

この記事では、その告知としてMisocaエンジニアのLT内容をご紹介します。

Misoca LT枠テーマ一覧

Redash で作る「じぶんダッシュボード」 @mallowlabs

計測できないものは改善できない。
じぶんのパフォーマンスを可視化する仕組みを Redash で作ったのでそれを紹介します。
運動量や、体重や睡眠時間、心拍数、生産性などを一つのダッシュボードで見られるようにする仕組みの裏側について話します。

Slackワークフロー活用術 @kokuyouwind

Slackでワークフロービルダーが利用できるようになりました。
Misocaでも早速様々な作業でワークフローを活用しているので、事例やTipsを紹介していきたいと思います。

Androidで郵便番号から住所を得る @k0matatsu

iOSではCoreLocationという標準ライブラリで郵便番号から住所を取得できますが、Androidには標準で用意されたものがありません。
Google Map APIも使わずに郵便番号から住所を得る処理を書いたので、その経験を踏まえ郵便番号の仕組みから解説しようと思います。

サクッと理解 GraphQL 入門 @KawamataRyo

GraphQLは昨年ごろからよく聞くようになりましたね。
Misocaでも新機能開発でのGraphQL導入の機運が高まっています。
今回はそれに向けて個人で勉強した内容(主に「初めてのGraphQL*1」より)をGraphQL入門者向けにまとめて話したいと思います。
(当初Firebase 関連で考えてたのですが、テーマ定まらず変更しました..)

当日のスケジュール

公募LTの応募状況で前後しますが、大体このようなスケジュールで考えています

時間 内容
18:45〜19:00 受付
19:00〜19:10 会場説明・Misoca説明
19:10〜19:20 Misoca LT1
19:20〜19:30 Misoca LT2
19:30〜19:40 Misoca LT3
19:40〜19:50 Misoca LT4
19:50〜20:00 休憩
20:10〜20:20 公募 LT1
20:20〜20:30 公募 LT2
20:30〜20:40 公募 LT3
20:40〜20:50 公募 LT4
20:50〜21:30 懇親会

おわりに

いかがでしたしょうか?
最近話題のSlackワークフローのMisocaでの活用術からRedashでの自分ダッシュボードまでかなりバラエティに富んだ内容になっています。
イベントの詳細な情報はconnpassの募集ページ をご確認ください。
公募LT枠も絶賛募集中です!!(マジで応募頼むで!!🙏 )

会場は東京、名古屋、松江、またYouTubeでのLIVE配信も予定しています。

採用情報

Misocaでは、技術について語るのが大好きなエンジニアを募集しています。

recruit.misoca.jp

*1:O'Reilly Japan 発行 初めてのGraphQL ――Webサービスを作って学ぶ新世代API

認証機能のないアプリケーションでOAuth2認証を提供する - OAuth2 Proxy 編

こんにちは。Misoca 開発チームの eitoball です。先日、いびがわマラソン2019 を走ってきました。フルマラソンは2回目ですが、初めてサブ4(グロスで3時間55分、ネットで3時間47分)を達成しました!

はじめに

今回は、Webサイトへのアクセス制限に GitHub や Facebook の認証を簡単に使えるようにできる OAuth2 Proxy というソフトウェアの紹介です。

OAuth2 Proxy

この記事、https://tech.misoca.jp/entry/2015/04/07/145743 では、mod_auth_openidc という Apache のモジュールを利用して、ウェブサイトに認証機能を追加する方法を紹介しました。認証に使うサービスは、OpenID Connect Provider である必要があります。OAuth2 Proxy では、認証に使うサービスは、OAuth2 での認証を提供していれば、利用することができます。

OAuth2 Proxy は、リバースプロキシサーバーのように動作して、下の図の secured upstream http service で表現される認証をつけたいWebサイトの前段でリクエストを受けつけます。外部サービスで認証済みの場合は、リクエストを後段で動作しているWebサイトに渡して結果を返します。認証していない場合は認証用のページを表示します。

OAuth2 Proxy の前段に、Apache や Nginx などを置いて、SSLターミネーションとすることもできますし、OAuth2 Proxy が直接、SSLを使った通信をすることを可能です。

設定例

GitHub を使って、認証する例を説明します。

インストール

aptやrpmパッケージは提供されていないようです。そのため、https://github.com/pusher/oauth2_proxy/releases より、使用するオペレーティングシステムに応じたパッケージをダウンロード・解凍して、/usr/local/sbinoauth2_proxy というバイナリを配置します。

$ curl -L -o oauth2_proxy.tar.gz https://github.com/pusher/oauth2_proxy/releases/download/v4.0.0/oauth2_proxy-v4.0.0.linux-amd64.go1.12.1.tar.gz
$ tar xzf oauth2_proxy.tar.gz
$ sudo cp oauth2_proxy-v4.0.0.linux-amd64.go1.12.1/oauth2_proxy /usr/local/sbin/

GitHub 側の認証情報の取得

「OAuth Apps」で認証情報を設定します。組織の場合は、ダッシュボードページの「Settings」タブから「OAuth Apps」からアクセスできます。多分、http://github.com/organizations/<組織名>/settings/applications のようなURIになります。個人の場合は、ここ から設定できます。

「New OAuth App」ボタンをクリックして、「Application name」、「Homepage URL」、「Authorization callback URL」を指定します。「Authorization callback URL」には、「https://<開発サーバーのホスト名>/oauth2/callback」を指定します。指定したら「Register Application」ボタンを押して、設定を保存します。

New_OAuth_Application.png (144.3 kB)

OAuth2 Proxy の設定

以下のような内容を/usr/local/etc/oauth2_proxy.cfgとして配置します。

http_address = "127.0.0.1:4180" # OAuth2 Proxy のアドレスとポート

upstreams = [
  "http://127.0.0.1:3000/" # 認証情報を付与したいサーバーのURL
]

email_domains = [ 
  "*" # 今回はどんなメールアドレスも認証する
]

client_id = "<GitHubで設定したOAuth AppのクライアントID>"
client_secret = "<GitHubで設定したOAuth Appのクライアントシークレット>"

provider = "github"

github_org = "<認証したいGitHubのorganization>"

cookie_secret = "<クッキーの暗号化鍵>"

設定できる項目などについては、OAuth2 Proxy の Configuration を参照して下さい。

cookie_secret には、ruby -rsecurerandom -e'puts SecureRandom.base64(16)'python -c 'import os,base64; print base64.urlsafe_b64encode(os.urandom(16))' のようなコマンドを実行して生成するのがお勧めです。

後、OAuth2 Proxy が自動起動できるようにします。systemd を使っているので、以下のような内容を /etc/systemd/system/oauth2_proxy.serviceに配置します。

[Unit]
Description=OAuth2 Proxy

[Service]
Type=simple
User=root
ExecStart=/usr/local/sbin/oauth2_proxy -config=/usr/local/etc/oauth2_proxy.cfg

[Install]
WantedBy=multi-user.target

そして、以下のコマンドを実行して、設定の有効化とOAuth2 Proxyを起動をします。

$ sudo systemctl enable oauth2_proxy
$ sudo systemctl restart oauth2_proxy

Apache の設定

Apache 側では、mod_proxy モジュールを有効にして、OAuth2 Proxy のリバースプロキシとして設定します。以下のような設定をします。

<VirtualHost *:443>
  ServerAdmin admin@example.com
  DocumentRoot /var/www/html
  ServerName sugoi-server.example.com
  
  # SSL の設定
  
  ProxyPass / http://localhost:4180/
  ProxyPassReverse / http://localhost:4180/
  ProxyPreserveHost On
  ProxyRequests Off
</VirtualHost>

確認

Apache を再起動して、認証を設定したサイトにアクセスすると以下のような画面が出ると思います。

Sign_In.png (18.6 kB)

「Sign in with GitHub」ボタンを押すとGitHubでの認証画面が出るので、ログインとパスワードを入力すれば、サイトにアクセスできるはずです。

最後に

OAuth2 Proxy の紹介とそれを使って、認証機能のないWebサイトに簡単に認証を提供する方法を紹介しました。

Misoca では、このようなちょっとしたことに興味もあるソフトウェアエンジニアやサイトリライアビリティエンジニアを募集しています。

recruit.misoca.jp recruit.misoca.jp

アプリの新しい画面がどのように生まれたか

こんにちは、こまたつです。
先週リリースされたAndroid版Misocaにて請求書などの詳細を表示する画面のリニューアルを行いました。
あたらしい詳細画面で表示する内容は元の画面とほとんど変わりありませんが、より見やすく項目を整理しました。

今回はこのリニューアルの過程でどのように検討・決定してきたかを少しだけご紹介したいと思います。

抱えていた課題

昨年6月にアプリをリリースしてから、様々なアップデートや軽減税率への対応を経て請求書などの詳細情報を表示する画面(以下、詳細画面とします)は複雑度を増していました。

詳細画面はアプリのなかでも中心となる存在で、郵送・メール送信などの発行処理のほか、プレビューや複製などの多数の操作が行えます。
また軽減税率によって税率別の合計欄などが追加され、表示したい項目が非常に多く情報の優先度づけも困難を極めていました。

初期のバージョンは絶妙なバランスの上でなりたっており、ジェンガのように積み重なったアップデートで抜き差しならない状況になっていました。
これは新たな機能追加がしにくいだけでなく、はじめて使うユーザーがアプリを使いはじめるのを困難にしてしまっていると考えました。

どうあるべきか

Android版Misocaでは取引にまだあまり慣れていない層をメインターゲットに据えています。
ユーザーのITリテラシーは必ずしも高くはなく、なかには各項目の合計を電卓で検算したいという方もいます。
請求業務そのものも「やらなければいけないこと」であり、低いモチベーションでも間違いなく請求できる必要があります。

煩雑な画面はひと目でその学習コストの高さが伝わりモチベーションを削いでしまうので、よりシンプルな画面にする必要があると考えました。

問題提起と検討

新たな機能追加のタイミングで、現行バージョンが既に限界であることと議論の元とすべく改善案を提案しました。

f:id:komatatsu:20191107192124p:plain

これは使い方によって表示を切り替えられるようにした案です。
ここからどのような画面であるべきか、デザイナーと一緒に今あるものは抜きにして理想の姿を探しはじめます。

f:id:komatatsu:20191107192140p:plain f:id:komatatsu:20191107192150p:plain

これは数日後にデザイナーのみずのが出した検討案です。
この時点でほぼ原型ができています。

ほとんど同じタイミングでまるやまも検討案を作ってくれました。

f:id:komatatsu:20191107181542p:plain

どちらも値を右側に置くことでレシートに近い表現になっているのがわかります。
この配置によって大事な金額部分が目で追って確認しやすくなっています。
また現実世界に既に存在するものに似せることで、ユーザーの学習コストが抑えられます。
他にも取引先を確認しやすいように導線を追加したり、たくさんの工夫が詰め込まれています。

これらのいいとこ取りをしてベースの案ができたので、ここから表示のバリエーションも含めた検討にはいります。

変換先文書

f:id:komatatsu:20191107192207p:plain

これは変換先文書一覧という、複製機能で作成した文書一覧へのリンク位置を検討している様子です。
表示している文書との関連性や、他の導線との兼ね合い、表示の意味などで議論が白熱しました。

しかし調べてみると利用頻度が非常に低くく、白熱する議論に対してユーザーに与えられる価値が釣り合ってなさそうな事がわかりました。
このリストを代替できる機能もあるため、総合的に考えたうえで削除しようという判断になりました。*1

回収保証

f:id:komatatsu:20191107192217p:plain

これは回収保証という、売掛金の回収ができなくなった場合に損害を補填してくれるサービスのステータス表示です。
今までは最下部に表示されていましたが、合計欄が下にきたので最上部へ移動しました。
利用登録が済んでいる場合にしか表示されない*2うえ、健全な取引のためにぜひ使ってほしいサービスなので最上部に来ても違和感なく、満場一致でした。

最終的にどうなったか

f:id:komatatsu:20191107182028p:plain

日付などの項目が右側に揃っているので、視線移動が抑えられ迷いにくい配置になりました。
件名が強調され、情報の階層がわかりやすくなっています。
操作の必要な処理のうち利用頻度の高いものを下側に集めたので、多くのユースケースでスマホを持ち直さなくても片手で素早く目的が達成できます。
郵送などを行うステップ数がひとつ多くなっていますが、これは慎重に行うべき操作なのであまりネガティブな意見は出ませんでした。

これからのはなし

Android版Misocaではユーザーが本業に集中出来るよう、それ以外の部分をかんたんに手早く済ませられる状態を目指しています。
まだまだ足りない部分が多いですが、ペースを上げて開発に取り組んでいますので引き続きよろしくおねがいします。
開発を手伝ってくれるメンバーもまだまだ募集しております。
ぜひ一度御覧ください。

recruit.misoca.jp

*1:あるものが消えるインパクトはとても大きいので、消して軽い気持ちで削除したわけではないです

*2:まだモバイルからの使い勝手がいいとは言えない状況なので、表示は控えめになっています

OOUI社内勉強会を開催しました

こんにちは、@torimizunoです。

10月になってHiGH&LOWの新作映画が公開されたことが嬉しく、強く生きているこの頃です。

f:id:torimizuno:20191028155150p:plain

最近Misocaのデザインチームでは、全6回に渡りOOUIの社内勉強会を行いました。

その後メンバーでオブジェクトについて議論する機会が増えたり、思考やアウトプットに効果を感じているので、どのような目的や流れで勉強会を実施したのかを共有したいと思います。

目的

OOUI(オブジェクト指向ユーザーインターフェース)について、雰囲気理解でなく、個々が理解して考え、UIに落とし込む能力を鍛えるため勉強をする。 知見が高まってきたら、社内でのオブジェクト指向を親会社 (弥生株式会社)との共同プロジェクトにも発展させていきたい。

実施方法

  • 1回1時間の全6回で実施
  • 社内デザイナーは共通理解度を深めるため、基本的には参加
  • デザインパートナーの方や社内メンバーは自由参加
  • Zoomでつなぎ、Scrapbox上で勉強会を実施

流れ

ソシオメディアさんのOOUIの記事をベースに、前半はインプット、後半はアウトプットに重点を置いて勉強会を組み立てました。

(ソシオメディアさん、記事とても活用させていただきました!ありがとうございます!)

  • 第1回 輪読会
    • https://www.sociomedia.co.jp/7279
    • 記事を30分黙読しながら各自メモや話したいことをまとめる
    • メモを共有して、ディスカッション
  • 第2回 輪読会
    • https://www.sociomedia.co.jp/8740
    • 記事を35分黙読しながら各自メモや話したいことをまとめる
    • メモを共有して、ディスカッション
    • この回はエンジニアも参加してくれて、継承や細分化の話をしてくれました
  • 第3回 準備運動
    • https://www.sociomedia.co.jp/8753
    • 記事を参考に、OOUIの実践を実施
    • 記事のユーザー要件をもとに、35分のラフスケッチ
    • 各自のラフスケッチの共有とディスカッション
  • 第4回 準備運動
    • https://www.sociomedia.co.jp/8753
    • 前半
      • 記事を参考に、10分でモバイルアプリケーションのメインオブジェクトを探す
      • この時はメルカリ、Spotify、SmartEXを各自調査しました
      • 調査後、10分で共有とディスカッション
    • 後半
      • 記事を参考に、10分でデスクトップアプリケーションのメインオブジェクトを探す
      • この時はGoogleカレンダー、Trello、Gmailを各自調査しました
      • 調査後、10分で共有とディスカッション
  • 第5回 実践
    • 40分でMisocaのメインオブジェクトを抜き出す
    • 残りの時間で共有、ディスカッション
  • 第6回 実践
    • 抜き出したMisocaのメインオブジェクトで、40分で改めてラフスケッチをする
    • 残りの時間で共有、ディスカッション

↓Scrapboxでの様子

f:id:torimizuno:20191028152851p:plain

勉強会を開催してみて

全6回とも、社内だけでなくデザインパートナーの方にも参加いただけて開催することができ、純粋に嬉しかったです。

実際に自分たちのサービスのオブジェクトを見つめ直し、未来の話ができたことで、有意義な時間になりました。

自分自身、勉強会前と比べ強くオブジェクトを意識するようになり、UI設計やレビューでも言葉にする機会が増えました。

特に文言については、デザインチーム内ですぐに改善に移ろう、という話ができたので、今後の改善に活かしていきたいです。

参加メンバーの感想

@kanizmb

勉強会に参加したことでソフトウェアにおけるオブジェクト同士のつながりやそれぞれが持つふるまいを意識したり、使用する言葉づかいに気を配ったりするようになりました。 見た目のデザインを行う前に、オブジェクトの構造をふまえた情報の設計を行う手順を入れることで、より骨太なデザインを提供していけるのではと思います。

またリモートワーク体制の都合上、業務以外で交流する機会が少ない弊チームですが、会を通じてわいわいやれてよかったです。いろいろな感想や意見が飛び交い、一人で学ぶのとはまた違った角度で捉えられました。 今回のように時間を区切って即興でデザインしてレビューし合うのも、続けていくと良い訓練になりそうです。

@rikanezu

OOUIへの知識が全く無かったためまずは輪読会のみに参加しました。 単純に読む機会ができたことで内容について理解できたのはもちろんのこと、 読みながら思ったことを各々でScrapboxに書いていき、そのあとに各々の感想を発表したので自分だけでは噛み砕けなかった部分も理解することができ良かったです。 実務でもデザイナーが言おうとしていることが理解できるようになったので、やり取りもスムーズになりました。 デザイナーでなくてもUIの良し悪しの判断をする機会は多いため、感覚的ではなく共通言語で話せるようになり今回参加して学ぶことができてよかったです。

@masarumaruyama

「何がオブジェクトで、それがどのようにUIと関係するのか」を意識しながら、色んなプロダクトに触れてみたり、実際に画面を起こしてみたり、意見を交換したりと、発見の多い勉強会でした。

オブジェクトとアクションの関係を明確にすることで、画面遷移・ナビゲーションのつくり方、言葉の選び方、プラットフォームに依存しない体験の考え方など、大小さまざまな視点がリンクしました。

また、同じプロダクトに関わっているメンバーで開催したことで、日常業務ではOOUIの考え方が共通言語として扱えるようになり、コミュニケーションの解像度が上がりました。

今回は基本的にデザイナー中心の参加でしたが、直感的に理解できる内容が多いため、プロダクトの設計に関わる、あらゆる立場の人が馴染みやすい考え方だと思いました。今後、チームでプロダクトを考える上で、コミュニケーションの軸の一つにできそうな可能性も感じています。

採用情報

Misocaでは、一緒に活発に勉強していけるデザイナーを募集しています。

recruit.misoca.jp

SlackワークフローとRubotyで最高のChatOps生活を

Misoca開発チームの黒曜(@kokuyouwind)です。

富山Ruby会議が近づいてきましたが、10/23 午前11時現在、まだスライドを1枚も作ってません。4連休に着手するつもりだったんですが、シャニマスとMTG Arenaに消えました。

あ、頭の中ではできあがってるから…… あとはスライドに書き出すだけだから……(震え声)

🤖 Slackワークフロービルダー

先日、Slackにワークフロービルダー機能が追加されましたね。

これはSlack上からメニュークリックや特定タイミングで起動するワークフローを作ることで、定型的な作業を自動化できるものになっています。

f:id:kokuyouwind:20191023110125p:plain

このような画面でワークフローを定義できます。

メッセージを送るだけでなく、フォームを表示したり、メッセージ内にワークフロー起動者の名前やフォームの入力を埋め込んだりなどができるようになっています。

ちなみに、弊社の@tharaは力を授けてくれるワークフローを作っていました。

f:id:kokuyouwind:20191023112640p:plain:w400

力を求めるとこうなります。

f:id:kokuyouwind:20191023112829p:plain:w400

ニュースサイトかな?

🤔困ったところ

標準の機能だけでも定形メッセージの送信やアンケートの収集など使い所はあるのですが、外部サービスと繋がらないのでChatOpsを実現するには少々力不足に感じます。

スラッシュコマンドが使えると面白そうだったんですが、残念ながらそのまま送信されてしまいました。

f:id:kokuyouwind:20191023125434p:plain:w400

これでremindが設定されてくれれば、ワークフローからリマインドの設定や削除をしたり、/trelloコマンドを使ってTrelloのカードを作ったりなどもできそうなんですけどね。

💎Rubotyと連携させる

そこでRubotyですよ!

弊社のSlackにはRubotyのチャットボットが住んでいます。このボットは通常のメッセージを見ているため、ワークフローからのメッセージ送信でコマンドを起動できます。

f:id:kokuyouwind:20191023125926p:plain:w300

こんな感じで、普通に反応してくれます。もちろんechoのようにメッセージ内容を参照するコマンドも問題なく機能します。

f:id:kokuyouwind:20191023174316p:plain:w300

つまりワークフローとRubotyを組み合わせれば、外部サービスとの連携なども自由にできるわけですね!*1

休暇申請

Misocaでは休暇予定が他の人にわかるよう、シフトカレンダーに予定を作成するルールがあります。

f:id:kokuyouwind:20191023175045p:plain:w400

こんな感じでGoogleカレンダーに入れるルールのため、カレンダーを見れば今日だれが休みなのかわかるようになっています。*2

ただ毎回手で予定を入れるのは面倒なので、チャットボットからカレンダー予定を作れるようにしています。

f:id:kokuyouwind:20191023175644p:plain:w400

これだけでも結構便利なのですが、フォーマットを間違えると反応してくれなくて悲しいなどの事故を起こしがちです。またコマンドでは休みの開始日-終了日を指定しますが、実際には1日単位で取得することが多いためちょっと冗長な指定になってしまいます。

そこでワークフローを使うと…

f:id:kokuyouwind:20191023175859p:plain:w300

このメニューから「有給取得(一日分)」を選ぶことでフォームが開きます。

f:id:kokuyouwind:20191023180532p:plain:w300

ここに必要事項を埋めてSubmitすることで、カレンダー予定を作ることができます。

日付のところは現状だとテキスト入力です。カレンダーコンポーネントが使えるようになってくれるともっと便利になりますね。

ちなみに、作成者のコメントはこちら。

f:id:kokuyouwind:20191023180955p:plain:w400

はい。

リリース作業のワークフロー化

もう少し実用的な例でいきましょう。

Misocaでは本番へのリリース作業を「リリースしたい」「リリース開始」という2つの発言でできるようにしています。*3*4

f:id:kokuyouwind:20191024131816p:plain:w400

f:id:kokuyouwind:20191024131841p:plain:w400

こんな感じでリリース作業を行っています。

これも十分に便利なのですが、「リリースしたい」と「リリース開始」を打ち間違える事故があったり、リリース内容の見出し部分を手で書くのが結構めんどくさかったりといった点が気になっていました。

そこで、以下のようなワークフローを定義しました。縦に長いので画像を3分割しています。

f:id:kokuyouwind:20191024181636p:plain:w400f:id:kokuyouwind:20191024181648p:plain:w400f:id:kokuyouwind:20191024181658p:plain:w400

実際に使ってみると、以下のようになります。

f:id:kokuyouwind:20191024182500p:plain:w400f:id:kokuyouwind:20191024182626p:plain:w400

リリース準備が整ったら、以下のフォームにリリース内容を記入します。

f:id:kokuyouwind:20191024182845p:plain:w300

このフォームを送信すると、リリース内容が共有されたうえでデプロイが始まります。

f:id:kokuyouwind:20191024182639p:plain:w400

手でRubotyを起動していた箇所がワークフローから起動されるようになり、しかもリリースカテゴリなどもフォームを埋めるだけになりました。

left blankの部分が邪魔、そもそも手でカテゴライズしてるのがあまりイケてない、などの課題はありますが、従前と比べてミスしやすい箇所がなくなったことでリリース作業がしやすくなっています。

💬 感想

Slackワークフローは現状だと少々機能不足ですが、チャットボットを使った作業フローはそのまま置き換えることができて大変便利でした。みなさんもチャットボットと連携させて、外部サービスを絡めた作業の自動化を試してみてはいかがでしょうか。

今後は機能を強化して、ワークフロー機能のなかで「Slackコマンドの発行」「入力に応じたワークフローの分岐」などが入ってくれると使い道が広がりそうですね。とても楽しみです。

📢 宣伝

MisocaではSlackワークフローを使ってChatOpsしたいエンジニアを募集しています。

www.wantedly.com

*1:もちろんHubotとかでも問題なく動くと思います

*2:休みの理由は特に入れなくて良いのですが、自分はたまにネタに走って入れています

*3:「リリースしたい」でリリース準備が開始されてCIやステージ環境でのビジュアルテストを行い、「リリース開始」で本番へのデプロイが行われます。実際にボットがやっていることは「特定ブランチから特定ブランチへのpush」のみで、GitHub WebHookによってJenkinsやCodeDeployが起動するようになっています。

*4:ブランチを更新した際にGitコミットや差分参照URLも出していますが、これらはモザイクをかけています

Misocaのリモートワーカーの仕事環境2019

こんにちは。@KawamataRyoです。
エンジニアになってから着々と体重が増えて、先日80kgの大台に乗りました。
大学の部活ではライト級(60kg以下)で試合に出てたのでその頃から20kgの増量。日々色々な方面で成長中です。

さて今回は、Misocaのリモートワーカーの仕事環境のお話です。
以前こちらの記事で紹介してから早2年、メンバーの入れ替わりもありリモートの環境も大分変わったと思うので、2019年度版を改めて紹介します。

f:id:mugi1:20190925141503p:plain:w30 @KawamataRyo

リモート歴 基本勤務時間
6ヵ月 8:00〜17:00

f:id:ba068082:20191021100746p:plain

仕事環境のこだわり

  • モニターアームがカッコいいと思い、無駄にディスプレイを浮かせています。キーボードの押打でめっちゃディスプレイが揺れるのが悩み
  • 椎間板ヘルニア持ちなので、デスク、椅子は良いものを使っています。昇降デスクなので時々スタンディングデスクとしても使っています
  • 隣にベンチ、腹筋コロコロがあるので、休憩時はいつでも筋トレ可能です

リモートワークに思うところ

  • リモートワークをやる前は不安だったのですが、始まってみればとても自然にコミュニケーションができて、むしろオフィスにいた頃より会話が多い気もします(ペアプロ、朝会とかで)
  • 運動不足になりがちですが、昼休みの時間を有効に使い懸垂やランニングなどしてます
  • 何より家族で朝昼ご飯を食べられて、子供との時間をたくさん取れるのが幸せです

@eitobal

(Misocaでの)リモート歴 基本勤務時間
約6年 9:00 - 18:00

仕事環境のこだわり

  • ErgoDox EZ を使っています。
  • Arctis 5 というヘッドセットを使っています。マイクが収納できるので便利です。
  • あまり、こだわりはないです…

リモートワークに思うところ

  • 週1・2日は名古屋のオフィスに行っています。どこでも働くことができるので助かっています。
  • もう少し雑談が簡単にできるようにしたいなぁと思っています。
  • 気づくと朝から1回も家の外に出ていないことがあるので、運動をするようにしています。週2回ぐらいジムで筋トレして、他の日は走っています。最近は月200km程度走るようになりました。

f:id:mugi1:20160811121142j:plain:w30 @mugi_uno

リモート歴 基本勤務時間
2年半 9:00-18:00

f:id:ba068082:20191021100811j:plain

仕事環境のこだわり

  • ピカチュウがいる
  • Blue Yeti
  • 配線を楽していい感じに隠している。オススメ (参考)

リモートワークに思うところ

  • 10年前は、将来自分がこんな働き方してるとは微塵も思ってなかったので、人生何があるかわかりませんね〜
  • 基本的にはリモートより同じ空間で仕事したい派。けど、家庭事情とかのバランスを見てこういう選択肢を取れるのはいい時代になったと思う
  • 運動不足が深刻化していたけど、最近ボルダリングに行って3年分ぐらいは運動したのでもう大丈夫!!

@hidakatsuya

リモート歴 基本勤務時間
4年 9:30-18:30

f:id:ba068082:20191021100845j:plain

仕事環境のこだわり

  • 最近31.5インチの4K ディスプレイにして快適
  • Alexa が地味に便利
  • マウス、キーボードが合っていないので検討中

リモートワークに思うところ

  • メンバーと同じ空間で働くのも好きなので、環境・体調等に合わせて選択できるということが最大のメリット
  • ただ、リモートワークに飼い慣らされてしまって年々腰が重くなっている

f:id:mugi1:20190925142042j:plain:w30 @RKTM

リモート歴 基本勤務時間
3年ぐらい 10:00-19:00

仕事環境のこだわり

  • メモリを32GBにしたのでAndroidビルドやRailsのテストを走らせるのが快適になった。
  • ディスプレイアームを使うことによって机を広く使えるようになった。おすすめ。(その空間には紙が積み上がっているけど)
  • 子どもが下の階でワーワー騒いだりするので、密閉型のヘッドセットを重宝している。

リモートワークに思うところ

リモートのメリット

  • オフィスまで片道1時間弱かかるので、その時間を他のことに使えるだけで嬉しい。家族との時間も増える。
  • 暑い・寒いでオフィス出社するかを判断したり。

非リモートの強み

  • 一緒の空間にいることで捗ることも多い(例:ホワイトボードを使ったディスカッションや、トラブルシュートなど)
  • 複雑な議題の打ち合わせをする時には、遠方の人も出張でオフィスに来てもらうこともある。
  • 使い分けできると良い。

リモートでうまくやるコツ

  • 一人でタスクを抱え込みすぎると詰まるので、積極的に「わからん!」と声を上げていくのが良い。
  • 進捗の報告なども多少過剰なぐらいでちょうど良い。SlackやGithubなどで動きがない人にはたまに声かけて詰まってないか聞いてる。

健康管理

  • 一歩も家を出ないことがあるので、夜にジョギングしたりしています。雨の日はアンクルウェイトをつけて仕事したり。最近はドラクエウォークを散歩の楽しみにしています。

f:id:mugi1:20190925141630p:plain:w30 @mizukmb

リモート歴 基本勤務時間
1年半くらい 10:00 ~ 19:00

仕事環境のこだわり

リモートワークに思うところ

私は名古屋に住んでいるので、自宅でリモート・名古屋オフィスに出社を選択できるのですが、結構気分で選んでいます。双方メリット・デメリットあるので、今日の調子を見て最大パフォーマンスを出せる環境で仕事するという働き方がもっと広まるといいなあと思っています。

終わりに & 次回予告

いかがでしたでしょうか?
最近、働き方改革で在宅勤務も増えてきてはいますが、まだ少数派ですよね。
リモートが何よりベストとは思いませんが、幸せな働き方の一つの解ではあると思います。リモートワークの知見が共有され、もっと社会にこの働き方が広がればよいなと思っています。

最後に、今個人のTwitterでリモートワーカーへの質問を募集中です。
もし、今回の記事への質問、リモートワークへの疑問などありましたら気軽にリプライ、コメントお願いします!
頂いたコメントを元に、来月あたりにリモートワークのQ&Aみたいなタイトルでまとめられたらと思ってます。乞うご期待!!

採用情報

Misocaではリモートワークでも幸せに働きたいエンジニアを募集中です。 recruit.misoca.jp

Misocaメンバーに影響を受けた一冊を聞いてみた

こんにちは。@mugi_unoです。

最近デスクにピカチュウが鎮座してます。かわいい。

f:id:mugi1:20190925135039j:plain:w400

影響を受けた一冊

先日社内で「自分が今までで影響を受けた一冊って何かある?」というお題で話をしたところ、なかなかに盛り上がりました。

今回はその話を元ネタとして、Misocaのメンバーに聞いた「影響を受けた一冊」をご紹介します。

「プログラムはこうして作られる」@KawamataRyo

プログラムはこうして作られるプログラマの頭の中をのぞいてみよう

プログラムはこうして作られるプログラマの頭の中をのぞいてみよう

💬本人コメント

f:id:mugi1:20190925141503p:plain:w60
エンジニアに転職するきっかけになった本です。著者が作ったオリジナル言語でテトリスを作るのですが、他の入門書とは大きく違い、「プログラマならどう考えるか」が重点的に書かれています。エラーが出た際の考え方から、新機能の追加の際の思考の流れまで。他のプログラミング入門書では味わえないソフトウェアを作る本当の面白さがわかる本だと思います。今、エンジニアを目指して勉強中の方に特におすすめです。

「魁!!クロマティ高校」@mizukmb

魁!!クロマティ高校(1) (週刊少年マガジンコミックス)

魁!!クロマティ高校(1) (週刊少年マガジンコミックス)

💬本人コメント

f:id:mugi1:20190925141630p:plain:w60
単行本4巻の第83話の腹話術の回で初心者だからこそ良い道具を使い腹話術の真髄を極めるべきと神山が不良を説得するシーンがあり、それ以来私もプログラマーとして良い道具を使って仕事をしようと決心しました

「レガシーコード改善ガイド」@mallowlabs

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

  • 作者: マイケル・C・フェザーズ,ウルシステムズ株式会社,平澤章,越智典子,稲葉信之,田村友彦,小堀真義
  • 出版社/メーカー: 翔泳社
  • 発売日: 2009/07/14
  • メディア: 大型本
  • 購入: 45人 クリック: 673回
  • この商品を含むブログ (157件) を見る

💬本人コメント

f:id:mugi1:20190925141653p:plain:w60
当時レガシーコードと戦っていたので、「レガシーコードと戦っているのは自分だけじゃない」と勇気をもらった一冊です。「テストがないコードはすべてレガシーコード」という思い切った定義から始まり、安心してリファクタリングできるように様々な方法を教えてくれる本です。ちなみに Misoca のコードはガッツリテストが書かれているのでレガシーコードではないですよ!

「エリック・エヴァンスのドメイン駆動設計」@RKTM

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

💬本人コメント

f:id:mugi1:20190925142042j:plain:w60
・開発者に閉じるのではなく、エンドユーザーと開発者が同じ用語を使って会話し、モデリングし、コードに落とし込み、保守していく思想が素晴らしい。
・個人的に、現実の業務がうまくコードに落とし込まれないことで、コードも理解しづらく、業務の変更に追随できずに苦しんできた理由がわかった。
・より良いサービスをサステナブルに開発していくために非常に役に立つ本。おすすめです!

「リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック」@yueno

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

  • 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2012/06/23
  • メディア: 単行本(ソフトカバー)
  • 購入: 68人 クリック: 1,802回
  • この商品を含むブログ (140件) を見る

💬本人コメント

f:id:mugi1:20190925142108j:plain:w60
ずっと前に勤めてた会社からもらった本。これ読むまではコードは短い方がよいと思ってた(変数名とか英字1文字とかにしてた)けど、そうじゃないんだよー、ということを教えてもらった気がする。もう随分前すぎてあんまり覚えてないけど。

「コンパイラ―原理・技法・ツール (Information & Computing)」@ryota

コンパイラ―原理・技法・ツール (Information & Computing)

コンパイラ―原理・技法・ツール (Information & Computing)

  • 作者: A.V.エイホ,R.セシィ,J.D.ウルマン,M.S.ラム,Alfred V. Aho,Jeffery D. Ullman,Ravi Sethi,Monica S. Lam,原田賢一
  • 出版社/メーカー: サイエンス社
  • 発売日: 2009/06/01
  • メディア: 単行本
  • 購入: 1人 クリック: 128回
  • この商品を含むブログ (30件) を見る

💬本人コメント

f:id:mugi1:20190925142140j:plain:w60
学生時代にこの本(1st edition)を読んで、実装と理論を結びつけながら理解を深めていった記憶があります。読みづらい部分があるし、内容的に少し古い感じもあるので今はあまり人にお薦めしていませんが、内容のある良い本だと思ってます。

「数学文章作法 基礎編」@kokuyouwind

数学文章作法 基礎編 (ちくま学芸文庫)

数学文章作法 基礎編 (ちくま学芸文庫)

💬本人コメント

f:id:kokuyouwind:20190930142248p:plain:w60
数学文章に限らず、わかりやすい文章を書く上での基本的な考え方がまとまっている本です。ドキュメントやソースコードを書く際に「読み手」のことを強く意識するきっかけになりました。

「悲劇的なデザイン」@torimizuno

悲劇的なデザイン ―あなたのデザインが誰かを傷つけたかもしれないと考えたことはありますか?

悲劇的なデザイン ―あなたのデザインが誰かを傷つけたかもしれないと考えたことはありますか?

  • 作者: ジョナサン・シャリアート,シンシア・サヴァール・ソシエ,高崎拓哉
  • 出版社/メーカー: ビー・エヌ・エヌ新社
  • 発売日: 2017/12/27
  • メディア: 単行本
  • この商品を含むブログ (2件) を見る

💬本人コメント

f:id:mugi1:20190925142209j:plain:w60
デザインは誰かを幸せにも不幸にでもできることを、事例を持って教えてくれる本です。誰かを傷つけない、悲しませないデザインにするには何ができるか?についても紹介されていて、読むと身が引き締まります。

「ユーザ中心ウェブサイト戦略 - 仮説検証アプローチによるユーザビリティサイエンスの実践」@kanizmb

ユーザ中心ウェブサイト戦略 仮説検証アプローチによるユーザビリティサイエンスの実践

ユーザ中心ウェブサイト戦略 仮説検証アプローチによるユーザビリティサイエンスの実践

  • 作者: 株式会社ビービット武井由紀子,遠藤直紀
  • 出版社/メーカー: ソフトバンククリエイティブ
  • 発売日: 2006/09/27
  • メディア: 単行本
  • 購入: 14人 クリック: 313回
  • この商品を含むブログ (47件) を見る

💬本人コメント

f:id:mugi1:20190925180900p:plain:w60
2006年の著。ユーザーの実際の行動を観察することでニーズを読み解き、行動に寄り添ったタイミングでアプローチする手法が具体例を伴って紹介されています。読んだ当時ユーザー中心設計は今のように一般的でなかったため、目からウロコが落ちたのを思い出します。

「ノンデザイナーズ・デザインブック」@mugi_uno

ノンデザイナーズ・デザインブック [第4版]

ノンデザイナーズ・デザインブック [第4版]

💬本人コメント

f:id:mugi1:20160811121142j:plain:w60
何かのデザインをするときに必ず内容を思い出しています。読むだけでいきなりイケてるオシャレなデザインに開眼できるわけではないですが、「これはひどい...」という新人類向けデザインの爆誕を防げます。日常のフロントエンドコーディングはもちろん、発表スライドや説明資料作りでも役に立っているな〜と実感しています。

まとめ

デザインからコンパイラまで多種多様でおもしろいですね。

もし興味が湧いたら読んでみてはいかがでしょうか? 私はクロマティ高校が読みたくなりました。

余談ですが、私は最初ジョジョの奇妙な冒険5部が思い浮かんだものの「でもマンガだしな..」とやめたのですが、蓋を開けてみたら2人目でいきなりクロマティ高校で、自分を強く持つのって大事だなって思いました。

採用

Misocaでは本からも学びたいエンジニアを募集しています

recruit.misoca.jp