🎃

技術選定における組織の力学

2023/10/23に公開

TL;DR

  • 技術選定において、どのような判断基準があり、その結果がどうなるか、簡単な図で示してみました
  • どの判断も正解・不正解はないですが、少なくとも「偉い人の一声」のような根拠の薄い、納得感の少ない判断は避けるべき
  • 最後に、どのような選定基準があるか、一例を挙げてみました

情報グラフ

ちょっと試験的に mermaid で言いたいことをグラフ構造で表現してみました。
これを念頭に置きつつ以下の内容を読むと分かりやすかったりするんでしょうか。

はじめに

今日、こんなことをツイートしました。

https://twitter.com/_skmkzyk/status/1716282472848318537

そこそこ反応があったので、もう少し考えてみようかと思います。

どのように技術選定されるか

今回のツイートでは「インフラの自動化をやるか」を中心に置きましたが、k8s の導入でもなんでもいいとは思っています。
その組織において少し大きめの技術選定が必要な際に、どのようなことが考えられているか、またどのように考えるべきかについてまとめてみます。

力学、という名前にしたのは、中央にある課題を何か 球 のようなものと見たてて、それに対して左側からいくつかの力が加わる様子が力学だなと思ったからでした。
右側は力が加わった結果の行き先を示していますが、右上の方向に動けばその技術が採用される、右下の方向に動けば採用されない、ということを表しています。
さらに、左側の力については右上の方向 (その技術を採用したい) に動かそうとする勢力の意見や考え方は右上に向き、採用したくない勢力の意見や考え方は右下に向けています。

さらにベクトルのような考え方を取り入れて矢印の大きさがまた、力の大きさを示していることにします。

採用したい勢力が強い場合

go movement

まずは、採用したい勢力が強い場合です。
ここでは矢印を少ししか書いていませんが、さまざまなことが考えられます。

  • エンジニアの興味 (⤴)

    エンジニアは新しいもの好きだよね、という偏見に基づけば「今の環境にない新しい便利なものがあるならそれを採用したい」と考えるであろうという前提のもとのベクトルです

  • 得られるメリット (⤴)

    対象となる技術的な内容をもってメリットが得られるという前提に基づいたベクトルです。構築にかかるコストが削減される、構築にかかる時間が短縮される、さまざまなメリットが考えられます

  • 学習コスト (⤵)

    新しい内容を学習しなければならず、それに追加の工数がかかることや一時的に新旧ふたつの環境を運用しなければならない、などのマイナス面を含んだベクトルです。ワークショップを実施するにもお金がかかりますし、その自動化のための仕組み自体にもいくらかコストがかかることが考えられます

どんな理由でもかまいませんが、これらを総合的に考えて採用したいベクトルが強ければ、「採用」という結果 (右上の方向) へ動くと考えられます。

採用したくない勢力が強い場合

nogo movement

先ほどと似ていますが、採用したくない勢力が強い場合です。

  • いままでどおりでいいじゃん (⤵)

    少しラフな言い方になりましたが、組織によっては「今までどおりでいい、今まで価値を出してきたからそのままでいい」と考えることもあるだろう、というベクトルです。

意見の数、そのベクトルの大きさは組織によってさまざまでしょうが、いずれにせよ採用したくないベクトルが強ければ、「不採用」という結果 (右下の方向) へ動くと考えられます。

偉い人の意見が強い場合

nogo authotitative movement

今までの図は、あくまで判断基準に寄与する「意見」をもとに判断が行われてきたケースでした。
一方で、「忖度」のような言葉が似合う組織であれば、偉い人の意見が強い場合も考えられます。
矢印のラベルには「偉い人の一声」としか書いておらず、その内容が判断に関係がないということを示しています。
また、この一声が重要視されることを、大き目の矢印で表しています。

