論文治療クリニック（外来）

あたらしい患者さんが相談にこられましたよ。

超初心（診）者です。

春にＳＷに無事合格し、今秋初めてＡＥを受験します。
午後�T迄はなんとかなりそうですが、論文で悩んでいます。
何とか一作目（システムテスト計画）を書き上げてみたんですが、どの位のレベルなのか
どこを改善しなければならないのか、全く想像がつきません。

いきなりこの様なお願いをするのも、失礼かとは思いますが、是非ドクターエーロン＠クリニ
ック院長の診療を受けさせて頂きたいのですが．．．
　

　初診者さん。早期治療が大事です。論文かけない病もいまや直る病気です。
診察してあげます。最近、治療希望の患者が増えています。しげさんを含めこれで4人目
ドクターも忙しいのですが、NAOKI医師にも協力願います。
（NAOKI医師文句はないな。昨年の恩を忘れてないね。）
長期療養中の三連星氏もいるし・・・（すっかり、医者の知識をつけているよね。）

NAOKI医師いかがか？

こんにちは Naokiです。

NAOKI医師なんて、まだまだ私も精進あるのみです。

私もＰＭ区分の１受験生であるので、
これからヒートアップしていきます。
ライトな見立てでよければ、できる限り協力しますよ。
PS
人の論文を読むと自分のためになることに最近気づきました。

NAOKI医師も大分成長しているね。論文医学は人のため、自分のためということに気が付きおった。一人前の日も近いのう。で、患者の超初診者氏のテーマは？

診療を受けさせて頂くことになった初診者です。
今日中にお送りするお約束でしたが、早く結果を知りたくて、昨日のうちに管理者用メール宛
に送らせて頂きました。テーマはシステムテスト計画です。
NAOKI医師に診て頂けるのですね！　よろしくお願いします。

ところで、このＨＰで良く出てくる「論述式突破ポイント集、論述式突破作戦」の出版元など
教えて頂きたいのですが。

ほう。H９のシステムテストですか。これもAEには重要ですね。そろそろ2回目が出題される可能性もあるし、さっそく。問題を見てみようじゃないですか。ちなみ、患者の超初診者氏がいっている「論述式突破ポイント集、論述式突破作戦」の出版元は「資格の学校」TACさんです。情報処理講座の責任者の方にお会いする機会があったので、「本屋で売ってください」とお願いしたら、「バラ売りはちょっと・・・」とお茶を濁されてしまった。TACの戦略だから、本屋では購入できず、残念ですね。

問３　システムテスト計画について

システム開発の最終段階で行われるシステムテストは、システムの機能・性能などの評価項目に対するテストを実施することによって、システムの完成度を総合的に検証する作業である。
　開発したシステムが、要求定義を満足しているか、データのインテグリティ・運用の一貫性を確保しているか、レスポンスタイムやターンアラウンドタイムが性能目標値を満足しているか、などの品質要件の評価を行う必要がある。
　しかしながら、実際には使用可能な端末台数が十分に確保できない、システムの使用開始時期との関係でテスト期間が限られている、またセキュリティ確保の必要から現実のデータが使用できない、などの制約によって、すべての要件を完全に網羅した評価を行うことは困難なことが多い。
　そこで、これらの制約条件を踏まえた上で、いかに効果的なシステムテスト計画を立案するかが重要となる。
　具体的には、テストの目的を明確にし、テスト項目・テスト方法・スケジュール・検証方法などを設定し、効率良く実施する手順・体制・環境を定めることが必要である。

　あなたの経験に基づいて、設問ア〜ウに従って論述せよ。

さてさて、患者さんの症状をみてみますよ。

平成９年　問３　システムテスト計画について
．．．．：．．．．１．．．．：．．．．２．．．．：
（設問ア）
　　　　　　　　　　　　　　　　　　　　　　
1.システムの概要と特徴

1.1.システムの概要

　Ａ社は県内を中心に７０店舗を展開する中堅クラスの
スーパーである。Ａ社は日次決算処理を基本としており
毎日店舗から送られてくる発注先からの納品伝票を本社
財務本部にてチェックを行った後、会計伝票の入力作業
（未払金の計上）を行っており、その作業に４時間／日
を要している。
　現在、約２００社ある発注先の内、当面の課題として
取引量の多い上位１５社について、インターネットを利
用した電子取引を行う事により、未払金計上作業の効率
化を図る目的でシステム化の検討を行った。
　私は、ソフトウェア企業に勤務しており、プレ段階か
らシステムの検討に入り受注後、基本設計・詳細設計の
作業に携わる事になった。

