第1回 CSSBattle in トラストバンク レポート

皆さんこんにちは。フロントエンドエンジニアの片柳です。

今回はフロンドエンドチーム内で行われた「CSSBattle」第1回目の様子をレポートします。

CSSBattleとは?

cssbattle.dev

CSSBattleとは、指定されたお題をCSSだけで、いかに早く・綺麗に模写できるかを競うウェブサイトです。
Sassはもちろん、予測変換も使えないため、CSSの特性やプロパティをいかに覚えているかが勝負の鍵となります。

今回は

  • 制限時間30分
  • 完成してもSubmitボタンは押さず、最後に一斉に押して点数発表

といったハウスルールで対戦します。

今日のお題

「初めてだから簡単なものから始めたいね」なんて、悠長なことを話しつつ、くじ引き。
映えある1回目のお題は

https://cssbattle.dev/targets/102.png

oh…

初回からかなり難しそうな絵柄に当たり、途端におよび腰になる一同。
「ええ…」「うーん…」と不安げな唸り声が各所で上がる一方で、「pxは省略しても大丈夫」といったCSSBattle特有のハックを見つけるなど、あっという間に30分は過ぎて行きました。

みんなの回答

奮闘の結果を少しだけご紹介

「ざっくり作ったのちに細部を整える」「初めから細かく整えつつ仕上げる」など、同じ会社の同じチーム内ですが、組み立て方に個性が出る結果となりました。

今回のお題で難易度を上げていたのは、上下左右に広がったドクロの骨部分。
辿り着けたのは7人中2人だけでした。

丸・丸・四角と3つの形から構成される要素ですが、疑似要素をうまく使うことで<div>要素1つでも作ることができます。
ただ、transformで角度をつけるとtopleftの指定で動く向きが変わるため、微調整の際には注意が必要です。

難しいお題に一同苦労しましたが、終わる頃には「別のお題でまたやってみよう!」などポジティブな声もあがり、チームの交流としては大成功でした。

最後に

弊社トラストバンクでは様々な職種で絶賛採用中です!
気になった方、是非お気軽にご連絡ください!

www.wantedly.com

OEMサービスのUIをStorybookで管理する

はじめまして。フロントエンドエンジニア兼サーバーサイドエンジニアの片柳です。

先日、トラストバンクから「Bonchiふるさと納税」がリリースされました!

www.trustbank.co.jp

ふるさとチョイスのOEMサービスとは、パートナー企業がブランドデザインを維持しながら、寄付申込や決済など、ふるさと納税サイトに必要な機能を包括的に提供できるサービスです。

パートナー企業ごとに異なるブランド・レイアウトを提供するためには、柔軟性に優れたUIパーツとそれを管理するためのツールが必要不可欠です。
本プロジェクトではStorybookを導入し、デザイナーやパートナーとのコミュニケーションを取りました。
簡単な導入方法と、実際に利用してみての良し悪しを紹介します。

導入

npmからインストール。

npx sb init

ディレクトリはこんな感じ。本プロジェクトにはNextJSを採用しています。

├ components/
│ └ tsx/
│   └ styled/
│     └ Button.tsx
└ stories/
  └ components/
    └ Button.stories.tsx

components/tsx/styled/にファイルを作ったら、その流れでstories/にもペタリ。
よりコンポーネントの追加を楽にするため、独自の拡張クラスを作成しました。

export class Storybook<T extends keyof JSX.IntrinsicElements | JSXElementConstructor<any>> {
  /**
   * メタ情報
   */
  protected meta: ComponentMeta<T>;

  /**
   * コンポーネントのテンプレート
   */
  protected template: ComponentStory<T>;

  constructor(title: string, Component: ComponentType<any>) {
    this.meta = {
      title,
      component: Component,
    };
    this.template = (args) => <Component {...args} />;
  }

  /**
   * メタ情報を取得
   */
  public getMeta(): ComponentMeta<T> {
    return this.meta;
  }

