論文治療クリニック

ライン

　論文治療クリニック（外来2003）
[治療FILE2003-001患者名：さんしのごい氏・・・2回目の治療]

久しぶりの外来です。前に途中で治療をやめてしまった「さんしのごい」患者さんです。では、ご本人から一言いただきましょう。

ドクターエーロン院長様

以前治療して頂いたさんしのごいと申します。
（ご無沙汰しておりました）

前回はお忙しい中、折角丁寧に指導（治療）頂いたにも関わらず、その後、本業が忙しくなってしまったのにかまけて、論文対策がおろそかになってしまい、性能改善論文の手直しすらできませんでした。大変、失礼致しました。

結局、忙しいながらもＡＥの本試験は何とか受験。午前は意地で（ＩＴＥＣの採点サービスでは）８０％取ったものの、午後Ｉで半分しか埋められず（去年のＤＢの午後Ｉで出たデータウェアハウスの問題に似ている気がしました）、午後IIは「新技術の導入について」を選択したものの、最後の結論を書いている最中に時間切れを迎えるという情けない結果に終わりました。

今年の春、ＤＢを受験してそれなりの手ごたえを感じたこともあって、今年こそＡＥ試験でも結果を出したいと思っています。

前回の治療の際、「創作論文を否定しないのであれば，テストフェーズであなたが開発メンバとして対応したケースに修正できるのであれば，再評価します。」

とのコメントを頂きましたが、ＨＰにある英伊駄目男さんの例をもとに構成を根本的に見直し、（あたりまえですが・・・）出題分から章立てを決め、骨子まで作成してから、実体験に基づいて文章をふくらませてゆくという方法を取りました（思考過程がわかるよう、途中で作成した骨子も掲載しておきました）。

従って、今度は逆に実感が伴わないものになっていないかが心配です。

また、ＩＴＥＣの通信講座を続けた効果？か、情報処理技術者試験に出てくる言葉も多用するよう心がけました。

では、よろしくお願い致します。

　はいはい。そうでしたね。初診のときは「重症で集中治療が必要」というきわめて厳しい結果（このときの診断は2002年診断その１を参照）だったですね。「創作論文を否定しないのであれば，テストフェーズであなたが開発メンバとして対応したケースに修正できるのであれば，再評価します。」なんていった覚えがありますね。

　では、自己治療の結果の論文骨子を拝見しましょうか。その前に問題文を再確認しておきましょう。

======================================================================
性能改善について

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

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

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

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

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

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

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

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

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

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

=========================================================================================
●この問題に対する論文の骨子

1-1.私が参画したシステムの概要

1-2.テストで発生した性能上の問題点

　今回のシステム開発では～という業務要件により、～という性能目標を達成する必要があった。
システム開発が進み、結合テストにおいて、本番運用と同等の機器構成により性能を計測した。
すると、要件定義時に定めた～という性能目標が達成されていないことが判明した。

2-1.発生した問題の原因及び調査・分析の方法

　要件定義において定めた～の性能目標が達成されていなかったため、私は～のツールを使用し原因の調査を行った。その結果、～ということが判明した。このことから原因は～にあることが明らかになった。

2-2.実施した性能改善、実施にあたって検討した内容

　2-1で性能上のボトルネックとなっていることが明らかになった～という事象を改善するため、いくつかの方法をメンバーとともに検討した。その結果、以下の対応策が案として挙げられた。

　案１．～
　案２．～
　案３．～

これらの案をもとに、期間、コストの面からも検討を行った結果、～という理由により、案Ｘの性能改善案を実施することにした。そして性能改善を行った後、再度テストを実施したところ、要件定義時に定めた～という性能目標を達成することができた。

3-1.実施した性能改善結果に対する私の評価
3-2.今後改善すべき点

これはこれは・・・論文患者とは思えないように綺麗な「論文構成」ですね。論文構成を書いて提出する試験だったら間違いなく合格ですね。

他の患者の皆さんに、この論文構成の美麗さが分かりますか？設問に対する要求事項に見事に答えていますね。・・・でもあくまで論文構成ですから、骨子がすばらしいということです。骨には問題がないことが分かったので、後は肉ですね。
=========================================================================================
設問に対する解答論文

