Moi! ヌーラボに入社してから3年目のUXエンジニアのヨーナスです。久しぶりのブログ投稿ですごく緊張しています。 今回は、アクセシビリティに特化することを決める前に色覚特性について知りたかったことを書こうと思います。このブログは、ヌーラバー真夏のブログリレー2024の8日目のブログとして更新しています。 まずは言っておきたいのは、私は色覚特性（色弱、色覚異常と呼ばれることもありますが、このブログでは色覚特性と表記します）を持っていないため、この投稿に書いてあることは間接的に得た情報に基づいています。色のアクセシビリティの判断は、できるだけ当事者に相談しましょう。 最初は、色覚特性について解説しようと思います。そのあと、ありがちな誤解をいくつか紹介します。最後に、基本的な対応方法を紹介します。 目に見えない障害としての色覚特性 さまざまな障害について考えるときによく頭に浮かぶのは、車椅子や

※このブログはヌーラボ真夏のブログリレー2024の6日目の記事です。 こんにちは！ウェブサイト課の松永です。 最近のウェブサイト課の活動として大きなものはNulab Developer APIサイトのリデザインとJBUG（ジェイバグ）サイトの新規開発があり、2024年6月にいずれも公開することができました。この記事では、フロントエンドエンジニアの視点でJBUGサイトの開発について共有できたらと思います。 なぜ作ったか JBUGはJapan Backlog User Groupの略で、Backlogユーザーによるコミュニティです。これまではJBUGに関する情報を紹介するページが存在せず、ヌーラボがJBUGについて情報発信をするときはブログやSNSに限られていました。もっと多くの人にわかりやすくJBUGの活動をお届けし、かつJBUGの理念や目的を一貫性のあるメッセージでお伝えすることで、JBU

こんにちは、ヌーラボの @vvvatanabe です！ 夏の訪れと共に、ヌーラボの一大イベント「真夏のブログリレー」が帰ってきました。今年も技術ブログリレーを実施しますが、今回はさらにパワーアップして、ソフトウェアエンジニアだけでなく、マーケティングやセールス、人事、広報のチームも参加します。さまざまな視点からのエキサイティングなブログが連なっていく様子を楽しみにしていてください！ アウトプットを楽しもう ブログを書くのは大変そうだと感じる方もいるかもしれません。しかし、ヌーラボでは「アウトプットの楽しさ」を大切にしています。新しいアイデアや発見を共有することで、より多くの人々と繋がり、成長できるのです。去年のブログリレーも大変好評でしたが、今年はさらにバラエティに富んだ内容をお届けする予定です。 過去のブログリレーの様子はこちらです： 2023 Tech https://adventar

ヌーラボのサービス開発部SRE課Platform Engineeringチームに所属するiwaです。ヌーラボのサービス開発をより迅速・快適に行い、顧客へ価値を届けるための基盤作りに奔走しています。 2024年3月に20周年を迎えたヌーラボは、福岡本社に集まってGeneral Meetingという国内の従業員が一堂に会するイベントを行いました。そんな対面で話す機会も後押しとなってPlatform Engineeringチームを増強、メンバーを新たにスタートを切ることになりました。 今回は、現在のヌーラボのPlatform Engineeringチームがどのような活動をしているのか、直近の課題やロードマップに組み込んでいる計画など、ありのままをお伝えします。 ヌーラボのPlatform Engineeringチームの歴史 これまでは、主力サービスのプロジェクト・タスク管理ツール「Backlog

こんにちはBacklogの生成AIチームのテリーです。 先日Scrum Inc.Japanの認定スクラムマスター研修を受けてきましたのでその内容をこのブログにまとめます。 スクラムマスターの研修に興味を持っている方などのお役に立てる記事になればと思います。 研修について Scrum Inc.のスクラムマスター研修は、Jeff Sutherland、スクラムの共同創設者によって設立された組織によって提供されるプログラムです。この研修は、参加者にスクラムフレームワークの深い理解を提供し、実践的なスキルを身につけさせることを目的としています。 研修を完了すると、参加者はScrum Inc.からスクラムマスターの認定試験を受ける資格が与えられます。私はまだ認定試験の受験はしてませんが、これから時間を作って受けたいと思います。 内容について この研修では、スクラムフレームワークの基本原則や実践方法に

