こんにちは、セキュリティエンジニアリングの西川です。息子が8歳なのですが、生まれてからずっと可愛いままで、いつまでこの可愛さは続いてしまうのでしょうか。 ということで、今日はセキュリティの文化の作り方について話をしていこうと思います。 セキュリティの文化の作り方ってなんなんだろう と言いますか、日々私自身、手探りなのですが、今日は取締役CTOの原トリ（以下トリ）からもらった金言とともにカミナシにおけるセキュリティの文化の作り方について書いていきたいと思います。 カミナシにおけるセキュリティの文化の定義 その前にセキュリティの文化を定義していかなければスタートラインにすら立てないわけですが、カミナシにおいては、セキュリティの問題をセキュリティ担当者の介在なしに、自分たちで気付き、セキュリティの問題をお互い注意し合えるようになるという定義を行っています。これは開発だけではなく、コーポレートでも

こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシでは RDB に Amazon Aurora MySQL 2（MySQL 5.7 互換）を使っています（以下 Aurora MySQL と略します）。 ある日、社内の Slack で「𠮷」などの文字列が登録できないのではないかという話が出ました。これを聞いて「あー」と思った方も多いでしょう。 MySQL で有名な UTF-8 の 4 バイト文字問題で、歴史的な理由から MySQL 5.7 以前では utf8 の文字セットは utf8mb4 ではなく utf8mb3 を指しています。 dev.mysql.com カミナシのアプリケーションは 4 バイトの文字列が入力された場合はシステムエラーを返す実装になっていますが、エラーの内容をユーザーにわかりやすく伝えることは難しいためユーザー体験としても良くない

はじめまして、2023年6月よりカミナシにセキュリティエンジニアとしてjoinした西川と言います。今回はCTOのToriと私とで参加したAWS re:Inforceについて書いていきたいと思います。 re:Inforceとは AWSのセキュリティに特化したカンファレンスでEXPO、ChalkTalk、BuildersTalkなどのセッションが存在し、ハンズオン形式だったり、みんなで話し合ったり、さまざまな形での学びを提供しています。 今回のre:InforceはMLBの大谷選手が所属しているエンゼルスの本拠地があるアナハイムで開催されました。去年はボストンで開催されていたので、来年は大谷選手が見られる！？というのは期待しないようにしましょう。ちなみにre:Inforce開催の週はエンゼルスのホームゲームがなかったので試合観戦はできませんでした（涙） re:Inforceのセッション 講師の

こんにちは〜。カミナシでソフトウェアエンジニアをやっている飯間です。 04/27(木)・04/28(金)の 2 日間、開発合宿に行ってきました！ この記事はそのレポートとなります。 合宿の目的・やったこと 今回の目的は以下の 2 点でした。 「β版マインド」発揮の場を提供する チームビルディング 1 の「β版マインド」というのはカミナシのバリューの一つです。これについては、弊社公式の説明をそのまま引用しますが以下の通りです。 “限られた時間や情報の中で、最大限考え尽くしたなら、すぐに一歩を踏み出そう。100%の確信を待っている時間はもったいない。 成功も失敗も前倒しして、そこから学べばいい。その繰り返しが、前例のない大きな成果につながっていく。” 合宿では、このβ版マインドを発揮するため、(リリースするかどうかは別として)「カミナシにあったらワクワクするβ版機能の開発」をテーマにハッカソン

こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシのプロダクトは、管理者の方が使う Web アプリに React、現場の方が使う iPad / iPhone アプリに React Native を採用しています。 どちらもフロントエンドの技術スタックを採用していることもあり、先日までは Monorepo と Yarn Workspaces の構成で運用されていました。 最近では Monorepo 化を進めている事例もよく見かけるようになってきました。 engineering.mercari.com devblog.thebase.in ですが、カミナシでは Monorepo をやめてリポジトリ分割をする意思決定を行いました。 具体的には、harami_client という Monorepo を harami_web と harami_mobile とい

