[GrapeCity Web TECH FORUM 2018]レガシーからの移行 - 株式会社日本プロテック

レガシーからの移行
株式会社日本プロテック
2 0 1 8 年１２月７日

Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved.
はじめに
レガシーシステムの移行要件
移行ソリューション
さぁ開発だ（開発の進め方）
苦労した点
Wijmoを使ってみて
最後に
アジェンダ

はじめに
業務システムは、C/S型アプリから、Webアプリへ
Windowsアプリ
Internet
ブラウザ
クライアント
サーバー
クライアント
DB+Webアプリ
サーバー
DB
スマホ
タブレット
テレビ・ゲーム
家電・車・農業
監視カメラ
C/S型アプリ Webアプリ
モバイルアプリ
→クラウド化
ITの急速な技術革新

はじめに
Webアプリの壁の打開に向けて
 C/S型のU/Iに慣れきっている。（キーボードコントロール）
 Webの挙動のストレス（遅い、使いづらい、不安定）
1995年 JavaApplet公開（インタラクティブ）
1996年 JDK1.0公開／ネスケ2.0に、JavaScriptが実装
1998年 IE6、ネスケ7.1、Firefox、OperaでDOMをサポート
2005年 Ajax（JavaScriptによる非同期通信）
2006年 Flex 2.0公開
2007年 Flash公開、Silverlight公開
2008年 Air公開
 RIAを取り入れることで、Webアプリケーションの表現力・操作性を向上
10
年前
 Webアプリの当初の課題

1995年 JavaApplet公開（インタラクティブ）
1996年 JDK1.0公開／ネスケ2.0に、JavaScriptが実装
1998年 IE6、ネスケ7.1、Firefox、OperaでDOMをサポート
2005年 Ajax（JavaScriptによる非同期通信）
2006年 Flex 2.0公開
2007年 Flash公開、Silverlight公開
2008年 Air公開
はじめに
サポート終了
企業課題
レガシーシステム
Flash/Flex ：2020年
Silverlight ：2021年

レガシーシステムの
移行要件

レガシーシステムの移行要件
情シスの課題と悩み
 ユーザー要望ではない。（予算の捻出）
 仕様書がなく、システムの理解度が乏しい
 見積の算出と移行ソリューション
 モチベーション
 ユーザーニーズを取り込み過ぎ？（複雑なU/I）
 さまざまなプラットフォーム
 サポート切れによる業務停止のリスク回避

ユーザー・情シスからの移行要件
 同じ画面デザイン（興味なし？）
 既存と同等の操作性（RIAの継承）
 プログラム解析（なぜか仕様書がない）
 書き起こし・書き直しのコード量の最小化
 マルチブラウザ対応
 長期的なサポート
 標準スキルでの運用
 アプリ配布の容易性
 短期間で仕上げて欲しい

既存システムが、Silverlightの構成例
ブラウザ+Plugin
DB+Webアプリ
Internet
RIA

移行ソリューション
主な移行アーキテクチャの比較検討
Windowsアプリ 既存と同等の操作性（RIAの継承）
→ ライブラリ、Componentの検討
 書き起こし・書き直しのコード量の最小化
→ サーバー側のコードを残す
 マルチブラウザ対応
→HTML5/JavaScript/CSSで実現
 長期的なサポート
→信頼できる団体、企業
 標準スキルでの運用
→JavaScript .Net系
 アプリ配布の容易性
→Webアプリ
ASP.net Web Form
JavaScript Framework
HTML5
ASP.net MVC
Java PHP Rails
■移行要件と検討方針 ■アーキテクチャ候補
JavaScript

• サーバーサイドはそのまま利用
– ビジネスロジックは一切いじらない
• フロントとサーバーの間に中間層を設けてSOAP
（XML）からJSONに変換
– 本当に変換するだけ
– BFFもどきと言えなくもないかもしれない
使えるモノは使う

既存システム
（Server）
既存システム
（Client）
使えるモノは使う
OLD
既存システム
（Server）
中間層
（Server）
SPA
（Client）
NEW
SOAP

• SPA（Angular）にした
• 既存システムがコンポーネントで分割されていた
ので、同じ単位で移植
Silverlight Angular
XAML HTMLテンプレート
コードビハインド
コンポーネント
（TypeScript）
既存の構造を活かす

• UXを悪化させない
• 社内システムなのでSEO、SSR考慮しなくてよい
• コンポーネントをそのまま移植できる
SPA（Single Page Application）

• 双方向バインディング
– コンポーネントだけではなく、内部の構造も既存シス
テムを踏襲できる
• 型！
– TypeScriptがデフォルト
– SIerのバックボーンを考慮する心意気（違う）
• フルスタック
– HTTPリクエスト、ルーティングなどなど
– ライブラリの組み合わせを検証してる時間が...
Angularを採用した理由

• React
• Vue.js
その他のSPAフレームワーク

• この短期間で...
– Functionalなスタイルに全員が馴染めるか？
– Reduxのややこしい部分に回答を出せるか？
• Stateの設計
• 非同期処理
• 双方向バインディングがない
• TypeScriptと組み合わせたときに、一部型パズル
みたいになって辛い
– 特にRedux、Material UIなど
Reactを採用しなかった理由