  /**
   * コンポーネントのテンプレートを取得
   */
  public getTemplate(): ComponentStory<T> {
    return this.template;
  }
}

これを

import { Storybook } from '@/components/tsx/plugins/Storybook';
import { Button } from '@/components/tsx/styled/button/Button';

const storybook = new Storybook<typeof Button>('basic/button', Button);

export default storybook.getMeta();

export const Fill = storybook.getTemplate().bind({});

Fill.args = {
  children: 'ボタンテキスト',
  radius: 4,
};

こう。
型付けもできて、見た目もスッキリです。

ボタンコンポーネントを小さくしたり、丸くしたり、青くしたり

良かったこと

何より簡単。シンプル

どんなに綺麗にコンポーネント一覧を作っても、更新を忘れてしまえば意味がないですよね。
作成したReactコンポーネントをただ貼り付けるだけで作成でき、細かい出し分けはStorybookに任せればいいので手間になりません。

無駄なコンポーネント開発を避けることができる

似てるようで少し違うコンポーネントをつい量産してしまうこと、ありませんか? 私はあります。
デザイン確認後、まずStorybookを見る癖をつけたことで、「このコンポーネント、Stroybookのあのコンポーネントと似てるな・・・デザイナーに相談しよう!」と、同じパーツの大量生産を避けることができました。
逆に、「このパーツは似ているけれど、使われ方が異なるから分けておこう」といった対応も簡単です。

イマイチだったこと

色味の一括変換ができない

「全てのコンポーネントの赤色を、青色に変えて確認したい」といった、全体を見て確認するような調整がStorybookは苦手です。
環境変数を持たせることもできないので、ページ全体のトンマナやアクセントになるような色遣いを検討するには不向きだと感じました。

NextJSとの相性がイマイチ?

NextJS独自の<Image>useRouterが含まれるコンポーネントだと、うまく機能しない場合がありました。
コンポーネントに基本的なスタイル以外の情報を持たせない運用を徹底すれば解決しそうですが、なかなか難しいですね。

まとめ

Storybookというツール自体は前から知っていて、「便利そう!使ってみたい!」と思ったいたため、実際にプロジェクトに活用できたのは良い経験になりました。
一長一短はありますが、従来の静的なコンポーネント管理と比べると、圧倒的にシンプルで運用しやすい印象です。
工夫次第ではstories.tsxファイルの自動生成や、環境変数に類似した機能も実装できそうですし、今後もどんどんカスタマイズしていきたいですね。

弊社トラストバンクでは様々な職種で絶賛採用中です!
気になった方、是非お気軽にご連絡ください!

www.wantedly.com

NRUG (New Relic User Group) SRE支部 Vol.1 「俺たちのSREとNew Relic」に登壇しました!

こんにちわ! CTO室でSREやっている@Tocyukiです!

先日、5/13にNRUG (New Relic User Group) SRE支部の記念すべき第一回目のイベントに登壇したので、参加した経緯とか振り返りをしていきたいと思います💪

nrug-sre.connpass.com

そもそもなんで登壇したの?

実はこのNRUG SRE支部には運営として携わっているのですが、たしかTwitter上でSRE支部設立の機運が高まり、そのやりとりに反応したらNRUGのSlackでNew Relicの中の人からメンションが飛んできてそのまま運営メンバーになっていた、という感じですw

SRE支部設立の瞬間

そんなこんなでとりあえず運営メンバーになり、最初のイベントということで週次でMTGしながら案出しは色々していたんですが、運営の3名がそれぞれフェーズも規模も異なる組織でSREをやっているということで、まずはそれぞれの「俺たちのSREとNew Relic」とかでセッションするのが良いのでは?という流れでイベントタイトルおよび内容が決まりました。

なんで運営に参加しようと思ったの?

自分は今までこういったイベントや勉強会には参加するだけで、運営に携わったこととかはなかったのですが、単純に他社のSREの方と繋がりたいなぁ、というのとすでに弊社で導入しているNew Relicへの興味、知見を高められると良いなぁと思ったのに加え、弊社の開発組織フェーズ的にも社内外へのポジティブな影響が期待できるんじゃないか?との思いで参加しようと思いました。

