リモート前提のまま変わらない組織

サマリ

• コロナ禍、フルリモートへ
• フルリモートでなんとかなった
• オフライン回帰。しかし雇用や制度設計はリモート前提のまま
• フルリモートで出来るようになったこと・出来なくなったことを正しく評価することは難しい
• たとえば、アジャイルの「全員同席」
• 機能的な出来ることと、偶発性で出来ること
• オフライン前提からハイブリッド前提へのシフト。失われた概念

前提

• 色んな状況の企業があると思います
• 実際の世の中の企業のトレンドとはズレがあるかもしれません
• だいぶ、僕個人のバイアスが入ってます
• 働き方の自由さに恩恵受けてる側ではあります
• コロナ禍とかの定義は雑です

コロナ禍、フルリモートへ

コロナ禍、企業はフルリモートを余儀なくされた。
結果的に「フルリモートでもなんとか仕事は進む」事が分かった。

もちろん、その場にいることが重要なエッセンシャルワーカーなど例外はあるが。

ホントにオフライン回帰？

オフライン回帰。しかし雇用や制度設計はリモート前提のままだったりする。
何がフルリモートで始まって、何が終わったか？もはや分からないのではないのだろうか。

正しく評価することは難しい

というのも、コロナ禍は長すぎた。

半年〜1年であれば、単なる「フルリモート検証期間」だったりするかもしれないが
世の中が完全に落ち着くのには2〜3年かかった。

その間に各地方で採用されたメンバーが居たり、人の入れ替わりがあったり、会社事情も変わりゆく。

込み入った状況で、「オンラインかオフラインか」の差分だけではなかなか単純比較できない。制度の是非の判断が難しい。
そしてもはや、リモート前提の制度を崩すわけにはいかなかったりする。整理がつかなくなって外資は解雇したり…厳しい

ハイブリッド前提

オンライン前提、ハイブリッド前提が染み付いたまま、フル出社していた時代が本当に思い出せているだろうか。もう常識は変わってしまっている。
働くメンバーに対して「いつも出社する」「同じ場所に居る」という前提が、以前のようにはいかない。
「この日はみんな、出社しよう！」
わざわざ言わないといけないという、不自然さ。 働き方の自由さとのトレードオフであり、むしろいつも皆居るという、常識がおかしかったのか、わからなくなる。

会社は必ず行く場所ではなくなった。

失われた余白、忘れられたオフライン仕草

会議に関しては、「会議の5分前に入退室」とか当たり前だった概念が失われた気がする。

勤務時間も考えさせられる。通勤時間で勤務時間が減るとか。

今日出社？在宅？人を会社以外で探すことも増えた。入れ違いすれ違い。

出社して会議をしても、みんな結局PC画面を見て会話するとか。前は自然とホワイトボード使ったり一点をみんなで見てたりするかもしれない

リモート前提のまま変わらない組織

そういった状況下、なんだかんだリモート前提のまま変われない組織もあるのではないかと思う。

もしくは、リモート時の制度を全廃してフル出社強制！とか週3出社強制！とか、どちらか極端にするのが、企業方針として一番簡単ではある。

リモートの良さもオフラインの良さもうまくミックスするのが一番難しく、下手すると中途半端な会社・組織になって競争力を失うかもしれない。

とはいえ、急にフル出社！とか言われたらそりや従業員は嫌だよね。

たとえば、アジャイルの「全員同席」

または「チーム全体」
https://www.agile-studio.jp/post/apm-whole-team

なんだかんだBizもDevもOpsも関係者皆が同じ場所に居て喋ってるのが良いんだよなと。

今の時代は前述のとおり「全員同席」の難易度は上がっている。
そこにエネルギーかけずに実現させるのが一番いいんだけども。

かくいう自分も、同じ場所に毎日来てねと言われるともはや嫌だなぁとかあるし

それぞれ忙しいしなぁ。バラバラに動きがち

オンラインに慣れてしまうと、縦割りぽくなりがちで会議の時しか顔を合わせないのよな。
一度、縦割り詰め込みで業務フローを設計してしまうと、なかなか元に戻せない気がしている。

