「いちばんめ」が大事でないならfindFirstよりfindAnyを使う

Javaの Stream の話です。

Stream は複数のものを扱いますが、結果が1つ（もしくは0 or 1個）だけ欲しい場合がよくあります。 こういう時に使用できるのが findFirst と findAny です。

jshell> Stream.of("hoge", "fuga", "piyo").findFirst()
$1 ==> Optional[hoge]

jshell> Stream.of("hoge", "fuga", "piyo").findAny()
$2 ==> Optional[hoge]

結果は同じで、先頭の "hoge" が返っています。findなんで Optional で包まれています。

実際の使用シーンはコレクションをIDとかで filter して、1件に絞られている場合とか、filter の条件を満たすものならどれでもいい場合です。 filterせずに findFirst() するのはあまりない気がする。そんなものは最初から Optional にしとけって感じだし。

こういう時に findFirst() が使われがちです。AIも findFirst() を生成してきます。ですがーー

「いちばんめ」に強い意志がないならば findAny() を選ぶ のがいいです。

実装している時は軽い気持ちで選ぶでしょうが、何か不具合があった時にこういうコードを見ると「これfirstでないとダメなのかな？」とか「このStreamの順序ってどうなってるんだっけ？」とか考えなきゃいけなくなります。まじめんどい。

脱線：2件以上あったらまずいときの話

「1件しか入っていないから findFirst() でいいや」としている場合。 2件以上入ってたら変なことになるけど目を瞑って findFirst() している場合。前者も大概だけど、後者のほうが罪深いです。

実は複数件入っているとかに起因する不具合がそれなりに見ます。わかりづらいです。 取得できて処理が続行できるので、不正な状態になっていることが握りつぶされている。2件目以降は消え去るので、本番でしか起こらないとかだとほんと調査しづらい。

もし「1件であること」が大事なのなら findFirst() を使ってはいけないです。もちろん findAny() もだめです。 ただ findAny() を選択している場合は「複数あったらどれが返ってもいいやつなんだよな」という確認が入っている感じがします。 FirstとAnyの違いに意識を向けられる場合は複数件にも意識が向く感じ。完璧じゃないけど結構な精度があるとは思う。 思考停止や「 findFirst() はグチグチ言われるから findAny() にする」とかだと効果ないですけどね。

やるなら一度 toList() とかでコレクションにして、サイズチェックしてから1件取り出しです。 ものによっては迂闊に toList() したら思った以上の件数があってOOMEとかも起こったりするので、 .limit(2).toList() とかですかね。

めんどくさいのはわかるけど、障害のほうがめんどくさいですし、お金もかかります。せっかくJavaつかってんだから実装で防げるものは防ぐのがいいです。

reduce で2件目以降がきたら例外にするとかもできます。ちゃっぴーに書いてもらったらこんな感じ。

T value = stream.reduce((a, b) -> {
    throw new IllegalStateException("More than one element");
}).orElseThrow(() -> new IllegalStateException("No element"));

これをいろんなとこにコピペするのはNGです。やるなら共通のユーティリティとかにしましょう。

……脱線のほうが長くね？

おまけ：StreamのAPI仕様

最後に一応、Javadocも見ておきましょう。サイドにメソッド一覧とか出るようになって使いやすくなりましたね。って今日気づきました。普段IDEでみるからね。。。

• Stream (Java SE 25 & JDK 25)
• Stream (Java SE 25 & JDK 25)

安定した結果が必要な場合は、かわりにfindFirst()を使用してください。

こんな書き方をされると「安定してる findFirst() の方を使った方が良さそう」と思っても仕方ないと思います。

でももし安定した結果が大事なのであれば、ストリームが順序を持つものであることを保証しなければなりません。 Stream自身に isOrdered() みたいな判定メソッドはないため、メソッド内でListから生成されたStreamであることが明らかであり、今後もそれが維持されることが前提になります。これは思っている以上に難しいことです。 そういうことにとらわれずにやるとすれば sorted() を読んで並び替えてから findFirst() でしょうか。 sorted() で実行時例外が出ないといいですねー。

