<p>、と言っても書き出した時点ではまだ何も触っていない。</p><p>XのタイムラインでClineの話題をよく見るようになり、気になって調べてみたらlaisoさんの超まとまった記事にたどり着いた。</p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Flaiso.hatenablog.com%2Fentry%2F2025%2F01%2F07%2F045009" title="ClineとAIコーディングツールの現状 - laiso" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><p>ざっくり読んでめっちゃ興味が湧いてきたので、自分もClineを試してみようと思った。</p><h1 id="h0ef859a5d4">環境構築</h1><p>やったこと。</p><ul><li>VSCodeのextensionをインストールする。<ul><li><a href="https://marketplace.visualstudio.com/items?itemName=saoudrizwan.claude-dev">https://marketplace.visualstudio.com/items?itemName=saoudrizwan.claude-dev</a></li></ul></li><li>DeepSeekのアカウントを作り、APIキーを発行する。<ul><li>Top upから先にお金を払っておいて、利用ごとにその残高から引かれていく方式のよう。</li></ul></li></ul><p>概ねこれだけで、あとはサイドバーからClineを起動するとAIプロバイダーとAPIキーを聞かれるのでDeepSeekを選択しAPIキーを入力。するともう準備完了っぽい見ためになった。</p><h1 id="h9776385478">Swiftを書かせてみる</h1><p>「CLIで動作するポーカー(テキサスホールデム)ゲームをSwiftで作って」という指示をだしたら、ガチャガチャコード書き始めてびびった。本当に「ウワッ」と声が出た。</p><figure><img src="https://images.microcms-assets.io/assets/3658e6a7fd3846aea91d64840f897fe0/4f231d7a71454dcaacd810067a79cb26/output.gif" alt="" width="984" height="638"></figure><p>ゲームを実行すると自分の手札が表示されて、賭ける金額かもしくは降りるかを入力する、というところまであっという間に実装された。</p><p>そのあと後続のアクションや機能追加のリクエストをいろいろしていたら、コンパイルエラーを治すために適当に変更する、そのコンパイルエラーを治すためにまた適当に変更する、の沼にはまってしまうようになった。指示が悪かったのかもしれないし、Swiftはまだあまり得意でないのかもしれないと思った。</p><h1 id="h3b756ddc46">個人ブログにタグフィルター機能を追加させる</h1><p>Nextjsでできたこのブログサイトのトップページに、タグフィルターをつけたいと思っていた。これをClineにやらせてみた。</p><p>まず要件を適当に指示し、出てきたものを見ながら細かい動作を変えたり見た目を整えたりする指示を追加で与えるだけで完了した。自分は本当に一行もコードを書かなかった。</p><p>できたもの↓</p><figure><img src="https://images.microcms-assets.io/assets/3658e6a7fd3846aea91d64840f897fe0/6d2504177b7245e09a038fdc17839a41/output.gif" alt="" width="964" height="1045"></figure><p>意味ある変更があるごとにgitにコミットするよう指示をしておいた。以下がClineが書いた変更である。(ブランチを切ったりPR作ったりするのは自分でやった)</p><div class="iframely-embed"><div class="iframely-responsive" style="padding-bottom: 50%; padding-top: 120px;"><a href="https://github.com/hiragram/website/pull/1" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fgithub.com%2Fhiragram%2Fwebsite%2Fpull%2F1&amp;key=c271a3ec77ff4aa44d5948170dd74161"></a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script><h1 id="h5fcec0cf90">所感</h1><p>正直舐めてた。コードが書かれている様子やエラーを勝手に解釈して修正を繰り返しているところをみて、ゾワッとした。嫌悪ではなく、ワクワクで鳥肌が立つ感じ。</p><p>今年はFlutterやろうかなと思っているので、上手に力を借りれば効率よく学習できるかもと思った。</p>

Clineを触ってみた

<p>株式会社nana musicのテックブログに寄稿していました。</p><p></p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Ftech.nana-music.com%2Fentry%2F2022%2F09%2F06%2F120709" title="Xcode Previewsをまとめて実機で触れるUIプロトタイプアプリにする - nana開発者ブログ" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe>

Xcode Previewsをまとめて実機で触れるUIプロトタイプアプリにする