そんな中、「全員同席」の環境をつくったら勝ちみたいなところあるよね。でも望むならそこに労力かけずに自然にそうあってほしい。 このあたり考えると「ゆとりの法則」もう一度読みたくなる。

機能的な出来ることと、偶発性で出来ること

職種にもよるし、会社にもよるし。
一見して、「機能的なことは出来ている」んだと思う。それも分かる。
だから淡々とプログラミングするなら、もしかしたらフルリモートでいいもんね。それで一定の価値は出せる。出せる人いると思う。

でも偶発性の中に、なにか新しいことのヒントがある気がする。なんとなくホワイトボードで設計議論する、アイデアディスカッションする。廊下でたまたま話す。なんでも良い。

そんな、「全員同席」のような偶発性をつくるのは、どうしてもオフラインって感じがする。オンラインでの仕事は増えたけど、「オンラインでの偶発性」なかなか自分は答えが見いだせなかった。それをやろうとしてたブロダクトはたくさんありましたが。

機能性と偶発性の両立を考えたい

自分としては、半端なことを言うんだけど オンラインでも偶発性をつくりたいし オフラインの偶発性の場もつくれればと思う。

機能的な面も維持しつつ。

でもなんだかんだ皆真面目だから機能面はなんとかなるんだろうなとか思いつつ。

【どれ使えば良い？】たくさんの生成AIに囲まれたおれたちは

自分の整理メモです。

簡単にまとめ

• 雑にコード出してほしいならChatGPT
• しっかりめに壁打ちしたいならClaude
• 雑にリサーチしたいならGemini
• しっかりめにリサーチしたいならパープレキシティ

まえおき

AIのトレンドも、「使う」から「任せる」に変わってきている。
またAIそれぞれも専門家、高度化、多様化している。
専ら、最近の話題はAIエージェントなのかなと思ってる。各AIでエージェントモードとか始まり、それがエンジニアの関心になってそう。

あえて何を使うか考える

そんな中、人によって

• 何使ってよいか分からん人
• すべてアーリーアダプターとしてついていってる人
• 名前だけは知ってる人
  など様々だと思う。

今回はあえて「何使ってよいか分からん人」向けに書く。というか、あえて立ち返って使い分けを考える。

あえてね。って言っとけばそれっぽくなるので便利。

雑にコード出してほしいならChatGPT

とにかく適当に投げるときにChatGPTを使う。
大体「こんなこと出来るっけ？」のたたき台のたたき台みたいなものを出してもらうイメージ。
出してもらったら「いやいや、違うがな」「もっとこっちの方がエエな」など、1つ考えが進むので、きっかけとして使っている。
雑でいい場合はそのまま採用することもあるけど、大体プロダクションコードには耐えないレベルだったりする。20年ぐらい前のコードの書き方か？みたいなのとかよくある。

しっかりめに壁打ちしたいならClaude

なんか相談すると「おー、たしかにな」みたいになる。熟考モードとかあるのも良い。 というのも、AIでありながらコンテキストを読むレベルが高いからだと思う。 Claude本人にChatGPTとの比較などしてもらったがコンテキストウィンドウが強みぽかったし、分からないことはキチンと分からないというタイプのAIです。ChatGPTは知ったかです。 課金する価値あると思うけど、無課金でもそれなりにクレジットあるので、使ったことない人は、まあ試してみるのも良いかも。

雑にリサーチしたいならGemini

Geminiなんぼのもんじゃい、と思ってあまり使ってはいないので、ニワカです。
Google検索のプロキシ、ファサードになってくれるようなイメージ。ChatGPTぐらいの賢さなんだが、最新の情報にアクセスできるため「ググっといていい感じに出して」が出来る気はする。

しっかりめにリサーチしたいならパープレキシティ

自分でググる代わりに、パープレキシティを使う。そんな感じ。
整理してくれたうえで、出典となるウェブ記事も分かるため便利。「ん？」って思っても元に当たれるからですね。

しかし、ウェブ記事がなかったりドキュメントないと情報が希薄になる。

