当社の事業内容は、一般的にはサービス業に属されていると思われがちですが、自分たち自身は製造業になりたいと考えています。製造業を目指しているので、以下の考え方を大切にしています。発展途上な面は、改善の継続で対応することを心がけています。
この姿勢を貫くことが、顧客システムの合理的開発に繋がると考えています。

１．「設計情報を効率的にコンピュータ上に転写することが技術」と考えている
Java、Cなどの言語知識は、道具の使い方を習うのと似ています。まず習得しなければならない基本技術でしょう。
しかし、システム開発で最も重要な技術は、設計図（情報）から、プログラミングし、コンピュータに実装するまでの業務をどう標準化し、その結果自動化するかです。
例えば電気分野であれば配線図、機械製造なら機械設計図をみれば、結果は同じモノが出来上がります。
しかし、残念ながら情報処理分野はこれらに匹敵する設計図（情報）がまだ無いのが実情です。標準化されていないから、職人芸的要素を多く残しているのです。
私たちは、一般の（日本で成功した）製造業を「手本」とし、効率的生産の仕組みを考えています。

２．システム構築は設計から関与する
これまでの経験を通じて、標準化を推進してきました。その中でソフトウエア部品、標準システム（認証、ワークフローなど）を蓄積してきました。

これらの利用は、当社標準設計技法に規定しており、実際に大きな成果が表れてきました。当社がシステム開発に関与する場合は、この標準化に準拠する必要があるので必ず、設計に参加する立場をとっています。そのため、第三者の作成した設計情報を単純にプログラミングする業務は行っていません。

当社事業範囲は、主に基幹事務システムとなっています。販売、購買、在庫、人事などの分野などです。
コンピュータ普及が進んだ結果、新たな業務（クレーム処理、経費精算、日報・工数管理）なども基幹事務システムの派生として取り組んでいます。今後、これらも基幹システムとなるのでしょう。

またSMTP、POP、FTP、HTTPなどのインターネット通信プロトコルとの連携も、事務システムに連動させる目的で範囲としています。

FA分野については、リモート計測分野に取り組んでおり、残塩素濃度測定管理システムなどを手がけました。FA分野は、事務システムなどと異なる技術と思われがちですが、全く同様の技術で、その構築を行っています。 従って、高度な科学技術計算、統計・確率計算以外の分野が、当社が扱う適用範囲であると考えています。

主にマイクロソフト社、Windowsサーバシステムとなっています。Linuxは、現時点で積極的に扱っていませんが、組み込みOSなどに使われている場合にC言語などで、対応しています（バーコード機器など）。

Linux上で動作するアプリが、Windowsでも動作する様になっているので、Apache、PHP、Mysqlについては、注視しています。

言語は、.NET（C#)を基本としています。C言語開発は少なくなってきましたが、かつて利用していた経験者がいるので対応可能です。（C#はCとJavaと一見区別がつかないのでCavaと呼んでいる（笑））

Javaを含め他言語（VB、PHPなど）は、言語の制御構造は同じなので、その都度、対応しています。

当社の開発標準は、目的業務のデータ構造をきちんと設計すれば、システム開発が効率的に行われることを経験的に認識しています。加えてデータを処理する業務ロジックもDBMSに記述すれば、同様に効率的システム開発が行えると確信し、それを推進しています。

現在DBMSはOracleを主としていますが、SQLServerも取り扱いが増えています。DBMSは、SQL以外にトリガーを含む各種プロシジャー、その他オブジェクトを利用するためOracle、SQLServerを開発標準としています。

世間では、オブジェクト指向設計方法論が言われていますが、当社は、DOA（データ指向アプローチ）の推進が、結果的にオブジェクト指向方法論と同様と思っています。

Mysqlについては、高度にプロシジャーを利用しない業務について適用性を模索しています。

表示層、業務ロジック層、データ層に分けてシステム構築を行っています。まず表示層は、HTMLベース、Windows画面いずれかを選択して行います。表示層のプラットフォームの拡大（PC、携帯、組み込み）に備えています。

業務ロジック層は、XML-WEBサービス、DBMSのプロシジャーで行っています。データ層は、Oracle、SQLServer上に展開しています。

１．ウォータフォールモデルの採用
開発工程は、昔からのウォータフォールモデルを使います。一時期、エンドユーザによるシステム開発が叫ばれた時があり、スパイラル型などの試行錯誤型モデルが言われた時期がありましたが、当社としては全く気に留めていませんでした。経験上、複雑であいまいな業務をエンドユーザのみで開発することには無理を感じていたからです。

しかし、当社のそのモデルは次の工夫点があります。修正ウォータフォールモデルです。

• 設計書類作成がPCで行える様になったので、それを実装工程でも利用する
• 例えば、画面、帳票などの外部設計は、そのまま開発ツールに連結する
• DB設計も、設計ツールで作成し、それを実装する

当社のシステム開発は、onMethod/Rule、onMethod/Online、onMethod/Batch、onMethod/Report、onMethod/WorkFlowで、規定しています。

２．開発手順

開発の手順は、概ね以下の通りです。

分析・要件定義工程

構築すべき機能を分析し、文書化する。手法しては、データ項目に着目し、ERDを作成し、DFDを作成する。 設計文書はUMLでとの声を聞くが、DFD、ERDはUMLより前に存在した。情報と機能を整理する点では相違が無いのではないかと思っている。ただ、クラス図が無いので、これはUMLを利用している。クラス図が必要なのは、詳細設計からである。

計画書作成工程

これからどんなシステムをどの様に作るかの共通認識を確保する目的から作成する。

• 目的
• システム概要（外部設計の初期段階）
• ERD、DFD
• 処理方式
• コスト
• 開発体制、スケジュール

ただ、小規模なシステム（20本以下）の場合、難易度などを勘案し、内容について取捨選択する。

詳細設計工程

プログラム仕様書の作成が主な内容である。仕様書には、機能記述とそれをプログラミングレベルまで詳細化した、モジュール設計書などがある。当社では、事務処理に限定されること、プログラムをパターン化し、再利用性を推進しているので、機能記述に止めている。
仕様書の作成は、プログラムパターンを選択することから始まる。

製造・単体テスト工程

プログラミング工程である。パターンが決まっている場合は、穴埋め方式になる。決まらない場合は、通常のコーディングとなる。単体テストまでは、プログラマーが、仕様書に基づいて行う。

総合テスト工程

プログラムを機能単位にまとめて行うテスト。テストシナリオに基づいて行う。テストは、コストを勘案して合理的に行う必要があると考えている。
プログラムはパターン化されており、汎用機時代のテストとは異なると考えている。

移行工程

運用開始のために、マスタ類の整備、マニュアル作成、教育などがある。本工程は、ケースバイケースで行っている。

運用

すべての準備が整った時点で運用となる。