設問ア

1-1.私が参画したシステムの概要

　Ｓ社は従業員約５００人、派遣社員約１０００人の都銀のシステム運用を請け負うアウトソーシングを生業とする会社である。Ｓ社では月末に勤務報告が集中し、しかも勤務体系と照合した上での記入ミスの精査、返却する作業の負荷が総務担当者に集中することが問題となっており、早急に改善すべき課題であったため、勤怠管理システムを導入することになった。
　導入にあたっては、当初は既存のパッケージ製品の活用も検討されたが、処理量が多いこと、各拠点間での助勤の実態も合わせて管理したいというニーズがあったことから、既存のパッケージをもとにリバースエンジニアリングを行い、ＰＣ用のＲＤＢＭＳを用いたレガシーアプリケーションとして新たにシステムを構築することになった。私はシステムベンダーの一員として要件定義からこのシステム開発に関わることになった。

1-2.テストで発生した性能上の問題点

　今回開発した出退勤システムにおいては、月末の再計算処理を夜間バッチとして行う機能を盛り込む事になっていた。そして、再計算処理のターンアラウンドタイムの目標値は、要件定義において、バッチ起動から翌日の業務開始までの７時間と定められていた。
　システム開発はプログラミングまで順調に進み、単体テストを終えたため、納期を１ヶ月後に控えたところで、結合テストを行うことにした。ここで、要件定義時に定めた再計算処理の性能目標が達成できているかどうか確認するため、本番運用と同等の機器構成を準備、システムを移行し、本番と同じ件数のテストデータを登録して再計算処理のターンラウンドタイムを計測した。その結果、再計算処理は１４時間を要し、要件定義時に定めた７時間という性能目標が達成できていないことが判明した。

2-1.発生した問題の原因及び調査・分析の方法

　要件定義において設定した再計算処理のターンアラウンドタイムが目標値を達成できていなかったことを受け、私はプロダクトの標準機能でデバック用のインスペクタ（プログラム１ステップずつ実行するツール）を用いて、特にＤＢアクセス処理に着目した上で再計算処理のロジックを調査した。ＤＢアクセスに注目したのは、以下の理由による。

・再計算処理の開発を担当したプログラマーは、埋め込みＳＱＬを用いたプログラミングを行うのは今回が初めてだった。
・ＤＢ設計にあたり、もとの出退勤パッケージのＥ－Ｒ図を鵜呑みし、性能要件を考慮した見直しが不足している事に思い当たった。

その結果、勤怠データ（社員、日付毎の出社時刻、退社時刻等）を格納した勤怠テーブルと、勤務体系の時間帯情報（何時から何時までが就業時間や休憩時間にあたるか）を格納した勤務体系詳細テーブルとの間で入れ子ループ型の処理が行われてることがわかった。すなわち、それぞれのテーブルの件数をｍ，ｎ件とすると、ｍｎ件分のＤＢアクセスが行われていたのである。そして、トレースツールを用いた各モジュール毎の処理時間を計測した結果、勤怠データ１件分の処理時間のうちでＤＢアクセスの占める割合が７割近くあることも明らかになった。

2-2.実施した性能改善、実施にあたって検討した内容

　デバックツールを用いた調査により、ＤＢアクセス処理の多さが性能上のボトルネックとなっていることが明らかになった。そのため、ＰＪリーダー、メンバーとともに改善策を検討した結果、以下の対応策が案として挙げられた。

　案１．勤怠テーブルの勤務体系コードをもとにした時間帯情報へのＤＢアクセスが１回で済むようＤＢ設計を変更する
　案２．同じ時間帯情報への２度目以降のアクセス時にはＤＢアクセスを伴わずに済むようメモリに格納する。