そういう意味でブログを書く意味は引き続きあるかなと思ってる。僕は専門性のある記事を書いてパープレキシティの養分になるのも悪くないかなと思う。
結局SEOではなくて、パープレキシティに最適化するだけの話。検索エンジンが担ってたところをパープレキシティが担うだけ。と思ってる。

モデルによって違うよね？

ちなみにここまでの話で、「モデルが違ったら全然話変わってくるやろ」ってツッコミが来そうかなと思います。

ちゃんと理解してる人にとってはそうだと思う。結構僕も浅いし教えてほしい。しかし、大半の人はモデルごとの違いまで説明できなさそう。

まぁそこ踏まえても雑に捉えるとこういう認識で良いのかなと思って書いている。生成AIの設計だったり設計思想、モデルのアップグレードあれど、大きく特性は変わらないのかなと思ってる。

まとめ

• 雑にコード出してほしいならChatGPT
• しっかりめに壁打ちしたいならClaude
• 雑にリサーチしたいならGemini
• しっかりめにリサーチしたいならパープレキシティ
• 検索エンジンではなくて、AIが台頭している。AIが検索エンジンを使っている。AI に最適化する時代
• AI経由で引き続き人は来るし役に立つ。ブログを書く意味は引き続きあるのではないか

仮claspぐらしのアリエッティ

ソフトウェアエンジニアをやめると生息するコードベースがなくなる

マーケター専任の形になって、コードベースがないのが地味に困る。
いままではプロダクトを在りどころとし、toolも自由につくれる、インフラもある(もちろん予算の中で)。 開発者体験だなんだというが、確かに開発者の特権的な部分だろうなと思う。

自分が使えても他の人が使えるとは限らない

色々考えるとcliとか作ったりバッチつくったりサーバー作ったりした方が再利用性が高かったり 拡張しやすかったりするんだろうけど
使うのは同じプログラマやソフトウェアエンジニアではなく、マーケターなどビジネスサイド。 と、考えるとGUIが必須。cliやバッチ、APIなどはメンテナンスや単純な活用も含めて現実的ではない。 そうすると自然とGASに行き着いた。

オレオレマクロ、属人化。ウッ頭が

ただし、これは古のエクセル、VBA、オレオレマクロと同じ末路をたどりかねない。 なので、GASでありながらいかにメンテナンス性を持たせるか、自分に属人化しないようにするか。

…など考えつつも、業務は思った以上に煩雑であり、要求されることも多いので ウダウダ言ってもいられず、業務効率化が急務みたいな感覚になる。

GASはエディタが辛い

GASはそのままAppScriptのエディタを使うと辛い。 とりあえずclaspを使いスプレッドシートにコードベースをpush出来るようにした。 VSCodeやVimなどお好みのものを使えるため快適な生活を迎えることができた。

https://github.com/google/clasp

GASでnode moduleがガンガン動くわけではない

例えば、zodでも入れてやるか〜とか思ったわけですが
https://github.com/colinhacks/zod

結局buildして、GASへコードをバンドルするようなかたち。というかGASにライブラリがインライン化される感じになるので めちゃくちゃ見通しが悪くなってツラい。minifyすればいいけどさ、、、読めんないしな zodは便利だけどやりたいことに対してtoo matchだし、やはり可読性が著しくひどくなってしまうのであまりライブラリは使わないことにした。 nodeなどで動くランタイム前提だと良いのだが、GASというエンジンにdeployされることを想定すると ある程度GAS化された後のコードも見やすいようにはしておきたいという判断。

GASはそこそこテストがしにくい

ちゃんとテストを書こうとか思うわけですが
SpreadSheetオブジェクトみたいなものがGASには存在して、それをmockしないとunitテストが出来ない。
結局末端のロジックはテストできるが、主要な部分はそういったグローバルなオブジェクト任せではあるため エンドtoエンドなテストはなかなか厳しいなというところは思う。
なんかローカルでGASが動くみたいなものがあったのでそれでもしかしたら画面の自動テストみたいなことも出来るのかもしれない。 そこまでは出来ていない。

ツールをつくればつくるほど、個別最適をやっている気分

