国の再生可能エネルギー固定価格買取制度(FIT)満了後のスイッチングを支援するシステムを開発。シームレスな申請手順と外部連携機能で業務効率化に貢献しました。
リリースタイミングに合わせた仕様調整力で、顧客の要望に柔軟に対応しました。

技術要素

• Java11
• Spring Boot 2
• Thymeleaf
• JQuery
• PostgreSQL

プロジェクトの特徴

• シームレスな申請手順
  ブラウザの読み込みを最小限に抑えた快適な操作性
• OCCTO連携機能
  外部機関との連携による業務自動化
• 柔軟な仕様調整
  リリース時期に合わせた迅速な対応

成果

• スイッチング業務の効率化
• ユーザー満足度の向上
• 外部連携による業務自動化
• 期日厳守のリリース

Altus-Fiveの強み

リリースタイミングに合わせた仕様調整力と最新技術への対応力で、顧客の要望に柔軟かつ迅速に応えることができる点が弊社の強みです。

The post 05 電力会社様向け卒FITシステム開発 first appeared on 株式会社Altus-Five.

エネルギー関連企業の会計システム移行やセキュリティ基準対応を支援。複数システムの知識を活かし、安定運用と業務効率化に貢献しました。
弊社がリーダーとしてプロジェクトを推進し、専門性とマネジメント力で価値を提供しました。

技術要素

• COBOL
• Java
• Biz/Browser
• Oracle
• OBIC7

プロジェクトの特徴

• 会計システムの移行
  老朽化した会計システムから新システムへ円滑に移行
• I/F切り替え対応
  関連システムの知識を活かした柔軟な対応
• PCIDSS準拠
  セキュリティ基準に沿ったシステムバージョンアップ

成果

• 会計システムの安定運用
• セキュリティ基準への適合
• 業務効率化の実現
• 顧客満足度の向上

Altus-Fiveの強み

専門性とマネジメント力を活かし、複数システムの連携やセキュリティ対応など複雑な課題もリード。顧客中心のチームでも主体的に価値を発揮できる点が弊社の強みです。

The post 04 エネルギーグループ会社様の業務をサポートするシステムの開発・保守・運用の支援 first appeared on 株式会社Altus-Five.

医療機器メーカー様向けに、精度管理システムを再構築・機能拡張・保守運用まで一貫してご支援しました。
従来は Java + RDB による構成でしたが、大量データ処理の限界に直面していました。そこで弊社は、HPE Ezmeral Data Fabric – Customer Managed (MapR) を活用した新アーキテクチャを導入。大幅なパフォーマンス改善を実現させました。

特徴・導入効果

• 大規模データ処理基盤の導入
  • MapRとSparkを活用し、精度管理データの集計を高速化。
• リアルタイム処理
  • MapR DB + ojai によるリアルタイム計測を実装。
  • フロント画面には Highcharts を採用し、計測結果のグラフ表示を実現。
• 継続的な進化
  • サーバーサイドからクライアントサイドまで、機能追加・保守運用を継続。
  • 高度なデータ処理からUI/UX改善まで、ワンストップで支援。

技術要素

サーバーサイド

• HPE Ezmeral Data Fabric (MapR) / MySQL
• Java / Spring / Scala / Spark / Kafka / Drill / Elastic Search / R Script

クライアントサイド

• Angular / Angular Material / TypeScript / RxJS / Node.js / Highcharts

成果

本プロジェクトにより、医療機器の精度管理に関わる 大量データを効率的に処理 できるようになりました。
その結果、

• 計測・集計のスピード向上
• データの信頼性確保
• 分析・改善サイクルの短縮化

を実現し、医療現場における品質向上・業務効率化に大きく貢献しました。

Altus-Fiveの強み

• 効率的なフロントエンド開発
  • フロント画面再構築では Angular Material をベースとしたデザインテンプレートを活用し、工数削減と品質担保を両立。
• バックエンド～フロントエンドまで一気通貫対応
  • データ基盤、リアルタイム処理、フロントの可視化までワンストップで提供。
• パフォーマンスと信頼性の両立
  • 医療機器分野において求められる「高精度 × 高速性 × 安定稼働」を実現。