案１はいわゆる横もち構造への変更である。すなわち、勤務体系と時間帯情報との間が１対多構造となっているのを、実用上のカーディナリティ（１つの勤務体系に対応する時間帯情報の件数）が最大２０件に満たないことから、勤務体系コードをキーとし、明細にあたる時間帯情報の側を時刻１、就業区分１、時刻２、就業区分２、・・・という形で一つのテーブルに統合してしまうというものである。
それに対し、案２は案１をＤＢ設計を変更せずにメモリ上で実現するものである。すなわち、前出の１対多構造のカーディナリティが最大２０件に満たないことから、時間帯情報を一時的に格納するための２０個のエリアをメモリ上に用意し、勤怠データを一旦勤務体系コード順に並べ替えた上で再計算処理を順に行ってゆくことで、同じ勤務体系に対する２度目以降のＤＢアクセスを高速なメモリアクセスで代替するというものである。
　これらの案をもとに、期間、コストの面からも検討を行った結果、案２を採用することになった。その理由は、案１を採用するとＤＢの設計変更が発生するために問題の再計算バッチに加え、勤務体系や時間帯情報を登録する処理の業務ロジックやＤＢのバックアップ処理に変更が及ぶ。その結果、対応工数の見積もりが２０人日にもなってしまったためである。これでは、残り１ヶ月の納期を達成できない。それに対し、案２は問題の再計算バッチ側の変更のみで良く、対応工数の見積もりも５人日で済むため、残り１ヶ月の納期を守った上で実現可能と判断した。
　再計算バッチ処理を修正し、前回と同じハードウェア環境、テストデータを用いて再度性能評価を行ったところ、修正前にはターンアラウンドタイムが１４時間以上もあったのが、修正後は約１時間と性能目標を大きく上回る結果とあり、要件定義時に定めた７時間という性能目標を達成することができた。

3-1.実施した性能改善結果に対する私の評価

　今回、性能改善を行った結果、ターンアラウンドタイム約１時間と性能目標を大きく上回り、納期に影響を及ぼすこともなかったことは自身の実績として素直に評価している。また、デバックツールを用いた調査についても、ＤＢアクセス処理がボトルネックであるという原因の真相究明に至っており、結果的に満足のいくものだと考えている。メモリに時間帯情報を格納する案は、大型機を用いたシステム開発経験の豊富なＰＪリーダが検討時に言った「コントロールブレイク処理のようなことはできないか？」という発言を元に皆で考え出した案であり、コミュニケーションの大切さも改めて痛感することができた。
しかしながら、要件定義時から関わっていながら、元のパッケージのＤＢ設計を鵜呑みにし、性能要件を考慮したＤＢ設計に思いを馳せることができなかった点に関して不満が残った。

3-2.今後改善すべき点

　今後の改善事項として、今回のシステムで他にＤＢ設計上、性能要件の考慮が不足している点は無いか、もしあった場合は今回の性能改善手法が再度適用できないかについて改めて検討してゆきたい。
さらには、今回の性能改善について、社内において事例として有効活用してゆく手段を模索したいと考えている。

はい。一気に読んでみました。では、他の患者さんも一緒に、この論文はどうなのか考えて見ましょう。
（以下次回）

７月２３（水）　さんしのごいさん治療ふたたび（その②）

ドクターです。早速治療の続きです。まず、最初に問題で論述要求されている内容と解答のそれぞれタイトルのチェックを行いましょう。ちなみに論文塾での採点方式は、まず、これから行っています。まず、ドクターが考える解答の各設問のタイトルを書き出します。これは、まず問題の設問アからウを見て、番号をつけていきます。ついでに必要文字数もいれてしまいましょう。

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

設問イ
　　設問アで述べたシステムについて、「２－１どのようにしてその原因を調査・分析したか」を述べよ。
　　　　さらに対策として「２－２どのような性能改善を実施したか、（実施に当たって検討した内容とともに）」、具体的に述べよ。

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

　　　　　　　　　　　　↓

１．システムの概要とテストで発生した性能上の問題点（８００字以内必須）
　１－１　システムの概要（４００字）
　１－２　テストで発生した性能上の問題点（４００字）

