論文治療クリニック

ライン

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

今年も治療がスタートしました。今年初の外来患者さんは「さんしのごい」さんです。どうやら，この名前はバードウォッチングでの名前らしいです。「ごい」とは「ごいさぎ」のことかな？では，プロフィールを拝見。

Dr.エーロン院長様

ご無沙汰しております、さんしのごいです。ようやく問題文と論文をタイピングし終えました。本文に入る前に、自身改めて読んでみて気付いた点を挙げておきます。

・問題文に沿ったテーマの実体験を取り上げてはいるが、設問で想定された順に展開されていない（設問に沿った段落分けがされていない）
・設問アから書いている
・情報処理用語が少ない
・全体的に文章が冗長（字数を稼ぐためというのがミエミエ）

ちなみにITEC社の採点結果は37点です。では、「治療」をお願い致します m(_ _)m。

　ITEC（大病院）の診察は３７点ですか。これは手厳しい。３７点では心不全状態です。では「論文治療クリニック」で見事に回復させ，社会復帰をさせてあげましょう。まず，問題から。

性能改善について　　　　　　　　　(H10秋-AE 午後Ⅱ問３)

　適用業務システムの性能目標は、業務要件や運用要件に基づいて、スループット、ターンアラウンドタイム、レスポンスタイムなどの具体的な数値として設定される。

　開発が進みテストを行った結果、性能目標が達成できていなければ、ネットワーク監視ツール、パフォーマンスモニタ、トレースツールなどによって原因を調査・分析し、性能改善を実施する。

　具体例としては、次のような性能改善のための対策が挙げられる。

（１）チューニング
　　・バッファサイズ、実行優先順位、処理多重度などのシステムパラメタの変更
　　・データベースのインデックスの見直し、排他制御方式の見直し
　　・プログラムロジックの変更

（２）設計レベルの見直し
　　・サーバの分割・統合、サーバとクライアント機能分担の見直し
　　・データベースの物理構造の見直し
　　・プログラム構造の見直し

（３）リソースの追加
　　・メモリ、ディスクなどのハードウェアの増設、ネットワークの高速化

これらの対策を実施するに当たっては、期間、コストなどの検討も必要である。
あなたの経験に基づいて、設問ア～ウに従って論述せよ。

設問ア
　あなたが開発に参画したシステムの概要とテストで発生した性能上の問題について、800字以内で述べよ。

設問イ
　設問アで述べた性能上の問題について、どのようにしてその原因を調査・分析したかを述べよ。さらに対策としてどのような性能改善を実施したか、実施に当たって検討した内容とともに、具体的に述べよ。

設問ウ
　設問イで述べた性能改善の結果について、あなたはどのように評価しているか、また今後改善すべき点は何か、それぞれ簡潔に述べよ。

ほう。院長が論文医師国家免許を取得した「性能改善」ですね。これは結構。合格したテーマなのでだれよりも正しい診察と治療が期待できますね。では，早速，患部をみせてもらいましょう。
=====================================================================

設問ア
１．システム概要及び発生した問題点について
　Ｓ社は従業員約５００人、派遣社員約１０００人の某都銀のシステム運用子会社で、東京の本社を中心とし、関東一円の９ヶ所の事業所（センター）を所有している。Ｓ社の総務部では毎月末になると従業員及び派遣社員からの勤務報告書を受け取り、記述に不備があった場合は所属するセンター長に問い合わせた上で訂正を行い、給与計算を行っていた。
　今回、Ｓ社では月末の勤務報告書確認作業での総務、各センター長双方の負担を軽減する為、勤怠管理システムを導入することになった。このシステムは総務部に設置されたＰＣ１台と本社及び各センターに一台ずつ設置されたタイムレコーダーとから成り、その間は公衆回線及びモデムで接続されている。従業員・派遣社員には一人につき一枚ずつカードが配布され、出勤時及び退社時には必ず入口に設置したタイムレコーダーに記録を打刻する。総務部ではＰＣの画面から各タイムレコーダーの打刻データを翌朝収集し、勤怠データに変換して印刷した帳票を各センターにＦＡＸで送付して確認を依頼し、打刻漏れ等の申告に応じて画面からの修正を行う。
　さて、このように主に総務の作業負担軽減を期待されたシステムであったが、実際に導入し運用を開始したところ、毎月一回月末に行う事になっている再計算処理が遅いという問題が発覚した。通常、再計算処理は総務部のオペレーターが退社前の午後８時頃に実行するが、処理に１４時間以上かかる事があり、翌朝の打刻データ収集が遅くなってしまうのである。

