claude-code-action をコードレビューなど複数のジョブで使っていて、ジョブ定義にツールの使用許可などを個別に書くのが面倒だったので .claude/settings.jsonを参照させるように設定していた。

- uses: anthropics/claude-code-action@v1
  with:
    settings: .claude/settings.json

そして、この記事を参考に、PRにインラインコメントを付けさせたくて settings.json にこう書いた。

// .claude/settings.json
{
  "permissions": {
    "allow": ["mcp__github_inline_comment__create_inline_comment"]
  }
}

そして適当なPR上のコメントでClaudeに「インラインコメント使える？」と聞いたら「そんなツール知らない」と言われた。

update_claude_comment は使えるのに、なぜ？

結論

settings.json に書いても MCP サーバーが起動しない。 claude_args に書く必要がある。

# これなら動く
claude_args: "--allowed-tools mcp__github_inline_comment__create_inline_comment"

なぜこうなるのか

settings と claude_args は別ルートで処理される

yaml inputs
    │
    ├─► settings ─► base-action で ~/.claude/settings.json に書き込み
    │                （Claude Code 起動後に読み込まれる）
    │                → ツール許可には使われる
    │                → MCPサーバー起動判定には使われない ❌
    │
    └─► claude_args ─► tag/agent mode で parseAllowedTools()
                       ─► prepareMcpConfig() に渡される
                       ─► MCPサーバー起動判定に使用 ✅

settings.json は Claude Code が起動した後に読み込まれるが、MCPサーバーを起動するかどうかの判定はその前に終わっている。

該当コード

src/modes/tag/index.ts:142-145:

const userClaudeArgs = process.env.CLAUDE_ARGS || "";
const userAllowedMCPTools = parseAllowedTools(userClaudeArgs).filter(
  (tool) => tool.startsWith("mcp__github_"),
);

CLAUDE_ARGS（= yaml の claude_args）からしか取得していない。settings は参照されていない。

この userAllowedMCPTools が prepareMcpConfig() に渡され、MCPサーバー起動の判定に使われる。

src/mcp/install-mcp-server.ts:138-141:

if (
  isEntityContext(context) &&
  context.isPR &&
  (hasGitHubMcpTools || hasInlineCommentTools)  // ← ここで判定
) {
  baseMcpConfig.mcpServers.github_inline_comment = { ... };
}

allowedTools に mcp__github_inline_comment__* がないと、サーバー自体が起動しない。

なぜ update_claude_comment は動くのか

github_comment サーバーは特別扱いされており、tag mode なら常に起動する。

const shouldIncludeCommentServer = !isAgentMode || hasGitHubCommentTools;

そのため settings.json に書かなくても使える。

現状の対処法

settings.json と claude_args の両方に書く。冗長だが仕方ない。

- uses: anthropics/claude-code-action@v1
  with:
    settings: .claude/settings.json
    claude_args: "--allowed-tools mcp__github_inline_comment__create_inline_comment"

これはバグ？

個人的にはバグというより、設計の問題だと思う。

ユーザーから見ると「ツールを許可する設定」は一箇所にまとめたいが、実際は2つのルートがあり、片方だけ書いても動かない。

直すなら、ALL_INPUTS 環境変数から settings を読み、permissions.allow の中身も MCPサーバー起動判定に使うようにすればよいのかなあ。

iOSアプリ開発者としての停滞感から脱却する

2014年にiOSアプリ開発者に転向してから10年が経った。腕にはそれなりに自信を持てるようになってきた一方で、ここ1年はただその記憶を切り売りして、やったことあるものを再放送してるだけだと感じることが増えた。会社の仕事ではレガシーに立ち向かうことが多くなって、トレンドに対するキャッチアップは別途時間を取らないと追いつかなくなったのもあるのかもしれない。キャリアの軸(というかそれしかない一本足)であるiOSアプリ開発者としての賞味期限を早めているかもしれないということへの危機感が今の色んな感情の根底にある気がする。

...

ちゃんと使えるiOSアプリ開発者としての賞味期限を伸ばせるよう鍛錬する。

結果: ⭕️❓

LLM、AIエージェントの台頭によって、自分が手を動かしてコードを書く量は激減した。単純に量をこなすことで育つ筋肉みたいなものは伸ばせていないと思うが、新時代のプログラミング手法によって、これまでに触れたことのなかった技術やフレームワークを使った個人開発アプリを作る機会を得られた。思い出せる限り上げると、WeatherKit、MusicKit、Mutipeer Connectivity、CloudKitあたりか。

あとはJSONDecoderのリグレッションを見つけてswift-foundationにPRを送ったのも、Claude Codeのサポートがあったからこそ取り組む気になったのだろう。マージされるといいな。

ソフトウェア開発者としての幅を広げる

これまでは割と意識的にiOSだけをやるようにして、他のプラットフォームには手を広げないようにしてきた。いろんな科目で60点取れるより、120点取れる科目が1つある方が価値が高いだろうと思っていたから。今もその思想は変わっていないが、ここから自分がiOSアプリ開発の技術を更に30点伸ばすよりも、持ってる知識を横展開して隣の領域で効率よく70点を目指すほうがコスパがいいのではと感じ始めた。

結果: ⭐️

年頭に記事を書いた時点では、例えばAndroidアプリとか、Webフロントエンドとか、そういう隣の畑のエンジニアリングを真面目に勉強してみるかなあ、みたいな想定で書いていたが、そんなこととは大きく違うことが起こった。

その記事を書いた直後にClineに初めて触れ、自分はコードを1つも書かないままそれらしく動くものができたその衝撃は今でも忘れられない。あれがたった1年前のことだとは今でも信じられない。その後Claude Codeをメインに使うようになり、「単に自分が手を動かす実装作業の置き換え」だけではなく、新しいパラダイムに適応するための模索を重ねてきた。そういう過程で大規模なイベント登壇のチャンスをいただいたり、今まで接点のなかった業界やコミュニティにふれることができた。

わいわいClaude Codeにリネームした #iosdc pic.twitter.com/mwHhhUFhzW

— hiragram/ひらり (@hiragram) September 21, 2025

iOSDCでもClaude Codeの話ができたし、恐れ多くも「結構やっているヤツ」という認知をいただくことが増えてきたので、ハリボテにならないように功夫を積まなければならない。

コードを書く以外の収入源を持つ

これにはとりあえず2つの意味があって、

• 10年やってきたiOSアプリ開発の知見を、コードを書く工数としてではない形で提供する
• 仕事でやってるような技術以外に趣味でやってることを収益化する

という感じ。

結果: 😑

現状維持。個人開発で作りかけの有象無象を完成させて何かしら収益源にできたらいいな〜みたいなことを考えていたが、やはりそう甘くはない。

子供の写真を5,000枚撮る

2024年の途中で子供が生まれて、年末までに3,312枚の写真を撮っていた(Googleフォトのアルバムでカウント)。今年には多分喋りだしたり歩きだしたりするだろうから、年末までに5,000枚撮りたい。写真も動画も撮るぞ。

結果: ✅

これを書いている2025年12月31日21時の時点で、Googleフォトの息子アルバムには10,524枚の写真がある。7,212枚撮れた。大達成であるが、4月に保育園に入ってからは以前比で激減していたため、この先も写真や動画を残すことを意識的にやっていかないと、なあなあでやらなくなってしまいそう。

たまに1年前とかの写真を振り返ると本当に幸せな気持ちになる。イベントごとの写真よりも、なんでもない寝顔とか、こんな服着てたなとか、そういうことをこれからも残していきたい。

その他スタッツ

• ブログ: 10記事
• Zenn: 5記事
• イベント・勉強会登壇: 6回

年頭に書いた記事はこちら。

2025年にhiragramと接してくださった皆さん、お世話になりました。来年も何か頑張っていきたいので今後もよろしくお願いいたします。

自己紹介

• @hiragram
• iOSアプリエンジニア(2015~)

やってること

• Claudeをエンジニアリングチームのように育てることで、どこまで任せられるのか実験中
• 自分は「エンジニアリングのことはそんなにわからないプロダクトオーナー」として振る舞い、Claudeで作ったエンジニアチームと対話しながら開発を進める
• 題材は、夫婦で保育園の送迎担当の予定を調整するためのiOSアプリ