２．性能課題の原因調査分析手順と実施した性能改善内容（１６００字～１８００字「具体的に」とあるので）
　２－１　性能課題の原因調査分析手順（８００字～９００字）
　２－２　実施した性能改善内容（８００字～９００字）

３．評価と今後改善したい点（４００字から６００字・・・「簡潔に」とあるので）
　３－１　評価（２００～３００字）
　３－２　今後改善したい点（２００字～３００字）
　

こんな感じですか。では、さんしのごいさんのとチェックしてみましょう。構成チェック！

　　　（さんしのごい患者のやつ）　　　　　　　　　　　　　　　　　　　　　　　　　　（ドクターのやつ）

1-1.私が参画したシステムの概要　　　　　　　　　　　　　⇔１－１　システムの概要（４００字）

1-2.テストで発生した性能上の問題点　　　　　　　　　　　⇔１－２　テストで発生した性能上の問題点（４００字）

2-1.発生した問題の原因及び調査・分析の方法　　　　　⇔２－１　性能課題の原因調査分析手順（８００字～９００字）

2-2.実施した性能改善、実施にあたって検討した内容　⇔２－２　実施した性能改善内容（８００字～９００字）

3-1.実施した性能改善結果に対する私の評価　　　　　⇔３－１　評価（２００～３００字）

3-2.今後改善すべき点　　　　　　　　　　　　　　　　　　　⇔３－２　今後改善したい点（２００字～３００字）

よいですね。一致してますね。まずはこの部分はOKです。よかったですね。ここには病巣はありませんでした。（以下次回）

７月２５（金）　さんしのごいさん治療ふたたび（その③）

ドクターです。では、次に設問アをチェックしましょう。設問アは以下の２つを書くのでしたね。

１．システムの概要とテストで発生した性能上の問題点（８００字以内必須）
　１－１　システムの概要（４００字）
　１－２　テストで発生した性能上の問題点（４００字）

では、設問アを書くときのセオリーを列記しましょう。

＜システムの概要＞
　ポイントその１・・・１－２で問われていることの布石とする。（この場合だと、性能上の問題を解決しなくてはいけないシステムだと書く）

性能改善を書くのだから、性能要件がシビアな特徴を持つシステムのほうが整合性は取れます。どうでもよいシステムを一生懸命お金をかけてチューニングするのは空しいものです。

たとえば、月１回程度しか使わないさほど重要でない報告資料を作るためのシステムは、いかにもクリティカルではありませんね。このようなシステムに一生懸命チューニングをしていると論述すると、「何やってんの？このSEは？」となって採点者に能力を疑われ、軽んじられてしまいます。

一方、いかにも重要システム（オンラインの基幹システム、利用者１０００人以上、全国オンライン）の場合は、性能要件がシビアと誰もが思います。このようなシステムのシビアな性能要件を満たすためのチューニングは当たり前の作業となるので、採点者も「そうそう。こんなシステムはチューニングしないと駄目だよねー。どんな手順でやったのか？このSEは？」ということになるのですね。そうやって、重んじられながら読んでくれるという訳。だから、システムの概要は重要なの。

では次は・・・・（以下次回）

７月２８（月）　さんしのごいさん治療ふたたび（その④）

ドクターです。続きを語るとしましょう。

ポイントその２・・・以下の内容を必ず入れよう。

・書こうとするシステムを計画、導入する企業（団体）について
　　→A社は、銀行である～、流通業であるB社では～、公官庁のC庁では～など

・どんなシステムか？導入背景は？
　　→なぜ、システム開発をしたのか。たとえば、顧客のニーズを分析したいので、顧客がどんな商品をどんなサイクルで買うのか分析できるOLAPシステムが必要だったなど

・私の立場
→AEとして書くのだから「私は、アプリケーションエンジニアとして、設計のリーダとして参加した」と書くのが無難。

なお、「私はリーダのもとで、内部設計を担当した。」と書きたい場合はどうか・・・・当然、正直に書くのは自由ですけど、採点者には当然ながら相手にされない。非常にさびしい論文となります。そもそも、AE（アプリケーションエンジニア）の試験なんだから、AEの対象とする業務の内容を一生懸命書かないと駄目なのは当たり前。

