まるで必殺技名のようなICT用語集

 この業界に長く関わっていると、毎年のように新たな言葉が生まれて、注目され、それが一般化していく流れをよく目の当たりにする。そんな中、(新しい用語に限った話ではないのだが)たまに聞いたことがない用語を耳にすると、それを知らない自分に恥ずかしさを覚えて、その場は「あぁ、それねー」とか言ってごまかしつつ、その後、人知れず「教えてGoogle先生っ!」って検索エンジンに向かう──という経験って、誰しも一回はあるのではないだろうか。
 そうやって新しく覚えた言葉は、積極的に会話に取り入れていきたくなるのも人のエゴだ。で、それを聞いた人がまたググって…という、このバイラル的なループが、ICT(Information and Communication Technology)用語を加速度的に拡散させていくのだろう。
 ただ、同じ会社内でまだあまり知られていないICT用語を発信したりすると、それを知らない人たちから「先進的な専門知識を持っている人(=アーリーアダプター)」としてちょっとしたリスペクトを受けられる。だが、その一時の優越感に浸って気をよくしていると、噂を聞いた上司なんかに「君はトレンドに詳しいみたいだから、ちょっと相談に乗ってほしい案件があるんだ…」とか、藪から大きな蛇を呼び出すことにもなるので注意が必要だ。
 さらに、同じICT業界内でも、特定のエンジニア間でしか通用しないような用語を、専門ジャンルが異なる人との会話で使ってしまうと、「それ誰の必殺技だよ?」とか言われかねない。

 そんな、知らない人が聞いたら、いや、知っている人が聞いても、まるで必殺技の名前のような”素敵な”ICT関連用語を集めて、その用語の正しい意味とともに紹介していこうと思った次第。

(順不同)

ストアドプロシージャstored procedure

 データベースエンジニアにはお馴染みの用語。よく略して「ストプロ」と呼ばれる。語尾の「シージャ」の響きが聞き慣れないフレーズで美しいので、一度聞くとかなりのインパクトで記憶に残る。必殺技名としては、攻撃系よりもバフ系っぽい雰囲気があるかと。

解説

 データベースの一連のクエリ処理をまとめたものに名前をつけて、関数のように再利用可能としたもの。定義されたストアドプロシージャはデータベース内に永続的に保存されて、外部のアプリケーションや言語に依存せずに、いつでも利用できる。
 一回の呼び出しで、複数のクエリ処理を実行でき、引数の受け渡しも可能のため、ケースによっては外部アプリケーション側にロジックを持たなくてもデータベース内で処理を完結できるようになる。
 また、手続き後に戻り値がないもののみを「ストアドプロシージャ」と云う。戻り値があるものは「ストアドファンクション」と呼ばれる。
 例えば、特定のテーブルのデータを更新したら、その更新データと別のテーブルのデータ値とを演算加工してその結果を集計用のテーブルに保存する──といったビジネスロジックが必要な場合、これを外部アプリケーション側から制御しようとすると、UPDATEクエリとSELECTクエリとINSERTクエリを順次発行する必要がある。しかし、UPDATE後のSELECT+値の加工+INSERTの手続きをストアドプロシージャとして保存しておき、UPDATEトリガーにそのストアドプロシージャの呼び出しを指定しておくと、外部アプリケーション側ではUPDATEを実行するだけで期待する処理がすべて行われるようになるのだ。
 ストアドプロシージャによるメリットは、クエリコストの削減によるアプリケーション側とデータベース側との実際のI/Oを減らせることだ。これによって、アプリケーション全体としてのパフォーマンス向上につなげられる。また、ビジネスロジック変更時のロジック修正をストアドプロシージャ内の手続き変更のみで済ますことができるというデータモデル保守性の向上にも寄与するかもしれない(逆にアプリケーションエンジニアにストプロのコーディング知識がないと保守の難易度が上がるので、一概にメリットとは言えないケースもある)。
 一方でデメリットもあり、ストアドプロシージャのコードは利用するデータベース(RDBMS)に大きく依存してしまうため、異なるデータベース間でのコードの再利用性が低いことなどがあげられる。
 

ガベージコレクションgarbage collection

 システムバックエンド側のプログラマーにはお馴染みの用語。一方で、デザイナーやフロントエンドエンジニアで知っている人は少ないのではないだろうか。字面や語感が格好いいので、ついつい使いたくなる言葉でもある。必殺技としては、探索補助系とかバフ系っぽい名前でもある。

