エンジニアの認知戦略はなぜすれ違うのか ソフトウェアエンジニアとして業界に長くいると、現場や SNS 上でのエンジニアどうしの「すれ違い」を何度も目にします。技術力の優劣ではない、性格や趣味嗜好の問題とも少し違う、なのにこの「すれ違い」は、驚くほど普遍的に業界内に存在しています。 この記事では、わたしがそのような「すれ違い」を何十年も観測し続けた末にたどり着いた一つの認知モデルに基づく見解です。科学的に証明された理論ではありません。しかし、この視点を持つだけで、日常の摩擦の見え方がかなり変わるはずです。 チーム内での症状 チェックリスト: あなたのチームで以下の状況を見たことはありますか? コードレビューで同じ PR に真逆の指摘が出る。 設計について、すぐ手を動かしたい派と全体像を合意してから着手したい派で割れる。 「なぜこうしたか」は誰かの頭の中にあり、その「誰か」を探す必要がある。
本記事について 株式会社カンリーでは、2025年6月頃から全エンジニア向けにClaude Codeを導入しています。 それ以前にDevinやCursorなども導入しており、現在ではこれら3ツールを個人の裁量で使い分けて業務をしています。 その中においてツールの理解度・習熟度は個人でばらつきがあり、組織として活用レベルを一段上げたいと考えて勉強会を実施しました。 本記事はその際の資料をほぼそのまま掲載したものとなります。 Claude Codeを使ったことはある、しかし使いこなす余地が残されている方向けの資料です。 なぜ今Claude Codeを学ぶのか 「人間がコードを書く時代は終わった」 「人間がコードを書く時代は終わった」—この主張は以前から様々な開発者によって語られてきた。 2026年1月には、Node.js作者でありDeno Land Inc. CEOのRyan Dahl氏もXで同
昨今GitHub上で提供されている有名なOSSに対して攻撃がなされることが多い（例: Nxの2025/08の事例）。自分もそこから学び、最低限GitHub上でセキュリティ周りの設定を入れた方が良いと考えた。 設定を考えるにあたって、とくに次の3つの記事が参考になった。 リポジトリを保護するためのクイック スタート - GitHub ドキュメント Nx の攻撃から学べること #s1ngularity | blog.jxck.io GitHub の Immutable Releases を有効にしてセキュリティインシデントを防ごう これらを参考にAIと協力して最低限のセットアップドキュメントを作ったので共有する。もっとこういう設定を入れるべきなどあれば、教えてもらえると嬉しい。 GitHub OSS セキュリティ最低限セット チェックリスト [ ] Dependabot Alertsを有効化
2025年08月16日23:00 【永久保存版】おんJ民が厳選した有能サイト大全 Tweet 1: 名無しさん＠おーぷん 25/08/16(土) 14:36:53 ID:Ey0G ノイズレスサーチ 邪魔なサイトを除外してGoogle検索できる検索エンジン http://pasokatu.com/nsearch 49%OFF 3: 名無しさん＠おーぷん 25/08/16(土) 14:37:40 ID:Ey0G 幻想世界神話辞典 世界のいろんな神話とか神の名前とかが載ってるサイト https://jiten.info/ 26: 名無しさん＠おーぷん 25/08/16(土) 14:48:48 ID:oBLr >>3 27周年とか凄いわね 5: 名無しさん＠おーぷん 25/08/16(土) 14:39:47 ID:gHmi 暇潰しに使えるサイトでいい？ 6: 名無しさん＠おーぷん 25/08/16
ユニットテスト 基礎講座 Jun. 7, 2025 @JJUG CCC 2025 Spring Takeshi Yonekubo
これを記事にしている 2025 年 5 月の二年ほど前 (2023-06-02) に、縁あって明治大学 情報科学科での特別講義 [1] を担当させてもらいました。 身内の評判は悪くなかったのでスライドは公開していたんですが、単に Google Slides を公開状態にしただけだったんですね。 [2] これではあとから参照・引用するのも難しく、ちょっともったいないかと思ったので、いまさらながら記事の形でまとめなおしておくことにしました。 一年も経てば情報が古くなってしまうコの業界です。賞味期限切れの話もあると思いますが、話のネタにでもしてもらえれば幸いです。 講義の対象と目的 この講義、目的は2つあって、まず「最新の情報科学トピックに触れる」こと。 それから、就職活動が始まる3年生がメインの対象者なので、 今後のキャリアプランとか人生指針に関するいろいろな視点を持ってもらうことです。 この
たまにお客様から「お店でお酒を出すのって、何か免許はいるんですか？」とか「夜の１２時をこえてお酒を出すのって風営法はどう関係しているんですか？」とか「お店を出すのに調理師免許がいるんですよね」とかって質問をされることがあるのですが、実は、日本では、「食品衛生責任者」という資格を持っているだけで小さい飲食店は始められます。この「小さい」ですが、店内で店員の数とお客様を足してその数が３０人までのことです。 ちなみに、僕がやっているbar bossaは席数は１８席で、働いているのは僕１人だけなので、食品衛生責任者の資格だけで大丈夫です。これで２４時間、お酒も出せますし、焼き肉も刺身も出せます。 店内での店員数とお客様の数が３０人以上の場合は防火管理者というのが必要です。 どちらも講習を受けるだけです。テストもないです。 食品衛生責任者というのは、保健所に連絡して、「今度、飲食店を渋谷でやろうと思
2025/02/28(金) JSConf.jp おかわり Node学園46時限目
ウォーターフォールとアジャイルは、それぞれ異なる前提と目的を持つマネジメント手法です。ウォーターフォールは全体計画の精度を前提に効率的な開発を目指し、アジャイルは変化に適応しながら試行錯誤を重ねることに重点を置きます。しかし、世の中ではマネジメント手法としてフェアな評価ができていないようにも感じます。 その要因は、アジャイルの説明が精神論や感情論に寄りすぎている点にあると思っています。そこで、そういった要素を排除し、双方をマネジメント手法として整理してみました。 前提条件 僕は、いわゆるエンタープライズ業界の人なので、SIerがいるような規模の組織を前提にしていますが、マネジメント手法としての考え方は、どの業界でも利用できると思います。 「ウォーターフォール」とは、大手SIerなどで定義されているウォーターフォール的なマネジメント手法のこと。V字と呼ばれる要件定義、基本設計、詳細設計、実装
こんにちは。 id:skozawa です。 こちらの記事は Gunosy Advent Calendar 2024 の 24 日目の記事です。 昨日は上村さんの 「LLM で Web 検索を効率化！- Web 検索エージェントとブラウザ拡張によるアプローチ」 でした。 背景 エンジニアのマネジメント領域 TL の見直し EM と TL の役割定義 キャリアパスの見直し まとめ 背景 Gunosy にはエンジニアマネージャー（EM）とテックリード（TL）、リードエンジニア（LE）という役職があります。 LE については以前に定義しましたが、EM と TL については役割分担が明確化されておらず、EM に負荷が集中しがちになるという課題があったため、役割を見直すことにしました。 EM と TL の役割を再定義し、TL は役職から役割に変更しました。 また、それに伴いキャリアパスを見直すことにし
Learn Vim the Smart WayWhat's This?Learn Vim (the Smart Way) is a guide to learn the good parts of Vim. This project was inspired by Steve Losh' Learn Vimscript the Hard Way. I thought it would be neat to do a broader, albeit less deep, overview of Vim + Vimscript in 2021. So here it is! This guide consists of three parts: How to use Vim How to customize VimHow to use VimscriptIf you're an advance
本記事は BASE アドベントカレンダー 2024 の 24 日目の記事です。 こんにちは、エンジニアリングマネージャーの松原(@simezi9)です。 新型コロナウイルスの流行に端を発する世の中の変動からもうじき5年が経過しようとしています。 当時の感染対策の流れで多くの企業がリモートワーク制度の導入を進めました。この記事を読んでいる方の中にもそのタイミングではじめてリモートワークに取り組んだ方も多いのではないでしょうか。 私もその当時に、BASE株式会社のリモートワークへの取り組みをエントリとして公開したことがありました。 参考：エンジニアのリモートワーク in BASE このエントリを書いてから4年。その間、マネージャーという立場からリモートワークの制度を運用してきた経験を踏まえて、私がいまリモートワークというシステムに対して思っていることを率直に書いてみたいと思います。 この文章が
創業以来、GitLabはDevSecOpsプラットフォームアプローチを適用して、65か国以上で人々が共同作業を行い、コミュニケーションし、結果を生み出す方法を革新してきました。当社では、その知識とベストプラクティスを一般に公開しています。
2024年12月20日 ソフトウェアテストシンポジウム 2024 東海 #jassttokai24
こんにちは、株式会社スマートバンクでモバイルアプリエンジニアをしているロクネムです。 書籍『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』ではプロダクト開発には以下の4つのリスクがあると説明されています: 実現可能性のリスク: エンジニアが、持っている時間とスキルとテクノロジーで必要なものを作れるかどうか 価値のリスク: 顧客が購入するかどうか ユーザビリティーのリスク: ユーザーが使い方をわかるかどうか 事業実現性のリスク: ソリューションが、販売、マーケティング、財務、法律など、ビジネスのさまざまな分野でも問題がないかどうか (順番は入れ替えています 🙏) 同書では、優れた開発チームはこれらのリスクに対して開発の早い段階で取り組むと記されています。 自分はこれらのリスクのうち「実現可能性のリスク」「価値のリスク」「ユーザビリティーのリスク」の3つについてはモバイル
スクラムガイドの目的 スクラムは複雑なプロダクトを開発、提供、保守する為のフレームワークである。このガイドではスクラムを定義している。定義には役割、イベント、作成物とそれらをまとめるルールが含まれている。フレームワークの各要素は特定の目的を有し、スクラムによって実現される価値と成果にとって不可欠な要素となる。スクラムの考え方や構造を変えたり、要素を省いたり、ルールを無視する事は問題を隠し、スクラムから得られる価値を限定したり、無意味な物にしてしまうのである。 Ken Schwaber と Jeff Sutherlandはスクラムのフレームワークを作る事に重要な役割を担った。 LeSS（大規模スクラム）は複数のチームでプロダクト開発をする際にスクラムを適応し、組織のシステムが変化した結果として形作られ、LeSSはLeSSルールにて定義をされている。LeSSルールは、各チームのレベルではスクラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