本案件のように 大規模データ処理・可視化システム の開発・運用に強みを持っています。
「パフォーマンス改善したい」「大規模データを効率的に扱いたい」といった課題をお持ちの企業様は、ぜひご相談ください。

The post 03 医療機器メーカー様向け 精度管理システム first appeared on 株式会社Altus-Five.

多様な派遣案件の中から IT系案件に特化 した検索ポータルを開発しました。
ITエンジニアとして働きたい求職者が、希望条件に沿った案件をスムーズに探せるように、直感的で高機能な検索体験を実現しています。

主な機能は以下の通りです：

• 全文検索によるキーワード検索
• スキル・勤務地・単価など、多様な検索軸による条件絞り込み
• レコメンドエンジン（協調フィルタリングを活用）による関連案件の提案
• ブログポータルサイトとの連動による情報発信
• 面談予約機能でスムーズなマッチングをサポート

技術要素

• Java / Spring Boot / JPA
• Apache Solr （全文検索）
• Apache Mahout による協調フィルタリング（レコメンド機能）

プロジェクトの特徴

この案件では、以下のような点で高い評価をいただきました：

• 超短納期でのリリースを実現
  限られたスケジュールの中、アーキテクチャ設計から開発・テスト・リリースまでを一気通貫で対応しました。
• 要件定義から弊社エンジニアがリード
  ご担当者様がシステムに詳しくなかったため、要件整理から開発に至るまで弊社が主体的に推進。ユーザー視点を踏まえた提案を行い、実務に即したシステムを構築しました。
• 検索精度 × 利便性の両立
  IT案件特有の検索ニーズを反映し、ユーザーが「探しやすい」「見つかりやすい」検索体験を提供しました。

成果

• エンジニアと案件のマッチング効率が大幅に向上
• レコメンドによる案件発見が増え、求職者の利用満足度が改善
• 導入企業様にとっても、案件紹介・面談設定のプロセスが効率化

Altus-Fiveの強み

本案件のように、システムに不慣れなお客様でも安心してお任せいただけます。
要件定義からリリースまで、私たちが伴走しながら、短期間で「本当に使えるシステム」を実現します。

The post 01 人材派遣会社様向け IT案件検索ポータル first appeared on 株式会社Altus-Five.

TERASOLUNAは、Spring Frameworkを中心としたOSSの組み合わせで構成されたフレームワークです。
開発ガイドも、公開されていて、とてもよくまとめられています。
OSSの組み合わせということで、TERASOLUNAじゃないプロジェクトでも、こちらのガイドラインに記載されているベストプラクティスを何度となく参考にさせていただきました。

プロジェクトの立ち上げ

ここでいう”プロジェクトの立ち上げ”とは、実装フェーズの準備を指しています。
大まかに、やることは、こんな感じじゃないでしょうか？

• 開発キットの準備
  開発チームのメンバーに、ローカルPCに開発環境を構築するための手順書を準備する。
• リポジトリの準備
  ソースコードを管理するために、社内のGitlab等にリポジトリを準備する。
• CI環境を準備
  社内の開発用サーバーにJenkinsとNexusを準備する。
• サンプル実装
  実装のお手本となるサンプル実装を作成する。
• 規約や方針を整備
  コーディング規約や、開発方針（モデリングやトランザクション、CSRF、RPGなどの適用方法など）を整備する。

準備が悪いと、手戻りが多く、実装中に迷いがちになるので、開発効率に影響がでます。プロジェクトに先駆けて、できるだけ整備したいところです。
でも、上流工程が長引いて・・・などの理由で、準備に十分な時間をかけられないケースも、よくある話です。

私が、TERASOLUNAのプロジェクトを初めて手掛けたときは、JenkinsなどのCI環境の構築から、チーム内でCIが運用されるまでに、1カ月以上かかりました。実装フェーズが始まって、しばらくしてCI環境が稼働したため、Jenkinsからのエラーレポート対応で、本来のタスクが停滞したことを記憶しています。

スターターキット

プロジェクトの立ち上げ時の毎度毎度で、CI環境構築に1人月もかけてられません。
それならばとJenkins職人を育成するのも、どうかと思います。