1.2.システムの特徴

　具体的な運用方法は以下の通りである。
　(1)．発注先での運用方式（ａ又はｂを選択して頂く）
　　ａ．ＥＤＰ処理を行っている場合は、既存データに
　　　加工を行った上で、Ａ社に納品データを送信（デ
　　　ータ送信方式）して頂く方式。
　　ｂ．ＥＤＰ処理を行っていない場合は、直接Wｅｂ
　　　上より、納品伝票を入力（伝票入力方式）して頂
　　　く方式。
　(2)．Ａ社での運用
　　　発注先から送信または入力された納品伝票を確認
　　後計上する事で、自動的に財務会計システムへ未払
　　金のデータを受け渡す。
　発注先への受入テストを前に、発注先側の運用部分は
ＡＳＰによる構築、Ａ社側の運用部分はＶＢによるシス
テムの構築を行った。

　　　　　　　　　　　　　　　　　　　　　　　　　
（設問イ、ウ）
　　　　　　　　　　　　　　　　　　　
2.テスト計画と評価の対象とした品質要件

2.1.運用までの期間設定

　Ａ社からの強い要望で、運用を新年度（４月）から開
始したいという設定がされた。それに伴い、発注先への
説明会を１２月中旬から１週間をかけて３０社に対して
行い、取引量の多い上位１５社については、４月から運
用を開始するという了解を頂いた。
　運用までのスケジュールは、１、２月を発注先側の準
備期間とし、３月から発注先の受入テストを実施すると
いう設定を行った。
　ただし、ＥＤＰ処理を行っている発注先については、
既存デ−タに対し、データ加工（科目コード、補助コー
ドの付与等）を行って頂く必要があり、発注先側のシス
テムの機能追加改修等の作業が発生する。発注先のシス
テムを担当しているＳＥ会社との調整が必要であり、運
用に遅れてしまう事態が予想された。

2.2.発注先のEDP環境の調査

　説明会に先だって発注先のＥＤＰ環境（ＥＤＰ処理の
有無、ＰＣ環境、その他）の調査資料を配布し、説明会
へ持参して頂いた訳だが、発注先によって、ＥＤＰ処理
している会社、していない会社、ＰＣを設置している会
社、設置していない会社等様々な形態がある事が判明し
た。
　受入テストについては、最低条件でＰＣを設置しイン
ターネットが利用出来れば伝票入力方式での受入テスト
及び運用が可能になるようにＡ社側と調整し、了解を頂
いた。

2.3.セキュリテイの確保

　発注先側で利用して頂く、ログオン画面には基本的に
Ａ社側で設定したユーザＩＤとパスワードを入力する事
で、業務メニューへ遷移するよう設定した。
利用者（発注先）認証とデータの暗号化についは、第三
社認証機関であるＶ社へ委託し、ＳＳＬによる暗号化通
信を採用した。

2.4.発注先の送信データの品質要件と検証方法

　Ａ社側での受信処理のプログラムは、発注先送信デー
タの全ての項目についてチェックを行い、それに加えて
データ項目間での関連性のチェックを行う仕様にした。
それに伴い、Ａ社側で正常に受信されれば、受入テスト
合格という品質要件を設定した。
　検証方法としては、発注先の送信データが取り決めた
通りの正常なデータで送信されるか、又、データに誤り
があった場合に、Ａ社の受信処理プログラムが表示する
エラーメッセージ（具体的にデータのレコード行数と項
目名およびデータ内容を表示させた）から、発注先自ら
誤りを判断出来、誤り個所の局所化が出来るよう工夫し
た。受入テストは、Ａ社の担当者が発注先に出向いて行
うようにした。

3.テストの制約と工夫

3.1.受入テスト環境

　今回のシステム化は、発注先への説明会から受入テス
トの開始まで、２ヶ月しかなく受入テストに間に合わな
い、発注先が出できた
　今回の受入テストに間に合わない場合でも、今後随時
受入テストを実施出来るよう、テスト環境を残すように
し、４月の運用を開始したあともテストが可能な状態に
なるようＡ社に提案し、了解を頂いた。

3.2.発注先のＰＣ環境