採用的な部分や社内へもポジティブな影響を及ぼせるだろうという思いはありましたが、外部コミュニティでの活動が自身と社内外へどのような影響を及ぼすのか、という部分について実際に確かめたくなったという側面もあります。

やってみてどうだったか?

これはもう本当にやって良かったです👌

今までの自分の経験やナレッジの有効性や需要的な部分の反応は自分の影響が及ぶ範囲でしか確認することができなかったのですが、今回運営でのMTGや登壇を通して、とてもポジティブな反応を頂けたので、自分がやってきたことに自信を持てるようになりました😎

あと、単純にポジティブな反応がもらえるのはとてもモチベーションに繋がりますし、嬉しいですw

特に今回のイベントはアンケートの回答率が30%近くあり、かなり満足度が高かったようで、そのようなイベントの運営に携われて本当に良かったです。

これからも積極的に自身でやってきたことをアウトプットしていき、どのような反応がもらえるか、またどのような影響が出るかを楽しみながら、社外のエンジニアの方との繋がりを増やしていけると良いなぁと思っております!

おわりに

情報は発信する人に集まるという性質もあるのかなと思いますので、モチベーション旺盛なエンジニア諸氏におかれましても積極的にコミュニティ活動や登壇等チャレンジしてみると良いのではないでしょうか?

そしてイベントが盛り上がったということでNew RelicさんにLPと開催レポートを作成していただきました!

こちらからイベントの動画や登壇資料も確認できますので是非ご確認くださいー👍 newrelic.com

開催レポートはこちら

newrelic.com

NRUGのSlackも誰でも入れますので、New Relic気になってる方は是非参加してみてください! join.slack.com

あと今回Twitterも非常に盛り上がったのでTogetterにもまとめたのでこちらも👍 togetter.com

そしてそして弊社トラストバンクでは様々な職種で絶賛採用中なので気になった方は是非お気軽にご連絡くださいー!

www.wantedly.com

リモートワークだからこそ取り入れたい!スウェーデンの雑談文化「Fika」のススメ

こんにちは!パブリテック事業部でSREを担当している藤谷です。前職でスウェーデン人と仕事をしていた時に教えてもらったスウェーデンの文化「Fika(フィーカ)」を紹介します。 トラストバンクでは原則リモートワークで、工夫をしないとチーム内でのコミュニケーションが取れないこともしばしばあります。 そんな中、実際にパブリテック内でもFikaを実践し始めています。

Fikaとは?

一言で表すと「コーヒーブレイク」です。 スウェーデンではFikaという習慣が根付いていて、どんなに忙しくても一旦仕事の手をすべて止め、コーヒーを飲みながら甘いものを取り入れる時間を一日数回、15分程度設けられています。

語源は音節が逆になる倒語で、スウェーデン語のコーヒー「kaff」がFikaと呼ばれるようになったと言われています。 スウェーデンではFikaが行われる職業は限られておらず、公務員もFikaの習慣が根付いています。 時間は人それぞれかと思いますが、一般的には毎日10時頃と15時頃にFikaの時間を設けることが多いそうです。

Fikaのやり方

雑談相手は誰でも良いです。(同僚、上司、部下等)作業の手を止め、仕事のことは忘れて、15分程度コーヒーとスイーツを食べながら雑談するだけです。 もちろん、コーヒーの代わりにお茶でもホットココアでも良いですし、スイーツが苦手なら、サンドイッチのような軽食でもいい。場所、時間や相手など、基本は自由です。

Fikaの3つのメリット

①仕事にメリハリが生まれる

仕事が忙しいと休み時間を割いてでも、仕事をしてしまいがちです。 ですが、人間の集中力が続くのは60分、長くても90分が限界だと言われています。 長く続けてしまうと疲労が溜まってしまい、その状態で無理やり仕事を続けると効率が落ちるだけでなくミスの原因になります。