そこで、TERASOLUNA用のCI環境の自動構築と、開発チームへの配布キットを自動生成するスターターキットを作りました。
https://github.com/altus5/terasoluna-starter-kit

~/bin/setup-ci.shを実行すると、ネットワーク内のサーバーにCI環境が作成されて、~/bin/create-development-kit.shの実行で、TERASOLUNAのブランクプロジェクトでリポジトリが作成され、配布する開発キットも同時に作成されます。

以前は、1カ月くらい準備に時間がかかっていたのに、2つのスクリプトで、わずか30分で実装フェーズの準備が整います。

ただ、このスターターキットは、もともと社内の開発用に作成したものなので、前提とする条件がエグイです。
実際には、プロジェクトに応じて、多少のアレンジが必要だと思いますが、スターターキットのひな形としては、使えるんじゃないでしょうか？

カスタマイズにお応えします。

さて、ひな形として使えるとは言え、そのカスタマイズに、1、2週間かかってしまったんでは、スターターキットの意味がありません。
貴社の貴重な”開発するための時間”を、その準備のために消費するのは、勿体ないです。
いっそ、スターターキットの制作を、弊社にご依頼されてみてはいかがでしょうか？低コスト短期間で、ご要望にお応えできると思います。
まずは、お問い合わせくださいませ。
貴社の開発環境とプロジェクトに合わせたカスタマイズ要件をお聞きし、お見積致します。
※TERASOLUNA以外のフレームワークも、対応可能です。

お問い合わせはこちらから

The post TERASOLUNAの開発環境を30分で整備するスターターキット first appeared on 株式会社Altus-Five.

Web Performer（以降WP）とは、超高速開発というジャンルに分類されている、 システムを自動生成するツールで、キヤノンITソリューションズさんが開発されています。
弊社では、このツールを使って、システム開発のスピードアップにトライしています。
超高速開発と言われているツールには、他にも、GeneXus や、Wagby などがあります。
WP と GeneXus については、説明会に参加させていただき、Wagby については、 評価版を利用してみて、最終的に、WP を利用することにしました。

この3つのツールに共通しているのは、確かに自動生成してくれるのだけど、 すべての要件を100%自動生成できるわけではないということ。
やはり、複雑な処理は、追加で実装したり、外部に補助システムを構築したりして、100%じゃない部分を補完する必要があります。
自動生成して、時間を圧縮しても、この機能拡張の開発にもたついてしまうと、 せっかくのアドバンテージが無くなってしまうので、機能補完というか、機能拡張のやり方に、 それぞれのツールを有効活用するコツがあるように思います。

WPの場合は、拡張機能部分は、追加実装していく方式です。
自動生成されたコードは、修正しないで、機能拡張用のクラスを追加実装していきます。
その開発方法も、開発ガイドに準備されていて、わからない場合は、 サポートサイトが用意されているので、Googleで検索する代わりに、 そこに問い合わせをして、解決策を得る感じになります。
弊社が Web Performer を選択した理由の1つは、このサポートが手厚そうなところでした。

Spring Boot化

さて、WPを使った開発の中で、私たちで工夫してきたことが、いくつかあるので、ご紹介します。
記事タイトルにもしましたが、WPが生成したコードを Spring Boot 化する方法になります。

WPで出力されたコードは、Spring 4 に対応していますが、 Spring Boot ではありません。
弊社は、WPを使った開発もやっているけれど、スクラッチでの開発の方が、 開発機会としては多くて、Spring を使った開発だと、最近では、Spring Boot です。

弊社流のWPを活用した開発は、WPで典型的な実装を自動生成して、複雑なロジックの実装は、Spring Boot で実装するというやり方を採っています。 特にスクラッチの開発に慣れた人には、合ってるように思います。

※ここで紹介するやり方は、キヤノンITソリューションズさんでは、推奨していませんし、サポート対象外になると思うので、自己責任の元、行ってください。

mavenプロジェクトにする

WPを使うと、クラスのコンパイルまでやってくれるし、依存 jar なども、 自動的に配備してくれるので、mavenを使う必要はないのだけど、 Spring Boot化するには、mavenか、gradle プロジェクトにする必要があります。
弊社では、mavenプロジェクトにしました。

