はじめに TypeScriptで開発していると、エラーハンドリングの難しさに直面することがあります。 定番のResult型やEither型などの素晴らしいアプローチもありますが、これらは導入コストが高く、チーム全体に浸透させるのが難しいこともあるでしょう。 本記事では、小さく始められてチームに浸透させやすい、Branded Typeを使って型安全なエラーハンドリングを実現する方法を紹介します。 自己紹介 カミナシ StatHackカンパニーの かわりくです！ 普段は食品表示ラベルをAIで検査するプロダクトを開発しています！ kaminashi.jp note.kaminashi.jp TypeScriptの例外処理の問題点 1. catchブロックのerrorはunknown型になる const invalidJson = '{"name": "John",}'; try { const

はじめに こんにちは。カミナシでソフトウェアエンジニアをしている tokuse(@stomy_13) です。 私が所属するチームが開発している現場帳票システム『カミナシ レポート』では、一部のアプリケーションで状態管理ライブラリの Zustand を使用しています。併せて Zustand の Immer middleware も使用しています。開発を進める中で Immer の内部実装を調査する機会がありました。 Immer は React の状態管理や Redux などと組み合わされて使われることが多く、多くの開発者に愛用されています。しかし、その便利さの裏にある仕組みについて詳しく知っている方は意外と多くはないと思います。 この記事では、Immer がどのように実装されているのか、その内部構造や仕組みのコア部分を簡単に解説します。 Immer とは Immer は「不変性を持つデータ構造

こんにちは。ソフトウェアエンジニアの古屋です。データベースのメトリクス、見てますか？私のチームが開発運用を担当する『カミナシ レポート』では Amazon Aurora MySQL をメインのRDBMSとして利用しています。この Aurora MySQL について少し課題がありました。 課題1. 増え続けるコスト 昨年の12月以降くらいでコスト、とくに Aurora:StorageIOUsage が右肩上がりで増えています（図の青色）。 課題2. 悪化するパフォーマンス （実際に運用されているのを初めて見たのですが）『カミナシ レポート』で利用している Aurora クラスターはCPU利用率（しきい値：60%）に基づいたオートスケールの設定がされており、アクセスのピーク帯になると負荷に応じて自動的にスケールアウトするようになっています。ただ、スケールアウトしてもパフォーマンスがよくなってい

こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。インターネットの根幹を支えるドメインと DNS の仕組みが好きです。 ところで、みなさんの会社ではドメインや DNS レコード（リソースレコード）をどのように管理されていますか？ カミナシでは以下のような課題を抱えていました。 運用・管理面 複数のレジストラでドメインが取得されていたため、異なる管理画面の操作方法や請求書の連携で手間がかかっていた DNS レコードのほとんどが手作業で追加され、それらのレコードが登録された経緯や目的の記録が残されていないものが多数あった。加えて、棚卸しの実施が不十分で、必要性が不明確なレコードが多数存在していた セキュリティ面 一部のレジストラにおいては、きめ細やかな権限管理機能が提供されておらず、ID とパスワードを共有せざるを得ない状況であった。結果として、CTO がこれらに関

どうもセキュリティエンジニアリングの西川です。禁酒しています。誘惑多い GW を超えたので勝ったも同然です。とはいえ、お酒は飲まずとも酒の場は好きなのでお気軽に誘っていただけると嬉しいです。 さて、今日はカミナシで去年より実施している Production Readiness Check についてお伝えできればと思っています。 Production Readiness Check とは何か プロダクションレディマイクロサービスという書籍が出ています。書籍の紹介に下記のようにあります。 UberのSRE（サイト信頼性エンジニア、サイトリライアビリティエンジニア）として、マイクロサービスの本番対応向上を担当していた著者が、その取り組みから得られた知見をまとめたものです。モノリス（一枚岩）を複数のマイクロサービスに分割した後に、安定性、信頼性、スケーラビリティ、耐障害性、パフォーマンス、監視、ド

カミナシのソフトウェアエンジニア佐藤です。カミナシレポートの開発に携わっています。 フロントエンドのエラーは「画面リロードやブラウザ再起動で復旧できる（かもしれない）」「クラッシュしてもユーザーの端末に閉じる」などの理由から、バックエンドよりは精緻に扱われない傾向があると個人的には感じています。 その一方、カミナシレポートは、ノンデスクワーカー向けの不安定なネットワーク環境で利用されることも多々あるアプリです。そのため、デジタルツールに不慣れな方のために精緻なフィードバックが必要とされる、リロードに頼ることが難しいケースがある、などの理由でエラーの扱いにも慎重になる必要があります。 本記事では、カミナシレポートのフロントエンド開発をする中で、 バックエンドの API コール時にエラーが発生する条件とその内容（型・クラス） これらエラーをハンドリングする箇所 について、把握しておきたいと感じ

TOPインタビューなぜ「プレイヤーの自分」と決別できたのか。「技術に詳しい経営者」が、本当にやるべきこととは｜カミナシCTO原トリ 株式会社カミナシ　取締役CTO 原トリ 大学を卒業後、ERPパッケージベンダーのR&Dチームにてソフトウェアエンジニアとして設計・開発に従事。クラウドを前提としたSI+MSP企業で設計・開発・運用業務を経験し、2018年Amazon Web Services入社。AWSコンテナサービスを中心とした技術領域における顧客への技術支援や普及活動をリードし、プロダクトチームの一員としてサービスの改良に務めた。2022年4月カミナシ入社、2022年7月よりCTOに就任。 X（Twitter） ノンデスクワーカーのDXプラットフォームSaaSを開発・提供するカミナシ。2024年8月～2025年2月の間に3つの新規プロダクトをリリースし、2025年1月には元DMM社のpos

どうもセキュリティエンジニアリングの西川です。JAWS DAYS 2025 の帰路でこのブログを書いています。私は空港でブログを書く確率が非常に高いです。なぜか捗るんですよね。 さて、カミナシでは昨年からセキュリティエンジニアを二人追加で採用することができ、業務委託含め5人体制になりました。それを機にセキュリティエンジニアを開発チームに派遣する仕組みを導入したのでそれについて話をしていきたいと思います。 セキュリティエンジニアを開発チームに派遣するとは 派遣するセキュリティエンジニアの目指すところを一言で表すならば「特定のサービス・プロダクト・チームを深く理解したセキュリティエンジニア」です。 派遣されるセキュリティエンジニアは基本的には最初の半年から1年程度は開発チームの1メンバーとして、ともに開発や運用を行います。ですので、障害対応やインシデント対応、お客様からの通常のお問い合わせなど

カミナシ ソフトウェアエンジニアの mina（@yoiyoicho）です。このブログでは、私が所属する「カミナシ ID」開発チームにおいて実施した、インフラコストの最適化施策について紹介します！ 「カミナシ レポート」の認証機能移行によりインフラコストが増加 「カミナシ ID」は OIDC / OAuth 2.0 などの標準仕様に準拠した、カミナシの ID 管理・認証基盤プロダクトです。インフラは AWS の各種サービスを活用して構築されています。 「カミナシ ID」は認証基盤という性質上、高いセキュリティや監査能力が求められます。そのため、API サーバーのアプリケーションログに加えて、データベースに対する操作やアクセス履歴をすべて記録した監査ログなど、各種ログを詳細に出力しています。これらのログは一度 CloudWatch Logs に集約され、Kinesis Data Firehos

カミナシで、Webフロントエンドエンジニアをしている osuzu です。 これまでフロントエンド専門外のエンジニアからReactを学ぶ良い方法やお勧めドキュメントを聞かれる度に、 公式ドキュメント のリンクを貼る日々を過ごしてきましたが、何かすごい上達方法がないものかと普段意識していることをこの記事で書き起こしてみました。 文字にした結果、中身になにか特別なことや魔法のテクニックは一つもなく、むしろプログラミング一般に通ずる話ばかりになりましたが、（自戒も込めて）凡事徹底することの難しさもあると感じておりその一助になれば幸いです。 ※ 凡事徹底：平凡なことを非凡なほどに実行すること。一つ一つの理解や実行は平易でも、それを実践し続けるのは難しい。 React Server Component（以下RSC）を採用するかで変わる部分もありますが、記事の例はClient Componentの話が中

カミナシ CTO のトリ(@toricls)です。気づけばカミナシへのジョインからもうすぐ丸3年です。会社からジョイン1,000日記念のプレゼントをもらいました。 ここ1年のカミナシ社ここ1年のカミナシは新製品のリリースラッシュです。2024年夏には「カミナシ 従業員」と「カミナシ ID」の2つ、2025年に入ってすぐの1月に「カミナシ教育」、そして翌月2月には「カミナシ 設備保全」と、短期間に複数の新製品をリリースし、2020年からのプロダクトである「カミナシ レポート」含め、現在もそれぞれが兼務のない安定したチームでスピード感を持って継続的に改善を続けています。 カミナシ社が全体として向かっている方向や、各サービスへの思い入れなどなど、いろいろ書きたくなる溢れ出る思いはあるのですが、このあたりについては最近公開した CEO 諸岡の記事や COO 河内の記事がそれぞれとても良い記事なので

プレイングマネージャー型のEMをしています、鈴木（@szk3）です。 今回は、私たちのサービスチームが新規プロダクト開発を始めるにあたって「スクラムを導入しなかった」経験について共有します。 このタイトルだけを見ると、スクラムに対して否定的な印象を持たれるかもしれません。しかし、これはスクラムへのアンチテーゼではありません。むしろ、スクラムの価値をリスペクトし、その実践に真摯に向き合いたいからこそ行った慎重な決断でした。実際、新規プロダクト開発の開始とほぼ同時期に認定スクラムマスター資格も取得し、スクラムについての理解を深めていく中で、この決断の意義をより一層実感しています。 新規プロダクトの開発において、アジャイル開発を取り入れることは当然の選択肢として考えられます。むしろ、アジャイル開発の実践にスクラムのフレームワークを使うことは、実質上のスタンダードとなっていると感じます。しかし、「

1. はじめに こんにちは。QAエンジニアとして働いている市川です。 今回は、私が所属しているカミナシ設備保全サービスチーム（以下サービスチーム）で「チーム全体で品質を考える文化づくり」を進めるために行った取り組みについて紹介します。 チーム構成は、エンジニア2名、デザイナー1名、PdM1名の体制で、私は昨年末からチームにスポットで参画して取り組みを進めてきました。 私が取り組んだことは大きく分けて以下の3つです。 QAやテストの考え方を伝える座学セッション 品質を考えるワークショップ 設計ワークへの参加によるコラボレーションの強化 これらの活動の背景には、「プロダクトの品質はQAだけで担保できるものではなく、チーム全員が品質に対して主体的に取り組む文化が重要」という考え方があります。 まだすべてが解決できたわけではありませんが、まずは1チームでトライしてみたプロセスを共有したいと思います

はじめに カミナシでソフトウェアエンジニアとしてサービスの開発をしている Taku (X アカウント) です。 帰国後の体調不良等あり公開が遅くなってしまったのですが、先日ラスベガスで開催された AWS re:Invent に2年振り2回目の参加をしてきた際のレポです。 今回の re:Invent で私は 生成 AI 系のワークショップを中心に受けており、前回の Amazon Bedrock のワークショップに続き Amazon Q Business のワークショップも受けましたので両方受けて思ったことを書かせていただきたいと思います。 筆者は生成 AI にそこまで精通しているわけでありませんので、もし誤り等あればご指摘いただけますと幸いです。 Amazon Q Businessとは Amazon Q は AWS の生成 AI 系サービスの一つで、生成 AI を利用したアシスタントです。

こんにちは。カミナシで「カミナシレポート」の開発を担当しているソフトウェアエンジニアの佐藤です。 カミナシレポートのバックエンドは Go で開発しており、データベースには Amazon Aurora MySQL を使用しています。また、データベースアクセスには ORM ライブラリの GORM を採用しています。 ほとんどのテーブルでは、プライマリキー（ID列）に AUTO INCREMENT を利用しています。これらのテーブルに GORM の Create メソッドなどを使って新しいレコードを挿入すると、AUTO INCREMENT で採番された値が自動的に対応する Struct のフィールドに反映されます。 AUTO INCREMENT による値の採番は MySQL 側で実行されているため、Go 側の Struct のフィールドに反映させるためには、Go アプリケーション側が何らかの方法

「しかたないスクラム」じゃないアジャイル開発を求めて はじめまして。1月からカミナシでエンジニアリングマネージャ（EM)を担当している @daipresents と申します。 カミナシでは新規事業開発のEMとして、絶賛全力で開発を支援しています。カミナシはとても現場に近い開発環境なので、ご興味のある方はぜひカジュアル面談 をお願いします！ この記事では、僕が関わる「新規事業開発」で実際に行われている「開発プロセス」と、そこに行き着いた経緯や意図をまとめたいと思います。タイトルにあるように、チームは「スクラムじゃないアジャイル開発を求めて」きたように感じています。 チームの立ち上げ期 僕は10ヶ月ほど前から業務委託として参加しており、現在のチームに入る前に、別のチームの支援も行っていました。そこではスクラムが採用されていて、試行錯誤しながら自律したチームを目指していました（今もがんばっていま