筋トレなどの運動も一緒で、適度に休憩を挟まないと長くは続けられないのと同じです。

スウェーデンのFikaは習慣として根付いているため、ほぼ強制的なコーヒータイムです。 一旦すべての仕事から手を離れ、Fikaタイムを取ることで仕事にメリハリが生まれ、短時間でも作業が進み、効率よく質の高い仕事につながります。

きわめて能率がいい社員の働き方

「SINGLE TASK 一点集中術――「シングルタスクの原則」ですべての成果が最大になる」という書籍にも以下のように書かれていました。

  • 能率がいい社員は、出社後すぐに仕事に取りかかるうえ、1日のあいだに何度か休憩時間を設けている。
  • 日々のスケジュールにリフレッシュする時間を組み込むことで、能率を上げている。
  • そのうえ、彼らは昼食時にも一切仕事しないことを心掛けている
  • 〈休憩を定期的にとるほうが、かえって成果をあげられる〉
  • しっかりと休憩し、自分を「オフ」にする時間があるからこそ、「オン」のときに集中できる。

②仕事にメリハリが生まれた結果ストレスフリーな働き方になる

  • スウェーデンでは、夜遅くまで会社に残ることは美徳とされていなく、愛する家族や自分の生活を大切にしているため、定時ダッシュするのが基本中の基本のようです。
  • Fikaは作業の手を止めて息抜きする時間なので、一旦仕事はすべて忘れ、休むときはしっかり休んで、働くときは集中して働く。メリハリをつけて取り組んだ方が、生産性があがるとスウェーデンでは言われています。

③仲間と雑談することでコミュニケーションが活性化される

  • Fikaは単なる休憩ではなく、非常に重要なコミュニケーションのきっかけとして重視されています。意識的に時間を取って、同じ時間に仕事の同僚等とコーヒーやお菓子を食べながら雑談をしたり、週末の予定を立てたりして会話を楽しむこと。
  • それによって職場での意思疎通が進んだり、意見を自由に言える雰囲気が出るなどのメリットがあります。
  • 仕事をするときはとことん打ち込んで、ちょっと疲れたころに甘い物で元気をチャージ。リラックスしながらおしゃべりすることによって社内の空気もよくなり、コミュニケーションの活性化も望めます。
  • 話のトピックは人によってさまざま。天気の話題にとどまらず、趣味やペットのことなどを、アットホームな環境でのんびり語り合う。そうすることにより、チーム全体の連帯感も自然に強まっていくらしいです。

まとめ

リモートワークではコミュニケーションが希薄になりがちです。雑談の文化としてFikaが習慣として根付いているスウェーデンの働き方は参考にできるところが多くありました。 Fikaは仕事の効率のためだけではありません。雑談のきっかけとして、実践してみませんか?

トラストバンクではエンジニアを募集しております! ポジションにとらわれず、いろいろなチャレンジができますのでご興味ありましたら是非募集ページをご覧ください! www.wantedly.com

Sentry運用日記 - 検知されるエラーをbeforeSendでフィルタリングする

どうも、フロントエンドエンジニアの田口です。
以前Sentryについての記事を書いたのですが、導入してから運用として問題が出てきたので、その対処をしたという続編みたいなものになります。
Sentryについては「導入した!」という記事は多いのですが、その後の運用についてはあまり語られていないような気がしますので、導入したばかりや導入を検討中という方の参考になればという期待を込めて書かせていただきました。

前回↓
tech.trustbank.co.jp

前回のあらすじ

クライアントサイドでのエラー検知のためにSentryを導入した

Issue多すぎ問題

