Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

488 views

Published on

2018年12月7日(金)に開催された「GrapeCity Web TECH FORUM 2018」より、日本プロテック 荒井光司様/疋田直樹様のセッション資料です。

Published in: Technology
  • Be the first to comment

  • Be the first to like this

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

  1. 1. レガシーからの移行 株式会社日本プロテック 2 0 1 8 年 1 2 月 7 日
  2. 2. レガシーからの移行
  3. 3. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. はじめに レガシーシステムの移行要件 移行ソリューション さぁ開発だ(開発の進め方) 苦労した点 Wijmoを使ってみて 最後に アジェンダ
  4. 4. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. はじめに 業務システムは、C/S型アプリから、Webアプリへ Windowsアプリ Internet ブラウザ クライアント サーバー クライアント DB+Webアプリ サーバー DB スマホ タブレット テレビ・ゲーム 家電・車・農業 監視カメラ C/S型アプリ Webアプリ モバイルアプリ →クラウド化 ITの急速な技術革新
  5. 5. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. はじめに 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アプリの当初の課題
  6. 6. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 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年
  7. 7. レガシーシステムの 移行要件
  8. 8. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. レガシーシステムの移行要件 情シスの課題と悩み  ユーザー要望ではない。(予算の捻出)  仕様書がなく、システムの理解度が乏しい  見積の算出と移行ソリューション  モチベーション  ユーザーニーズを取り込み過ぎ?(複雑なU/I)  さまざまなプラットフォーム  サポート切れによる業務停止のリスク回避
  9. 9. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. レガシーシステムの移行要件 ユーザー・情シスからの移行要件  同じ画面デザイン(興味なし?)  既存と同等の操作性(RIAの継承)  プログラム解析(なぜか仕様書がない)  書き起こし・書き直しのコード量の最小化  マルチブラウザ対応  長期的なサポート  標準スキルでの運用  アプリ配布の容易性  短期間で仕上げて欲しい
  10. 10. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. レガシーシステムの移行要件 既存システムが、Silverlightの構成例 ブラウザ+Plugin DB+Webアプリ Internet RIA
  11. 11. 移行ソリューション
  12. 12. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 移行ソリューション 主な移行アーキテクチャの比較検討 Windowsアプリ 既存と同等の操作性(RIAの継承) → ライブラリ、Componentの検討  書き起こし・書き直しのコード量の最小化 → サーバー側のコードを残す  マルチブラウザ対応 →HTML5/JavaScript/CSSで実現  長期的なサポート →信頼できる団体、企業  標準スキルでの運用 →JavaScript .Net系  アプリ配布の容易性 →Webアプリ ASP.net Web Form JavaScript Framework HTML5 ASP.net MVC Java PHP Rails ■移行要件と検討方針 ■アーキテクチャ候補 JavaScript
  13. 13. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 移行ソリューション • サーバーサイドはそのまま利用 – ビジネスロジックは一切いじらない • フロントとサーバーの間に中間層を設けてSOAP (XML)からJSONに変換 – 本当に変換するだけ – BFFもどきと言えなくもないかもしれない 使えるモノは使う
  14. 14. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 移行ソリューション 既存システム (Server) 既存システム (Client) 使えるモノは使う OLD 既存システム (Server) 中間層 (Server) SPA (Client) NEW SOAP
  15. 15. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 移行ソリューション • SPA(Angular)にした • 既存システムがコンポーネントで分割されていた ので、同じ単位で移植 Silverlight Angular XAML HTMLテンプレート コードビハインド コンポーネント (TypeScript) 既存の構造を活かす
  16. 16. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 移行ソリューション • UXを悪化させない • 社内システムなのでSEO、SSR考慮しなくてよい • コンポーネントをそのまま移植できる SPA(Single Page Application)
  17. 17. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 移行ソリューション • 双方向バインディング – コンポーネントだけではなく、内部の構造も既存シス テムを踏襲できる • 型! – TypeScriptがデフォルト – SIerのバックボーンを考慮する心意気(違う) • フルスタック – HTTPリクエスト、ルーティングなどなど – ライブラリの組み合わせを検証してる時間が... Angularを採用した理由
  18. 18. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 移行ソリューション • React • Vue.js その他のSPAフレームワーク
  19. 19. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 移行ソリューション • この短期間で... – Functionalなスタイルに全員が馴染めるか? – Reduxのややこしい部分に回答を出せるか? • Stateの設計 • 非同期処理 • 双方向バインディングがない • TypeScriptと組み合わせたときに、一部型パズル みたいになって辛い – 特にRedux、Material UIなど Reactを採用しなかった理由
  20. 20. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 移行ソリューション • TypeScriptの型付けが微妙と言われていた • 体制が脆そうで説得し辛かった • 感触は良かった Vue.jsを採用しなかった理由
  21. 21. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 移行ソリューション Vue.jsを採用しなかった理由 GitHubより
  22. 22. ほんとうは Reactに したかった
  23. 23. 閑話休題
  24. 24. フレームワークは決まった... だけど、 それだけでよいのだろうか?
  25. 25. RIA Silverlight Adobe Flex
  26. 26. リッチ インターネット アプリケーション
  27. 27. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 移行ソリューション • 様々なコンポーネントが使われていた – データグリッド – ツリービュー – etc... リッチなUIを作らないといけない
  28. 28. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 移行ソリューション Wijmoを利用した画面
  29. 29. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 移行ソリューション • 自作 • 色々な無償ライブラリを組み合わせる – UIのフィーリング、利用方法 • ライブラリ選定のポイント – 機能の豊富さ(一貫性を保つためにも!) – サポート(言語含む) – 情報量 – 品質 – 実績 リッチなUIを作らないといけない
  30. 30. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 移行ソリューション • Angular/TypeScriptをサポート • 多機能 • サポート(日本語/バグFixのスピード) • 継続的な更新、メンテナンス • 他製品の利用実績 – ComponentOne – InputMan – ActiveReports – Spread Wijmoを採用した理由
  31. 31. さあ、開発だ!
  32. 32. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 開発の進め方 • フロント側、サーバー側で分業 – 短納期ゆえ... • サーバー側の仕様、I/FはAPI Blueprintで定義
  33. 33. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 開発の進め方 • MarkdownでAPI仕様書が書けるツール • モチベーション – 仕様書もバージョン管理したい – Markdownで書ける – キレイなHTMLを生成できる API Blueprint
  34. 34. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 開発の進め方 • Markdownで書ける – Swaggerは(当時)JSON or YAML • コードファーストができない – ASMX Webサービスで使えるのか不明 (おそらく不可能) なぜSwaggerにしなかったのか?
  35. 35. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 開発の進め方 フロント側 サーバー側 1 モック作成(HTML) API仕様書作成(API Blueprint) 2 API定義を元に作成したダミーデー タを使って実装を進める API実装 3 本物のAPIを使って実装、テスト 次のAPI仕様書作成 4 次の画面のモック作成 完成した画面(Angular)をCMSに 組み込んでテスト 5 1~4を繰り返す 実際の開発フロー
  36. 36. 以上のような進め方で、 なんの問題もなく リリースできました
  37. 37. 嘘です
  38. 38. 苦労した点
  39. 39. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 苦労した点 • Angular • API Blueprint • プラットフォーム(CMS) • テスト自動化 • ブラウザ間の差異
  40. 40. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 苦労した点 • 学習コスト – TypeScript – RxJSにピンとこない問題 • 双方向バインディング – 関数と引数で全てが決まるReactの考え方の方がシンプ ル Angular
  41. 41. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 苦労した点 • Markdown(風)シンタックス – 慣れるまでにかなりハマった API Blueprint
  42. 42. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 苦労した点 • 事例が見つからない • Wijmoが保証していない プラットフォーム(CMS)
  43. 43. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 苦労した点 • 自動化 – 一画面やって挫折 – Angularはテストも面倒見てくれるので、書くのは楽と いえば楽 • 人力 – 最初は地獄だった テスト
  44. 44. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 苦労した点 テスト 実運用時の構成 Spring(Java) Web API Angular
  45. 45. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 苦労した点 テスト (普通の)ローカル開発時の構成 Spring(Java) Web API Angular (単独起動)
  46. 46. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 苦労した点 テスト (普通の)ローカル開発時の構成 Spring(Java) Web API Angular (単独起動)
  47. 47. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 苦労した点 テスト (実際の)ローカル開発時の構成 Spring(Java) Web API Angularの ソース Angular ソース修正のたびに、 Angularをビルド& Springにデプロイ
  48. 48. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 苦労した点 • Storybookを導入 – コンポーネントのカタログを作るためのツール テスト
  49. 49. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 苦労した点 • まずはStorybook上で実装、テスト – ソースの変更を検知して即時画面反映 • OKであればSpringに載せてテスト テスト
  50. 50. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. 苦労した点 自作した部分について… • 見た目が違う • 印刷結果が真っ白 • if文でブラウザ判定 – 辛い • Silverlight、Flexではプラットフォームが吸収し てくれていた(と思われる)点 ブラウザ間の差異
  51. 51. Wijmoを使ってみて
  52. 52. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. Wijmoを使ってみて • 良かった点 – サポート – だいたいなんでもある – 見た目が業務アプリ向け • 改善希望 – ドキュメントの充実 – 見た目のカスタマイズ性向上 – TypeScriptの型定義の充実
  53. 53. さいごに
  54. 54. Copyright (C) 2018 NIHON-Protec Co., Ltd. All Rights Reserved. さいごに • サーバーサイドを流用+フロントをJS(SPA)で 置き換えるという方針は今の所ベスト – 直近の案件は全てこの方針で進めている • 見積は、慎重に… 画面の表面だけで判断できない。 – ツールによるメトリクス分析。 – テスト自動化の工数を取れるとベスト。 • 無理に自作しない。 • 画面のデザインは変わる前提で話す
  55. 55. ご清聴ありがとうございました。

×