仕事に前向きではあるけれど、ちょっと扱いに困る「こじらせた」感じのする、あの人——— 今回のAgendは、楽天大学・学長の仲山さんにそんな「こじらせ社員」についてお聞きしてみました。 仲山さんのお話から見えてきたのは、相 […]

職場にいる「こじらせた人」とどう仕事をしていけばよいのか | Agend(アジェンド)

みなさん、隙間家具としての様々な社内ツールを作っていますか？エンジニアをしている @wa6sn です。 2025 年末ごろに、社内向けアプリをカジュアルに公開するためのプラットフォーム、Orbital 1 を作りました。ざっくり言うと 「コンテナイメージを置くだけで、サブドメインと社内認証つきの Web アプリが公開される」 ものです。いわゆる社内版 Heroku みたいなもの、と言うと伝わりやすいかもしれません。今回はこれを紹介します。 Orbital とは？ 前述の説明の通りです。せっかくなので Orbital でアプリケーションを作る様子の gif アニメーションを貼っておきます。 ダッ…

社内向けアプリを爆速で公開するためのプラットフォームを作った - giftee Tech Blog

LayerX社内の定例でつかった資料です。

5 © LayerX Inc. 機能をつくることそれ単体に価値はない、むしろマイナスである 使われて初めて価値が出る 使われて運⽤に乗って初めて価値が出る 使わないユーザーには認知負荷を招く。 端的にいうと邪魔。理解ができない。とっつきづらい。無駄なストレス。 Read
Me
6 © LayerX Inc. 機能は未来に負担をおしつける 次の開発が遅くなる。 バグがないか常に動作確認し続ける必要がある。未来永劫。 パフォーマンスが悪くなる。その機能のせいでパフォーマンスの改善ができなくなる。 未来に悪影響をもたらす。 リファクタ、リアーキ、何らかの障壁になり続ける。
AIのコンテキストを無駄に⾷う。それも永劫。それは遅さとAIコストにつながる。 後続の⼈間の理解を要求し続ける。 そしてもちろんその時間で本来別のものが提供できた。機会コストの無駄である。 機能は、使わないユーザーにとっては百害あって⼀利なし。 Read Me
使われないものを作るな 正しくないものを作るな
8 © LayerX Inc. 使われないものを作るな 暇でいい、暇なほうがずっといい エンジニアは、作らないことは悪じゃない PdMは、エンジニアを暇させることは悪じゃない 間違ったものを作って未来とユーザーに負担を強いるより100倍良い 拙速な開発にストップをかけることは明確にあなたの仕事
PdMとかエンジニアとかデザイナーとかQAとか関係ない。 「AIで作れるから⼀旦作るか」と、とりあえず作ってないか？作ったものを誰かに判断させるコストをお しつけてないか？ Read Me
9 © LayerX Inc. 過去の例：認証基盤のリニューアル撤退 Read Me https://note.com/applism_118/n/n6ac43ace4566
10 © LayerX Inc. じゃあ、⼀部の⼈しか使わない機能はどうすればいいのか ⾊々な業種‧業態‧業務フローがある。⼀部の会社しか使わない機能は構造上存在する。時々し か使わない機能は存在する。 理想は、機能をつくるなら、欲しい⼈が欲しくなったときに気づく場所におく。 AIのSkillとおなじ。 ⼈間のコンテキストは限界がある。
使おうとおもったら⾃然と気付けるような場所。 Read Me
11 © LayerX Inc. じゃあ、設定でON/OFFできるようにすればいいのか 明確にNo。 設定の認知コストがかかる。それは⼈間もだし、AIも含む。 設定に気づかせない限り誰も使わない機能である。それは存在しないのと同じ。作らない⽅が良い。気づかない ⼈、使わない⼈には百害あって⼀利なし。 設定に気付く⼈は、適当な場所においたら数%未満だろう。
設定をおくとしても、デフォルト値はなにかも徹底的に考え続ける必要がある。それを放棄するのはありえな い。 そして設定の分岐の数だけ動作確認で後ろのひとは永遠に苦しみ続ける お客さんへの案内は苦しみ続ける お客さんに設定を探し理解するコストを負担させているだけである。設定という概念は⼀⽣残る。 Read Me

機能を作るな。楽して作るな。 （LayerX社内資料） Don’t Build Features. Don’t Take the Easy Way Out. - Speaker Deck

Working Out Loud 大声作業（しなさい）、チームメンバー同士でのトレーニング文化の醸成 - スタディサプリ Product Team Blog の記事が好きで、今でもたまに読み返している。 自分が "今やっていること" や "やってきたこと" を周囲に伝えるのはむずかしい。これは得意不得意というより慣れの問題で、慣れていない人が多いのだと思う。 慣れるには数をこなすしかないんだけれど、技術として抑えておくとよさそうなこともある気がするので雑に書き出してみる。 なぜ伝えるのがむずかしく感じるかというと、「わからない」と「やりづらい」の2つが要因だと思う。 「わからない」 : 何をど…

自分がやっていることを伝える技術 - Konifar's ZATSU

AI時代に適したリポジトリって？カウシェ・LayerXに聞く最新リポジトリ構成