mavenを使うメリットは他にもあります。 WPは、インストールベースでライセンスが発生しますが、出力されたコードを使う分には、ライセンスが発生しません。
機能拡張の部分は、普通にJavaのクラスで実装するので、WPが無くても開発できます。 極端な話、WPでコード生成する作業を1台のPCで行って、生成されたコードをソース管理のリポジトリにコミットして、共有しておけば、他のPCでは、共有されたコードを使って、WPなしで機能拡張部分を開発することができます。
WPのインストールが不要なら、その分のライセンスも節約できます。

以下に pom.xml を作成する場合のポイントを整理してみましたので、参考にしてください。

プロジェクトの構成を分割する

弊社では、4つのプロジェクトに分けました

1. 以下のプロジェクトのまとめ役としての親POMプロジェクト
2. WPが生成するjspやWEB-INF配下とSpring Bootの構成ファイルをパッケージしたメインのwarプロジェクト
3. WPが生成するjavaソースコードをまとめた jarプロジェクト
4. 機能拡張部分の jarプロジェクト

上記の2と3は、1つでも良いのですが、4から3の中にある機能を利用する可能性を考慮するなら、分けておくと良いと思います。

WPが依存するjarを洗い出す

WPが利用しているjarを洗い出して、pom.xmlに追加します。

jarをリストアップ

WPでアプリケーションを生成したら、出力されたディレクトリにある、WEB-INF/lib の中にある jar をリストアップします。

pom.xml の dependency に追加

jarファイル名と、ファイル名にあるバージョン番号を手掛かりに、mvnrepositoryで検索して、pom.xml の dependency に追加します。

詳細がわからないjarの対応

jarファイル名だけでは、バージョン番号がわからないとか、mvnrepositoryで検索しても、見つからない jarがあったりします。もとより探すこと自体が面倒でもあります。
弊社では、groupIdを独自のものにして、mvnのローカルリポジトリに追加することで対応しました。可能なら、nexusなどのプライベートリポジトリを使った方がよいと思います。
例を示します。
commons-validator.jarというファイル名だけでは、バージョンがわかりません。ファイルサイズを手掛かりに、mvnrepositoryで検索すると、versionは、1.4であることがわかったのですが、それ自体面倒です。

• 本来の正しい dependency

<dependency>
<groupId>commons-validator</groupId>
<artifactId>commons-validator</artifactId>
<version>1.4</version>
</dependency>

• 独自の dependency を作ってローカルリポジトリに登録してしまう

<dependency>
<groupId>jp.altus5.webperformer</groupId>
<artifactId>commons-validator</artifactId>
<version>2.1.1</version>
</dependency>

groupIdを jp.altus5.webperformer と他とは被らないものにして、versionは、WPのバージョンにしておくとよいと思います。
このままでは、jarが見つかりませんので、mvnコマンドで、ローカルリポジトリに追加します。

mvn install:install-file \
-Dfile=$webapp/WEB-INF/lib/commons-validator.jar \
-DgroupId=jp.altus5.webperformer \
-DartifactId=commons-validator \
-Dversion=2.1.1 \
-Dpackaging=jar \
-DgeneratePom=true \
-DcreateChecksum=true

Servletのバージョンを3.0にあわせる

Spring Bootのデフォルトのtomcatは、Servlet 3.0なので、3.0未満に依存した jarから、servlet-api を除外します。WP2.1.1では、axis2-jaxwsと、axis2-kernel、axis2-springの3つです。

<dependency>
  <groupId>org.apache.axis2</groupId>
  <artifactId>axis2-jaxws</artifactId>
  <exclusions>
    <exclusion>
      <groupId>javax.servlet</groupId>
      <artifactId>servlet-api</artifactId>
    </exclusion>
  </exclusions>
</dependency>

これは、Spring Boot化したら、WPの機能のうち、SOAPを使った機能が使えないかもしれないことを示唆しています。弊社では、SOAPを使わないので、その動作確認もしていませんが、もし、使いたい場合には、spring-boot-legacy の利用を検討するとよいと思います。

