石黒です。今日は社内向けに書いたメモをnoteにも公開したいと思います。 スタートアップ、日報文化がある会社も多いのかな？と思います。 この『日報』ってのは大変に奥が深く、これだけでいくらでも話せるくらいに日報にまつわるあれこれを見てきました。 組織文化の話、日報の話、業務の可視化の話、義務なの？みたいな話、色々あると思いますが、成長企業においてこの『日報』というものと10年付き合ってきた私からの視点をもとに、社内メモを公開します ※以下、社内メモより転記 LayerXの日報文化LayerXには「日報文化」があります。Slackの #daily_report チャンネルには450人を超えるメンバーが入っています（2025年9月現在）。 日報はLayerXのミッション「すべての経済活動を、デジタル化する。」を達成するために非常に大切な文化です。『LayerX羅針盤』にもAppendixのとこ

組織の地力は「当たり前のレベルがどういう水準か」に現れる。 たとえば「このレイヤーのテストコードは当然書く」とか「Pull Request の description はレビュワーや将来の自分たちのために丁寧に書く」とか。あるいは、「皆が今期のチーム目標を言える」とか「期日までに勤怠の提出を全員が終えてる」とかもそう。 こういった一つ一つの"当たり前"のレベルがどういう水準かが組織の強さと言えるが、これを上げていくのはなかなかむずかしい。この"当たり前レベル"を上げていくにはどういうステップが必要かを雑に書いてみることにする。 1. トップオブトップを知る まずはトップオブトップの組織ではどういうレベルなのかを知ること 現時点でのトップの当たり前レベルを知り、そこから自組織の相対的な立ち位置を把握する 手段はWebや書籍、Podcastからのインプットでもいいし、イベントやカンファレンスに

こんにちは、プラットフォームチーム所属のmaco+（まこたす）です。 ちょうど2年前に「モノリスなRailsにモジュラーモノリスを導入した話」というタイトルで執筆させていただきましたが、その後の取り組み・経過について中間レポートをお伝えできたらと思います。 導入の背景 本題に入る前に導入の背景やポイントについて簡単におさらいしたいと思います。 導入検討当時、今後人数の増加が考えられる開発組織においてhacomonoプロダクトの開発生産性を下げないようにしたいという課題がありました。人数が増えると複数のチームから触れるようなコードに対しては認知負荷があがり責任の所在が曖昧になるものです。当時これらの問題はそこまで顕在化しておらず、予防的な意味合いでモジュラーモノリスの導入がなされました。 なぜモジュラーモノリスだったのかなどより詳しい話は、先述の記事を参照いただければとおもいます。 また当時

今回は、エンジニアのマネジメントについて書いてみます。 まず簡単に自己紹介をします。私は新卒でDeNAに入社し、主にスマホゲームのサーバ機能を提供するゲームプラットフォームの開発に携わっていました。 その後YOUTRUSTでのサービス開発を経て、プレックスというベンチャー企業に入社。テックリードとしてゼロからSaaSを立ち上げ、開発に取り組んできました。 開発した建設業向けのVertical SaaSは、導入社数1500社を超えました。 チームを持って育成やマネジメントをするようになったのは、２年ほど前から。チームはインターン生も含めて５人です。 マネジメント経験はまだ浅く、偉そうなことを語れる立場ではないのですが、この２年ほど試行錯誤しながら考えた「これからのエンジニアマネジメント」について、備忘録的にまとめておこうと思います。 （質問や議論、大歓迎です！　コメント等お待ちしてます。）

いま一緒に働いている同僚が「考える時間軸を伸ばす」という言葉をよく使う。 「もう少し考える時間軸を長くしたいですね」とか「時間軸を長く考えてみると〜」とか。自分はこの言葉がとても好きで、最近の考え方にも影響している。この"考える時間軸"を伸ばすということについて、雑に考えをまとめておく。 考える時間軸が短いと、重要な問題が放置されたり解決策の意思決定の筋が悪くなったりする。 たとえば、腰を据えて取り組む必要のあるアーキテクチャ改善やシステムリプレイスをイメージしてみるとわかりやすいかもしれない。 1年以上かけて取り組む必要があるようなこういった課題が、明確に"放置する"という意思決定をされることなくぬるっと優先順位が下がって対応されないという経験をしたことはないだろうか。あるいは、根っこの解決の選択肢を最初から除外して今できる範囲で取り組める小手先のパッチワークを繰り返してしまったりとか。

2025年7月5日に開催された「Claude Code 初学者 勉強会 2」の登壇資料です。 https://currypurin-dojo.connpass.com/event/360112/