人間は仕様決めと動作確認とレビューしかしないという縛りで週末に作り始めた保育園送迎分担アプリ。Claudeのプラグイン作り込むほどいい感じになっていく pic.twitter.com/YC5K8L8wGI

— hiragram/ひらり (@hiragram) December 14, 2025

ios-team プラグイン

MCPサーバー

Xcodeプロジェクトとシミュレータを直接操作するための2つのMCPサーバーを提供しています。

pbxproj-mcp (自作)

https://github.com/hiragram/pbxproj-mcp

Xcodeプロジェクト（.xcodeproj）の構造とビルド設定を操作するサーバーです。

• ターゲットの追加・削除
• Swift Packageの依存関係管理
• ビルド設定の取得・更新
• スキームの作成・編集
• ビルドフェーズの管理

iossim-mcp (自作)

https://github.com/hiragram/iossim-mcp

iOSシミュレータを制御し、アプリの動作確認を自動化するサーバーです。

• シミュレータの起動・シャットダウン
• アプリのインストール・起動・終了
• スクリーンショットの取得
• UI操作（タップ、スワイプ、テキスト入力、長押しなど）
• UI要素のプロパティ取得

スキル

開発の各フェーズで活用できる6つの専門スキルを用意しています。

design-system

カラーパレット、タイポグラフィ、スペーシングなどをSwiftコードとして生成します。複数テーマの切り替えに対応し、アプリ全体で一貫したデザインを維持できます。

アプリの概要や世界観をざっくり説明すると、「スタンダード」「保守的」「大胆」と、それぞれのより色味を前に出したバージョンの合わせて6パターンを作って見せてくれるClaude Skillを作った。 pic.twitter.com/YubOExEgwq

— hiragram/ひらり (@hiragram) December 7, 2025

ui-mock-builder

SwiftUIのView実装を支援するスキルです。`#Preview`マクロを活用し、複数の状態バリエーションをプレビュー可能な形で生成します。既存の共通コンポーネントを活用しながら効率的にUIを構築できます。

スキル/カスタムコマンド/サブエージェントをいろいろ充実させた結果「夫婦で保育園の送迎担当を調整するための、送りと迎えの可否について１週間分入力して送信する画面を作ってください」という指示だけでこれが出せるようになった pic.twitter.com/DUxIm9zObx

— hiragram/ひらり (@hiragram) December 2, 2025

screen-architecture

Reduxパターンに基づくiOS画面の状態管理設計を支援します。Single Root State、Reducer、Storeの3層構造により、堅牢でテスト可能な実装を実現します。

build-settings-validator

Xcodeプロジェクトのビルド設定を推奨設定と比較し、問題を検出・修正します。Swift 6対応、警告設定、セキュリティ設定などを検証できます。

project-architecture

プロジェクト全体のアーキテクチャ設計を支援します。モジュール分割、ターゲット追加、依存関係の整理など、スケーラブルな構成を実現します。

Claudeに自由にガチャガチャやらせてたら署名周りでビルド通らなくなっちゃって自分でもよくわかんなくて困ってたんだけど、新しく作って構成ちょっと寄せた空のXcodeプロジェクトを持っててそれと色々見比べて原因探すskillを作ったら即解決してくれた pic.twitter.com/kAYARYzQqS

— hiragram/ひらり (@hiragram) December 20, 2025

localization

String Catalog（.xcstrings）を使った型安全なローカライズ実装を支援します。Xcode 26のシンボル生成機能をフル活用し、ハードコードされた文字列を排除します。

コマンド

よく使うワークフローを簡単に実行できる3つのコマンドを提供しています。

/prototype

SwiftUIプレビュー付きのプロトタイプを素早く生成します。既存コードに依存しない単体動作するコードを出力し、アイデアの検証を高速化します。

/implement

プロジェクトのアーキテクチャに従った本番品質の実装を行います。screen-architectureスキルで定義されたルールに基づき、一貫性のあるコードを生成します。

/propose

実装からPR作成までを一括で実行します。ビルド確認、テスト実行、コミット、プッシュ、プルリクエスト作成、CI監視までを自動化します。

エージェント

専門的なタスクを担当する2つのエージェントを搭載しています。

ios-feature-developer

iOS機能開発の専門エージェントです（Opus 4.5）。Swift/SwiftUIの最新機能、Combine、Core Data、Clean Architectureなど幅広い技術に対応します。新機能実装、既存機能修正、バグ修正などを担当します。

ios-screenshot-analyzer

シミュレータのスクリーンショットを視覚分析するエージェントです（Sonnet）。UI要素の値、色、レイアウト、コンポーネント状態などを検証し、実装が仕様通りかを確認します。

ワークフロー例

プロトタイプから本番化まで

1. /prototype ログイン画面 でSwiftUIプレビュー付きプロトタイプを生成
2. シミュレータで確認し、ios-screenshot-analyzerで視覚検証
3. /implement ログイン画面 でReduxパターンに基づく本番実装
4. /propose でコミット・プッシュ・PR作成を自動化

新規プロジェクト立ち上げ

1. build-settings-validatorでビルド設定を検証・最適化
2. design-systemでデザインシステムを構築
3. project-architectureでモジュール構成を設計
4. localizationでローカライズ基盤を整備

特徴

• 統合的設計 - MCPサーバー、スキル、コマンド、エージェントがシームレスに連携
• 本番対応 - プロトタイプから本番化まで一貫したワークフロー
• アーキテクチャ志向 - Reduxパターンによる堅牢な状態管理
• 開発効率化 - ビルド、コミット、PR作成まで自動化
• 品質担保 - ビルド設定、デザイン、ローカライズの検証機能

このプラグインを使うことで、iOSチーム全体で一貫性のある高品質なアプリ開発が可能になります。

初めて現地で観戦したのが2024年のもてぎだったから、現地観戦歴がちょうど1年になったことになる。

今回は指定席を取らず、S字カーブあたりの自由観戦エリアを陣取った。また今回は家で燻っていた一眼レフを引っ張り出し、車の写真を撮るのにも挑戦した。

写真

スタートグリッド順に貼っていく。

#38 KeePer CERUMO GR Supra

#1 au TOM'S GR Supra

#23 MOTUL AUTECH Z

#12 TRS IMPUL with SDG Z

#3 Niterra MOTUL Z

#24 REALIZE CORPORATION ADVAN Z

#100 STANLEY CIVIC TYPE R-GT

#8 ARTA MUGEN SIVIC TYPE R-GT #8

#16 ARTA MUGEN CIVIC TYPE R-GT #16

#64 Modulo CIVIC TYPE R-GT

#19 WedsSport ADVAN GR Supra

#39 DENSO KOBELCO SARD GR Supra

#14 ENEOS X PRIME GR Supra

#37 Deloitte TOM'S GR Supra

#17 Astemo CIVIC TYPE R-GT

$ claude して、何も発言していない状態で叩いた結果がこれ。

なにかを言う前にすでに半分以上コンテキストを消費していることがわかる。

このプロジェクトではMCPツールを .mcp.json に書いてコミットしている。いわゆるプロジェクトスコープというやつ。

{
  "mcpServers": {
    "ios-simulator": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "ios-simulator-mcp"
      ],
      "env": {}
    },
    "XcodeBuildMCP": {
      "command": "npx",
      "args": [
        "-y",
        "xcodebuildmcp@latest"
      ]
    },
    "github-as-app": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "github-as-app@latest"
      ],
      "env": {}
    },
    "supabase": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "@supabase/mcp-server-supabase@latest",
        "--project-ref=xxxxxxxxxxxxxxxxxxxx"
      ],
      "env": {}
    },
    "xcodeproj": {
      "type": "stdio",
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "-v",
        "/Users/hiragram/Development/voicecall:/workspace",
        "ghcr.io/giginet/xcodeproj-mcp-server",
        "/workspace"
      ],
      "env": {}
    }
  }
}

github-as-app 以外はだいたい代替手段があって一旦なくしても良いかなって感じがするので消してみる。