解説

 プログラムの処理中に不要になったメモリを自動的に開放する仕組みのことで、直訳すると「ガベージ(=ゴミ)コレクション(=収集)」となる。
 およそプログラム言語において実行される処理は、実行する時に必要なデータをメモリという領域に格納して処理を行う。そして、プログラム側で指示がない限り、処理が終わった後も不要になったデータはメモリに残ったままである。このまま他の処理が続々と実行されると、いつしかデータを入れるメモリが足りなくなって、処理ができなくなるいわゆる「メモリリーク」が起きてしまう。それを防ぐため、ある処理が終了した時点で、不要になったと判断されるメモリを自動で掃除(解放)していく機能が、この「ガベージコレクション」である。
 PHPやRuby、JAVAといった言語にはこのガベージコレクションが実装されているので、開発時にメモリの残容量等を厳密に考慮しなくても、プログラム言語側でよしなにメモリ管理をしてくれるのだ。逆に、C++やDelphi、Objective-Cなどは実装方法が異なるので、注意が必要だ。

プログレッシブエンハンスメントProgressive Enhancement

 フロントエンドエンジニアを救った金言的な概念である。かつて「Web2.0」などに端を発してWEBコンテンツが爆発的に溢れた際、世のすべてのフロントエンドエンジニアには途方もない「クロスブラウザ」の壁が立ちふさがっていた。その頃のインターネットの世界では、フィーチャーフォンからスマートフォンへのデバイスシフトや、自動アップデート型のChromeの登場による、IEやFirefoxなどのパッケージ型レガシーブラウザからのブラウザシェアの急速な変遷といった大きなパラダイムシフトが起きていた。そんな過渡期にあっても、WEBのフロントエンドには新旧すべてのデバイス、ブラウザでのコンテンツ配信性能が求められていたのだ。
 そして、それに応えるべく編み出されたのが「レスポンシブデザイン」である。
 しかし、レスポンシブデザインをもってしても、すべてのレガシーデバイスをカバーし切れなかった。制作サイトの対応ブラウザ条件にIEのバージョンまで明記していなかったがために、「IE6でデザインが崩れるんだけど…」とかクライアントから電話が来たりして、(最新バージョンがIE9の当時)「IE9で見てくれよ!」と本心で思いつつも、IE6用のCSSハックを追加する──というような作業を延々と繰り返していたものだ。
 そんな苦境に立たされていた世のフロントエンドエンジニアを「クロスブラウジングの悪夢」から救ったのが、まさに必殺技「プログレッシブ・エンハンスメント」である。

解説

 HTML5の基礎理念でもある「セマンティックさ(文書としての「意味」を重要視する考え方で、見栄えではなく、題名は見出しタグへ、記事本文は段落タグへといった、正しく意味付けされたマークアップを行うべきという表現手法)」を土台にして、どのユーザーにも同じ意味のコンテンツが提供されるが、見栄えとしてのコンテンツ表現はユーザーの閲覧環境により差異が生じることを是とする考え方。
 モダンなブラウザを使用しているユーザーにはよりリッチな表現でコンテンツが表示され、レガシーなブラウザ環境のユーザーにはコンテンツの表現力は低下しているものの最低限の意味は伝わる。このように、ユーザーの閲覧環境の差による見栄えの差はあれど、両者が受け取るコンテンツの意味が同一であることこそが重要である、という解釈だ。
 このプログレッシブエンハンスメントの概念は、文章の「セマンティックさ」を担保することで、リッチな見栄えの適応範囲を最大限絞り込み、制作側のマークアップコストを最適化するのに大いに役立った(はずだと思う)。
 例えば、見積もり時に「今回制作するサイトの対象ブラウザは「プログレッシブエンハンスメント」に準じてローンチ時の最新ブラウザで考えています」とコミットしておけば、とりあえずレガシーブラウザへの対応に苦慮することからは解放された。
 まぁ、当時は「プログレッシブエンハンスメント」を正確に理解しているクライアント自体が少なかったので、その後デザイン納品時のクライアントチェックになって、やれあのブラウザで表示が違うだの色々とリテイクを求められることも多かったのが実情なのだが…。

ディレクトリトラバーサルdirectory traversal

 ネットワーク脆弱性の用語の一つ。脆弱性関連の用語は、実際の攻撃手段の名前ということもあって、まさに必殺技的な名前の宝庫である。これに関して言えば、「トラバーサル」のフレーズが小気味良い。

解説

 ネットワーク上のファイルの保存場所(=ディレクトリ)を遡(さかのぼ)るように横断(=トラバーサル)することで、本来提供者側がアクセスを想定していないファイルへアクセスして、システムへの攻撃を行う攻撃手段。
 主に親ディレクトリへの遡上を伴うことから、ネットワークシステムでディレクトリを遡上するためのパス指定方法である「../」より「ドットドットスラッシュ攻撃」とか、「ディレクトリクライミング」などの別名で呼ばれることもある。

コンテンツインベントリcontents inventory

 デザイナーやディレクターといったフロントエンドの設計に携わる人にはお馴染みの用語で、文字通りコンテンツの目録(=インベントリ)のこと。元々ICT業界では「インベントリ」と云うと、資産管理分野でのPCなどの機器情報の一覧を指していたようだ。
 必殺技としてはバフやデバフ系のイメージ。インベントリという語呂感が妙に艶っぽくて印象に残る。