おまけ：Codexさん

あなたがいま書いてきたコードですけど。

人間なら「わかってんのになんでやらんの」と言いたくなっちゃいますが、AIにそういう説教するのは「お金払って話を聞いてもらって相槌を打ってもらう」というアレですから、アレ。

"壊してよいオモチャ"を持つ

"壊してよいオモチャ"はアプレンティスシップ・パターンにある私のお気に入りパターンの一つです。

アプレンティスシップ・パターン　―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

お気に入り具合は干支が一周して同じようなタイトルでブログを書いてることから察してください。

• "壊してよいオモチャ" を作る - 日々常々

"壊してよいオモチャ" とは

自分で作った、自分で使う、自分のためのツールのことです。

書籍の「問題」セクションはこういう文章で始まります。

あなたは、失敗を許さない環境で働いています。

先のブログでも「仕事では安易に失敗することはできません。」と書いていたりします。書籍ではこう続きます。

しかしながら、何かを学ぶ最善の方法は、たいていは失敗することです。

「 "壊してよいオモチャ" を通して失敗を経験していこうぜ」と言うのが大まかなパターンの説明です。

"壊してよい" という言葉

壊してよいと言える条件にはどのようなものがあるでしょうか。 仕事で扱うプロダクトで「壊してよい」と言うためには様々な条件があるでしょう。 自分で使うツールであれば、直せるならば壊しても構わないと言えることが多いです。

着目したいのは「壊れてよい」ではなく「壊してよい」と言うところ。 原題だと「Breakable」となっています。ableなので「壊せる」のような積極的な感じも感じたり感じなかったり。英語わからん。 「何もしてないのに壊れた」は定番のネタですが、このコンテキストでは自分の行動によって「壊す」が盛り込まれています。 壊れてしまうような、むしろ積極的に壊すようなチャレンジをしてもよい。それが "壊してよい" にあるように思います。

"オモチャ" という言葉

「オモチャ」という言葉には「楽しめる」ということが含まれます。

オモチャであり楽しめるものであるべきことを忘れないでください。それらが楽しめなくなり、最初の熱狂の嵐が過ぎ去った後は、それらは埃を被ることになり（以下略

楽しめることが大事です。時間を忘れていじってしまうような、そういうもの。 この辺りがうまく名付けられたパターン名の良さですね。

なおアプレンティスシップパターンには情熱という言葉を含む「情熱を放つ」と「情熱を育む」があります。そういえば同年代に情熱プログラマーという本も出版されてました。「情熱」が流行っていた時期なんでしたっけ。

情熱プログラマー ソフトウェア開発者の幸せな生き方

"壊してよいオモチャ" という言葉

夢中でいじり回して、ぶっ壊してしまって、直して、またいじる。 そんな物体が "壊してよいオモチャ" です。

子供が遊んでいるオモチャを見ていると、簡単に壊れるものの、簡単に直せるようになっているものが多いです。 負荷が集中する稼働部はあえて外れやすく作り、そうでない部分は頑丈に作っている、というような話を聞いたことがある気がします。 これも "壊してよいオモチャ" が持つべき特性の一つでしょう。

ソフトウェア開発者が扱うのはソフトウェアですから、ハードウェアや物体、人などを扱う仕事に比べて "壊してよいオモチャ" を得るハードルは非常に低くあります。せっかくのアドバンテージなので活かしましょう。

"壊してよいオモチャ" を持つ

さてタイトル。 "壊してよいオモチャ" は昔からある言葉ではあるし、珍しいアプローチではないものの、なかなかハードルが高くもありました。

特に近年は自分でツールをつくらずとも、よくできたツールに溢れていました。 特化したツールを使わずとも汎用的なツールでなんとかなる場面も多いです。

書籍でも以下のように書かれています。

たいてい、これらのオモチャは、業界の標準ツールの簡単な再実装であり、（以下略