{
  "mcpServers": {
    "github-as-app": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "github-as-app@latest"
      ],
      "env": {}
    }
  }
}

改めて新しいセッションで /context を叩くと

だいぶスッキリした。これでコンテキストの空きが増えて、体感する性能の変化があるかどうかは色々触ってみて確認する。

MCP流行りの初期に色々入れたものが残ったままになってる人は多い気がするので一度棚卸ししてみるとよさそう。

最近の道具

LLMエージェント: Claude Code

最近Claude Maxの$200/moのプランにアップグレードした。iOSアプリの新規開発というユースケースで自分が使っている範囲では、Opus 4とSonnet 4の差はあんまり感じていない。が、ケチケチしてもしょうがないかなと思ってOpus固定で使っている。

Claude Codeの話をXでポツポツ書いていたらmizchiさんに誘ってもらってClaude Code Deep Diveというイベントに登壇した。

CI: Claude Code Actions + GitHub Actions + M4 Pro Mac mini

Claude Code ActionsがClaude Maxに含まれるようになり、利用を始めた。Claude Codeは定額で使えるようになったが、GitHub Actionsは実行時間に応じたコストがかかるので、「とりあえず書かせて、ダメだったら全部捨ててやり直す」みたいな人間側のメンタルモデルと相性が悪い。せっかくハードルが下がったのにそこでブレーキがかかるのは勿体ないと感じて、Self-hosted runnerとして動かすためのM4 Pro Mac miniを買った。やってるのはiOSアプリの開発なので。

今のところSelf-hosted runner上でやってるのは

• Claude Code Actionsによるコードレビュー
• Claude Code Actionsによるタスクの実行
• PRごとのiOSアプリ/APIサーバーのテスト実行

ユニットテストの実行はこれまでXcode Cloudを使っていたが、Self-hosted runnerに移行して、Xcode Cloudは配信用ビルドを作るだけにして有料プランを解約した。Xcode CloudはIntelプロセッサの環境なので、同じコードに対するスナップショットテストで生成される画像がAppleSilicon環境と微妙に差が出てしまってVRT構築に対してネガティブな要素だったのが、M4 Pro Mac miniで動くようになったので厳密な画像比較ができるようになったのも嬉しい。

M4 Pro Mac miniには大変満足している。CPUを14コアに、メモリを64GBに、ストレージを1TBに増やした。Self-hosted runnerのプロセスを4つ動かしていて、iOSシミュレータが絡むテストジョブが複数並行で走っても自分の作業に何も影響がないくらいにはパワフルである。ラップトップにしようとも思ったが、4年前に買ったM1 ProのMacBook Proが存命なのでコスパが良さそうなminiにした。正解だったと思う。

タスク管理: Linear

最近使い始めた。LLMエージェントの重要性が上がっていって、彼らにとってアクセスしやすいところにタスクやドキュメントがあることの価値が日に日に高まっている中、GitHub issueでプロジェクト管理っぽいことをする難しさと、でも別の場所に置きたくないという気持ちとで葛藤しているときに出会った。

LinearとGitHubリポジトリを連携すると双方向に同期できるようになる。GitHubにissueを立てるとLinear側にチケットとして起票されるし、Linear側でチケットを作るとリポジトリにissueが作られる。コメントも同期されているので、Linear側から @claude このissueやって みたいにClaude Code Actionを起動することもできる。

あとモバイルアプリがGitHubよりLinearのほうが洗練されていて使いやすい。最近は眠る前に布団の中でモバイルから思いつく限りのissueを立ててClaude Code Actionに着手させてから寝るという流れになってる。

VibeTunnel + Tailscale

VibeTunnelはローカルのMacのCLIをWebブラウザから見られるようにしてくれるツール。これにTailscaleで構築した仮想ネットワークと組み合わせると、家の外からでもブラウザさえ使えれば家のMacで動いてるClaude Codeにアクセスできるようになる。複数のプロセスを一覧管理したり切り替えたりするUIも日々洗練されていってて、tmuxが手に馴染んでいない自分にとってはこっちのほうが管理しやすかった。

Issue/PR管理: Jasper

Linearからポンポンissueを作って、Claude Code ActionsがガンガンPRを投げてくる、という状態になったので、Chromeのタブが破滅していく。久しぶりにJasperを導入して、フィルターをこねこねして、botが投げまくってくるPRを打ち返したりタスクissueに対して着手指示をだしたりしている。

おわりに

これはあくまで個人開発のフォーメーションであり、所属先の業務で取っている体制ではないことは留意されたい。

今は音声を使ったコミュニケーションアプリをiOS向けに開発している。

どうもVibe Codingという言葉を自分の作業に向けて使うのはピンと来ない。ノリで適当にやっているわけではない、むしろ自分で全部やる状況よりも緻密にフローを構築して丁寧にやっている自負がある。早くこの言葉廃れないかな。

半年後とかにまたその時の状況を書きます。

きっかけと背景

社内のエンジニアMTGで、筆者が個人開発でAIエージェント（対話型AI）を使ってコーディングしている体験を紹介したところ、何名かが興味を持ってくれた。「実際に触ってみる場をつくろう」とハンズオンを企画することになった。

Slackで声をかけたところ、エンジニア以外の職種も含め7名が参加してくれた。

題材アプリ「オキッパ」について

今回のハンズオンでは、「空いている物置きをシェアできるサービス」を想定したWebアプリ「オキッパ」を題材に使用した。

オキッパは、近隣住民同士が使っていない物置スペースを貸し借りできるCtoCのシェアリングサービス。ユーザーはスペースを探して予約・利用でき、貸し手は物置の空き時間を有効活用できる。

このサービスを簡易的に再現するアプリをNext.jsとSQLiteで構築し、各参加者はこれをベースにAIと一緒に機能開発を行った。

ハンズオンの設計

• AIとのインターフェース: VSCode + Cline
• 利用モデル: Claude 3.7 Sonnet
• 初期コードと手順書: 
  • コード: https://github.com/hiragram/okippa
  • 手順書: https://github.com/hiragram/ai-coding-hands-on
  • brewとnodeが入ってるエンジニアのMacだったら手順書通りに進めればすぐ取りかかれるはず。

エンジニアではない参加者もいたため、環境構築は画面共有で一緒に進めた。

ハンズオンの進め方

以下のようなお題を用意した：

• トップページのデザインを変えてみる
• 未完成機能の続きを実装させる
• オーナーへの問い合わせ機能
• 予約機能
• 独自の新機能アイデアを実装してみる

基本的には自由課題に近い形式で、AIに指示を出しながらそれぞれが取り組んだ。

成果と作品例（一部紹介）

参加者がAIと協力して開発した成果の一部を紹介する：

• チャットボット風問い合わせ機能
• 予約可能日をカレンダー表示
• ブランドカラー反映 + UI改善
• フィルタ付きトップページ
• キャンセル待ち機能
• 口コミ投稿 + トップページ表示

いずれもAIエージェントとの対話を通じて実装されたもので、短時間ながらしっかり動作するレベルのアウトプットが得られた。

苦労した点と反省

特に苦戦したのは環境構築だった。

エンジニアにとっては当たり前のHomebrewやNode.jsも、他職種にとっては高いハードル。AppleScriptでサーバー起動を自動化しようとしたものの、セキュリティ機構に阻まれてうまくいかなかった。

AIを活用したDB初期化も完璧とはいかず、AIが「完了した」と返してもアプリが動かないトラブルも発生。今後の課題としたい。

参加者の声（要約）

• テストの補完や小さな修正にはすぐ使えそう
• 複雑なUI改善もプロトタイピングとして試せる
• デザイナー視点でも使い道が見えた
• ただしレビューが必要な部分にはまだ不安も

おわりに

正直なところ、開催にはかなりの準備時間とコストがかかった。トークン代・休日稼働を含めて筆者の持ち出しもあったが、それでも得られる気づきや知見は大きかった。

このような社内でのナレッジ共有・実験的な取り組みがもっと広がっていくと良いなと思う。

📚 関連リポジトリ:

• コード: https://github.com/hiragram/okippa
• 手順書: https://github.com/hiragram/ai-coding-hands-on