Sentryの導入時、エラーがどれほどの量検知されるのか、また導入によるデメリットなどは無いかの確認のため、いきなりサービスの全ページを監視するのではなく、監視範囲を徐々に広げていくような導入方法を採りました。最初はユーザーの訪問数も少なめなページで様子を見て、その後は訪問数の多いページを少しずつ監視対象として追加していき、最終的に全ページを監視対象としました。
しかし、訪問数の多いページを追加監視していくのに比例して、明らかにエラー検知数が増加しており、3月期にはTeam Planについてくるエラー検知クォータ(5万イベント)を25日目にはオーバーし、クォータを追加することになりました。
導入によるデメリットもなく、エラー検知のメリットを感じ始めていたことを踏まえ、監視対象の拡大は進める一方で、多すぎるIssueによりトリアージの判断も困難になってしまっていたため、増えすぎた検知数をなんとかする必要性も高まりました。

対処しなくて良いエラー、対処すべきエラーの見極め

そもそもどんなエラーが増えているのかを確認するため、加速度的に増えていくIssuesの件数にツラさを覚えつつも、検知数の多いIssueから分析を開始しました。
これは普通のエラーですね。エラーの原因も分析が可能ですし、解消も容易です。

画像はイメージです

一方でこのようなエラーも。

これは……?

最初のエラーと比較してみるとstack traceが何も出ていません。このIssueの内容から原因を調査して対処するのはかなり厳しいものがあります。 *1
ツラいことに、こうしたIssueの数は分析可能なものと比較しても同じかそれ以上の量上がってきていました。エラーのトリアージ(優先度付け)として、このような分析困難なエラーに向き合うことは時間やSentryのクォータを丸々含めた「予算」の無駄になりますので、フィルタリングすることにしました。

フィルタリング方法の検討と実装

フィルタリング方法で最も簡単なのは管理画面で捨てたいものをポチポチとやればすぐに捨てられる方法ですが、果たしてSentryにあるのか…と思ったら、ありました。

削除しつつ将来にわたり無視する…完璧だ

しかしこの無視する機能、Teamプランでは使用できません。一つ上のBusinessプランが必要です。残念ですがこちらの使用は断念。
ということで管理画面からのフィルタリングはTeamプランではほとんど出来ないので、SDKによるフィルタリングを実装しました。

beforeSendという強力な味方

Sentry SDKには便利なオプションがいくつもあり*2、既にwhiteListUrls(allowUrls)によるURLでのフィルタリングやenvironmentによるIssueのタグ付けを導入していました。
今回のフィルタリングでは、beforeSendを使用しました。beforeSendは関数を登録でき、eventオブジェクトを返せばエラーをSentryに送り、nullを返せばエラーはSentryに送られずに破棄されます。
例えばstack traceの有無のみでフィルタリングするのであれば以下のような簡単な実装で済ませられます。

beforeSend(event) {
  try {
    const hasStacktrace = event.exception.values.some(value => {
      return value.stacktrace?.frames?.length > 0;
    });
    if (hasStacktrace) {
      return event;
    }
    return null;
  } catch {
    return event;
  }
}

beforeSendはかなり柔軟な実装ができますので、エラーに関する情報が詰まっている引数のeventの中身を一度確認してみることをおすすめします。
また上のスニペット例では引数としてeventしか使用していませんが、第二引数としてhintが使用可能です。
hintオブジェクトにはoriginalExceptionというプロパティがあり、Sentry特有のエラーのオブジェクトに変換される前のエラーが取得できます。が、内容的にはeventオブジェクトでも取得可能なもののようなので、今のところhintは使用していません。

Sentryの公式ドキュメントでもbeforeSendをはじめとするフィルタリングのアイデアがいくつか書かれていますので、こちらを見ながらサービスに必要なフィルタリングを実装していくのがGoodかと思います。

docs.sentry.io

Sentryの運用はフィルタリングが肝

beforeSendによるフィルタリングによって、上がってくるIssueのほとんどは分析可能なものになりました。数は多いのですが、これらは一つ一つバグとして潰していくことが可能です。
Sentryの運用をされている方の記事等を見ているとフィルタリングの重要性について書かれていることが多いので、重要性を認識してはいたのですが、今回の改善によってより一層認識を強くしました。
今後はSentryでバグを潰していくとともに、Sentry自体の運用についても定期的に見直していこうと思います。またアップデートをしたときにはここで記事を書きます。