• TypeScriptの型付けが微妙と言われていた
• 体制が脆そうで説得し辛かった
• 感触は良かった
Vue.jsを採用しなかった理由

Vue.jsを採用しなかった理由
GitHubより

ほんとうは
Reactに
したかった

フレームワークは決まった...
だけど、
それだけでよいのだろうか？

リッチ
インターネット
アプリケーション

• 様々なコンポーネントが使われていた
– データグリッド
– ツリービュー
– etc...
リッチなUIを作らないといけない

Wijmoを利用した画面

• 自作
• 色々な無償ライブラリを組み合わせる
– UIのフィーリング、利用方法
• ライブラリ選定のポイント
– 機能の豊富さ（一貫性を保つためにも！）
– サポート（言語含む）
– 情報量
– 品質
– 実績
リッチなUIを作らないといけない

• Angular/TypeScriptをサポート
• 多機能
• サポート（日本語/バグFixのスピード）
• 継続的な更新、メンテナンス
• 他製品の利用実績
– ComponentOne
– InputMan
– ActiveReports
– Spread
Wijmoを採用した理由

開発の進め方
• フロント側、サーバー側で分業
– 短納期ゆえ...
• サーバー側の仕様、I/FはAPI Blueprintで定義

開発の進め方
• MarkdownでAPI仕様書が書けるツール
• モチベーション
– 仕様書もバージョン管理したい
– Markdownで書ける
– キレイなHTMLを生成できる
API Blueprint

開発の進め方
• Markdownで書ける
– Swaggerは（当時）JSON or YAML
• コードファーストができない
– ASMX Webサービスで使えるのか不明
（おそらく不可能）
なぜSwaggerにしなかったのか？

開発の進め方
フロント側サーバー側
1 モック作成（HTML） API仕様書作成（API Blueprint）
2
API定義を元に作成したダミーデー
タを使って実装を進める
API実装
3 本物のAPIを使って実装、テスト次のAPI仕様書作成
4 次の画面のモック作成
完成した画面（Angular）をCMSに
組み込んでテスト
5 1～4を繰り返す
実際の開発フロー

以上のような進め方で、
なんの問題もなく
リリースできました

苦労した点
• Angular
• API Blueprint
• プラットフォーム（CMS）
• テスト自動化
• ブラウザ間の差異

苦労した点
• 学習コスト
– TypeScript
– RxJSにピンとこない問題
• 双方向バインディング
– 関数と引数で全てが決まるReactの考え方の方がシンプ
ル
Angular

苦労した点
• Markdown（風）シンタックス
– 慣れるまでにかなりハマった
API Blueprint

苦労した点
• 事例が見つからない
• Wijmoが保証していない
プラットフォーム（CMS）

苦労した点
• 自動化
– 一画面やって挫折
– Angularはテストも面倒見てくれるので、書くのは楽と
いえば楽
• 人力
– 最初は地獄だった
テスト

苦労した点
テスト
実運用時の構成
Spring（Java）
Web API
Angular

苦労した点
テスト
（普通の）ローカル開発時の構成
Spring（Java）
Web API
Angular
（単独起動）

苦労した点
テスト
（実際の）ローカル開発時の構成
Spring（Java）
Web API
Angularの
ソース
Angular
ソース修正のたびに、
Angularをビルド＆
Springにデプロイ

苦労した点
• Storybookを導入
– コンポーネントのカタログを作るためのツール
テスト

苦労した点
• まずはStorybook上で実装、テスト
– ソースの変更を検知して即時画面反映
• OKであればSpringに載せてテスト
テスト

苦労した点
自作した部分について…
• 見た目が違う
• 印刷結果が真っ白
• if文でブラウザ判定
– 辛い
• Silverlight、Flexではプラットフォームが吸収し
てくれていた（と思われる）点
ブラウザ間の差異

Wijmoを使ってみて
• 良かった点
– サポート
– だいたいなんでもある
– 見た目が業務アプリ向け
• 改善希望
– ドキュメントの充実
– 見た目のカスタマイズ性向上
– TypeScriptの型定義の充実

さいごに
• サーバーサイドを流用＋フロントをJS（SPA）で
置き換えるという方針は今の所ベスト
– 直近の案件は全てこの方針で進めている
• 見積は、慎重に…
画面の表面だけで判断できない。
– ツールによるメトリクス分析。
– テスト自動化の工数を取れるとベスト。
• 無理に自作しない。
• 画面のデザインは変わる前提で話す

ご清聴ありがとうございました。

[GrapeCity Web TECH FORUM 2018]レガシーからの移行 - 株式会社日本プロテック

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à [GrapeCity Web TECH FORUM 2018]レガシーからの移行 - 株式会社日本プロテック

Similaire à [GrapeCity Web TECH FORUM 2018]レガシーからの移行 - 株式会社日本プロテック (20)

Plus de Developer Solutions事業部メシウス株式会社（旧グレープシティ株式会社）

Plus de Developer Solutions事業部メシウス株式会社（旧グレープシティ株式会社） (20)

Dernier

Dernier (8)