最近、エンジニア以外の職種でもAIを活用する動きが社内で加速している。企画、マーケ、カスタマーサポートなど、これまであまり技術に関与してこなかったメンバーがAIツールを使って、情報の整理や文章作成、アイデア出しなどに取り組むようになってきた。

これはとても良い流れだと思う。一方で、AIとの向き合い方や、AIが生成した情報をどう扱うかについて、よく考察された共通認識がないまま進んでいることに危うさも感じている。

この記事では、実際の業務の中で感じた違和感や課題をもとに、「これからのAI時代に必要なコミュニケーションの基本姿勢」について考えてみたい。

自分で判断できないことをAIに委ねない

AIが出した情報に対して、自分で正否や適切さを判断できないまま、それを業務に使おうとするのはとても危険だ。その情報の正しさを評価できない状態でアウトプットしていることになるから。

たとえば、医療の専門知識がない人がAIを使って病状に関する説明文を書いたり、法律の知識がないままAIに契約文書を作らせたりするようなケースがある。AIの出力がもっともらしく見えても、自分で判断できない分野でそのまま使うのは非常にリスクが高い。

だからこそ、AIを使うときには次のような基本姿勢が求められる：

• 出力内容の意味を自分で理解し、評価する
• そのまま使うのではなく、自分の責任で修正・検証する
• 自分で判断できない領域では、自分がAIを扱うのではなく、最初から専門家に頼むことを検討する

専門家の力を借りるというのはもちろん正しい。でも、「わからない人がAIに書かせたものを専門家にレビューしてもらう」という形になると、その専門家にとっては手間が増えているだけの可能性がある。

それなら最初からAIを挟まず、その人に直接依頼するべきで、AIを使うかどうかは専門家自身が判断すればいい。依頼する側が気を利かせたつもりでAIを噛ませることが、かえってマイナスになることもある。

個人の生産性向上が他人の負荷になっていないか？

「AIで生産性を上げましょう」という言葉はよく聞くし、実際その通りだと思う場面もある。だが、アウトプットの検証や最終確認を他の誰かに丸投げしていないか？ という視点は常に持っていたい。

たとえば、エンジニア以外の職種の人が、技術的な文脈を含むお知らせや説明文をAIで作成するようなケース。内容はそれっぽく見えるかもしれないが、技術的に正しいかどうか、適切な用語や構成になっているかを判断するのは簡単ではない。

結果として、エンジニアに「技術的に問題ないか見てほしい」とチェックを依頼することになり、作成者の作業は効率化されたかもしれないが、エンジニアの作業量が増えているということになる。

つまり、「個人の生産性向上」の裏で、組織全体の工数はむしろ増えているという逆転現象が起きる可能性もあるということ。

AIが生成したものだろうが他者に提供する時点で自分の責任

最近では、会議の議題や議事録の作成にAIを活用する例も増えてきた。それ自体は便利なことだけど、そこで注意すべき点がある。

まず、議題や提案がAIによって生成された場合：

• その内容は「誰の意見」なのか？
• AIの提案に、どれだけ自分が賛同しているのか？
• 議論をどう進めたいと思っているのか？

こういったことを明示しないと、対話の出発点が曖昧になり、議論の軸が定まらない。

また、AIが作成した議事録や要約をそのまま提出する場面でも同様だ。「AIが書いたから自分は責任を負わない」という態度ではなく、“自分の提出物”として出す以上は、その内容に責任を持つべきだと思う。

もちろん、皆が皆、無責任にAIを使っているわけではない。ただ、AIの出力との向き合い方や、その扱いに対する意識の濃淡には大きな個人差があるのも事実だ。

無闇に疑ってかかりたいわけではないので、AIの出力を活用する側として、「この出力はどのような立場から提示されているか」「自分の意見が含まれているかどうか」をあらかじめ開示してくれると、とても助かる。

たとえば、

• 「AIに聞いたらこう言われて、私も同じ意見です」
• 「よくわからないのでAIに聞きました。自分の意見は特にありません」

このどちらかを明示してくれるだけで、議論の進めやすさは大きく変わってくる。

おわりに

AIの活用はこれからも加速していく。それは歓迎すべきことだと思う。ただし、AIを正しく活用するためには、それにふさわしいリテラシーと姿勢が必要になる。

• 自分で判断できる範囲で使う
• 他人に丸投げしない
• AIの出力を使うなら、自分の言葉として引き取る

こういった考え方が、組織の中に自然に浸透していくことを願っている。

共感してくれる人がいたら、ぜひ一緒に「AI時代の建設的なコミュニケーション」について、考えていけたらうれしい。

表題の「必要だった」とは、今もう必要でないということではなく、今の時点でそういうAI活用に取り組めている企業はきっとそうだったのだろう、我々はそうでなかったからそこにいないのだろう、ということ。

金銭コストだけが問題ではない

AIを導入する際、「お金がかかる」という点が話題になりがちだ。確かに金銭コストも重要な要素ではあるが、実はそれだけが障壁ではない。もっと根本的な問題がある。

やるべきことを真面目にやっているか

流行りの兆しを見つけて取り組む意欲があったとしても、足元の障壁がバラバラ残っていると、結局トレンドに振り払われてしまう。重要なのは、普段からエンジニアリングのあるべき形を実践しているかどうかだ。例えば:

• リポジトリにDBのパスワードのような秘匿情報をコミットしないを真面目にやっている
• ユニットテストが充実していて、AIが生成したコードの妥当性を自信を持って判断できる
• 要件定義やドキュメント化の能力が鍛えられており、AIへの適切な指示やフィードバックができる

こうした基本的なことができていないと、AIのような新しい技術をスムーズに導入できる機動性を維持するのは難しい。重要なのは「既存のエンジニアリングがAIを用いた開発に耐えうる構造になっているか」という点だ。

急に回ってきた代打で結果を出せるのは、出番がなかったとしても基礎練習を怠らなかった奴だろう。

気持ち

エンジニアリングとAIの本質を考える中で、自分が所属する組織を盛り上げて押し上げる行動をもっとしなければならないと感じる点が多々あった。必ずしも潤沢な資金が必要なのではなく、日々より良いエンジニアリングを追求し続けることと、それが当たり前の文化になるような流れを作ることだ。

AI時代においても、結局は地に足のついたエンジニアリングがすべての基盤となる。現在地から一歩で理想の状態に到達しようとするとうまくいかない。普段からやるべきことをやっておいて、いざ祭が始まればすぐ参加できるような姿勢を取り続けることが、長期的にはトレンドに乗る最良の方法だと再認識した。

やったこと

公式ドキュメントで環境構築して、公式Codelabsの「初めてのFlutterアプリ」を途中までなぞった。

https://codelabs.developers.google.com/codelabs/flutter-codelab-first?hl=ja#4 この5章まで終わった。

所感

Codelabsのチュートリアルがわかりやすくて良い。

コードはパッとみた感じはなんとなく輪郭は頭に入ってくるものの細かい書き味は結構違う印象でまだ全然慣れない。エディタが普段と違うのも大きく影響していそう。

また気が向いたらやる。

作業中のメモ

