エンジニアのコミュニケーションで気をつけているのは「正しさ」より「前に進むか」
うぐいすソリューションズ Advent Calendar 2025の 24 日目担当の zen です。ラストバッター頑張ります。 エンジニアのコミュニケーションで気をつけているのは「正しさ」より「前に進むか」 エンジニアとして働いていると、「何が正しいか」は割とすぐ分かるのに、それをどう伝えるかで悩む場面が多いなと感じます。 僕自身、コミュニケーションが得意だと思ったことはあまりありません。それでも振り返ってみると、(自分を変に攻撃してくる人がいない場合に限りますが)プロジェクトが大きく揉めたり、人間関係が壊れたりすることは少なかった気がします。 なぜだろう、と考えてみた結果、どうやら僕はずっと 「正しいことを言う」より 「チームが前に進むかどうか」 を優先してきたように思えます。 この記事では、そんな僕が普段あまり意識せずにやっている、エンジニアとしてのコミュニケーションの考え方をまとめ
よいセッションとは何か？ ～ カンファレンスプロポーザルの本質を考える - kawaguti’s diary
はじめに アドベントカレンダーの時期、ブログなどで、セッションの通し方、みたいなノウハウが語られることが多いようです。カンファレンスの実行委員としてオープンプロポーザル形式で公募するようになって長いので、私なりにこうあってほしいなーということを書いてみることにしました。 「よいセッションの作り方」「よいプロポーザルの書き方」「そのための日々の過ごし方」という流れでブログが書かれるといいなーと思うのですが、実際は「ウケるプレゼン作成術」「通るプロポーザルの書き方」こそが利用者にウケる、というコンテンツが増えたりはしそうです。 これはOutput, Outcome, Impact の話につながるのですが、登壇することを通じて得たい成果(Outcome)は話を聞いてもらって、参加者の皆さんに活かしてもらうこと、それが話者の評価にもつながるというところかなと思います。そうして参加者の皆様が成功すれ
言語化が下手な人は5つのタイプに分けられる｜すてぃお
「Slackで何を言いたいのかわからない」「ドキュメントを書くのに異常に時間がかかる」 こういった人は組織に一人はいないだろうか。 マネージャーとして「言語化能力を鍛えてほしい」と思うことは多いとは思います。また、LLMを利用して業務を行う際には言語化能力が非常に重要となると考えております。 ですが、正直なところ、できていない人に対して、トレーニングでなんとかなるのか疑問に感じることもあるのではないでしょうか。 僕は23歳の頃、会社の先輩に「お前、何言ってるかわからないから話すのやめるわ」と言われたことがあります。かなりショックだったのですが、それ以来、「どう伝えればわかってもらえるか」を強く意識するようになりました。 その結果、今では言語化能力が高いと言われることもあります。（このようなnoteを書いていると言語化してもらうの助かるとも言われます。） このような経験から言語化能力は天性の
Claude Codeを使ってリポジトリからWikiを生成する
Claude Codeを使ってリポジトリ内を探索してWikiを構築してもらったところ、高精度で実用性の高いものができました。再現手順を共有します。 実例 このようなWikiが完成しました。 DeepWikiが出力したものと比較しても遜色ない品質であると思います。 Wikiのセットアップ GitHubリポジトリの設定画面からWikiを有効にし、空のHomeページを作成してください。 詳細な説明は省きます。 Git submoduleとしてクローン GitHub WikiはGitリポジトリとして扱えるため、以下のコマンドでsubmoduleとしてcloneします。 クローン先はどこでもいいですが、今回はリポジトリ直下のwikiディレクトリにします。 手順書(wiki-manual.md)を作成 Wikiを作る際のルールをまとめた手順書を用意します。自分の好みに合わせた手順を用意すればいいですが
技術力に優劣はある(「技術力に優劣はない」を読んで) - じゃあ、おうちで学べる
sizu.me はじめに 先日、「技術力に優劣はない（技育などに参加している学生に向けて）」という記事を読みました。技育に参加する学生たちへの励ましのメッセージで、技術との向き合い方の多様性を認め、コミュニケーション力の重要性を説き、相互リスペクトの大切さを訴える、とても温かい内容でした。 この記事は、あの記事の対象読者ではない私が、横から口を出すような形になってしまうことを承知で書いています。 元の記事の主張——技術の感受性には段階があること、ジュニアにはコミュニケーションが大事なこと、べき論に揺さぶられないこと、どの段階にいてもキャリアは作れること——これらは本質的に正しいと思います。 ただ、私はこう思います。それでもなお、技術力という軸においては、やはり優劣が存在し、それが中長期的なキャリアに大きな影響を与えます。 このブログが良ければ読者になったり、nwiizoのXやGithubを
【2024年最新】Python環境構築完全ガイド：OS別・目的別ロードマップ
Python開発において避けて通れないのが、プロジェクト間の依存関係の衝突です。これを解決する鍵は「仮想環境の徹底利用」にあります。標準ライブラリのvenvを使用し、プロジェクトごとに独立した実行環境を構築することが、再現性と安全性を担保するベストプラクティスです。まず、以下のコマンドで環境を作成・有効化し、必要なパッケージをpipで管理しましょう。この習慣を徹底することで、「私のPCでは動くのに」問題を根絶できます。 # 仮想環境の作成と有効化 python3 -m venv .venv source .venv/bin/activate グローバル環境が引き起こす依存関係の「地獄」から脱却する Pythonを使った開発を始めるとき、最初に直面するのが環境構築の壁です。「とりあえず動けばいいや」と安易にPC全体（グローバル環境）にパッケージをインストールし続けた結果、以下のような深刻なト
runn と Testcontainers で「ちょうどいい」Go API テスト - Techtouch Developers Blog
はじめに バックエンド API のテスト事情 バックエンドのテスト構成（これまでとこれから） テスト構成分類（これまで） テスト構成分類（これから） 「ちょうどいい API テスト」とは API テストに求める価値 実行の容易性 メンテナンスのしやすさ 技術選定のポイント runn の採用理由 Testcontainers の活用 実装例 API サーバー実体 APIテスト runn シナリオ APIテストコード おわりに はじめに バックエンドエンジニアの nome です。花粉症🤧なのでこの時期はリモート仕事の幸せを改めて実感しています。 テックタッチのバックエンドAPIでは、これまでユニットテストと Postman による API 統合テストを中心に自動テストを実施してきましたが、テストカバレッジの不足や実行・メンテナンスコストの課題がありました。 本記事では、これらの課題を解決する
【過去の社内メッセージより】グーの根も出ないSHIFTの評価軸｜丹下大 masaru tange 【大の視点 at note】
2010年より、SHIFTの社内向けブログにさまざまなメッセージを書いてきました。そのメッセージをより多くの方たちに読んでいただきたいと思い、noteに転載したいと思います。今回は、SHIFTの評価制度に関する根本的な考え方についてのメッセージです。 （SHIFTの社内向けブログ2018年4月4日） ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ SHIFTは新卒の人、中途の人、めちゃくちゃ増えていますし、毎年1.6倍で成長しており、従業員も2,000人を超えるほどになってきました。 僕は兼ねてから、経営というよりも会社は街の運営だと言っていますよね。 みなさんが、技術を磨いたり、社員同士でお互いに経験をシェアしたり、品質保証とは違う視点で交流をはかったり、安心安全に働ける環境を整え、その結果お客さんが喜び、価値を認めてもらい、しっかりとフィーを払ってもらい、その結果自分
第860回 Ubuntu+Visual Studio Code+Ollamaでプログラムの相談をする | gihyo.jp
今回はVisual Studio CodeにAI Toolkit for Visual Studio Codeをインストールし、Ollamaのフロントエンドとして使用する方法を紹介します。 AIにプログラムを書かせるところまでしなくても 世間ではAI（LLM）にプログラムを書いてもらって云々という話題をよく見かけますが、そこまではしなくても、プログラムに関する悩みごとがパパっと解決したらいいなと思うことはよくあります。たいていは試行錯誤の上で解決するので、LLMに悩みを聞いてもらって解決できたら、ずいぶんと生産性が上がることでしょう。もっといい書き方あるのではないかと訝しんだり、思いつかない不具合があるのではないかと疑心暗鬼になることもあります。そんなときも、LLMに聞いてもらえればそれなりの答えが期待できます。とはいえあまり大事にはしたくないので、ローカルで動作するLLMを使用したいとこ
言語化ニガテ民にはZettelkastenがおすすめ
これはなに こんにちは、LT開発部のもりたです。 今回はもりたが最近はじめたZettelkastenのご紹介をします。これは知識管理の手法で、アウトプットの敷居がめっちゃ下がるやつなんですが、ま〜〜よくわからん単語すぎて困ると思うので、今日はサクッと本編に入りますね。 Zettelkastenとは？ Zettelkasten（ツェッテルカステン）は、学びを小さなメモにして保管する方法論です。やっていることはそれだけで、ただただ学んだことを小さくメモにまとめて貯めていきます。その際に大切な点があり、それは「自分の言葉で書く」ことと、「情報をなるべく小さく保つ」ことです。 Zettelkastenっていろんな説明のされ方があるんですが、この「範囲は小さく、品質は高く」思考を言語化できるというのが最初の大きなメリットです[1]。 今回はZettelkastenなんて１ミリも知らんぜというみなさん
4万行超のopenapi.yamlをTypeSpecに移行した話
4 万行超の openapi.yaml のツラミ ファイルが大きすぎて編集しづらい OpenAPI が肥大化していくにつれて開発体験の低下を招いていました。 GitHub Copilot や Cursor の Tab 機能で随分楽になりましたが、それでも 4 万行もあるファイルを手作業で入力するのは純粋に辛いです。 AI Agent のコンテキストを大きく圧迫する Cursor 等の AI Agent のコンテキストを大きく圧迫することが直近の開発で大きな課題となりました。 具体的には次のような問題が発生したため、ファイルを分割することが急務となりました。 コンテキストが溢れて Cursor Agent が停止する Longer Context を有効化すると処理できるようになるが、トークンを余分に消費してしまう TypeSpec とは TypeSpec は、API を記述するための Mi
SSRで認証をどうするべきか？
既存プロジェクトにNext.js等のSSRを導入する場合は既存の認証機能を維持したり活かしたりする必要があります。しかしSSRの認証とCSR(SPA)の認証は同じではなく、簡単に共有できるものではありません。 ここでは複数のテックブログの事例を見ながら、この難しさと本物のウェブサービスで採用された解決策を見ていきます。 CSRとSSRの認証の違い まず最初に、CSR(SPA)とSSR[1]の認証の違いをざっくり紹介します。技術的制約を理解していただくことが目的です。 クライアント視点では、認証システムは突き詰めると、トークン(鍵)[2]を安全に保管し、必要時にサーバに渡す(鍵穴に差し込む) ことです。この２つに絞って解説します。[3] https://www.flaticon.com/free-icons/vault (by IYIKON) https://www.flaticon.com
エンジニアの目標設定で意識していること - yigarashiのブログ
はじめに マネージャーにとって目標は組織の成果を大きくするための強力なツールです。しかしジュニアなマネージャーにとって、目標設定をどのように行うかは、なかなかまとまった知見を得づらく不安を感じやすいようです。本エントリでは私がエンジニアリングマネージャーとして目標設定で考えていることをまとめてみます。 まず前提として、私は自社でWebサービスを開発している事業会社のエンジニアリングマネージャーで、ソフトウェアエンジニアの目標管理を行なっています。組織全体の制度としてはMBOに近く、組織の目標があり、そこに向けて各メンバーも個人目標を設定し、その達成度合いによって評価します。一回のイテレーションの長さは半年で、（その是非は様々あるとして）評価は給与査定と連動しています。状況が違えば私がこれから述べることが当てはまらないケースも多分にあるかと思うので、そこは各自でうまく受け取ってください。 マ
OAuth 2.0の認可エンドポイントにおける脆弱な実装例と対策について考える - Qiita
認可コードグラント RFC 6749で定義されるOAuthの認可コードグラントでは、認可サーバの実装として、認可エンドポイントとトークンエンドポイントの2つが必要です。リクエストは大きく分けて認可リクエスト (Authorization Request) およびトークンリクエスト (Access Token Request) の2つに分けられます。 全体のシーケンス図は以下の通りです。 PlantUMLのソースコード @startuml @startuml title 認可コードグラントにおけるシーケンス図 autonumber actor RO as "リソースオーナー" participant UA as "User-Agent" participant C as "クライアント" participant AS as "認可サーバ" participant RS as "リソースサーバ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
衝突（コンフリクト）のマネジメント | ドクセル
【特集】 俺はローカルアカウントで使いたいんだよ！Windows 11のセットアップでMicrosoftアカウントを回避する方法最新版
https://x.com/ryuzee/status/1918482796588482965?s=12
ミニPCに「外付けグラフィックボード」を増設して劇的な性能アップ【MINISFORUM DEG1を検証】 | ちもろぐ
「布団を干すだけ」ではダメ。家の中のダニ対策の正しい手順をプロに聞いた（女子SPA！） - Yahoo!ニュース
もし今からGraphQLを採用するなら