これは明確に「車輪の再実装」と呼ばれるアンチパターンですが、アンチパターンは特定文脈においては推奨される行動になります。 たとえば「プログラマが知るべき97のこと」の "車輪の再発明の効用" が挙げられます。

• 車輪の再発明の効用 | プログラマが知るべき97のこと

プログラマが知るべき97のこと

"車輪の再発明の効用" では作る過程で知ることが多いところにフォーカスしています。 "壊してよいオモチャ" も同様の記述はありますが、それ以上に使い続けてメンテナンスすることに力点があるように思います。 これは「メンテナンス」というプロセス自体も再発明の範囲と言えたりする感じ。

本稿の趣旨は「車輪の再発明をしよう」という話ではなく「持ち続けよう」です。前者も大事なんだけど、それを踏まえた後者です。

自分のためのツールを作って、それを使い続けましょう。 その過程で得られるものは非常に多いです。 メンテナンスの中には「0から作り直し」があっても構いません。同じ名前をつけた同じ目的のツールを「使い続ける」のが大事です。

AI時代だからこそ

なんでこんなことを書いているかって言うと、AIによって「それっぽく動くもの」を作る速度は明確に早くなったからです。

なのでそれに乗じて自分のための道具を作って、それを使い倒してみるといいんじゃないかなーと最近思っている次第。実際やってみたら思った以上に手応えがあったので書いてます。

speakerdeck.com

「こういうことできる気がする」と言う、自分の「気がする」と言う直感を検証するのが容易になりました。 開発者としての直感を鍛えたり検証したりすると、いろいろ捗ります。

このスライドでは「重々しく捉えなくても100行くらいならノリで書けるでしょ？」とか言ってますが、そりゃ書く労力だけならねぇって感じで。実際は脳内で設計とか走らせてるわけで。難しいものもあるよね。 でもその辺もAIが担ってくれます。思いついたらやってみましょう。

その過程で自分の知らない技術が勝手に出てくることもしばしばあります。そこをとっかかりに対象技術への理解を深めましょう。 「この技術使ってるけど、なんで？」とかAIを問い詰めてみるのもいいでしょう。 知っている技術だけで構成されてしまったなら、意識的に気になっていた技術を盛り込んでみましょう。特定ライブラリやフレームワークでもいいですし、設計パターンでもよいでしょう。キーワードだけぶちこめばそれに沿ってそれっぽいものを作ってくれます。

AIでの初期作成はさっくり作れてしまうので「車輪の再発明」の過程で得られるものはほとんどありません。プロンプトの試行錯誤などはありますが、それはその技術であって「車輪」に用いられる技術ではないわけで。 それゆえに使い続ける点に力点を置きます。 作ったツールを使っていると、当然のように痒いところに手が届きません。 どんどん変更していきましょう。 そして、ふとした変更で簡単に壊れてしまうでしょう。

壊れにくくするのか、直しやすくするのか、置き換えやすくするのか。そういうことを考えて "壊してよいオモチャ" に取り組むのは、これまでも大事だったことですが、今後も活きていくんじゃないかなって。そうおもったりします。

具体例

JIGは私にとっての "壊してよいオモチャ" の代表例です。

github.com

2018年4月からなので8年弱さわり続けていることになります。 あまり変更していない時期もありますが、ずっと生きていますし、色々と「壊す」ようなことにも取り組んできました。 壊したときの影響範囲をどうコントロールするかとかも重要なテーマ。 こういうプロダクトがあると「AIと既存コードをぶつけたらどうなるかとか」とかの肌感覚も得やすいです。

JIGは他の人も使っているので「自分だけのため」ではありませんが、 "壊してよいオモチャ" は別に「自分のため」であって「自分だけのため」ではないです。 「自分のため」は自分自身がそのツールに対して要求を出す第一人者であり、動かなくなったりしたら真っ先に困る人ってこと。 他の人のためのツールは動かなくなって困るまでにラグがあったり、ちょっと困っても「別に言わなくていいか」となったりするので違うんです。 作りっぱなしでそれっぽく動くだけのものは "壊してよいオモチャ" ではありません。ここ大事。