どうもセキュリティエンジニアの西川です。これがきっと私にとっての今年最後のブログです。今年の AWS re:Invent は自身の登壇があったのでほとんど楽しめませんでした。悔しいのでこうしてブログを帰ってきてからいくつか書いています。カミナシのメンバーの中で私と CTO だけは自腹で AWS re:Invent へ参加していますが、来年の飛行機もすでにとっていたりします。来年ラスベガスでお会いしましょう。 AWS re:Invent の中でもたくさんの Generative AI のセッションがありました。私自身はほとんど参加していなかったのですが、Generative AI の GameDay に出たことをきっかけに Generative AI 意外と難しくないなと思い、Security Hub の通知をアクショナブルに変えてエンジニアの誰しもが対応できるようにしてみようと思ったのが本

こんにちは。カミナシでソフトウェアエンジニアをしております佐藤です。 先日、『カミナシ レポート　記録アプリ（Web）』の提供を開始いたしました。 現場帳票システム『カミナシ レポート』、マルチデバイスで記録ができるWeb版をリリース PWA として利用が可能であり、また、ネットワークが不安定な現場での使用も想定したオフライン機能も備えています。これらを実現する上では、Service Worker が重要な役割を果たしています。 『カミナシ レポート　記録アプリ（Web）』の実装には、VitePWA を利用しています。VitePWA では Service Worker の制御に Workbox が使用されています。 Workbox は Service Worker の扱いをよしなにやってくれる非常に便利なライブラリなのですが、正しく活用する上では、やはり、Service Worker その