それでは今回はこの辺で〜ノシ

ということでいつもの

トラストバンクではバグを分析し、それを修正することが得意なエンジニアを随時募集しております! www.wantedly.com

*1:ちなみにこのエラーについて調べたところ、マーケティング関連のタグ(GTMか何かで導入されている)でfetchで取得したいリソースがCORSエラーになっていたようです。allowUrlsでファイルのパスでフィルタリングしているのにIssueとして上がってしまう理由は分かっていません😓

*2:https://docs.sentry.io/platforms/javascript/configuration/options/

CloudflareでTorをブロックする方法

パブリテック事業部のSREを担当している大場です。

突然ですが、Torネットワークというのをご存じでしょうか?
秘匿性の高い通信を行う際に利用される技術ですが、検索するとダークウェブなど何やら怪しい言葉が並びます…。あまり一般的に利用されているものではありませんが、Torブラウザを使えばだれでも利用はできます。
このようにいろいろな国を経由してアクセスしているようです。
f:id:hideki_oba:20220407180616p:plain

少しだけ紹介しましたが、Torブラウザの利用を推奨しているわけでは決してありません!

で、本題ですが、、
リスク軽減かつ、あまり利用ケースも考えられないため、TorネットワークからLoGoフォームへのアクセスをブロックすることにしました。
大げさにきこえるかもしれませんが、LoGoフォームではCloudflareを利用しているので設定はめっちゃ簡単です。
f:id:hideki_oba:20220407181043p:plain

ファイアウォールルールでこの設定をするだけです!超簡単ですね。

Cloudflareに感謝しつつ、トラストバンクではエンジニアを募集しております!
ポジションにとらわれず、いろいろなチャレンジができますのでご興味ありましたら是非募集ページをご覧ください! www.wantedly.com

Chromeのタブを自動クローズ!拡張機能xTabが作業効率UPに役立つ3つのポイント

f:id:tb_hiromu_fujitani:20220405091429p:plain こんにちは!パブリテック事業部でSREを担当している藤谷です。 去年まではタブを開きすぎてしまうことが多かったのですが、半年ぐらい利用しているGoogle Chrome拡張機能「xTab」が作業効率UPに役立っているので、そのポイントを3つ紹介します。

ブラウザのタブ、気付いたらこんな状態になっていませんか? もしなっている場合は、今回紹介する「xTab」を使うことで強制的にタブを開きすぎてしまうクセを改善し、それによって作業効率UPが期待できますので、ぜひ最後まで読んでみてください! f:id:tb_hiromu_fujitani:20220404175534p:plain

xTabが作業効率UPに役立つ3つのポイント

前提として、人間は同時に複数のことを認知・処理することは不可能です。もし可能であれば、車の運転中に読書だってできるはずです。 つまり、タブを大量に開いていることは、認知・処理できないものを常に目の前に置いていることになります。 優先順位をつけることができない複数の要求にさらされると人間の脳は圧倒され、うまく機能しなくなるのです。 そういった前提を元に、作業効率UPに役立つ3つのポイントを紹介します。

①メモリ使用率を大幅に下げられる

ブラウザで使うタブを減らすことでメモリ使用率を大きく下げることが可能です。 Google Chromeは意外にもメモリ使用率が非常に高く、その使用率はタブを開けば開くほど向上します。動きのあるサイトだとCPU使用率まで上がってしまうことも。 高性能なPCであれば、影響は少ないかもしれませんが、ある程度のスペックがないと影響を受けてしまいます。

f:id:tb_hiromu_fujitani:20220404180011p:plain

②集中力が向上する

タブを閉じる癖をつけることで集中力、認知能力が向上し、作業効率のUPにつながります。