あと全然開発に関係ないものだと、将棋の棋譜閲覧ツール。

github.com

完全に自分専用で配布とか考えてないんだけど、vibe coding 100%でKotlinつかったデスクトップアプリと言う。Kotlinなんもわからん。vibeなので一行も書いてないけど、一応読んではいる。純粋に「趣味で自分が欲しいと思ったもの」に振り切っているのがポイントで、作りが微妙でも「まぁ動くならいいや」と進めていたりする。そのうち「仕様を出力してゼロから別の技術使って作り直した時にどの程度のものになるんだろう」みたいなのを試しそうと思ってる。

他にも開発で使うツールは色々あったりします。 "壊してよいオモチャ" は毎日のように使うのが大事だと思います。 少しの引っ掛かり、ちょっとした機能追加。そう言うのを使いながら感じるのはある種の才能かもしれませんが、ある程度は習得できる技術だとも思います。 使っている間は情熱を持ってメンテナンスするのですが、役目を終えて使わなくなったものはメンテナンスもしなくなります。打ち捨てられるのもオモチャの宿命かね。

脱線：失敗について

失敗に関しては昔（2013年）にこんなこと言っていたり

• テスト駆動開発を継続する | PDF

最近だと若干まるい表現に。

表現がまるいだけで、言ってることは「失敗しようぜ」である。

脱線：パターンの使い方

「アンチパターン」とか「デザインパターン」とかはよく見聞きするでしょうし、個々のパターンが言及されることは日常でも少なくありません。

パターンはパターンとして名前がついて輪郭を帯びるだけでもかなりの力を発揮します。 そのため「特定の状況のこと」をパターンと呼んでいることもしばしばあります。

これはこれで間違いないのですが、パターンの力はそんなものではありません。 パターンにはコンテキストやフォースなどもありますが、大きいのは「パターンはパターン間で繋がる」ということです。 パターン間が繋がるとテコの原理が働き、相乗効果が生まれます。 一つのパターンだと語りきれない状況もパターンを組み合わせて網目を構築すると掬えたりしますし、新たなパターンで補うこともできます。

「これパターンだっけ？」と思ったら、そのパターンの原典をあたるなりAIに聞くでもいいので、関連パターンに意識を向けてみましょう。 きっと新たな発見があります。

ちなみにChatGPTさんに「壊してよいオモチャの関連パターンは？」と雑に投げると、以下が返ってきました。

書籍で記載のあるものとかぶっていたりいなかったりですが、まぁ確かにという感じ。どう関連あるかとかも言ってくれるのでよかですね。

まとめ

好きなAIで好きにまとめて。←

いや正直、人が書くブログなんて思考を原液で垂れ流すくらいのほうが今後は価値あるんじゃないかなぁって思ったりするわけですよ。

あ、 "壊してよいオモチャ" って言う言葉から個の何かをイメージしがちなんだけど、部分的に「ここは "壊してよいオモチャ" にできるな」みたいなのがあります。 たとえば仕事の中でプロダクトでは難しくても、テストコードだとかCI環境だとかは "壊してよいオモチャ" として、壊れてしまうかもしれないチャレンジをしがいがある場所です。うまいこと設計すればプロダクトの中でも "壊してよいオモチャ" 領域は作れます。仕事の中で "壊してよいオモチャ" で遊びながら力もつける、なんてことを無意識にできるようになると、経験値も爆上がりでタイパも良いです。と言うかそう言うことができないと「仕事外の時間で勉強しなければならない」みたいなことになっちゃって、なんともだよねって思ったりします。

まとめセクションに発散することを書くんじゃない。

技術選定は好みでやっていいんだよ

「技術選定」という言葉に重々しさを感じる人は多いと思います。

物事は名前がつくと輪郭がはっきりします。普段何気なくやっている仕事の一環であっても、名前をつけると成果物や責任などが明確になるという事象です。 掲題の「技術選定」の他にも「設計」「品質保証」など、そういう名前を使った時に起こります。 これには良い面もありますが、悪い面の取り扱いがなかなか悩ましいものです。