自分としては成果を出して貢献していると感じているのに、いまいち組織からの評価は高くならない時に考えたほうがいいかもしれないことを雑にまとめてみる*1。 0. 自分に原因があると仮定する 「自分はこれだけやっているのに正当に評価してくれない」と憤りを感じて、イライラしたり悲しくなったりしているかもしれない。わかる もしかしたら上司や制度にも問題があるのかもしれないが、そこをいくら考えても自身ではコントロールしにくいし好転しないことが多い。憤りを感じたりモヤモヤしたりする時は、まずは自分がコントロールしやすいところにフォーカスして考える方がよい 気持ちの切り替えが難しいけれど、いったん「原因はすべて自分にある」と極端に考えて以降のポイントを深堀って考えてみるとよいかもしれない 1. がんばる方向を確認する 組織にとって必要なことではなく「自分はこれが大事だと思った」ということをひたすらやってし

2025/6/24に開催された「AI駆動開発、そのやり方で合ってる？PMとエンジニアで語る AI駆動開発に求められる品質とは」の登壇資料です。 https://offers-jp.connpass.com/event/356194/

システム開発は「決めること」の連続なので、そこからの学びをちゃんと得ていけば、影響範囲に応じた適切な意思決定ができるようになると思うんだけど、そこを回避して「作業者に徹する」と先のキャリアで詰んじゃうよーって話をした— magnoliak🍧 (@magnolia_k_) June 9, 2025 ほんとプログラムを書いたり、アーキテクチャ設計とかしていると、「変数の命名」みたいなレベルからコストを踏まえたミドルウェアの選定まで、影響の大きさの大小に関わらずたくさんの「決めること」が出てくる 個人開発では全部決められるかもしれないけど、受託だったり、自社サービスだったりすると、案は出せるけど、決める権限が無い、みたいな場面も多い。 でもそんな中でもプロとして、「こうあるべき」を提案できる人は、「決める立場」になった時に適切に決められるようになるし、「決める人の気持ち」への理解が深まり、より

[社内共有版「Claude Code、どこまでも」] はじめに Claude Codeを使い始めて1週間。私の開発スタイルは完全に変わった。 きっかけは3ヶ月前に書いた「生成AIといっしょ: 動作するきれいなコードを生成AIとつくる」という記事だった。当時はAIとの協業について考察していたが、正直なところ、まだ私が「運転席」に座っているつもりでいた。AIはあくまで「副操縦士」だと。 syu-m-5151.hatenablog.com 現実は違った。 実際にClaude Codeを使ってみて最初に感じたのは、自分の開発スタイルとAIの特性のミスマッチだった。私は根っからの「とりあえずコード書いてみよう」タイプ。設計書？計画？そんなものは書きながら考えればいい—それが私の流儀だった。 ところが、AIは違う。指示に対して忠実すぎるのだ。「認証機能を実装して」と曖昧に伝えれば、私の意図とは全く違う

はじめに 最近のAI関連技術の進化は目まぐるしいですよね。私たちfreeeの開発組織でも、世の中のトレンドに追従、あるいは先回りする形でGitHub Copilotや社内から安全にLLMを利用するための基盤整備にも取り組んできました。そして2025年、これまでの検証フェーズを経て、AI活用をさらに加速させるべく、AIツールの本格導入を進めています。 現在、freeeの開発現場では主に GitHub Copilot、Cline、そしてDevinといったAIツールが活用されています（他にも細かなツールはありますが！）。特に最近全開発者向けに開放されたClineは、今後の開発スタイルを変える可能性を秘めていると注目しています。 この記事では、そのClineを全社導入するにあたり、私たちがどのように考え、どのような課題に直面し、そしてどう対策してきたのかをお伝えできればと思います。この記事が、AI

こんにちは！「家族アルバム みてね」（以下、みてね）SREグループのおじまです。 今回は、みてねの開発プロセスを支えるデプロイパイプライン、特にブランチ戦略を改善し、ステージング環境における占有問題などの課題を解決したお話をご紹介します。 みてねの開発フローとこれまでの課題みてねでは、ブランチ戦略としてGitHub Flowを採用しています。GitHub Flow では、はじめにメインブランチからフィーチャーブランチを作成します。フィーチャーブランチで機能開発を行った後、プルリクエストを作成します。フィーチャーブランチは、プルリクエストにおけるコードレビューを経て、メインブランチにマージされます。メインブランチは常にデプロイ可能な状態に保たれます。GitHub Flowは、シンプルで分かりやすいのが特徴です。 しかし、GitHub Flow自体には、本番環境以外へのデプロイ方法について明確

Qiita Conference 2025 https://qiita.com/official-campaigns/conference/2025#day3 Appendix - https://konifar-zatsu.hatenadiary.jp/entry/2023/11/01/193210 -

