はてなブックマーク

スクラムよ！ 私は帰ってきたぞ！ スクラムをやめたけど戻したチームの経験談 こんにちは。アニメ『日本三国』を見終わって、横山光輝さんの『三国志』を読んだときの興奮を思い出した daipresents です。天命をまっとうするぞー。 少し前に、Slackを眺めていると、エンジニアリングマネージャ友達のなかしょーさんが「スクラムをぶっ壊す」とフンフンされていたのをみつけて、そう思った理由を伺ってみるとなかなか面白かったので、今日はその話を書いてみたいと思います。 スクラムじゃないかもと思った理由 なかしょーさんチームでは、スクラムが導入されていました。社内でも古株プロダクトでもあることから、比較的スクラムを長く続けていたチームです。 そんなチームは、スプリントを1週間でまわしていました。しかし、だんだん変化への対応タイミングが増えてきて、週単位での対応が必要になってきたそうです。 結果的に、立

こんにちは。カミナシで「カミナシ 設備保全」サービスの開発を行っている澤木です。 今回はフロントエンドのテスト戦略についての話を書いていこうと思います。 フロントエンドのテストはどこに何をどれだけ書くかが悩ましい領域です。 ユニットテストは書きやすく実行も速いですが全部組み合わせたときに動く保証はないし、E2Eテストは本物に近い保証が得られるけれど書くのもメンテナンスするのも工数がかかります。 特にE2EテストはAIでコーディングができるようになる前は工数が高く、書きたくても書けなかった部分がありました。 それがAIコーディングエージェントの普及で書くコストが下がり、E2Eもだいぶ書きやすくなって、どのテストをどれくらい書くのかという配分も改めて考え直したくなりました。 今回はテストトロフィーをベースに私たちがどういう考え方でテストの設計を行なっているか、またAIによって何が変わったのか、

こんにちは、ソフトウェアエンジニアの渡邉（匠）です。 「カミナシ 設備保全」の開発に携わっています。 以前、「40,000行のAPIテスト作成で学んだClaude Code Skillsの育て方」という記事を書きました。 AI を使って大量の API テストを生成した話です。 今回はその土台になっている、テストそのものの構成を紹介します。 私たちのバックエンドの API テストは、数十のAPIを対象に、200 本を超えるファイル、1,000 件を超えるテストケースまで育ちました。 本記事の主題は、テストフレームワーク runn で書いた runbook の設計、なかでも「何を確かめるか」と「どう呼ぶか」を分ける部品化です。 まず土台となる、runn を go test に埋め込む実行基盤を紹介した上で、本題の runbook 設計に入ります。 runn を go test に組み込む ru

カミナシでソフトウェアエンジニアをしている furuya です。今回は開催直前！ AWS Summit Japan 2026 の楽しみ方をご紹介します！これを見て、「行ってみようかな」と思っていただけた方がひとりでも増えれば幸いです。 ※2026/06/24 現在公開されている情報や、AWS Summit Japan 2025 のときの情報をもとにしています。最新の情報は AWS Summit Japan 2026 公式サイトでご確認ください。 aws.amazon.com AWS Summit Japan 2026とは 6月25日（木）、26日（金）に幕張メッセで行われる、日本で一番大きな AWS の学習イベントです。 AWS Summit Japan は、クラウドと AI イノベーションの最前線を体験できる 2 日間の無料イベントです。エージェンティック AI やサーバーレスコンピュー

はじめに カミナシでエンジニアリングマネージャーをしている、すずけん（@szk3）です。自チームのプロダクト「カミナシ 設備保全」には 2 つの AI 機能があり（プレスリリース）、どちらも Amazon Bedrock AgentCore 上のエージェントから同じ LLM モデルを呼び出しています。 リリースからしばらく経つと、「で、それぞれのAI機能でLLMの呼び出しいくらかかってるの？」という当然の疑問が出てきました。ところがこの２つのAI機能は同じLLMモデルを呼び出しており、請求上は合算されるため、機能ごとのコストを切り分けられていませんでした。 この記事では、Amazon Bedrock の Application inference profile を使って、同じモデルを呼び出す複数の AI 機能のコストを機能別に可視化した話を共有します。 同じモデルを呼ぶと、コストが混ざる

