みなさんはモノづくりが好きですか？私は好きです。モノを作る過程は楽しいですし、自分の作ったモノが世の中を良くできたら嬉しいですし、うまくいったらお金ももらえます。最高ですね。起業する前の個人開発時代から考えると約15年間モノづくりに関わっておりますが、上記の理由から私としては今後も関わり続けたいという想いがあります。そんな私がモノづくりの最前線に立ち続けるため何をやっているのかを今回はお話します。

今回は、社内で利用しているWebブラウザベースのVoIPサービス「CallConnect (以下、コールコネクト)」における通信不安定の問題と、その解決に至る過程を共有します。TechouseではWebブラウザベースのコールコネクトを利用し、セールス担当者・カスタマーサクセス担当者・キャリアアドバイザー担当者とお客様との間の連絡にフル活用しています。Webブラウザからコールコネクトの画面を開いてボタンをポチるだけでお手軽に外線電話をかけられるので大変重宝しております。

定義：主体とは「ものごとに変化を生み出す力の源泉」である「主体性がある」とは、ものごとに変化を与える性質があるということである。 「主体的である」とは、ものごとに変化を与えようとする振る舞いをしているということである。主体というのはエネルギーの流れでありエネルギーの固まりである。 主体はいろんなものに宿る。

最近関わった機能開発において、JavaScriptを使ってフロントエンドのコードを書く機会がありました。本記事では、そのJavaScriptコードの単体テストを書く際に苦戦した理由と、テストを書きやすくするために行った工夫を書いていきます。Jestは、JavaScriptのテストフレームワークです。クラウドハウス労務では今年からJestが導入され、新規に開発された機能については単体テストが書かれていますし、インターン生を中心にテストが書かれていない既存の機能のテストを書くプロジェクトが進行しています。ソフトウェアの品質を継続的に保つためには自動テストは不可欠です。特に、クラウドハウス労務のような短いスパンでのリリースを繰り返すSaaSプロダクトでは、新機能のリリースに伴うデグレードを回避するために自動テストは殊更重要です。私たちのチームではテスト駆動開発が推奨されており、コードレビューの際には、テストが欠けたコードをリリースしようとすると必ず指摘を受けます。

Techouse では AWS をフル活用してサービスを提供していますが、利用しているサービスの1つに Amazon Neptune があります。 Amazon Neptune 、ご存知でしょうか？ Amazon Neptune は高速かつ、高い可用性とスケーラビリティをもつフルマネージドのグラフデータベースサービスです。といっても、そもそもグラフデータベースがどのようなものかご存知でない方も多いのではないでしょうか。 本記事では、実際に弊社の SaaS プロダクト「クラウドハウス労務」に Amazon Neptune を導入した事例を紹介し、 RDB との対比で Amazon Neptune (グラフデータベース) がどういったものかをご紹介したいと思います。

今回はクラウドハウス労務のメンテナンス中に起きた事件と、今後同じ事件が起きないようにするために講じた対策について紹介します。ある日私たちはデータベースのメンテナンスを行いました。来たる新機能のために必要な新規テーブルを追加したり、既存のテーブルに変更を加えたりするメンテナンスです。メンテナンス当日、新規テーブルは次々と作成されていき、順調に思われました。しかし異変は急に訪れます。マイグレーションがいつまでも終わらないのです。どうしてここまで時間がかかるのか。私たちは急いでログを確認しにいきました。ログを確認したところ、あるALTER TABLE文の実行にとても長い時間がかかっていました。対象テーブルは1000万レコードを超える巨大なテーブルだったため、変更に膨大な時間がかかってしまっていたのでした(終わりそうになかったので当日はプロセスを中止し、後日時間のかからない方法で完了させましたが、データベースのクローンを用意して同等のSQLを実施したところ完了まで3時間30分かかりました)。