解説

 WEBサイトの情報設計(IA:インフォメーション・アーキテクト)に関わる用語。
 主に制作するWEBサイトにおける全コンテンツの一覧をまとめたドキュメントのこと。全体の制作ボリュームを把握したり、必要となる機能要件を洗い出すためのひな形になったり、コンテンツのカテゴライズやサイトマップ作成のベースとなったり、と用途は多い。
 特にコレといった定型的な書式が存在するわけでもなく、作成するWEBデザイナーやディレクターによって表現手法は千差万別である。一般的に、サイトマップやコンテンツリストと同義的にとらえられることも多く、それらのモダンな呼び名として認識している人もいる。

スキャフォールディングscaffolding

 単に「scaffold(=スキャフォールド)」とも呼ばれ、MVCフレームワークを利用してプログラミングしているエンジニアにはお馴染みな用語だ。アプリケーションの大枠を作る際にしか使われないコマンドの一種でもあるので、大規模な開発等に参加しているエンジニアには、実際に使用する機会が得られないケースも多いかもしれない。
 必殺技の名前としては、探索補助系とかバフ系のイメージか。

解説

 MVCフレームワーク等にて、データモデルの型をベースにして、いわゆるCRUD(クラッド:追加=Create/読込=Read/変更=Update/削除=Delete)を行うための画面やコードを自動生成する機能のことを指す。
 Scaffoldの単語自体が「足場」という意味なので、アプリケーションの「足場作り」という処理や機能でも利用される言葉だ。
 注意しないといけないのが、このスキャフォールディングで作られるのはあくまで「足場」であって、最終的なアプリケーションのビューやコントローラーとしては未熟であるということだ。スキャフォールディングで生成されたコードがいかにクールだったとしても、それをそのままローンチするアプリケーションに転用するのは避けた方が良い。
 ちなみに、(私の知見がある範囲内では)Ruby on Railsのスキャフォールディングが素晴らしく、プロジェクト作成後にモデルを指定しながらscaffoldを実行することで、DBマイグレーション用のファイルとモデル、コントローラー、ルーティング、ビューまで、およそ必要となるアプリケーション関連ファイルをすべて一括で自動生成してくれる。Railsはアプリケーションの生産性に優れる、とよく云われるが、この強力なスキャフォールディングこそ、その所以の最もたるところなのではないかと思う。

スパイラルアプローチspiral approach

 別に「スパイラルモデル」とも呼ばれる。モダンなプロジェクト・マネージャを自認するのであれば、覚えておかなければならない開発手法だ(実際にマネージメントできるかどうかはさておきだが…)。
 必殺技としては攻撃系っぽいが、アプローチ部のフレーズがやや語彙的に力強さに欠けるのでバフやデバフ系もありか。

解説

 ユーザからのフィードバックや要望に対して具体的な対応をしながら、設計とプロトタイピングを繰り返しつつ、徐々に完成に近づけていくシステム開発の手法である。小規模なものは「アジャイル」開発とも呼ばれ、大規模なものが「スパイラルモデル」や「エクストリーム・プログラミング」などと呼ばれる。
 従来の「ウォーターフォールモデル」の「最初にガッチリ仕様を定め、既定の工程を順序良く辿って行く」という開発手法では、開発途中における変更要望に柔軟に対応することは難しく、実際のユーザからのフィードバックも開発が完了してからでないと受けられないため、シーズとニーズの乖離によるリスクヘッジができなかった。そのアンチテーゼとして考え出された反復型開発モデルの一つが、スパイラルアプローチである。
 スパイラルアプローチでは、作業工程を可能な限り分割して、分割したシステム単位でプロトタイプを作成し、ユーザからのフィードバックを元にシステム補正を行う。これによって、システムを成長させながら反復型開発を続け、らせん状(=スパイラル)に巻き昇るような形で完成させるという流れになる。
 スパイラルアプローチなどの反復型開発モデルは、パッケージではないSaaS(サース:Software as a Service)型のアプリケーション・ソフトウェアの開発に向いていて、ユーザのフィードバックからの柔軟かつ速やかな要求反映や機能改善が可能な点で、大きなアドバンテージがある。一方で、反復型開発モデルではリファクタリングやリバースエンジニアリングのスキルが重要になってくることもあって、エンジニアリング条件が高度になるとともに、適確なリソース管理や課題管理を継続的に行っていく必要もある。また常に成長し続けるシステムに追従するドキュメンテーションにも難があり、保守・開発が属人化し易いというデメリットもみられる。
 このモデルをマネージメントして成功に導くためには、従来の「ウォーターフォールモデル」でのマネージャとしての知見よりも、実際の開発現場で得た、実処理をグループ化してプロトタイプモデルとして小分けできる感性や、ユーザからのフィードバックから現実的なシステム補正要件に落とし込んでスケジュール化できる柔軟性の方が強く求められるのではないかと思う。
 世のクライアントや非エンジニア畑出身の上司などは、このモデルが「要件が柔軟に変えられる」ものだという一側面のみにフォーカスして、開発途中での無茶な変更要望もお構いなしに投げてくるケースが多い。これらの無理難題を上手く捌(さば)きつつ、品質をキープしながら上向きなスパイラルを形成していける──そんな凄腕のマネージャさんに一度はお目にかかってみたいものだ。 