設問イ
２．原因の調査・分析および対策
　ユーザーから、「月末の再計算処理が翌日の業務に支障の出ない時間（７時間以下）で終わるようにして欲しい。」との依頼を受け、私は早速現在の処理方式の問題点洗い出し、及び対策の検討を行った。尚、対策を進めるにあたって
　・既にシステムの開発は終わり保守段階に入っている為、保守要員（私一人）のみで対応しないといけない（対応費用を別途請求する事は状況的に不可能）
　・次の再計算処理（一ヶ月後）までに対応して欲しい

　　との要望であった

この２つの制約事項があった為、私が主担当として作業を行い、開発時のプロジェクトリーダーに週一回状況を報告し、問題等あれば指示・アドバイス等を迎ぐという方法で進めてゆくことになった。
　現在の再計算処理の流れを調査してゆくうち、処理が遅くなる要因の一つとして、データベースの設計で正規化を進め過ぎている（この出退勤システムはＰＣ上のＲＤＢソフトを用いて作られている）事が判明した。すなわち、タイムレコーダーから収集した出社時間、退社時間およびあらかじめ社員毎に申請・登録しておいた勤務体系の３つの情報を元に、勤務時間を算出するのだが、勤務時間帯（何時から何時までを勤務時間、もしくは休憩時間とするか、さらに何分単位で切上／切捨てを行うか）の情報を格納するテーブルと勤務体系自身の情報を格納するテーブルが１対多の関係になっているのである。従って、１件（特定社員、特定日付）の勤怠情報から勤務時間を算出するのに、対応する勤務時間帯の情報を全て抽出して一件一件から勤務時間を算出して累計してゆくという方式を取るという処理が社員・協力会社要員に一ヶ月の日数を乗じた件数分行われていたのである。
　この調査結果から、対策の方針は”如何にして勤務時間帯テーブルへのアクセス回数を減らすか”という事になった。それに対し、私は以下の２つの案を考えた。

　案１、正規化を戻し勤務体系テーブルに勤務時間帯情報分の項目も付加する。
　案２、改め勤怠データを勤務体系順にソートし、勤務体系が変わった時に初めて勤務時間帯情報をテーブルから読み込みメモリ上に格納する（２件目以降はメモリアクセスとなる）

（注：一つの勤務体系に対して時間帯の情報は高々１０件以内である事を加味した上で上記案を立案した）
案１はわかり易いが、作業期間が２ヶ月程かかってしまう見通しだった上、勤務体系や時間帯情報を登録する画面の修正も必要となるという問題もあった。それに対して案２はデータベースの構造を変える必要は無く、作業期間も１０日位の見通しであった為、リーダーとも合意した上で第２案を選択することになった。なお、一つの勤務体系に対し、メモリに格納する勤務時間の件数の上限は２０件とし、勤務体系登録画面で２０件を超える勤
務時間帯を登録しようとすると警告メッセージを表示する機能を組み込む事、及びそのことをマニュアルにも記載するという条件でユーザーの了承も得る事ができた。
　再計算機能を修正し、単体テストを行った後、結合テストとして実際にユーザー先で先月使用したデータを提供して頂き、再計算処理を行ってみる事にした。ところが、修正前には１４時間以上かかっていた処理であり、場合によっては長時間監視していなければいけない。その為、データベース上にワークテーブルを作成し、処理開始時と処理終了時の時刻をワークテーブルに格納する簡単なツールを処理に組み込む事にした。
さて、その結果であるが、約１時間という目標を大きく上回る結果となった。

