ユニケージ "Unicage"

1.ソフトウェアの特徴

標準環境の考え方

ユニケージのシステムは、UNIX系のOS＋シェルスクリプトのみで構成されています。UNIX系のOSであれば、必ずシェルは実装されているので、ユニケージ自体、UNIX系OSであれば、それらすべてで動作します。

ユニケージは移植性を高めるために、OSやシェルの方言の使用をなるべく避け、その基本機能だけを組み合わせてアプリケーションの構築を行います。

従来の移植性確保の考え方が、多岐にわたるOSやミドルウエアのラッパーを作成し、標準的な開発環境を用意することを指向しているのに対し、ユニケージは、標準的なハードウエアの上で、経年劣化しないメインストリームOSを選び、その中のさらに標準的なコア部分のみを選んで、移植性を担保するという道を選んでいます。

これにより、ソフトウエアのクッション層を省き、ハードウエアのスピードアップを直接享受することができるのです。ユニケージはソフトウエアの進歩は、階層化することでなく、なるべく数少ない良いものの組み合わせを見出すことにあると信じています。

小さく効率的な部品

シェルスクリプトの中核をなすソフトウエアはコマンドです。しかし、従来のUNIX系OSに標準に実装されている sort や cat コマンド等だけでは、業務処理には足りません。

UNIXにはユーザー自身が独自コマンドを作成する楽しみが残されています。私たちは、過去2000以上のコマンドを作成し、現在はそれらを数十個のコマンドに集約しています。

ユニケージオリジナルコマンド自体は多機能でもありませんし、奇をてらったものでもありません。例えば、self/delf (列の選択) join1/loopj (データの結合)など、単純な見た目で、その外部仕様が分かれば、多くの人が独自にソースプログラムを記述して、同機能のコマンドをつくることができることでしょう。

ユニケージの独自性の一つは、このコマンド群にあるのは確かですが、コマンド自体に秘匿性の高いノウハウがあるものではありません。それは、ナイフ、フォーク、スプーンの発明に似ています。それらの食器の見た目は、誰でも理解可能なものですが、それは長年の経験の中で、シンプルに纏め上げられてきたものです。ユニケージオリジナルコマンド群は、システム構築の基本的な要素部品からなっており、誰でも理解可能で、利用可能です。

ユニケージにとって、優れたシステム技術とは、一部の人にしか理解できない複雑さや難解さに基づくものでなく、優れたアイデアをだれでも理解可能なシンプルな技術で実現し、卓越したセンスと多くの経験の中で磨き上げられたものであると私たちは確信しています。

2.データ配置の特徴

テキストデータ

ユニケージのデータはテキスト形式を基本としています。

単純な行列の形式から、ヘッダーと明細の組み合わせ、あるいはXMLのようなタグ形式など、幅広い範囲をサポートしています。そして、フラットなテキスト形式ファイルをUNIXのディレクトリ構成にしたがって素直に配置しています。業務で発生したデータを種類ごとに分類し、時系列や項目単位など比較的小さな単位でファイルに保存します。巨大な1ファイルに多く種類と量のデータを蓄積することはしません。

こうやって発生した情報を小分けして分類整理することにより、プログラムによるデータの扱いを容易に、かつ効率よく処理することができるのです。

LEVEL1-5

ユニケージは大福帳方式です。発生するデータ（トランザクション・データ）を要約せずにそのままファイルに保存します。入力業務を例にとると、1エンターにつき1ファイルが生成されます。ファイルの数は膨大になりますが、最近のハードディスクの大容量化は、企業レベルの発生データを無限期間保存するに余りあります。生明細データは発生事実であり、すべての企業情報システムは発生事実の編集が基本であるので、生明細データの保存が何よりも重要であると私たちは考えます。

LEVEL1は生明細データであり、テキスト形式とは限りません。また、LEVEL1は非同期で発生することが多いのも特徴です。

LEVEL2は、LEVEL1のデータを毎秒、毎分、毎時、毎日のように同期的にシステムに取込み、情報処理のタイムテーブルに乗せたものです。通常LEVEL2はテキスト化され、イレギュラーデータは取り除かれます。

LEVEL3は、LEVEL2データを項目ごとに分割したり、時系列に整理したり、業務上意味のある項目、例えば利益などのファイルに分類整理したデータです。

LEVEL1-3のデータはデータの発生、取込、整理という一連の流れで処理され、発生データの種類ごとに整理されます。一般の企業において発生データ種は数十から数百前半くらいといわれています。

