JP/EN

 

技報検索

2013年12月発刊 Vol.33 No.3 通巻118号
「エアラインリザベーション」

技報118号は、全日本空輸株式会社 (ANA) が30年以上にわたりメインフレーム上で使用してきた国内線旅客システム「able-D」を、米国ユニシス社のオープンエアラインパッケージ「AirCore」をベースに再構築したプロジェクトについてまとめています。 大手航空会社の基幹システムである旅客システムは、停止できない社会基盤でもあり、今回のオープンシステムへの移行は、世界的に前例のないものでした。本特集号では、それを実現した大規模システム開発プロジェクトマネジメントへの取り組み、オープン技術によるアーキテクチャ設計、インフラシステム、外部システム接続、フレームワークや業務ソリューション開発の概要、テスト戦略、移行計画などを紹介しています。

エアラインリザベーション

巻頭言

基調論文

論文

オープン国内線旅客システム開発の考慮点

金子 時生

2013年2月に全日本空輸株式会社の基幹システムである国内線旅客システムが稼働した。同社においては約30 年ぶりの全面更改となった。  当該システムは、WEB予約または旅行代理店における予約業務、発券/決済業務、及び搭乗業務のサービスを担っており、一企業の基幹システムとしてのみならず、社会基盤としての安定した稼働が要求されるシステムである。  今回の開発では、オープンプラットフォームの環境でメインフレームと同等のサービスレベルを実現すること、所与の時間内で移行・稼働させることがゴールであった。その達成により、生産性の向上、及び迅速な新サービス提供が可能となった。  本稿は、ミッションクリティカルな大規模システムを稼働に導くにあたり、バイブルとしてきた基本方針と開発内容をご紹介し、開発の上で考慮してきたポイントを本特集号のイントロダクションとして取り纏めたものである。

論文ダウンロード[PDF] (2.2MB) >

大規模開発のプロジェクトマネージメント 坪内 淳

プロジェクト管理には様々な方法論が存在し、管理体系も確立している。大規模プロジェクトでも管理体系と方法論については変わりないが、大規模ゆえに遂行上の障壁が多く、これを乗り越えるためにプロジェクト管理にいくつか加味しなければならい点がある。  まずプロジェクトの計画段階では、作業の大きさを考えてプロジェクトを管理できる実行単位へ細分化することが必要であるが、この際実行単位ごとにプロジェクト目的を細分化することも重要である。  次に実行段階では、進行上の問題と課題の把握と分析、対策検討に極力傾注することが重要であり、プロジェクトの状況に応じて柔軟に管理のやり方を見直すことも求められる。これらの柔軟な運営を実現するためにはプロジェクト管理を顧客と一体となった体制で実施することが効果的である。一体となって運営することで、課題解決のスピードアップや品質の向上を期待することができる。

ダウンロード[PDF] (1.6MB) >

大規模開発を支えた開発プロセス 小笠原 一洋

ANACore開発プロジェクトは非常に大規模で、開発期間が長期に渡ったため、プロジェクトの途中で新規参入する開発者も多かった。またシステムに接続する外部インタフェースも多岐に渡り、それぞれに異なるアーキテクチャが用意されていた。このような状況を踏まえ、開発作業を円滑に進めていくために開発環境の整備とアーキテクチャ毎の開発プロセスを定義した。また各開発プロセスで作成される成果物についても、各種規約の順守性やバグ混入の可能性をチェックする仕組みを作ることで、高品質が保たれるようにした。

ダウンロード[PDF] (2.0MB) >

ProjectAIにおけるテスト戦略 平松 敦郎

長期に渡り複数のテスト工程を経てITシステムを作り上げる大規模プロジェクトは早い時期からテスト戦略を定め、各工程がどのようなテストを担い、最終目標に到達するかを可視化することが重要である。ステークホルダー、プロジェクト管理者、テスト担当者、障害対応者と、テスト工程に携わるプロジェクトメンバー全員が共通認識を持ち、テストに臨むことでプロジェクトの無駄を排し、IT技術者が真に重要と考える作業に集中することができる。本稿では、事例に取り上げるプロジェクトが、テスト戦略書をどのように作成、利用したかを明確にし、テスト戦略がプロジェクトを成功に導いた一要因となったことを明らかにする。

ダウンロード[PDF] (2.0MB) >

大規模ミッションクリティカルシステムを支えるアーキテクチャとフレームワーク 鮫島 荘介

大規模ミッションクリティカルシステムであるANACoreの開発では、AirCore(AirlineCore Systems Solutions)をベースに、ソフトウェアアーキテクチャを策定し、またそれを実現するフレームワークを開発した。策定・開発したアーキテクチャとフレームワークは、SOA(Service-Oriented Architecture)を考慮し、メインフレームの性能と運用性を実現するべく様々な工夫を凝らしている。  本稿では、ANACoreに適用したソフトウェアアーキテクチャとフレームワークを紹介し、ノウハウの一端を解説する。

ダウンロード[PDF] (2.0MB) >

多種多様な接続を有する外部システム群との接続方式 佐藤 覚