「ディスカバリーとデリバリーの接続をスムーズにしたい」 プロダクトマネージャーやデザイナーからよく聞く話ではないでしょうか？ また、エンジニアからこんな話を聞いたことはありませんか？ 「ディスカバリーで決まったものを開発するだけになっている。まるで社内受託のようだ。」 migi（@migii000）です。 カミナシでプロダクトマネージャー（ PdM ）をしています。 以前、デザイナーの satoami さんとの協働について社内でインタビューしてもらいました。 この note では「チームの中では境界線を曖昧にしてオーバーラップしながら開発をしている」的なことを書きました。チームが発足して半年ほどですが、開発プロセスがかなり機能している実感があります。 どんなプロセスで何をやっているのか、私たちのプラクティスをまとめるのがこの note の目的です。 はじめに：ディスカバリーとデリバリーの接

こんにちは、「カミナシ 従業員」開発チームの a2 (@Atsuhiro_tim) です。 re:Invent については、弊社含め多くの企業のセッションレポートを目にしていることと思います。 re:Invent は新サービス発表のある基調講演や、実際に手を動かしてサービスを触れるセッションへの参加などがメインコンテンツですが、ラスベガスに一週間滞在する間、それらが全てではありません。異国に行くこと自体や、セッション以外にも面白いアクティビティなどがあります。 今回は、そういったセッション以外の側面にスポットを当ててみたいと思います。ゆるい記事なので、すきま時間に読んでいただければと思います。 Uber やチップなど、現地ならではの物から刺激を得る やはり日本から出るので、文化の違いを感じる点は re:Invent 参加の面白さの一つです。 ラスベガスの空港についてからホテルまでは Ube