コーポレートエンジニアの@sion_cojpです。 コーポレートエンジニアをやってると、コード化できないものも多く、その場合は手順書を残す必要があります。 手順書は 「作業者が、上からなぞって実施していけば誰でも同じ作業になる」ために、見やすく書くノウハウをこの記事では紹介します。 1. 全体の文字数・1文の文字数・画像数をなるべく少なくする 2. インデントは2つまで。最悪3つ目まで 3. 危ない作業は赤文字 + 太文字で 4. 画像を使わず、なるべく文字だけで表現する 5. プロセス図に沿った手順を書く 6. 作業の流れだけを書く。ベストはコピペだけでできるように完結させる 7. 注意点はcalloutに書く 8. calloutが長くなればtoggleを使う 9. あまり発生しない手順はtoggleを使う 10. 分岐を極力少なくする 11. ひとつの画面で入力することが多い場合は、

カミナシエンジニアの osuzu です。 「状態管理にどのライブラリを使うか」への違和感 Reactの状態管理の話になると、だいたいライブラリの比較から始まります。少し前なら Redux か Zustand か Jotai か、最近だと TanStack Query と React Hook Form を組み合わせれば残りはわずか、みたいな話が多い印象です。 ただ、読んでいてどこか議論がかみ合わない感じがずっとありました。 理由はたぶんシンプルで、その問いは手前にすべきモデリングを飛ばしているからだと考えてます。 ライブラリ起点・コンポーネント起点はなぜこじれるのか フロントの状態管理でやりがちな失敗に、両極端な二つがあります。「Reduxを採用したので全部storeに乗せる」や「Reactをシンプルに使うため全部useStateで」です。 Redux や useState が悪いというこ

こんにちは。カミナシで「カミナシ 設備保全」の開発を行っている澤木です。今回はフロントエンドのコンポーネントディレクトリの構成、特に「ネストを深くしないために何をやっているか」という話をご紹介したいと思います。 feature-basedなディレクトリ構成 まず前提として私たちのチームでは機能（feature）単位でディレクトリを切り、各featureの中をさらにcomponents / hooks / contexts / model / repositoryといった責務ごとのディレクトリに分けるスタイルを採用しています。現在のフロントエンドの実装では一般的な構成かと思います。 features/hoge/ ├── components/ ├── contexts/ ├── hooks/ ├── model/ ├── repository/ └── index.ts 今回はこの中で主にc

こんにちは、ソフトウェアエンジニアの渡邉（匠）です。「カミナシ 設備保全」の開発に携わっています。ゴールデンウィークが明けて1ヶ月ほどが経過し、休暇モードからやっと仕事モードに戻ってきました。 このプロダクトは開発開始から約2年が経ちました。バックエンドは長いあいだ presentation / domain / repository の3層で書いてきましたが、最近これにユースケース層を加えた4層へと再構成しました。 この記事では、なぜ最初から4層にしなかったのか、そしてなぜ今になって構成を取り直したのか、を書きます。 シンプルに始めた 当初のバックエンドは presentation / domain / repository の3層でした。守ろうとしていたのは「依存方向を内側に保つ」という一点です。層がいくつあるかは本質ではなく、依存の矢印がビジネスルールを置く domain 側を向き続

はじめに カミナシでエンジニアリングマネージャーをしてます、すずけん（@szk3）です。 唐突ですが、皆さん AWSのエミュレーター使ってますか？ 自チームのプロダクトはS3、DynamoDB、STS、IAM あたりの AWS サービスに依存していて、ローカル開発やテストではこれらのエミュレーターを使っています。ただ、歴史的な背景からリポジトリには LocalStack、RustFS、Moto の 3 種が混在していて、用途ごとに考えることが地味に増えてしまった状態でした。 この記事では、その 3 種を Moto に統一した経緯と、検討した他の候補、そして移行から少し経った今でも次の選択肢を検討し続けているよ、という話をシェアします。 統合前の構成 ローカル開発とテスト環境では、目的ごとに違うエミュレーターを利用していました。 エミュレーター 用途 対象 AWS サービス LocalSta

はじめに カミナシの共通ID管理基盤を開発しているmanaty（@manaty226）です。カミナシ ID管理基盤ではログストレージにCloudWatch Logsを使っていましたが、サービスの成長に伴いコストに悩んでいました。この記事では、私たちが実践したAmazon S3 Tables（以下、S3 Tables）を使ったログストレージの構築と移行、そのコスト最適化効果について書きます。 サービス成長に伴うCloudWatch Logsのコスト増大 Amazon CloudWatch Logs（以下、CloudWatch Logs）はAWSが提供するログの保管や分析のためのサービスです。多くの一般的な構成ではアプリケーションが出力するログをそのままCloudWatch Logsに保管し、何かあればCloudWatch Logs Insightsを利用してログをクエリしたり、特定のエラーロ