こんな感じで設問アを書けばよい。しかし、ドクターが「論文塾」で臨床実験した経験では、これができてない場合が非常に多い。どんなに治療しても治らないんだよね。

残念ながら、これができてない設問アは・・・

　　　　　　　　　　　　　　　　　　　　「設問ア心不全」（※設問アに心（魂）がこもっていない病気）

となります。設問アには魂を入れてあげよう。

では、さんしのごいさんの場合はどうか。魂が入っているのか・・・「設問ア」チェック！（以下次回）

７月３０（水）　さんしのごいさん治療ふたたび（その⑤）

ドクターです。では、設問アチェック！です。

設問ア

1-1.私が参画したシステムの概要
＜企業の概要＞
　Ｓ社は従業員約５００人、派遣社員約１０００人の都銀のシステム運用を請け負うアウトソーシングを生業とする会社である。

＜システム導入の背景＞
Ｓ社では月末に勤務報告が集中し、しかも勤務体系と照合した上での記入ミスの精査、返却する作業の負荷が総務担当者に集中することが問題となっており、早急に改善すべき課題であったため、勤怠管理システムを導入することになった。
　導入にあたっては、当初は既存のパッケージ製品の活用も検討されたが、処理量が多いこと、各拠点間での助勤の実態も合わせて管理したいというニーズがあったことから、既存のパッケージをもとにリバースエンジニアリングを行い、ＰＣ用のＲＤＢＭＳを用いたレガシーアプリケーションとして新たにシステムを構築することになった。

＜私の立場＞
私はシステムベンダーの一員として要件定義からこのシステム開発に関わることになった。

1-2.テストで発生した性能上の問題点

　今回開発した出退勤システムにおいては、月末の再計算処理を夜間バッチとして行う機能を盛り込む事になっていた。そして、再計算処理のターンアラウンドタイムの目標値は、要件定義において、バッチ起動から翌日の業務開始までの７時間と定められていた。
　システム開発はプログラミングまで順調に進み、単体テストを終えたため、納期を１ヶ月後に控えたところで、結合テストを行うことにした。ここで、要件定義時に定めた再計算処理の性能目標が達成できているかどうか確認するため、本番運用と同等の機器構成を準備、システムを移行し、本番と同じ件数のテストデータを登録して再計算処理のターンラウンドタイムを計測した。その結果、再計算処理は１４時間を要し、要件定義時に定めた７時間という性能目標が達成できていないことが判明した。

　まず、性能目標があり、テストでは目標に達していないので、さあ、大変だ。というシナリオですね。よいよい。これでよいです。非常に魂の入った設問アですね。この試験が設問アだけだったら。必ず合格しますね。では、問題の設問イはどうか？（以下次回）

８月１（金）　さんしのごいさん治療ふたたび（その⑥）

ドクターです。では、次は設問イです。設問イは以下の２つのことを要求されていいますね。

２．性能課題の原因調査分析手順と実施した性能改善内容（１６００字～１８００字「具体的に」とあるので）
　２－１　性能課題の原因調査分析手順（８００字～９００字）
　２－２　実施した性能改善内容（８００字～９００字）

では、２－１から見てみましょう。

2-1.発生した問題の原因及び調査・分析の方法

＜調査方法＞
　要件定義において設定した再計算処理のターンアラウンドタイムが目標値を達成できていなかったことを受け、私はプロダクトの標準機能でデバック用のインスペクタ（プログラム１ステップずつ実行するツール）を用いて、特にＤＢアクセス処理に着目した上で再計算処理のロジックを調査した。

＜なぜ、その調査をしたのか＞
ＤＢアクセスに注目したのは、以下の理由による。

・再計算処理の開発を担当したプログラマーは、埋め込みＳＱＬを用いたプログラミングを行うのは今回が初めてだった。
・ＤＢ設計にあたり、もとの出退勤パッケージのＥ－Ｒ図を鵜呑みし、性能要件を考慮した見直しが不足している事に思い当たった。