スキューモーフィズムSkeuomorphism

 WEBのデザイン関連用語。あまり会話レベルで登場する言葉ではないが、WEBデザイナーでこの言葉を知らないと、かなり恥ずかしい思いをするので、基礎知識として覚えておく必要がある。
 言葉の意味的には錬金術系統、フレーズからは幻惑関連のデバフ系の必殺技っぽいイメージがある。

解説

 デザインにおける表現手法の一つで、実際にある物質に似せた形状のデザインや装飾を施すことで、ユーザーに馴染みのないモノを、馴染みあるモノのように思わせて利用を促進する手法だ。
 WEBにおいてこれと対極に位置するのが「フラットデザイン」であり、こちらの知名度はかなり高い。
 WEBデザインの潮流では、一昔前(2000年後半~2012年頃)に流行っていた表現手法で、例えば、ボタンにさも押せそうな立体的な質感を持たせたりしていた。iPhoneのランチャーアイコンなどが有名で、今はフラットなデザインになっているが、昔は凸感のある陰影が追加されていたのが懐かしい。
 現在のWEB上では、主流のフラットデザインに圧(お)されてなかなか見かけなくなったが、ゲームなどでは多く取り入れられていて、テーマ性を持った世界観を表現するうえでは非常に有効なデザイン手法であるため、今後も廃れることはないだろう。

クロスサイトリクエストフォージェリcross-site request forgeries

 ネットワーク脆弱性の用語の一つ。脆弱性関連の用語は、実際の攻撃手段の名前ということもあって、まさに必殺技的な名前の宝庫である。
 クロスサイト系の脆弱性攻撃手段には、有名な「クロスサイトスクリプティング」や「クロスサイトトレーシング」「クロスゾーンスクリプティング」などがあるが、このクロスサイトリクエストフォージェリがフレーズ的に一番格好いいと思う。

解説

 別名CSRF(シーサーフ)攻撃とも呼ばれ、WEBアプリケーションが意図していない外部サイトからのリクエストを受け付けてしまう脆弱性を衝いた攻撃手段だ。
 例えば、ログインが必要なWEBアプリケーションにて、ログイン後の任意の処理で、その処理リクエストが許可された場所からのものかどうかを確認していないような場合に、攻撃者が外部にその処理リクエストを発行するWEBページ等を設置して、対象とするWEBアプリケーションにログイン可能なユーザーをその攻撃用のWEBページに誘導するように仕向ける。もし攻撃を受けるユーザーが該当のWEBアプリケーションからログアウトしないまま、攻撃用WEBページにアクセスしてしまうと、意図しない処理が実行されてしまうことになる。
 過去には、偽装された攻撃用URLにアクセスしたら、とある掲示板に自分のアカウント名で誰かの殺害予告が投稿されてしまい、誤認逮捕されたケースなどかなり怖い事例がある。
 アプリケーション提供側は、利用者が常に善なるもの、提供側の意に沿ったアクションをしてくれるものと考えて、しばしばログインなどの認証を経た後のリクエストは安全なものであると信じ込んでしまいがちだ。そのため、これらの脆弱性に気づかずに攻撃者に利用されることになるのである。
 また、この脆弱性への対策にリクエストメソッドにGETを許可しないようにすればいいと誤った認識を持っているエンジニアもいる。だが、この攻撃を防ぐためには、その施策は的外れで、正解としてはリクエストを受け取った都度、リクエストの出どころの正当性を検証する(リクエスト毎に発行されるトークンを認証したり、リファラーを確認する等)必要がある。
 

プロビジョニングProvisioning

 ネットワーク・サーバ運用に関わるエンジニアにとってはお馴染みの用語。元々は「この後起こる事象に備えて準備をしておく」という意味で、ICT業界では主にネットワーク・サーバ運用の分野でよく使われるようになった。
 必殺技の名前としては、言葉の意味や語感からもバフ系だろう。

