【team411 Advent Calendar 2025】3日目: 真の価値創造のためのソフトウェア業界における標準化の必要性
初めに
こんにちは、team411 Advent Calendar 2025の3日目を担当します、echoと申します。
team411 Advent Calendar 2025では、12月1日から25日までteam411のメンバーが日替わりで記事を投稿しています。各メンバーがこれまで(&これから)投稿してくれた記事はこちらにまとまっていますのでよければご覧ください。
今回は、ソフトウェア業界における標準化について軽めに記事にしてみたいと思います。
私個人、ITエンジニアの領域では初学者であることより、自身が自主的に学習した知見や開発について述べられる部分がほとんどないので、ちょっと抽象的なお話に留めておこうと思います。
自己紹介
echo
- 所属:電気通信大学 情報理工学域III類
- 趣味:音楽(聞き専)
- 技術:ほぼ皆無、HTML/css/Pythonは多少理解があります、TSを勉強中
標準化とは
そもそも、標準化というワード自体そこまで聞きなれないものです。
経済産業省の資料によると、標準化とは、「もの」や「事柄」の単純化、秩序化、試験・評価⽅法の統⼀により、製品やサービスの互換性・品質・性能・安全性の確保、利便性を向上するもの、と説明されています。
具体例を挙げると、、、
ねじが良い例でしょう。
産業革命期、ねじは専門業者が製造していたものの、各機械メーカーが自社製の機械に合わせて独自の直径・ピッチのねじをは発注していました。イギリスの技術家のウィットウォースは流通する多様なねじの形状を整理、独自の規格を定めてこれを発表し、これを機にこの「ウィットウォースねじ」の規格が次第に国中に普及しました。この規格の広まりは、大量生産を後押しし、世界中でのイギリス製機械の信頼性を大いに高めました。
要は、標準化とはあるサービスや製品に関する規格を普及させる(又は普及する) ことを指すと考えてもらえば分かりやすいでしょう。ちなみに、
なので注意が必要です。
現状のソフトウェア業界における課題
1.学習コストの多重払い
私は、大学入学の4月に411に入部することでITエンジニアの領域にほとんど初めて飛び込みました。そのとき感じたのは、何を勉強したらええねん 。Python、C++、Java、JavaScript, etc.なにがどう違うかよく分からないし、全部同じじゃないの？と思いました。とりあえず、高校でちょろっと触ったPythonの勉強をしていましたが、実際に411のプロジェクトに入ると、よりよくワカラナイ専門語句が先輩の間で飛び交っていました。
Node.js、実行環境？
React.js、ライブラリ？
Next.js、フレームワーク？
という感じ、何が何だかよくワカラナイ、全部JavaScriptじゃないんか～い。最近になって、ようやくそれぞれについて理解してはきましたが、初見だと全部同じに見えます(ガチ)。
一旦、上の説明は置いておいて、現在のソフトウェア開発における学習コストの多重払いについて述べていきます。
特に初学者にとっては、「大まかには同じ目的や機能であるにも関わらず、作法が少し違う」というものは、学習のための労力が半端ではありません。Aが何かすらよくわかっていない、Aについての理解が曖昧であるにも関わらず、AとBの違いについて知ろうとしてしまったり、AとBを比較した時にどちらを学習した方が学習効率が良いのか(勉強した時間や労力に対してどれだけ効率的に学習の成果をあげることができるか)考えてしまったりします。
具体例として、プログラミング言語を学ぶこととプログラミングを学ぶことの混同があります。文法の違いという表層的なノイズのために、学習者の認知リソースが文法自体やその相違に使われ、プログラミングの本質的な論理構造に到達できないという現象は、プログラミング学習において深刻な非効率を生む要素になっています。
Pythonで、
for x in arr:
print(x)
という書き方を覚えた初学者が、JavaScriptの
for (const x of arr) {
console.log(x);
}
を見た時に、同じ「配列の要素を順番に取り出す」動きだと捉えることができず、全く別の知識として覚え直そうとしてしまう事例も存在するかと思います。本来学ぶべきは、ある配列の全要素に対して、順繰りに要素を出力するというアルゴリズムの概念であり、これを理解していれば、言語ごとの記号の違いは方言の違いのようなもので、さほど労力をかけるようなものではないことだと分かります。
しかし、初学者はその方言の違いに苦しんでしまうのです。
2.微差による分断
様々な技術における僅かな差は、初学者の学習の負担を増加させるだけでなく、ソフトウェア業界内で自身のキャリアを狭めたり、特定の個人への過度な依存が発生したりするといった状況を生み出します。
企業がある課題を解決するために何かしら新規の、又は現行のプロダクトを開発(若しくは修正)しようとしたときに、その開発の幅は会社が抱えるエンジニアの技能に依存します。エンジニア個人は、大枠は同じであったとしても、微差により、その技術が扱えるかどうかは大きな差になり、自身の分かる範囲での開発を余儀なくされます。また、その範囲は個人単位で異なるため、Aさんが独自の(というよりAさんが扱えるフレームワークで)実装した機能を、後継のエンジニアであるBさんが理解でき、早期かつ流動的な引継ぎが行えるかというと、それにはBさんの扱えるフレームワークがAさんと同じであるという条件の下にしか成立しません。
環境の乱立
初学者として、シェル環境の乱立には悩まされました。プログラムを書いたり、開発を行う上でVScodeで環境構築を行い、必要なライブラリなどをインストールしたわけですが、どのシェルを使えばよいかよくわかりませんでした。シェルには様々な種類がありますが、同じ操作を行うにしてもそれぞれ違うコマンドを入力しなければならず、ネットの記事通りにコマンドを打ったのに、シェルの微細な非互換性故に上手くいかず、余計にリソースを割くケースが何度もありました。
シェルはコンピューターのOSとユーザーをつなぐプログラムで、ユーザーからのコマンドをOSに伝えて実行するためのインターフェースとして作られているので、OSによってそのコマンドも異なって定められています。これを考慮すると、シェル環境の乱立はOSの違いに基づくものと言えると思います。
人材流動性・リスク管理
先に、エンジニア個人は、技術の微差により、技量の範囲が限定されるという話をしましたが、これは、人材ロックイン、車輪の再発明、といった問題を引き起こすことになります。
あるエンジニアのチームが、Aというソフトウェアを使って開発を行ったとします。現状の標準化のない技術環境では、そのチームが何らかの理由によって解散したり、チームの使用していたソフトウェアのサービスが終了してしまったりしたときに、会社としては、即座に後継となる人員を用意したり、代替となるサービスに切り替えて開発を行わなければなりません。しかし、Aというソフトウェアを使えるチーム(の人員)を新たに探すこと、若しくは新たなソフトウェアの学習には、余計に時間や金銭などが発生することとなり、会社としてもそのリスクは背負いたくありません。
この状況では、チーム、ひいては企業自体の新陳代謝を抑制することにもなってしまいます。
なぜなら、自社で開発した、あるプロジェクトを維持し続けるには、そのプロジェクトを成り立たせるためのソフトウェアを使える人材を確保しておく方がリスクが少ないからです。チームを再編成するとなると、新たなメンバーが入るたびにプロジェクト特有のルールやライブラリの使用法を教育するコストが発生する上に、再編成したとしても以前と同じレベルでの開発が継続できるかどうかは不透明で、経営陣からするとそのリスクは取りたくないと感じてしまいます。
原因
1.NIH症候群
自由ソフトウェア又はオープンソースのプロジェクトでは特に、同じ機能を実現することを目的とするプロジェクトが複数存在するケースが多いです。実際、Linuxディストリビューションは数百も存在します。それぞれは表面上目的が異なる上に、応用分野が異なるとされていますが、中身はほとんど同一であると言われています。
エンジニアリングの世界では、「何を解決するか」という問題よりも「それをどんな技術で解決するか」に情熱が注がれるケースも多々存在し、既存の製品で市場の需要を満たしているにも関わらず、新たな開発を行い、至急ではないエコシステムが作られてしまいます。
2.微細な差別化による生存競争
ビジネスとして重要視されるべきなのは、「課題の解決」です。消費者にとって需要のあるサービスを安定して提供し、利益を生むことを第一に考えます。したがって、そのサービスを実現するソフトウェアは課題の解決のためのあくまでもツールであるべきです。
一方、開発者やツールベンダーは「体験の洗練」を重要視します。コードをどれだけ効率的に書けるか、如何に同様のサービスよりも優勢なものを作成できるかに重きを置きます。したがって、ユーザーが感じられないような魅力が宣伝文句として用いられます。
この微細な差別化による生存競争は、デジタルテレビのオーバースペック領域までの競争の例を見れば、それが如何にユーザーにとって必要性のないものであるかを物語っています。
アナログ放送からデジタル放送に切り替わることを機に、デジタル化が急速に進み、テレビ業界の基礎的な技術レベルが大幅に向上しました。これによって、ユーザーが要求する品質や機能・性能のレベルを比較的容易に達成できるようになり、メーカー間の技術革新による機能・性能競争はもはやユーザーhがその違いを認知できないレベルにまで到達しました。コントラスト比で言えば、ユーザーは、せいぜい数百:1でしか使用しないのにもかかわらず、メーカーは100万:1や200万:1など、人間の認知の限界を超えるような性能で他社との差別化を図りました。
果たして、ユーザーにとって必要なのは、他者サイトよりも0.01秒早く開けるWebサービスなのでしょうか。
ソフトウェア業界における標準化の意義と必要性
ビジネス価値と乖離した微細な差別化が、ソフトウェア技術の領域において行われる段階にあるのは、その根幹となる多くが本来は成熟しており、日常品になるべき段階に到達しているからだと考えることができます。ハードウェア産業が「ねじ」や「コンテナ」を標準化することによって飛躍的な生産性の向上を果たしたように、ソフトウェア産業もまた、微差による囲い込み競争から脱却し、真の課題解決型産業へ転換していく必要があるのではないでしょうか。
最後に、この業界において必要とされる(であろう)標準化や、標準化がもたらす意義についてまとめて筆を擱くこととしましょう。
標準化の必要な領域
まず一つ目は、言語と概念の抽象化及びこれらの共通インターフェース化だと思います。現状として、ループ処理や配列操作、コンポーネント定義といった基礎的な概念に対し、ツールごとに異なる文法が定義されています。プログラムの根幹である「アルゴリズム」や「概念」を共通のインターフェースとして整備し、どう書くかを基本的に一意に定め、何をするかに集中できる環境を作り出す必要があるかと思います。
二つ目は、差別化領域の限定です。いわゆる、好みから品質への競争領域のシフトですね。現状はファイルの書きやすさや構文の美しさといった個人の好みに依拠する微差で様々なサービスやプロダクトの生存競争が行われています。個人的には、書きやすさや美しさといった要素も確かに重要だとは思いますが、それが開発の新規性・継続性を失わせる理由になってはならないとも思います。好みに依拠する表層的な部分を標準化し、パフォーマンスやセキュリティ、堅牢性といった、技術の品質や完成度の階層で競争できる市場へ変革する必要があると思います。
標準化がもたらす意義
標準化はエンジニア個人や企業にとって、自由を奪う足枷ではなく、寧ろ不毛な作業やリスクから解放するための翼でなければなりません。標準化という潤滑油により、技能の幅やビジネスの幅を広げるチャンスを得たソフトウェア業界が、より複雑な課題解決を行える界隈になるべきではないかと思います。
標準化がもたらす意義として一つ目に挙げられるのは、エンジニアと企業の双方にもたらされる自由と流動性です。エンジニアは、特定のツールを扱える作業員から脱却し、様々な目的に応じて自らの能力を発揮できる課題解決のプロフェッショナルとして機能できるようになり、組織としても特定の人材に固執しなければならないというリスクから解放され、最適なチームを組成できる機動力を手に入れられるようになると思います。これによって、業界全体の新陳代謝も早くなるのではないでしょうか。
二つ目に、クリエイティビティの増大があります。環境構築のパズルやエラー回避のモグラ叩きに使われていたリソースをユーザーエクスペリエンスの向上や新規ビジネスロジックの構築に使うことができるようになると思います。さらに、標準化された土台があれば、その上に積み上げる創作物はより質の高いものになるのではないかと思います。
最後に
個人的には、それぞれのサービスが持つ特徴がそれぞれ使用されるメリットがあり、私が初学者であるが故にそれに未だ気づくことができないからこそこの文章が書けているのかなぁとも思います。
明日は、miozuneさんの「Notionタスク管理の自己流設定まとめ」です。
お楽しみに！
Discussion