　発注先が使用しているＰＣのハードウェアのスペック
や、ソフトウェアの構成がまちまちであり、受入テスト
に入った段階で、Ｗｅｂ上の画面構成が崩れるといった
現象や、参照系のプログラムがメモリ不足で表示されな
いといった現象が、数件報告された。
　上記問題点に対し以下の処置をとり、ソフトウェアに
ついては、一部バージョンの限定を実施した。
・画面サイズについては、最小の８００×６００ドット
で表示出来るよう改修を実施した。
・メモリの最小構成を６４ＭＢとし、表示出来る行数を
２００行程度に限定した。

4.テスト計画の評価と課題

4.1.テスト計画の評価

　当初予定の１５社に対し、１３社が受入テスト及び運
用を開始する事が出来た。
今回運用を開始出来なかった、発注先に対しては、既存
の受入テスト環境を残す事により、引続き受入テストを
可能にし、随時運用に参加して頂くように調整した。
　発注先からの送信データのチェックは、全てプログラ
ムで行っており、データの品質要件の確認について人手
を介さずに自動化する事が出来、Ａ社側のデータの検証
作業を効率化する事が出来た。
　運用開始後、Ａ社でこれまで４時間／日かかっていた
納品伝票のチェック及び入力作業を電子データで取得す
る事により、２時間／日の時間短縮を図る事が出来た。

4.2.今後の課題
　　　　　　　　　　　　　　　　
　発注先向けに実施した当システムの説明資料（運用環
境、データ交換仕様等）については、ハードウェアのス
ペックや、ソフトウェアのバージョン等の制限事項を具
体的に記載し、スムーズに受入テストが実施出来るよう
に資料の改修を加える。
　当システムに参画していない発注先に対しては、Ａ社
と協力して今後、発注先への説明会を実施し、すべての
発注先が当システムへ参画して頂くようにし、未払金の
入力作業をなくしていく。
　今後、当システムを発注先がもっと効果的に利用して
頂けるよう、発注先からのみのデータ送信だけではなく
Ａ商事から発注データを送信するといった・運用が行え
るよう、システムの展開を検討していきたい。
　　　　　　　　　　　　　　　　　　　　　　　以上

ふむふむ。では、NAOKI医師に見てもらいましょう。NAOKI医師　よろしく。

Naokiです。
厳しい意見を求めるかたが多いようなので、感じたままを素直にかきます。奮い立ってくれることを期待します。

１）記述内容が大きい小さいの筆圧が一定しておらず。主張が伝わってこない。

新しいキーワード、範囲の多きなシステムで大風呂敷を広げた形ですが、そころここらでほころびが見えます。
まず、問題はシステムテストについての問です。
基本設計・詳細設計の作業しか参加しなければシステムテスト段階での経験はかけないのでは？

２）新しいキーワードで目を引くが意味を取り違えている。

　本当に経験したことを書いているのだろうかという懐疑心にさいなまれてしまいます。

　認証機関はユーザの公開かぎを預かり本人である証明を行う機関をいいます。
ＳＳＬはＩＥやネスケなどブラウザがもつ暗号化のプロトコルですね。意味を取り違えているか、説明不足ということになりますね。

３）重要ポイントが薄い
　もっとも重要なことはシステムテストの肝である評価の対象とした品質要件なぜそのような要件を設定したかが押さえ切れていないことでしょう。

　思いのたけを一気に吐き出しますよ。

　システムテストでは、品質要件としてユーザと品質目標値について、要求仕様もしくは基本設計書で明文化し、ユーザとの共通認識をとっておく必要があります。　その品質目標値はできるかぎり、定量的、又は定性的な内容でなければいけません。そうでないと良い悪い、どこまでテストすればよいか、どのようなテストが効率的か判断できませんもんね。

ということをまず書いたほうが良いです。一番重要なことを頭に書きましょう。

とはいっても時間的にだとか環境的にだとか色々問題があって全部を網羅できないのが現実ですよね。そんなすったもんだを書きましょう。

　記述内容では社外からのデータを受信することにこだわっておられますが、一番大事なのは、A社システム会計DBの中身が正しく更新されているかということではないのでしょうか？（お財布をもっているのはどなた？） 他の会社がつくったプログラムを一生懸命テストしてもどうかと思います。また受信プログラムが正常受信したらＯＫではテストとして成立していないのでは？

　こういいきってしまうと話がここで終わってしまいますので、社外からのデータが重要ということで話を続けます。

