今はまだ生成AIに自分の文章を書かせたくない - An Epicurean
少し前にエンジニア採用に携わっていた頃は、XのDMなどでスカウトを送っていた。丁寧に文面を考えていたので、一通に大体15~30分かかっていた。それもあって、スカウト返信率は70%を超えていた。そういう僕のスカウト文を見て「これはAIでは書けない文章だ」と誉めてくれる同僚もいた。 実際、僕はスカウト文を作るときに最近の生成AIは使っていなかった。ただ、生成AIでスカウト文をいい感じに書いてもらうことも全然できるだろう。やっている人もいるだろうし、それを全然否定しない。単に、僕の個人的なポリシーとして、文章を書くときには「まだ」生成AIを使わないようにしているというだけだ。 別に、未来永劫使いたくないという話ではない。今はこの新しい道具を自分に馴染ませていくフェーズなのだ。実際、文章を書く以外のリサーチや、ちょっとしたコードや画像の生成に生成AIを使うことはもはや日常になった。 それでもなお、
マネージャーを経験したエンジニアが、再びプレイヤーを選んだ理由とそれまでの学び｜k_7016
はじめにこんにちは！カミナシでエンジニアをやっている倉澤です。 この度、約2年務めたマネージャーロールから IC (individual contributor)ロールに戻ったので、それについて現時点での考えをまとめたいと思い、ブログを書きました。 マネージャーに興味のある IC の方や、キャリアに悩んでいる方、はたまた、カミナシのマネージャーについて興味のある方にも参考になれば幸いです！ カミナシでの略歴2022年7月にカミナシに入社し、2023年4月にアソシエイトマネージャー (カミナシではマネージャー補佐のような役割です)、2023年7月に正式にマネージャーになりました。 2024年8月に元のチームから派生する形で短期的なミッションを持ったチームを組成し、そのチームのミッションが完了するとともに IC ロールに戻ることに決め、2025年4月1日 から IC ロールとして働いています。
マネージャーの仕事は「評価」や「人材育成」とは限らない｜柳川慶太
BASE株式会社で金融事業の事業責任者と執行役員をしている柳川と申します。 私はエンジニア→PdM→事業責任者というキャリアを歩んできました。 その中でマネジメントの仕事も5年ほどしてきました。 具体的には以下のような仕事をしてきました。 1からの組織立ち上げと採用リード 多職種の多階層の組織のマネジメント 1->30人規模の組織運営 いわゆるプロのマネージャーというよりは、事業責任者であるゆえのマネージャーの経験であることはご留意ください。 今回はその経験を踏まえて考えた、「マネージャーの仕事とは」をまとめてみました。 実は次作のnoteも決まっていましてそれに繋がる内容になります。 対象プロダクトをつくり、それを何らかの形でお金に変えていく そんな仕事を前提にしています。 そして僕は、プロダクトづくりはその全工程が「企画」の仕事だと考えています。 上記に加えてスタートアップであることを
フロントエンド API コール時のエラーハンドリングを軽く整理（Fetch API・typescript-fetch・TanStack Query） - カミナシ エンジニアブログ
カミナシのソフトウェアエンジニア佐藤です。カミナシレポートの開発に携わっています。 フロントエンドのエラーは「画面リロードやブラウザ再起動で復旧できる（かもしれない）」「クラッシュしてもユーザーの端末に閉じる」などの理由から、バックエンドよりは精緻に扱われない傾向があると個人的には感じています。 その一方、カミナシレポートは、ノンデスクワーカー向けの不安定なネットワーク環境で利用されることも多々あるアプリです。そのため、デジタルツールに不慣れな方のために精緻なフィードバックが必要とされる、リロードに頼ることが難しいケースがある、などの理由でエラーの扱いにも慎重になる必要があります。 本記事では、カミナシレポートのフロントエンド開発をする中で、 バックエンドの API コール時にエラーが発生する条件とその内容（型・クラス） これらエラーをハンドリングする箇所 について、把握しておきたいと感じ
技術文章を書くための執筆技術と実践法（パラグラフライティング）
Pen-based Interaction - Lecture 4 - Next Generation User Interfaces (4018166FNR)
防御力の高い技術ブログを書こう - じゃあ、おうちで学べる
はじめに ある日のこと、私はもしくはあなたは思いつきました。そう、自分の考えを発信してみようと。それはまるで、小さな紙飛行機を窓から放り投げるような、どこまで飛ぶかわからない冒険でした。そんなわけで画面に向かい、キーボードを叩き始めたのですが、すぐに奇妙な不安が襲ってきたのです。 ほら、誰かがそっと後ろから覗き込んで「それ、間違ってるよ」とか「それって昔の話でしょ」なんて言ってくるかもしれない。もっと恐ろしいのは「もっといいやり方があるのに」という呪文めいた言葉です。そんな呪文を浴びせられたら、私はきっと透明人間になりたくなるに違いありません。 でも不思議なもので、そういう批判の声が聞こえてくるのは、実は自分の頭の中だったりするんですよね。まだ何も書いていないのに、もうすでに架空の批判者と対話している。ある意味、私たちは常に誰かと対話している生き物なのかもしれません。 そこで考えたのです。
サッポロ一番塩らーめんの粉をバターに練り込む「ポロイチバター」
1980年、東京生まれ。片手袋研究家。町中で見かける片方だけの手袋を研究し続けた結果、この世の中のことがすべて分からなくなってしまった。著書に『片手袋研究入門』（実業之日本社）。 前の記事：町に眼鏡をかけてあげたんだ ＞ 個人サイト 片手袋大全 ＞ライターwiki バターファンクラブの落ちこぼれ 昨年べつやくさんが書いた『バターファンクラブ』という記事に、私も参加した。 バター好き同志でとことんバターの魅力を語り合った その後もべつやくさんはバターバーガーを食べに行ったり、『指グルメ』でバターを試したり、ファンクラブ会員としての活動を怠っていない。だが私は目立った活動もないまま1年以上経過してしまった。 べつやくさんデザインのバターTシャツが泣いている… 勿論、この間もバターはたっぷり摂取してきたし、バターのオブジェを見つけると写真に撮ったりはしている。 （うわ、バター！）と驚いて思わず撮
SAFe(Scaled Agile Framework)が、再び「採用を控えるべき技術」に選定される - arclamp
日本でもSAFe™（Scaled Agile Framework®）は、大企業がアジャイル導入を進める際に使われるフレームワークとして知られています。しかし、有名コンサル企業Thoughtworksは2021年と2025年の2回に渡り、SAFeを「Hold（採用を控えるべき）」として評価しました。 ThoughtworksとTechnology Radarについて Thoughtworksは、テクノロジーを活用した組織変革やアジャイル開発の分野でグローバルに活躍するコンサルティング企業です。マーチン・ファウラーが所属し、CI（継続的インテグレーション）、IaC（Infrastructure as Code）、マイクロサービスなど、様々な技術トレンドを名付けたり、紹介したりしています。 Technology Radarは、彼らが年に2回発行しているレポートで、様々な技術についての評価がされま
社内デザインシステムをMCPサーバー化したらUI実装が爆速になった
はじめに こんにちは、普段 Ubie で症状検索エンジンユビー(https://ubie.app/)の開発をしている江崎です。 最近、Cursor エディタや GitHub Copilot などのコーディングアシスタントツールが進化し続けていますが、社内固有のデザインシステムとの連携はまだまだ課題が残っていました。そこで社内エンジニアである sosuke とともに、Ubie Vitals というデザインシステムを MCP サーバー化することで、UI 開発の速度と精度が劇的に向上した体験を共有します。 目次 デザインシステムと開発の現状課題 MCP サーバーの登場 Ubie UI MCP の構築 デモ テキストだけで UI 実装が可能に デザイナーの壁打ち相手としての可能性 今後の展望 デザインシステムと開発の現状課題 Ubie では「Ubie Vitals」というデザインシステムに則って
対立議論を避けがちな人が持つリスク｜すどう
最近読んだ『決断の本質』という本に「事業を成長させるには、あえて対立を生み出し、議論として仕組み化していくことが重要」とあって、なるほどなと思った。対立を避けることが美徳のように感じられる場面って多いけど、そこで止まってしまうとむしろ組織の停滞を招くな、という気づき。 たしかに、誰かが傷ついたり、雰囲気が悪くなるのを防ぎたいという気持ちはわかる。自分もそういう空気を察してしまうタイプなので、わざわざ意見をぶつけに行くことには多少の抵抗がある。でも、その“空気を壊さないこと”と“良い意思決定がされること”はまったく別物で、むしろその間にギャップがある方が問題なんじゃないかと思ったりする。 対立＝悪ではない意見の違いはあって当たり前で、対立が起きるということはそれだけ多様な視点が集まっている証拠。 だからこそ大事なのは、「ぶつかることを前提にどう対話していくか」「どう仕組みに落としていくか」。
Thoughtworks Technology Radar とはなにか - yoshidashingo
吉田真吾（@yoshidashingo）です。 めまぐるしく進化するソフトウェア開発の分野において、多くの組織にとって適切な技術選定は難易度の高いプロセスです。企業で利用する多くの技術領域(開発手法、フレームワーク、プログラム言語、ツールやライブラリ、プラットフォーム)それぞれについてロングリストを作成し、自分の組織にあった評価軸や仮説に基づいてショートリストにし、実際にPoC計画を立てて小さいデモプログラム・環境を作成して評価をするといった活動が必要です。さらに、今日採用した技術は半年後1年後にまた再評価が必要になるかもしれない。 こういうプロセスを漏れなく回すためには、成熟化した技術組織を継続維持できている必要があります。十分に組織化されていないスタートアップや、十分な技術投資ができない中小企業や、組織横断的なExcellenceが徹底されていない大企業それぞれにおいてはなかなか実践が
なぜ締め切りを守れないライターには良い文章を書く人が多いのか？｜シュッパン前夜 編集部
締め切りがあるから原稿を書く 締め切りを１ヶ月過ぎた原稿がまだ上がってきていません。 何度も催促して、ようやくライターから「書けたも同然です。今日中には」という連絡がきたのは３日前。さすがに催促の文言も言い訳の引き出しもお互い尽きてきた感があります。 締め切りを設定して、原稿を上げてもらうのは編集者の大事な仕事ですが、これがなかなか悩ましい。 締め切りを破るライターには、良い文章を書く人が多いからです。 （あくまで私の経験上ですが） 真っ先に思い出すのは名コラムニストだった小田嶋隆さんです。 小田嶋さんは「引きこもりの浦和サポ」を自認するほどのサッカー好きでした。サッカー雑誌の連載をお願いしていた頃があったのですが、締め切りを守ったことは一度もありませんでした。発売日に間に合うぎりぎりのタイミングで原稿が上ってくることが恒例になっていて、いつも綱渡りでした。 それでも小田嶋さんが原稿を落と
組織図に対するさまざまな要求と現在地 - LayerX エンジニアブログ
こんにちはまたはこんばんは、バクラク事業部 Platform Engineering 部でID基盤などを管理するチームに所属してあれこれやっている id:convto といいます。 認可などに関連することからバクラクでも「組織図」と表現されるリソースを弊チームで管理しているのですが、今回はその組織図についてお話しします。 この記事で取り扱う組織図リソースについて この記事で「組織図」と表現されるものは、組織の階層をあらわす木構造と、それぞれのチームの従業員所属情報などを管理するリソース全体を指します。 よくある例を簡易的な図で示します。 組織図の例 各社に合わせた情報統制を実現しようとしたとき、組織図は重要な情報です。この組織図をベースにたとえば「あるチームに所属していたらある申請を承認可能にしたい」や、「上位部門に所属している場合はそれ以下のチームに関連するリソースを閲覧可能にしたい」な
941さんに教わったカンファレンスブース設計の秘訣 - CARTA TECH BLOG
こんにちは、CARTA HOLDINGS 技術広報のしゅーぞーです。 今回はCARTAの技術広報メンター @941さんに教わった「カンファレンスブース設計」の秘訣をご紹介します。 背景と経緯 CARTA は2024年4月より 技術広報のコンサルティングをしている @941さんに技術広報メンタリングを行っていただいています。 コロナ禍で社内のカンファレンスブース出展ナレッジが薄くなっていたため、 @941さんに教わりながら1からブース設計のノウハウを学びました。 そのサポートもあり、2024年10月から半年で約5個のカンファレンスにブースを出しました。 その中で学んだこと、また@941さんにフィードバックされた内容を抽出してまとめてみました。実例を交えながら、カンファレンスブース設計の秘訣をご紹介します。 ※: 事前に941さんからレビューを頂いて掲載しております 大前提 カンファレンスでは
【保存版】親が亡くなったらやること全52項目を解説！一覧チェックシート付き - リハコ
「もしも、親が亡くなったら、どうしたらいいの？」 人生で、必ず直面しなければならない、親の死。 いつかその日が来ることを覚悟して。もしくは今まさに、親が亡くなった直後で、この記事を読まれているのではないでしょうか。 初めに、お伝えします。 親が亡くなった後にやることは、文字通り“山程”あります。 あなたがやることを、下記のリストに全部まとめました。 悲しみに暮れる暇もないまま、このように数々の手続きに忙殺される日々が待ち受けています。 とはいえ、しっかりと考えずに手続きを行ってしまうと、 「葬儀会社にぼったくられたり、相続問題で大損した…」 「葬儀で使う遺影の写真は、希望のものを使ってあげたかった…」 「お世話になったみんなに見送られたかったのを知らずに、家族葬にしてしまった…」 などと、後悔してしまうことは、案外少なくありません。 そこでこの記事では、親が亡くなったあとに知りたいことを全
言語モデルの物理学 - ｼﾞｮｲｼﾞｮｲｼﾞｮｲ
言語モデルの物理学 (Physics of Language Models) とは、FAIR (Meta) の Zeyuan Allen-Zhu が提唱した、言語モデルの研究を進めるためのコンセプトです。ざっくり言うと、「あのモデルはこう」とか「そのモデルはこのモデルよりもこう」というような博物学的な知識を深めるのではなく、17世紀にケプラーやニュートンが物理学において行ったような原理に基づいた研究を進め、「言語モデルはなぜこのような振る舞いをするのか」という問いに答えられるようになるべきという考え方です。 言語モデルの物理学の特徴は大きく2つあります。 第一は、ウェブから収集したコーパスを使わず、きっちりコントロールされたデータセットを使って言語モデルを訓練するということ。ウェブは誰も全体像を理解できないほど複雑で、ノイズにまみれています。本物の物理学でも空気抵抗や摩擦があると、「鉄球は
昨年入社した新人さんが、あまりにも助けを求めるのがうまくて、「こいつ人生二度目か？」と思った話。
今日書きたいことは、大体以下のような話です。 ・昨年入社した新人さんが、人生二度目かというレベルで「助けを求めるのが上手い人」でかなり驚いています ・助けを求めるのが上手い人は、大体下記のようなことができています -手遅れになる前に「困っています」を出力できている -何がしたくて、何が出来ていないかを言語化できている -何をやろうとしたか、どこまで試みたかを言語化できている -普段の進捗をちゃんと周囲に報告・共有している -助けを求める際、必要な人を巻き込めている -自然と感謝の言葉を口に出来ている ・これが自然に出来る人は色んなところで得をしますよね ・ただ、ここまでできなくても、ただ「困っています」「進んでいません」をちゃんと出力できるだけでも上司としては十分ありがたいです ・新人さんは、遠慮なく弱音を吐きつつ、少しずつでも「助けを求めるノウハウ」を蓄積していけるといいんじゃないかと思
開発チームの中でセキュリティを育てる - セキュリティエンジニア派遣の試み - カミナシ エンジニアブログ
どうもセキュリティエンジニアリングの西川です。JAWS DAYS 2025 の帰路でこのブログを書いています。私は空港でブログを書く確率が非常に高いです。なぜか捗るんですよね。 さて、カミナシでは昨年からセキュリティエンジニアを二人追加で採用することができ、業務委託含め5人体制になりました。それを機にセキュリティエンジニアを開発チームに派遣する仕組みを導入したのでそれについて話をしていきたいと思います。 セキュリティエンジニアを開発チームに派遣するとは 派遣するセキュリティエンジニアの目指すところを一言で表すならば「特定のサービス・プロダクト・チームを深く理解したセキュリティエンジニア」です。 派遣されるセキュリティエンジニアは基本的には最初の半年から1年程度は開発チームの1メンバーとして、ともに開発や運用を行います。ですので、障害対応やインシデント対応、お客様からの通常のお問い合わせなど
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TypeScript 関数型スタイルでバックエンド開発のリアル
.mdc駆動ナレッジマネジメント/.mdc-driven knowledge management