３．今回行った分析・設計についての評価及び改善
　今回、私が行った分析プロセスは、処理の内容を解析し、フロー図に落としてゆくというごく普通の手法であり、問題点も見つかるべくして見つかったという感がある。とはいえ、結果から見れば目標だった再計算処理７時間以内という数値を大きく上回っており、また実現するための改善方法も定められた期間、要員で実現可能な方法であり、さらには一勤務体系への時間帯情報登録可能件数の上限を２０件と決定するプロセスも後付けながら調査に基づいたものであり、マニュアルや画面対応等ユーザーへの配慮も成されたものであったと思われる。
しかしながら、では何故もともとそのように設計されていたのか？（開発段階で仕様通り動く事以外に配慮されていなかったのではないか？）さらには、１時間まで短縮という見方によっては極端な効果を挙げてしまった為、かえってユーザーに不信感を与えてしまった可能性もある。
　今後の改善としては、他に設計段階で実運用の観点から考慮漏れしている部分が無いかどうかの見直し、保守要員として他に挙がっているユーザーからの要望の実現及びそれらを確実に行う事で顧客満足度を向上させるというテーマに取り組むべきと考える。さらに、一通りの設計見直し、要望に応じた機能改善が終了したところで、このシステムをパッケージとして他のユーザーにも導入する事を検討したいと考えている。

どうですか？このクリニックで治療し，AEに合格した元患者たちは見ているでしょうか？みんなの見立てを教えてください。院長の見立ては・・・

　　　　　　　　診断結果・・・かなり「重症」である。集中治療室で治療が必要。

と診断されました。細かく説明すると長くなるので，まず目立ったところから。

設問ア
　あなたが開発に参画したシステムの概要とテストで発生した性能上の問題について、800字以内で述べよ。

設問アはテストで発生した性能上の問題を問われています。いいですか，あなたはシステムを開発中で，性能要件を最初に設定している前提で出題されているのです。テストフェーズで，その目標と結果のギャップを認識することを性能評価と呼び，そのギャップを現実のシステムで運用できるようにすることを「性能改善」と呼ぶのです。問題にも，このように書いあるはずです。確認してみてください。

私の言っていることと違うでしょうか？ちっとも違いませんよね。この問題の主張は，こういうことです。
したがって，論文に書くべき内容の背景には，
　　　　　　　　　　　　　　　　　①システム開発中案件　　　で
　　　　　　　　　　　　　　　　　②当初設定した性能要件（要件定義フェーズで定義したはず）を満足しない結果が
　　　　　　　　　　　　　　　　　③システムテストで明らかになった。

このシナリオで書くことが大前提です。これ以外は外道な論文となり，採点されないか評価が著しく低い「はずした論文」となってしまいます。これを理解したうえで，患者さんの論文を見ますと・・・・

「病巣部分１」

・・・さて、このように主に総務の作業負担軽減を期待されたシステムであったが、実際に導入し運用を開始したところ、毎月一回月末に行う事になっている再計算処理が遅いという問題が発覚した。通常、再計算処理は総務部のオペレーターが退社前の午後８時頃に実行するが、処理に１４時間以上かかる事があり、翌朝の打刻データ収集が遅くなってしまうのである。

「病巣部分２」
・既にシステムの開発は終わり保守段階に入っている為、保守要員（私一人）のみで対応しないといけない（対応費用を別途請求する事は状況的に不可能）

他の患者さんお気づきになりましたでしょうか？なんか変？ですね。そうです。この論文はとっくに開発が終わって保守に入っているシステムに対する改善案件なんです。要求されているテーマを別解釈しているんです。これではせっかく書いた論文が浮かばれません。ずれているんです。完全に。（ちょっと厳しいが，これも治療のためですから我慢して！）