　そういった取り決めはインターフェース仕様、プロトコルとして設計段階で決定されることをシステム間で取り交わされることですね。
　ここでも品質要件として、送信されるデータの電文長の最大値や運用時間・送信時間、文字コードの問題、金額の単位や商品コードの共通化など取り決めてシステムテスト項目としなければいけないことが山ほどあるような気がしますがいかがでしょうか？

テストする対象が何ということをきちっと抑えることが大前提です。

「レベルしらず」ということでしたが、私の「好み」だけかもしれませんが、もっと平易な言葉で良いので設問のキーワードに誠実に抑えて書くことをお勧めしますよ。
設問に対しての心構えをしっかり持っておきましょう。お嫁さんのお父さんに挨拶しにいったときの、「仕事は何を」と聞かれた質問だと思ってください。
ふざけたり、はぐらかしたり、自分の趣味の話をしますか？そんなとき誠実「仕事について」答えるでしょう？
それと同じくらいの気持ちで答えてください。

好き勝手言いましたが、かくいう私もＰＭの１受験生です。ＰＭ論文１つ書き上げたのですが、出てくるキーワードとキーフレーズが経験とフィットせず支離滅裂です。自信喪失しています。
　ただ、試験日までに問題意識をもち自問自答する苦しさのみが、栄冠をもたらしてくれると思いますよ。（ううっ、自分自身も励ましているのです。）論文一緒にがんばりましょう。では

NAOKI医師はそうとう厳しい診察結果をだしてるね。院長もじっくり見ましたので、次には私の見立てをお伝えしましょう。私も厳しい見立てをするかもしれませんが、まだまだ試験まで時間はあります。これから適切な治療を施せば、大丈夫ですからめげずに頑張ってください。

まず、全体の構成を確認しましょう。

この問題の骨子まず、全体の構成を確認しましょう。問題文と設問をくらべると、上記のように整理できます。
今回の患者さんの論文は、問われたことにたいして、的確に答えていないという点が大きな問題です。

（設問ア）
1.システムの概要と特徴
　1.1.システムの概要
　1.2.システムの特徴
（設問イ、ウ）
2.テスト計画と評価の対象とした品質要件
　2.1.運用までの期間設定
　2.2.発注先のEDP環境の調査
　2.3.セキュリテイの確保
　2.4.発注先の送信データの品質要件と検証方法
3.テストの制約と工夫
　3.1.受入テスト環境
　3.2.発注先のＰＣ環境
4.テスト計画の評価と課題
　4.1.テスト計画の評価
　4.2.今後の課題

上記が患者さんのタイトルの抜粋です。この大項目、中項目だけみても、的確に解答しているのか分かりません。また、

2.テスト計画と評価の対象とした品質要件

2.1.運用までの期間設定

　Ａ社からの強い要望で、運用を新年度（４月）から開始したいという設定がされた。それに伴い、発注先への説明会を１２月中旬から１週間をかけて３０社に対して行い、取引量の多い上位１５社については、４月から運用を開始するという了解を頂いた。
　運用までのスケジュールは、１、２月を発注先側の準備期間とし、３月から発注先の受入テストを実施するという設定を行った。
　ただし、ＥＤＰ処理を行っている発注先については、既存デ−タに対し、データ加工（科目コード、補助コードの付与等）を行って頂く必要があり、発注先側のシステムの機能追加改修等の作業が発生する。発注先のシステムを担当しているＳＥ会社との調整が必要であり、運用に遅れてしまう事態が予想された。

2.2.発注先のEDP環境の調査

　説明会に先だって発注先のＥＤＰ環境（ＥＤＰ処理の有無、ＰＣ環境、その他）の調査資料を配布し、説明会へ持参して頂いた訳だが、発注先によって、ＥＤＰ処理している会社、していない会社、ＰＣを設置している会社、設置していない会社等様々な形態がある事が判明し
た。　受入テストについては、最低条件でＰＣを設置しインターネットが利用出来れば伝票入力方式での受入テスト及び運用が可能になるようにＡ社側と調整し、了解を頂いた。

テスト期間が厳しいという制約に持っていこうとしているのだと思いますが、かなり無理があります。通常、このように取引先を巻き込んだシステム開発をする場合、もっと事前計画で詰めることが必要です。（というか、あたりまえ）テスト計画の段階になって、取引先のシステム環境を知るなんてことは現実にはありえないでしょう。
もし、この話が本当なら、AEとしてかなり気づきのない仕事をしていると評価されてしまい、論文読んでもらえない可能性が高いです。