LEVEL4データは別名アプリケーションデータと呼ばれ、アプリケーション（画面や帳票、他システムへのＩ／Ｆ）単位に、その出力に便利な項目で予め構成されたファイルです。複数のアプリケーションで共有するLEVEL4は存在せず、各LEVEL4に内容の重複があっても気にしません。

LEVEL5は出力データです。ユーザーダウンロードデータやログなど、システムが動作したりユーザー操作によって発生したデータを指します。これらを常に保存しておくことにより、システムの使用程度、稼動効率を調査したり、システム監査業務に利用したりすることができます。

3.完全分散型システム

完全分散

日本語では、「分かる（understand）」と「分ける（divide）」とは同じ字を充てます。つまり理解することと分類するということは同義です。

ユニケージは「理解＝分類」をサーバー配置、ソフトウエア配置、データ配置に反映させます。

分けることにより、サーバーやソフトウエアやデータの役割が明確化します。役割特化された対象には、役割以外の余計な機能や内容を持たせません。このため、処理は無駄が無く速いのです。機能は必要になったところで積み上げればよいという発想を持っています。

２つめの考えは完全です。完全とは自立可能という意味です。

自立サーバー群はそれぞれ自分の仕事を行い、仕事の結果を他サーバーに自他の必要に応じて連携します。人間社会は、それ自体が自立した個の集合体ですから、個のサポートを行うシステムも人間社会のアナロジーであるべき、との考えが根底にあります。

完全分散型システムの各サーバーは個の仕事と対になっていて、互いに仕事の結果を交換しながら全体の仕事を進めます。このサーバーネットワーク形態をコンピューターズ・コミュニティと呼びます。

疎結合された各サーバーは、環境や内的要因にあわせてアメーバのようにその数や組み合わせ方を変えていくことができます。

共有と全有

自立サーバーには自身が必要とするデータがあります。全体でみればそのデータには重複があるでしょう。ユニケージでは一元化のドグマに囚われることなく、重複分散を認めています。そして、同じデータを一箇所に集めるのでなく、同じデータを必要とするところにコピーを配るようにしています。すなわち「共有」するのものは「全有」してよいという考えです。「全有」することにより、各自は自分の都合でデータを加工したり、アレンジすることができます。

全有データはサーバー単位にとどまらず、サーバーのアプリケーション単位にまで及びます。つまり各アプリケーションは、自身が必要とするデータを自分自身で独占所有できるよう、データを配置しています（LEVEL4）。

アプリケーション自身にも全有の考え方が適用され、各アプリケーションはいわゆる共有ルーチンを呼び出すことはありません。似たような処理があっても、それぞれのソースプログラムの中で完結されているのです。

プログラム内部構造も共有分が錯綜しないよう、ワンプログラムワンフローの原則を貫いてます。（ユニケージはシェル関数の記述さえも基本的には禁止しているのです！）このような全有ポリシーにより各サーバー、各アプリケーションの完全独立性が確保され、自身の仕事を自身のリソースと能力でいかようにも進歩させられる環境を作っています。

ユニケージにおいては、他者に迷惑をかけないよう、常に関係者と相談し、自分の仕事については常にリスクをマネージしながら、自身で判断する自律的な仕事の仕方を理想としています。

4.開発方式の特徴

一休さん方式

ユニケージは、データをいかに安全確実便利に使うかに集中しています。ソフトウエアは作り直しが利きますがデータは失うと二度と戻りません。

ユニケージは目的に対し真っ直ぐにアプローチしなければならないと考えています。データの利便性を向上させるために、必要な実データをまず全部取込んで、各サーバーや各アプリケーションにうまく届けるようソフトを調整しながら組みあげていきます。

ソフトの仕様を固めて、ソフトを組んでから最後にデータを流すという回りくどいことをしません。実データは仕様書よりも「現実的な」情報が多いのでユニケージはプロジェクト当初に要件定義より先に実データをすべて準備することに拘るのです。

一休さんは、屏風に書かれた虎を見事捕まえてみよ、という難題を前に、「さあ、すべて準備は整いました。私が虎を縄で縛りますから、虎を屏風から出してください。」という頓智で場を切り抜けた逸話がありますが、ユニケージは一休さんにならい、データという虎を見事捕まえるために、まずデータを全部出してもらうことを要求します。さらに、実データを使ってプログラミングすることにより、単純な動く動かないの単体テストはプログラミングの過程でクリアでき、開発効率も向上するのです。

