メモ: いつも忘れるPython + uv + ruffのVSCodeの設定2025年9月版
いつも忘れてどっかからコピペしているのでメモしておく．Ruffを使うようになってfomatter/linterの設定がめちゃくちゃ楽になってほんと助かる．
VSCodeのsettings.json
Formatter
{ "[python]": { "editor.formatOnSave": true, "editor.codeActionsOnSave": { "source.fixAll.ruff": "always", "source.organizeImports.ruff": "always" }, "editor.defaultFormatter": "charliermarsh.ruff" }, "editor.formatOnSave": true, "editor.formatOnSaveMode": "file" }
Ruffの設定
[tool.ruff]
lint.select = [
"F", # Flake8
"B", # Black
"I", # isort
"E", # error
"W", # warning
"UP",
]
lint.ignore = []
lint.fixable = ["ALL"]
exclude = [
".ruff_cache",
".venv"
]
line-length = 120
indent-width = 4
target-version = "py313"
[tool.ruff.format]
quote-style = "single"
AIではない生きた人間としてどうソフトウェア開発に関わっていくか2025
仰々しいタイトルをつけてしまったからにはそれに見合う文章を書かねばなるまい．なおこの文章はすべて人力で作成しており一切AIの手を借りていない．
自分の立ち位置
ソフトウェアエンジニアとしてのキャリアを数えると今年で12年になるらしい*1．12年ってすごい．生まれた子どもが小学校6年生になってしまう．そりゃ甥も姪も大きくなるわけであり，自分も歳を取り衰える訳である*2．
ソフトウェアエンジニアを取り巻く現状
2025年7月現在，多くのソフトウェアエンジニアがキャリアについて改めて考えさせられていると思う．Vibe coding*3は間違いなくソフトウェアエンジニアの仕事を奪いつつある．すでに多くの人達が日々「驚いて」いるように，devin, cline, claude code, gemini cliといったAIコーディングツールが人間を凌駕するスピードでコードを書き始めた．GitHub copilotが登場した時は「よくできたコード補完」という程度で，プログラミングにおける補助ツールに過ぎなかった．しかし，今やAIコーディングツールが主役に成り代わっている．自分も職場でdevin, cline, claude codeを使い，プライベートではcodexも使っているが，使い始めてすぐエディタと同等のプログラミングにおける必須品になった*4．
実際に自分でゼロからコードを書く機会は大幅に減少した．まずAIにドラフトを書かせてその後人間がリファクタリングする，もしくは人間が書いたコードに対してAIがテストを書く．そんな仕事の仕方が基本になった．論文や長いドキュメントはまずNotebookLMに入力して要約させ*5，その上で自然言語で知りたい情報だけを質問する．OSSのコードは自分でいきなりコードを読まずにdeepwikiで概観を把握してから深堀りする．そんな感じで，ありとあらゆるタスクにとりかかる時は「まずAIに頼む」ようになった．自分がキャリア駆け出しの頃，自分のタスクすべてをメンターである先輩経由で受取り，すべてのアウトプットをその先輩にレビューしてもらうスタイルで仕事をしていた時期があった．その頃の自分が今のAIのような立ち位置だなと感じている．このような様を見れば「もう人間はいらない」と思う人が出ても不思議ではない．メディアのこういった体験談が書かれた記事を読んだ偉い人が「もうソフトウェアエンジニアはいらないので採用計画を見直すために今募集しているポジションを全てcloseしよう」と主張し始めても仕方がないと思う．
大Vibe coding時代における生きた人間の価値
一方で，これまた多くの人が指摘するように，AIによるVibe codingも当然完璧ではなく，多くのミスを平気で行う．厄介なのはミスをうまく隠蔽することが多い点である．例えばclaude codeで，「修正後は必ずテストが全て成功することを確認する」というルールを~/.claude/CLAUDE.mdに追加していたら変な修正で無理やりテストを通したり，テストが通るのをいいことに本来の要件とは異なる修正をしたりと，割とカジュアルに変なことをしてしまう*6．プログラミングだけはできるが，既存のコードから設計意図を汲み取ってその方針を守る，みたいなことが死ぬほど苦手らしい．planningフェーズを挟んでも同じミスを繰り返すのでこのあたりがclaude codeの限界のようにも見える*7．なので，まだまだこの辺の分野は人間の方が有利であり，人間のソフトウェアエンジニアが必要な理由であると主張できそうである．ただAI関連の技術は日進月歩であり，1年経ったらどうなるか分からない．設計意図を正しく汲み取れるモデルやリファクタリングだけが異常に得意なモデルが出てきても不思議ではない．
この先生きのこるには2025
では今後どのように生き残っていけばいいのか，という話になるが，一つの方針としてはAIに奪われない知見をコードにフィードバックできる立場であり続けるしかないような気がする．要するに，実運用で実際に起きたincidentの知見，一つのGitHub repository上のコードベースだけでは分からない連携しているmicro serviceや連携している外部サービスの事情，インフラ側のクラウドベンダーの事情，ソフトウェア開発のベストプラクティスには反するがビジネス要件上そうせざるを得ない「歪んだ」設計，といった人間だけが知っていることをAIにフィードバックし続ける作業は，今のところ人間にしかできない．現存する商用LLMのcontext lengthはソフトウェア開発タスクにおいては割とすぐに使い切ってしまえる長さで，かつ長期記憶を効率よく保存したり参照する手段がないと感じているため*8，このあたりではまだ人間の方が有利なのではないかと考えている．最終的にAIと会話し続けるのはソフトウェアエンジニアであり続ける以上，こういった知見を直接AIにフィードバックしたり，AIの成果物をチェックするのは人間しかできない仕事だと思っている．いわゆる「シニア」や「スタッフ」レベルのソフトウェアエンジニアにしかできないフィードバックをAIに与え続けるのが当面の人間が発揮すべき価値になるのではないだろうか．
もちろんこういったフィードバックをするには人間の側にもインプットが大量に必要であり，AIと会話している時間以外はチーム内外の他のメンバーと積極的にコミュニケーションを取り意思決定をリードする仕事はこれまで以上に重要になる．また，コンピュータサイエンスやソフトウェアエンジニアリングの世界の新しい知見もキャッチアップして開発に反映させていく作業が必要なのはこれまで通りなのでこちらもサボる訳にもいかない．なんかAIのお陰で仕事がラクになるどころかより難しいレイヤの仕事の割合ばかりが増えているような気がするが，people managementを業務に含めないIC (indivisual contributor)としてのソフトウェアエンジニアとして価値を発揮していくには，どうしてもこういった人間にしかできない仕事での価値を発揮していくしかないと思う．
これを面白い仕事と思うかつまらないと思うかは人それぞれだが，自分自身は，歳を取ってアラフォー真っ盛りになったこともあってか，自分で手を動かすよりも，自分の知見や考えをチームに伝えて全員の生産性や品質を高めていくようなバフをかける立場の方が合っていると感じ初めている*9．次の10年をICのソフトウェアエンジニアとして生き残るにはいかにチームにバフを効率よくかけられるかが大事になってくると考えている．もちろんpeople managementにシフトするのも一つの手ではあるが，自分自身の性格としてソフトウェア開発の現場にいてpeople managementに専念できる訳がないので，自分が出す価値がAIのそれを上回ることができなくなるまではまだICとしてもがいてみたいと思う．
おわりに
この文章はここ半年でソフトウェア開発の現場で起きた変化と，その上で考えたことをまとめてみた．来年もまた今ぐらいの時期に似たような振り返りをしてみたいと思う．
*1:最初の2年半はシステムエンジニアという肩書だったので除外している
*2:登山とトレランとマラソンを始めたら体力だけは逆に20代の頃を超えて逆転してしまったが
*3:このエントリ内ではAIが介入するプログラミング作業全般を指す
*4:逆にエディタそのものの価値が今後下がっていく気すらしている
*5:最近はプライベートでもyoutubeの長いインタビュー動画やニュース動画はいきなり観ないでNotebookLMに要約させてから視聴するかどうか決めるようになった．収益化している側からしたらいい迷惑だろうけど50分ものインタビュー動画を観続けて欲しい情報を探すのは人間にはしんどい．
*6:一方で，過去に人間でもそういうことをしているケースを見たことが何度もあるのであまりAIだけを怒るに怒れない気持ちにもなる
*7:なおSonnetしか使っていないのでOpusを使った場合はまた結果が異なる可能性はある
*8:もちろん外部知識を参照する機能があるのは把握しているが，それでも人間の知見要約能力や参照能力の方がまだ高いのではないかということを主張している
*9:とかなんとか言いつつプログラミング自体も大好きなので全く手を動かさなくなることは絶対にないと信じているが
「社内での評価」にこだわるか「自分の満足」を優先させるか問題
現職に入社してから1年と6ヶ月が経った．自分が同じ会社に1.5年勤務しているというのは割と長い方である．ただ，この間何も変化がなかった訳ではなく2回のチーム異動があったりもした．しかし今後も特になにもない限りは現職で勤務を続けるつもりである．
それとは別に，ここ数年ずっと悩み続けている問題がある．それは普段の自分の労働において「社内での評価」と「自分の満足」のどちらを優先するかという問題である．
平たく言えば，昇進するために我慢してでもやりたくないことをやるか，自分が価値があると信じる行動を優先するかという問題である．なぜこのような問題について悩み始めたかというと，社内での評価を気にせず仕事をしていると給料が上がらなくなってきたと感じ始めたからである．自分としては大きな成果を出せたと思った期でも評価がパッとしないことが増えた．先に断っておくと，これは現職の評価制度が問題という訳ではなく前職からである．少なくとも20代の頃は何もしなくても給料が年々伸び続けたのでこのようなことを考えたことがなかった．より正確には「社内での評価」なんてものを考慮する余裕すらないぐらい目の前の業務をこなすのに必死だったり夢中だったりしたからだと思う．それでも結果的にどんどん自分ができることは増えたし給料も増え続けたので悩むことはなかった． しかし30代半ばになってきた辺りから状況が変化してきた．評価面談の度に「自分の手応え」と「社内での評価」にgapを感じるようになってきた．自分としては「このObjectiveのこのKR達成のためにこのような貢献をした」だったり「こういう取り組みをして社の開発生産性向上に貢献した」という具体的なactionを示すことができてはいたものの，そのactionに対する自己評価が「社内での評価」とは悪い方にズレるケースが増え始めた．はっきり言えば「給料が思ったように上がらない」状態である．
この事象の原因について，ずっと原因を自己分析をしてきたり歴代のマネージャと議論してきたが，今のところ明確な原因と対策は分かっていない．逆に明確な原因が分かるとしたらそれは現職の人事評価制度がリバースエンジニアリングされているということになるのでそれはまずいのだが，自分が次の期の評価のタイミングで「社内での評価」を上げるためにどうしたらいいのかが分からないでいる．
そもそも自分は「社内での評価」をこれ以上上げたいのだろうか？先に現職での立ち位置を雑に説明しておくと，Management roleではなくIndivisual Contributor roleのSoftware Engineerとして社に所属しており，今のところManagement roleにシフトするつもりは特に無い．社員ladderはそれなりに高い方に来ているがまだ上のladderがある段階である．そのような立ち位置の人間に会社から求められている事と，自分のSoftware Engineerとして進みたい方向にズレが来ているという可能性がある．可能性がある，というよりはほぼ確信している．だから，マネージャから求められていると思われるactionを増やして社内での評価を意識的に上げるか，今の評価を維持し続けられるならヨシとして現状維持をするかを悩んでいる．前者なら，一例として，普段の自分の業務においてProject / Product managementに近い仕事の割合が増加し，技術的な課題と向き合う時間が減少することが考えられる．あるいは労働時間を増やして後者の時間を確保し続ける生活に変化させる．それを受け入れられるかどうかについて悩んでいる．
自分を曲げてまで社内の評価を取るか，と表現すると大げさかも知れないが，これまで自分の人生において，仕事というのは相当に大きいウェイトを占めてきた存在であり，仕事の成果とはほぼ自分そのものであってほぼ自分の生活である．これまでの自分の努力や自己投資してきた金銭や時間を裏切るようで，簡単には変えられない．正直に言うとそのように感じている．要は感情の問題なのだと思う．感情の問題の方が大きく，いつものように損得勘定だけで自分を律することが難しい．そもそも自分は，その程度の損得勘定を受け入れることができない程度の低い人間であって，民間企業で働く1会社員としては，今いるポジションがどうやっても限界なのかも知れない．
Poetryでprojectを作ったらとりあえず入れておくdev packages
2024年10月更新
ruff を使いましょう．以下の内容は全部忘れてください．
Deprecated
いつも忘れるのでメモ
poetry add --group dev flake8 isort black flake8-bugbear flake8-docstrings mypy
setup.cfg はこんな感じに
[flake8] max-line-length = 88 convention = google [mypy] ignore_missing_imports = true show_error_codes = true [isort] include_trailing_comma = true line_length = 88 multi_line_output = 3
Poetryでproject rootに.venv directoryを作って欲しい場合の設定
Poetry projectをVSCodeで開く場合，project rootに .venv が生成されないので依存ライブラリのコードへの参照をVSCode上で解決できないケースがある．使用しているvirtualenvのpathを手動で指定する必要があるが，毎回やるのは面倒くさい．かといって，機械学習だと3rd party libraryを大量に参照するので直接Code jumpできないとめんどくさいケースが多々ある．
そこで，以下の設定を入れておくことでpoetryはvirtualenvをprojectのroot directory直下の .venv というdirectoryに生成するようになり，この問題を解決できる．
poetry config virtualenvs.in-project true
なお，すでにvirtualenvを作っている場合は適用されないのでその場合はvirtualenvを作り直す必要がある（当たり前だけど）．
参照: Configuration | Documentation | Poetry - Python dependency management and packaging made easy
WSLでLinux環境を構築してから任意のドライブに引っ越すまでの手順
何番煎じだって話だが備忘録として残しておく．
はじめに
WSLでLinux環境を作ると，デフォルトではWindowsがインストールされているドライブ上にLinuxのファイル本体が配置されてしまう．別 のドライブにLinuxのファイルを配置したい場合は，一度Windowsがインストールされているドライブ上にLinuxをインストールした後に，ファイル一式をexportして任意の場所にimportする必要がある．めんどくさいね．
前提条件
Windows 11で動作確認をした．
Windows 10でもWSL自体は動作するのだが，Windows 10の場合WSLのバージョンが古くなってしまうらしく，これが原因で，WSLで構築したUbuntu環境上で nvidia-smi でGPUが確認できない問題が発生した．NVIDIAのサイト によれば，CUDA on WSLにはWSL2が必要で，WSL2はWindows 11以降でのサポートになるとのことだったのでWindows 11にアップデートしてから本記事に書いた手順を実行した．
> wsl --version WSL バージョン: 1.1.3.0 カーネル バージョン: 5.15.90.1 WSLg バージョン: 1.0.49 MSRDC バージョン: 1.2.3770 Direct3D バージョン: 1.608.2-61064218 DXCore バージョン: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windowsバージョン: 10.0.22621.1413
手順
1. 管理者としてTerminalを開く
2. インストールできるディストリビューションの一覧を確認する
> wsl --list --online インストールできる有効なディストリビューションの一覧を次に示します。 'wsl.exe --install <Distro>' を使用してインストールします。 NAME FRIENDLY NAME Ubuntu Ubuntu Debian Debian GNU/Linux kali-linux Kali Linux Rolling Ubuntu-18.04 Ubuntu 18.04 LTS Ubuntu-20.04 Ubuntu 20.04 LTS Ubuntu-22.04 Ubuntu 22.04 LTS OracleLinux_8_5 Oracle Linux 8.5 OracleLinux_7_9 Oracle Linux 7.9 SUSE-Linux-Enterprise-Server-15-SP4 SUSE Linux Enterprise Server 15 SP4 openSUSE-Leap-15.4 openSUSE Leap 15.4 openSUSE-Tumbleweed openSUSE Tumbleweed
3. 任意のDistributionをInstall
ここでは Ubuntu-22.04 をinstallする．
> wsl --install -d Ubuntu-22.04
4. installできたことを確認
> wsl -l -v NAME STATE VERSION * Ubuntu-22.04 Stopped 2
> wsl uname -r 5.15.90.1-microsoft-standard-WSL2
5. 任意のDriveにexportする
> wsl --export Ubuntu-22.04 {file_name}.tar
6. 一度installしたUbuntu-22.04をuninstallする
> wsl --unregister Ubuntu-22.04
7. 任意のPathにimportする
> wsl --import {distro_name} {import_path} {file_name}.tar
8. (Optional) ログインユーザを変更する
何故かimportするとログインユーザが root に変更される．これが嫌な場合はログインユーザを変更する．
Ubuntu-22.04上で以下のように /etc/wsl.con ファイルを作成して何度かログインし直すと変更される． wsl --shutdown してもすぐには反映されず，一定時間待つ必要があるようだった．謎．
cat << EOF > /etc/wsl.conf [user] default=user-name EOF
推薦システムを勉強し始めた
はじめに
３ヶ月ぶりの労働を再開して一ヶ月が経った．最初こそ披露困憊で業務後は何もできなくなっていたものの，徐々に勘を取り戻してきたので余裕が出てきた．
同時に，今後のICとしての昇級についても同時に考えを巡らせる必要が出てきたりしたので*1，よい機会だと思い新しい技術軸として推薦システムについて勉強することにした．
なぜ推薦システムかと言えば以下の理由である．
- 現職で作っているものがフリーマーケットサイトなので推薦システムを内製しているチームがあり，そのチームと今後協業する必要が出てくる可能性がある
- 推薦システムは以前勉強した機械学習と関連している部分があり，ある程度使える共通基礎知識がある
- 絶対的な解がない分野なので研究対象としてもまだ伸びしろがある
- 推薦システムは何かしかのコンテンツをユーザに提供しているサービスでは常に重要であり，今後10年スパンぐらいで見ても需要は減らないだろうと思った
今やってること
あまり進捗は出ていない．とりあえず以下の本を頭から読んでいる．
古典的な近傍ベースの推薦システムだけでなくモデルベースの推薦システムについても解説されており，網羅的に勉強するには良さそうだと思って選んだ．また，読むために必要な知識*2についても都度細かく説明してくれているので初心者には読みやすい構成になっている．
今後の予定
まだ3章までしか読んでないので残りを早めに全部読んで全体像を掴むことを最初のマイルストーンとしている．その後は手を動かして実装してみたり，kaggleの推薦システムコンペをやってみようかと思っている．
あと以下の本は実装についても触れているようなので併せて読んでみる予定である．
月に１回ぐらいのペースで学んだことをこのブログで報告していきたいと思う．