悪い面の一つが萎縮。 「私にはできない」や「こんなことしちゃっていいんだろうか」と言った行動を阻害するものです。 なんかいやなので、重さの呪いを解けないかなーと思いながら書いてます。

技術選定の重さ

「技術選定」という言葉は「卓越した技術力を持った人が、未来を見通して、誤りのない最適な選択をする」のような神の所業を想像させます。

できればいいんですが、そんなことはできません。 できないにも関わらず、こういう想像をさせるフォースがある。 このフォースを生み出す要因は色々あると思うのだけど、極端に振り切ったもので２つ思いつく。

一つはポジティブなもの。 技術選定の話を目にするものの多くは、「すごい人がすごく考えたこと」だったりする。 実際、技術選定に関するセッションや書籍などからはさまざまな背景を盛り込んだり制約を乗りこなしながら難しいことをやっているかの印象を受ける。 こんな難しいことはとても自分にはできない、まだ早い、そう思っても仕方ないだろう。 でも外部に発表されるものってそういうものです。 きっちりかっちりやっているように見えるかもしれないけれど、「やってきたことを整理したらこういうこと」という後付けが少なからず存在する。 情報を受け取る側は整理されたものだけを見るので、それに伴う試行錯誤や苦労は話の中で伝えられても、実際の重さは伝わらない。

少し話はそれるが、「うまくいかなかった技術選定」の発表機会はあまりない。 興味ある人は多いだろうし、ネタを持っている人も多くいるし、そういう場もたまにある。 けれど、そもそも失敗談は話しにくい。 個人の失敗談を晒すのも少なからず抵抗はあるものだし、技術選定のような影響範囲が広いものはその比ではない。 そういう抵抗で晒しにくいのもあるのだけど、それに加えて失敗要因はさらに固有の物になりがちで、共有されたものから学ぶのが難しい領域だったりする。 アンチパターンのように一般化すると役立てやすくはあるのだけど、問題領域、技術領域、組織領域などまちまちだし、そのうえ具体固有の話になる。 そこからアンチパターンを見出す技術は結構な難度がある。 「抵抗により出しづらい」と「出されたものも役立てづらい」のセットにより、機会が少ない物になっているんじゃないかなと思っている。 これは技術選定に限った話じゃなく、エッセイ本とかでも成功した人のはよくあるが失敗した人のはそんなにない。

話を戻して、もう一つがネガティブなもの。 具体的な技術選定が話題になるのは、その選定された技術が責められる時だったりする。 「なんでこんなもの使ってるんだ」のような言葉とともに「誤っている」という評価が下されてしまう。 これは過去の選定を現在から責める構図。 過去から反撃されることはないし、その技術を否定する現在のコンテキストがあるので、とても叩きやすいだろう。 こういうのを目にしてしまうと「技術選定したら叩かれる」と思ってしまったりするかもしれない。 現場での過去に選定された技術を叩くのは、それを変えるために多少は必要なことだろう。 けれど当時には当時なりの背景があるし、過度に叩いても埃くらいしか出てこない。 十分な推進力が得られたらやめたほうがいい。

たまにSNSでの技術選定に対する叩きがある。 これは「過去と現在」ではないが、叩く側が安全領域から石を投げているのは変わらない。 選定基準が不可解なものや、「このやりかたが唯一絶対の正解だ！」みたいに過度に喧伝されているものに「いやいや……」と言うのはいいと思うし、あって欲しいと思う。 でもそれに乗っかって、さらに石を投げるのはなんだかなって思います。 （こう言うのを見たくないからXの「おすすめ」はのっとふぉーみーなんだよ・・・）

技術選定と言う言葉に重々しさを与えていることの話はこれくらいにしておく。

軽い技術選定

重いと思われていそうな「技術選定」だけど、実際のところは技術選定と認識せずにやっていることも多くある。

というのも、どこから技術選定と呼ぶかの明確な線引きが、たぶんない。たぶん。