解説

 ネットワークやコンピューター(≒サーバ)といった設備を、必要に応じて速やかに提供できるように予測し、準備しておくこと。もしくは、それら準備されたリソースを実際に提供すること。
 プロビジョニング関連の用語には対象とするリソースやケース等で「サービス・プロビジョニング」や「シン・プロビジョニング」などいくつかあるが、私が関わったことがあるMSP分野でよく利用される「サーバ・プロビジョニング」がメジャーではないだろうか。
 サーバ・プロビジョニングの実例としては、プロビジョニング要求に応じて、提供すべき仮想サーバ(=インスタンス)を選定し、OSやミドルウェアといった各種アプリケーションをデプロイし、システムやネットワークの設定(IPアドレスの付与、DNSの設定、ポートフォワーディング等)を行い、WAFやL/Bの下へサーバ・インスタンスを配置して、サービスを提供可能にするところまでの一連の作業があげられる。これら一連の作業を自動化するために、事前にDockerコンテナやChef、Ansibleといった技術を使って準備を行うこともまた「プロビジョニング」の一環であり、プロビジョニングの語彙が示す作業範囲は非常に広い。
 クラウド技術の汎用化に伴って、仮想化された大量のサーバをリモートで一元的に制御できるようになっている昨今は、エンドユーザやクライアントからのいついかなる要求にも応えられるようにこの「プロビジョニング」が非常に重要になって来ていると云えよう。
 

ディスクストライピングdisk striping

 単に「ストライピング」とも呼ばれ、ネットワーク・サーバ運用のエンジニアで知らない人はいないだろう。いわゆるディスクアレイ(=ハードディスク)の「RAID(レイド)0」のこと。
 その名の通り「分断」系の攻撃技の名前以外は考えられない。

解説

 1つのデータを2つに分割(=ストライピング)してハードディスクに書き込むこと。複数のディスクにデータを分散して格納するディスクアレイ(=ハードディスク)の仕組み「RAID(レイド:Redundant Array of Independent Disk)」のデータ分散機構の一種で、単純なデータ分割のみを行うレベル0の「RAID 0」の仕様である。
 保存すべきデータが分割されて複数のディスクに同時に書き込まれるため、データサイズが小さくなり、書き込みや読み込み時のI/O(=ハードディスクへのアクセス時間)が減って、高速なデータ操作が可能になるメリットがある。しかしながら、分散されたどちらかのデータが破損すると、1つのデータとしては再現できなくなるデメリットもある。
 例えば、ひらがなの「あ」は2進数では「11000001000010」となり、これを保存時に「1100000」と「1000010」に分割して複数のディスクに保存したと(便宜上)仮定すると、もし片方のデータが破損してしまうと、ひらがなの「あ」というデータを再現することができなくなるということだ。
 保存するデータの性質にもよるが、一般的には、データのミラーリング(=二重化)ができる「RAID 1」や、エラー訂正コード(パリティコード)によるデータ復旧が可能な「RAID 3」以上のアーキテクチャを選定することが望まれる。

トランザクションtransaction

 データベース・エンジニアおよびプログラマーにとってはお馴染みの用語。データベースを取り扱う際は、このトランザクションを知らずに取り扱ってはいけない。特に決済などお金に絡むような仕組みを開発する時には、きちんとトランザクションを理解したエンジニアに任せないと、後々とんでもない目に遭ったりする。
 必殺技としては、「分割できない」という語意から転じて、対象者の行動を制限するようなデバフ系がしっくりくる。

解説

 言葉の本来の意味は「取引」とか「処理」であり、トランザクション自体に特別な意味が付与されるのはデータベース管理分野においてだけである。その特別な意味も、Wikiとかを引いてみると「分けることのできない一連の情報処理の単位」などと書いてあっていまいちピンとこない。
 私なりに意訳すると「トランザクションとは、データベースの処理において“分割してはならず”、“失敗時には実行されない”、単一もしくは複数のSQLクエリの塊」と云える。
 つまり、トランザクションとして定義されたSQLクエリの塊は、それぞれの単一のSQLクエリとして分割してはならず、塊内のすべてのSQLクエリが成功した場合のみ、データベースに永続的に保存されるものなのである。
 例えば、ECサイトでの商品購入を(便宜上の)トランザクション処理とした場合、ステップ1:購入された商品の在庫をマイナスして、ステップ2:購入者のお財布から購入金額をマイナスして、ステップ3:ショップ側の売り上げをその分プラスして、ステップ4:購入者のステータスを購入完了にして、ようやく決済完了の後続処理につながるとする(クレジットカード決済の場合、ステップ2が外部APIとの連携になってしまうので、この一連の流れを1トランザクションとして処理化できない。便宜上としたのは、ECサイト内に顧客がお財布口座を持っているという仮想の仕組みになる)。
 もしトランザクション処理内のそれぞれのステップが分割処理可能としてしまうと、ステップ3でもしトラブルが発生してその後の処理が継続できなくなった場合への対処を別途考えてロジック化しておく必要があるだろう。最悪、再決済を行った購入者に二重課金が発生してしまう等のリスクもありえる。
 トランザクション処理では、全てのステップが正常に処理されない限り、各ステップの処理結果はデータベースに保存されない。一つでもステップが失敗した場合はトランザクション処理はロールバックされて、トランザクション開始前の状態に戻ることになる。つまり、購入者は何も購入しなかったことになり、在庫も減っていない状態で再度商品購入を行うことができるのだ。
 このトランザクションの性質は、ACID(アシッド:Atomic=原始性/Consistent=一貫性/Isolation=独立性/Durable=永続性)特性と呼ばれ、課金決済など世の中の多くのシステムで利用されている。