<p>2024年は自分にとって大きな変化が続いた年だった。今までとは違う価値観で転職をして、30歳になり、子供が生まれた。そういうものを経て、いろいろ価値観が改まったと感じているので年頭所感として書いておく。</p><h2 id="hb43c909428">2025年の目標</h2><ul><li>iOSアプリ開発者としての停滞感から脱却する</li><li>ソフトウェア開発者としての幅を広げる</li><li>コードを書く以外の収入源を持つ</li><li>子供の写真を5,000枚撮る</li></ul><h2 id="h7aeef5b96b">iOSアプリ開発者としての停滞感から脱却する</h2><p>2014年にiOSアプリ開発者に転向してから10年が経った。腕にはそれなりに自信を持てるようになってきた一方で、ここ1年はただその記憶を切り売りして、やったことあるものを再放送してるだけだと感じることが増えた。会社の仕事ではレガシーに立ち向かうことが多くなって、トレンドに対するキャッチアップは別途時間を取らないと追いつかなくなったのもあるのかもしれない。キャリアの軸(というかそれしかない一本足)であるiOSアプリ開発者としての賞味期限を早めているかもしれないということへの危機感が今の色んな感情の根底にある気がする。具体的には</p><ul><li>インプットとアウトプットをセットで前年比がんばる<ul><li>ブログも新しく作ったしね</li></ul></li><li>コミュニティに前年比ちゃんと参加する<ul><li>登壇したい</li></ul></li><li>もうすこし自然にトレンドに触れられるように業務を改善する<ul><li>今いる環境を良くすることかもしれないし、違う環境に身を置くかもしれない</li></ul></li></ul><p>このような取り組みを通じて、ちゃんと使えるiOSアプリ開発者としての賞味期限を伸ばせるよう鍛錬する。</p><h2 id="hf4d0970471">ソフトウェア開発者としての幅を広げる</h2><p>これまでは割と意識的にiOSだけをやるようにして、他のプラットフォームには手を広げないようにしてきた。いろんな科目で60点取れるより、120点取れる科目が1つある方が価値が高いだろうと思っていたから。今もその思想は変わっていないが、ここから自分がiOSアプリ開発の技術を更に30点伸ばすよりも、持ってる知識を横展開して隣の領域で効率よく70点を目指すほうがコスパがいいのではと感じ始めた。広げる先の候補としては</p><ul><li>Androidのネイティブアプリ開発を身につけて、iOS/Android両対応のアプリ開発者になる</li><li>モバイルアプリのマルチプラットフォーム方面の技術を身につけて、iOS/Android両方に向けたアプリを作れるようになる</li><li>Webアプリケーションの開発を身につけて、iOS版とWeb版を作れる開発者になる</li><li>バックエンドのAPIを開発できる言語を新たに身につけて、iOSアプリに加えてそれが叩くAPIも仕事で作れるようになる</li></ul><p>今の時点でこんなところかなーと思っている。順番に意味はない。とりあえずちょこちょこいろいろ触ってみてちゃんと決めるつもり。</p><h2 id="he57de19dc2">コードを書く以外の収入源を持つ</h2><p>これにはとりあえず2つの意味があって、</p><ul><li>10年やってきたiOSアプリ開発の知見を、コードを書く工数としてではない形で提供する</li><li>仕事でやってるような技術以外に趣味でやってることを収益化する</li></ul><p>という感じ。どちらもいろいろ考えていることがあるがまた改めて文章にしたい。</p><h2 id="hc9f2e70ccb">子供の写真を5,000枚撮る</h2><p>2024年の途中で子供が生まれて、年末までに3,312枚の写真を撮っていた(Googleフォトのアルバムでカウント)。今年には多分喋りだしたり歩きだしたりするだろうから、年末までに5,000枚撮りたい。写真も動画も撮るぞ。</p><h2 id="h9be0c3393d">おわりに</h2><p>がんばるぞ。</p>

1個の人間としての生存戦略と2025年の目標