こんにちは、ヌーラボのウェブサイト課でフロントエンドエンジニアをしている東尾です。2024年からヌーラボのウェブサイト課が中心となって取り組んでいるアクセシビリティの取り組みを共有します！ きっかけは昨年のアクセシビリティカンファレンス福岡に参加したチームメンバーたちからの共有です（当時はまだ私はヌーラバーではなかったため、参加していませんでした）。伊原力也さん・柴田宏仙さんの発表「ウェブアクセシビリティ社内教育のすゝめ 〜品質か、営業か〜」の中で、「どんな小さなことでもまずはアクセシビリティに関して取り組んでいることを発表していく」ことを推奨する趣旨のお話をされていたと聞いています。 サービスは約20年の歴史がありますが、ヌーラボではアクセシビリティに関する取り組みはまだ始めたばかりです。改善としては小さいもの、中には今や当たり前に対応しなければいけないものもあるかもしれません。しかし、

こんにちは。Backlogチームの内田です。 ※このブログは ヌーラバー ブログリレーfor Biz 2023 の11日目の記事です。 私は現在42歳で、40歳にして結婚し、子供が生まれました。この新たな節目で、私は家庭をより効果的に管理するためのアプリ「ファミリーログ」を開発しました。 アプリはiPhoneユーザー向けにこちらから、Androidユーザー向けにこちらからダウンロードできます。 ファミリーログのサイトはこちらから。 私はBacklog利用者歴2年、利用者・開発者歴9年の超ヘビーBacklogユーザーです。Backlogの利便性に触発され、その利点を家庭管理アプリにも応用することにしました。 Backlogの素晴らしい点「オールインワン」 Backlogの素晴らしい点の１つは、「オールインワン」な機能です。タスク管理、Wiki、Git、ファイル共有といった多岐にわたる機能が１

この記事では、Backlog クラシックプランからの移行フローリニューアルの開発プロジェクトで、 Playwright を使いテストデータの作成を自動化したことについて紹介します。 今回、初めて Playwright をさわってみたのですが、複雑な手順をわかりやすいコードとして表現できるのがとても便利だったので知見と今後の課題をまとめます。 要約 テストデータの作成に時間がかかり、十分に手動テストができていなかった Playwright などのツールを使って自動化することで、効率よく不具合を発見できるようになった 継続的に E2E テストとしてメンテナンスしてゆくためにはさらに工夫が必要 開発を進める上で感じた課題 仕様変更によって多くのテストデータを用意する必要が発生した このプロジェクトでは、開発チームが中心となって大まかなフローや画面設計を作っていました。その一方で、画面上の文言やシ

Backlog Gitチームの中村です。去年まではBacklog Enterpriseチームにいましたが、今年からはGitチームへ異動してGit機能の開発・運用、「AI要約」機能の開発などをやっています。 Gitチームに異動してきてからオンボーディングを受ける中で、オペレーション作業時の手数の多さや、無視しているアラートがあることが気になりました。 Gitチームは以前から「タスクの属人化を減らそう」という流儀（ワーキングアグリーメント）を掲げていましたが、これらの要素は仕事の属人化につながると感じました。異動直後に感じたこれらの違和感をチームで共有し、少しずつ改善していきました。 また、Gitチームは3人で開発と運用の両方を担当しているため、運用にかかる時間が減れば減るほど開発に集中することができます。属人化を減らすとともに、自動化などによる運用の負荷軽減も行いました。 アラート対応の属人

SPAにするとNext.jsの嬉しさが半減しますが、/pages/以下のディレクトリ構造がそのままエンドポイントのパスに対応する、ディレクトリベースのルーティングをとても気に入っていたので、ほぼルーティングだけのためにNext.jsを使い続けていました。 今年（2023年）の春頃、高機能なNext.jsをルーティングのためだけに使いつづけるのはやはり違う気がする、と調べていて「ViteとReact Routerを使えば簡単にディレクトリベースのルーティングできるよ」という記事を見つけたのが、実はViteを知った最初でした。流行に鈍感…これが老化か…。 Simplifying Routing in React with Vite and File-based Routing Viteにはimport.meta.glob()という機能があり、トランスパイル時にディレクトリ以下のファイルを列挙し