マイグレーションmigration

 データベースエンジニア、プログラマー、情報システム担当エンジニアなどに馴染み深い用語かもしれない。「何を」マイグレーションするかによって呼び名が変わるので、マイグレーションという言葉だけでは広義の「移行」という意味でしかない。
 必殺技名としてはちょっとインパクトが弱いが、系統としてはバフ系か。

解説

 単語の意味は「移動・移住」であり、「OSマイグレーション」「レガシーマイグレーション」「データベースマイグレーション」等、システムやプラットフォーム、データベースといったIT資産の移行のことを指す用語だ。
 WindowsやCentOSなどOSのメジャーバージョンを最新版へ移行することを「OS(Windows)マイグレーション」と云い、レガシーなプラットフォーム上のシステムをオープンソース等を利用した最新のプラットフォームへ移植することを「レガシーマイグレーション」、データベースのデータを異なるバージョンのDBや、RDBMSへ移動することを「データベースマイグレーション」と呼ぶ。ちなみに、Ruby on Railsでデータベースを新たに作成する際も「DBマイグレーション」と呼ぶが、これにはちょっと違和感を覚える。
 「レガシーマイグレーション」の規模になると、相当の人員と工期がかかる大手術になることが多く、あまり関わる機会は少ないのではないだろうか。
 逆に「OS(Windows)マイグレーション」あたりは個人のPCで行うこともしばしばあり、PCを自作している人などにとってはお手のモノかもしれない(毎度、面倒ではあるのだが…)。
 「データベースマイグレーション」は新規開発以外のシステム開発ではよく「データ移行」とか云われて、開発タスク化されることが多い。オープンなDBマイグレーションツールもいくつか公開されているので、認知度が高いマイグレーションの分野かもしれない。

コアコンピタンスcore competence

 ICT業界に限った話ではなく、広く使われるマーケティング用語である。類似語に「コンピテンシー(=高水準能力)」とかもある。
 俗に「意識が高い系」の営業担当やマネージャ、経営者などの会話でよく使われていると感じるのは私だけだろうか。お互いに言葉の意味がきちんと理解されて使われているのかどうかが怪しいシーンでよく聞く言葉だ。
 必殺技の名前としては、バフ系だろう。

解説

 経営戦略における自社の「強み」を表す用語だ。ICT業界に限らないが、日本人同士の会話の場でこの「コアコンピタンス」を口にするような人とは親しくなれそうな気がしない(私個人的に…)。「わが社の強みは~」って話してくれた方が、信頼感増す気がする(私個人的に…)。

ファシリティfacility

 施設や設備という意味を持つ言葉だが、ICT業界では主にネットワーク・サーバ運用のシーンでよく使われる。よくデータセンターの紹介ページなどに「ファシリティ的に~」とか「堅牢なファシリティを~」とか書いてあるが、ファシリティ自体の語彙がそこまで認知度がないので、サーバ運用とかに疎い顧客にとっては内心「そもそもファシリティって何なんだよ!?」と思っている人もいるのではないだろうか。
 「器用さ」という意味もあるので、必殺技名とするならバフ系か。
 

解説

 ネットワーク・サーバ運用のシーンで頻出するフレーズで、企業内のサーバルームといった施設から、データセンターのような建物、サーバラック等に供給される電源の容量や空調、耐震性といった設備の仕様まで、およそ情報通信機器の運用において物理的なコストがかかるモノについてはすべからくファシリティと称する文化がある。
 ネットワーク・サーバ運用に関わるエンジニアは、会話の流れや文脈から、ファシリティ(マネージメント)のことなのかファシリティ(コスト)なのか、単に固有名詞としてのファシリティなのかを適確に判断してコミュニケーションを取れるスゴイ人たちなのである。
 ちなみに、Linuxなどのサーバにおいてファシリティというとログの種類を指すようだが、今までログ関連でファシリティというフレーズを聞いたことがないので、こちらはかなりマイナーな用途なのかもしれない。

フィジビリティスタディfeasibility study

 略して「フィジビリティ」とも云い、「F/S」と表記されることもある。これもICT業界に限らず、広く使われるマーケティング用語である。
 必殺技名としては、バフ系のイメージ。