<p><strong>この記事の内容はあくまで私個人の考えであり所属企業の方針とは関係ありません</strong></p><p>…という自己<s>陶酔</s>肯定感の高さが滲んで普段は嫌悪している前置きをして。</p><p>この文章は、理想とする組織には人手が足りず、採用予算とヘッドカウントに限りがあり、優先度に基づいて必要なポジションを埋めていかねばならず、早く採りたい気持ちと妥協したくない気持ちの間で圧迫されている、(私のような)現場の面接担当者に向けたものである。</p><h2 id="h54f74ddb23">危険信号を自覚する</h2><p>エンジニア職の採用候補者との面談や面接をいくつもこなす中で、とても優秀な人と予期せず出会うことがある。輝かしい職歴に確かな技術、明瞭な受け答えと人当たりの良さ、きっと多くの会社がこの人を欲しがるだろう。こんな人には滅多に出会えない、他社に取られたくない、と思う。この人がうちに貢献できることはたくさんある、どこの部署で何をしてもらおう、と考え始める。</p><p>この時点で、すでに危険信号である。</p><p>その優秀な採用候補者というレアポケモンに自分が心を躍らせているのは、以前から自分たちが必要として探し求めていたからか？それとも、突然レアなのが目の前に現れて捕まえたくなってるだけか？どちらに当てはまるのかを冷静に客観的に理解する必要がある。</p><p>現場のチームの中でどの守備位置を補強したいのか、その候補者はどんな能力を持っていないといけないか、つまり採用のペルソナと呼ばれるようなものをきちんと高い解像度で理解していることが何より大事。そのためには前提として現場のチームとそれを構成する各個人の状況を把握すること、組織としての強みと弱点がそれぞれどこにあるのかを知っていることが必須。そこをきちんと理解したうえで、チームに必要な補強というのが、複雑な新機能を高度に設計できる人を採ることなのか、既存のコードをバリバリ改善できる人を採ることなのかを考えなければならない。</p><p>しかしながら、過去から現在までの職場での採用活動を思い返しても、「経験xxx年くらいで年収xxx万くらいのxxxエンジニアを採る」しか掲げられていないことも多かった。ペルソナの解像度が十分に高い状態で進む採用活動は、例えちょっと優秀でタイミングが合えばぜひ欲しいな〜と思う人と出会ったとしても、「でもこの人の能力は今自分たちが最も必要とするものではない」と自信を持ってお見送りすることができる。逆にペルソナの理解が粗い状態では、「この人優秀そうで取り逃がすともったいないから本当に必要な人かわからないけどとりあえず通過させる」方向に力が働く。自分たちにあるニーズとの不一致に確証を持てないから。</p><p>まとめると、自分たちが本当に必要としている像を高い解像度で理解していないと、優秀そうなやつを何でもかんでも採る方向に力がかかりやすい、ということに自覚的になり、そうならないために現場感を磨き続ける必要があるということ。</p><h2 id="hdd1517a381">この話を他人に説明するときに使ってる例え</h2><ul><li>強そうだからリザードン捕まえたけど、実は現場はみずタイプのジムを攻略しようとしていて、ピカチュウが欲しかった。リザードンは役に立たなかった。モンスターボールもなくなった。</li><li>年俸の高さでしかサッカー選手を評価できない監督が、チームの弱点すら把握しておらず、またゴールキーパーを連れてきた。</li><li>お前優秀なビジネスマンが採用候補者として現れるたびに採って新規事業始めるのか？</li></ul><h2 id="ha8198ef565">逆に</h2><p>私が求職者側としてカジュアル面談を受けるとき、必ず「いま現場を構成してるメンバーはそれぞれどういう強みを持っていて、どこに弱点があるのか」「この採用活動を通じて新しく入るメンバーに期待する能力や振る舞いはなにか」を聞くようにしている。それに対して私の経験や得意分野と一致するようなことを言ってくれたら選考受けてみようかなと思うし、なんかほにゃほにゃしてたり私の得意領域と違うことをバシッと言われたりすると、今回は縁なかったなと思う。</p>

優秀な採用候補者に出会ってしまったときのために普段考えていること