2013年2月に稼働を開始した新国内線旅客システムは、メインフレームベースの旧国内線旅客システムを、オープン・アーキテクチャをベースに再構築したものである。外部システムとの接続連携については、旧システムで確立された接続方式を踏襲する必要があり、新システムの外側に配置したゲートウェイ機能と新システムの入り口に配置した外部システム用のフレームワークを開発し、これらの組み合わせで50を超える既存の接続方式を実現した。業務アプリケーションはこれらの接続処理と完全に切り離されており、接続方式に影響を受けない。本稿では、この接続機能を提供するために開発したアプリケーションの概要と、外部システムとやり取りする既存の電文を新システムで扱うことのできるインタフェースに変換する仕組みについて紹介する。

ダウンロード[PDF] (1.3MB) >

オープン系エンタープライズシステム構築 石崎 達也,滝沢 和明

全日本空輸株式会社の基幹系システムである、国内線旅客システムがオープンプラットフォーム環境にて2013年2月に稼働した。旧システムはメインフレームの高い可用性と信頼性に支えられ、30年以上稼働し続けてきた。オープン系技術の台頭から久しく、ITコストの抑制からオープンプラットフォームへの移行が情報系システムを中心に進められてきたが、基幹系システムのオープンプラットフォーム移行には大きなリスクを伴う。  本稿は、今回の国内線旅客システムの移行において、メインフレームと同等の高いサービスレベルをいかに実現したかについて記載する。

ダウンロード[PDF] (3.2MB) >

大規模トランザクション処理の性能対応 高井 健志

大規模開発では、アプリケーション機能の開発がほぼ終了し統合テストに入ってから性能問題が発覚し、アプリケーションチューニング等で大幅なオーバーヘッドがかかり、その結果プロジェクト全体のスケジュール遅延やコストの増大につながることがある。  当該状況に陥らないためには、1)早期にアーキテクチャを決定しアプリケーションフレームワーク(共通機能)を構築する、2)構築したフレームワークの下でプロトタイプアプリケーションのベンチマークテストを実施し、最終形アプリケーションでの性能予測および性能に対するキーポイントを明確にする、3)アプリケーション開発前に性能検証の戦略を立て、単体テスト時より工程毎に性能を継続的に検証する、という対応を実施することが重要である。  本稿では、性能リスクにいかに対応したかを記述し、開発を通じ注力すべきポイントを明確化する。

ダウンロード[PDF] (1.3MB) >

旅客システムアプリケーション 水澄 正晴

旅客系システムとはエアライン業務の中枢システムであり、予約・発券・搭乗という三つのサブシステムから構成されている。  ここでは旅客系システムの更改が必要となった背景、新システムに求められているもの、新システムのベースとして採用した米国Unisys社のエアラインパッケージ“AirCore”ソリューション、アプリケーション開発でのポイントを紹介する。

ダウンロード[PDF] (1.1MB) >

大規模ミッションクリティカルシステムにおける移行計画 倉田 祐介,久一 大介

2013年2月にANACoreの稼働を迎えるにあたり、稼働7日前から本番運用に影響することなく、データベース移行作業を実施し、稼働当日のシステム停止時間を4.5時間という短時間で新旧システムを一斉に切替え、移行作業を完了させることができた。  100%確実に移行を実施するための移行計画をコンティンジェンシープランも含め入念に立案し、9カ月で合計19回の移行リハーサルを実施しながら、発生した課題を確実に解決し、PDCAサイクルを繰り返したことが今回の移行作業の成功につながったと考える。  本稿では稼働当日のシステム停止時間4.5時間の達成に向けての対応策と、コンティンジェンシープラン及び準備内容を紹介する。

ダウンロード[PDF] (1.7MB) >

国内線旅客システム稼働後の障害対応への備え 伊藤 直樹

国内線旅客システム稼働において、稼働直後の様々な事象に素早く対応すべく準備することが必要である。稼働直後から2週間の緊急障害対応に備えた期間を臨戦期間と定義し、その間の24時間体制を臨戦体制とした。  まず、問合せ・障害の発生数を予測し、それに耐えうる体制と役割を確立した。そして、その体制のもと、効率よく臨戦体制の作業を遂行できるよう、障害対応のフロー、ログデータの参照ルール、障害対応リリース手順の整備、システム稼働状況監視の方法等を検討しルールと手順を整理した。この体制で効率良く作業するための端末/ファシリティ/ロケーションについても検討し準備した。また、マネジメント面では稼働状況確認会議体について報告手段や報告内容、会議の進め方や意思決定についても定め手順化した。  最後に、定義されたルールや手順の検証と要員の教育のために、臨戦体制訓練も積み重ねて稼働当日に備えた。  臨戦期間中には、約3,700件(最初の3日間で約1,800件)のインシデントが発生したが、臨戦体制の準備と訓練により、発生インシデントに対し効率よく速やかに対応することができ、顧客の業務へ大きな影響を及ぼすことなく安定稼働に繋げられた。

ダウンロード[PDF] (1.3MB) >

PDF形式のデータをご覧頂くにはAdobe Reader(無償) が必要です。
ダウンロードはこちら >

Get ADOBEREADER