エンジニアという仕事
非機能要件に特化したエンジニアリング
まず最初にお伝えすべきことは、株式会社Spelldataは一般的な「システム開発会社（SIer）」ではないということです。
私たちはお客様のシステムのプログラムを書く（開発する）ことは行いません。
その代わり、開発されたシステムが「意図通りに動くか」「十分な速度が出るか」「安全か」を検証し、改善する「非機能要件」の専門家集団です。
開発者が「機能を作る（動くものを作る）」ことに集中する一方で、私たちは「品質を保証する（正しく、速く、安全に動かす）」ことに全責任を持ちます。
パフォーマンスエンジニアリング、GcoreやTailscaleを活用した堅牢なインフラ設計、セキュリティ診断。
私たちが提供するのは、単なる作業ではなく、工学（エンジニアリング）に基づいた高度な知的サービスです。
パフォーマンスエンジニアリングは以下のように説明されており、開発とは異なる規律であることが分かります。
パフォーマンスエンジニアリングは、システム開発のライフサイクルの中で、パフォーマンスに対する非機能的な要件（スループット、レイテンシ、メモリ使用量など）を確実に満たすために適用される技術を網羅しています。
（中略）
パフォーマンス・エンジニアリングは、多くの大企業において、システム・エンジニアリングとは別個の、しかし並行して行われているタスクを持つ別個の規律となっています。
出典：Wikipedia - Performance engineering
機能要件と非機能要件：異なる専門性
ソフトウェア開発の世界には、素晴らしいスキルを持ったソフトウェアエンジニアが数多く存在し、複雑なビジネスロジックやアーキテクチャを構築しています。
しかし、「機能を実装する技術」と、「システムを維持・改善し、極限まで性能を引き出す技術」は、似て非なるものです。
F1マシンに例えるなら、速いマシンを設計・製造するエンジニアがいる一方で、レース中にタイヤの状態やエンジンの数値を解析し、ピットインのタイミングやチューニングを判断するレースエンジニアが必要です。
Spelldataが担うのは後者の役割です。
私たちは、インフラエンジニア、セキュリティエンジニア、パフォーマンスエンジニアといった、「非機能要件」に特化したスペシャリストです。
開発されたシステムが、実際のインターネット環境でどう振る舞うか計測し、統計的に分析し、ボトルネックを特定して改善する。
これは開発の下流工程ではなく、システムの価値を最大化させるために不可欠な、独立した高度なエンジニアリング領域なのです。
Spelldataは、この領域に専門特化することで、日本のIT現場に本来のエンジニアリングを根付かせたいと考えています。
エンジニアとは何か
「エンジニア（Engineer）」という言葉は、日本では非常に広い意味で使われています。
プログラマー、オペレーター、サポート担当者まで、IT業界に関わる人はほぼ全員が「エンジニア」と呼ばれます。
では、本来の「エンジニア」とは何を指すのでしょうか。
IEA（International Engineering Alliance、国際エンジニアリング連盟）が定める国際基準「GAPC（Graduate Attributes and Professional Competencies）」2021年版は、その序文でエンジニアリングを次のように定義しています。
エンジニアリングは、人々のニーズ、経済発展、社会へのサービス提供に応えるために不可欠な活動である。
エンジニアリングは、数学・自然科学と、工学の知識・技術・技法の体系を、目的をもって適用することを含む。
エンジニアリングは、しばしば不確実な状況の中で、その影響を可能な限り予測した解を生み出すことを追求する。
出典：IEA "Graduate Attributes and Professional Competencies" Version 4 (2021) 1 Introduction（日本語訳は当社）
エンジニアの本質は「問題を解く」ことです。
手順書に従って操作する、指示されたコードを書く、ツールを動かす——それらは「問題を解く」ことではなく、「作業をこなす」ことです。
エンジニアリングとは、不確実な状況の中で、科学的知識を適用し、影響を予測しながら解を設計する知的行為です。
IEAが定める三層の職能区分
IEA（International Engineering Alliance、国際エンジニアリング連盟）は、エンジニアリングに関わる職能を明確に三層で定義しています。
この三層区分を定めるGAPCは、IEAがWFEO（世界工学団体連盟）と共同で、UNESCOの支援を受けて改訂した国際基準であり、30を超える国・地域における資格相互承認の基盤となっています。
| 区分 | 英語 | 関連協定 | 扱う問題と役割 |
|---|---|---|---|
| エンジニア | Engineer | ワシントン協定 | 複合的な工学的問題（complex engineering problems）——自明な解がなく、抽象的思考・創造性・独自の分析を要する問題——を、数学・自然科学の第一原理に基づいて解決し、解を設計する |
| テクノロジスト | Engineering Technologist | シドニー協定 | 広く定義された工学的問題（broadly-defined engineering problems）を、実証済みの分析手法と確立された技術を適用して解決する |
| テクニシャン | Engineering Technician | ダブリン協定 | 明確に定義された工学的問題（well-defined engineering problems）を、標準化された手法と規範化された実践知識に基づいて解決する |
「テクニシャン」は技術が低いのではありません。
熟練した技術者であり、現場において欠かせない存在です。
GAPCが三層を分ける基準は、地位の上下ではなく、扱う「問題の性質」です。
テクニシャンは、解法が確立された問題を「どうやるか（How）」を正確に実行して解き、エンジニアは、まだ解のない問題に対して「なぜそうなるのか（Why）」を科学的に解明し、「どうあるべきか（What）」を設計します。
日本の「エンジニア」呼称問題
日本のIT業界では、この三層の区別がほぼ機能していません。
IEA基準に照らせば「テクニシャン」や「テクノロジスト」に該当する業務に従事していても、全員が等しく「エンジニア」と呼ばれます。
これは職業上の誇りを否定するものではありませんが、Spelldataが現場で見てきた限り、いくつかの副作用が生じやすくなります。
- 「自分はエンジニアだ」という自己認識が、本来のエンジニアリング能力（問題の科学的解決）の習得を後回しにしがちになる
- 「なぜ動かないのか」を追究せず、「再起動したら直った」で終わる対応になりやすい
- 計測・統計・設計という工学的アプローチよりも、勘と経験則で判断する文化が根付きやすくなる
Spelldataが「統計的品質管理をIT業界に普及する」をミッションに掲げるのは、この問題意識と直結しています。
私たちは、日本のIT現場に本来のエンジニアリング——計測し、分析し、設計する——という規律を持ち込むことを使命としています。
JABEEとSpelldataの取り組み
この問題に対して、国際的な枠組みはすでに答えを用意しています。
日本からは、JABEE（日本技術者教育認定機構）が2005年にワシントン協定に加盟し、大学等の技術者教育プログラムを認定しています（日本唯一の加盟団体）。
情報系専門教育を対象とするソウル協定にも、JABEEは2008年の創設時から加盟しています。
JABEE認定コースの修了者は、国家資格である「技術士」の一次試験が免除されるなど、そのステータスは明確に区別されています。
Spelldataは、JABEEの賛助会員です。
さらに、代表取締役の竹洞陽一郎は、JABEE広報委員会のメンバーとして、日本における「真のエンジニア教育」の普及と質の向上に直接携わっています（2026年8月現在）。
私たちは、単に基準に従うだけでなく、日本におけるエンジニアリングの地位向上と、世界で通用する人材育成にコミットしている当事者なのです。
技術士としてのエンジニアを目指して
IEAの区分でいう「エンジニア」に対応する日本の国家資格が、技術士です。
よく耳にする「基本情報技術者」などの試験は、知識・技能の習得度を測るものです。
複合的な工学的問題を解決する能力を、筆記試験と実務経験・口頭試験で審査する技術士とは、測る対象が異なります。
現在、開発現場で「動くものを作る」ことにやりがいを感じている方も多いでしょう。
しかし、もしあなたが「なぜ動かないのか？」「どうすればもっと速く、安全になるのか？」という根本的な仕組みや原理原則に興味があるなら、あなたはSpelldataのエンジニアに向いています。
Spelldataは、感覚や経験則（勘）ではなく、データと論理（科学）で戦う集団です。
非機能要件という、システムの品質を決定づける重要な要素に対して、科学的・工学的な視点からアプローチしたいと願う方を、私たちは歓迎します。
ここには、作業を正確にこなす立場から、まだ解のない問題を解き、解を設計する真のエンジニアへと成長できる環境があります。
真の問題解決のために
私たちがここまでエンジニアの定義にこだわるのは、言葉の問題ではありません。
システムが本来の目的——問題解決——を果たせるかどうかは、機能の実装だけでなく、速度・安全性・信頼性という非機能要件の水準によって決まるからです。
どれほど高機能なシステムを作っても、表示が遅すぎて使い物にならなかったり、セキュリティホールがあって情報漏洩したりしては、問題解決どころか新たな問題を生んでしまいます。
開発を行わない私たちだからこそ、第三者の目でシステムを客観的に評価し、品質の根拠をデータで示すことができます。
「作ること」ではなく「正しく動かすこと」を専門とする——それがSpelldataのエンジニアリングの原点です。