もちろん、最終的に判断するのは「偉い人」であり、だからこそ偉い人に正しいインプットをして正しく判断してもらうのが大事です。
ここで指摘したいのは「偉い人が言ったからそれを採用する・採用しない」は避けよう、ということです。

判断材料の一例

上の矢印に書いた内容と被りますが、判断材料として考えられるものをいくつか挙げてみます。

  • エンジニアの興味

    エンジニアの興味は非常に大事かと考えています。エンジニアの興味「だけ」が採用理由であれば飽きてしまったあとにどうするかという未来の課題につながります。一方で、たとえば「儲かるから」という理由だけで技術が採用されるとあまり興味が持てず、結果として技術の導入が失敗することもあります。エンジニアの興味は、その技術がどのようなメリットをもたらすかを理解するためのきっかけになると考えています。

  • コスト削減

    コスト削減も技術の採用に置ける重要な要素のひとつです。正直なところ、コスト削減は簡単であり、結果もすぐ現れます。とくに売上の向上とあまり関係がないような IT システムに関してはコストの削減だけしかやれることがない、という可能性もあります。

  • 売上の向上

    コスト削減と同様に投資対効果へと貢献するものですが、こちらの方が難しいです。その技術を採用することによってすぐに売上が向上することが保証されることはほとんどなく、間接的な貢献しか測れないことが多いのではないでしょうか。tech 企業であれば技術の採用自体がすぐサービスの向上、売上の向上へとつながっていくかもしれませんが、小売・製造業などの非 tech 企業で IT 技術の採用がすぐ売上に直結するような仕組み作りが済んでいる企業はトップ企業のみに限られている印象です。

  • 学習コスト

    あらゆる新しい技術の導入には学習コストがかかります。たとえば k8s を例に挙げると、今まで VM ベースの運用をしてきたようなメンバーがいきなり運用できるようなものではありません。書籍を買ったり、ワークショップを受けたり、資格を取ったりするなどして知識を身に着ける必要があります。加えて、単に知識をつけるようメンバーに伝えただけではモチベーションがついてこない可能性も高いです。組織・個人評価の KPI と関連付けた正しい動機付けが必要です。必要な学習コストを一時的なメンバー採用で補うことが欧米では比較的容易であることも多いですが、日本では雇用者側目線であまり自由度がないため今いる組織・メンバーにどうなってもらうかという観点で考える必要があります。

  • 構築・運用コスト

    すべてに当てはまるわけではないですが、なんらかの自動化の仕組みにはそれに応じた構築コストがかかることが考えられます。また、構築すると自動的に運用コストも付随して発生することが容易に予測されます。自動化に限定した話をすれば、じゃあその構築・運用コストに見合うだけのメリットが得られているのかはよく検討が必要です。毎回インフラストラクチャのアーキテクチャが大きく異なり、そのたびに自動化の枠を外れて個別調整が必要になるようであれば自動化のコストの方が高くなってしまう可能性は高いです。

  • 保守的な組織

    「いままでどおりでいいじゃん」は保守的な組織と表現できるかと思います。変化を嫌い、今までどおりでありたい、というメンタルです。よく言われることではありますが、競合他社含めて全員・全企業がそうであれば「いままでどおり」になるのですが、他社が一歩でも先に出た瞬間にもう「いままでどおり」ではなくなってしまいます。他社と同じ歩調を歩むことができてやっと「いままでどおり」な訳です。世の中がどんどん先に進んでいき、改善していくことを考えると、やはり何らかの改善が常に求められるということになるでしょう。

まとめ

頭の中でもやもやして、それを図に起こしてみたところちょっと興味深いなと思ったのでもう少し掘り下げてみたというものです。
ビジネスにおける判断ごとには明確な正解・不正解があるものではなく、どんな判断にも簡単に批判ができるものではありません。
とはいえ、あまりに不明瞭な判断が続き、実際に導入・構築・運用を進めていくメンバーが腐ってしまうような自体は避けたいものです。

Discussion