<p>2025年3月、社内で「AIエージェントによるコーディング体験ハンズオン」を開催した。この記事ではその取り組み内容や参加者の成果、そこから見えた可能性や課題について紹介する。</p><hr><h2 id="h50bae57383">きっかけと背景</h2><p>社内のエンジニアMTGで、筆者が個人開発でAIエージェント（対話型AI）を使ってコーディングしている体験を紹介したところ、何名かが興味を持ってくれた。「実際に触ってみる場をつくろう」とハンズオンを企画することになった。</p><p>Slackで声をかけたところ、エンジニア以外の職種も含め7名が参加してくれた。</p><hr><h2 id="h18f61bea19">題材アプリ「オキッパ」について</h2><p>今回のハンズオンでは、「空いている物置きをシェアできるサービス」を想定したWebアプリ「オキッパ」を題材に使用した。</p><p>オキッパは、近隣住民同士が使っていない物置スペースを貸し借りできるCtoCのシェアリングサービス。ユーザーはスペースを探して予約・利用でき、貸し手は物置の空き時間を有効活用できる。</p><p>このサービスを簡易的に再現するアプリをNext.jsとSQLiteで構築し、各参加者はこれをベースにAIと一緒に機能開発を行った。</p><figure><img src="https://images.microcms-assets.io/assets/3658e6a7fd3846aea91d64840f897fe0/4e9967d8c5d744e29f6721f96f87a8a7/okippa_top.png?w=1310&amp;h=800" alt="" width="1310" height="800"><figcaption>オキッパのトップページ</figcaption></figure><figure><img src="https://images.microcms-assets.io/assets/3658e6a7fd3846aea91d64840f897fe0/8e8c5eb0fe69476dbca383da17d06b7e/okippa_sample.png?w=1154&amp;h=800" alt="" width="1154" height="800"><figcaption>レンタルスペース詳細画面</figcaption></figure><hr><h2 id="he582e81e16">ハンズオンの設計</h2><ul><li><strong>AIとのインターフェース:</strong> VSCode + <a href="https://cline.dev/" target="_blank" rel="noopener noreferrer nofollow">Cline</a></li><li><strong>利用モデル:</strong> Claude 3.7 Sonnet</li><li><strong>初期コードと手順書:</strong> <ul><li>コード: <a href="https://github.com/hiragram/okippa">https://github.com/hiragram/okippa</a></li><li>手順書: <a href="https://github.com/hiragram/ai-coding-hands-on">https://github.com/hiragram/ai-coding-hands-on</a></li><li>brewとnodeが入ってるエンジニアのMacだったら手順書通りに進めればすぐ取りかかれるはず。</li></ul></li></ul><p>エンジニアではない参加者もいたため、環境構築は画面共有で一緒に進めた。</p><hr><h2 id="hf4a13f4798">ハンズオンの進め方</h2><p>以下のようなお題を用意した：</p><ul><li>トップページのデザインを変えてみる</li><li>未完成機能の続きを実装させる</li><li>オーナーへの問い合わせ機能</li><li>予約機能</li><li>独自の新機能アイデアを実装してみる</li></ul><p>基本的には自由課題に近い形式で、AIに指示を出しながらそれぞれが取り組んだ。</p><hr><h2 id="h783eef3273">成果と作品例（一部紹介）</h2><p>参加者がAIと協力して開発した成果の一部を紹介する：</p><ul><li><strong>チャットボット風問い合わせ機能</strong></li><li><strong>予約可能日をカレンダー表示</strong></li><li><strong>ブランドカラー反映 + UI改善</strong></li><li><strong>フィルタ付きトップページ</strong></li><li><strong>キャンセル待ち機能</strong></li><li><strong>口コミ投稿 + トップページ表示</strong></li></ul><p>いずれもAIエージェントとの対話を通じて実装されたもので、短時間ながらしっかり動作するレベルのアウトプットが得られた。</p><hr><h2 id="h464750115b">苦労した点と反省</h2><p>特に苦戦したのは環境構築だった。</p><p>エンジニアにとっては当たり前のHomebrewやNode.jsも、他職種にとっては高いハードル。AppleScriptでサーバー起動を自動化しようとしたものの、セキュリティ機構に阻まれてうまくいかなかった。</p><p>AIを活用したDB初期化も完璧とはいかず、AIが「完了した」と返してもアプリが動かないトラブルも発生。今後の課題としたい。</p><hr><h2 id="h6f2d4aab10">参加者の声（要約）</h2><ul><li>テストの補完や小さな修正にはすぐ使えそう</li><li>複雑なUI改善もプロトタイピングとして試せる</li><li>デザイナー視点でも使い道が見えた</li><li>ただしレビューが必要な部分にはまだ不安も</li></ul><hr><h2 id="h9be0c3393d">おわりに</h2><p>正直なところ、開催にはかなりの準備時間とコストがかかった。トークン代・休日稼働を含めて筆者の持ち出しもあったが、それでも得られる気づきや知見は大きかった。</p><p>このような社内でのナレッジ共有・実験的な取り組みがもっと広がっていくと良いなと思う。</p><hr><p>📚 <strong>関連リポジトリ:</strong></p><ul><li>コード: <a href="https://github.com/hiragram/okippa">https://github.com/hiragram/okippa</a></li><li>手順書: <a href="https://github.com/hiragram/ai-coding-hands-on">https://github.com/hiragram/ai-coding-hands-on</a></li></ul>