ある種、業務上こぼれ落ちたものを効率化しており。
これは本来はシステム側で吸収する部分、システム間のインテグレーションの不充分を人類が頑張っているということなのだなと思う。

「自動化した！」と思っても立場を変え、視野を変えるとツナギが無い、なんてことは多々あるのではないでしょうか。 あなたの自動化はどこからどこまで？

というのを改めて思う。開発チームが見えている視野での自動化は実は不充分かもしれない。

よしなにやっています。

TypeScript + clasp + esbuildみたいな構成

文字ばっかりだったので、気安めにコードじゃないですがディレクトリ構成みたいなの貼っておきます。 細かい話は別途気が乗ったらしてみようと思いますが 要するにこの記事のようなことをやっています。

https://zenn.dev/funteractiveinc/articles/776b5812833475

├── .clasp.json
├── .clasp.ignore
├── appsscript.json
├── esbuild.js
├── jest.config.mjs
├── package-lock.json
├── package.json
├── node_modules
├── src
│   ├── helper
│   │   ├── hoge.ts
│   │   ├── fuga.ts
│   │   └── piyo.ts
│   ├── job
│   │   └── job1.ts
│   │   └── job2.ts
│   │   └── job3.ts
│   ├── test
│   │   ├── hoge.test.ts
│   │   ├── fuga.test.ts
│   │   ├── piyo.test.ts
│   └── types.ts
└── tsconfig.json

ケント・ベックは水を飲む

私がペアを組むときには、近くに水のボトルを置いている。
健康にも良いし、休憩をとることを忘れなくなる。
― ケント・ベック
（エクストリームプログラミングより）

まえがき

ケント・ベックは水を飲む。

上記はエクストリームプログラミングの白本と呼ばれるものからの引用です。

あえて、ペアプロのトピックでこの一文を入れていたのが気になっていた。
ケント・ベックはなぜこれを書いたのだろうか？

労働に大事なのは休憩

ペアプロはとにかく疲れるというのは古事記にも書かれている。それ以外の仕事全般も同様に疲れる。 https://gist.github.com/j5ik2o/2970973

共通しているのは、定期的に休憩が必要ということ。

水を適度に飲んでいると、こまめにトイレに行くことになる。

それが休憩の合図になるということだ。

ついつい、過集中したり深追いしそうなとき 歯止めをかけてくれるのは生理現象という真実…！

水分補給は健康に大事

こまめにトイレに行くのが面倒だからと 水分補給をサボるのは止めたほうが良い。

僕はそれで体調を崩した。病気のリスクの一つには、水分不足と休憩不足がある。

このリスクは僕に限らず、デスクワーカーすべてに関わる話だ。

水分を取ることと、長時間同じ姿勢でいないこと。これはデスクワーカーの生活習慣から健康を守るカギとなる。

▼座り続けるリスクについて。日本人は座りすぎている https://www.mhlw.go.jp/content/000656521.pdf

▼中年期の水分補給不足で早期死亡リスク増 https://pubmed.ncbi.nlm.nih.gov/36599719/

つまりケント・ベックは健康で仕事がうまい

休憩の大事さ、水分補給の大事さを理解して書籍にまで反映してるケント・ベックは偉い。

その結果、現在もバリバリ働いているわけだからなおさら説得力がある。
エクストリームプログラミングだって20年近く前でしょう？

健康の秘訣ですね。

まとめ

ケント・ベックは水を飲む。

みんなも、健康と仕事バリバリのために水を飲みましょう！ 元気があればなんでも出来る！

質問も意見も必要ない

例えば、勉強会で発表する時。 逆に定例ミーティングなどで聞く側に回るとき。 あると思います。

そういうときの、「話し手」「聞き手」としてのスタンスの話です。

なにか質問や意見などありますか？

なにか話があり、提案、方針の共有などの発表があったとする。

そういった場合、話の終わりで咄嗟に出る「なにか質問や意見などありますか？」みたいな、なんとなくお決まりのフレーズが来る。

特に思いつかないなぁ。。

この時、聞き手は「質問も意見もないなぁ」と特に発言しない人が多いのではないかと思う。