2.3.セキュリテイの確保

　発注先側で利用して頂く、ログオン画面には基本的にＡ社側で設定したユーザＩＤとパスワードを入力する事で、業務メニューへ遷移するよう設定した。利用者（発注先）認証とデータの暗号化についは、第三社認証機関であるＶ社へ委託し、ＳＳＬによる暗号化通信を採用した。

この説明に対する後の記述がないですね。この１段落は完全に浮いてます。テスト計画に関係ないとみなされます。

ということで、合格レベルの論文を書くためには以下の点を留意してください。

1.1システムの概要
　　　　省略
1.2システムの特徴
＜ポイント＞
テストを実施する上で特徴的なことを書く必要があります。たとえば、
�@機密性が要求されるシステム→本番データがなかなか使えない。
�Aオンライントランザクション数が多く整合性維持、レスポンスタイムがポイントである→その環境を人手で用意するのは大変である。→トランザクションを大量発生させるツールの用意
�B顧客の前で処理するので、レスポンスにはシビア→目標値をクリアしないと稼動できないので、この部分は優先した。
などの特徴を書くのですが、以降の制約条件に繋がる形で書かないといけません。単に特徴だけ適当に書くと、品質要件や制約に結びつかなくて苦労します。この部分を後を考えることなく、先に書き始めてしまうとあとで取り返しのつかない状態になってしまいます。

2.1評価の対象とした品質要件その理由
　＜ポイント＞
まず、AEの大事な仕事に「システムテスト計画」があるので、枕言葉のように「前記システムの特徴を踏まえ、システムテストの重点確認ポイントを加味しながらシステムテスト計画を策定し、メンバーに徹底した」と書いておくのがよいでしょう。メンバーに徹底した、ユーザーと協議しながらポイントをまとめたとか、書いておくと非常にいいです。いかにもテストが上手く進むような印象を採点者に与えることでしょう。これもアドバンテージです。、

問題文に、重要な検証観点は以下の通り書いていますので、このまま使ってしまうのが得点を多くするコツです。

　a要求定義を満足しているかの観点
　　システム開発で重要なのは、要求定義を満足しているかである。特に今回のシステム開発では複雑な会話処理、画面遷移がある。ユーザーにとって、この機能が十分機能するかはこのシステム評価に直結する。このため、この部分は非常に重要な品質要件であった。

　bデータのインテグリティ・運用の一貫性を確保しているかの観点
　　先ほどの特徴でも書きましたが、整合性が壊れる可能性が高いシステムの場合は、このあたりが重要であると書いておき、理由を述べておきます。

　cレスポンスを満足しているかの観点
　　これも同様です。レスポンスはほとんどの基幹系系システムで問題になるので、適当な数値目標とともに書いておき、それを満足しないと稼動することは出来ないなどの最もらしい理由を書いておきます。　

2.3あらかじめ考慮した制約条件と工夫した点

　制約におけるキーワードは、端末がない、時間がない、本番データが使えないです。
・端末がない場合は、しようがないですね。机上でできるだけデータを作成して、多人数で効率的使った。時間決めて順番　で使ったとかかくしかないですね。
・時間がない場合は、本当に効率的に実施する計画を用意したと書くのがようでしょう。効率的にするためにユーザーの事務マニュアルを借りた。ユーザーにデータを提供してもらうことでデータ作成時間を削ったとか。本来システムテストはユーザーにも参加してもらうのが普通ですから、この辺は上手く書かないといけないとおもいますが。

3.1計画の評価
　このあたりは、でどうだったの？を書けばいいです。上記の工夫点を1つ2つ例にして、「このやり方はよかった。こういう効果もあったんです。」と書ければバッチグーでしょう。

3.2今後の改善点

最後に改善点ですが、これはそれぞれあるでしょうから、一様にはいえません。まあ、私が書くなら・・・

「今回は、時間がないなかで制約を考慮したシステムテストを行う必要があった。幸い今回は無事乗り越えることができたが、今後もこのような事態には遭遇するはずである。今回の得たものを自分の今後の業務だけでなく、全社的資産として継承していく必要がある。そのためシステムテスト効率化マニュアル的なものをまとめ、共有化していく必要があると痛感している。」

という感じですか。

ということで、このへんで治療を完了します。今後は、このような形で論文を書くようにしてください。