＜調査結果＞
その結果、勤怠データ（社員、日付毎の出社時刻、退社時刻等）を格納した勤怠テーブルと、勤務体系の時間帯情報（何時から何時までが就業時間や休憩時間にあたるか）を格納した勤務体系詳細テーブルとの間で入れ子ループ型の処理が行われてることがわかった。

＜まとめ＞
すなわち、それぞれのテーブルの件数をｍ，ｎ件とすると、ｍｎ件分のＤＢアクセスが行われていたのである。そして、トレースツールを用いた各モジュール毎の処理時間を計測した結果、勤怠データ１件分の処理時間のうちでＤＢアクセスの占める割合が７割近くあることも明らかになった。

はいはい。調査方法とその理由、調査結果、まとめが入っていて心地よい美麗な語り口ですね。これはよいよいここまでは完璧ですね。（以下次回）

８月４（月）　さんしのごいさん治療ふたたび（その⑦）

ドクターです。２－１はよくかけていますね。次は設問イの２－２です。「実施した性能改善」ですね。では、見てみましょう。

2-2.実施した性能改善、実施にあたって検討した内容

　デバックツールを用いた調査により、ＤＢアクセス処理の多さが性能上のボトルネックとなっていることが明らかになった。そのため、ＰＪリーダー、メンバーとともに改善策を検討した結果、以下の対応策が案として挙げられた。

（ドクターチェック！）

「ＰＪリーダー」→素直に「プロジェクトリーダ」と書いておくほうが無難。別に問題ないとは思うのですが、一応略語は禁止と言われています。もし、書くならプロジェクトリーダ（以下、PJリーダ）くらいに書いておくとOK。

　案１．勤怠テーブルの勤務体系コードをもとにした時間帯情報へのＤＢアクセスが１回で済むようＤＢ設計を変更する
　案２．同じ時間帯情報への２度目以降のアクセス時にはＤＢアクセスを伴わずに済むようメモリに格納する。

案１はいわゆる横もち構造への変更である。すなわち、勤務体系と時間帯情報との間が１対多構造となっているのを、実用上のカーディナリティ（１つの勤務体系に対応する時間帯情報の件数）が最大２０件に満たないことから、勤務体系コードをキーとし、明細にあたる時間帯情報の側を時刻１、就業区分１、時刻２、就業区分２、・・・という形で一つのテーブルに統合してしまうというものである。

（ドクターチェック！）

？？？・・・いわゆる横もち構造？・・・わかんないです。万人に分からなきゃだめです。テキストででてこない言葉はわかんないですよ・・・これは一般的なことばです？辞書にでてますか？情報処理用語辞典（日経BP）にでてますか？少なくともシステムアナリスト、システム監査技術者、アプリケーションエンジニア、2級ファイナンシャルプランニング技能士のドクターは知りません。
それと、いろいろDBのエンティティの説明が書いてあるのですが、良く分かりません。書いているほうは当然分かると思うのですが、はじめて論文を読む人間には、エンティティの詳細を説明するのは無理があるかもしれません。ここにきて、少し治療が必要な病巣がでてきたかも知れませんね（以下次回）

８月６（水）　さんしのごいさん治療ふたたび（その⑧）
ドクターです。よく読み返しました。横もち構造とは繰り返し属性を持つテーブルのことですね。つまり、非正規化するということですね。だったら、テーブル情報は冗長になるが、非正規化したと書いたほうが分かりやすいですね。

案１は、非正規化して、JOINをなくしましたという案。JOINは時間がかかりますので、チューニングするときにはまず検討する方法ですね。また、案２は、バッファサイズの調整の話ですね。これもチューニングの際には検討すべき項目ですね。

結局、案２にしたということですね。その理由は・・・・

　これらの案をもとに、期間、コストの面からも検討を行った結果、案２を採用することになった。

その理由は、案１を採用するとＤＢの設計変更が発生するために問題の再計算バッチに加え、勤務体系や時間帯情報を登録する処理の業務ロジックやＤＢのバックアップ処理に変更が及ぶ。その結果、対応工数の見積もりが２０人日にもなってしまったためである。これでは、残り１ヶ月の納期を達成できない。