持論としては、正直言うと、質問も意見も要らない。あったらもちろん良いけど、無くても成立するんではないかという話。

いきなり質問なんて出来ないよ

そんないきなり発表を聞いて、良い質問が出来る聞き手は少ない。

• そもそもその話をだいぶ理解しているか
• すごい質問力のある人か

のいずれかしかいない。

そうなると「理解できる人と質問力のある人だけの場」になってしまう。それは発表者としても本意ではないと思う。

いきなり意見なんて出ないよ

同様に、いきなり発表を聞いて、良い意見が出来る聞き手は少ない。

• そもそもその話をだいぶ理解しているか
• すごい傾聴力のある人、発信力のある人

のいずれかしかいない。
そうなると「理解出来る人と傾聴力・発信力のある人だけの場」になってしまう。それは発表者としても本意ではないと思う。

xxxさん、何かコメントありますか？

上記も踏まえ、話す側は「何かコメントありますか？」ぐらいでいいと思う。話をby nameで振るぐらいにする。とりあえず話してもらう。

そうしてるうちに「他にコメントある人いますか」と他の人も話しやすくなるかも。

そうこうしてるうちに、もしかしたら質問も出てくるかも。ぐらいの気持ち。

まずはリアクションやフィードバックが欲しいと思うので、別に何か反応もらえればまずはそれで良いはずよね。

意見とか質問とかじゃないんですが、、感想は

聞き手側は、質問や意見じゃなくて感想を言えばよいと思う。もちろん、意見や質問があるときはムリして感想を入れなくて良い。

でも突然振られたとか、誰も反応がないときとかは、ぜひ何か話した内容について感想を伝えてみて欲しい。

「意見とか質問とかじゃないんですが、、感想は、、、」という、切り出し方で良いと思う。
感想だけで充分フィードバックになるし、話が広がるきっかけになったり、皆が一旦おちついてその事柄を集中する時間が出来る。

「質問あります？」「ないでーす！」← これが一番意味ない

「質問無いでーす！」ほど意味のない会話もないだろう。

流すぐらいなら、「面白くないし、この話やる意義があまりないよ」など率直に意見してあげたほうがマシのような気もする。

まとめ

• 無理に質問も意見もしなくて良い。感想でも良い
• 話し手は、とりあえず「言葉を発してもらい」フィードバックを得るところから
• 受け手は、感想レベルでも言ってみるところから
• 良い発表は、内容に質問するスキがあったり
• 発表の中で質問の機会を自然に得られるみたいなとこもある

ソフトウェアエンジニアやめました

タイトルは釣りではありません。 仕事上、2025年からソフトウェアエンジニアではなくなりました。

どういうこと？

マーケティング部署に所属し、主にBtoBマーケティングをやっています。営業にどうつなぐかととかも考えたりしてます。

未だに気持ちとしては、プログラマの心もある。
必要であればSQL書くし、サクッとラクできそうならGASでも書くかーってなるし、アラートとか出たらなんとなくエラーログ読んで当たりつけるし、めんどくさくなってコード読んで自己解決とかもする。

なんでソフトウェアエンジニアやめたの？

そんなにやめるつもりも元々はなかった。

めちゃ端折って簡単に言うと、「プロダクトのドメイン知識を得るためにマーケターになるのが良いと思った」ので、マーケと開発の兼務をこれまでやっていた。俺がDDDや。 ※過去にnoteに書いたりしてた https://note.com/yy_yank/n/n664b0de1268b

その後、色々なんやかんやあり、事業として一番自分が貢献できるのがこのかたちなんじゃないかという着地になった。

このサービス、プロダクトに力を入れたいって時にプログラミングにこだわる必要ないよな？みたいなのが元々あったかもしれない。

プログラミングで天地ひっくり返すほどの成果が出せなかったので、実力不足でもある。

そんなコンバートあるもんなん？

今の役目がどれぐらい続くかも分からない。
別に開発にいつでも戻れる〜みたいな逃げ道がつくりたいわけでもないし、現状のチャンスに真面目に取り組みたい。

