AWSの話題を中心に、日々の業務やプログラミングの徒然を綴るエンジニアブログです。

HANDS LAB

HANDS LAB ENGINEERS BLOG

ハンズラボエンジニアブログ

ハンズラボが採用しているユニケージという謎テクノロジーについて 第1回


自己紹介

はじめまして。ハンズラボの臼井です。

自己紹介を適当な箇条書きで以下に記します。

  • 目の前の業務がどうこうとかのプロジェクトよりも、テクノロジーでつらみを減らしたりワイワイしたい派
  • 強い静的型付け派
  • FBより圧倒的にTw派
  • インドア派
  • 猫派及びアルパカ派

派が多くてゲシュタルト崩壊しそうです。
以後よしなに。

はじめに

東急ハンズ/ハンズラボの開発事例については、当社代表の長谷川が各媒体にて紹介していますが、
その中でしばしば出てくる 「ユニケージ開発手法」 というものが、ハンズラボの技術の中核を占めるもののひとつになってます。
この手法の採用事例については、検索して頂ければ、ビジネス観点からはいくらかヒットするので概観は掴めます。
しかし、技術の観点からについては、USP研究所様による公式サイト、及びOSS版のリポジトリ 以外は殆ど情報が無い、というのが現状です。

ここでは、できるだけフラットな観点から、ユニケージ開発手法について主に技術的な観点から説明します。

当社の事情等を交えつつ、ちょっとだけビジネス寄りの視点も加えたりします。

この記事の主な目的は以下です。

  • 当社に興味を持って下さっているエンジニア各位の、ユニケージなにそれこわい、という気持ちに対して、正しい判断材料を提供する。
    • こわいのままでもいいし、こわくなくなってもいい。
    • エンジニア採用にあたり、マイナーな開発環境を使用しているにもかかわらず、これについて十分に情報を公開しないのは、ちょっとフェアじゃないかもなーという思い。
  • データフロープログラミングってどうなんだろうね、という提起。
  • 筆者の知識の整理。

エモさを抑えて、ポエムにならないように頑張ります。

いきなり結論

本論にて長々と説明していきますが、結論から言うと、

ユニケージ開発手法とは、
規約に従いよく整理されたディレクトリに配置されたフラットファイルをシステムのデータストアとみなし、
バッチ、Webアプリケーション含めたシステム全てをデータフロープログラミングで構築する為の、
テキスト処理特化コマンドセットを用いたDSLである。

といったところでしょうか。
※上記は筆者の見解であり、USP研究所様、及びハンズラボの公式見解ではございません。
なおデータフロープログラミングの定義は、Wikipedia の当該の項を参照しました。
データフロープログラミング – Wikipedia

以降、サンプルコードを用いて解説していきます。
長くなりそうなので、数回に分けてマイペース連載します。
# いきなり連載かよ、というツッコミを社内でくらいましたが……

基本はフィルタ処理

ユニケージ開発手法で使用するコマンドは、殆どが特定の 標準入出力を行う単機能コマンド です。
複数のコマンドを*nix系OSのパイプで繫ぎまくって、
目的の出力を得る ために入力を処理していく、という流れです。

フィルタ処理の例

実務でありそうな処理の例を以下に引用します。
引用元 : UEC – usp engineers’ community – UECジャーナル ユニケージエンジニアの作法その六 「1プログラム1役」を徹底せよ

各コマンドの処理内容や可読性について議論も出来ますが、それはさておき。
大事なことなので殆ど同じ事を繰り返しますが、概ね上記の様に、
標準入出力をフィルタ処理してパイプで繫いで、目的の出力を得る、という流れだけ理解して下さい。
ユニケージでのプログラムのロジックの殆どは、上記の様な処理にて成り立っています。

制御構文は最小限に

また、可能な限り if, for, while などの制御構文を用いず、
フィルタ処理のみで結果を出す、という原則があります。
データフローが見えづらくなるという点と、
シェルスクリプトにおけるforやwhileは他言語のそれらより十分に遅い、
という2点から、この原則があると理解しています。
forやwhileの遅さについては、実験してもらえればわかりますが、シェルスクリプトのそれらは文字通り桁違いに遅いです。
実際に100万回のforループで、内部で何もしないコードを実行すると、一目瞭然です。

あえて再利用性を捨てる

所詮は表形式フラットファイルを適切に操作するだけなので、
ExcelやAccessなどの経験は多少あるが、
普通のプログラミングをしたことのないノンプログラマでも、
初級レベルの習得が容易である、ということが、ビジネス上の採用理由と考えています。
抽象化や再利用性を一旦放棄し、
既に存在するデータからその場で欲しいデータを最速で得るためにはどうしたらよいか、
という事にフォーカスしていると解釈しています。

そして元販売員エンジニアが産まれた

ノンプログラマが高速でアウトプットを出せるようになり、
さらには初級プログラマへの短期間での成長が他開発環境に比べ比較的容易
->業務を理解するエンジニアが社内から何十人も成長した
というのが、長谷川が各所で喋っている、
“販売員をエンジニアにすることで要件定義コストを軽くする”
ということの背景になっています。

初級プログラマの定義ですが、ここでは、
研修レベルを超えており、社内外問わず主に設計に従って実装を行うメンバーとして実プロジェクトに参加できる程度の能力
くらいに捉えて下さい。

次回以降の内容

次回は、通常の手続き型やオブジェクト指向言語の記述と対比させながら、
具体的なデータ例を用いて解説します。

その先については未定ですが、
ユニケージ開発手法の適用可能範囲や、
pros/cons について正面から議論することを予定しています。
予定が変更になった場合はお察し下さい

おまけ

余談ですが、筆者は最近ユニケージあんまり書いてなくて、
主に PHP + Elastic Beanstalk + DynamoDB な感じの環境でJSON吐き出す機械を作ってます。
このあたりの環境については、その内井上が解説してくれると期待。

第2回はこちら