「それ本当にMVP？」AI時代にプロダクトが巨大化する理由をふりかえる おはようございます。シャトレーゼに入ったときのいい匂いの根源がなにか気になっている daipresents です。あれ、ほんとなんの匂い？ この1年、AIがとてつもないスピードで進化しており、活用するエンジニアもどんどん進化しているように感じています。 僕は「カミナシ 教育」と「カミナシ 従業員」の2プロダクトにかかわっているのですが、「小さく作ったつもりが、結果的に大きくなっちゃった」というケースが、立て続けでありました。 もしかしたら「AIの登場によって、MVPも巨大になってしまっているのではないか？」と感じたので、ふりかえってみようと思います。 AIの登場によってわかったこと カミナシ社内でも開発に置けるAI活用は進んでいます。これはデータにも現れていて、今年に入ってからはAIによるコード生成量は格段に増えていま

2026年4月、「カミナシ 教育」開発チームのオフサイト。 エンジニア・プロダクトマネージャ（PM）・プロダクトデザイナー（PD）が3人ずつのチームに分かれ、「カミナシ 教育」のAI機能をいじりながら、ある特殊なケースを探していました。 機能のバグでしょうか？いえ、もっと厄介なものです。「出力結果はおかしいのに、評価指標は問題なしと判定してしまうケース」——AI機能を評価する仕組みそのものの盲点です。 これが私たちのチームで実施したAI評価改善ワークショップの一場面です。 AI評価改善ワークショップの様子 こんにちは、カミナシでAIエンジニアをしている井上です。カミナシではプロダクトのAI機能の検証や開発、プロダクト横断のAI機能運用の基盤作りなどに携わっています。現在は「カミナシ 教育」のAI機能の評価基盤構築に取り組んでおり、本記事でご紹介するワークショップもその一環です。 なぜ、わざ

はじめに カミナシで新規プロダクトの開発をしているShimmy(@naoya7076)です。 現在、新規プロダクトをプロトタイプとして開発しており、顧客に提供しながらフィードバックを得ています。Claude Codeをはじめ、開発の全工程でAIを活用しており、開発アイテムは予定以上のスピードで実装できています。 「AIでコーディングが速くなった。ではその空いた時間で何をやるのか？」 この問いに対して、自分が新規プロダクト開発で実践してきたことを書きます。 「もっと作る」はアンチパターン AIで実装速度が上がると、「もっと作ろう」という方向に引っ張られがちです。しかし、むやみに作るものを増やすのはアンチパターンです。理由は2つあります。 コードの意図の希薄化 AIによってコードを爆速で書けるようになりましたが、それを続けていると人の理解を超えた「意図が希薄なコード」が増えてしまいます。プロト

はじめに カミナシでエンジニアをしている Shimmy です。今は新規プロダクト開発をしています。 0→1の開発設計では「コードベースの持続可能性」と「短期的なデリバリー速度」の両方が重要です。そのバランスを取りながら、AIの力を最大限活かせるアーキテクチャを考えてきました。 その過程で分かった設計原則というのは、AIを活用する前から変わらないものでした。 この記事では、AIの力を引き出す設計と、その設計を決定論的に守らせる仕組みついて話します。 補足: TanStack Start（フルスタックReactフレームワーク）を利用しており、フロントエンドとバックエンドが同一コードベースにあります。 AIの力を引き出す設計の3つの条件 自分のプロダクトの設計原則は次の3つです。 関心の分離: 関心事ごとにファイルをまとめる。AIのコンテキストに載せやすく、並列開発でもコンフリクトしにくい 価値

プロダクトマネージャやデザイナもAIでプルリクエストを作成できるプロセスを作ろう こんにちは。息子と『ドラベース』を読みはじめた daipresents です。トンボール投げたい！ カミナシでは「カミナシ 教育」と「カミナシ 従業員」のマネージャを担当しております。 前回、月1回のオンサイトにおける取り組みを紹介させていただきました。 参考： エンジニアじゃない人でもAIを使えば開発貢献できるんじゃないの？イベントを開催してみた こちらについては、プロダクトマネージャやプロダクトデザイナの評価はとても高く、「もっとやりたい！」、「リリースしたい！」と、みんな開発に対する意気込みを表明してくれました そこで、翌月のオンサイトでは、今回はさらに一歩進んだ取り組みとして、「イベントでやるだけでなくて、開発フローに組み込めないか」を実験してみました。 しかし、実際にプロセスに組み込んでみようとなる

