新型コロナによるWYRDの働き方の変遷
代表の大越です。 2020年1月のダイヤモンド・プリンセス号で新型コロナ感染者が出始めてから早1年半が経過しました。今回のブログでは、その間でWYRDの働き方がどう変わったかを振り返りたいと思います。 まず前提として、コロナ禍前のWYRDでは、基本オフィスに出社して仕事をするスタンスでしたが、大雨・大雪・台風の予報が出ている時などは「無理に出社せず在宅勤務にしましょう！」といった感じで、年に4,5回くらいは在宅勤務する日がありました。 また、一部のメンバーは既に週2,3日在宅勤務を導入していたり、移動が多いメンバーはモバイルwi-fiを持ち歩き移動中にリモートワークしたり、クライアント先と自社オフィスで半分ずつ仕事したりと日頃からフレキシブルにリモートワークする環境はありました。 1回目の緊急事態宣言期間前（2020/2/17～2020/3/31） 2020年2月17日、新型コロナウィルスの市中感染が確認されたため、満員電車等での感染を防ぐため2月末までの2週間について原則在宅勤務とするよう社員に通達。 2月末になっても感染状況は収まらず、引き続き3月についても1ヶ月間在宅勤務を継続。 ※クライアント先での作業についても調整のうえ、順次在宅勤務にシフト 前述したとおり、元々リモートワークする環境はあったので在宅勤務通達を出した際も特に何かを用意することなくスムーズに在宅勤務にシフトすることができました。 1回目の緊急事態宣言期間中（2020/4/7～2020/5/24） 4月になると状況はさらに悪化し緊急事態宣言が発出されたので、その期限にあわせ5月末まで在宅勤務を延長。4/1入社メンバー2名も顔合わせをして翌日からいきなり在宅勤務となりました。 ここまで3ヶ月半の在宅勤務通達を出してきましたが、社員全員がフルで在宅勤務できたかというと、各社員が抱える固有の問題により在宅勤務できないメンバーもいて、必ずしも在宅勤務が歓迎されるわけではありませんでした。 ・同居家族の関係で家で在宅勤務できる環境がない ・子供の学校がオンライン授業となり自宅回線の取り合いとなる ・東京の狭い家では在宅勤務用の自分スペースを自宅に確保するのは難しい 1回目の緊急事態宣言期間後（2020/5/25～2020/8/31） 1回目の緊急事態宣言が明けた2020/5/25の東京都の新規感染者数は7名。 今では考えられないくらい少ない数字です。 感染拡大が収まってくると各クライアントや各プロジェクト毎に徐々に元に戻す話しが出始め、弊社クライアントでは2社から現場での作業に戻す方針の話しがありました。 ただ、どちらもフルで現場作業というわけではなく、週2日現場作業で週3日はリモート作業となりました。 S社：週2日現場⇒月1日現場(緊急事態宣言中)⇒週2日現場 M社：週5日現場⇒完全在宅勤務(緊急事態宣言中)⇒週2日現場 その他のクライアントでは、引き続きリモートワークを継続だったり、これを機にオフィスを縮小し完全リモートワークにシフトするクライアントもでてきました。 6月以降のWYRDメンバーの働き方としては ・毎日オフィス勤務（家庭事情により在宅勤務できない） ・週に1-3回オフィス勤務（クライアント都合・若手社員の育成事情） ・ほぼ在宅勤務 このような感じで分かれました。 少ない日は2,3人出社、多い日でも5,6人出社といった感じですね。 こうなると16席の執務スペース、2つの会議スペース、リフレッシュスペースを備えているオフィスの賃料がもったいないと感じ始めました。 WeWorkやRegusなどコワーキングスペースへの移転も検討したのですが、15人規模から5,6人規模への縮小は思いのほかコストメリットが出なかったので、移転せず残ることにしました。（今となってはオフィス移転しなくてよかったと思っています） GoToトラベル/GoToイート開始（2020/9/1～） 東京都の新規感染者数が100名前後で推移する中、世の中はGoToトラベル/GoToイートで盛り上がり始めました。 ちょうど在宅勤務を初めて6ヶ月経過した頃ですね。 この頃になると、日本政府の経済復活施策もあって外出することに抵抗もなくなり、気分転換や運動不足解消を理由にオフィスに出社する人も増えました。 少ない日は変わらず2,3人出社、多い日は10人近く出社する日も出てきました。 この頃から、WYRDメンバーの働き方として、オフィス勤務・在宅勤務は本人に任せることにしました。 個人個人で抱えている問題も異なり、一概に「オフィス勤務がいい！」「在宅勤務がいい！」と言えないので、自身で一番パフォーマンスが高く出せる働き方を選択してもらうことにしています。 ※若手エンジニアはパフォーマンス次第で出社要請あり ちなみに直近の2021年8月の状況はこのような感じになっています。 ・毎日オフィス勤務(33%) ・週に1-3回オフィス勤務(50%) ・ほぼ在宅勤務(17%) パフォーマンスをきちんと出せる方については在宅勤務も認めています。 中途採用募集中！ WYRDでは年間通して中途採用の募集をしております。 2011年よりワークライフバランスを意識した経営に取り組み始め、エンジニアのパフォーマンスを重視した働き方を試行錯誤検討してきました。 前述したように新型コロナをきっかけに在宅勤務もだいぶ進み、社員それぞれがパフォーマンスを出せる最適な環境で働くことができます。 WYRDに興味を持たれた方、求人応募お待ちしております！
快適なGitライフを送りたいと思っている話
こんにちは。浅野です。 最近応援しているアイドルグループのメジャーデビューが決まりました〜〜いや〜めでたい！なかなかコンサートやイベントに行きづらいご時世ではありますが、細々と応援していきたいと思います！ さて、今日のテーマは「Git」です。開発に欠かせないツールで、毎日使っていますが、使いこなせているかと訊かれれば、みぞおちにワンパンを食らったかのごとく、「ゔ...」となってしまいます。 そんな感じなので、もっといろんなGitの使い方を教えてもらいたい〜と思い、とりあえず話のきっかけを作るために、私が便利だな〜と思っているコマンドたちについて書いていこうと思います。内容としては、以前プロジェクト内で共有してもらったものや、自分で調べて使えるな〜と思ったもの、よく使うのに忘れてしまうコマンドなどを備忘録という目的も兼ねて、載せていきます。 git add -p これは教えてもらってから愛用しています。差分を一つ一つ確認しながら、ステージングエリアにファイルを追加できます。余計な空白や意図していない変更に気付けるので、大変便利です。 git stash -p stashも一つ一つ確認しながらできるらしい。特定のものだけ退避できるので、複数の作業をしていて、ブランチを間違えた場合などに使えそうです。ただ実行するとめちゃめちゃ遅い(私だけ?) git commit --amend 直前のコミットを変更できるコマンド。私はgit commit -mで、コミットメッセージを書いている途中にも関わらず、勢い余ってEnterキーを押してしまうことがあるのですが、このコマンドのおかげで、そしらぬ顔で作業が継続できます。 git rebase -i コミットID こちらもコミットを変更できるコマンドですが、2つ以上前のコミットにも手を加えることができます。私は、多くなりすぎたコミットログをまとめるために使ったりしています。あとはあまりないかもしれませんが、CommitterやAuthorを変更することもできます。注意点としては、指定したコミットは含まれず、次のコミットからが対象になります。 git reset HEAD git reset HEAD ファイルパス # 特定のファイルを指定する場合 これは、「私〜〜いい加減覚えてくれ〜〜」という思いをこめて載せました。git addしたものを取り消せます。resetと聞くと、どうしてもコミット済みのものに対して行うというイメージがついており、git addを取り消すことと結びつかず、毎度忘れてしまいます。HEADは「現在のブランチの最新のコミットの状態」で、そこまで戻したいんだからresetで良い。よく考えれば分かりそう... git checkout リモートブランチ名 git checkout -b ローカルブランチ名 リモートブランチ名としなくても、リモートブランチをローカルに持ってくることができます。記述が少なくて楽チンですね♪なお事前にgit fetchが必要です。 git checkout コミットid ファイルパス 特定のファイルを特定のコミットの状態まで戻してくれるコマンド。checkoutってブランチを切り替えるだけではないんですね。以前、文字コードの影響で意図せず発生してしまった差分の取り消し方が分からず、困り果てていたのですが、その状況を救ってくれた恩人コマンドです。 最後に、コマンドではないですが、Gitの使い方として、私は、SSHキーのパスフレーズを打たないとgit pushできないように設定しています。(これはGitの機能ではないですが...)一瞬ですが、git push前に立ち止まって冷静に考えることができるので、安心感があります。 さて、いくつか書き連ねましたが、まだまだ知らない便利なコマンドや、より良い使い方が山ほどあるんだろうな〜と思います。そういうのをたくさん吸収して、快適なGitライフを送りたいです。 そんなわけで、「このコマンド便利だよ」、「こんな使い方おすすめだよ」というのがあれば、ぜひ教えてください。では今回はこの辺で！
大切なのは悩まないこと
初めまして。今年の4月に入社した渡部(ﾜﾀﾅﾍﾞ) と申します。 入社から早2ヶ月、私が研修の中で大切だと感じたことを書きたいと思います。 さて、タイトルにもあるので結論から述べてしまおうと思います。 私が研修の中で大切だと感じたことは 悩まないこと です。 考えることをやめるわけではありません。長々と頭を抱える時間を減らす という意味です。 つまり、分からない時は周りに助けを求めるべき ということです。 なぜそう思い、それが大切だと感じたか、理由は簡単明瞭です。 周りに頼れる先輩方がいるから です。それなのに聞かないのは勿体ないですよね？ まず、悩むということは、 自分の持ち合わせていない知識・技術を要求されている ど忘れしてしまい、思い出したい の2つが主な理由かなと思います。 後者であれば少し考えたら答えに辿り着けるかもしれませんが、前者の場合はそうもいきません。 自分で解決したい場合は、その事柄について調べる必要があります。 しかし、そこでも3つパターンが発生すると思います。 調べた結果、正しい答えに辿り着く 調べた結果、見当違いな答えに辿り着く そもそも、どう調べたら良いか分からない 1の場合は何の問題もないと思われます。 しかし、自分では正解かどうか分からないため、内心穏やかではないはずです。 レビューをして頂き、自信と確信を得て初めて安堵できると思います。 2の場合は、間違っているものの、答えが出ている分、レビュー・指摘を頂けます。 ですので、その指摘の対応をする、という形で解決することが多いと思います。 その後、同じ事柄に直面した際に対処できれば問題はないかなと思います。 問題は3の場合です。 自分の引き出しにその事柄に関する知識が微塵もないか、そもそもの観点が違う場合が多いです。 それでも躍起になり、自分で解決しようとすると時間を浪費します。 そんな時は潔く白旗を振り、周りの方に助けを求めた方がイイと痛感しました。 自分の引き出しにその事柄に関する知識が微塵もない そもそもの観点が違う と、原因がどちらだったとしても、周りの方に聞くことで、 自身の知識の幅が広がる 事柄に対するアプローチのかけ方を学ぶことができる と、確実に成長に繋がると思います。 しかし、周りの方に助けを求める時、現状や期待する結果を上手く伝えなければなりません。 内容を整理していると、その事柄に対して別の観点からアプローチをかけられる場合があります。 それが解決に直結する場合も少なくないので、やはり、周りの方に助けを求める というアクションは大切なのだと思います。 長々と書いてしまいましたが、考えることと悩むことをイコールにしないで、今後も精進したいと思います。 ご拝読いただきありがとうございました。
iOSのショートカット機能を利用して勤怠管理を行う(2)
このブログの担当は大体３ヶ月ごとに回ってくるのですが、 前回の記事の続きが気になって夜も眠れない人のために２ヶ月連続の投稿になります。 小林です。 前回の記事で、以下のように締めくくりました。 それでは、皆さんショートカットを実行するのを忘れないようにしましょう。 皆さん、思ったはずです。実行するのを忘れないやつは、そもそも勤務表をつけ忘れないのでは？と。 その通りです。１ヶ月経ちましたが、何回実行し忘れたことか。。。 そこで今回はなんとかさらに自動化できないかと試行錯誤していきたいと思います。 ショートカットアプリの中に「オートメーション」という機能がありました。 「ショートカット」機能がボタンを押下することで実行されるのに対して、特定のトリガーを検知して実行してくれる機能です。 そのトリガーの中に「到着」という項目があり、「指定した場所から半径100m(最低範囲)に近づいたら起動する」というものがありました。 まさにこれだと思い、設定してみたところ、なぜかメッセージが届かない。。。 起動はしていたので、設定ミスではありませんでした。 調べてみるとユーザガイドにこのような記述がありました。 以下のオートメーションは自動実行できません: 到着 オートメーション機能はトリガーを検知し、通知をしてくれます。その通知を押下した場合に実行される仕様なのです。 一部の機能は、その確認作業をOFFにすることができる(自動実行)のですが、上記の通り、「到着」は自動実行できないようです。 しかし、ここで諦めるわけにはいきません。 さらに調べると「NFC」というトリガーを見つけました。 これは、登録しておいたNFCタグの検出をトリガーとします。 机の上にNFCタグを置いておき、出退勤時にスマホをかざせば、時間を記録することができるようになりました。 残念ながら、完全な自動化にすることはできませんでしたが、唐突にボタンを押下するよりは、NFCタグを見て「かざさなくては」と思える方がよいかもしれません。 いつの日か、「移動作動機能」が自動実行できるようになることを待ちましょう。。。 ショートカットアプリでは変数を使用したり、if文を使用したりすることが可能なので、色々なことができそうです。 ぜひ皆さんも使ってみてください。 おまけ 実行した時間をメッセージアプリに送信するように設定していたのですが、それでは月末にスマホを見ながら、転記する必要があります。それも面倒ですよね？ 実はGoogleSpreadSheetとGoogleAppScriptを使用すると簡易的なWebサーバを用意することができます。 参考：Web Apps 上記の処理は、GET要求があった場合にSpreadSheetを更新する処理(一部抜粋)です。 自動的に勤務表が更新され、さらに勤務表作成にかける時間を短縮することができます。 アクションの中に「Web > URLの内容を取得」というものがあり、これにURLやパラメータを設定することで、リクエストを送信することができるようになります。
よく見る Capybara を利用したコードの誤った書き方
Capybara は良くクローラーとか E2Eテストで使われると思いますが、比較的E2Eテストで利用されることが多いと思います. ここでは E2Eテスト での Capybara の誤ったコードを紹介していきます. 動的なDOM 現在ではJSによって動的にDOMが変更されるため、常にDOMに変更が加わることを前提にコードを書く必要があります. Capybara APIの Check系のメソッドには対象の状態(DOM要素の存在、表示の状態)になるまでリトライされる機構があります. この辺の非同期の内容は公式ドキュメントのAsynchronous JavaScript (Ajax and friends)に書いてあります. 反対にCheck系以外の値を単純に取得する様なメソッドは、その時点のDOMから情報を取得します. 動的なDOMをテストするには以下のような3つステップを踏むことで対応ができます. 事前状態のチェック アクション 事後状態のチェック 例えば、ユーザ名の変更のユースケースを例にすると以下のように表現できる. 事前状態のチェックexpect(page).have_field('firstName', with: "old name") アクションfind("input.firstName").set("new name")find("button.update").click 事後状態のチェックexpect(page).have_field('firstName', with: "new name") input要素 には name属性 指定がない Input要素 には has_field? を使う.以下のDOMを前提に説明していきます. <div class="firstName"> <input name="firstName" value="John" /> </div> <div class="lastName"> <input value="Smith" /> </div> input要素のname属性がfirstName の入力値を確認する場合は以下の様にします. find(page('.firstName')).has_field?('firstName', with: 'John') # => true input要素のname属性がない場合は以下の様に書くことになるので直感的ではない為、避けるべきでしょう. find(page('.lastName')).has_field?(nil, with: 'Smith') # => true 配列として扱う # bad expect(all('.title').count).to eq 5 expect(all('.title')[1].text).to eql('hello') # good expect(page).to have_selector('.title', count: 5) expect(page).to have_content('.title', with:'hello', exact: true) ノードの数を調べる場合は has_selector? の count を検討するべきです. n番目のノードを取得する際は :nth-child()か:nth-of-type()を検討すると良い. all('.title').count や all('.title')[1].text が相応しくない理由は、評価時点でのDOMしか確認できないからです. count の場合は要素の数を取得しあた後にDOMに変更があった場合で期待値と異なってしまいます. [1].text の場合は2つの問題があり、1つ目は [1] でもしDOMが1つの要素の配列だった場合は nil になってしまい nil.text の様な評価をされてしまいNoMethodError が起きます. 2つ目は例え要素が2つ以上存在して取得できた場合でも、count同様その時点のDOMの評価になるため期待値と異なってしまう場合があります. 値を取得してしまう has_content? は has_text? のエイリアスで同じものです.オプションの exact のデフォルトは false なので正確に一致させる場合は true を指定する方が良いでしょう. false の場合は部分一致になります. # bad expect(find('.title').text).to eql 'hello' # good expect(page).to have_content('.title', with: 'hello', exact: true)