Park

1. テスト

1.1. UI

1.1.1. Selenium

1.1.2. Appium

1.2. 静的コード解析

1.2.1. 汎用コードスタイルチェック

1.2.1.1. CheckStyle

1.2.2. Javascriptコードスタイルチェック

1.2.2.1. ESLint

1.2.3. 脆弱性チェック

1.2.3.1. SCALe

1.3. コンテナ

1.3.1. Container Structure Tests

2. ガイドライン対応

2.1. ミッション

2.1.1. システム全体を確認して各要求事項に対する対応状況を明確にする

2.2. 調査

2.2.1. 非常時の見読性確保に対する対応

2.2.1.1. ネットワークが切れた時の対応

2.2.2. ネットワークセキュリティに対する要件への対応

2.2.2.1. TLS1.2+クライアント証明書が必要

2.3. 監査

2.3.1. 新サービスの対応状態の確認

2.3.2. 版が更新されたときの確認

3. コンテンツ

3.1. ドメイン名

3.1.1. karte-blanc

3.1.1.1. jp

3.1.1.2. com

3.1.1.3. net

3.1.1.4. co.jp

3.2. Blancのトップページ

3.2.1. どの場所で管理するか

3.3. 新機能のリリース通知

3.3.1. どのような方法で？

3.4. マニュアル

3.5. FAQ

3.6. 問い合わせ先情報

4. システム管理

4.1. 運用

4.1.1. 運用準備

4.1.1.1. VM構成の場合

4.1.1.1.1. DBのパッチ当て手順

4.1.1.1.2. DBのDDL更新手順

4.1.1.1.3. VMの更新手順

4.1.1.2. コンテナ構成の場合

4.1.1.2.1. コンテナの更新手順

4.1.1.3. ログの確認手順の確立

4.1.1.4. 異常検知時の対応手順

4.1.2. 管理

4.1.2.1. ドメイン情報

4.1.2.1.1. 契約

4.1.3. マニュアル作成

4.1.4. バックアップ

4.1.4.1. 災害対策

4.1.4.1.1. 避難時の参照方法

4.1.4.1.2. バックアップ所在地

4.1.4.2. リカバリー対策

4.1.4.2.1. リカバリー時間

4.2. 保守

4.2.1. 保守体制

4.2.1.1. 教育

4.2.1.2. 問い合わせ対応

4.2.1.2.1. 電話

4.2.1.2.2. メール

4.2.1.2.3. その他

4.2.1.3. 対応マニュアル

4.2.1.3.1. FAQ

4.2.2. 保守対応

4.2.2.1. 全社員への情報共有

4.2.3. リリース

4.2.3.1. 手順

4.2.3.2. ビルド環境

4.2.3.2.1. 自動化

4.2.3.3. 種類

4.2.3.3.1. デイリー

4.2.3.3.2. 製品

4.2.3.3.3. その他

4.3. 導入

4.3.1. サービス開始手順の確立

4.3.2. 新規施設の追加手順

4.3.3. 新規アカウントの登録手順

5. DevOps

5.1. 進め方

5.1.1. 第１段階

5.1.1.1. VM

5.1.1.1.1. コード修正からビルドまでの自動化

5.1.1.1.2. デプロイの自動化

5.1.1.2. コンテナ

5.1.1.2.1. コンテナイメージのレジストリ選定

5.1.1.2.2. コンテナイメージの自動作成

5.1.1.2.3. CI/CDの調査

5.1.2. 第２段階

5.1.2.1. コンテナ

5.1.2.1.1. コード修正からビルドまでの自動化

5.1.2.1.2. コンテナイメージ生成の自動化

5.2. 共通

5.2.1. バージョン管理

5.2.1.1. 環境

5.2.1.1.1. 検証環境

5.2.1.1.2. 開発環境

5.2.1.1.3. 本番環境

5.2.1.2. 対象

5.2.1.2.1. モジュール

5.2.1.2.2. データベース

5.2.1.2.3. 設定ファイル

5.2.1.2.4. apiuscm

5.2.1.2.5. コンテナ関係のコンフィグ

5.2.2. バグトラッキング

5.2.2.1. JIRA

5.2.3. システム構成管理

5.2.3.1. ansible

5.2.3.2. Puppet

5.2.3.3. Chef

5.2.4. CI/CD実行基盤

5.2.4.1. Jenkins

5.2.4.2. Circle CI

5.2.4.3. Travis CI

5.2.5. Chat

5.2.5.1. Slack

5.2.5.2. ChatWork

5.2.5.3. HipChat

5.3. OPS

5.3.1. プロビジョニング

5.3.1.1. ツール

5.3.1.1.1. ansible

5.3.1.1.2. Vagrant

5.3.1.2. 環境の構築

5.3.1.2.1. コンテナ

5.3.1.2.2. VM

5.3.1.3. デプロイ手法

5.3.1.3.1. Simple-Deployment

5.3.1.3.2. Rolling-Deployment

5.3.1.3.3. Bule-Green-Deployment

5.3.1.3.4. Canary-Deployment