ここ2年ほど、すっかりフロントエンド開発者になっている藤田です。以前、Reactフロントエンドの状態管理ライブラリRecoilについて記事を書きました。 Recoilで快適フロントエンド開発 Recoil Syncでさらに快適フロントエンド開発 その後どうなったかというと、実はRecoilからJotaiに乗り換えていて、半年ほど経ちましたので、Jotaiについて書きたいと思います。 サイトの一行目から「Recoilにインスパイアされた」と言ってるとおり、Recoilの良いところを受け継ぎ、不便なところを無くしたような状態管理ライブラリです。 Jotaiの基本 基本はRecoilとほとんど同じで、React.useStateを便利にしたような感覚で非常に簡単に使えます。3ステップで見てみましょう。 1. Providerで囲む アプリケーション全体を<Provider>で囲みます。 impo

はじめに こんにちは、ヌーラボの池です。ビジネスチャットツール Typetalk の開発をしています。 さて、先日ビジネスチャットツールの Typetalk はフロントのフレームワークを AngularJS から Angularバージョン2以降(以下、Angular2系という) へと移行しました。その際、発生したタスクが複雑な依存関係を持っていました。そのため、チームメンバーが次に着手すべきタスクを瞬時に判断するのが困難になっていました。今回はそういったタスクの依存関係を Backlog と Google スプレッドシートと Google Apps Script を使って整理し、次に着手すべきタスクが一目でわかるようにしたのでその事例を紹介します。 タスクの依存関係が把握しづらい問題について AngularJS の移行作業では各チームメンバーに割り振るタスクを、コード内に現れる”コンポーネ

1. サーバーサイドテンプレートをやめる Angular2系 において、エントリーポイントとなるHTMLファイルはバンドルされた JavaScript ファイルを読み込むだけの静的なHTMLファイルにするのが基本です。サーバーサイドアプリの動的データは Angular アプリケーション内で Ajax 経由で取得します。今回の移行作業ではサーバーサイドが動的データを含んだHTMLファイルをいくつか返していたので、それを AngularJS 内のコンポーネントに作り替える必要がありました。 2. コントローラーとテンプレートが1対1になるようにコンポーネント化する Angular2系 ではコンポーネントのHTMLテンプレート部分(*.component.html といったファイル)とロジック部分(*.component.ts といったファイル)は1対1に対応していますが、AngularJS は

はじめに こんにちは、ヌーラボの池です。ビジネスチャットツール Typetalk の開発をしています。 さて、先日 Typetalk はフロントフレームワークを AngularJS から Angular バージョン2 以降(以下、Angular2系という) に完全移行しました。移行作業は数年にわたる長期プロジェクトとなりましたが無事完了させることができました。今回はこのような長期間の移行作業にかかったリソースや、プロジェクトの進める上で行ったこと、得られたことについて紹介したいと思います。具体的に行った移行作業については別記事にまとめていますのでそちらをご参照ください。 AngularJS を Angular に移行する際に必要だった作業 アサイン時の状況 まず、私が移行作業にアサインされた時の状態からお話しします。AngularJS の移行作業は私がアサインされる2年ほど前に開始されてい

はじめに 先日話題になった「Webの将来はサーバサイドレンダリング（SSR）に回帰していく」という記事によると、Isomorphic /Universal JavaScriptのような、単一のコードでサーバーとクライアントの両方で実行できるアプリケーションを構築する手法が再び注目を集めているようです。そこで、本記事では以前書いたタスクボードアプリを題材として、Isomorphic RustなフロントエンドフレームワークであるLeptosを使ったサーバーサイドレンダリング (SSR) とハイドレーションを行う方法を紹介します。 なお、ソースコードはGitHubに上げていますが、前回のブログ記事からLeptosのバージョンが上がっており、前回から多少ソースコードを変更しています (本記事ではLeptos v0.2.4を使っています)。 前回のおさらいと今回の概要 前回作ったアプリはクライアント