あと，すごく気になるんですが，そもそも，このシステムは本番稼動前になにをテストしたのでしょうか？ぜんぜん性能要件を満たしていないんです。おそらく，性能要件分析もしていないし，性能テストもしていないのでしょう。そもそも，パソコン１台とモデムを使い，ネットワークしているシステムなんですから，ほとんどシステムというよりも機器をつなげただけのものといえます。この仕組み自体の有用性認めるんですが（システムの有用性は規模ではなく，どのように業務に貢献するかです）情報処理技術者試験の論文題材としては？という気がします。

院長がこのテーマで書いたときは，生命保険会社の基幹業務の性能改善でした。ユーザ数，顧客への影響，コスト，期間，メンバー数，新技術の利用，特別な機器の利用などかなり大きなものでした。これくらいの題材でないと，どうかな？と思います。（注：詳しくは，はじめての午後Ⅱ論文攻略ゼミ「経林書房」のAE編とAE合格論文集「リックテレコム」の模範論文参照）

ただし，この論文をそういう形で架空のシステムに変えてしまう手はあります。これは，またあとのほうで教えます。

とにかく，たくさん指摘したいことはあるのですが・・・（以下次回）

つづきです。うーん。設問イの書き方も気になります。設問イで要求されていることは・・・

①設問アで述べた性能上の問題について、どのようにしてその原因を調査・分析したかを述べよ。

②さらに対策としてどのような性能改善を実施したか、実施に当たって検討した内容とともに、具体的に述べよ。

この２点を求められています。

①では、原因を調査した方法を書く必要があります。その方法は問題にある通り・・・

ネットワーク監視ツール、パフォーマンスモニタ、トレースツールなどによって原因を調査・分析し・・・

このように何らかのモニタリングツールを使って分析することが想定されています。午後Ⅱ論文では，できるだけ問題の記述を取り込んで回答したほうがよいと言われているし，私もそのとおりだと思います。当然，テキストや指導ではそのように誘導しています。一方，この論述では・・・

現在の再計算処理の流れを調査してゆくうち、処理が遅くなる要因の一つとして、データベースの設計で正規化を進め過ぎている（この出退勤システムはＰＣ上のＲＤＢソフトを用いて作られている）事が判明した。

とくに，具体的手順は記載されていないことが分かります。正規化を進めすぎて処理時間が長くかかるということを表現したいと思うのですが，問題に・・・

どのようにしてその原因を調査・分析したかを述べよ。

とあるのですから，もっと具体的手順を書くべきだと私は思います。つまり，「あっさりしすぎて」ということです。
正規化が進みすぎていることを何らかの計数的アプローチで突き止めたのでしょうか。SQLアナライザでテーブルの取得に関するコストを算出していくのが通常の方法だと思うのですが、このあたりを書いておく必要があると思います。

すなわち、タイムレコーダーから収集した出社時間、退社時間およびあらかじめ社員毎に申請・登録しておいた勤務体系の３つの情報を元に、勤務時間を算出するのだが、勤務時間帯（何時から何時までを勤務時間、もしくは休憩時間とするか、さらに何分単位で切上／切捨てを行うか）の情報を格納するテーブルと勤務体系自身の情報を格納するテーブルが１対多の関係になっているのである。従って、１件（特定社員、特定日付）の勤怠情報から勤務時間を算出するのに、対応する勤務時間帯の情報を全て抽出して一件一件から勤務時間を算出して累計してゆくという方式を取るという処理が社員・協力会社要員に一ヶ月の日数を乗じた件数分行われていたのである。

この部分の書き方はよいといましょう。調査の結果、○○であった。詳細は、以下のとおりであったという書き方自体は悪くないです。上記は、その部分として書いておけばよいでしょう。なお・・・