5.3.2. モニタリング

5.3.2.1. ツール

5.3.2.1.1. Prometheus

5.3.2.1.2. DataDog

5.3.2.1.3. Zabbix

5.3.2.1.4. Grafana

5.3.2.2. コンピューティングリソース

5.3.2.2.1. コンテナおよびPODレベル

5.3.2.2.2. Nodeレベル

5.3.2.3. ログ

5.3.2.4. サービスの死活監視

5.3.2.5. 異常発生時のアラートを挙げる方法の検討

5.4. DEV

5.4.1. 自動化

5.4.1.1. コンテナイメージ生成

5.4.1.1.1. Kaniko

5.4.1.1.2. Jib

5.4.1.2. ビルド

5.4.1.2.1. Maven

5.4.1.2.2. Gradle

5.4.1.2.3. ant

5.4.1.3. ビルド＆デプロイ

5.4.1.3.1. 実行基盤

5.4.1.3.2. VM型

5.4.1.3.3. コンテナ型

5.4.2. ソース管理

5.4.2.1. Bitbuket(Git系)

6. マイルストーン

6.1. プレリリース向け

6.1.1. 方針・目的

6.1.1.1. ３省３ガイドライン対応は

6.1.1.2. システム構成はVM仮想化を基にする

6.1.1.3. 可用性や信頼性は低くて良い

6.1.1.3.1. 簡単なデモに耐えうる程度で良い

6.1.1.4. お客さまにBlancのデモを見せる事が出来る

6.1.2. GCE上にBlanc環境を構築

6.1.2.1. Google Compute Engineの調査

6.1.2.2. GCE上にDb2を構築

6.1.2.3. GCE上にWASを構築

6.1.2.4. GCE上にBlanc環境を構築

6.1.2.5. WASを二重化したうえで負荷分散

6.1.2.6. GCE上にBlanc環境を構築する手順書等を作成

6.1.2.6.1. Windows2016Serverをに日本語化したイメージを作成する

6.1.2.6.2. コマンドラインのバッチでインスタンスを作成する手順にする

6.1.2.6.3. 手順書はGoogleドキュメントで作成

6.1.3. Azure上にBlanc環境を構築

6.1.4. Azure環境のテスト

6.2. ORCAカンファ向け

6.2.1. 方針・目的

6.2.1.1. JAHIS主催のORCAカンファレンスで行われる展示会に出展し、Blancのアピールを行う

6.2.2. デモ環境構築

6.2.2.1. ミニPC上にローカルで動作するBlanc環境を作る

6.2.2.1.1. WASインストール

6.2.2.1.2. Db2インストール

6.2.2.1.3. BlancのDBをセットアップ

6.2.2.1.4. 動作確認

6.3. クリニック向け

6.3.1. 方針・目的

6.3.1.1. クリニック向け機能の範囲内の３省３ガイドライン対応を行う

6.3.1.2. 製品として実際にお客様に向けて提供を開始する

6.3.1.3. システム構成はVM仮想化を基にする

6.3.1.4. 可用性や信頼性が必要

6.3.2. 性能設計

6.3.2.1. 具体的な性能要件を定義する必要がある

6.3.2.1.1. 要求

6.3.3. 運用準備

6.3.4. プロダクション環境構築

6.3.4.1. セキュリティ

6.3.4.1.1. HTTPS対応(TLS1.2)

6.3.4.1.2. クライアント証明書

6.3.4.1.3. サーバー証明書

6.3.4.2. バックアップ

6.3.4.2.1. システムバックアップ

6.3.4.2.2. データバックアップ

6.3.4.3. 冗長化

6.3.4.3.1. サーバー

6.3.4.3.2. ネットワーク

6.3.4.3.3. アプリのセッション

6.3.5. ステージング環境構築

6.3.6. 開発向けテスト環境構築

6.3.7. 部門連携

6.3.7.1. ORCAクラウド

6.3.8. 基盤テスト

6.3.9. 全体テスト

6.4. 病院向け

6.4.1. 方針

6.4.1.1. 病院向け機能を持つ

6.4.1.2. 病院向け機能まで対象にした３省３ガイドライン対応を行う

6.4.1.3. システム構成はコンテナ仮想化を基にする

6.4.2. プロダクション環境の構築

6.4.3. ステージング環境の構築

6.4.4. 開発向けテスト環境の構築

6.4.5. 性能設計

6.4.6. オンプレ対応

6.4.7. 部門連携

6.4.7.1. クラウドのサービスとの連携

6.4.7.1.1. ORCAクラウド

6.4.7.2. 院内のサービスとの連携

6.4.7.2.1. 未定

6.5. その他環境

6.5.1. イベント向け

6.5.2. プレゼン向け

7. プラットフォーム

7.1. クラウド

7.1.1. 共通

7.1.1.1. PublicCloudの選定

7.1.1.1.1. 調査

7.1.1.1.2. Microsoft Azure にほぼ決定

7.1.1.2. ドメイン名

7.1.1.2.1. 名称検討

7.1.1.2.2. ドメイン名の取得

