そこで、まるっと削除を行う次のようなPowerShellスクリプトをこさえました。
git branch -v | Select-String "\[gone\]" | % {$_ -split " +"} | Select-String "feature|fix|hotfix" | % {git branch -D $_}
要するに [gone] のブランチのうち、 feature, fix, hotfix を含んでいるブランチを git branch -D で消すという操作です。
Linux環境でも似たようなスクリプトを使っていたのですが、Windowsだとgrepすら無くて調べるのに時間を要してしまいました。
今の所結構快適に動いてくれていて、手元のブランチもスッキリして良い感じです。
次は、ブログのエンジンをHugoに移そうと考えているので、そのあたりの作業ができたらまとめたいと思っています。
]]>具体的には、ビルドする際に WoerkerExtensions.csproj が見つからないといったエラーが出る場合の対処法になる。
ソリューションをクリーンしても、リビルドしても、システムを再起動しても解決しないこの現象は、複数のソリューションやプロジェクトを行き来する中で、NuGetで取得して使っている共通名称のパッケージを削除したような場合に発生していると思われます。
この現象に遭遇した場合、NuGetのキャッシュを削除することで対処します。
具体的には
少なくとも、私の環境では上記手順で問題を解決することができました。
]]>次のコマンドでMicrosoftの署名キーを信頼し、dotnetの関連パッケージをAPT経由で取得できるようにパッケージリポジトリの追加を行う。
cd /tmp # 適当な作業フォルダで作業すると良い
wget https://packages.microsoft.com/config/ubuntu/20.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb # パッケージ取得
sudo dpkg -i packages-microsoft-prod.deb # インストール
rm packages-microsoft-prod.deb # 後始末
記事執筆時点では.NET6がLTSで利用できるので、次のコマンドで.NET6の開発環境をインストールする。
開発についてはSDKがあれば十分だと思う。
もしランタイムが必要な場合は、記事末尾の参考リンクにある情報に従って、ASP.NET Coreサポートのあるなしで、自身の環境に適した方をインストールすると良い。
sudo apt-get update; \
sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y dotnet-sdk-6.0
インストールが完了したら、インストールされた.NETのバージョンを確認しておく。
dotnet --version
Ubuntuで
cargo install cargo-edit
した時に、 No package 'openssl' エラーになったら
sudo apt-get install libssl-dev
することで解決できる。ちなみに、 pkg-config パッケージも必要なようなので、不足している場合は同時に apt install するのが良いと思います。
普段私用で使っているPCはASUSのゲーミングノートで、CPUにAMD Ryzen7を搭載して、GPUもちゃんと載っている等スペックにこだわった分大きくて、ノートPCながらバッテリの持ちが悪く、ちょっと自室からリビングに持ち出して家族の居るところで何か作業しようとしてもなかなか面倒臭さが先立ってしまう状況でした。
そんな折、ここひと月ほど「スペック高めのUMPC的なサブ機が欲しいなあ」という気持ちが高まっており、高みに達した結果、OneMix4という10インチクラスのモバイルPCを購入しました。
私は日本語キーボード使いなので、日本語キーボードを使えることが必須でした。そして今買うならという事でWindows11に対応している事。
さらに持ち歩きしやすいサイズなので、10インチ以下のサイズで収まる事と、重さも1kgを切っている製品を探しました。
CPU/GPUヘビーなタスクは母艦であるゲーミングPCでこなすので、そういうのは必要ありません。とはいえ勉強用のコードを書くぐらいのことはしたいのと、外付けのディスプレイに接続することも考えてHDMIポートと16GB程度のメモリが載っているのが望ましいという条件で探し始めました。
条件を絞れば絞るほど候補は少なく、UMPCの雄であるGDP Pocket 3は日本語キーボードが無いために購入候補から外れました。
こうなると、OneMix3S、OneMix4、少し大きくなりますがSurfaceシリーズぐらいしか選択肢になりません。
Surfaceはタブレット用途に特化していて私のようにPC用途中心で使うには使いづらそうに感じたので、OneMix3SかOneMix4かに絞り込みました。
で、結局OneMix4を購入したわけです。
画像や動画を扱う事はほぼ無いので、ストレージは512GBにしました。
購入にあたっては、ハイビーム秋葉原本店を利用。店員さんに直接疑問点を聞くこともできる上、実機を触りながら比較検討出来て、とても良い購買体験でした。
その場でお持ち帰り…したかったのですが、在庫が無いという事で後日配送になりました。
楽しみに待つこと数日、ようやく手元に届いたのが昨晩の事です。そこから新しいオモチャを手に入れた子供のように遊んでみていますが、その中で気づいた良い点と悪い点について一度まとめておこうと思います。
キーボード周りについては、PowerToysを導入してあれこれ使いやすいようにキーの位置を変更するようにしました。
画面のグレア加工についても、別途保護フィルムを調達することにしたので、それが届けば満足いく環境になるのではないかと思っています。
新しいマシンで勉強やブログの更新がはかどると良いなと思っています。
]]>OとKRの決め方は毎回悩むところです。
なにしろ、書籍(1.)によると「重要で、具体的で、行動を促し、（理想を言えば）人々を鼓舞するようなものだ」なんて言われていて体力を使う会議になりがちですし、別の書籍(1.)では「OKRを２週間以内に設定できなければ、優先事項を見直す必要がある。会社が結束するためのゴールを設定する以上に重要な仕事などない。」なんて書かれているので、事業にコミットしようという気持ちが強ければ強いほど、言葉尻に熱意を注ぐような、重箱の隅をつつく議論になりがちだからです。
OKRを決めるときに必ず守りたいのは、「Oから決める」という事です。
KRから決めると、大抵の場合ムーンショットにならなかったり、お飾りのOになってしまうからです。
まずは、私が何度かOKRをやってきた中で良いと思ったOを決めるためのプラクティスを紹介します。
ただ、これもやってみた感触として良かったなと思える方法なだけで、正解ではないと思いますし、こうして立てたOも期の最後に振り返ると全く達成できていないケースもありましたので、参考程度に見ていただくのが良いと思います。
目の前の仕事に目がいくと、ミッションやバリューの方向を向いていないOを定めがちです。
OKRのOはムーンショットと呼ばれる達成困難に思える高い目標を掲げるわけですが、これは高い目標を達成するために集中する事で、通常とは異なるイノベーティブな発想ややり方を生み出すためでもあります。
そのためには、Oが自分たちのチームやプロダクトが出すべきミッションやバリューに向かっている必要があります。
Oの決定で行き詰まってしまった時は、一度ミッションやバリューがなんだったかを思い返すと良いです。
例えばECサイトを構築しているとして、顧客から伝票出力についてのクレームが入っているタイミングでOKRを決めようとすると、このクレームに目をつぶって議論することが難しくなります。
それでも、自分たちのミッションやバリューに立ち返って、そこから演繹的に議論する事で、Oを議論するタイミングに入ってきているノイズから自分たちの価値観を守ることができると思います。
「定量的なOではなく、定性的なOにするべき」というのは多くのOKR関連書籍で言われている事ですが、本家OKR宣伝書とも言える書籍(1.)を参照すると、決してその限りではない事がわかります。
そこで、Oについては、アウトプットではなくアウトカムを狙うというのもひとつの方法だと思います。
すなわち、OKRの実施期間である3ヶ月が経過したときに、周りからどのように見られていたいか？この3ヵ月、ミッションやバリューに向かって活動した結果、何を得ていたいのかをOとして掲げる方法です。
これは、アウトプットを重視したO（XXの達成を目指す系のO）に比べると感情に訴えかけるものになりやすく、やる気を出すOを掲げるコツでもあるかなと思いました。
ミッションやバリューの方向を向くと、どうしても高い目標を掲げがちになってしまいます。
しかし、OKRは3ヶ月とか半年のサイクルで回っていくものなので、この部分を考えてみると、OKRを実践した期間で、今の時点よりもミッションやバリューが目指しているものに近づいていけば良いということに気付きます。
そこで、例えば3ヶ月でやるなら3ヶ月という期間を強く意識して、その中でのムーンショット的なOを考えるのが良いと思っています。
不思議なもので、期間を強く意識するとより現実味のあるOが議論の俎上に上る率が高かったように思います。
保守的になりすぎて、ルーフショット（屋根の上）程度の目標になってしまう事も度々見られましたが、そこはチームの目標であればチームによる議論で、個人の目標であれば上長との議論で誤りを訂正していけるはずです。
期間を強く意識してOをブレイクダウンさせなければいけない目安としては、これまでやってきたOKRで、毎回Oが同じ事を指していて変わらないとすれば、それはもっと小さなOを複数達成すると到達できるOなのかもしれないと思います。
OKRについては、常々「ムーンショットな目標を立てる」と言われているため、圧倒的に高い目標を立ててしまいがちです。
これを「マーズショット」と表現するケースがありますが、月に行く目標を立てないといけないのに、月を飛び越して火星に行く目標を立ててしまうケースが起こりえます。
火星に行く目標は大抵の場合とても抽象的で、カッコいい言い回しで表現できるので魅力的なOに映ってしまいがちです。また、言葉の力強さに押し切られてチームの目指すものがこの手のOに決まってしまうこともあります。
けれども、真に価値のある、有効なOを打ち立てるためには、一旦立ち止まって「その前に月に行けていないよね？」というような視点の議論が必要です。
まずは肉眼で大きく見えている目標から順に切り崩していくのが良いと思います。
（空を見上げてみればわかるように、月は火星よりもずっと大きく、はっきり見えているはずです）
「OKRを決める会議をします」と言って人を集めて、その場でOKRを出させるやり方はあまり良いやり方ではありませんでした。
事業規模が小さく、全員が「今何をしなければ自分たちの明日が無いか」を常に意識している状態であればこのやり方でも良いと思いますが、その段階を超えている事業であれば、事前に個々人にOKRを考えさせてくるのが良いと思います。
ただ、このとき大切なのは心理的安全性です。どんなOKRを立てて発表したとしても、会議の場で辱められたり惨めな気持ちになったりしない人たちの集まりでなければ、考えてきたOを出し合って決めるのは難しい仕事になると思います。
もし心理的安全性が醸成されていないチームでOKRを取り入れようと思うのであれば、まずはバカな事を言っても辱められたり惨めな気持ちになったりしないチームビルディングを優先させるべきだと思います。
管理する側にとっては、皆がOKRに対して何かやってくれていることが見えますし、各人の掲げたOやKRを読んでくれていること、そしてそこでコメントによる議論が行われることで活発に動いているように見えるので、とても良い方法であるように錯覚してしまいます。
けれども、私の経験的からすると、これはよくない議論の進め方です。
なぜなら単に議論が長引いたり重箱の隅をつついたりするような、内容の薄いものに力をかけてしまいがちで、「OKRを決める」という作業に無駄に時間を持っていかれた結果、本来やらなければならい価値を創造する仕事をするための時間が削がれていくからです。
最悪なものを挙げると、ちょっとした誤字を指摘するコメントがついてしまったり、語尾の言い回しを指摘するような議論に発展してしまったり、ファイル名に日本語を使っているのがよく無いなどという全く実りのないコメントが飛び交ってしまってチームが疲弊するケースがあります。
（いずれも私が実際に経験したものです）
本来の価値を出すための目標を決めるのに、価値を出せない時間が増えていくのは本末転倒だと言えます。
議論するのであれば、各人で持ち寄って、ある場を設けて一気に議論するべきで、腰を据えて誰かの考えたOKRを批評するような時間を設けるべきではありません。
（これは「OKRの白い本」による罪だと思いますが）Oにはムーンショットや具体的である事などの諸条件に加えて「わくわくして、ベッドから飛び起きたくなるようなもの」を設定するように言われています。
これによって、語尾のちょっとした言い回しや嵌め込む単語など細部にこだわった議論が展開されてしまう可能性があります。
Oの意図するところが全員に齟齬なく伝わっているのであれば、細部の言い回しや単語の置き換えにはこだわらないのが良いでしょう。
「ヨーロッパに行く」というOを掲げた結果、チームの皆がフランスやドイツやイタリア等、異なる国々を思い描いて仕事をしていたのでは、本当の目的地であるスイスにたどり着けないワケですが、「スイスに行く」といも目標を立てられたのであれば、「スイスに行ってやる！」「目指せスイス！」などといった、（Oの本質が変化しない）言い回しの違いを決めるために時間を使うべきではないです。
つづいてKRを決めるためのプラクティスです。
先述したとおり、Oを決めてからKRを決めるワケですが、主要な結果(KeyResult)という語感が良くないのか、KRを「達成するべき数値目標」と捉えてしまうケースが多いようです。
計測可能であることは大切な事ですが、KRは達成するべき数値目標ではなく、バロメータである事を理解する必要があります。
つまり、今Oに向かって正しく歩けているか、歩けているとしてそれはどのぐらいの速度か、といった情報を得るためのものがKRであって、達成するべき目標はあくまでOなのです。
したがって、一見するとOに対応するように見える「OOをXXの状態にする」とか「XXを4つリリースする」とか「現在と同等の水準を維持できるようにする」とか「YYの手法を共有する」などといったKRは良いKRとは言えません。
「KRは、OKRを進める中でバロメータとして機能してくれるものである」というのが、設定するうえでの大切な条件になると思います。
たとえば、「O月X日までに」といった文言を入れるなど、締め切りを定めるようなやり方は良いやり方です。
「ムーンショットだから計画は立てられない、だから日付も入れられない」という議論を展開する人が出てくるかもしれませんが、「ムーンショットを実現するために計画を立てなければいけない」というのが本質なので、日付を入れて計画をもってのぞむのが大事だと思います。
日付も入れられないほどのムーンショットであれば、それは月よりも先を目指しているか、月に行くための手立てが何も見えていない、もっと小さい目標から着手しなければならない事を示しています。
理想は週次で変化を追いかけられるものにする事です。
例えば、悪い例としてあげたXXを4つリリースするというのは数値目標でかつ行動目標になっているため、良いように思えます。
けれども、このKRは変化を追いかけることでOの達成度をはかるのが難しいです。
この手の指標を立てた場合、よく観察してみるとKRの達成を目指してしまっていて、Oの達成を脇に置いてしまっているケースがたくさんありました。
一度立てた目標を変える事を嫌がる傾向がありますが、違っていると感じたら、早々に勇気をもって見直しをかけることも大事だと感じます。
せっかく立てた目標だからとか、あれだけ議論して間違っていたというのを認めたくない気持ちはわかりますが、間違ったものに向かって進んでいたら、OKRが形骸化するか、目的としていた成果が得られず、OKRの効果を実感できないか、いずれにせよ良くない結果をもたらすからです。
健康度/健全度は、書籍(1.)に出てくるフォードの例によれば、目標達成のために削ってはいけない事を削って達成していないかを見るためのものです。
「これが犠牲になっていたら、目標達成できてもかかえるリスクが大きくなりすぎる」というパラメータを2-3個設定するのが良く、健康度/健全度に設定したい内容がそれ以上の数出てくるようであれば、Oをもっと細かい領域に細分化して考えるべきケースが多いです。
上からの号令でOKRをやることになったものの、OKRをはじめるための土壌がないために頓珍漢なOKRを立ててしまって、達成できずに挫折し、果てはOKRを捨ててしまったチームも見てきました。
そういう状態にならないために、OKRをはじめる土壌としてどんな環境が必要なのかを考えてみます。
「とはいえ」等のキーワードを使って、OKRで定めた以外の事柄に目を向けさせるチームだとOKRはうまく機能しません。
例えば駆け出しのモール型ECサイトで、OKRとして購入してくれるユーザに対するものを掲げているのに、「とはいえ」というキーワードを使って出店する店舗の側を向いた機能開発をしてしまうようなマインドの組織だとOKRを適用するのは時期尚早です。
OKRはチームやプロダクトに対して本当に必要な、価値のある仕事に一極集中することで高い価値創造と一点突破する突破力を発揮できるフレームワークなので、「もったいない精神」とか「八方美人精神」が働いてしまうチームの場合、まずはそのマインドセットを改めるところから手を付ける必要があると思っています。
上からの号令でOKRを設定した場合、魅力的なOを設定できてもそれを測るためのKRの設定に苦労するケースが多くみられます。
KRは、普段から取っている統計情報をベースに定められると心強いので、普段から統計情報を取っていないチームでは、これらの情報を定期的にとるところから着手すると良いです。
例えばコードメトリクスやテストカバレッジ、顧客満足度や契約件数などの数値を定期的に取得するような組織体制を整えることが何よりも先にやることだと思います。
（付け焼刃で設定したKRでOを測定しても、正しい計測にならないことがほとんどです）
OKRについて紹介している書籍の多くは、だいたいやり方を解説するだけで、継続する際のポイントについては触れられていない事が多いです。
そこで、私が経験したチームで2サイクル目以降のOKRをどう進めていたかをメモしようと思います
1回目のOKRが終わったら、必ず振り返りをします。
振り返りのフレームワークは何でもいいと思いますが、続けたい事と改善したい事(問題点)、また進める上で不安に感じていた事をまとめられると良いと思います。
振り返りでは、全員でKRの目標値と達成値の差を眺めて、どの程度達成できているのか、達成できた(できなかった)要因は何かを議論して振り返ると良いです。
この振り返りではチームとして結論を出す必要はなく、多く出た意見をまとめるようにすると、次のサイクルで成果を出しやすくなると感じました。
（例えば、チームメンバー6名中4名が似たような要因を感じていたとか）
そのため、誰かの出した意見を否定する振り返りは行わないように注意します。
特に声の大きな人や議論を引っ張るタイプの人から否定的な意見が出ると、チーム全体としてどのような状態にあったのかも見えづらくなるので注意が必要です。
KRにして6-7割達成できたのであれば、次はより遠い目標を立てても良いと思います。
達成率が0に近いのであれば、Oを見直すか、そもそもKRが正しくOの動きを測れるものでなかったのではないかという疑いをかけるべきです。
（というか、日々仕事をしていて、1週間の間でKRが目的とする方向に動いていないとすれば、KRの設定が間違っているか、やっている仕事が間違っているかなので早めに見直しをかけたほうが良いです）
KRの達成率が3-4割であれば、引き続き同じパラメータで継続しなおしても良いと思います。
ただ、KRはより遠くに設定するようにしないと、単にゴールが近づいてくるだけの状態になるので注意が必要です。
つらつらとOKRに対する経験則をならべてきましたが、OKRをあきらめてしまうチームがある一方で、少しずつでも軌道修正しながらOKRにくらいついていくチームでは、高い効果を発揮できる武器である事も実感しました。
私の経験が、今OKRに悩んでいる人の一助になれば幸いです。
動画ではモッチャモッチャとスローロリスを食べるオランウータンの様子が。
とても興味深かったので、少し深掘りして調べてみることにしました。
元の記事はIFLSの記事です。
内容はほとんどGIZMODOと同じで、「ボルネオオランウータンがスローロリスを捕食した事例が観察された」というもの。
ボルネオオランウータンは、動物園で掲示されている解説パネルや図鑑では、「草食で稀に昆虫や鳥の卵をを食べる」事が書かれているのみで、基本的に肉食はしない生き物として知られているだけに今回の肉食（しかも猛毒を持つことで知られているスローロリスの捕食）は結構驚くべきことなんじゃないかと思います。
（以前に、とある動物園の解説ガイドで聞いた限りでは、スマトラオランウータンも含めると、空腹のときにネズミを食べた事例や死んだ鳥を食べている捕食事例はあるようですが、いずれにしても空腹に耐えかねての緊急事態での捕食事例ではないかとガイドされていました）
そういうわけで、元論文を当たってみます。
ちょっと探すのに苦労しましたが、残念なことにOpen Accessにはなっておらず、Abstractしか読むことができませんでした。
Abstractを読む限り、捕食したのは空腹状態のアンフランジオスで、メスとその子供（3歳半）と共に行動していたようです。
オスがロリスを食べている間、メスと子供はその様子を観察しながら、時折ロリスを分けてほしい要求をしていたようですが、オスはそれに応じず、オスだけがロリスを食したようで、とても面白い行動観察なのではないかと思います。
ボルネオオランウータンはとても好きな生き物のひとつなので、機会があれば論文も詳細に読んでみたいです。
]]>昨年
来年は、2年ほどWebサービスづくりをやってみた結果、データベース的なサイトやECサイトを構築するのよりも、生産に関連するような技術や古いソフトウェア資産が作り出した情報資産を将来にわたって持続可能な形にしていく技術が好きだなあと強く感じたので、そういう方面で頑張れるように努力したいと考えています。
なんて書いていたのですが、狙ってか成り行きか、この度また転職をすることができました。
それも、希望していた製造系の業界への転職です。
今回の転職は多少苦労した印象で、ざっと半年以上転職活動をしたと思います。
最初はマイナビ転職に絞って転職活動をしていましたが、マイナビクリエイターだとか何とかと関連するサービスにあれこれ登録させられたり、エージェントを名乗る人間が登場したりした割に一向に決まらず、しびれを切らしてリクナビ転職とGreenも併用することにしました。
思い返してみれば、前回もマイナビを通じた転職では中々決まらず、Greenで転職活動をはじめて、比較的短期間で決まった印象があるので、マイナビは転職先が決まりづらいのかもしれないという印象を持ちました。
（マイナビ転職、マイナビエージェント、マイナビクリエイターという3種類の異なるサイトを使わないといけないのが結構なストレスで、エージェントを介したものは、紹介される仕事内容が微妙というのもあり、1,2件面談をしただけでその後使わなくなってしまいました）
結局、今回もGreen経由で紹介された製造系の企業に転職を決めることができました。
私とGreenの相性がなかなか良いのかもしれません。
体調や環境の変化もあるのだと思いますが、心身ともにずいぶんやられた一年だったと感じます。
2022年はもう少し健康的に生きたいなと思う次第です。
Rust/Go/F#あたりを書いてみるのをしていましたが、結局長続きせず。
今は次の職場で使う技術である点も鑑みて、再びC#の復習をしています。
主戦場は.NET Coreに移り、LTSの.NET 6がリリースされ、C#も10になり…
加えてASPまわりもすっかり変わってしまっていて、学ぶことが多そうです。
並行しながらRustは継続して学んでみようと思っているところです。
まずは仕事を覚えて新しい職場になれるというのを念頭にやっていこうと思います。
その他の目標として、C#を使って簡単なWebアプリケーションを書いてみようと考えています。
楽しい一年になることを期待しています。
そこでふと、何を不満にかんじているのか整理してみるのも面白いなと思って、書き起こしてみました。
書いたところで何がある訳でもありませんが、私はこういう所に不満を感じる性格だというのが見えてくるかなと思います。
（仕事の内容に直結している部分への不満が多いので、ボカしています）
しかし、Railsで飯を食べている以上避けることができないのもまたRSpecの嫌な所で、いやいややるので一切覚えることができず、毎回あらゆることをGoogle先生にお尋ねしながら開発を進めています。
そんな中で、解決するのに手こずった内容があったのでメモしておきます。
「こんなのやる意味あるのか？」と私は思うのですが、どうやらアソシエーションが設定されている事を確認するSpecを書きたいという要求があるようです。
やる意味あるのか？と思ったのはあながちおかしくないようで、それをやっている例があまり出てきませんでした。
具体的にはこんな風に書きます。
RSpec.describe SampleModel, type: :model do
describe 'References' do
it { is_expected.to belogs_to(:hoge) }
it { is_expected.to have_one(:fuga) }
it { is_expected.to have_many(:piyo) }
end
#...
end
has_many/has_oneでアソシエーションを設定するのに、Specではhave_manyでチェックしないといけないところはややわかりづらいですね。
画像のバリデーションを用意しているとかで、ファイルをアップロードして、それに対するバリデータの動きを見るようなSpecを書く場合です。
StackOverFlowにはごっついアップロードコードを用意しろという回答が出てきますが、fixture_file_uploadというメソッドを使えば、それよりは簡単に書くことができます。
#sample.imageのimage部分がActiveStorageで関連付けられたモデルだと思ってください
context '...' do
before{ sample.image = fixture_file_upload('/images/100x100.png')
it { ... }
end
ここで、アップロードするファイルはspec/fixtures/imagesディレクトリ配下に配置します。
（fixture_file_uploadのrootディレクトリがspec/fixturesになる訳です）
具体的に出ているエラーは、こんな具合のものです。
Errno::EEXIST:
FIle exists @ dir_s_mkdir - /home/circleci/...
上記のエラーでネットを探すと、Windowsのディレクトリ名の扱いに関係したページばかりが出てきますが、原因は別の所にあります。
これは、ActiveStorageの保存先を設定するときに、storage.ymlに
local:
service: Disk
root: <%= Rails.root.join("/public/images/active_storage") %>
などと設定している場合で、サーバの構成の都合上、/public/imagesがシンボリックリンクに設定されているような環境で、なおかつCircleCIが利用する環境向けの設定ファイル（例えばenvironments/test.rb等）に
config.active_storage.service = :local
と設定してあるケースで発生します。
手元ではシンボリックリンクが活きているのでエラーになりませんが、CircleCI上に上げたとたんにシンボリックリンクが使えないものになっているので、このエラーになるというわけです。
解決方法としては、（どうせCircleCI上のコンテナは使い捨てなので）storage.ymlにシンボリックリンクでないディレクトリを使うストレージの設定を用意して、それを使うようにします。
具体的には
local:
service: Disk
root: <%= Rails.root.join("/public/images/active_storage") %>
cci:
service: Disk
root: <%= Rails.root.join("/tmp") %>
等とCircleCI用のストレージ設定を用意しておいて、環境別の設定の方にも config.active_storage.service = :cci として、専用の設定を使うように記述してあげれば良いです。
RSpecのように、テストを書くのが面倒なフレームワークを使っていると、テストを書くこと自体が億劫になって、結果としてプロダクトの品質に負の影響を及ぼす事になると感じています。
私のこれまでの経験から、プロダクトは生き物なので、下手に秘伝のソースを継ぎ足して構築していくよりも、部分的にでも刷新し続けられる状況を保つようにするべきと感じます。
刷新作業の際に、勇気をもってプロダクトにメスを入れられるようになるためにも、テストを書きやすく、保守しやすいフレームワークが求められていると感じます。
]]>