自動化システム 高い生産性

高い生産性

数学的な集合を基盤とする内部のテクノロジーにより開発を圧倒的に効率化しています。
また、自動化やソフト資産を駆使した小規模のソフトウェアパッケージの開発・販売も承っています。

自動化による高速開発に強みがあります。オンラインでのビデオチャットやオンライン資料を用いた学びについて承っています。また、自動化やソフト資産を駆使した小規模のソフトウェアパッケージの開発・販売も承っています。

目次

高い生産性を担保する集合による演算を用いた技術

弊社は、数学的な集合を基盤とする内部のテクノロジーにより開発を効率化する独自技術を持ちます。
この技術には、演算的にシステムの合成や差分の管理ができる特徴があります。
また、MySQLのような集合を記述可能な言語で記述されたシステムとの相互変換や合成が可能です。
集合の写像は様々な応用が可能です。例えば、blade.php, php から ejsなどの他の言語への変換も写像ですし、CSVからJSONへの変換も写像ですし、JSONからデータベースへの変換も写像となりますが、写像を用いて、様々なプラットフォームやユースケースに対応します。

弊社が用いているSQLコマンドを用いてモデリングをするツールの1つをこちらから見ることができます。

モデリングツール

一見すると、SQLのエンジンにみえますが、SQLの上位互換の言語で記述されたモデリング言語であり、GUIを含め、様々なシステムを記述することが可能です。
コマンドベースアーキテクチャ(ABCI:Command Base Architecture)と呼ぶ技術を用いて、データ互換性、モデルの整合性、編集履歴の保存など、様々な仕組みを動作させることが可能です。

言語レベルの写像であれば、トランスパイラーを表すことができます。例えば次のようなものです。phpからejsへの写像変換

このような仕組みを組み合わせることによりより複雑なシステムをメンテナンス性の高い形で開発することが可能です。

なお、この生産性を高めるシステムは
ABCI
と呼んでいるアーキテクチャ理論がバックボーンになっています。

開発に用いている集合システム

簡単な例を示しますと例えば下のような内部言語でプロジェクトを管理しています。集合を扱いやすいSQLと重複部分は多いですがSQLにない記法をいくつか拡張しています。

$groups &object &labels {
  id:unit;
  name:string /key;
  parent_id:unit?-groups.id;
  parent_name:string :="parent.name";
  members:members*-members.group_id;
  subscribers:subscribers*-subscribers.group_id;
}

このような形で複数の集合やその関連を定義していきます。集合型なので継承ではなく、Aspect指向に近いアプローチです。また、テーブルやViewの処理と相性のよい手法です。合成の手法としてアーベル群で一般化する手法をとっています。もともとは逆解析と呼ばれる数値計算に適用することを考えて考案された記法なので、Webシステム以外にも様々なものを記述可能で、システムインテグレーションに適しています。

システムインテグレーションのアプローチとしてはプロジェクトや集合を演算的に合成する手法を取ります。プロジェクトはテンプレート単位で管理しています。合成の種になる集合のテンプレートとしては、下のシステムレベルのテンプレートから、各種共通機能などのコンポーネントレベルのテンプレートまで様々なものがあります。

基本的なコードは自動生成されますが、UIの調整のための生成エンジンもあります。

モデリング環境

実際のモデリングのツールとしては上のようなものを用いています。視覚的に確認しながら作業を進めるため、モデリングにおけるミスが発生しにくくなっています。

自動生成システム

基本的なコードは自動生成されます。laravelで開発をする際に必要となるものは一通り自動生成されます。

部品生成システム

UIの調整のための生成エンジンもあります。例えば、UIは次のようなツールで生成します。

定型的に生成されるコードであるため、ミスは小さくなっています。また、多数のシステムを結合した状態のシステムを細かく分割しているため、あとでシステムインテグレーションすることが比較的容易となると考えられます。

採用している集合型モデリングについて

集合とクラスの最大の違いは直積に分解できるかどうかということで、集合からクラスへの変換はできますが、クラスから集合への変換はできません。直積に分解できる写像が定義できるというのは逆写像が存在することを意味していて、そのプログラミング上の意味は双方向バインディングできるということです。同型写像であれば、中間形式でエントロピー落ちがなければ自明に直積が存在し、双方向バインディングが可能です。実装にエントロピー落ちがないかの証明は M M^-1 のテストシナリオを全ての境界値に対して書けばできます。

SQLは一階述語論理なので、 join × where × offset × limit というように直積に分解でき、逆写像も定義できますが、クラスには自分で定義しなければそのようなものは存在しません。また、SQLで定義したviewに対する追加や削除などの操作は参照するtableにも反映されますが、オブジェクト指向で同じ要件を満たすのはSQLほど簡単ではありません。システムの終端ストレージがSQLである場合、webシステムがエントロピー落ちのない同型写像であることを論理的に証明するにはweb上からSQLを実行できればよいということになります。なお、よくある勘違いですが、セキュリティはエントロピーとは関係がありません。アクセスしてはいけない人のローカルデータとリモートデータが双方向バインディングされてはいけないので。つまり、同型写像プラットフォームにおいては制約条件も写像されるべき対象であるということです。例えばサーバ側で不正値であるデータはクライアント側でも不正値であるこということです。例えば投稿の文字数上限が500文字という制限をイメージするとわかりやすいですが、ブラウザでも入力値チェックをし、サーバでも入力値チェックをします。このように端末やルーターやスイッチやロードバランサやWebサーバやSQLサーバなどアクセスするハードウエアの数だけ実装の重複が発生しやすいため自動化というのは効果的なアプローチとなります。

また、デバイスがわかれる場合、そのデバイスを制御するための記法はすべてまちまちです。一つの要件から派生して生じる要件というものがフラクタル的に増えていく特質があるため、全体を体系的に俯瞰しながら実装していく必要があります。様々なレイヤーのプロフェッショナルを多数抱える企業様であれば問題ありませんが、少人数で進める小さい案件になると全体をカバーするのが大変になります。自動化なりエージェントシステムなりにより、このような手間を省けます。また、サーバサイド、クライアントサイドの担当者がわかれる場合に生じるコミュニケーションコストがなくなることで、より実際的な価値の部分に集中できます。

このような集合を用いた処理が特に向いているのは業務データ処理系や厳格な数値計算系、非集合処理が向いているのはゲームや組み込み領域です。集合型でもオブジェクト指向型でも同じキーワードが頻出しますが、同じキーワードでもアーキテクチャが異なれば全く別物になります。例えばSQL文の中の if expression はフィルタですが、C言語の中の if statement はフィルタとは限りません。集合型は宣言型に書き直せますので、内部処理を除けば破壊的代入のない記法となりますが、組み込みやハードウエア実装ではメモリを節約などするために可能な限り破壊的代入をしますし、目標とするゴールが大きく異なります。