note に入社して4年たっていた。

おはようございます。watura です。2026年4月5年目に入りました。前職よりはもう長くいて、前々職においつく勢いです。 入社から5作目です。 この一年はTALES iOSアプリをずっとやっていました。4年なので、半分近くがTALESだと？！とすこしびっくりしています。 いかにiOS アプリ開発でも生成AIによる開発効率化を行えるかを試行錯誤する1年でもあった気がします。 日進月歩すぎて、なにやってきたかさっぱり覚えていないので、最近使っているSkillとかをちょろっと書いておいてみます。たぶん、半年とかしないうちに陳腐化するんでしょうけどね！ なお日々、スキルやAGENTS.mdはベストプラクティスみて修正して！とかこのドキュメント読んで修正して！といった指示を与えて見直しを行なわせ続けています。 開発環境 Claude Code Xcode Xcode MCP + オレオレMCP Proxy たまにCursorとかZedとかHelixとか TALES MOBILEリポジトリはアプリ系モノレポにしていて、iOS/Android/共有ライブラリが一つのリポジトリに入っています。iOSの開発のときに、Androidの情報が不要だったり、共有ライブラリもそこまで必要がないので、Skillでそれぞれの情報を読込むようにしてあります。 最近つくったスキルで、 /open-xcode がめっちゃ便利です。やることは、ごにょごにょした上でxcodeで現在編集中のプロジェクトを開くというものです。Claude Code→Xcodeへの遷移がスムーズになるため、複数のWorktreeでそれぞれ別の開発を行なっているときなどに，正しいXcodeを開くという動作がめっちゃ楽になりました。 また、不完全ではあるものの、WorktreeのルートにあるXcodeのuserdataをあたらしいworktreeのXcodeにねじ込むことで，最初から動かしたいスキーム・ターゲットをセットした状態でひらけるようにするという機能も追加しました。少なくとも執筆時点では、xcode mcpはスキーム・ターゲットの変更には対応していません。なので、手動で調整してあげる必要がありました。無理やりXcodeのステートを書き換えるようにしたので、ターゲット類を私の希望するデフォルト状態にできるようになりました。 その結果、 実装したいIssueを与える FigmaがあればMCPで見に行く 他Issueがリンクしてあったら見に行く いろいろ情報収集し実装をはじめる 実装ができたら、/open-xcode スキルが発動する /xcode-build スキルも発動する コンパイルできるようになるまでがんばってくれる /xcode-test でtestも多少はためす 実装に私が満足できていたら手動で /appium スキルでその機能のスクショをとりにいかせる 機能へのアクセスをe2eテストに落とす iOSアプリ開発において、Claude Codeとかにいい感じにビルドをさせるというのは結構面倒くさい処理です。あと、このIssueを与えたりしたときに /worktree が実行されて初期化とかブランチ名いい感じとかうごくようにしたいなぁと試行錯誤しているところです。 ⏺ /open-xcode  xcworkspace（優先）か xcproj を開く。  探索順序  - iOS/App/App.xcworkspace  - iOS/App/App.xcproj  - note.xcproj  - 上記になければfdでglob検索  動作  1. talesリポジトリの場合、スキーム切替スクリプトを実行（Xcode未起動時のみ）  2. openコマンドでプロジェクトをフォアグラウンドに  3. 引数があればxedでファイルを開く  引数  - なし → プロジェクトを開くのみ（編集中ファイルがあればそれを開く）  - ファイルパス → そのファイルを開く  - ファイルパス:行番号 → 指定行で開く  例  - /open-xcode  - /open-xcode Feature/SampleFeature.swift  - /open-xcode Feature/SampleFeature.swift:95 まあ、これらの処理はスクリプトにしてサクッと実行させる方が確実に実行されていい気がしてます！ 最近よく使っているスキル一覧 ビルド・テスト /open-xcode Xcodeプロジェクトを開く（ファイル・行番号指定も可） /xcode-build Xcode MCPでiOSビルド /xcode-test Xcode MCPでiOSテスト コンテキスト読み込み /ios-context iOS開発ルール・ドキュメント読み込み /android-context Android開発ルール・ドキュメント読み込み /sharedlib-context SharedLibビルドルール読み込み /graphql-context GraphQLスキーマルール読み込み コードレビュー /code-review PR品質・パフォーマンス・セキュリティレビュー /review-comments PRレビューコメントへの対応 ワークフロー /commit Conventional Commitsに沿ったコミット /publish コミット＋PR作成 /worktree git worktree作成・作業開始 /tales-issue-task-run \[#issue\] Issueからタスク分解→実装→PR作成 その他 /release-note \[ver\] \[platform\] マイルストーンからリリースノート生成 /appium E2Eテスト用ドキュメント参照 MCP Server Xcode MCP（オレオレMCP Proxy経由) ビルド・テスト・プレビュー Appium MCP E2Eテスト・アクセシビリティチェック エンジニアとしAIすすみ過ぎてどうすんの？アプリ開発者とかもうオワコンなんじゃないの？みたいなことを書いていたりもしたのですが、マジでただコードを書くだけの人って不要だよなとなりました。 少なくとも今現在においては、作られていくコードを効果的に誘導していくみたいなところに職人芸が出てくるんじゃないかなぁという気がしています。 というわけで、開発を少しでも楽にするぞというところをすすめていくために、AIをたくさん使いいろいろやってきています。また、この記事を書いていたら、もう少しああしたらよくなるなとかいろいろ思いつくので、どんどん進めたいですね。