タブの開きすぎは目の前の作業に集中ができていない証拠でもあります。 「あ、そういえば」といった感じで、目の前のタスクとは関係のないページを見てしまい、そのページに関連したタスクに意識がスイッチングしてしまいます。 すると、元々やっていたタスクが忘れられ、新しいタスクに意識が飛んでいき、いつまでもタスクが終わらない状況になりかねません。

以下の記事で「デスクが散らかっていると集中力も生産性も低下する」ことが解説されております。

www.dhbr.net

アメリカのプリンストン大学の研究結果で、乱雑な環境は人の認知能力と集中力を低下させることがわかっているとのこと。これはデスクに限らずブラウザのタブも例外ではないと考えます。

③作業ミスを減らせる

タブを開きすぎていると、自分がどのタブで作業をしていたかがわからなくなり、作業ミスの原因になります。 例えばブログ記事の作成で、同じ編集画面を2つ開いて、他のサイトで情報収集をしている間に、どちらの編集画面が最後に編集していたかがわからなくなり、誤ったほうに更新をかけて、これまでの作業がリセット…という事態になったりします。

これがもしAWSの設定値の変更中に調べ物をして、誤ったAWSの設定変更をしてしまった…となると大惨事です。 基本的に目の前の作業と関係のないタブは閉じる!というクセがついていればこういったミスは減らすことが可能です。

ブラウザのタブを開きすぎないことに慣れる

ブラウザは本当に強い意識を持たないとすぐにタブだらけになってしまいます。私も最初はそうでした。 ここでGoogle Chrome拡張機能「xTab」がとても便利です。 事前に設定しておいたGoogle Chromeの最大タブ数を超えてタブを開けなくする拡張機能です。

意識しなくても拡張機能が強制的にタブを閉じてくれますので、「タブを閉じるクセ」を付ける良い練習になります。 練習の結果、開きすぎないことに慣れると、想像以上に作業効率がUPすることに気づくことでしょう。 chrome.google.com

xTabの設定内容

「Tab limit」:開ける最大タブ数を設定します。 「Close least recently used」:一番手前で使用したタブから閉じていきます。 「Close least accessed」:アクセスが少ないタブから閉じていきます。 「Close Oldest」:古い順番にタブを閉じていきます。 「Block new tabs from opening」:新しいタブを開くことをブロックします。 f:id:tb_hiromu_fujitani:20220404181126p:plain

実際に半年間使った感想

私は以下の設定です。10個を超えるタブ数になると以下のように新規タブのオープンがブロックされます。 TabLimit:10 設定:Block new tabs from opening

最初は10って意外に少なくて、慣れるのが大変でしたが、慣れたら10個どころか2~3個程度しか開かなくなりました。 その分、PCが軽くなったり、気が散らなくなって作業も捗ります。人間は最初はつらいことでも慣れたうえにクセができてしまえば、問題ありません! f:id:tb_hiromu_fujitani:20220404181530p:plain

類似プラグイン「OneTab」はどうなのか

簡易的なブックマークのような感じで開いたタブをプラグイン内にまとめる機能が「OneTab」の特徴ですが、個人的にはあまりお勧めしません。

整理が得意であれば問題ないのですが、整理が苦手な人は、逆効果になると思っています。 私の場合、机の下や引き出しの中に物を詰め込んで、実質は整理されていないのに整理した気になった状態になりがちなのですが、それと同じことがブラウザで起きてしまいそう…と思いました。

「xTab」と「OneTab」を併用するのはアリかもしれません。

まとめ

以上、タブを自動的に閉じてくれるChrome拡張「xTab」が作業効率UPにつながる理由と、集中力や作業ミスにつながるなどの悪影響を解説しました。 最初は、新しいタブを開くのをブロックされて、不便に感じるかもしれません。それを乗り越えた先には、大きく作業効率が上がっているはずです! ぜひ試してみてください。

トラストバンクではエンジニアを募集しております! ポジションにとらわれず、いろいろなチャレンジができますのでご興味ありましたら是非募集ページをご覧ください!

www.wantedly.com