こんにちは。Backlog 開発チームの madokan ことまどかんです。 このブログは、8月に実施した Backlog 内の Team Pasta のチームビルディングへの参加レポートです。 チームビルディングは、 Gallup 社の CliftonStrengths （ストレングスファインダー）というテストの座学編と Nintendo Switch の協力型ゲームで遊ぶ実践編との2部構成で実施しました。 なんとチームメンバー全員が実際に顔をあわせるのは今回がはじめてでした。 前編〜 Team Pasta の働き方 〜 さっそく当日のレポートの前に、前編として Team Pasta の業務の進め方について紹介します。 Team Pasta は、京都・愛知・福岡在住のメンバーで構成されていて、フルリモートで仕事をしています。業務はモブ（モブプログラミング）で行うことが多く、アプリケーショ

はじめに ヌーラボでサービス開発部長をしている馬場です。 自分が身につけた技術や知識を惜しげもなく技術ブログに書いているソフトウェア開発者がいます。かっこいいですね。憧れます。彼らのように、ソフトウェア開発者が技術ブログを書くことにはどのような価値があるのでしょう？僕の考えをまとめてみました。 人に教えることほど、勉強になることはない 僕が一番大きな価値だと考えているのは、技術ブログを書いてアウトプットすることによって、ソフトウェア開発者自身のスキルを向上させることです。 ブログを書くということはつまり、自分の知識をその読者に教えるということです。教えるという行為は教わる側だけではなく、教える側も学べることが多いのです。ピーター・ドラッカーも「No one learns as much about a subject as one who is forced to teach it. /人

本記事はブログリレーの8/8分になります。 こんにちはMakkyです。 会社が完全テレワークOKになって2年ちょっとが経ちました。 ヌーラボは出社したい人は出社してもOKという感じなんですが、家で仕事する人が多いので、各々自分の仕事環境が思い思いのものになっています。 こうなると、他の人の仕事環境ってやっぱり気になりますよね？ 以前はオフィスに出社していたので同僚のデスクが視界に入ったりして、なんとなく使ってるマウスやキーボードを知っていたりしたんですが、そういうことも無くなったので今回マウスとキーボードの動向を調査してみました！ こういうのってエンジニアの人が対象になりがちですが、せっかくなのでいろんな部署の人にアンケートをとってみました。 ※複数使ってる人も想定して「仕事で使ってるメインのもの」としています 調査概要 対象者: ヌーラボ日本拠点所属社員（部署は問わない） 回答数: 77

CacooチームのKawabataです。本記事はヌーラバーブログリレー2022の8月4日分の記事です。 本記事では、自作のツールのバグのせいで悔しい思いをしつつも、改善につなげた話をします。あくまで個人的に作っているツールについての話なので、ヌーラボでの業務とは無関係です。記事を通して会社で働きながらも盆栽いじりのように個人開発を行うエンジニアライフの楽しさや大変さが伝われば幸いです。 ツールのバグによって、妻の仕事のデータを吹き飛ばしてしまいましたが、File System Access APIを使って改善につなげました。ヌーラボには個人開発倶楽部という部活があり、個人開発者同士で作ったものを紹介したり情報を共有したりしてお互いにモチベーションを高め合っています。 私は個人的にプレゼン動画作成ツールを作っています。簡単に説明すると「プレゼンテーションのスライドに音声を録音して、一本のプレ

SRE課で、主にBacklogのSREを担当しているMuziです。 物理サーバやインスタンスで動作していたアプリケーションを、Kubernetesクラスタに移行する際には、いままで暗黙的に存在していた前提に目を向ける必要があります。そのような前提を無視すると、アプリケーションは動作したとしても、可用性が悪化する可能性があるためです。 私たちがBacklogをEC2インスタンスからKubernetesクラスタに移行した際にも、可用性の悪化に繋がる問題に対処する必要が生じました。今回は、そのような問題の一つであるGraceful Shutdownに関する注意点を、私たちの実体験をもとにご紹介します。 なお、以下の内容はAmazon EKSのKubernetesバージョン1.22で確認しました。Amazon EKSに固有の話題も含みますが、Kubernetes全般に共通する部分も多いかと思います