こんにちは！カミナシでソフトウェアエンジニアをやっているくらさわです！ 今回は社内でゆるめに輪読会をやってみた話をブログにしてみました！ どうぞご覧ください！ 輪読会のきっかけ 読む本の選定について 輪読会の進め方 輪読会の結果と反省 まとめ 輪読会のきっかけ きっかけは僕が最近積読本が増えてきたからなんとかしたいな〜、社内で輪読会でも開いたら無理やり読むようになるかな〜みたいな軽い気持ちで Slack の個人部屋 (いわゆる times ) で呟いたのが始まりでした。 そしたら何人かリアクションくれたので、その場で本の候補を募ってみました。 そんな雑な感じで始めた輪読会ですが、僕の中では二つの目的がありました。 僕の読書習慣をつける 複数チームでまたがって技術的な議論や雑談をする場を作る 1 はかなり自分本位な目的です笑 2 はカミナシでは、少し前にチーム分割により、チームが別れ、雑にチ

ソフトウェアエンジニアの 鈴木 (@szk3) です。 先日、カミナシにおいて古くから存在する１つの機能をリアーキテクティングしました。 その結果、処理時間は4分の1以下、コストは90%程度削減 と大きな成果を出すことができました👏 本記事では、その機能が抱えていた課題に対しどのような改善のアプローチをして上記の結果に結びついたのか？について共有します。 Excel変換とは 今回、リアーキテクティングの対象となった機能は、カミナシに帳票として記録されたデータをExcel形式に変換して出力する機能です。 これを、”Excel変換” と呼んでいます。 Excel変換は、カミナシのサービスの中でも比較的古くから存在する機能です。 ここ数年での利用ユーザーの増加と共に、設計当初のシステムアーキテクチャが技術的な負債となっている状態でした。 Excel変換の課題 まず最初に、設計当初のアーキテクチ

カミナシのソフトウェアエンジニア @imu です。 いきなりですが、バグと聞いてどういう印象を持ったでしょうか？おそらく、ネガティブなイメージを持つ方が多いのではないかと思います。ですが、ソフトウェアエンジニアには付きものと言って過言ではないくらい、バグとは長く付き合っていくものですよね。 今回はバグを調査する勘所として、バグが発生してしまったときにどういう調査をしているのか、普段何に気をつけているのかを共有して、誰かの役に立てれば幸いです。 あくまで私個人の話であり、ソフトウェアテストプロセスの話はしないので予めご了承ください。 目次 目次 前提 バグ調査の勘所 バグ発生前の心構え リリース直後のバグ発生 既存バグ 再現性の低いバグへのアプローチ ユーザーからの問い合わせ まとめ 前提 自身が携わっているプロダクトが一つ リリース日が決まっている（24時間365日リリース出来る環境ではな

こんにちは。カミナシ ソフトウェアエンジニアの @aoman です。 つい先日、Goで有名な@tenntennさんがConnpassで募集していたGopher塾#2に参加させていただきました。 tenntenn.connpass.com 大変勉強になりおすすめです！筆者が参加したのは第一回目ですが、二回目三回目と予定されているようなので、有料講義ではありますが気になる方はぜひ参加してみてください！学生さんであれば無料の抽選枠もあります。 その際に紹介されていたコードで、エラーのラップ関数があったのですが、これが「ﾒｯﾁｬｱﾀﾏｲｲ!!ｽﾀｲﾘｯｼｭ!!」と感動しました。そのコードは、Goの公式ページである https://go.dev/ のWebサイトを実装しているリポジトリ pkgsite 内の internal/derrors パッケージで実装されています(GitHubリポジトリはミラ

前回の記事でも書かせていただいたとおり、先週アメリカのラスベガスで行われた AWS re:Invent に参加してきました。 kaminashi-developer.hatenablog.jp 筆者は海外へ行くことも2回目(米国は初)で慣れないことも多く大変だったため、反省を来年に生かすためにも、初参加してみてわかったこと、事前準備しておけば良かったと感じたことを記載させていただきます。 来年は AWS re:Invent に参加したい(けど海外はあまり行ったことがなくて不安)という方はぜひご覧いただければと思います。 ※ セッションの内容に触れる技術的なことは今回記載しておりませんので、そちらは別途ブログに記載できればと考えております。 事前準備〜移動 ホテル及び、人気のセッションの予約はすぐ埋まるのでチケット取得は早めに イベントのチケットを購入するとイベントのポータルサイトにログイン