開発言語やフレームワークを選ぶのを技術選定と呼ぶのは異論はないだろう。 ライブラリを導入するのはどうか。雑にChatGPTに聞いてみたら「小物なら違う」とか言い出した。なんだそれは。

（これサムネになるとやだな） 「技術選定って重いよねー」な話の流れなので「これは技術選定じゃないからやりやすいよね！」みたいなニュアンスなんだろうか。生成AIにはそもそもニュアンスとかないだっけ、よくわからない。

私は小さかろうがライブラリ導入は技術選定、導入しないのも技術選定だと思っています。 というか開発上のあらゆる判断が技術選定に通じるもの。 細かいところだとリファクタリングでメソッド抽出するってのも、その領域での技術選定なわけだ。

なんか 書くの面倒になった うまく書ける気がしないから省略します。 このセクションで書きたかったのは「技術選定はそれと思わずに日常的にやっている」です。

• もう技術選定はできてるから怖がらなくていいんだよ！
• 技術選定からは逃げられないので諦めましょう。

どちらで捉えるかはお任せします。

まっとうな技術選定

技術選定が重いと思われる要因の一つに、技術選定と言うと正しいやり方と正しい結果があるように思われる点があると思います。

「正しい」技術選定があるのかはよく分かりませんが、まっとうなやり方はあると思います。たとえば……

• 目的を確認する
• 制約条件を洗い出す
• 選択肢を並べる
• 評価軸を考える
• 比較して選ぶ

……みたいな。 評価軸は選択肢を並べる前に挙げた方が選択肢によるバイアスがかからないからいいかもしれない。 かもしれないけど、選択肢を出した後でないと評価軸が思いつかないこともしばしばある。

他にもいろんなやり方はあるけれど、「こういう明示的なステップでやるのが技術選定だ」という認識が、先に書いた「軽い技術選定」は技術選定ではないと思われる要因なのかもしれない。 そうではなく、軽い技術選定には軽いなりのやり方があって、それを自然に行っているだけだと思っています。 軽いがゆえに言語化も重視もされていない、そんな感じ。

技術選定に必要なのは一つ、説明責任だと思います。なぜその技術を選んだかに答えられれば、それはまっとうな技術選定だと言えるんじゃないかなーと。 軽い技術選定では軽いやり方で選んでいる、そのやり方を選んだ理由が何かしらある、であれば十分まっとうだなと。 プロの仕事は多かれ少なかれ説明責任を伴うわけで、であれば技術選定は別段特別なことではないので、そんな重そうに感じたり距離を置いたりしなくていいんじゃないかなと。

技術選定を好みでやる

タイトル駆動で書いているこのエントリ。 本当に書きたかったのこのセクションだけなのに、なんでここまでのこんな面倒なことを書くはめになっているんだ……誰に書かされたでもなく自分が勝手に書いてるんだけどさ。

「技術選定ってどうしたらいいんだろう」という話に「どうしたら」なので先にあげたような「やり方」を示すことがしばしばあります。 自分がいざ「技術選定するかー」となったときも、とりあえず「まっとうなやり方」でやってみる気分になる時もある。

そうすると選択肢と評価軸が出て、表ができる。たとえばこんな感じ。

評価軸	hoge	fuga	piyo
学習・導入コスト	○	◎	△
運用実績・安定性	◎	◎	○
スケーラビリティ	○	○	◎
運用負荷	○	○	◎
チームの習熟度	◎	○	△
将来の拡張性	○	○	◎

（このやり方は評価軸の出し方や評価の仕方とかにいろんな方向性や仕掛けがあるのだけど、それは本筋でないので省略します。）

ここまではいい。で、どうやって選ぶよと。

技術選定が苦手な人はやり方を知らないことも多いんだけど、やり方に従っても最後で手詰まりになることが多い。 こういう比較表を作っても「 hoge にします」とはならず、表を前に途方に暮れていたりする。