解説

 新規事業やプロジェクトなどが実現可能かどうかを検討するために、事前に行う調査や研究のことを指す用語で、新規事業の企画書などに含まれる市場調査や競合状況、販売計画、採算性などの指標が実際のアウトプットとなる。マーケティングの要素が強く、主に経営判断や投資判断の材料として使われているので、エンジニア側には縁遠い用語かもしれない。
 プロジェクト・マネージャをやっていると、プロジェクトの初期に予備調査としてシステム開発の実現可否を判断する指標としてのフィジビリティスタディを求められることがある。そういう場合、大抵はRFP(Request For Proposal)的な要求事項と制約事項、利用可能なプラットフォームやソリューション案を提示して、プロジェクト実施判断を仰ぐことになる。

ハドゥープHadoop

 ネットワーク・サーバ運用に関わるエンジニアや、ビッグデータを取り扱うエンジニアにはお馴染みの用語。ハドゥープ自体はオープンソースソフトウェアの名前なのだが、大規模データを分散処理するための蓄積・管理の仕組み全体を指す固有名詞的にも使われている。
 ちなみに、「ハドゥープ」という名称は開発者であるDoug Cutting氏のお子さんの象のぬいぐるみの名前とのこと(素敵なネーミングセンスだ!)。
 何だかわからないけど強そうな感じのフレーズなので、攻撃系の必殺技でいいかも。

解説

 ハドゥープの中核は、大規模データ(=ファイル)を分散して蓄積する仕組みであるHDFS(Hadoop Distributed File System)で、データは複数に分割され、さらに複数の場所に複製が保存される。この時点でデータに対する信頼性が確立するため、各分割先のディスクにおけるRAIDを必要としない。
 もしも分割保存先のディスクが故障したとしても、それら機器の故障を検知して別の場所に再びデータの複製が行われるため、基本的に故障したディスクの差し替え等を考慮しなくてもよい。さらに、データ保存領域はフレキシブルにスケールアウトできるため、とりあえず大規模データを入れっぱなしにしておいてもハドゥープ側でよしなに管理してくれるという、まさに夢のようなストレージと云える。
 オープンソースで利用しやすく、元々機器は故障するものとして、そのうえでデータストレージとしての信頼性を追求しているソフトウェアのため、寄せ集めのPCを使ってハドゥープを組むことも可能である。RDBMSのようにスケールアウト時にスキーマの拡張が必要ないのも魅力的で、とりあえずデータノードの領域だけ確保しておけば大規模データを永続的に蓄積しておくことができる。
 ハドゥープの仕様を紐解けば解くほど、「サーバ運用なんてものは極限まで楽できるんだよ!」という人のエゴが見え隠れしていて、非常に共感を覚えるのは私だけだろうか。

グロースハックGrowth Hack

 ICTエンジニアリングにおける新しいマーケティングの概念を示す用語で、このグロースハックな活動を行う人をグロースハッカーと呼ぶ。「ハッカー」と云っても悪いことをする人ではないので注意が必要だ。もともと「ハッカー」とは技術的な探求心が旺盛で、専門的な分野において深い知識を持ち、そしてロジカルで柔軟な思考を持ち合わせた人たちを指す言葉だ。つまりはエンジニアの中においてもニッチな「ハイレベル・エンジニア」のことであり、その能力を悪い事に利用する者は「クラッカー(cracker)」と呼ばれて区別される。
 一般的に「ハック」の意味が曲解されて浸透してしまった現在では、このフレーズにネガティブな印象を受けやすいが、本来の意味からは回復系やバフ系の必殺技名こそがふさわしい。

解説

 グロースハックの言葉が使われ始めたのが2014年頃からなので、まだIT業界的にも新しい概念と云える。グロースハック自体は新しいデジタルマーケティングの手法であり、従来のシステム開発とマーケティングが分離・独立したサービス運営構造ではなく、マーケティングとシステム開発を同時並行的に実施しながらサービスを成長させていく新しいサービス運営保守の形である。
 元々、スタートアップやベンチャー企業が「いかにお金をかけずに」マーケティングを行いつつ、自社サービスを改善していくかという実践的な試行錯誤の結果から生み出されたもののようだ。そのため、グロースハックでは「コストをかけない」という事が重要である。
 しかしその後、多くの企業がこのマーケティング手法に注目し、ICT業界に広まっていく流れの中で、「コストをかけない」という本来のグロースハックの定義部が薄れ(もしくは欠落し)てしまい、モデル論や方法論が一人歩きしてしまっているのではないか、と私は感じる。
 根本的にグロースハッカーはエンジニアでなければならず、さらにマーケティングの知識が豊富な優秀なマーケターである必要もある。その彼(彼女)が、日々マーケティングの成果から逆算した起因となる指標を探り出し、その指標を最大化するための裏付けとしてシステムを改修していくことになる。おそらくほとんどの施策は失敗するが、失敗してもあきらめずに新たな指標を探し、ひたすら成果を得るための改善を続けていく──というのが、グロースハッカーの役割だ。
 世にあふれるMA(マーケティングオートメーション)ツールを利用してポップアップ広告用のJavaScriptを追加するような付け焼刃な手段はグロースハックとは呼べないだろう。