AIと不安で眠れない夜。 あ〜〜〜〜〜今日もTwitterのタイムラインはAI、Claude、OpenClaw、エーアイ、Codex、Gemini、ハーネスの話題で持ち切りだわ。なんだよハーネスって。自意識過剰なホモサピエンスがAI様をコントロールできると考えているのか！？奴らの成長速度を考えたら、数年以内に制御できる範囲なんてとっくに飛び出して二足歩行でコンビニ行ってオハヨーのブリュレアイス買って食っとるわ。あれうますぎだろ。 あ〜〜〜〜〜わかってるよ。Twitter呼びは時代遅れだって？そのツッコミも飽きたわ！俺は死ぬまでTwitterって言うからいちいち気にしないでくれ！ ジュニアやミドルエンジニアは不要？そうかもね！日々開発して身に染みてるよ。 と思ったらなに！エンジニア自体不要？SaaSも is dead？まだ俺は生きてんの！勘弁してよ〜〜〜〜〜〜〜。 漠然とした焦燥感と、描いて

「カミナシ レポート」の開発・運用をしている、AWS インフラが得意な Security Engineering の furuya です（属性過多）。妙に流行り物に乗っかるときがあるのですが、「超かぐや姫!」を見てきました。よかったです。それはさておき今回は「カミナシ レポート」の開発におけるセキュリティ向上施策のお話です。 カミナシでは開発チームに Security Engineer を派遣する取り組みがあります。 kaminashi-developer.hatenablog.jp 気がつけば、この記事の公開から1年が経過していました。ここでそれを振り返ってみたいと思います。 サービスにおけるコンテキストを把握する 派遣されるセキュリティエンジニアは基本的には最初の半年から1年程度は開発チームの1メンバーとして、ともに開発や運用を行います。ですので、障害対応やインシデント対応、お客様から

こんにちは、ソフトウェアエンジニアの渡邉（匠）です。「カミナシ 設備保全」の開発に携わっています。 Claude CodeのSkills（以下スキル）を使い、約2週間で40,000行超のAPIシナリオテストを書き切りました。最初のスキルは粗削りでしたが、テストを量産する中で繰り返し改善した結果、後半は「スキル実行 → レビュー → マージ」のサイクルだけで回せるようになりました。 この記事では、スキルをどう設計し、どう育てたかを中心にお伝えします。 背景 APIの動作保証にシナリオテストツール runn を使っていました。 サービス成長に伴うAPIの増加により、当初のテスト構成では運用が回らなくなってきました。1ファイルあたりのステップ数が膨らみ、どこで何を検証しているのか判別が難しい状態に。テストの追加・修正が心理的にも技術的にもハードルの高い「辛い作業」へと変わっていました。 そこで、

「カミナシ レポート」の開発・運用をしている furuya です。最近我が家では成長してきた子どもたちのことを考えて寝室含めて部屋の配置換えを検討しており、そのパズルに頭を悩ませています。それはさておき今回は「カミナシ レポート」の開発において AI Agent を主軸にした開発スタイルを取り入れたお話です。 背景 近年の AI Agent の進化は目覚ましいですね。日々情報がアップデートされる中、カミナシのエンジニアリング組織としてもこの流れについていかなければならない、ということで各チームいろんなことにトライしており、組織的にもそれが推奨されています。もちろん、前提として以前から GitHub Copilot や Claude Code などの Coding Agent を開発に取り入れています。そんな中で個人的に感じた課題と同時期に得た学びがカチッとはまる出来事がありました。 課題

はじめに 「カミナシ レポート」を開発しているかわりくです！ 日本最大級のテックカンファレンス、Developers Summitに初参加してきました。 2日目のセッションの感想や持ち帰れそうなことをメモっております。 会場の雰囲気は、デデデデカイ！規模がデカい！今まで参加したどのカンファレンスよりも人の数と会場のキャパシティと、ブースの数が桁違い...！スタッフさんも多い...!ありがとうスタッフさん...! タダでサンドイッチもらってごめんなさい...!スタッフさんの分まで楽しみます！ 興奮しながらの入場となりました。 （2026/2/19終了後、最速レポとして投稿されたものです。） beyond the code（デブサミ26のキャッチコピー） セッションレポート LLM利用率80%への道筋：ピクシブが実践した「People・Process・Technology」三位一体の変革とは？