2025-01-30T22:00:13+09:00,Flutter環境構築やる https://docs.flutter.dev/get-started/install/macos/mobile-ios
2025-01-30T22:04:03+09:00,VSCodeのextensionを入れる https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter
2025-01-30T22:16:37+09:00,https://codelabs.developers.google.com/codelabs/flutter-codelab-first?hl=ja#0 これやる
2025-01-30T22:22:32+09:00,pubspec.yamlがプロジェクトの基本情報を書いておく場所らしい。コメントがいっぱいあるのでcopilotに日本語にしてもらった。
2025-01-30T22:39:00+09:00,"""これが Flutter の有名なステートフル ホットリロードの動作です"" とのこと"
2025-01-30T22:41:06+09:00,StatelessWidgetとStatefulWidgetの違いはあとで理解しておいたほうがいいらしい
2025-01-30T22:47:27+09:00,Scaffoldという便利ウィジェットがよく使われるらしい
2025-01-30T22:57:47+09:00,ある関数の引数のカッコの中でCmd+Shift+Spaceするとシグネチャが見れる　便利
2025-01-30T23:01:07+09:00,xcodeのview debuggerみたいなのがWidget inspectorというらしい
2025-01-30T23:01:33+09:00,Cmd+. でrefactoring menu
2025-01-30T23:02:18+09:00,SizedBox(height: 20) ga
2025-01-30T23:02:26+09:00,スペーサーの役割をする

XのタイムラインでClineの話題をよく見るようになり、気になって調べてみたらlaisoさんの超まとまった記事にたどり着いた。

ざっくり読んでめっちゃ興味が湧いてきたので、自分もClineを試してみようと思った。

環境構築

やったこと。

• VSCodeのextensionをインストールする。
  • https://marketplace.visualstudio.com/items?itemName=saoudrizwan.claude-dev
• DeepSeekのアカウントを作り、APIキーを発行する。
  • Top upから先にお金を払っておいて、利用ごとにその残高から引かれていく方式のよう。

概ねこれだけで、あとはサイドバーからClineを起動するとAIプロバイダーとAPIキーを聞かれるのでDeepSeekを選択しAPIキーを入力。するともう準備完了っぽい見ためになった。

Swiftを書かせてみる

「CLIで動作するポーカー(テキサスホールデム)ゲームをSwiftで作って」という指示をだしたら、ガチャガチャコード書き始めてびびった。本当に「ウワッ」と声が出た。

ゲームを実行すると自分の手札が表示されて、賭ける金額かもしくは降りるかを入力する、というところまであっという間に実装された。

そのあと後続のアクションや機能追加のリクエストをいろいろしていたら、コンパイルエラーを治すために適当に変更する、そのコンパイルエラーを治すためにまた適当に変更する、の沼にはまってしまうようになった。指示が悪かったのかもしれないし、Swiftはまだあまり得意でないのかもしれないと思った。

個人ブログにタグフィルター機能を追加させる

Nextjsでできたこのブログサイトのトップページに、タグフィルターをつけたいと思っていた。これをClineにやらせてみた。

まず要件を適当に指示し、出てきたものを見ながら細かい動作を変えたり見た目を整えたりする指示を追加で与えるだけで完了した。自分は本当に一行もコードを書かなかった。

できたもの↓

意味ある変更があるごとにgitにコミットするよう指示をしておいた。以下がClineが書いた変更である。(ブランチを切ったりPR作ったりするのは自分でやった)

所感

正直舐めてた。コードが書かれている様子やエラーを勝手に解釈して修正を繰り返しているところをみて、ゾワッとした。嫌悪ではなく、ワクワクで鳥肌が立つ感じ。

今年はFlutterやろうかなと思っているので、上手に力を借りれば効率よく学習できるかもと思った。

2025年の目標

• iOSアプリ開発者としての停滞感から脱却する
• ソフトウェア開発者としての幅を広げる
• コードを書く以外の収入源を持つ
• 子供の写真を5,000枚撮る

iOSアプリ開発者としての停滞感から脱却する

2014年にiOSアプリ開発者に転向してから10年が経った。腕にはそれなりに自信を持てるようになってきた一方で、ここ1年はただその記憶を切り売りして、やったことあるものを再放送してるだけだと感じることが増えた。会社の仕事ではレガシーに立ち向かうことが多くなって、トレンドに対するキャッチアップは別途時間を取らないと追いつかなくなったのもあるのかもしれない。キャリアの軸(というかそれしかない一本足)であるiOSアプリ開発者としての賞味期限を早めているかもしれないということへの危機感が今の色んな感情の根底にある気がする。具体的には

• インプットとアウトプットをセットで前年比がんばる
  • ブログも新しく作ったしね
• コミュニティに前年比ちゃんと参加する
  • 登壇したい
• もうすこし自然にトレンドに触れられるように業務を改善する
  • 今いる環境を良くすることかもしれないし、違う環境に身を置くかもしれない

このような取り組みを通じて、ちゃんと使えるiOSアプリ開発者としての賞味期限を伸ばせるよう鍛錬する。

ソフトウェア開発者としての幅を広げる

これまでは割と意識的にiOSだけをやるようにして、他のプラットフォームには手を広げないようにしてきた。いろんな科目で60点取れるより、120点取れる科目が1つある方が価値が高いだろうと思っていたから。今もその思想は変わっていないが、ここから自分がiOSアプリ開発の技術を更に30点伸ばすよりも、持ってる知識を横展開して隣の領域で効率よく70点を目指すほうがコスパがいいのではと感じ始めた。広げる先の候補としては

• Androidのネイティブアプリ開発を身につけて、iOS/Android両対応のアプリ開発者になる
• モバイルアプリのマルチプラットフォーム方面の技術を身につけて、iOS/Android両方に向けたアプリを作れるようになる
• Webアプリケーションの開発を身につけて、iOS版とWeb版を作れる開発者になる
• バックエンドのAPIを開発できる言語を新たに身につけて、iOSアプリに加えてそれが叩くAPIも仕事で作れるようになる

今の時点でこんなところかなーと思っている。順番に意味はない。とりあえずちょこちょこいろいろ触ってみてちゃんと決めるつもり。

コードを書く以外の収入源を持つ

これにはとりあえず2つの意味があって、

• 10年やってきたiOSアプリ開発の知見を、コードを書く工数としてではない形で提供する
• 仕事でやってるような技術以外に趣味でやってることを収益化する

という感じ。どちらもいろいろ考えていることがあるがまた改めて文章にしたい。

子供の写真を5,000枚撮る

2024年の途中で子供が生まれて、年末までに3,312枚の写真を撮っていた(Googleフォトのアルバムでカウント)。今年には多分喋りだしたり歩きだしたりするだろうから、年末までに5,000枚撮りたい。写真も動画も撮るぞ。

おわりに

がんばるぞ。

…という自己陶酔肯定感の高さが滲んで普段は嫌悪している前置きをして。

この文章は、理想とする組織には人手が足りず、採用予算とヘッドカウントに限りがあり、優先度に基づいて必要なポジションを埋めていかねばならず、早く採りたい気持ちと妥協したくない気持ちの間で圧迫されている、(私のような)現場の面接担当者に向けたものである。

危険信号を自覚する

エンジニア職の採用候補者との面談や面接をいくつもこなす中で、とても優秀な人と予期せず出会うことがある。輝かしい職歴に確かな技術、明瞭な受け答えと人当たりの良さ、きっと多くの会社がこの人を欲しがるだろう。こんな人には滅多に出会えない、他社に取られたくない、と思う。この人がうちに貢献できることはたくさんある、どこの部署で何をしてもらおう、と考え始める。

この時点で、すでに危険信号である。

その優秀な採用候補者というレアポケモンに自分が心を躍らせているのは、以前から自分たちが必要として探し求めていたからか？それとも、突然レアなのが目の前に現れて捕まえたくなってるだけか？どちらに当てはまるのかを冷静に客観的に理解する必要がある。

現場のチームの中でどの守備位置を補強したいのか、その候補者はどんな能力を持っていないといけないか、つまり採用のペルソナと呼ばれるようなものをきちんと高い解像度で理解していることが何より大事。そのためには前提として現場のチームとそれを構成する各個人の状況を把握すること、組織としての強みと弱点がそれぞれどこにあるのかを知っていることが必須。そこをきちんと理解したうえで、チームに必要な補強というのが、複雑な新機能を高度に設計できる人を採ることなのか、既存のコードをバリバリ改善できる人を採ることなのかを考えなければならない。

しかしながら、過去から現在までの職場での採用活動を思い返しても、「経験xxx年くらいで年収xxx万くらいのxxxエンジニアを採る」しか掲げられていないことも多かった。ペルソナの解像度が十分に高い状態で進む採用活動は、例えちょっと優秀でタイミングが合えばぜひ欲しいな〜と思う人と出会ったとしても、「でもこの人の能力は今自分たちが最も必要とするものではない」と自信を持ってお見送りすることができる。逆にペルソナの理解が粗い状態では、「この人優秀そうで取り逃がすともったいないから本当に必要な人かわからないけどとりあえず通過させる」方向に力が働く。自分たちにあるニーズとの不一致に確証を持てないから。

まとめると、自分たちが本当に必要としている像を高い解像度で理解していないと、優秀そうなやつを何でもかんでも採る方向に力がかかりやすい、ということに自覚的になり、そうならないために現場感を磨き続ける必要があるということ。

この話を他人に説明するときに使ってる例え

• 強そうだからリザードン捕まえたけど、実は現場はみずタイプのジムを攻略しようとしていて、ピカチュウが欲しかった。リザードンは役に立たなかった。モンスターボールもなくなった。
• 年俸の高さでしかサッカー選手を評価できない監督が、チームの弱点すら把握しておらず、またゴールキーパーを連れてきた。
• お前優秀なビジネスマンが採用候補者として現れるたびに採って新規事業始めるのか？

逆に

私が求職者側としてカジュアル面談を受けるとき、必ず「いま現場を構成してるメンバーはそれぞれどういう強みを持っていて、どこに弱点があるのか」「この採用活動を通じて新しく入るメンバーに期待する能力や振る舞いはなにか」を聞くようにしている。それに対して私の経験や得意分野と一致するようなことを言ってくれたら選考受けてみようかなと思うし、なんかほにゃほにゃしてたり私の得意領域と違うことをバシッと言われたりすると、今回は縁なかったなと思う。

$ mkdir workspace
$ cd workspace
$ cp -r $IDF_PATH/examples/get-started/hello_world/*

プロジェクト名を変えるには、 CMakeLists.txt で

set(PROJECT_NAME, "new_name")

ビルドする。

$ . $IDF_PATH/export.sh
$ idf.py set-target esp32c3
$ idf.py build flash monitor

エントリーポイントをSwiftに置き換える

https://github.com/hiragram/esp32-swift-template/tree/979c6c1d735850d0febdcb2a2c8aabc2bf371972

swift-embedded-examplesの esp32-led-strip-sdk を写経するような形で CMakeLists.txt を書いた。

https://github.com/hiragram/esp32-swift-template/blob/979c6c1d735850d0febdcb2a2c8aabc2bf371972/main/CMakeLists.txt

Hello worldはできたので、次はwifi関連の機能を触ってみたい。

• CMake: プロジェクト構成を定義するもの。 CMakeLists.txt でビルドプロセスを設定する。
• Ninja: CMakeによって生成されるビルドスクリプトを高速に実行する。

プロジェクト構成

ESP-IDFの典型的なプロジェクト構造は以下のようになる。

• project/
  • main/
    • CMakeLists.txt : アプリケーションコード用のビルド設定
    • main.c : アプリケーションのエントリーポイント実装
  • CMakeLists.txt : プロジェクト全体のビルド設定
  • sdkconfig : コンパイル時の設定

swift-embedded-examplesを見る

いわゆるLチカを見ていく。 https://github.com/apple/swift-embedded-examples/tree/main/esp32-led-strip-sdk

esp32-led-blink-sdkというやつもあったが光らなかった。DevKitMに乗ってるのはカラーLEDで、esp32-led-strip-sdkのREADMEにはカラーLEDを動かしてる写真が乗ってたので、blinkが単色LED、stripがカラーLEDを意味するのだろうか。

esp32-led-strip-sdkはC6を想定したサンプルコードのようだが、LEDのピン番号を書き換えるだけで動いた。

次やること

Main.swift の書き方とBridging Header周りはなんとなく触ってわかったので、IDFの新規プロジェクトからLチカサンプルまで自分でたどり着くかどうかやってみる。

CMakeLists.txt が結構いろいろ書いてあるのでつまづきそうな気がする。

• ESP32
  • Espressif Systems社が開発したマイコン。チップそのもののこと。
• ESP32開発ボード
  • ESP32チップに追加の部品やIOを追加したもの。Espressif Systems社のDevKitCを始め、他メーカーからも純正ESP32チップにモジュールを追加した開発ボード製品が発売されている。
    • M5Stack
    • Arduino Nano ESP32
    • など
• ESP32-C3, ESP32-C6
  • それぞれESPシリーズのチップのモデル。
  • WifiやBLEの対応バージョンが違ったりする。
  • それぞれのチップに固有のハードウェア/機能を使わない限り同じコードで動くはずである。
• ESP-IDF (Espressif IoT Development Framework)
  • Espressif System社が提供する公式の開発フレームワーク。
  • ESP32シリーズ(ESP32, ESP32-C3, ESP32-S3, ESP32-C6など)のプログラムを開発するためのツールチェーンとライブラリを統合した環境。
• Embedded Swift
  • 組み込みシステム向けに設計されたSwiftのコンパイルモードの一つ。
  • まだExperimental
  • ESP-IDFがハードウェアを抽象化し、そのAPIをSwiftから呼び出す。
    • Bridging HeaderでCのAPIを見えるようにする。
• DevKitMのCOMポートとUSBポート
  • 手元にあるDevKitMにはUSB-C端子が2つあり、それぞれCOMとUSBと書かれている。
  • COMポートはプログラムの書き込みやデバッグに使われるもので開発中はこっちに繋いでおけば良い。
  • USBポートはこの開発ボードをUSBデバイスとして利用するときに使われるポート。キーボード作るときとか。
• COMポートにUSBケーブルを繋いでも認識されないとき
  • $ idf.py flash が No serial ports found. Connect a device, or use '-p PORT' option to set a specific port. で失敗するとき。
  • DevKitMのUSB-to-UARTチップのドライバをインストールする必要がある。
    • Macのシステム情報のUSBのページを見て、製造元ID 0x1A86 があれば CH340 、 0x10C4 があれば CP210x 。

過去の転職を数えると4回、そのうち複数のオファーを貰って比較検討したのは1回だけ。それ以外はそろそろ辞めようかな〜と漠然と思っているところにメッセージを頂いて選考受けてそのままそこに、って感じ。ちなみに新卒の就職も最初に内定出たところにその場で承諾して就活を終えた。

バタバタと短期で決断してスポッと移動する、みたいなのをこれまでやってきたが、改めて考えると実は結構機会損失があるのではと思い始めた。逆に、めっちゃ時間をかけられるとしたらどういう体験になるんだろうか。

選考を通過して受けるオファーには回答期限がある。複数のオファーを並べて転職先を選ぶためには、すでに得たオファーの中で一番近い回答期限がくるまでに、今受けている/これから受ける会社のオファーをかき集めなければならない。そうすると転職活動は急に慌ただしくなる。すでに決まっている選考日程を前倒しできないかお願いしたり、選考結果を急かしたりすることになってしまう。一般にオファーの回答期限はたかだか数週間くらい？覚えていないが。その間に興味がある会社や事業ドメインに手広くエントリーしたり、現場の人と追加で面談させてもらったり、みたいな有意義な転職活動を満足にしきるのは難しくなるだろう。

そういう爆発的な短期決戦の転職活動ではなく、じっくりコトコトみたいなタイプのゆるい転職活動、ゆる転職活動は実現可能なのかを考えてみた。

回答期限がなくて採用枠をホールドしないオファー

オファーに回答期限があるのは、応じるのか断るのか結論が出るまでの間その人が座るかもしれない席が予約状態になるからである。例えばヘッドカウントが1の求人なら、前のオファーが断られるまで次の人にオファーを出せない。だから企業側としてはなるべく回答期限を短くしたいし、それによって求職者は慌ただしいスケジュールを組まなければならなくなる。

これはどっちも不幸なようにも見えるので、前提をひっくり返して考えてみる。

まず、選考を通過した求職者に企業がオファーを出すとき、回答期限は設けないことにする。その代わり、企業はオファーへの回答を待たず、採用活動を継続する。他に選考を通過した者がいれば、そちらにも同様のオファーを出す。もし自分がオファーを承諾しようとした時点ですでに他の人が同じポジションのオファーを承諾してヘッドカウントがなくなっていたら、自分はそこには入れない。つまり、「回答はいつでもいいけど、先に他の人で埋まっちゃったらナシね」というのが、「回答期限がなくて採用枠をホールドしないオファー」である。

実際、エンジニア不足と言われる昨今、あるポジションが半年経っても埋まらないみたいなことはまったく珍しくなくて、そういう状況のときに「半年前にオファーもらった時は現職に残ることにしたので断ったんだけど、やっぱりそっちに行きたくなりました」みたいなポケモンが現れたら、採るでしょ？それでよくない？

事業のフェーズがめっちゃ変わるとか、採用要件がめっちゃ変わるとか、そういうガラッとした変化によって過去に選考通ったという事実が無価値になるようなことがない限り、改めて認識すり合わせ直すくらいで互いに入社の決断できたりしないかな。

もし将来また転職するかとなったときはそういうやり方でやってみたい。そういう雰囲気になってたらいいなー。

Amazon.co.jp: スーパーエンジニアへの道　技術リーダーシップの人間学 電子書籍: G.M.ワインバーグ, 木村 泉: Kindleストア

ゆるコンピュータ科学ラジオというポッドキャスト番組を普段から聞いていて、そこで紹介されていた本だ。

この本は訳書で、日本語版は1991年に初版が出版された。30年以上が経っていながらその内容は今も色褪せないと評判で楽しみにしていた。

……が、正直私には合わなかった。訳書という性質からなのか、30年前の文章だからなのかはわからないが、とにかく読んで理解する負荷が高かった。多分本来書かれていることの半分も頭に入っていないだろう。

それでも私が従前抱えていた疑問が少し晴れた部分があったので、その点について書く。

悪い体臭を放つエンジニア

第15章「力、不完全性、整合性」にて、次のようなエピソードが記されている。

ある若いプログラマがひどいにおいを発散していて、まわりの連中が彼といっしょに働くのをいやがった

「あなたのグループの人たちの中に、あなたの近くで働いているとあなたの身体から発散するにおいのために気分が悪くなる、といってきた人が何人もいます。私たちはあなたの仕事ぶりを高く評価していますが、もしほかの人たちがあなたといっしょに働けないのだとしたら、明らかにわれわれのグループは生産的ではあり得ません。この問題を解決するために、何ができるでしょうか。」といってやりさえすればよい。

なぜマネージャーはそうしないのだろう？

なぜ仲間のプログラマの方がそうするのではないのだろう？

引用元: G.M.ワインバーグ. スーパーエンジニアへの道　技術リーダーシップの人間学. 共立出版株式会社. Kindle 版. (以降同じ)

このエピソードに登場するラルフというエンジニアは革細工が趣味で、それで使う薬品が身体に染み付いており、周囲にとって悪いニオイを発していたのだった。ラルフ自身はその香りに馴染みがあったために、それに気づかなかった。ラルフのマネージャーは、著者の助言をうけて、ラルフに周囲の状況を率直に伝え改善を求めた。するとラルフはマネージャーに感謝し、医者に薬品による皮膚の悪いニオイを改善する薬を処方してもらい、問題は解決された。

著者はこれを

これほど機械的な解決法はない、というぐらい機械的な解決法であった。

と評している。

この一連のエピソードについて私が思ったことを整理する。

率直に指摘できないのは、その者を未熟とみなしていることと同じ

著者はこの出来事について次のように書いた。

• マネージャーやチームメイトがラルフが発するニオイについて本人に率直に指摘するのを躊躇う理由は、それによってラルフがカッと怒ったり、深く落ち込んでしまったときに、それに対する責任を負えないと考えるから
• しかし、結果的に、ラルフは指摘を受け入れ、その解決策を獲得してみせた。ラルフは周囲からの合理的な指摘に対して怒りや落ち込みといった反応を示さずに自分の行動を変えられる成熟した精神と高い自尊心を持ち合わせていた

つまり、自分の技術に自身をもって自尊心高く仕事をしている人は1個の大人として精神的に成熟しており、逆に周囲が「この人はこの指摘をされたら怒ったり悲しんだりするだろう」と仮定することはすなわち「この人は精神的にまだ未熟なのだろう」と暗に考えているのと同じである、ということ。

率直に指摘をするとき、その状況を自分に当てはめて想像してしまう

著者は次のようにも書いた。

• ラルフに率直な指摘をすることを躊躇うのは、その指摘を受けることを自分自身に当てはめて想像してしまうから
• でもよく考えて。自分がもし高い自尊心を持って仕事に取り組んでいたら、その指摘に感謝し、自覚がなかったことを申し訳なく思い、なにか改善の手を打てるだろう。自分に当てはめて怒りや悲しみを想起するのは、自分が1個の大人として成熟していないからだ。

つまり、「相手がこういう反応をするかもしれない」という想像がどこから来るかというと、「自分だったらそういう反応をするはずだ」という自己認識から来る、ということ。そして自分の自尊心が高いことは、相手がそれだけ成熟していると信じられることに繋がり、率直なコミュニケーションを円滑に打ち合うことを実現する。

ちなみにこの本の中では、もしラルフが率直な指摘を受けてカッと怒るような未熟なプログラマであったとしたら、それは単にラルフが未熟なことが問題であって、マネージャーやチームメイトの問題ではないとされている(個人的にはマネージャーは部下の成熟にコミットしてほしい気はする)。

「コードレビューは優しい言葉で」に当てはめる

「良いコードレビューとは」、みたいな文脈で敬語がどうだとか言葉遣いがどうだとか語られることがある。果ては「ビックリマークをつけましょう！」とか「絵文字を使いましょう😄」とか言い出す始末(私は正直くだらんと思っている)。

ラルフの例をコードレビューに当てはめて考えてみる。自身の知識不足からコードに明らかな技術的間違いがあることを率直に指摘されたとき、成熟した大人のエンジニアであればそれを新たな知識獲得の機会と捉えてより良いコードを書くことができるが、精神的に未熟なエンジニアであれば指摘してきた人を怖いと感じたり自分の知識すべてについて自信をなくしたりするだろう。他者のコードに明らかな技術的間違いを見つけたとき、成熟した大人のエンジニアであれば相手にも同じく成熟した大人であることを信じて率直な指摘ができるが、精神的に未熟なエンジニアであれば相手が気を悪くすると思って本来伝えたいニュアンスからねじ曲がったコメントを書いてしまうだろう。

もっともっと雑で乱暴な言語化をすると、「 同僚のことを、技術をもって1人のプロとして自尊心高く働いている大人のエンジニアであると信じてあげて」みたいな。

一番まずいのは情報がねじ曲がってしまうこと

単に語尾がどうとかいう話ならまだいいが、相手の未熟さに遭遇しないためにふわふわの優しい言葉で包むみたいなことをやりすぎていると、深刻度や緊急度が誤って伝わることに繋がる。

「パスワードを平文で保存するのはダメです、ハッシュ関数を通してください」であって、「パスワードを平文で保存すると良くない気がするのでハッシュ関数を通したほうが個人的にはいいかもです」であるべきではない。これでは相手を未熟とみなした挙げ句指摘の深刻度も軽いものとして扱われる、悲惨な結果につながる。

自分の意見に自身を持ってときには断定的に物を言えるのもまた、自分への自信と自尊心があることのあらわれでもあるだろう。

次にまずいのは歪んだコミュニケーションが定着して当たり前になること

「Aにしてください」ではなく「Aのほうが良いと思うんですが、どうですか？」のような優しい言葉遣いにしましょう、みたいなコードレビューポリシーが跋扈している環境では、純粋に意見を求めようとして「Bも良さそうなんだけどどうですか？」と聞いたはずが、受け取り側は「Bにしてくださいという指示を受けた」という認知になり逆転現象が起こる。

非難していいわけではない

この本の中で、成熟した人間の行動パターンとしていくつか挙げられている中に、次のようなものがある。

人や状況を扱うときは、それぞれの文脈の中で、それがどうあってほしいかとか、どうあるはずであるかとかではなく、むしろどうあるかに目を留めて扱う。

ラルフの例なら、目を留めるべきは「ラルフから悪いニオイがして、周囲のメンバーが困っていること」であり、それが趣味によるものであることや本人に自覚がなかったことなどを咎める必要はないということ。コードレビューの例なら、そのコードの間違いに目を留めればよく、その背景にある知識不足や確認不足を咎める必要はない(もちろん、それら自体が深刻な問題であるなら咎められるべきだが)。

関連

技術リーダーに必要な、たったひとつの能力。#147 - ゆるコンピュータ科学ラジオ

多くの方が魂のこもった熱いメッセージをくださる一方で、中にはこれはちょっと自分のプロフィールをちゃんと見ていただけてないのかなと思うものもある。ちゃんと時間をかけて書いてくれたものはちゃんと読みたいし、コピペでささっと作られたものに時間を取られたくないので、7年くらいまえからやってることがある。

「スカウトメッセージにはあなたの好きな焼き鳥の部位を書いてください」

今のところWantedlyのプロフィールの下の方とGitHubのユーザーページに、上記のテキストが置いてある。私のプロフィールをある程度隅々まで読んだ上で書かれたメッセージには、その人の焼き鳥の好みが書かれている。逆にコピペで量産されたテキストや、サマリだけみて書かれたメッセージには、焼き鳥が書かれていない。冒頭に焼き鳥の好みが書いてあれば最後まで目を通すようにしている(できればちゃんとお返事をかけると良いのだが)。

意外とフィルターとしての性能は高いし、その後カジュアル面談の機会を得たときもアイスブレイク的に触れて頂くこともある。

思えば現職、前職、前々職とファーストコンタクトには焼き鳥が書いてあったし、クックパッドに入ったときの最初の面談のときはオフィスのキッチンラウンジで焼き鳥丼が振る舞われて面白かった。

というわけで、プロフィール情報にそういうトラップを仕掛けておくのは結構おすすめ。スカウト送る側の人は隅々までプロフィール見るようにしよう。

ちなみに、採用担当者の間で人気が高いのは、かわと砂肝のようだ。

オフィスに集まって働くチームのコミュニケーションには2種類ある。双方の意思によって行われるものと、特に意図せず醸し出された情報を特に意図せず感じ取るものだ。私は前者をアクティブ、後者をパッシブなコミュニケーションと呼んでいる。アクティブなコミュニケーションはイメージしやすく、口頭での会話やチャットのやり取りがそれにあたる。ではパッシブなコミュニケーションとは何なのか。

パッシブなコミュニケーション

それは、例えば以下のようなものである。

• ある同僚の顔色や声色から、なんとなくその日の体調がわかる
• ある同僚が考え事をしている時間が多くて、壁打ち相手になったほうがよさそうに感じる
• ある同僚が息抜きにコーヒーを飲んでいて、今なら話しかけても大丈夫そうと思える

一言で抽象化するなら「その人の挙動や雰囲気から周囲に届く情報」だろうか。パンデミックを機にリモートワークとなった人は、過去にオフィスで働いていたときのことを思い返すと、そういった雰囲気から多くの情報を得ながら働いていたのではないか。

では、リモートワークにおいてはどうか。これらのパッシブなコミュニケーションは、オフィスに集まって働いていたときには無意識に成り立っていたはずだ。一方でチャット中心のリモートワークでは、これらのパッシブなコミュニケーションから本来得られる情報は殆ど失われてしまう。

リモートワークに必要な覚悟

失われたパッシブなコミュニケーションをアクティブなコミュニケーションで補う

オフィス空間に自然に存在していたパッシブなコミュニケーションによる情報伝達が失われたリモートワークにおいては、その重要さを理解し、アクティブなコミュニケーションによってそれを補う努力をする必要がある。その覚悟を持たずにリモートワークをするというのは、「単に自分にとって快適な環境に居て、コミュニケーションのクオリティは下がっただけの人」になるということである。「通勤時間がなくなって嬉しい」みたいな理由でリモート環境を選択している人はそうなっていないか振り返ってほしい。アクティブなコミュニケーションでさえもリモートワークにおいてその難しさは増し、例えばチャットに書く文章は解釈が一意になるよう推敲したり、相手の文章から正しく意図を汲み取ることに気をつけたりする必要がある。さらにそこに加えて、失われたパッシブなコミュニケーションを補って初めて、「オフィスに集まって仕事をするのと同じ水準のコミュニケーション」を目指せるのだ。

オフィス空間におけるパッシブなコミュニケーションは、直接的に業務に関わることだけではなく、例えば服装や持ち物、仕事で使う機材などからその人の趣味や嗜好などを感じることができ、それはチームビルディングや新メンバーのオンボーディングの過程で役に立ってきた。一方でリモート環境に新しく参画したメンバーが半年経っても同僚の深い人となりをあんまりわかっていない、みたいな状況も珍しくないだろう。これもまた、本人と周囲の両方が意識的にパッシブなコミュニケーションの欠損を埋める努力をしないと、チームのモメンタムが上がらない大きな要因になりうる。

どうすればいいのか

「失われたパッシブなコミュニケーションをアクティブなコミュニケーションで補う」とは、具体的にどのような行動を指すのか。シンプルに表現すると、「適切な自己開示」と「他人に興味を持つこと」であると言える。

適切な自己開示とは、パッシブなコミュニケーションにおいては自身から無意識に醸し出され、周囲がそれを読み取っていたような情報を、自ら意識的に発するということである。いわゆる分報のような場所を使ってもいいし、チームのチャンネルを使ってもいいと思う。パッシブなコミュニケーションひとつひとつの情報量はそれほど多くない。上でパッシブなコミュニケーションの例として挙げたものをチャットでの自己開示で補うとしたら、「朝から腹痛い」「うーん」「コーヒー休憩」で十分なこともあるだろう。

他人に興味を持つとは、他人の自己開示に意識を向けそこから情報を得るということである。また、ただ受け取るだけではなく、適切にレスポンスを返すことで、アクティブなコミュニケーションに活力をもたらし、ひいてはチーム全体のモメンタムを高めることに繋がる。同僚の分報に参加するとか、いろんなチームのチャンネルに参加してみるとか、そういうアンテナを広く張ることが他人に興味を持つ第一歩となる。

才能

ここまで読んで、「なんだその程度のことか」と感じたあなたには、リモートワークの才能があります。引き続きコミュニケーション水準を高く保ち、チームのモメンタムを高めていってください。

技術面について

Next.jsもVercelも初めて触ったし、ヘッドレスCMSもJamstackも初めてどういうものか理解した。

Next.jsについてはコンポーネントを分割して他のファイルから呼び出すやり方がわかった程度で、あとは先人の記事とChatGPTの助けによって形にした感じ。

このブログは、microCMSが公開している以下の記事をほぼなぞって完成した。

Webフロントエンド技術には昔から苦手意識があり(ビルドしてページを表示するまでの登場人物が多いこととか)、教養として最低限触っておきたい気持ちはずっと持っていたものの、楽しいと思える手前で挫折してきた。ブログをプラットフォームに頼らず自前で作る醍醐味といえば自分の好み通りにカスタムできることだが、果たして自分がそういう楽しみ方をしていくのかはわからない。

ブログについて

従前ははてなブログを使っていたが、最近は数年おきに転職エントリが上がるだけになっていて、最近になってそもそもブログを書く目的が存在しなかったことに気づいた。役に立つ技術記事を書く意欲があったわけでもなく、自分の日常を知ってほしいわけでもない。眼前にある更新頻度も質も低い旧ブログから、例えばnoteに移行するとか、mediumに移行して英語で技術記事を書くとか、そういう選択肢もフワフワと存在していたものの、何のために移行するのか、移行先で何のためにブログを書くのかが何もないままなので何も決まらずにいた。

ブログプラットフォームを抜け出して自前で構築することはそのプラットフォームがもたらす集客効果の恩恵を手放すことを意味するが、そもそもそういうオーガニックな流入がドカンと来るような色のコンテンツなんだっけと思ったとき、別にいらんのかもしれん。検索やプラットフォームからの流入を無視して、「僕自身のことを知るために見に来る」みたいな人に自分がどういう人間なのかを伝える材料としてブログを書いていけたらいいのかなーとなった。例えば転職活動のレジュメに添えるとか。

ああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああ

見出し2

あ

あ

あ
改行

見出し3

太字

斜体

見出し4

見出し5

リンクテキスト

• リスト要素1
• リスト要素2
• リスト要素3
  • ネストした要素
    • ネストした要素2
• リスト要素4

こんにちは。

インラインコード Hello world

画像の挿入も確認

let aaa = "Hoge"
print(aaa)