　ユーザーから、「月末の再計算処理が翌日の業務に支障の出ない時間（７時間以下）で終わるようにして欲しい。」との依頼を受け、私は早速現在の処理方式の問題点洗い出し、及び対策の検討を行った。
尚、対策を進めるにあたって
　・既にシステムの開発は終わり保守段階に入っている為、保守要員（私一人）のみで対応しないといけない（対応費用を別途請求する事は状況的に不可能）
　・次の再計算処理（一ヶ月後）までに対応して欲しいとの要望であったの２つの制約事項があった為、私が主担当として作業を行い、開発時のプロジェクトリーダーに週一回状況を報告し、問題等あれば指示・アドバイス等を迎ぐという方法で進めてゆくことになった。

　この段落は、保守フェーズの作業としてかかれていますが、テストフェーズしてして書くことが必要です。また

・私一人で対応・・・
・開発時のプロジェクトマネージャの見守るなか・・・

という記述は違和感があります。これも保守フェーズを土俵としているので、しっくりきていないのでしょう。というわけで、前提をテストフェーズに書き換え，再度送っていただければ見ますが，どうします？
私は，いろんな論文を見て，書き換えを行ってきましたが，この論文をそのまま採点してほしいといわれてもちょっと苦しいです。創作論文を否定しないのであれば，テストフェーズであなたが開発メンバとして対応したケースに修正できるのであれば，再評価します。この内容から修正するのは出来ない話ではないと思います。がんばってみてください。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（とりあえず，診察完了）

三連星さんのお小言２００２－１

三連星＠患者さん（劇薬注意，今回は押さえ気味）からお小言が届いています。原文とおりお届けします。

エーロン様こんばんは　三連星＠患者です。

エーロンさんの挙げた、
＞設問ア：テストで発生した性能上の問題　　において、
＞テストで発生した問題点を書いていない（問題文に従っていない）

ですが、ここは大きい問題とは見ていません。減点は減点でしょうけど。

致命傷はこちら。

＞設問ア：あなたが開発に参画したシステムの概要について

開発には参画していないのに論文に書いています。

え？　運用後、プログラムを修正したから開発のうち？？？

そういう見方もあるかもしれませんが、システム開発の当初から携わったことは無い、と判断されることには変わりありません。（当初から携わっているのがあれば、当然そっちを書く。）

経験論文なのに、経験が無いのを白状するのはマズイです。

ここは「テスト中に要件を満たさないことが明らかになった」ことにしないと。

設問イ

＞案１．．．．．
＞案２．．．．．

この書き方は一見定石どおりですが、よくみると変なところがあります。
定石は、普通に考えられる主な案を列挙し、比較の上１つづつ、つぶしていきます。
でも、そうなってはいません。

案３：データディスクとして高速ディスクを増設というのは？
　（勤務時間帯テーブルのみ他のディスクへ移動、というのもココに含める。）

案２の、修正１０日よりは安上がりと思いますが．．．．．．また、案１の

＞勤務体系や時間帯情報を登録する画面の修正も必要となる

ですが、画面修正は不要では？

というのは、既存状態でも、１人１日のデータとして、

＜＜社員番号、日付、出社時刻、退社時刻、勤務体系コード＞＞

は必要だから勤務体系コードはどこかで入力している筈です。

時間帯情報は勤務体系コードを元に参照できます。
設問ウ
＞しかしながら、では何故もともとそのように設計されて
＞いたのか？（開発段階で仕様通り動く事以外に配慮され
＞ていなかったのではないか？）

これは、書いてはならないことです。

というのは、自分の失敗でなく、他人の（＝自分の関知していない箇所の）失敗だから。

設問ウは、自分の行動に対する評価です。
＞今後の改善としては、他に設計段階で実運用の観点か
＞ら考慮漏れしている部分が無いかどうかの見直し、
＞このシステムをパッケージとして他のユーザーにも導入

これも、書く内容が違います。性能改善に関係した範囲での改善点を書きます。たとえば
　　・こうすればもっと改善できた（あるいは、同程度の改善で安く（早く）できた）
　　・更に性能改善できることは．．．．．．　　
　　・業務体制でこういうことがまずかったので今後の体制はこうするべきなど。

性能改善以外の部分の改善を書くのは本当にダメか、といわれると返答に窮しますが、私は性能改善関連のほうで書きたいですね。