弊社では、大企業向けのSaaSプロダクトを複数運営しており、安定した品質で日々のサービスを提供するために、プロダクトのコーディングにおいてテスト駆動開発（TDD）を推進しています。また、継続的インテグレーション（CI）を導入することで、テストに通らないコードがmainブランチにマージされないように管理しています。そのため、インターン生たちはまず研修でテスト駆動開発（TDD）の基礎を学んだ後、各プロジェクトにアサインされます。本記事では、私自身があるプロジェクトでTDDを活用したリファクタリング作業中に、ソフトウェアテストに対する誤った思い込みから生じたミスについて振り返り、その教訓を共有します。

本記事では、私が弊社で主催したイベント「テスト技法勉強会 2024」を紹介します。ソフトウェア開発に必要な、基礎的なテスト技法の習得を目的とした勉強会です。解説だけでなく演習にも重きを置き、業務にもすぐ生かせるような実践的内容を取り扱っています。今年度開催した「テスト技法勉強会 2024」では、弊社に所属する学生エンジニア22名が、ガッツリ1日かけてテスト技法を習得しました。

今回はパフォーマンスモニタリングの強化のために導入した APM(Application Performance Monitoring)サービスの AWS X-Ray と RUM(Real User Monitoring) サービスの Amazon CloudWatch RUM をご紹介させていただきます。ウェブアプリケーションのユーザー体験を向上させるうえで、パフォーマンス監視は欠かせません。特に、複雑なアーキテクチャを持つアプリケーションでは、問題の原因を迅速に特定することがビジネスの成功を左右します。AWS X-Ray と Amazon CloudWatch RUM を活用すれば、フロントエンドからバックエンドまでを包括的に監視し、最適化が可能です。本記事では、実際の使用例を交えながら、この2つのツールを使いこなす方法を解説します。

こんにちは。2024 年 5 月からインターン生として開発に携わっている maczac150 です。 先輩方から受けるコードレビューの中で、命名についてのご指摘を頂くことがあります。自分はネーミングセンスが良くないからなあと思うときはありますが、磨けるものだそうです。Ruby の生みの親である、まつもとゆきひろさん曰く、「名前は理解の試金石」だそうで、「適切に名前を付けることができる」と「その概念を理解している」は近いと述べています。逆の言い方をすれば、良い名前が付けられないのは、その概念をきちんと理解できていない可能性があるということですね。確かに思い当たる節はあります。Techouse のインターンを始めるまでは、「自分が分かればいいや」くらいの気持ちで命名していましたが、そんな適当な考え方がまかり通るはずがありません。今回は普段の業務で得た、命名に関する教訓を書いてみたいと思います。

この記事では自身が携わっているプロダクトであるクラウドハウス採用のデザインや実装をしていく中で、参考にしていた本やサイトの話をさせていただきます。こんな方に読んでいただけると幸いです。デザインに興味はあるものの、何から学べばいいか迷っている方。作っているプロダクトの使い勝手をもっと良くしたい方。「デザイン」というと、色や形、サイズなど表に見えるもののみを指すようなイメージがあるかと思います。ですが、それらはデザインの中のビジュアルのみを指しており、デザインを構成している要素としては不十分です。

先日初めてテストを書く機会があったのですが、私は書き方を習得するまでに非常に苦労しました。そこで今回は初心者の目線で、テストを書くときに苦労した話を書こうと思います！私と同じような未経験エンジニアの方々は共感してくれるのではないかと思います。エンジニア歴が長い先輩の方々も未経験のエンジニアのオンボーディングをする時にも役に立つかもしれません。私たちTechouseのインターンは研修の学習資料としてRuby on Rails チュートリアルを使用します。こちらにはテストについての記述があり、そこでテストに関する知識は身につけましたが、その重要性には気づけていない状態でした。数ヶ月テストを書いてきましたが、まだ私の知らないテストの大切さや便利さ、奥深さがあるのだろうと思います。さて、まずは今回自分がテストを書いたときのタスクについてお話しします。

Techouse では技術責任者の山崎による任意参加の社内勉強会を隔週で行っており、そこでは OS・ネットワーク・データベース・ハードウェア・セキュリティ・システムアーキテクチャなど、エンジニアとして基礎的な知識が学べます。ここで先日、メカニカルシンパシー(2) 命令レベル並列性というタイトルの勉強会が開催されました。この勉強会でメモリのキャッシュラインへのヒット率による実行時間の違いを学んだ時に気になることがあり、調べてみたら面白いことがわかったので紹介させていただきます。