それに対し、案２は問題の再計算バッチ側の変更のみで良く、対応工数の見積もりも５人日で済むため、残り１ヶ月の納期を守った上で実現可能と判断した。
　再計算バッチ処理を修正し、前回と同じハードウェア環境、テストデータを用いて再度性能評価を行ったところ、修正前にはターンアラウンドタイムが１４時間以上もあったのが、修正後は約１時間と性能目標を大きく上回る結果とあり、要件定義時に定めた７時間という性能目標を達成することができた。

（ドクターチェック！）

はいはい。非常に説得力のある理由だと思います。一時はどうなるかと心配しましたが、非常に踏ん張った論文ですね。好感が持てます。今回の場合、よく読めば理解できるのですが、採点者は非常に早いスピードで論文を読んでいますから、途中で止まってしまうような難しい記述は止めるほうがよいでしょう。簡単に書けばよいのです。なお、最後に「再度テストして問題ないレベルに到達した」という記述がありますが、これは非常にGOODです。こういう記述があると、「よい仕事をしているなあ」と採点者に誉められます。本当に。

でも、ここまでは非常によくかけていると思います。では、最後は設問ウです（以下次回）

８月８（金）　さんしのごいさん治療ふたたび（その⑨
ドクターです。では、最後の設問ウを見てみましょう。設問ウには以下を書くのでしたね。

３．評価と今後改善したい点（４００字から６００字・・・「簡潔に」とあるので）
　３－１　評価（２００～３００字）
　３－２　今後改善したい点（２００字～３００字）

では、さんしのごい患者の論述をじっくり拝見。

3-1.実施した性能改善結果に対する私の評価

　今回、性能改善を行った結果、ターンアラウンドタイム約１時間と性能目標を大きく上回り、納期に影響を及ぼすこともなかったことは自身の実績として素直に評価している。また、デバックツールを用いた調査についても、ＤＢアクセス処理がボトルネックであるという原因の真相究明に至っており、結果的に満足のいくものだと考えている。

（ドクターチェック）：まず、冷静に自己評価しているところは好感もてますね。よいことはよかったと素直に言えることが大事ですね。

メモリに時間帯情報を格納する案は、

（ドクターチェック）：「メモリに時間帯情報を格納する案」？？？？？日本語はいまいちですね。気持ちは分かるけど。ここは、「バッファを利用した案」と言ったほうが普通ですね。

大型機を用いたシステム開発経験の豊富なＰＪリーダが検討時に言った「コントロールブレイク処理のようなことはできないか？」という発言を元に皆で考え出した案であり、コミュニケーションの大切さも改めて痛感することができた。

（ドクターチェック）：「コントロールブレイク処理のようなことはできないか？」？？？？？？これも意味よく分かりませんね。余計な記述です。採点者は絶対わからないよー（以下次回）

８月１１日（月）　さんしのごいさん治療ふたたび（その⑩）
気を取り直していきましょう。コントロールブレイクの処理のような～は禁句です。このヒントを与えてくれた上司の方はすばらしいと思うし、それでひらめいた「さんしのごい」さんもすばらしいと私は思います。
しかし、論文にこういう情緒的な表現は不要でしょう。当然、あっても不合格にならないと思います。この論文は合格レベルにありますので、設問ウで何を書こうが、問題ないのです。が、一応作法として禁じておきます。
コミニュケーションのよさは必要なのですが、ここでの論点では不要な記述ですね。（以下次回）

８月１３日（水）　さんしのごいさん治療ふたたび（その⑪）
では、最後の文章を見ていきましょう。

しかしながら、要件定義時から関わっていながら、元のパッケージのＤＢ設計を鵜呑みにし、性能要件を考慮したＤＢ設計に思いを馳せることができなかった点に関して不満が残った。

（ドクターチェック！）性能要件を考慮したDB設計に思いを馳せる→当初から性能要件を考慮できなかった点に関して不満が・・・
思いを馳せるは論文表現としては違和感があります。大きな減点になるとは思いませんが、上記のように表現しておくほうが無難でしょう。
でも、反省を書いておくのはよいことです。失敗から学んでいく真摯な態度に好感が持てます。