コーポレートエンジニアの @sion_cojp です。 この記事では、Claude Code を使って SaaS セキュリティチェックを自動化した取り組みについて紹介します。 SaaSセキュリティチェックとは？ 従業員が新しい SaaS を業務で利用したい場合、その SaaS がセキュリティ面で問題ないかを、コーポレートエンジニアが事前にチェックします。 チェック項目の一部を挙げると以下のような内容です。 公的認証資格を取得しているか（SOC など） MFA（多要素認証）／二段階認証に対応しているか 解約後にデータは完全に削除されるか 準拠法・管轄裁判所の確認 また近年では、SaaS に AI 機能が標準搭載されるケースも増えており、 学習への利用をオプトアウトできるか 入力データがモデル改善に使われるかどうか といったAI 特有の観点もチェック対象になっています。 これらを総合的に確認し

こんにちは、ソフトウェアエンジニアのいちび (@itiB_S144) です。 2026年1月28日 (水) に「カミナシ Tech Night #1 - AWS re:Invent 2025 Recap Special」を開催しました！カミナシのエンジニアチームとしては初めての外部の方も参加可能なイベントの開催で、準備段階からドキドキしていましたが、当日は大盛況で無事に終えることができました。 今回のテーマは AWS re:Invent 2025 の recap (復習) イベントということで、実際にカミナシから現地参加したエンジニア 5 名と豪華なゲストの方々がそれぞれの視点でセッションレポートをお届けしました。イベントには社外からも 13 名ほど参加いただき、会場は熱気に包まれていました！ 本ブログではイベントのレポートをお伝えします。 カミナシ Tech Night とは カミナシの

こんにちは。青春ミュージックと言えば Judy and Mary の @daipresents です。好きな曲は『LOVER SOUL』です。 「カミナシ 教育」の開発チーム（サービスチームと呼んでいます）は、月に1回だけ東京神田オフィスに集まってオフサイトを行っています。そこでは、その月のふりかえりだけでなく、直接話したいことや、話したほうが意思決定がしやすいことをアジェンダにして、対話やディスカッションの時間を確保しています。 1月度のオフサイトでは、エンジニアと非エンジニア（プロダクトマネージャ、プロダクトデザイナー、リサーチャー）のペアを作り、「AIを使って非エンジニアに機能開発をやってもらおう」というイベントを開催しました。 会場の風景。神田オフィスの広場で開催しました。 このイベントの狙いは以下です。 プロダクトマネージャやプロダクトデザイナーが、プロダクトのちょっと気になった

コーポレートエンジニアの @sion_cojp です。 この記事では、ISMS関連の文書を Google Docs から GitHub に移行した理由と運用方法 について紹介します。 ISMSで管理する文書とは？ ISMS（Information Security Management System）は、情報セキュリティを組織として継続的に管理・運用するための仕組みです。 ISO/IEC 27001（JIS Q 27001）は、そのISMSをどのように構築・運用・改善していくべきかを定めた規格になります。 例えば、規格では「付属書A 9.4.5 プログラムソースコードへのアクセス制御」が要求事項として定められており、これに対応する形で社内文書には「ソースコードのアクセスおよび管理方法」を記載します。 ISMS というと「文書が多い」「運用が大変」というイメージを持たれがちですが、本質は 文

新年明けましておめでとうございます、セキュリティエンジニアリングの西川です。年末から胃を壊しており、健康の大切さを改めて感じています。何事も当たり前ではないということですね。 さてさて、そんな話も関係しつつ AWS App Runner 使っていますか？カミナシでも使っています。お手軽にデプロイできるし、スケールも自動でしてくれるのでとても使い勝手が良いですよね。 という App Runner 全人類使うべきだよ！という話ではなく、App Runner を使う上での注意点をお伝えしたいと思います。 App Runner の特徴 本題に入る前に App Runner のことを知らない方のために App Runner の特徴をお伝えしたいと思います。App Runner は ECS 同様にコンテナをデプロイすることができます。さらに ECS はインフラの設定などを自分でする必要がありますが、A

新年あけましておめでとうございます！自分，なかなかテキストによるアウトプットが苦手なのですが，今年は頑張って克服していきたい所存です！ 改めましてこんにちは．株式会社カミナシで EM をしております Keeth（@kuwahara_jsri）こと桑原です．昨年もカミナシ社のエンジニアリング本部で２日間，開発合宿を開催しましたので，今回はそのレポートとなります！ 開催概要 日程：10月15日 12:30 〜 10月16日 15:00 場所：熱海 参加者：エンジニア23名 今回の開発合宿の目的は， AI Vibe Coding実践を通して，各エンジニアの開発生産性向上 エンジニアブログ執筆時間を設け本合宿含めたブログ執筆機会を与えることで，リーチしていなかった人材も含めた採用プレゼンス向上 としました． カミナシはマルチプロダクト戦略でサービス展開をしており，日々チームもプロダクトも変化してい