弊社では、数万件におよぶ自動テストをGitHub Actionsを利用してランダム実行しています。並列実行されるテストにおいて、特定の順序で実行されると一部のテストが失敗するケースがありました。私がその原因を調査し、修正に取り組むことになったのですが、この失敗は、STI（Single Table Inheritance）を使用したデータベース設計と関連していることがわかりました。本記事では、その問題の詳細と解決に至るまでのプロセスを紹介します。並列実行されるテストでは、テスト間に依存関係がある場合や、同一のデータベースリソースにアクセスする場合に競合が発生し、実行順序によって予期しないエラーが発生することがあります。特に今回、STIを使用しているテーブルで発生した競合が原因となり、テストの失敗に繋がりました。

現在環境変数を使って秘密情報を渡す手法は非推奨となっており、Docker Secretsを利用してコンテナに秘密情報を渡す手法が推奨されています。これはなぜでしょうか。本記事では、Docker Secretsを活用して機密情報を安全に受け渡す方法について解説します。そしてなぜこの取り組みが必要なのか、どのような理由でDocker Secretsを用いる手法が推奨されるのかを説明していきます。まず、環境変数を使って秘密情報をコンテナに渡す方法にはいくつかの問題点が存在します。生成された子プロセスは環境変数に対するアクセスが可能です。そのため、サードパーティのツールを呼び出す際など、予期せぬ子プロセスが秘密情報にアクセスする可能性があります。

Techouseに入社して純粋に思ったこととして、「セキュリティ意識が高いなぁ…」と思いました。過去に勤務した経験のあるどの組織よりもセキュリティ意識がしっかりしていると感じました（もちろん近年はセキュリティ意識をより求められているというのもありますので、これまで勤めた組織もセキュリティ意識は向上していっているとは思います）。お客様の情報をはじめとした情報資産の保護について、弊社の情報セキュリティ方針を掲げるだけでなく、しっかり実行していくということに矜持を感じました。そのような組織で働くと、自然と自分自身も同様の視点を持つようになります。そこで今回は、その視点を踏まえたうえでCI/CDに着目し、改善に取り組むことにしました。

弊社が提供するATSサービス『クラウドハウス採用』では自由度高くウェブサイト制作が可能という特徴があります。画像も自由に利用することができるため、１ウェブサイト作るのに少なくとも50ファイル以上の画像を利用されるお客様がほとんどです。その際、大変になるのが画像のアップロード作業。現在の仕様ですと「ひとつ選択してアップロード」をファイル数分繰り返す必要があります。これをデザイナーにクラウドハウス採用の管理画面を開く手間を掛けさせず解決できないかという想いで試してみたのが今回のFigmaプラグインでの画像アップロードとなります。

先日、新機能の開発を進める中で、ファイルへの書き込みを扱うコードを書く機会がありました。その際、Ruby でファイル書きこみを行う際のバッファリングの仕組みと、それを制御する IO#flushとIO#fsyncというメソッドに改めて注目することになりました。本記事では、これらのメソッドがどのような役割を果たし、どのような場面で利用すべきかを紹介します。

私事ですが、この秋に、2ヶ月ほど「ペアプログラミング」なるものを初めて行いました。今回はその経験をまとめるとともに、ペアプロの魅力について自分なりに語って参ります。24年10月に新卒入社する直前までインターンとして働いていた私ですが、年末調整で重要な機能部分を幾つか任されることとなりました。苦労していた8月ごろ、突如とんでもないチャンスが降ってきました。

本日は私の携わっているプロダクトであるクラウドハウス労務で行っているエンジニア長期インターン生のオンボーディングの効率化について紹介します。

今年5月、Techouse は「RubyKaigi 2024」に参加しました。RubyKaigi 2024 への参加はとても勉強になることが多く、エンジニアとして成長に対してとても有意義な時間でした。そこで、社内でも「成長や挑戦につながるイベントを企画してみよう！」ということで、社内イベントを企画する運びとなりました。