Spring Bootのプラグインや依存jarを追加する

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<!-- Spring BootでJSPを使えるようにする -->
<dependency>
  <groupId>org.apache.tomcat.embed</groupId>
  <artifactId>tomcat-embed-jasper</artifactId>
  <scope>provided</scope>
</dependency>

Spring Bootを実行可能warとなるように設定する

Spring Bootは、実行可能なjarとしてビルドすることができますが、 WPが生成するコードは、jspが使われていて、Spring Bootでjspを使うには、 jarでは、無理で、warにビルドする必要があります。
こちらも、実行可能なwarとしてビルドできます。

jspやプロパティの文字コードをUTF-8に整える

この作業は無くても大丈夫ですが、一部のコードは、Windows-31jを文字コードとしたものが出力されます。
機能拡張の実装をするときに、WP以外の Eclipse や エディタでそのリソースを開くと文字化けして見辛いので、いっそ、文字コード変換をしておくとよいかもしれません。
弊社では、文字コード変換のための gulpタスクを作成して、nodejsで変換しています。

自動ビルドとnexusの利用

WP上で編集した各種定義ファイルを、リポジトリにプッシュしたら、コード生成からコンパイル、jar作成までを、自動ビルドするスクリプトがあると便利です。
特に、大きいプロジェクトになってくると、コンパイルに時間がかかるようになるので、メモリをたっぷり割り当てて、ビルド時間の最小化を試みるのもよいと思います。
弊社では、ビルドサーバーを設けて、WPのソースをプッシュしたら、ビルドサーバでビルドして、jarファイルをnexusのプライベートリポジトリにコミットして、 拡張機能の担当者に自動配布されるようにしています。

Spring Boot のコンフィグレーション

Spring Boot として実行するための main と、コンフィグレーションを実装します。 コンフィグレーションの内容は、WPが出力した web.xml をもとにします。

mainクラス

@SpringBootApplication
public class App {
    public static void main(String[] args) {
        SpringApplication.run(App.class, args);
    }
}

Web関連以外のコンフィグレーション

@Configuration
@ComponentScan(basePackages = {"jp.altus5.hoge", "jp.co.canon_soft.wp.runtime.webmvc.component"})
@EnableAutoConfiguration
public class AppConfig {
}

DBの構成なども、ここに追加して良いと思います。 弊社では、バッチ処理からもDBの構成を利用したいので、拡張ライブラリの方に、追加しました。

Web関連のコンフィグレーション

@Configuration
public class WebConfig extends WebMvcConfigurerAdapter {
    @Bean(name = DispatcherServletAutoConfiguration.DEFAULT_DISPATCHER_SERVLET_BEAN_NAME)
    public DispatcherServlet dispatcherServlet() {
        return new DispatcherServlet();
    }

    @Bean(name = DispatcherServletAutoConfiguration.DEFAULT_DISPATCHER_SERVLET_REGISTRATION_BEAN_NAME)
    public ServletRegistrationBean dispatcherServletRegistration() {
        ServletRegistrationBean registration = new ServletRegistrationBean(
                dispatcherServlet(), new String[]{"*.do"});
        registration
                .setName(DispatcherServletAutoConfiguration.DEFAULT_DISPATCHER_SERVLET_BEAN_NAME);

        return registration;
    }

    @Bean
    public ViewResolver setupViewResolver() {
        UrlBasedViewResolver resolver = new UrlBasedViewResolver();
        resolver.setViewClass(JstlView.class);
        return resolver;
    }

    @Override
    public void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer) {
        configurer.enable();
    }

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addWebRequestInterceptor(new RequestInterceptor());
    }

    ・・・・

WPが出力したコードの所有権とか著作権は、弊社が保有するものの、WP自体はOSSではないので、 どこまで、コードを公開してよいのか、判断できないため、一部を抜粋して、問題なさそうな部分のみ掲載しています。

まとめ

以上、WPが出力したコードをSpring Boot化するポイントをご紹介しました。
もし、ご興味のある方がいらっしゃいましたら、お気軽にお問い合わせください。

The post Web Performerが出力したコードをSpring Boot化してみた first appeared on 株式会社Altus-Five.