床屋方式

床屋に行くと、始めに何センチ切るのか、ハサミかバリカンかを聞いて仕事に取り掛かり、ある程度切った段階で、もみ上げはどうするのか、分け方はどうするのか、リキッドはつけるのか等々の仕上げ具合を聞かれます。

切られてしまったあとで、ロングヘアーがやっぱりよかった、と言う客は滅多いないでしょう。この接客手法は秀逸です。２回のリクエストで、誰相手でも仕事を完成させます。

どんなシステムでも骨格となる仕様と、あれば便利という仕様に分けることができます。

骨格となる仕様は、システム化して本来的に「やりたいこと」を実現できる仕様であり、それさえ出来れば、最低限目的を達する仕様のことです。そのような仕様はシステムの目的が決まると、短期間に詰まります。画面の美しさや操作性はその限りではありません。このレベルでユニケージは一度システムを短期間で完成させます。それは画面が見苦しくて操作性が悪いということではありません。本来目的達成までの時間を優先しているのです。

リリース後、２度目のリクエストを聞きます。そのリクエストは便利機能や更なる操作性です。ユニケージは簡易なシェルスクリプトで記述されており、２度目のリクエストを反映させることはさほど難しいことではありません。

5.ドキュメンテーションの特徴

実用的で、少量で済む工夫

ユニケージにおいては、開発のときに必要なドキュメントは少量で、保守のときに必要なドキュメントは実用的に、がコンセプトです。

1. システム全体図（サーバー配置図、ネットワーク、データフロー、アプリケーション配置図などが入ったもの
   ……紙さま）を作成します。
2. ユニケージシステムで管理しているデータ（レベル１～３）の、レイアウトや項目の意味を記したオンラインドキュメントを作成します。
3. 業務フロー図を作成して、業務全体を理解し、画面図を作成して、項目やロジックを理解します。

ドキュメントが少なくて済む理由は、ユニケージはデータの入出力のシステムという簡単なアーキテクチャであり、システムの骨格はお作法に基づいているからです。全体が分かる紙さまを見て、システムの全体の外形をつかめば、あとは詳細をたどって理解できる構造になっています。

システムは生物

ユニケージは「システムは生物」という考え方を持っています。企業は常に社会やマーケットの変化に合わせ、適応し続けなければならない宿命にあります。このため、企業の戦略、戦術は常に変化し、それを支えるシステムは変化しなければいけません。

ユニケージはこれら変化するシステムの内容を、システム自身が出力できるように設計します。運用スケジュールや各プログラム間の関係、すべてのデータのレイアウト、詳細設計など「変化しうる」内容について、自動出力し、ドキュメントを生成します。

このようなことができるために、システムの作り方やプログラムの記述に一定のルール（お作法）が存在します。例えば、シェルスクリプトは各処理ブロックごとに、その入力ファイルと出力ファイルのレイアウト、処理内容について「必ず」記述しなければなりません。これは詳細仕様書に相当しますが、この記述ルールは必ず守られます。なぜなら、お作法チェッカープログラムが、ルール外のスクリプトを見つけ出し、リリースをストップできるからです。

ユニケージには、多くの「お作法」が存在し、ドキュメントの削減に寄与しています。例えば「ワンプログラムワンフロー」の原則や、「アプリケーション固有のLEVEL4」の作法は、複雑になりがちなプログラム間の相互関係の記述やテストを不要にしています。

従来のドキュメントが、システム変更に対し「変更履歴」を積み重ねるのに対し、ユニケージはドキュメントは「AS IS（現況）」の積み重ねでよいと考えています。システムは生物であり、子供が成長していく様を「変更履歴」でなく各時代の様子をつぶさに記録しておけば十分足りるのです。どうしても各時代の「差分」が欲しければ、diff コマンドを使えばよいのですから。

子供が大人のDNAのコピーをもらい、独自の発展をするがごとく、ユニケージもアプリケーションのコピーをもらい、独自に改良できることが自然であると考えています。また、ユニケージでは Copyright は著作者を守る権利でなく、コピーする権利であると真面目かつシニカルに考えています。優れたソースは、多くの子供たちにコピーされ、原著作者は尊敬の対象となるのです。

6.教育・育成プログラムの特徴

多能工

