「技術選定」という言葉に重々しさを感じる人は多いと思います。
物事は名前がつくと輪郭がはっきりします。普段何気なくやっている仕事の一環であっても、名前をつけると成果物や責任などが明確になるという事象です。 掲題の「技術選定」の他にも「設計」「品質保証」など、そういう名前を使った時に起こります。 これには良い面もありますが、悪い面の取り扱いがなかなか悩ましいものです。
悪い面の一つが萎縮。 「私にはできない」や「こんなことしちゃっていいんだろうか」と言った行動を阻害するものです。 なんかいやなので、重さの呪いを解けないかなーと思いながら書いてます。
技術選定の重さ
「技術選定」という言葉は「卓越した技術力を持った人が、未来を見通して、誤りのない最適な選択をする」のような神の所業を想像させます。
できればいいんですが、そんなことはできません。 できないにも関わらず、こういう想像をさせるフォースがある。 このフォースを生み出す要因は色々あると思うのだけど、極端に振り切ったもので２つ思いつく。
一つはポジティブなもの。 技術選定の話を目にするものの多くは、「すごい人がすごく考えたこと」だったりする。 実際、技術選定に関するセッションや書籍などからはさまざまな背景を盛り込んだり制約を乗りこなしながら難しいことをやっているかの印象を受ける。 こんな難しいことはとても自分にはできない、まだ早い、そう思っても仕方ないだろう。 でも外部に発表されるものってそういうものです。 きっちりかっちりやっているように見えるかもしれないけれど、「やってきたことを整理したらこういうこと」という後付けが少なからず存在する。 情報を受け取る側は整理されたものだけを見るので、それに伴う試行錯誤や苦労は話の中で伝えられても、実際の重さは伝わらない。
少し話はそれるが、「うまくいかなかった技術選定」の発表機会はあまりない。 興味ある人は多いだろうし、ネタを持っている人も多くいるし、そういう場もたまにある。 けれど、そもそも失敗談は話しにくい。 個人の失敗談を晒すのも少なからず抵抗はあるものだし、技術選定のような影響範囲が広いものはその比ではない。 そういう抵抗で晒しにくいのもあるのだけど、それに加えて失敗要因はさらに固有の物になりがちで、共有されたものから学ぶのが難しい領域だったりする。 アンチパターンのように一般化すると役立てやすくはあるのだけど、問題領域、技術領域、組織領域などまちまちだし、そのうえ具体固有の話になる。 そこからアンチパターンを見出す技術は結構な難度がある。 「抵抗により出しづらい」と「出されたものも役立てづらい」のセットにより、機会が少ない物になっているんじゃないかなと思っている。 これは技術選定に限った話じゃなく、エッセイ本とかでも成功した人のはよくあるが失敗した人のはそんなにない。
話を戻して、もう一つがネガティブなもの。 具体的な技術選定が話題になるのは、その選定された技術が責められる時だったりする。 「なんでこんなもの使ってるんだ」のような言葉とともに「誤っている」という評価が下されてしまう。 これは過去の選定を現在から責める構図。 過去から反撃されることはないし、その技術を否定する現在のコンテキストがあるので、とても叩きやすいだろう。 こういうのを目にしてしまうと「技術選定したら叩かれる」と思ってしまったりするかもしれない。 現場での過去に選定された技術を叩くのは、それを変えるために多少は必要なことだろう。 けれど当時には当時なりの背景があるし、過度に叩いても埃くらいしか出てこない。 十分な推進力が得られたらやめたほうがいい。
たまにSNSでの技術選定に対する叩きがある。 これは「過去と現在」ではないが、叩く側が安全領域から石を投げているのは変わらない。 選定基準が不可解なものや、「このやりかたが唯一絶対の正解だ！」みたいに過度に喧伝されているものに「いやいや……」と言うのはいいと思うし、あって欲しいと思う。 でもそれに乗っかって、さらに石を投げるのはなんだかなって思います。 （こう言うのを見たくないからXの「おすすめ」はのっとふぉーみーなんだよ・・・）
技術選定と言う言葉に重々しさを与えていることの話はこれくらいにしておく。
軽い技術選定
重いと思われていそうな「技術選定」だけど、実際のところは技術選定と認識せずにやっていることも多くある。
というのも、どこから技術選定と呼ぶかの明確な線引きが、たぶんない。たぶん。
開発言語やフレームワークを選ぶのを技術選定と呼ぶのは異論はないだろう。 ライブラリを導入するのはどうか。雑にChatGPTに聞いてみたら「小物なら違う」とか言い出した。なんだそれは。
（これサムネになるとやだな） 「技術選定って重いよねー」な話の流れなので「これは技術選定じゃないからやりやすいよね！」みたいなニュアンスなんだろうか。生成AIにはそもそもニュアンスとかないだっけ、よくわからない。
私は小さかろうがライブラリ導入は技術選定、導入しないのも技術選定だと思っています。 というか開発上のあらゆる判断が技術選定に通じるもの。 細かいところだとリファクタリングでメソッド抽出するってのも、その領域での技術選定なわけだ。
なんか 書くの面倒になった うまく書ける気がしないから省略します。
このセクションで書きたかったのは「技術選定はそれと思わずに日常的にやっている」です。
- もう技術選定はできてるから怖がらなくていいんだよ！
- 技術選定からは逃げられないので諦めましょう。
どちらで捉えるかはお任せします。
まっとうな技術選定
技術選定が重いと思われる要因の一つに、技術選定と言うと正しいやり方と正しい結果があるように思われる点があると思います。
「正しい」技術選定があるのかはよく分かりませんが、まっとうなやり方はあると思います。たとえば……
- 目的を確認する
- 制約条件を洗い出す
- 選択肢を並べる
- 評価軸を考える
- 比較して選ぶ
……みたいな。 評価軸は選択肢を並べる前に挙げた方が選択肢によるバイアスがかからないからいいかもしれない。 かもしれないけど、選択肢を出した後でないと評価軸が思いつかないこともしばしばある。
他にもいろんなやり方はあるけれど、「こういう明示的なステップでやるのが技術選定だ」という認識が、先に書いた「軽い技術選定」は技術選定ではないと思われる要因なのかもしれない。 そうではなく、軽い技術選定には軽いなりのやり方があって、それを自然に行っているだけだと思っています。 軽いがゆえに言語化も重視もされていない、そんな感じ。
技術選定に必要なのは一つ、説明責任だと思います。なぜその技術を選んだかに答えられれば、それはまっとうな技術選定だと言えるんじゃないかなーと。 軽い技術選定では軽いやり方で選んでいる、そのやり方を選んだ理由が何かしらある、であれば十分まっとうだなと。 プロの仕事は多かれ少なかれ説明責任を伴うわけで、であれば技術選定は別段特別なことではないので、そんな重そうに感じたり距離を置いたりしなくていいんじゃないかなと。
技術選定を好みでやる
タイトル駆動で書いているこのエントリ。 本当に書きたかったのこのセクションだけなのに、なんでここまでのこんな面倒なことを書くはめになっているんだ……誰に書かされたでもなく自分が勝手に書いてるんだけどさ。
「技術選定ってどうしたらいいんだろう」という話に「どうしたら」なので先にあげたような「やり方」を示すことがしばしばあります。 自分がいざ「技術選定するかー」となったときも、とりあえず「まっとうなやり方」でやってみる気分になる時もある。
そうすると選択肢と評価軸が出て、表ができる。たとえばこんな感じ。
| 評価軸 | hoge | fuga | piyo |
|---|---|---|---|
| 学習・導入コスト | ○ | ◎ | △ |
| 運用実績・安定性 | ◎ | ◎ | ○ |
| スケーラビリティ | ○ | ○ | ◎ |
| 運用負荷 | ○ | ○ | ◎ |
| チームの習熟度 | ◎ | ○ | △ |
| 将来の拡張性 | ○ | ○ | ◎ |
（このやり方は評価軸の出し方や評価の仕方とかにいろんな方向性や仕掛けがあるのだけど、それは本筋でないので省略します。）
ここまではいい。で、どうやって選ぶよと。
技術選定が苦手な人はやり方を知らないことも多いんだけど、やり方に従っても最後で手詰まりになることが多い。
こういう比較表を作っても「 hoge にします」とはならず、表を前に途方に暮れていたりする。
結局のところ技術選定は「選ぶ」のが難しいんだけど、「やり方」がそれを担ってくれることはありません。 やり方はあくまで「選ぶための材料を集める」ものでしかないので、「自動的に決まるもの」と思ってるとしたら期待値が違うのです。 ある程度の条件を与えればAIが「これがいいよ」って言ってくれるけれど、それでも説明責任は自分になります。 少なくとも現在では、説明責任を「AIが言ったから」では果たせない。将来的にはいけるかもしれないけど、いまは通用しない。 つまり「責任の重さ≒技術選定の重さ」なのかもしれない。（であれば技術選定に限ったことではないわなってやっぱり思うわけだが……） 「責任を取りたくないんだ！」って話もあるかもなんだけど、それは別の話なので割愛。 そうじゃなく本当に選びづらい状況もある。本稿はそちらの話です。
色々条件を並べてみた結果、「どちらをとっても50歩100歩だな」と思えることはしばしばあります。 やり方は選ぶための材料集めで、天秤に錘を乗せていくような行為です。 選択肢に決定的な差が見出せないなら、 最後は好みで選んでしまってよい と思います。
というのも、好みは対象を理解する原動力になるから。 技術選定の対象となる選択肢は膨大な背景を持っていることが多く、選定後に何かあったときは選定時よりも深く調べる必要があります。 そういう時に「これ好みじゃなかったんだけどな」と思いながら調べるのはストレスになるけれど、好きなものならストレスも少なく（ないとは言わない）、深く調べる方向に動きやすかったりします。
何か問題があった時、対象技術の設計思想を前提に対処するのと、表面的な回避をするのでは前者の方が結果的に良いことは多いです。 好きな技術だと前者を、好きじゃない技術だと後者を取りがちになる。なってしまう。人間ってそういうもの。 そしてこの選択は無意識に行われるので、何故そちらを選んだかは個人の中に閉じてしまい深掘りされることは稀だったりします。
好みで選んでから理由を後付けしてしまおう。 流石に選定文書のような記録を残すときに「好みだから選びました！」とは書けないでしょう。 将来それを見た人も戸惑ってしまいますし、役に立ちません。 （私的には「好みだから選んだ」って書いてくれてたらすごく役にたつと思うんだけど、書かれているのを見たことがないから、まぁそういうものなんだろうなと思っています。） 最初に選択肢を並べたときよりももう少し深く調べれば、なにかしら差別要因が見つかるはずなので、それを押し出してしまいましょう。 そうすると「最初からその評価軸で選んでそれになった」のような感じになります。やったね。
差別化要因の言語化が好みの言語化につながり、自分を見直すきっかけになることもあります。これは副次作用。 なお、調べたら評価がひっくり返って選択肢が変わることもしばしばあります。それも一興かなと。
しめ
「技術選定」という言葉を重々しく感じ、自分ではやらないことだと思っているかもしれません。 ですが日常の開発は選択の連続であり、「軽い技術選定」も多くあります。 そういう軽い技術選定も「技術選定」だと思って取り組むことで、技術選定がうまくなるんじゃないかなー、なんて思うわけです。
技術選定をする以上、少なくとも一次判断は自分に委ねられているわけで。 自分ができる範囲で選択材料を集め、それで選択肢が絞りきれないのであれば、最後は自分の好みで選んでしまいましょう。
選択肢が絞りきれないということはどちらを選んでも大差ないわけです。 選ぶのが仕事なので、天秤を傾けるために何かを乗せなければなりません。 決め手が見当たらないなら「好み」を乗せてしまいましょう。
材料集めをしないとか、明確に優れている選択肢があるのをぶっちぎって好きなものを選ぼうって話ではありません。
おまけ
- ChatGPTさん「好みで決めたらダメ」
- 私「うるさいばーか」
どうでもいいけど、この「失敗」の選定理由も妥当なことが多いです。 さすがにこれそのまま書かれたら跳ねるけれど、たとえば有名ってことは事例が多いとかで使い方の情報が得やすいとかスキルセット持った人が多いとか保守が続く見込みが高いとか言えます。ほら説明できる。他も同じ。