3-2.今後改善すべき点

　今後の改善事項として、今回のシステムで他にＤＢ設計上、性能要件の考慮が不足している点は無いか、もしあった場合は今回の性能改善手法が再度適用できないかについて改めて検討してゆきたい。
さらには、今回の性能改善について、社内において事例として有効活用してゆく手段を模索したいと考えている。

（ドクターチェック！）この最後の振り返りは見事です。非常に後味のよい論文としてまとまりましたね。次回に全体の評価をするつもりですが、総論的にはよい解答論文と思います。合格レベルと言いきれるでしょう。よくもまあ、あの状態（昨年の手遅れ論文）から立ち直りましたね。奇跡の生還というところでしょうか。でも、しっかり学習すればこうなるんですね。だから、治療が必要なのです。治療が上手くいった好例ですね。（以下次回）

８月１５日（金）　さんしのごいさん治療ふたたび（その⑫）
今日は、さんしのごいさんがきてくれました。少し問診。

ドクター：
ごいさん、論文病は完治ですか？

ごいさん：
１度ならず２度までも丁寧な見立てを有難うございました。

ドクター：
いえいえ。ところで、今回の論文で注意したことは？

ごいさん：
今回の論文は、設問から骨子まで作成しておき、それに経験をもとに肉付けしてゆく方法を採りました。少なくとも方針は間違っていなかったようで、安心しました。ところで、今回の治療でチェックして頂いた用語について少し補足させてください。

ドクター：
はい。どうぞ。

ごいさん：
「横もち構造」の出典ですが、ＩＴＥＣ社の「データベーススペシャリストのためのデータベース技術」（第４版）で非正規化の方法の説明にあったものを使用しました。と言っても、あくまでも説明の中の表現であってＩＴ用語として書かれていたわけではありません。ご指摘頂いた通り、素直に掲載箇所のテーマである「非正規化」を採用した方が無難だったと思います。「コントロールブレイク」ですが、汎用機で順ファイルに書かれた明細から特定項目毎に集計（ＳＱＬで言うＧＲＯＵＰ　ＢＹ）するのを、プログラムで実現するため、キー項目が変わるまで加算を続け、キーが切り替わったタイミングでそれまで加算した内容をレコード出力し、切り替わったキーで再度０から加算を開始するというものです。今回のチューニングでは、勤務体系（１側のキー）が切り替わった時点でそれまでメモリに展開していた勤務体系詳細テーブル（多側）のメモリ上の値を入れ替えるという方式をとりました。

ドクター：そういうことですか、小伝馬町情報処理試験専門教育機関からでた言葉でしたか・・・（以下次回）

８月２５日（月）　さんしのごいさん治療ふたたび（その⑬）
ドクターです。夏期休暇も終わり、８月も残すところ１週間になりました。そろそろ、論文塾のセミナーの季節です。先週は大阪でAEコースがありました。受講患者さんは少なかったのですが、その分、非常に手厚い講義を行うことできました。
結果的に、「はじめて論文を書きます」という患者さんが、２６００字を書かれて、内容もGOOD。合格レベル論文を書けるようになりました。Dｒの公開治療もほぼ、完成したということでしょうか？大阪論文塾受講生の皆様、お疲れ様でした。

さて、今回で、さんしのごいさんの見立ても完了です。今日は、総合評価ですね。

AE論文のカルテ
患者名「さんしのごい」
総合評価・・・・A（合格論文のレベルにある）

内容	見立て
設問要求に対応した解答論述か	A 非常によい
題意、主旨を理解しているか	A 非常によい
主張に説得力があるか	A 非常によい
論旨構成が正しいか	A 非常によい
文章にリズムがあるか	A 非常によい

論文病の治癒はかなり進んだようです。ドクターもほっとしています。１０月の本試験でもかなりよいものを書ける力がついていますのでこのまま、治療を続けていけば問題ないと思います。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　2003/8/25　さんしのごいさんの治療完了