ClineでWebアプリを開発するハンズオンを開催した(コンテンツも公開)

<h2 id="h8d027c8ed3">はじめに</h2><p>最近、エンジニア以外の職種でもAIを活用する動きが社内で加速している。企画、マーケ、カスタマーサポートなど、これまであまり技術に関与してこなかったメンバーがAIツールを使って、情報の整理や文章作成、アイデア出しなどに取り組むようになってきた。</p><p>これはとても良い流れだと思う。一方で、<strong>AIとの向き合い方や、AIが生成した情報をどう扱うかについて、よく考察された共通認識がないまま進んでいることに危うさも感じている</strong>。</p><p>この記事では、実際の業務の中で感じた違和感や課題をもとに、「これからのAI時代に必要なコミュニケーションの基本姿勢」について考えてみたい。</p><hr><h2 id="hec50fb5a92">自分で判断できないことをAIに委ねない</h2><p>AIが出した情報に対して、自分で正否や適切さを判断できないまま、それを業務に使おうとするのはとても危険だ。<strong>その情報の正しさを評価できない状態でアウトプットしていることになるから</strong>。</p><p>たとえば、医療の専門知識がない人がAIを使って病状に関する説明文を書いたり、法律の知識がないままAIに契約文書を作らせたりするようなケースがある。AIの出力がもっともらしく見えても、自分で判断できない分野でそのまま使うのは非常にリスクが高い。</p><p>だからこそ、AIを使うときには次のような基本姿勢が求められる：</p><ul><li>出力内容の意味を自分で理解し、評価する</li><li>そのまま使うのではなく、自分の責任で修正・検証する</li><li>自分で判断できない領域では、自分がAIを扱うのではなく、最初から専門家に頼むことを検討する</li></ul><p>専門家の力を借りるというのはもちろん正しい。でも、「わからない人がAIに書かせたものを専門家にレビューしてもらう」という形になると、その専門家にとっては手間が増えているだけの可能性がある。</p><p>それなら最初からAIを挟まず、その人に直接依頼するべきで、AIを使うかどうかは専門家自身が判断すればいい。依頼する側が気を利かせたつもりでAIを噛ませることが、かえってマイナスになることもある。</p><hr><h2 id="h1ebe94e97c">個人の生産性向上が他人の負荷になっていないか？</h2><p>「AIで生産性を上げましょう」という言葉はよく聞くし、実際その通りだと思う場面もある。だが、<strong>アウトプットの検証や最終確認を他の誰かに丸投げしていないか？</strong> という視点は常に持っていたい。</p><p>たとえば、エンジニア以外の職種の人が、技術的な文脈を含むお知らせや説明文をAIで作成するようなケース。内容はそれっぽく見えるかもしれないが、技術的に正しいかどうか、適切な用語や構成になっているかを判断するのは簡単ではない。</p><p>結果として、エンジニアに「技術的に問題ないか見てほしい」とチェックを依頼することになり、<strong>作成者の作業は効率化されたかもしれないが、エンジニアの作業量が増えている</strong>ということになる。</p><p>つまり、「個人の生産性向上」の裏で、<strong>組織全体の工数はむしろ増えている</strong>という逆転現象が起きる可能性もあるということ。</p><hr><h2 id="habff825909">AIが生成したものだろうが他者に提供する時点で自分の責任</h2><p>最近では、会議の議題や議事録の作成にAIを活用する例も増えてきた。それ自体は便利なことだけど、そこで注意すべき点がある。</p><p>まず、議題や提案がAIによって生成された場合：</p><ul><li>その内容は「誰の意見」なのか？</li><li>AIの提案に、どれだけ自分が賛同しているのか？</li><li>議論をどう進めたいと思っているのか？</li></ul><p>こういったことを明示しないと、<strong>対話の出発点が曖昧になり、議論の軸が定まらない</strong>。</p><p>また、AIが作成した議事録や要約をそのまま提出する場面でも同様だ。<strong>「AIが書いたから自分は責任を負わない」という態度ではなく、“自分の提出物”として出す以上は、その内容に責任を持つべき</strong>だと思う。</p><p>もちろん、皆が皆、無責任にAIを使っているわけではない。ただ、AIの出力との向き合い方や、その扱いに対する意識の濃淡には大きな個人差があるのも事実だ。</p><p>無闇に疑ってかかりたいわけではないので、AIの出力を活用する側として、「この出力はどのような立場から提示されているか」「自分の意見が含まれているかどうか」をあらかじめ開示してくれると、とても助かる。</p><p>たとえば、</p><ul><li>「AIに聞いたらこう言われて、私も同じ意見です」</li><li>「よくわからないのでAIに聞きました。自分の意見は特にありません」</li></ul><p>このどちらかを明示してくれるだけで、議論の進めやすさは大きく変わってくる。</p><hr><h2 id="h9be0c3393d">おわりに</h2><p>AIの活用はこれからも加速していく。それは歓迎すべきことだと思う。ただし、<strong>AIを正しく活用するためには、それにふさわしいリテラシーと姿勢が必要になる</strong>。</p><ul><li>自分で判断できる範囲で使う</li><li>他人に丸投げしない</li><li>AIの出力を使うなら、自分の言葉として引き取る</li></ul><p>こういった考え方が、組織の中に自然に浸透していくことを願っている。</p><p>共感してくれる人がいたら、ぜひ一緒に「AI時代の建設的なコミュニケーション」について、考えていけたらうれしい。</p>