弊社Techouseには、素質ある多くのエンジニアインターンが在籍しています。エンジニアインターンの文化については、こちらの記事をご参照ください。彼らは将来優秀なエンジニアになることが期待される「金の卵」であり、各事業部に配属されています。しかし、基本的に実務経験がない状態でのスタートとなります。実務経験を通して成長できる部分は多々ありますが、それだけでは補いきれない知識やスキルが求められる場面も多くあります。さらに、弊社の各事業部のサービスは規模が大きいため、勉強不足だと大規模開発に求められる以下のような知識が不足しがちです。

今回は、localStorage に保存された値を検証する場面で、Zod の parse 関数を利用した方法を紹介します。筆者はこれまで localStorage から取得した値のパースに、JSON.parse を使っていましたが、Zod の parse 関数と組み合わせることで、より型安全に値をパースできました。

みなさんはRBS::Inlineをご存知でしょうか。 RBS(Rubyに型システムを導入するインターフェース言語)をコメントから生成出来るようにしたものです。 先日参加したRubykaigi 2024 follow upというイベントでRBS::Inlineを知り、これはいいものだと早速私は会社のPRに勝手にRBS::Inlineを混ぜました。 そうしたらレビューでこんなコメントが・・・

本記事では、私が設計・実装を担当した2FA機能について、開発中に得られた知見や学んだことについて紹介します。クラウドハウス労務では企業向けの人事労務管理サービスを提供しています。利用企業は従業員に対してアカウントを払い出し、従業員は自身のアカウントにログインして各種労務手続きを行います。クラウドハウス労務のログイン方式には外部サービスであるAuth0を利用したOpenID Connect(以下OIDC)を利用しています。OIDCには認証機能を提供するIDプロバイダー(以下IdP)、サービスを提供しているリライングパーティ(以下RP)の2つのアクターが登場します。OIDCではRPに認証の機能を持たせずIdPで認証情報を一元管理をしており、それによってRPが得られる利益はたくさんあります。

Ruby on Rails の Active Storage はお手軽に画像ファイルなどをクラウドストレージに保管できる便利なライブラリです。しかし正しく利用するにはクラウドストレージの仕様やWeb標準への理解が必要不可欠です。今日はそんなActive Storageを使って、Amazon S3 に画像ファイルを保存するというありがちなパターンで色々沼った話をしようと思います。

私が携わっている開発チームの中には、現在20名近くのインターン生が在籍しております。インターンは企業によってさまざまな形態がありますが、Techouseのインターンは、長期インターン（本人の希望にもよる、大学・大学院を卒業するまでずっと）である、プロダクト開発がたくさんできる、という特徴をもっており、インターン期間中に私も驚くほどの成長を遂げています。今回は、どうしてTechouseエンジニアインターン生が、圧倒的な成長ができるのか、開発チームマネージャの私の視点から述べようと思います。

本日は、異なる Amazon ECS Service のコンテナイメージの整合性を確認するために Sidekiq Middleware を使用した話を書きます。クラウドハウス労務は、企業の人事労務業務を支援するクラウドサービスです。企業に属する従業員の情報を集めるため扱うデータの量が多く、企業の基幹システムと連携するためのエクスポート処理などでは大量のデータを一度に扱う必要があります。こうした機能を、クラウドハウス労務では Sidekiq という Ruby の gem を活用した非同期処理により実現しています。クラウドハウス労務では AWS の ECS(Elastic Container Service) によりコンテナを管理しており、ユーザーからのリクエストを受け取るアプリケーションサーバーも Sidekiq のプロセスも ECS のコンテナ上で動作しています。

先日、自身の参画しているプロジェクトの Ruby のバージョンが 3.3.5 に更新されました。これに伴い、手元の開発環境にも Ruby 3.3.5 を install しようと思いました。 開発環境では Ruby のバージョン管理マネージャとしてrbenvを利用しております。

今回の記事では「エンジニア100人に聞きました」を実施いたします。 「エンジニア100人に聞きました」とは、10年以上前にサイボウズ社を中心に行われた会社を跨いだコラボ企画であり、各社のエンジニアの気風を紹介し合った取り組みになります。