アクショナブルメトリクス – Actionable Metrics

 グロースハックにおける、マーケティング用語の一つである。アクショナブルメトリクスという言葉よりも、その実体であるマーケティングモデル「AARRR(アー)」の方が有名なので、それなら知っているという人も多いかもしれない。
 まぁ、「AARRR(アー)」とか「ARRRA(アーラ)」とかだと、まったく必殺技っぽくないので、あえてマイナーなアクショナブルメトリクスを選んだ次第だ。

解説

 グロースハックにおけるマーケティングモデルを示す用語で、アクショナブルメトリクスは「(ユーザが)行動を起こすことができる指標(=行動指標)」のことを指す。いわゆる、ページビュー(PV)やユニークユーザ数(UU)といった何かしらの施策を行った後に結果として現れる指標ではなく、その結果を得るための起因となる指標だ。本来この指標はサービスごとに異なるものであり、その指標を探し出すことがグロースハッカーの真の役割でもある。
 だが、そう簡単にそれらの指標を導き出せないのも事実である。
 そこで、今までの数々のグロースハックの成果から得られた一定の指標をモデルケースとして体系化したものが、アクショナブルメトリクス「AARRR(アー:Aqcuisition Activation Retention Referal Revenue)」である。これは、一般的なWEBサービスにおけるユーザの行動を分類したモデルで、マーケティングにおいて今、力を注ぐべき段階はどこなのかの一つの目安にすることができる指標だ。
 AARRRの構成要素を簡単に紹介しておこう。

  • アクイジション(Aqcuisition):新規ユーザ獲得期における指標(ユーザ数などの量的なもの)
  • アクティベーション(Activation):ユーザ活性化における指標(サインアップ率など質的なもの)
  • リテンション(Retention):継続ユーザの行動における指標(再訪問者数など質・量とも)
  • リファラル(Referal):紹介による拡散指標(ツイートやシェア数など質・量とも)
  • レベニュー(Revenue):収益による指標(サービスの売上など量的なもの)

 サービス黎明期であれば、アクイジションやアクティベーションの成果の最大化を図るべく、それらに関連する部分のシステム最適化、UX改善や分析強化といった施策を“考えてみるべき”というモデルだ。なぜ、施策“すべき”ではなく“考えてみるべき”なのかと云うと、サービスの独自性やその時の状態によって施策するべき箇所は異なるからだ。このモデルが示す指標をまさに道標(みちしるべ)として、その時の状況を勘案しながら、力を入れるべきマーケティングポイントを見つけ出すことこそが、リアルなグロースハックであり、グロースハッカーのやるべきことだ。

アンビエントファインダビリティAmbient Findablity

 IoT(Internet of Things)における新たなるユーザー体験として定義されたアンビエントユーザーエクスペリエンス(Ambient UX)に関連する用語。
 概念に対してようやく技術が追いついて来たような形で、昨年頃から注目を浴びるようになった言葉だ。なので、知らない人が多いかもしれない。
 必殺技の名前として考えると、バフ系がしっくりくる。
 

解説

 アンビエントユーザーエクスペリエンスの概念は、古くは2006年頃からあるらしく、今後のIoTやA.I.といった最新技術が汎用化されていくICT社会を形作る「アンビエント社会」におけるユーザ体験を表す言葉だ。概念としては昔からどこにでもあるありふれたもので、スーパーで買い物している時に見かける商品陳列情報のサインや、待合室で流れるBGM、電車の中で流れているテロップニュースなどがよく例示されている。あまりピンと来ないが、つまりはそれがアンビエントというものらしい。
 アンビエント社会でのサービスは、WEBの検索エンジンのようにユーザ側からのアクションを契機にしないのが特徴で、サービス側からユーザに対してアクションを持ちかけ提供する形になる。例えば、ユーザの「今の」情報をIoTのセンサーなどで取得し、A.I.がそのユーザにとって必要なサービスを推論して、提供を持ちかける──といった感じだ。まさに、近未来的な社会だが、現在のICTを見る限りそう遠い未来図ではないように思える。
 そんなアンビエントユーザーエクスペリエンスの中における、アンビエントな(=周囲を取り巻く環境に溶け込んだような)ファインダビリティ(=検索性、探しやすさ)は、従来のユーザ主体型のユビキタスなファインダビリティとは異なる検索性能の指標となるものである。

 いやはや、長くなったが、今回はここまで。
 また、素敵なICT用語を見つけたら追加していこうと思う。

Leave a Reply

Your email address will not be published.