7.1.1.3. ネーミングルール

7.1.1.3.1. Kubernetesリソースの名前付けルール

7.1.1.3.2. コンテナイメージ

7.1.1.3.3. URL

7.1.1.4. セキュリティ

7.1.1.4.1. TLSのクライアント認証に関する調査

7.1.1.4.2. VPN

7.1.1.4.3. データの暗号化

7.1.1.4.4. ネットワークの暗号化

7.1.1.5. 部門システムとの連携

7.1.1.5.1. 院内のシステム

7.1.1.5.2. クラウドのシステム

7.1.1.6. ネットーワーク構成

7.1.1.6.1. 検討

7.1.2. プロダクション環境

7.1.2.1. VM型仮想環境

7.1.2.1.1. WASを多重化した際のシステム構成

7.1.2.2. コンテナ型仮想環境

7.1.2.2.1. kubernetes

7.1.2.2.2. メンテナンス手順

7.1.2.2.3. 個別設定の永続化

7.1.2.2.4. 出力ログ

7.1.2.2.5. 機能検証

7.1.2.2.6. コンテナ環境構築

7.1.3. ステージング環境

7.1.4. テスト環境

7.1.5. 拡張機能

7.1.5.1. 認証基盤

7.1.5.1.1. ソリューションの調査

7.1.5.1.2. ソリューションの検証

7.1.5.1.3. サンプルアプリケーションの開発

7.1.5.2. 部門連係

7.1.5.2.1. 標準的なIFミドルウェア（ETL)

7.1.5.2.2. 既存IF(windowsサービス）での連携方法・構成

7.2. オンプレミス

7.2.1. システム構成の検討

7.3. クライアント

7.3.1. OS環境

7.3.1.1. Windows系

7.3.2. ブラウザ環境

7.3.2.1. Google Chrome

7.3.3. クラウド

8. サービス

8.1. マイクロサービス型

8.1.1. 開発言語

8.1.1.1. 推奨

8.1.1.1.1. サーバー

8.1.1.1.2. クライアント

8.1.1.2. その他いろいろ

8.1.2. プラットフォーム化

8.1.3. 複数プラットフォームの透過的運用

8.1.3.1. Azure

8.1.3.2. GCP

8.1.3.3. AWS

8.1.3.4. Oracle

8.1.3.5. オンプレミス

8.1.4. ロギング

8.1.4.1. 内容の統一化

8.1.4.2. 運用統計の製品化

8.1.5. マイクロサービス化

8.1.5.1. 処理のガイドライン

8.1.5.1.1. エラー時の動作

8.1.5.1.2. エラーログ

8.1.5.1.3. 運用ログ

8.1.5.2. プロトコル整備

8.1.5.2.1. RESTful

8.1.5.2.2. gRPC

8.1.5.2.3. GraphQL

8.2. モノリシック型

8.2.1. Java Servlet

8.2.2. WAS+Db2

9. 振り分け保留

9.1. ビッグデータ

9.1.1. 収集

9.1.1.1. 匿名化

9.1.1.2. 承認

9.1.2. 分析

9.1.2.1. 再利用目的

9.1.2.1.1. フィードバック

9.1.2.1.2. 新機能

9.1.2.1.3. 新製品

9.1.2.1.4. 外販

10. マネー

10.1. お金のかかる要素

10.1.1. ソフトウェアライセンス

10.1.1.1. OS

10.1.1.2. Db2

10.1.1.3. WAS

10.1.2. Cloudサービス

10.1.2.1. Azure

10.1.3. 証明書

10.1.3.1. サーバー証明書

10.1.3.2. クライアント証明書

10.1.4. その他の料金

10.2. 費用

10.2.1. 固定費

10.2.1.1. 運用担当者の人件費

10.2.1.2. インフラ維持費

10.2.2. 変動費

10.2.2.1. 基盤にかかる費用

10.2.2.1.1. ミドルウェアライセンス

10.2.2.1.2. クライアント証明書

10.2.2.1.3. サーバー証明書

10.2.2.1.4. クラウドサービス

10.2.2.2. 導入担当者の費用

10.3. 決済システム

10.3.1. 契約方法

10.3.1.1. オンライン

10.3.1.2. 銀行

10.3.1.3. 代行

10.3.2. 決済代行業者

10.3.2.1. どこを利用するか

10.3.3. 仕組み

10.3.3.1. 要調査

10.3.3.2. 請求額の計算

10.3.3.2.1. 施設毎

10.3.4. セキュリティ

10.4. 費用削減

10.4.1. OSSに乗り換える

10.4.1.1. WASをtomcatへ変更

10.4.1.2. Db2をPostgreSQL

10.4.2. クラウドサービスを活用

10.4.2.1. Database

10.4.3. クライアント証明書を扱うための認証局を自前で用意する

10.5. サービス料金

10.5.1. 価格の決定方法を考える必要がある

10.5.2. 料金モデル

10.5.2.1. アカウント単位

10.5.2.2. 組織単位

10.5.2.3. 従量性

10.5.2.4. 固定性