AI時代のコミュニケーションに期待する最低限の責任感

<p>最近、CursorやDevinのような、プログラミングにAIの力をもたらすツールが流行している。当初は個人のアーリー層が中心だったが、最近では企業も本格的に取り組み始め、その成果を発表するケースが増えてきた。</p><p style="text-align: start">表題の「必要だった」とは、今もう必要でないということではなく、今の時点でそういうAI活用に取り組めている企業はきっとそうだったのだろう、我々はそうでなかったからそこにいないのだろう、ということ。</p><h2 style="text-align: start" id="h0286df22c2"><strong>金銭コストだけが問題ではない</strong></h2><p style="text-align: start">AIを導入する際、「お金がかかる」という点が話題になりがちだ。確かに金銭コストも重要な要素ではあるが、実はそれだけが障壁ではない。もっと根本的な問題がある。</p><h2 style="text-align: start" id="h7bcaea32a8"><strong>やるべきことを真面目にやっているか</strong></h2><p style="text-align: start">流行りの兆しを見つけて取り組む意欲があったとしても、足元の障壁がバラバラ残っていると、結局トレンドに振り払われてしまう。重要なのは、普段からエンジニアリングのあるべき形を実践しているかどうかだ。例えば:</p><ul><li>リポジトリにDBのパスワードのような秘匿情報をコミットしないを真面目にやっている</li><li>ユニットテストが充実していて、AIが生成したコードの妥当性を自信を持って判断できる</li><li>要件定義やドキュメント化の能力が鍛えられており、AIへの適切な指示やフィードバックができる</li></ul><p style="text-align: start">こうした基本的なことができていないと、AIのような新しい技術をスムーズに導入できる機動性を維持するのは難しい。重要なのは「既存のエンジニアリングがAIを用いた開発に耐えうる構造になっているか」という点だ。</p><p style="text-align: start">急に回ってきた代打で結果を出せるのは、出番がなかったとしても基礎練習を怠らなかった奴だろう。</p><h2 style="text-align: start" id="h3d13520037"><strong>気持ち</strong></h2><p style="text-align: start">エンジニアリングとAIの本質を考える中で、自分が所属する組織を盛り上げて押し上げる行動をもっとしなければならないと感じる点が多々あった。必ずしも潤沢な資金が必要なのではなく、日々より良いエンジニアリングを追求し続けることと、それが当たり前の文化になるような流れを作ることだ。</p><p style="text-align: start">AI時代においても、結局は地に足のついたエンジニアリングがすべての基盤となる。現在地から一歩で理想の状態に到達しようとするとうまくいかない。普段からやるべきことをやっておいて、いざ祭が始まればすぐ参加できるような姿勢を取り続けることが、長期的にはトレンドに乗る最良の方法だと再認識した。</p>

企業におけるエンジニアリングにAIを素早く導入するために必要だった姿勢

<p>今日からFlutterやる。</p><h2 id="h2220f0ef7d">やったこと</h2><p>公式ドキュメントで環境構築して、公式Codelabsの「初めてのFlutterアプリ」を途中までなぞった。</p><p><a href="https://codelabs.developers.google.com/codelabs/flutter-codelab-first?hl=ja#4">https://codelabs.developers.google.com/codelabs/flutter-codelab-first?hl=ja#4</a> この5章まで終わった。</p><figure><img src="https://images.microcms-assets.io/assets/3658e6a7fd3846aea91d64840f897fe0/b097b5e66a3c423280e6a25cb9f0f688/flutter.gif" alt="" width="800" height="666"></figure><h2 id="h5fcec0cf90">所感</h2><p>Codelabsのチュートリアルがわかりやすくて良い。</p><p>コードはパッとみた感じはなんとなく輪郭は頭に入ってくるものの細かい書き味は結構違う印象でまだ全然慣れない。エディタが普段と違うのも大きく影響していそう。</p><p>また気が向いたらやる。</p><h2 id="h84204246f9">作業中のメモ</h2><pre><code class="language-bash">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,&quot;&quot;&quot;これが Flutter の有名なステートフル ホットリロードの動作です&quot;&quot; とのこと&quot;
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,スペーサーの役割をする</code></pre>

Flutter学習day1

<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