カミナシ ソフトウェアエンジニアの中原です。 会社として AWS re:Invent 2022 に参加させていただけることになり、現在ラスベガスに来ています！ 時差があるため、現在ちょうど1日目のセッションが終わる頃なのですが、現地の雰囲気をいち早くお伝えさせていただこうと思います！ 前日まで ロサンゼルスには日本時間の 11/26(土) の夜に出国し、一度ホノルルを経由し現地時間の日曜朝にラスベガス（マッカラン国際空港）に到着。 イベントの会場は近くのホテルになるのですが、現地の11/27(日)はマッカラン国際空港にて Badge pickup を行っていたため、空港内でそのままイベントのパスをもらうこともできました。 reinvent.awsevents.com しかし昼頃には空港の Badge Pickup は混み始めており、ついでにSwag（お土産）ももらうべく、メイン会場となる

カミナシのソフトウェアエンジニア @imu です。 ソフトウェアエンジニアの仕事をしていて、やりがいを感じられる瞬間はいくつかありますよね。例えば、「新規機能開発をする」「新しい技術に触れる」「モノづくりが楽しい」などが挙げられます。ここ最近、私自身が一番やりがいを感じるなと思うことがあります。 それは「ユーザーからフィードバックをもらう」ことです。 日々の開発をする中で、ユーザーからフィードバックをもらうことは少ないかも知れません。直接ユーザーと会話する機会が少ないので、作成した機能や改善したことがユーザーのためになっているかを把握することは難しいです。 今回、技術的負債を解消した結果、ユーザーフィードバックが社内に共有される良い文化の事例をご紹介したいと思います！ 目次 目次 技術的負債解消のキッカケ 一括承認とは 技術的負債について 課題 原因調査 該当クエリ 何が起きているのか 解

はじめに こんにちは、カミナシ社でソフトウェアエンジニアをやっている浦岡です。 我々は「ノーコードでユーザー独自の現場アプリを作成できる」サービスを開発しています。 そのサービスのフロントエンドの開発にはReact×Reduxを使っているのですが、 サービス特性のため「Reduxのstateがファットになりがち」であったり「コンポーネント間のデータの依存関係が多くなりがち」といった状態に陥ります。 その結果、アプリの反応速度が遅くなりがちです... この記事では、上のような状態に陥った「React×Redux」アプリの高速化の一例をサンプルアプリを用いて説明します。 サンプルアプリについて 今回、Reduxのチュートリアルにあるカウンターアプリを改良し、下のような「モンスターの捕獲記録」アプリを作ります。 サンプルアプリについて Version1(コンポーネントをブルブルさせてみる) まず

こんにちは。カミナシ ソフトウェアエンジニアのAomanです。 最近ちょこちょこアルゴリズムやデータ構造、Goのキャッチアップしています。 そんな中、go.devのブログ Go blog のとある記事でダブルポインタを使用するコードに出会いました。筆者は今まで、RubyやJavaScript/TypeScriptなどの言語を多く触っていたためか、お恥ずかしながらダブルポインタを使うコードを初めて見たので「なんなのだこれは…」と戸惑いました。本記事ではそんなダブルポインタが使われていたコードについて、簡単にご紹介したいと思います。 そもそもダブルポインタとは？ その名の通りポインタのポインタのことなのですが、わからない方は下記の記事がわかりやすくまとまっており参考になると思います。 daeudaeu.com ダブルポインタと聞いて、まずはじめに思った感想は「そんなもの必要？」です。今まで使っ

概要こんにちは！ カミナシで Software Engineer をしている Issei です。 最近エンジニアリングチーム内で AWS 資格をとるムーブがあり、その一環でこの度 AWS 認定試験を受け以下の資格を取得しました。 AWS 試験は多くの方が既に受けており、ノウハウも色々とありそうですがこの note では、私なりに短期集中での試験に向けた準備や、試験会場のタイプごとの感想をシェアできたらと思ってます 🙌 今回取得した AWS 資格AWS Solutions Architect - Associate (SAA) 2022/08/29 取得 (822 点) - 2週間 受験方法：Pearson VUE Online AWS Solutions Architect - Professional (SAP) 2022/09/26 取得 (803 点) - 4週間 受験方法：Pea

こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 10 月の終わりに、ひとつだったエンジニアリングチームを分割する形で 2 チームが生まれました。社内では骨 🦴 と稲 🌾 という愛称で呼ばれています。 ちなみに、骨 🦴 の由来はこちらです。 今週から新しいチームが始動するのですが、チーム名は「骨」になりました🦴 英語の "hone" は「磨きをかける」という意味があるので、骨太でしっかりしたシステムを作り磨きをかけるという願を懸けました✨ pic.twitter.com/Gvf2VBYk7d— Manabu Sakai (@manabusakai) 2022年10月25日 前職でチームの立ち上げやスクラムを経験していたこともあり、CTO から骨 🦴 チームのスクラムマスターを任されました（専任ではなくエンジニアと兼任です）。 チームの立ち上げから 1

こんにちは！カミナシでソフトウェアエンジニアをやっているくらさわです！ 今回は元々、サーバサイドをメインに開発していた私が、カミナシでモバイルアプリの開発に取り組んでみた話を書きたいと思います！ カミナシのチームについて React Native について Expo について 超入門 やってみた感想 終わりに カミナシのチームについて カミナシのプロダクト開発では「単一のチームで顧客への価値提供が可能な体制をとる」という思想のもと、フロントエンド、バックエンド、インフラストラクチャーなどの技術的スタックでチームを分けることはしておりません。 参考記事: type.jp そのため、各個人では得意、不得意はありつつも、チームとしては全ての領域を担当しています。 フロントもサーバもインフラも手を出したいタイプの人にとってはめっちゃいい環境だと思います！おすすめです！ そんな環境なので、私もずっと

カミナシ・ソフトウェアエンジニアの @Taku です。 先日行われた Sansan株式会社様主催の BtoB SaaSにおける技術課題との向き合い方 にて「デスクレスSaaSが向き合う、現場DXのための技術課題」というタイトルで発表してきました。 sansan.connpass.com 登壇概要 カミナシでは日本の就業人口の約60％を占める「ノンデスクワーカーの才能を解き放つ」をMissonに、現場のDXに取り組んでいます。 デスクレスSaaSという日本ではまだあまり例のないサービスのため、特有の技術課題がありました。 そのような技術課題にどう向き合っているのか、約2年半の間に急成長していく中で直面した課題を含め、お話しさせていただきます。 speakerdeck.com 「カミナシ」のサービス説明 「カミナシ」はノンデスクワーカー向けのノーコードツールです。 従来「紙」で記載していたチェ

カミナシのトリ (@toricls) です。みんな大好き Google Apps Script (GAS) の小ネタです。 TL;DR 業務で使っている Google カレンダーの 外部の方がいそうな予定 オフィスとかに出社が必要そうな(≒大好きな家から出なきゃいけなさそうな)予定 あたりに、自動で「色ラベル」を付けてくれるスクリプトを GAS で書きました。 以下のような感じで、いかにも他のと違って目立つよね！という感じに色を自動で付けてくれます。例えば僕のカレンダーだと、緑色のラベルを外部の方がいそうな予定(下のスクショだと「一次面接」)に、オレンジ色のラベルを家の外にでなきゃいけなさそうな予定(下のスクショは単なる飲み会)に設定するようにしています。 便利〜 いかにも便利そうですね。 (余談:「外部の方がいそうな予定」をハイライトしたかった理由はシンプルに遅刻やすっぽかしといった事故

カミナシ・エンジニアリングマネージャーの @dmi8a と、 エンジニアの @imu です。 現場DXプラットフォーム「カミナシ」は、WebのアプリケーションとMobileのアプリケーションを1セットで提供する形を採用しているサービスです。 今日はExpoのOTAアップデートを介した、カミナシMobileアプリのリリースでぶつかった壁とそれを突破した方法について共有させてください。 本記事における前提 「カミナシ」は、Mobileのアプリケーション開発に、React Nativeを採用しております。 ※ご周知の通り、React Nativeは、iOS/iPadOS系アプリとAndroid系アプリの双方を開発できるクロスプラットフォームのアプリ開発用フレームワークです。 本記事では、iOS/iPadOS系アプリに絞った話となっております旨ご了承ください。 React Native + Exp