単なる感想です。 タイトルの通り、カミナシという会社において自身が納得いく働きができていないと感じているので、 それについて書こうと思います。 posopmeの経歴について カミナシのVPoEは何をする人なのか? 何に納得がいっていないのか? どうすれば納得いく働きができるようになるのか? そもそもそういった動きを求められているのか? 実はあまり悩んでないし、やりがいはある まとめ 宣伝 posopmeの経歴について サクッと説明すると以下になります。 ソフトウェアエンジニアとしてのキャリアを積んだ後、 2016年より株式会社ディー・エヌ・エーでソーシャルゲームプラットフォームの開発に携わる。 その後、2018年より株式会社メルペイでテックリードとして認証認可基盤の開発・運用を担当。 2020年に入社した合同会社DMM.comではアーキテクトとして 100名規模の開発組織で技術戦略を主導す

こんにちは。エスマットエンジニアの金尾です。 皆さんはDevinと働いていてつらい思いをしたことはありますか？　僕はあります。 弊社にDevinがやってきてからしばらく経ちました。チュートリアルとも言われる250ACUは早々に使い切り、今ではプロダクト改善タスクをこなしながらいろいろと運用方法を模索している段階です。 支払い上限分まで働くとその後は一切の活動を停止するDevin。 いち労働者として見習いたい。 本記事では、Devinを使ってみた所感および今後の活用についてまとめたものです。 AIエージェントとしての特徴 以下、二ヶ月ほど使ってみての所感です。 (他と比較すると)遅い Cursorなどの他のAIエージェントと比較すると、Devinの作業スピードは決して速いものではありません。Sessionチャットからその場で都度指示出しすることはできますが、体験としてはあまりよくなく、併走し

こんにちは。研修担当のyukyanです。GMOペパボは2025も新卒研修をやっていきます。今年の目玉はVibe Coding研修です。この記事では、まずVibe Codingとは何か、そしてVibe Coding研修の目的と内容、最後にCTOのあんちぽからVibe Coding研修にかける思いをお話します。 Vibe Codingとは？ Vibe Codingは、「完全に雰囲気に身を任せて、コードの詳細に気を払わず、自然言語だけで指示をしてコーディングする」コーディングスタイルです。このスタイルは、OpenAIの共同創設者であり、TeslaのAIディレクターとしての経験があるAndrej Karpathy氏が2025年2月に提唱したものです。具体的に説明していきます。 There's a new kind of coding I call "vibe coding", where you

LayerXのAI・LLM事業部で事業部CPO 兼 プロダクト部の部長をしている小林(@nekokak)です。 2025年4月1日から事業部内の体制が変わり、プロダクト開発を推進するチームもupdateがあったのですが、内外からどういう体制なんですか？って聞かれることが多いので簡単ではありますが、我々がどういう体制で開発を行っているかを紹介してみたいと思います。 AI・LLM事業部 全体の体制について AI・LLM事業部は4月1日から２つの部が誕生しました。 BizDevとコンサルティングを中心とするビジネス部、プロダクト開発・運用を行うプロダクト部の２つです。 私はプロダクト部のマネージメントを行うことになりました。 事業推進にはビジネス部との密なコミュニケーションは重要で普段からかなりコミュニケーションは取っているのですが、今回はプロダクト部の説明にフォーカスしてみます。 プロダクト部

TVerバックエンドチームの id:takanamito , 小林 ( @k0bya4 ) です。 この記事では、TVerにおけるAPIリアーキテクチャについて紹介します。 ここでいうリアーキテクチャはAPIサーバーのソフトウェア的なアーキテクチャを変更する作業のことを指します。一部インフラにも変更点はありますが、今回の記事ではソフトウェアのリアーキテクチャにフォーカスして書いていきます。 今回の記事では、なぜリアーキテクチャをするのか、どのような課題を解決しようとしているのかを整理して解説します。 リアーキテクチャをする理由 新アーキテクチャの設計方針 オニオンアーキテクチャの採用 プロセスの分割 新アーキテクチャの具体的な取り組み アーキテクチャ構造と分割の意図 コードジェネレートの積極的な採用 OpenAPI ORM APIのマイグレーション計画について やらなかったこと できていな

ダイニーの urahiroshi です。 自分は前職のメルカリ、現職のダイニーで計3年くらい Engineering Manager を務めてきましたが、Engineering Manager の本質的な役割は「チームや組織のパフォーマンスを最大化すること」だと考えています。そのためには、チーム開発におけるメンバー間のスムーズなコミュニケーションが不可欠です。 これまでコミュニケーションに関するフィードバックを行ってきた中で、よく見られる改善点がいくつかあったため、それらをベストプラクティスとしてまとめてみました（それぞれのセクションで一つずつ本が書けるくらい多数のプラクティスが挙げられるテーマだと思いますが、特に頻出するポイントに絞っています）。皆さんのチーム開発にも役立てていただければ嬉しいです！ レビューをするときのプラクティス 指摘にはWhyを書き、Howを押し付けない ❌️ Ba