ユニケージエンジニアは多能工です。サーバーの選定、セットアップ、ネットワーク設計や設定、データI/Fシステム、データ整理システム、アプリケーション作成、運用システム作成、保守メンテナンスに至るまで、「何でも屋」を志向しています。ユニケージは多能工こそが、システム開発の現場力と改善力を生み出すと信じています。自分自身で仕事を完結させられると、仕事は圧倒的に楽しくなります。顧客の喜びがモチベーションとなって、辛い難局も乗り越える忍耐や努力も身につきます。ユニケージは多能工を育成するために、習得すべきことの総量を減らすための技術向上を目指しています。
例えば、ユニケージは、すべてのシステムをデータの入出力という観点で３つの単純なシステム（入力、整理、出力)で理解します。すべてのシステムはシェルスクリプトで記述され、テキストファイルで相互に情報を伝えます。
このような単純さの上ですべてのシステムを開発するので、ユニケージを習得すれば、一つの完結するシステムを一人で開発できるようになるのです。

コミュニケーション

システムは使う人がいて初めて意味を持ちます。使う人とコミュニケーションが十分に取れなければ、良いシステムは作れません。ユニケージはよいコミュニケーションのために、プロジェクトの環境や人間関係が大切であると考えます。

プロジェクトは関係全部署のメンバーからなり、対決ではなく、調和をはかるよう運営されます。プロジェクトには強力なリーダーが必要です。そして、目先の作業を詰める会議だけでなく、仕事の意義や、仕事を支える環境などについて、自由に話すことができる明るい雰囲気が必要とされ、その雰囲気作りはリーダーの役割とされています。

ユニケージプロジェクトの成功の鍵は、システムの目的や骨格についてすべてのプロジェクトメンバーが共有することにあります。コミュニケーションを通じて、業務を正しく理解して、より良いLEVEL3などのデータ構造を決めることが肝心と考えています。

育成プロセス

人材の育成は訓練(discipline)です。教育(education)はプログラムでは行えないと考えています。訓練は優秀な人材を生み出すのでなく、形式を身に着けさせ、一定レベル以上のサービス水準を保証するためです。訓練の初期段階は「すべて従う」ことと「いつでもどこでも」がキーワードとなります。ユニケージ作法を大量の練習問題で身につけ、ユニケージの熟練エンジニアの行動や考え方にできるだけ長時間触れることがよい訓練です。座学の理解ではなく、作法や思考方法が自然に出てくるまで身につけることが大切です。これは学習ですから、報酬をもらう性質のものではありません。

訓練の中期段階は、実務経験を積み、成功を積み重ねることです。失敗することもあるかもしれませんが、失敗の経験も自力で工夫する力を身につけるよいチャンスです。成功パターンを見出し、成功パターンにむけて調整ができる力を身につけ、それを繰り返すことにより、自信をつける段階です。この時期は成功に応じて、報酬を与えるべきで、報酬自体がモチベーションになってもよいでしょう。
最後のステージは熟達のステージです。プロジェクトリーダーを務める者のキーワードは、「スピード」と「細心」です。長時間仕事をすることを止め、いかに短く早く仕事を終わらせるかの工夫を行います。スピードが無いがための副次的問題を解消し、本質的な問題に集中します。時短はメンバーの健康と意欲維持にも寄与するでしょう。

プロジェクトを失敗させるどんな問題もはじめは常に小さく現れます。リーダーはこの小さな問題を看過せず、細心をもって丁寧に対処します。例えば、開発効率を高める技法の議論は時間をかけるべきであり、メンバーの参加意欲や表情をつねに気にすべきです。熟達ステージの評価は、納期どおりの納品は勿論、開発システムがもたらす効果と、プロジェクトメンバーの育成にも焦点があたります。

7.ビジネスモデルの特徴

ユニケージのビジネスモデルは「教育と初期構築とサポート」です。

開発パートナーや自社開発を目指すユーザー企業に、ユニケージの基礎教育を行います。初期システム構築をUSP研究所がメインで担当しながらOJTとして開発パートナーやユーザー企業の教育を行います。メインのシステム構築やその後のメンテナンスは開発パートナーやユーザー企業で担当してもらいます。

リリース後は、ユニケージライセンスやサポート業務でビジネスを行います。USP研究所のビジネスモデルは、ユニケージそのものをオープンにして、様々なシステムで広く使ってもらいながら、ユーザー企業、開発パートナー、USP研究所の三方良しを指向しているのが特徴です。