「ソフトウェアエンジニアとして見られない」というのは、自分にとってバスケやってたやつが急に相撲やり始めたみたいなもんであり
それなりに真価を問われているというプレッシャーもある。プレッシャーというか責任的な。

思い切りましたね？

そうっすね。割と今までの経験とか捨てるんか？みたいな怖さはあるのかもしれない。
まぁでもそんなのちっぽけな話だな、などと思って、それよりやってみたほうがおもろいやん、が勝ってしまった。

あとsongmuさんのこの記事とか読んで数センチぐらい後押しされた。感謝感謝。
https://songmu.jp/riji/entry/2024-11-25-software-engineer-as-a-career-option.html

どうすんのこのブログ？

本当はnoteとかに感動的なポエム書いて注目を浴びてガハハという展開も考えたんですが

結局、このブログが気持ち悪いというか。
立ち位置よくわからなくなるし、このブログに最近のこの異動のことを書いたほうが良い気がしたのでした。

結論、このブログは続けようと思います。
プログラマ向けに、今のポジションだからこそ見えるところもあるので、その視点で書いてみようかなと。ソフトスキル寄りかも。
あと、ピュアに純粋に趣味で技術を追ったりとかプログラミングしたりは出来るはずなのでそのあたり。

知識のアップデートせずに古い技術とかであぐらかいてるオジサンにはなりたくないなというところでもあります。ある程度役に立つものだったりとか、自分の完全な趣味とか、鮮度のあるものとかを今後もお送りできればと思う次第です。

まとめ

近況報告 & このブログのスタンスについてでした！

よりエモいキャリアがどうだ〜、とか事業がどうだ〜とかはそういう気分になったらnoteでも書こうかなと思います。

Pixel Watch 3を買った

新年、皆さんいかがお過ごしですか？
僕は仕事がバタバタしすぎて虚無になっています。

ところで11月ぐらいにPixelWatchを買っていたので、今回はその感想を書こうと思います。

買ったもの

• Google Pixel Watch 3
• 59800円

スマホもPixelで、色々そっちの寄せた方が親和性はあるんだろうなと思って買った。
体調大事だなとデバイスで測りたかったというのもある。

まちがえてディグダを貼ってしまいました
こっちがホントの my new gear... pic.twitter.com/3NR8SQr8db

— やんく (@yy_yank) November 6, 2024

メリット

• 自分の心拍数が分かる
• 睡眠が測れる
• 思ったよりも睡眠時間を確保できてないことに気づく
• 案外つけたまま眠れる
• 歩数も測れる
• 電話着信などの通知に時計で気づける
• 時計からスマホを探せる

自分は「寝るとき時計なんかつけらんないよ！ムリムリ〜！」と思ってたけど案外イケた。
そして、つけてみると案外寝れて無くてびっくり。 就寝時間と、実際の睡眠時間は異なるのだなぁ。

正確な歩数が出るのも嬉しい。

あと、地味に「スマホを見つけられる」のが助かってる。
前まで、半ギレで「俺のスマホどこ〜？？」とGoogleスピーカーに文句言ってたので、それより大分ラクで助かる。

デメリット

• それなりに値段が高い
• つけたり外したりめんどい
• 逆に通知に気づきすぎる
• 充電がダルい

まあ高い。そして付け外しが面倒。時計だからそりゃそう。
あと通知全てに気づく。それがストレスな人は通知設定を減らしたほうが良さそう。電話気づけるのは助かるんだけどね〜。

充電はtypecではあるのだが、丸っこい聴診器みたいなやつを時計にくっつけないと出来ない。
そのケーブル探すのとか、電池管理とか地味にめんどい。

スマホすらまともに充電しない民の僕としては、管理が増えてしまった。
充分長持ちするんですけどね！

初めに買うにはFitbitの時計とかのほうが良いかも

僕は大外ししたくないので、少々高いけど Pixel Watch 3にした。
でも試しに買うならfitbit senseやfitbit versaあたりでも充分な気もする。
求める機能性、デザイン性、ブランドなどで各自決めれば良いかなと思います！

まとめ

Google Pixel Watch 3買ってみたよという話でした！
気になってる方のご参考になれば幸い！