もたらしたもの：FE / BE の一貫性 統合前：BE / FE で状態がズレる 統合後：状態が常に 1
つに揃う → FE / BE の状態が、常に 1 つに揃う © LayerX Inc. API スキーマが BE / FE でズレる（最新の変更の取り込み忘れなど） 共通ライブラリを BE / FE で二重にメンテナンス BE / FEでスキーマがズレない 共通ライブラリを 1 箇所で管理し、二重保守が消える 17
もたらしたもの：越境のしやすさ 統合前：リポジトリを往復する（例：API を 1 本追加する） 統合後：端から端まで一気に貫ける → 越境する AI のための土台が整った
© LayerX Inc. スキーマ → BE → FE を別々の PR で行き来 開発単位とPRの単位が一致しない スキーマ → サーバ実装 → クライアント実装まで 1 PR、AI に一筆書きで任せられる BE まで含めた Preview環境を提供し、 「動くもの」を触れるように 18
まとめ © LayerX Inc. なぜ統合したか：TypeScriptがBEにも浸透し、なおかつAI が FE / BE を越境するように
不安：統合すると遅く・重くなるという開発者体験に対する懸念 どう進めたか：不安を、前以上に速くする姿勢で打ち返した もたらしたもの：FE / BE のズレが消え、一気通貫で開発できるように 19

越境するAIのために、境界を取り払う - AI 時代の開発体験向上に向けたリポジトリ統合の取り組み - - Speaker Deck

カウシェの モノレポ 2023年代 レポジトリ⼀覧 • kauche-app(BE) • kauche-mobile(iOS) • kauche-android(Android)
• kauche-terraform(Infra) • kauche-ope-frontend(Web/社内向け管理画⾯) • kauche-partner-frontend(Web/出品者向け管理画⾯) • kauche-farm-frontend(Web/カウシェファーム) • その他 昔はマルチレポだった！
カウシェの モノレポ モノレポ移⾏プロジェクト • (2025/04)最初、iOSレポとAndroidレポを統合することから始まる ◦ 当時AI⽂脈はなく、ネイティブアプリエンジニアがiOSとAndroidを両⽅触れるようにするため だった。 • 💡AIとの相性が良いことに気づく
◦ AIへ⼊⼒する情報量が⼤きいほど、より多くの⽂脈を踏まえた実装を出⼒する • 現在の組織規模なら、モノレポの旨味も享受できるはず‧‧‧ • (2025/07)全部をモノレポに統合するPrjが始まる
カウシェの モノレポ 現在 レポジトリ⼀覧 • kauche-app(iOS,Android,BE,Infra,Web) • kauche-deployment(Cloud Run YAMLの保存場所)
◦ ※もうすぐkauche-appへ統合予定 モノレポになりました！

monorepo.pdf - Speaker Deck

目次 はじめに 改善前の開発フロー 直列処理のボトルネック 数字で見るコスト AIで直列から並列へ転換する 最初のアプローチ ── 直列のまま高速化しようとした（失敗） 方針転換 ── 並列化に切り替える（成功） 改善後の開発フロー（並列化） フィージビリティレポートを生成するAIワークフロー 実際に生成されたレポートを見てみる 店舗満足度アンケート 要件定義書 Part 1: 評価サマリ システムの目的 評価サマリ 主要な判断ポイント User Storyへの改善提案 Part 2: ユースケースと業務ルール ユースケース一覧 モーダル表示制御 回答収集 AIが追加で洗い出したユースケース …

Title	Category	URL	Added at
職場にいる「こじらせた人」とどう仕事をしていけばよいのか \| Agend(アジェンド)	misc	https://agend.jp/media/kojirase/	2026/6/17 13:17:37
社内向けアプリを爆速で公開するためのプラットフォームを作った - giftee Tech Blog	misc	https://tech.giftee.co.jp/entry/2026/06/17/120931	2026/6/17 13:10:39
機能を作るな。楽して作るな。（LayerX社内資料） Don’t Build Features. Don’t Take the Easy Way Out. - Speaker Deck	misc	https://speakerdeck.com/mosa_siru/don-t-build-features-dot-don-t-take-the-easy-way-out	2026/6/15 20:59:50
自分がやっていることを伝える技術 - Konifar's ZATSU	misc	https://konifar-zatsu.hatenadiary.jp/entry/2026/06/14/175633	2026/6/15 12:16:32
越境するAIのために、境界を取り払う - AI 時代の開発体験向上に向けたリポジトリ統合の取り組み - - Speaker Deck	misc	https://speakerdeck.com/shibukazu/yue-jing-suruainotameni-jing-jie-woqu-rifu-u-ai-shi-dai-nokai-fa-ti-yan-xiang-shang-nixiang-ketaripozitoritong-he-noqu-rizu-mi	2026/6/13 14:50:16
monorepo.pdf - Speaker Deck	misc	https://speakerdeck.com/suzuito/monorepo	2026/6/13 14:48:40
AIで要件定義の土台を即時生成し、要求変更の手戻りコストをゼロに近づけた話 - Tabelog Tech Blog	misc	https://tech-blog.tabelog.com/entry/ai-driven-requirements-definition-process_52	2026/6/11 22:28:45