<p>ESP-IDFのhello worldサンプルを新規プロジェクトのテンプレートとしてコピーしてくるのが早い。</p><pre><code class="language-bash">$ mkdir workspace
$ cd workspace
$ cp -r $IDF_PATH/examples/get-started/hello_world/*</code></pre><p>プロジェクト名を変えるには、 <code>CMakeLists.txt</code> で</p><pre><code class="language-cmake">set(PROJECT_NAME, &quot;new_name&quot;)</code></pre><p>ビルドする。</p><pre><code class="language-bash">$ . $IDF_PATH/export.sh
$ idf.py set-target esp32c3
$ idf.py build flash monitor</code></pre><h2 id="h81f517f3f3">エントリーポイントをSwiftに置き換える</h2><p><a href="https://github.com/hiragram/esp32-swift-template/tree/979c6c1d735850d0febdcb2a2c8aabc2bf371972" target="_blank" rel="noopener noreferrer nofollow">https://github.com/hiragram/esp32-swift-template/tree/979c6c1d735850d0febdcb2a2c8aabc2bf371972</a></p><p>swift-embedded-examplesの <code>esp32-led-strip-sdk</code> を写経するような形で <code>CMakeLists.txt</code> を書いた。</p><p><a href="https://github.com/hiragram/esp32-swift-template/blob/979c6c1d735850d0febdcb2a2c8aabc2bf371972/main/CMakeLists.txt" target="_blank" rel="noopener noreferrer nofollow">https://github.com/hiragram/esp32-swift-template/blob/979c6c1d735850d0febdcb2a2c8aabc2bf371972/main/CMakeLists.txt</a></p><p>Hello worldはできたので、次はwifi関連の機能を触ってみたい。</p>

ESP-IDFの新規プロジェクトからSwiftでhello worldするまで

<p>ESP-IDFはビルドシステムとして <code>CMake</code> と <code>Ninja</code> を使用する。</p><ul><li><strong>CMake</strong>: プロジェクト構成を定義するもの。 <code>CMakeLists.txt</code> でビルドプロセスを設定する。</li><li><strong>Ninja</strong>: CMakeによって生成されるビルドスクリプトを高速に実行する。</li></ul><h2 id="h262fcef4ea">プロジェクト構成</h2><p>ESP-IDFの典型的なプロジェクト構造は以下のようになる。</p><ul><li><code>project/</code><ul><li><code>main/</code><ul><li><code>CMakeLists.txt</code> : アプリケーションコード用のビルド設定</li><li><code>main.c</code> : アプリケーションのエントリーポイント実装</li></ul></li><li><code>CMakeLists.txt</code> : プロジェクト全体のビルド設定</li><li><code>sdkconfig</code> : コンパイル時の設定</li></ul></li></ul><h2 id="h036ef1bde9">swift-embedded-examplesを見る</h2><p>いわゆるLチカを見ていく。 <a href="https://github.com/apple/swift-embedded-examples/tree/main/esp32-led-strip-sdk">https://github.com/apple/swift-embedded-examples/tree/main/esp32-led-strip-sdk</a></p><p>esp32-led-blink-sdkというやつもあったが光らなかった。DevKitMに乗ってるのはカラーLEDで、esp32-led-strip-sdkのREADMEにはカラーLEDを動かしてる写真が乗ってたので、blinkが単色LED、stripがカラーLEDを意味するのだろうか。</p><p>esp32-led-strip-sdkはC6を想定したサンプルコードのようだが、LEDのピン番号を書き換えるだけで動いた。</p><h2 id="h1ce7e783a6">次やること</h2><p><code>Main.swift</code> の書き方とBridging Header周りはなんとなく触ってわかったので、IDFの新規プロジェクトからLチカサンプルまで自分でたどり着くかどうかやってみる。</p><p><code>CMakeLists.txt</code> が結構いろいろ書いてあるのでつまづきそうな気がする。</p>

Embedded SwiftのESP32向けサンプルを見る

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

ESP32でSwiftを動かしたいので前提となる知識を整理する

<p><strong>(具体的に転職を考えてるわけではありませんがメシの誘いは喜びます)</strong></p><p>過去の転職を数えると4回、そのうち複数のオファーを貰って比較検討したのは1回だけ。それ以外はそろそろ辞めようかな〜と漠然と思っているところにメッセージを頂いて選考受けてそのままそこに、って感じ。ちなみに新卒の就職も最初に内定出たところにその場で承諾して就活を終えた。</p><p>バタバタと短期で決断してスポッと移動する、みたいなのをこれまでやってきたが、改めて考えると実は結構機会損失があるのではと思い始めた。逆に、めっちゃ時間をかけられるとしたらどういう体験になるんだろうか。</p><p>選考を通過して受けるオファーには回答期限がある。複数のオファーを並べて転職先を選ぶためには、すでに得たオファーの中で一番近い回答期限がくるまでに、今受けている/これから受ける会社のオファーをかき集めなければならない。そうすると転職活動は急に慌ただしくなる。すでに決まっている選考日程を前倒しできないかお願いしたり、選考結果を急かしたりすることになってしまう。一般にオファーの回答期限はたかだか数週間くらい？覚えていないが。その間に興味がある会社や事業ドメインに手広くエントリーしたり、現場の人と追加で面談させてもらったり、みたいな有意義な転職活動を満足にしきるのは難しくなるだろう。</p><p>そういう爆発的な短期決戦の転職活動ではなく、じっくりコトコトみたいなタイプのゆるい転職活動、<strong>ゆる転職活動</strong>は実現可能なのかを考えてみた。</p><h2 id="hc36c84c2ed">回答期限がなくて採用枠をホールドしないオファー</h2><p>オファーに回答期限があるのは、応じるのか断るのか結論が出るまでの間その人が座るかもしれない席が予約状態になるからである。例えばヘッドカウントが1の求人なら、前のオファーが断られるまで次の人にオファーを出せない。だから企業側としてはなるべく回答期限を短くしたいし、それによって求職者は慌ただしいスケジュールを組まなければならなくなる。</p><p>これはどっちも不幸なようにも見えるので、前提をひっくり返して考えてみる。</p><p>まず、選考を通過した求職者に企業がオファーを出すとき、回答期限は設けないことにする。その代わり、企業はオファーへの回答を待たず、採用活動を継続する。他に選考を通過した者がいれば、そちらにも同様のオファーを出す。もし自分がオファーを承諾しようとした時点ですでに他の人が同じポジションのオファーを承諾してヘッドカウントがなくなっていたら、自分はそこには入れない。つまり、<strong>「回答はいつでもいいけど、先に他の人で埋まっちゃったらナシね」</strong>というのが、「回答期限がなくて採用枠をホールドしないオファー」である。</p><p>実際、エンジニア不足と言われる昨今、あるポジションが半年経っても埋まらないみたいなことはまったく珍しくなくて、そういう状況のときに「半年前にオファーもらった時は現職に残ることにしたので断ったんだけど、やっぱりそっちに行きたくなりました」みたいなポケモンが現れたら、採るでしょ？それでよくない？</p><p>事業のフェーズがめっちゃ変わるとか、採用要件がめっちゃ変わるとか、そういうガラッとした変化によって過去に選考通ったという事実が無価値になるようなことがない限り、改めて認識すり合わせ直すくらいで互いに入社の決断できたりしないかな。</p><p>もし将来また転職するかとなったときはそういうやり方でやってみたい。そういう雰囲気になってたらいいなー。</p><p></p>

ゆる転職活動は実現可能か？

<p>この本を読んだ。</p><p><a href="https://amzn.to/4eNLEfw" target="_blank" rel="noopener noreferrer nofollow">Amazon.co.jp: スーパーエンジニアへの道　技術リーダーシップの人間学 電子書籍: G.M.ワインバーグ, 木村 泉: Kindleストア</a></p><p>ゆるコンピュータ科学ラジオというポッドキャスト番組を普段から聞いていて、そこで紹介されていた本だ。</p><p>この本は訳書で、日本語版は1991年に初版が出版された。30年以上が経っていながらその内容は今も色褪せないと評判で楽しみにしていた。</p><p>……が、正直私には合わなかった。訳書という性質からなのか、30年前の文章だからなのかはわからないが、とにかく読んで理解する負荷が高かった。多分本来書かれていることの半分も頭に入っていないだろう。</p><p>それでも私が従前抱えていた疑問が少し晴れた部分があったので、その点について書く。</p><h1 id="hbd7ed47f16">悪い体臭を放つエンジニア</h1><p>第15章「力、不完全性、整合性」にて、次のようなエピソードが記されている。</p><blockquote><p>ある若いプログラマがひどいにおいを発散していて、まわりの連中が彼といっしょに働くのをいやがった</p></blockquote><blockquote><p>「あなたのグループの人たちの中に、あなたの近くで働いているとあなたの身体から発散するにおいのために気分が悪くなる、といってきた人が何人もいます。私たちはあなたの仕事ぶりを高く評価していますが、もしほかの人たちがあなたといっしょに働けないのだとしたら、明らかにわれわれのグループは生産的ではあり得ません。この問題を解決するために、何ができるでしょうか。」といってやりさえすればよい。</p></blockquote><blockquote><p>なぜマネージャーはそうしないのだろう？</p></blockquote><blockquote><p>なぜ仲間のプログラマの方がそうするのではないのだろう？</p></blockquote><p><em>引用元: G.M.ワインバーグ. スーパーエンジニアへの道　技術リーダーシップの人間学. 共立出版株式会社. Kindle 版. (以降同じ)</em></p><p>このエピソードに登場するラルフというエンジニアは革細工が趣味で、それで使う薬品が身体に染み付いており、周囲にとって悪いニオイを発していたのだった。ラルフ自身はその香りに馴染みがあったために、それに気づかなかった。ラルフのマネージャーは、著者の助言をうけて、ラルフに周囲の状況を率直に伝え改善を求めた。するとラルフはマネージャーに感謝し、医者に薬品による皮膚の悪いニオイを改善する薬を処方してもらい、問題は解決された。</p><p>著者はこれを</p><blockquote><p>これほど機械的な解決法はない、というぐらい機械的な解決法であった。</p></blockquote><p>と評している。</p><p>この一連のエピソードについて私が思ったことを整理する。</p><h2 id="h5dfbdb03be">率直に指摘できないのは、その者を未熟とみなしていることと同じ</h2><p>著者はこの出来事について次のように書いた。</p><ul><li>マネージャーやチームメイトがラルフが発するニオイについて本人に率直に指摘するのを躊躇う理由は、それによってラルフがカッと怒ったり、深く落ち込んでしまったときに、それに対する責任を負えないと考えるから</li><li>しかし、結果的に、ラルフは指摘を受け入れ、その解決策を獲得してみせた。ラルフは周囲からの合理的な指摘に対して怒りや落ち込みといった反応を示さずに自分の行動を変えられる成熟した精神と高い自尊心を持ち合わせていた</li></ul><p>つまり、自分の技術に自身をもって自尊心高く仕事をしている人は1個の大人として精神的に成熟しており、逆に周囲が「この人はこの指摘をされたら怒ったり悲しんだりするだろう」と仮定することはすなわち「この人は精神的にまだ未熟なのだろう」と暗に考えているのと同じである、ということ。</p><h2 id="h7eeff0352a">率直に指摘をするとき、その状況を自分に当てはめて想像してしまう</h2><p>著者は次のようにも書いた。</p><ul><li>ラルフに率直な指摘をすることを躊躇うのは、その指摘を受けることを自分自身に当てはめて想像してしまうから</li><li>でもよく考えて。自分がもし高い自尊心を持って仕事に取り組んでいたら、その指摘に感謝し、自覚がなかったことを申し訳なく思い、なにか改善の手を打てるだろう。自分に当てはめて怒りや悲しみを想起するのは、自分が1個の大人として成熟していないからだ。</li></ul><p>つまり、「相手がこういう反応をするかもしれない」という想像がどこから来るかというと、「自分だったらそういう反応をするはずだ」という自己認識から来る、ということ。そして自分の自尊心が高いことは、相手がそれだけ成熟していると信じられることに繋がり、率直なコミュニケーションを円滑に打ち合うことを実現する。</p><p>ちなみにこの本の中では、もしラルフが率直な指摘を受けてカッと怒るような未熟なプログラマであったとしたら、それは単にラルフが未熟なことが問題であって、マネージャーやチームメイトの問題ではないとされている(個人的にはマネージャーは部下の成熟にコミットしてほしい気はする)。</p><h1 id="hb038fc4f8b">「コードレビューは優しい言葉で」に当てはめる</h1><p>「良いコードレビューとは」、みたいな文脈で敬語がどうだとか言葉遣いがどうだとか語られることがある。果ては「ビックリマークをつけましょう！」とか「絵文字を使いましょう😄」とか言い出す始末(私は正直くだらんと思っている)。</p><p>ラルフの例をコードレビューに当てはめて考えてみる。自身の知識不足からコードに明らかな技術的間違いがあることを率直に指摘されたとき、成熟した大人のエンジニアであればそれを新たな知識獲得の機会と捉えてより良いコードを書くことができるが、精神的に未熟なエンジニアであれば指摘してきた人を怖いと感じたり自分の知識すべてについて自信をなくしたりするだろう。他者のコードに明らかな技術的間違いを見つけたとき、成熟した大人のエンジニアであれば相手にも同じく成熟した大人であることを信じて率直な指摘ができるが、精神的に未熟なエンジニアであれば相手が気を悪くすると思って本来伝えたいニュアンスからねじ曲がったコメントを書いてしまうだろう。</p><p>もっともっと雑で乱暴な言語化をすると、<strong>「 同僚のことを、技術をもって1人のプロとして自尊心高く働いている大人のエンジニアであると信じてあげて」</strong>みたいな。</p><h2 id="hdfea16ca7f">一番まずいのは情報がねじ曲がってしまうこと</h2><p>単に語尾がどうとかいう話ならまだいいが、相手の未熟さに遭遇しないためにふわふわの優しい言葉で包むみたいなことをやりすぎていると、深刻度や緊急度が誤って伝わることに繋がる。</p><p>「パスワードを平文で保存するのはダメです、ハッシュ関数を通してください」であって、「パスワードを平文で保存すると良くない気がするのでハッシュ関数を通したほうが個人的にはいいかもです」であるべきではない。これでは相手を未熟とみなした挙げ句指摘の深刻度も軽いものとして扱われる、悲惨な結果につながる。</p><p>自分の意見に自身を持ってときには断定的に物を言えるのもまた、自分への自信と自尊心があることのあらわれでもあるだろう。</p><h2 id="h2ecee3e535">次にまずいのは歪んだコミュニケーションが定着して当たり前になること</h2><p>「Aにしてください」ではなく「Aのほうが良いと思うんですが、どうですか？」のような優しい言葉遣いにしましょう、みたいなコードレビューポリシーが跋扈している環境では、純粋に意見を求めようとして「Bも良さそうなんだけどどうですか？」と聞いたはずが、受け取り側は「Bにしてくださいという指示を受けた」という認知になり逆転現象が起こる。</p><h2 id="hec0fa7de0c">非難していいわけではない</h2><p>この本の中で、成熟した人間の行動パターンとしていくつか挙げられている中に、次のようなものがある。</p><blockquote><p>人や状況を扱うときは、それぞれの文脈の中で、それがどうあってほしいかとか、どうあるはずであるかとかではなく、むしろどうあるかに目を留めて扱う。</p></blockquote><p>ラルフの例なら、目を留めるべきは「ラルフから悪いニオイがして、周囲のメンバーが困っていること」であり、それが趣味によるものであることや本人に自覚がなかったことなどを咎める必要はないということ。コードレビューの例なら、そのコードの間違いに目を留めればよく、その背景にある知識不足や確認不足を咎める必要はない(もちろん、それら自体が深刻な問題であるなら咎められるべきだが)。</p><hr><h2 id="h066f4663d0">関連</h2><p><a href="https://podcasts.apple.com/jp/podcast/%E6%8A%80%E8%A1%93%E3%83%AA%E3%83%BC%E3%83%80%E3%83%BC%E3%81%AB%E5%BF%85%E8%A6%81%E3%81%AA-%E3%81%9F%E3%81%A3%E3%81%9F%E3%81%B2%E3%81%A8%E3%81%A4%E3%81%AE%E8%83%BD%E5%8A%9B-147/id1604353315?i=1000674577788" target="_blank" rel="noopener noreferrer nofollow">技術リーダーに必要な、たったひとつの能力。#147 - ゆるコンピュータ科学ラジオ</a></p>

「コードレビューは優しい言葉遣いでするとよい」は嘘

<p>ありがたいことに、エンジニアとしてうちに来ないかというメッセージを転職系のメディアやSNSで頂くことがある。</p><p>多くの方が魂のこもった熱いメッセージをくださる一方で、中にはこれはちょっと自分のプロフィールをちゃんと見ていただけてないのかなと思うものもある。ちゃんと時間をかけて書いてくれたものはちゃんと読みたいし、コピペでささっと作られたものに時間を取られたくないので、7年くらいまえからやってることがある。</p><h1 id="h261dc0774d">「スカウトメッセージにはあなたの好きな焼き鳥の部位を書いてください」</h1><p>今のところWantedlyのプロフィールの下の方とGitHubのユーザーページに、上記のテキストが置いてある。私のプロフィールをある程度隅々まで読んだ上で書かれたメッセージには、その人の焼き鳥の好みが書かれている。逆にコピペで量産されたテキストや、サマリだけみて書かれたメッセージには、焼き鳥が書かれていない。冒頭に焼き鳥の好みが書いてあれば最後まで目を通すようにしている(できればちゃんとお返事をかけると良いのだが)。</p><p>意外とフィルターとしての性能は高いし、その後カジュアル面談の機会を得たときもアイスブレイク的に触れて頂くこともある。</p><p>思えば現職、前職、前々職とファーストコンタクトには焼き鳥が書いてあったし、クックパッドに入ったときの最初の面談のときはオフィスのキッチンラウンジで焼き鳥丼が振る舞われて面白かった。</p><p>というわけで、プロフィール情報にそういうトラップを仕掛けておくのは結構おすすめ。スカウト送る側の人は隅々までプロフィール見るようにしよう。</p><p>ちなみに、採用担当者の間で人気が高いのは、かわと砂肝のようだ。</p>

真摯なスカウトメッセージに真摯に対応するために焼き鳥を仕込む

<p>オフィスの同じ空間で顔を合わせて仕事をするのと比べて、リモートワーク環境ではコミュニケーションが希薄になりがちだ。</p><p>オフィスに集まって働くチームのコミュニケーションには2種類ある。双方の意思によって行われるものと、特に意図せず醸し出された情報を特に意図せず感じ取るものだ。私は前者をアクティブ、後者をパッシブなコミュニケーションと呼んでいる。アクティブなコミュニケーションはイメージしやすく、口頭での会話やチャットのやり取りがそれにあたる。ではパッシブなコミュニケーションとは何なのか。</p><h1 id="hf93255a204">パッシブなコミュニケーション</h1><p>それは、例えば以下のようなものである。</p><ul><li>ある同僚の顔色や声色から、なんとなくその日の体調がわかる</li><li>ある同僚が考え事をしている時間が多くて、壁打ち相手になったほうがよさそうに感じる</li><li>ある同僚が息抜きにコーヒーを飲んでいて、今なら話しかけても大丈夫そうと思える</li></ul><p>一言で抽象化するなら「その人の挙動や雰囲気から周囲に届く情報」だろうか。パンデミックを機にリモートワークとなった人は、過去にオフィスで働いていたときのことを思い返すと、そういった雰囲気から多くの情報を得ながら働いていたのではないか。</p><p>では、リモートワークにおいてはどうか。これらのパッシブなコミュニケーションは、オフィスに集まって働いていたときには無意識に成り立っていたはずだ。一方でチャット中心のリモートワークでは、これらのパッシブなコミュニケーションから本来得られる情報は殆ど失われてしまう。</p><h1 id="h53ec214bff">リモートワークに必要な覚悟</h1><h2 id="h158bed0ffa">失われたパッシブなコミュニケーションをアクティブなコミュニケーションで補う</h2><p>オフィス空間に自然に存在していたパッシブなコミュニケーションによる情報伝達が失われたリモートワークにおいては、その重要さを理解し、アクティブなコミュニケーションによってそれを補う努力をする必要がある。その<strong>覚悟を持たずにリモートワークをするというのは、「単に自分にとって快適な環境に居て、コミュニケーションのクオリティは下がっただけの人」になるということ</strong>である。「通勤時間がなくなって嬉しい」みたいな理由でリモート環境を選択している人はそうなっていないか振り返ってほしい。アクティブなコミュニケーションでさえもリモートワークにおいてその難しさは増し、例えばチャットに書く文章は解釈が一意になるよう推敲したり、相手の文章から正しく意図を汲み取ることに気をつけたりする必要がある。さらにそこに加えて、失われたパッシブなコミュニケーションを補って初めて、「オフィスに集まって仕事をするのと同じ水準のコミュニケーション」を目指せるのだ。</p><p>オフィス空間におけるパッシブなコミュニケーションは、直接的に業務に関わることだけではなく、例えば服装や持ち物、仕事で使う機材などからその人の趣味や嗜好などを感じることができ、それはチームビルディングや新メンバーのオンボーディングの過程で役に立ってきた。一方でリモート環境に新しく参画したメンバーが半年経っても同僚の深い人となりをあんまりわかっていない、みたいな状況も珍しくないだろう。これもまた、本人と周囲の両方が意識的にパッシブなコミュニケーションの欠損を埋める努力をしないと、チームのモメンタムが上がらない大きな要因になりうる。</p><h2 id="h3ccf31693b">どうすればいいのか</h2><p>「失われたパッシブなコミュニケーションをアクティブなコミュニケーションで補う」とは、具体的にどのような行動を指すのか。シンプルに表現すると、「適切な自己開示」と「他人に興味を持つこと」であると言える。</p><p>適切な自己開示とは、パッシブなコミュニケーションにおいては自身から無意識に醸し出され、周囲がそれを読み取っていたような情報を、自ら意識的に発するということである。いわゆる分報のような場所を使ってもいいし、チームのチャンネルを使ってもいいと思う。パッシブなコミュニケーションひとつひとつの情報量はそれほど多くない。上でパッシブなコミュニケーションの例として挙げたものをチャットでの自己開示で補うとしたら、「朝から腹痛い」「うーん」「コーヒー休憩」で十分なこともあるだろう。</p><p>他人に興味を持つとは、他人の自己開示に意識を向けそこから情報を得るということである。また、ただ受け取るだけではなく、適切にレスポンスを返すことで、アクティブなコミュニケーションに活力をもたらし、ひいてはチーム全体のモメンタムを高めることに繋がる。同僚の分報に参加するとか、いろんなチームのチャンネルに参加してみるとか、そういうアンテナを広く張ることが他人に興味を持つ第一歩となる。</p><h1 id="h6603b519b0">才能</h1><p>ここまで読んで、「なんだその程度のことか」と感じたあなたには、リモートワークの才能があります。引き続きコミュニケーション水準を高く保ち、チームのモメンタムを高めていってください。</p>

リモートワークに必要な覚悟あるいは才能

<p>特にそうしたかった強い理由があるわけではない。普段iOSアプリばかり開発していて全然違うことに取り組むことでリフレッシュしたかったのもあるし、30歳になってもうちょっと外から見えるアウトプットをしたいと思ったときに未熟な20代の頃の記事と地続きにやっていく気になれなかったから、というのもある。</p><h1 id="hb5da74b317">技術面について</h1><p>Next.jsもVercelも初めて触ったし、ヘッドレスCMSもJamstackも初めてどういうものか理解した。</p><p>Next.jsについてはコンポーネントを分割して他のファイルから呼び出すやり方がわかった程度で、あとは先人の記事とChatGPTの助けによって形にした感じ。</p><p>このブログは、microCMSが公開している以下の記事をほぼなぞって完成した。</p><div class="iframely-embed"><div class="iframely-responsive" style="padding-bottom: 52.5%; padding-top: 120px;"><a href="https://blog.microcms.io/microcms-next-jamstack-blog/" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fblog.microcms.io%2Fmicrocms-next-jamstack-blog%2F&amp;key=c271a3ec77ff4aa44d5948170dd74161"></a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script><p>Webフロントエンド技術には昔から苦手意識があり(ビルドしてページを表示するまでの登場人物が多いこととか)、教養として最低限触っておきたい気持ちはずっと持っていたものの、楽しいと思える手前で挫折してきた。ブログをプラットフォームに頼らず自前で作る醍醐味といえば自分の好み通りにカスタムできることだが、果たして自分がそういう楽しみ方をしていくのかはわからない。</p><h1 id="hb72367fcbf">ブログについて</h1><p>従前ははてなブログを使っていたが、最近は数年おきに転職エントリが上がるだけになっていて、最近になってそもそもブログを書く目的が存在しなかったことに気づいた。役に立つ技術記事を書く意欲があったわけでもなく、自分の日常を知ってほしいわけでもない。眼前にある更新頻度も質も低い旧ブログから、例えばnoteに移行するとか、mediumに移行して英語で技術記事を書くとか、そういう選択肢もフワフワと存在していたものの、何のために移行するのか、移行先で何のためにブログを書くのかが何もないままなので何も決まらずにいた。</p><p>ブログプラットフォームを抜け出して自前で構築することはそのプラットフォームがもたらす集客効果の恩恵を手放すことを意味するが、そもそもそういうオーガニックな流入がドカンと来るような色のコンテンツなんだっけと思ったとき、別にいらんのかもしれん。検索やプラットフォームからの流入を無視して、「僕自身のことを知るために見に来る」みたいな人に自分がどういう人間なのかを伝える材料としてブログを書いていけたらいいのかなーとなった。例えば転職活動のレジュメに添えるとか。</p>

Next.js+Vercel+microCMSでブログを構築したことについて

<h1 id="ha879678dfe">見出し1</h1><p>ああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああ</p><h2 id="had7ce3f1cb">見出し2</h2><p>あ</p><p>あ</p><p>あ<br>改行</p><h3 id="h594976e74f">見出し3</h3><p><strong>太字</strong></p><p><em>斜体</em></p><h4 id="h88e8c523a3">見出し4</h4><h5 id="h169558c650">見出し5</h5><p><a href="https://x.com/hiragram" target="_blank" rel="noopener noreferrer nofollow">リンクテキスト</a></p><ul><li>リスト要素1</li><li>リスト要素2</li><li>リスト要素3<ul><li>ネストした要素<ul><li>ネストした要素2</li></ul></li></ul></li><li>リスト要素4</li></ul><p>こんにちは。</p><p>インラインコード <code>Hello world</code></p><p>画像の挿入も確認</p><figure><img src="https://images.microcms-assets.io/assets/3658e6a7fd3846aea91d64840f897fe0/fc586ce76cd148ce90144276edf5c5ed/image.png" alt="" width="460" height="460"></figure><pre><code class="language-swift">let aaa = &quot;Hoge&quot;
print(aaa)</code></pre>

Posts rss_feed