結局のところ技術選定は「選ぶ」のが難しいんだけど、「やり方」がそれを担ってくれることはありません。 やり方はあくまで「選ぶための材料を集める」ものでしかないので、「自動的に決まるもの」と思ってるとしたら期待値が違うのです。 ある程度の条件を与えればAIが「これがいいよ」って言ってくれるけれど、それでも説明責任は自分になります。 少なくとも現在では、説明責任を「AIが言ったから」では果たせない。将来的にはいけるかもしれないけど、いまは通用しない。 つまり「責任の重さ≒技術選定の重さ」なのかもしれない。（であれば技術選定に限ったことではないわなってやっぱり思うわけだが……） 「責任を取りたくないんだ！」って話もあるかもなんだけど、それは別の話なので割愛。 そうじゃなく本当に選びづらい状況もある。本稿はそちらの話です。

色々条件を並べてみた結果、「どちらをとっても50歩100歩だな」と思えることはしばしばあります。 やり方は選ぶための材料集めで、天秤に錘を乗せていくような行為です。 選択肢に決定的な差が見出せないなら、 最後は好みで選んでしまってよい と思います。

というのも、好みは対象を理解する原動力になるから。 技術選定の対象となる選択肢は膨大な背景を持っていることが多く、選定後に何かあったときは選定時よりも深く調べる必要があります。 そういう時に「これ好みじゃなかったんだけどな」と思いながら調べるのはストレスになるけれど、好きなものならストレスも少なく（ないとは言わない）、深く調べる方向に動きやすかったりします。

何か問題があった時、対象技術の設計思想を前提に対処するのと、表面的な回避をするのでは前者の方が結果的に良いことは多いです。 好きな技術だと前者を、好きじゃない技術だと後者を取りがちになる。なってしまう。人間ってそういうもの。 そしてこの選択は無意識に行われるので、何故そちらを選んだかは個人の中に閉じてしまい深掘りされることは稀だったりします。

好みで選んでから理由を後付けしてしまおう。 流石に選定文書のような記録を残すときに「好みだから選びました！」とは書けないでしょう。 将来それを見た人も戸惑ってしまいますし、役に立ちません。 （私的には「好みだから選んだ」って書いてくれてたらすごく役にたつと思うんだけど、書かれているのを見たことがないから、まぁそういうものなんだろうなと思っています。） 最初に選択肢を並べたときよりももう少し深く調べれば、なにかしら差別要因が見つかるはずなので、それを押し出してしまいましょう。 そうすると「最初からその評価軸で選んでそれになった」のような感じになります。やったね。

差別化要因の言語化が好みの言語化につながり、自分を見直すきっかけになることもあります。これは副次作用。 なお、調べたら評価がひっくり返って選択肢が変わることもしばしばあります。それも一興かなと。

しめ

「技術選定」という言葉を重々しく感じ、自分ではやらないことだと思っているかもしれません。 ですが日常の開発は選択の連続であり、「軽い技術選定」も多くあります。 そういう軽い技術選定も「技術選定」だと思って取り組むことで、技術選定がうまくなるんじゃないかなー、なんて思うわけです。

技術選定をする以上、少なくとも一次判断は自分に委ねられているわけで。 自分ができる範囲で選択材料を集め、それで選択肢が絞りきれないのであれば、最後は自分の好みで選んでしまいましょう。

選択肢が絞りきれないということはどちらを選んでも大差ないわけです。 選ぶのが仕事なので、天秤を傾けるために何かを乗せなければなりません。 決め手が見当たらないなら「好み」を乗せてしまいましょう。

材料集めをしないとか、明確に優れている選択肢があるのをぶっちぎって好きなものを選ぼうって話ではありません。

おまけ

• ChatGPTさん「好みで決めたらダメ」
• 私「うるさいばーか」

どうでもいいけど、この「失敗」の選定理由も妥当なことが多いです。 さすがにこれそのまま書かれたら跳ねるけれど、たとえば有名ってことは事例が多いとかで使い方の情報が得やすいとかスキルセット持った人が多いとか保守が続く見込みが高いとか言えます。ほら説明できる。他も同じ。