【勉強記録forH25秋SA】過去問H24午後Ⅱ
システムアーキテクト試験まであと６日です。
そろそろ、証明写真の準備をしなければ。。。
さて、今回のエントリーも論文対策です。
お題は「業務の変化を見込んだソフトウェア構造の設計」
頻出問題の設計の問と思いますが、システム構造の設計とソフトウェア構造の設計は違いますよね。
実は、ソフトウェア構造の設計に言及する問は少ないようです。
システム構造の設計とソフトウェア構造の設計、どちらが問われているかきちんと見極めておかないと題意通りの回答が出来なくなってしまうので要注意ですね。
コンテンツも、システム構造の設計での工夫点、ソフトウェア構造の設計の工夫点と分けて双方用意しておかねばいけません。
問１ 業務の変化を見込んだソフトウェア構造の設計
企業を取り巻く環境の変化に応じて、業務も変化する。情報システムには、業務の変化に対応して容易に機能を変更出来るような、ソフトウェア構造の柔軟性が求められる。
このため、システムアーキテクトは、システム要件定義の段階から、業務の変化が起こり得るケースを想定し、変化の方向性やシステムに与える影響を予測する。ソフトウェア構造の設計では、その予測に基づいて、業務が変化してもシステム全体を大きく作り直す必要がないように考慮しなければならない。
例えば、次のようにソフトウェア構造の設計を行う。
・業務フローの制御部分と業務ロジック部分を分離する
・業務ロジックが互いに疎結合となるように分割する
・データアクセスコンポーネントを共通化する
その際、そのような設計を行う事によって引き換えに生じた課題に対応するための工夫を行う事が重要である。例えば、処理時間が長くならないように複数のプロセスを平行して処理したり、処理同士の整合性を確保する為に排他制御の仕組みを用意したりする。
設問ア あなたがソフトウェア構造の設計に携わったシステムにおける、対象業務の概要及び特徴について、800文字以内で述べよ
設問イ 設問アで述べたシステムについて、どのような業務の変化を想定したか。また、業務が変化してもシステム全体を大きく作り直す必要がないように、どのようなソフトウェア構造を設計したか。800文字以上1600文字以内で具体的に述べよ
設問ウ 設問イで述べたソフトウェア構造の設計において、生じた課題とそれに対応するために重要と考えて工夫した点、及び設計したソフトウェア構造に対するシステムアーキテクトとしての評価について、600字以上、1200字以内で具体的に述べよ
第１章 私がソフトウェア構造の設計に携わったシステムについて
1.1 対象業務の概要
私は、移動体通信事業社D社の情報システム部に勤務しているシステムエンジニアである。
今回、論述の対象とするシステムは、窓口業務支援システムである。このシステムは、サーバクライアント型で構築されている。全国に約3000店舗あるショップと呼ばれる販売店にクライアント端末が数台ずつ配備され、ショップスタッフの窓口業務を支援する為のシステムである。
窓口業務では、来店顧客のオーダーに合わせて、新規契約やサービス内容の変更、携帯端末の販売、料金の領収を行う。新規契約やネットワークサービス内容の変更の場合は、交換機システムなどの関連システムにその情報を通知し、回線開通やサービス内容の変更をリアルタイムに行う事で、来店顧客の要望通りの状態になった携帯電話端末を持ち帰ってもらう為の業務である。
1.2 窓口業務の特徴
ショップの窓口業務は、D社の事業を支える重要基幹業務である。窓口業務を行うショップスタッフは、20万人を超える。新商品の発売時に繁忙期となり、特に新商品の発売に伴う料金割引施策や新サービスのリリース時の窓口業務は年々複雑化している。それでも、そんな繁忙期こそ１分でも短い応対時間で回転率向上が求められるのが窓口業務の特徴である。
私は、この窓口業務支援システムのソフトウェア構造の見直しプロジェクトにシステムアーキテクトとして参画した。
題２章
2.1 私が想定した業務の変化
私が想定した業務の変化は、二点ある。
一つ目は、タブレット端末などのモバイル機器を活用した、簡易オーダーの待合室対応業務の追加である。現在の窓口業務は、汎用PCに専用アプリケーションというスタイルに限定した運用となっている。しかし、前述したように1分でも短い応対が求められている。そこで、簡易な手続きにおいては、持ち運び可能なタブレット端末で行う事ができる環境を整え、待合室での簡易オーダーの受付を可能にする業務が新たに発生すると想定した。
二つ目は、新サービス等のリリースに伴うシステム操作の変更内容のトレーニング時間が十分にとれなくなる事である。現在は、システムの操作方法の変更がある度にWebトレーニングシステムでのトレーニングを必須業務として組み込み、入力ミス等を抑止している。しかし、昨今の市場環境の激化により、競合他社が発表した割引施策に追従する必要性があり、数日間の内に新サービスのリリースの判断が下されていく事が予想される。そうなると、トレーニングシステムの準備にも限界があり、十分なトレーニングを受けられないまま窓口対応を行わなければならないスタッフがでてきてしまう。
2.2 ソフトウェア構造の設計について
(1)タブレット端末での窓口業務に備えたソフトウェア構造の設計について
私は、ソフトウェア構造の設計の時に、クライアント端末機器の多様化を考慮した。まず、クライアント端末機器の種類が業務ロジック部分に影響しないように、クライアントアプリケーションのソフトウェア構造を業務ロジックと通信データ制御部分とクライアント機器依存部分のコンポーネントに分離する設計とした。こうする事で、クライアント端末のタブレット化の対応では、通信データ制御部とクライアント機器依存部分のコンポーネントを修正する形となる。業務ロジックの変更が無いので開発規模を小さくできる。
(2)トレーニング業務時間の削減に備えたソフトウェア構造の設計について
トレーニング業務時間が削減される事を想定し、その分の埋め合わせとしてシステムのユーザビリティの向上が必要であると考えた。例えば、新規契約オーダ時に候補となる割引サービスを動的に表示したり、あるサービスの契約時に必須となる前提契約内容の確認を動的に促す機能などの追加である。このような機能があれば、システムの基本的な操作さえ把握していれば、新サービスリリースの度にシステム操作に関する詳細トレーニングがなくても窓口業務は遂行出来ると考えた。
もちろん、この機能については、経営陣の短期判断による短期改修に対応する必要がある。そこで、この機能のソフトウェア設計では、ルールエンジンを採用する方針とした。ルールエンジンは、サービス間の相関が定義されており、業務ロジックからの問い合わせに応じて回答する機能を持つ。このルールエンジンを活用して、サービスの相関チェック機能、チェック結果の動的表示機能、あり得ない組み合わせのエントリーをガードする機能を追加する事にした。
今後の新サービスのリリース時には、このルールエンジンの変更だけとなる為、ユーザビリティを向上と、短期改修の要望に十分答えられると判断した。
以上、二点のソフトウェア構造の設計の工夫により、想定される業務の変化がある場合でも、一番開発規模が大きい業務ロジックの修正が必要ないソフトウェア構造とした。
第三章
3.1 ソフトウェア構造の設計で生じた課題について
詳細設計のフェーズに入ると、クライアント端末機器の多様化を考慮したコンポーネントの分割に関する課題が発生した。業務ロジックと通信データ制御部分のコンポーネントを分割した事でコンポーネント間のオーバーヘッドが加わり性能要件が満たせないことが想定された。
背景として、このシステムの特徴である関連システムとのリアルタイム連携が関係してくる。前述したように、顧客に即日で無線サービスを利用してもらう必要がある為、交換機システム等の関連システムとのリアルタイム連携は必須である。その為、業務ロジックから通信制御コンポーネントへのデータの受け渡しは入力項目毎にリアルタイムで行うように設計していた。一つ一つのデータ量は少ないが、新規契約時などは入力項目が多くなるため、コンポーネント間のデータのやり取りも多くなる。その分、加わるオーバーヘッドも多くなってしまうのである。さらに、細切れで渡されるデータに対するエラー処理も複雑化し開発規模が増大する恐れもあった。
3.2 課題に対する対応策
私は、コンポーネント間のデータのやり取りが多くなってしまう事による性能劣化と開発規模の増大の課題に対処する為に、入力項目毎のデータをコンポーネント間でやり取りする方式から、オーダー毎に１つの電文を業務ロジック側で作成して通信データ制御部分に受け渡す仕様に変更することにした。これにより、１つのオーダーで約10から50回のコンポーネント間のやり取りがあったものを、1回にする事ができ、コンポーネント間のオーバーヘッドの課題を解消する事が出来る。逆に、追加で必要となるのがサーバアプリケーション側の機能の追加である。ひとまとめにして送られた電文を分解し、適切なシステムに振分けるコンポーネントを追加しなければならなくなる。しかし、サーバ側は、処理能力が高いので、この処理の追加による性能の問題は発生しないことが確認できたので、この方式を採用する事にした。
3.3 設計したソフトウェア構造に対するシステムアーキテクトとしての評価
私は、今回のソフトウェア構造の設計により見込まれる業務の変化に柔軟に対応できると考えている。柔軟性をもった設計の基本は、適切な処理の分割である。その基本を忠実に守り、更にルールエンジンという適切な技術を採用する事で業務の変化に強いシステム構造を支えるソフトウェア構造の設計が出来たと考えている。ー以上ー
そろそろ、証明写真の準備をしなければ。。。
さて、今回のエントリーも論文対策です。
お題は「業務の変化を見込んだソフトウェア構造の設計」
頻出問題の設計の問と思いますが、システム構造の設計とソフトウェア構造の設計は違いますよね。
実は、ソフトウェア構造の設計に言及する問は少ないようです。
システム構造の設計とソフトウェア構造の設計、どちらが問われているかきちんと見極めておかないと題意通りの回答が出来なくなってしまうので要注意ですね。
コンテンツも、システム構造の設計での工夫点、ソフトウェア構造の設計の工夫点と分けて双方用意しておかねばいけません。
問１ 業務の変化を見込んだソフトウェア構造の設計
企業を取り巻く環境の変化に応じて、業務も変化する。情報システムには、業務の変化に対応して容易に機能を変更出来るような、ソフトウェア構造の柔軟性が求められる。
このため、システムアーキテクトは、システム要件定義の段階から、業務の変化が起こり得るケースを想定し、変化の方向性やシステムに与える影響を予測する。ソフトウェア構造の設計では、その予測に基づいて、業務が変化してもシステム全体を大きく作り直す必要がないように考慮しなければならない。
例えば、次のようにソフトウェア構造の設計を行う。
・業務フローの制御部分と業務ロジック部分を分離する
・業務ロジックが互いに疎結合となるように分割する
・データアクセスコンポーネントを共通化する
その際、そのような設計を行う事によって引き換えに生じた課題に対応するための工夫を行う事が重要である。例えば、処理時間が長くならないように複数のプロセスを平行して処理したり、処理同士の整合性を確保する為に排他制御の仕組みを用意したりする。
設問ア あなたがソフトウェア構造の設計に携わったシステムにおける、対象業務の概要及び特徴について、800文字以内で述べよ
設問イ 設問アで述べたシステムについて、どのような業務の変化を想定したか。また、業務が変化してもシステム全体を大きく作り直す必要がないように、どのようなソフトウェア構造を設計したか。800文字以上1600文字以内で具体的に述べよ
設問ウ 設問イで述べたソフトウェア構造の設計において、生じた課題とそれに対応するために重要と考えて工夫した点、及び設計したソフトウェア構造に対するシステムアーキテクトとしての評価について、600字以上、1200字以内で具体的に述べよ
第１章 私がソフトウェア構造の設計に携わったシステムについて
1.1 対象業務の概要
私は、移動体通信事業社D社の情報システム部に勤務しているシステムエンジニアである。
今回、論述の対象とするシステムは、窓口業務支援システムである。このシステムは、サーバクライアント型で構築されている。全国に約3000店舗あるショップと呼ばれる販売店にクライアント端末が数台ずつ配備され、ショップスタッフの窓口業務を支援する為のシステムである。
窓口業務では、来店顧客のオーダーに合わせて、新規契約やサービス内容の変更、携帯端末の販売、料金の領収を行う。新規契約やネットワークサービス内容の変更の場合は、交換機システムなどの関連システムにその情報を通知し、回線開通やサービス内容の変更をリアルタイムに行う事で、来店顧客の要望通りの状態になった携帯電話端末を持ち帰ってもらう為の業務である。
1.2 窓口業務の特徴
ショップの窓口業務は、D社の事業を支える重要基幹業務である。窓口業務を行うショップスタッフは、20万人を超える。新商品の発売時に繁忙期となり、特に新商品の発売に伴う料金割引施策や新サービスのリリース時の窓口業務は年々複雑化している。それでも、そんな繁忙期こそ１分でも短い応対時間で回転率向上が求められるのが窓口業務の特徴である。
私は、この窓口業務支援システムのソフトウェア構造の見直しプロジェクトにシステムアーキテクトとして参画した。
題２章
2.1 私が想定した業務の変化
私が想定した業務の変化は、二点ある。
一つ目は、タブレット端末などのモバイル機器を活用した、簡易オーダーの待合室対応業務の追加である。現在の窓口業務は、汎用PCに専用アプリケーションというスタイルに限定した運用となっている。しかし、前述したように1分でも短い応対が求められている。そこで、簡易な手続きにおいては、持ち運び可能なタブレット端末で行う事ができる環境を整え、待合室での簡易オーダーの受付を可能にする業務が新たに発生すると想定した。
二つ目は、新サービス等のリリースに伴うシステム操作の変更内容のトレーニング時間が十分にとれなくなる事である。現在は、システムの操作方法の変更がある度にWebトレーニングシステムでのトレーニングを必須業務として組み込み、入力ミス等を抑止している。しかし、昨今の市場環境の激化により、競合他社が発表した割引施策に追従する必要性があり、数日間の内に新サービスのリリースの判断が下されていく事が予想される。そうなると、トレーニングシステムの準備にも限界があり、十分なトレーニングを受けられないまま窓口対応を行わなければならないスタッフがでてきてしまう。
2.2 ソフトウェア構造の設計について
(1)タブレット端末での窓口業務に備えたソフトウェア構造の設計について
私は、ソフトウェア構造の設計の時に、クライアント端末機器の多様化を考慮した。まず、クライアント端末機器の種類が業務ロジック部分に影響しないように、クライアントアプリケーションのソフトウェア構造を業務ロジックと通信データ制御部分とクライアント機器依存部分のコンポーネントに分離する設計とした。こうする事で、クライアント端末のタブレット化の対応では、通信データ制御部とクライアント機器依存部分のコンポーネントを修正する形となる。業務ロジックの変更が無いので開発規模を小さくできる。
(2)トレーニング業務時間の削減に備えたソフトウェア構造の設計について
トレーニング業務時間が削減される事を想定し、その分の埋め合わせとしてシステムのユーザビリティの向上が必要であると考えた。例えば、新規契約オーダ時に候補となる割引サービスを動的に表示したり、あるサービスの契約時に必須となる前提契約内容の確認を動的に促す機能などの追加である。このような機能があれば、システムの基本的な操作さえ把握していれば、新サービスリリースの度にシステム操作に関する詳細トレーニングがなくても窓口業務は遂行出来ると考えた。
もちろん、この機能については、経営陣の短期判断による短期改修に対応する必要がある。そこで、この機能のソフトウェア設計では、ルールエンジンを採用する方針とした。ルールエンジンは、サービス間の相関が定義されており、業務ロジックからの問い合わせに応じて回答する機能を持つ。このルールエンジンを活用して、サービスの相関チェック機能、チェック結果の動的表示機能、あり得ない組み合わせのエントリーをガードする機能を追加する事にした。
今後の新サービスのリリース時には、このルールエンジンの変更だけとなる為、ユーザビリティを向上と、短期改修の要望に十分答えられると判断した。
以上、二点のソフトウェア構造の設計の工夫により、想定される業務の変化がある場合でも、一番開発規模が大きい業務ロジックの修正が必要ないソフトウェア構造とした。
第三章
3.1 ソフトウェア構造の設計で生じた課題について
詳細設計のフェーズに入ると、クライアント端末機器の多様化を考慮したコンポーネントの分割に関する課題が発生した。業務ロジックと通信データ制御部分のコンポーネントを分割した事でコンポーネント間のオーバーヘッドが加わり性能要件が満たせないことが想定された。
背景として、このシステムの特徴である関連システムとのリアルタイム連携が関係してくる。前述したように、顧客に即日で無線サービスを利用してもらう必要がある為、交換機システム等の関連システムとのリアルタイム連携は必須である。その為、業務ロジックから通信制御コンポーネントへのデータの受け渡しは入力項目毎にリアルタイムで行うように設計していた。一つ一つのデータ量は少ないが、新規契約時などは入力項目が多くなるため、コンポーネント間のデータのやり取りも多くなる。その分、加わるオーバーヘッドも多くなってしまうのである。さらに、細切れで渡されるデータに対するエラー処理も複雑化し開発規模が増大する恐れもあった。
3.2 課題に対する対応策
私は、コンポーネント間のデータのやり取りが多くなってしまう事による性能劣化と開発規模の増大の課題に対処する為に、入力項目毎のデータをコンポーネント間でやり取りする方式から、オーダー毎に１つの電文を業務ロジック側で作成して通信データ制御部分に受け渡す仕様に変更することにした。これにより、１つのオーダーで約10から50回のコンポーネント間のやり取りがあったものを、1回にする事ができ、コンポーネント間のオーバーヘッドの課題を解消する事が出来る。逆に、追加で必要となるのがサーバアプリケーション側の機能の追加である。ひとまとめにして送られた電文を分解し、適切なシステムに振分けるコンポーネントを追加しなければならなくなる。しかし、サーバ側は、処理能力が高いので、この処理の追加による性能の問題は発生しないことが確認できたので、この方式を採用する事にした。
3.3 設計したソフトウェア構造に対するシステムアーキテクトとしての評価
私は、今回のソフトウェア構造の設計により見込まれる業務の変化に柔軟に対応できると考えている。柔軟性をもった設計の基本は、適切な処理の分割である。その基本を忠実に守り、更にルールエンジンという適切な技術を採用する事で業務の変化に強いシステム構造を支えるソフトウェア構造の設計が出来たと考えている。ー以上ー
この記事へのコメント