論文治療クリニック

ライン

　論文治療クリニック（外来2003）
[治療FILE2003-003患者名：まんな氏・・・初診]

まんな氏という患者が治療に見えました。では、どんな患者なのか診てみましょう。

こんにちは、エーロン先生。

まんなです。僕は、文章の書き方も得意でない方なので、かなり重症かも知れませんが、よろしくお願いします。

略歴：入社6年目のシステムエンジニア
　　　　ＡＥ試験は、初受験です。　（昨年ＡＥ試験は申し込んだが、勉強しなかった為受験せず）

典型的な患者さんですね。入社６年目で文章が苦手、ＳＥとしてよく見受けられるタイプですね。では、早速診て見ましょう。問題から

性能改善について

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

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

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

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

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

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

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

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

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

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

では、つぎに論文を診ましょう。

１　システムの概要とテストで発生した性能上の問題
１．１システムの概要
　私は、A社に勤務するシステムエンジニアである。今回B社のカードシステムを構築に携わった。B社は３００万人ほどの顧客を持つ中堅カード会社である、既存のシステムがホスト系のシステムで古く、再利用等を高める為、今回クライアント・サーバ型のオープン系システムに移管することになった。このシステムは、カード会員の顧客の入会・会員の属性情報・請求処理、またカードの支払いがあった後の入金処理、更には入金しない会員の延滞情報までも管理する巨大システムである。システム的には、会員の明細情報などを表示する画面オンライン機能と、一度に入金処理などをする夜間バッチ処理とに分かれる。その中でも月に一度の入金処理と、その後引き続き行われる延滞確定処理は大量のデータのDB反映、帳票作成をする処理がある。これを夜間に行い、日中のオンライン処理に影響が出ないようにする必要があった。私はこの入金・延滞確定の開発チームのリーダとして参加した。
１．２テストで発生した性能上の問題
　結合テストのフェーズで、性能上の問題が発生した。夜間処理として入金延滞の処理を行わなければならず、入金処理は3時間以内に終わらなければならなかった。３００万件のデータ処理をするので、1件あたりに使用できる時間は０．４秒である。しかしながら、1件あたり8秒もかかっているという現状であった。入金処理は、かなり複雑で５０以上のクラスを使っており、アクセスDBも２０テーブルアクセスしているものであった。

２　原因の調査・分析と対応案と検討内容
２．１原因の調査・分析
　今回Javaを用いてオブジェクト指向開発による開発をしたが、ほどんとのメンバーがオブジェクト指向開発は始めてであった。又このシステムは大規模であるため、たくさんのクラスを深層に渡って呼んでいる複雑なものであった。よって性能改善するためには、原因と調査を明確にすることが重要であると考えた。よって、私はソフトウエア開発技術者と共同でトレースツールを用いて、どこで処理がかかっているかを調査した。するとトレース結果は以下のようになった。
①DBアクセス約４５％
②DBアクセスのデータ取得約４０％
③データの加工・編集約１５％
大規模な機能であるため、無駄なDBアクセス・データ取得はあるとは思っていたが、この２項目に関して、ほとんどの時間を費やしているとは、驚きであった。又、トレースツールで順に追っていくと、同一機能で同じデータを別の所で呼んでいるとこが見うけられた。これは同一機能内でも一機能が大きいため複数の担当者が設計しており、重複したデータの取得となってしまっていた。
２．２　対策案と検討内容
（１）DBアクセスの減少
トレースの結果でDBアクセスが処理時間の４５%も占めていた。この入金処理は２０テーブルほどのアクセスがあり、１テーブル１クラスで実装されており、それぞれサーバからDBサーバに1クラスずつのアクセス、つまり２０回DBサーバにアクセスする仕組みになっていた。この２０回のDBアクセスを減らすことが性能改善につながるので、その対策を考えた。幸いにも、このDBアクセスは、１つの同じクラスから呼ばれている為、対応が取りやすかった。この解決策として、共通クラスをストアドプロシージャ化する対策を取った。これにより２０回だったDBアクセスが1回になり、処理時間も０．８秒まで減少した。
（２）DBアクセス後のデータ取得量の削減
　トレース結果で次に処理時間がかかっていたのが、DBアクセス後のデータ取得のところであった。この処理時間はデータ量に比例するので、取得データ量を減らすことが必要であった。無駄なデータ取得している箇所は2箇所あった。
① ２０テーブルアクセスする共通クラスを同じ入金処理内の機能内で2回呼んでいる
② 共通クラス内で取得するレコードは、必要な項目を持つテーブルはレコード全項目を取得しているため、入金処理で参照・更新等使用しない項目まで取得している。
② に関しては、どの項目を使用しているかの調査が必要であり、この大規模な機能で調査するのは、たくさんの工数がかかり、納期まで2ヶ月という段階では厳しい。また処理時間的にも①は、データ量を半分にするため、処理時間も半分になるという見込みより、①を達成すれば合計時間が０．４秒で０．５秒以内という目標を達成できるため、コストと工数を考えて②は実施しないことにした。①はクラス間で取得したデータの参照を引数で渡していくことにより実現できた（データの参照を渡すため、パフォーマンスは低下しない）

３　評価と効果的な方法
３．１評価
　この性能改善では２．１の①で共通クラス内の変更である点、２．１の②では、たくさんのクラスを修正しなくてよい、比較的簡単なクラスであった為、期間内に修正でき、又納期まで2ヶ月という段階で性能改善以外の妥当性確認について、結合テストを平行して進められ、無事納期までに完了することができた。トレース・ツールによる調査・確認・対策案・検討は、このような大規模な機能の追跡には、非常に有効である。有効であるというより無くてはならないものであった。
３．２効果的な方法
　上記のように今回は、結合テストの妥当性の確認とある程度平行して進められたが、性能改善すべき場所ややり方によっては、結合テストを一度止めて行わなければいけない場合もあるであろう。よって、結合テスト以前に、重要な問題点は認識をもって取り組まなければならない。無駄なサーバへのアクセス、重複ロジック等については、設計段階で考慮されているべき事項で、アプリケーション・エンジニアとして設計者に周知・徹底させる必要がある。しかしそうは言っても、目標レスポンスには、結合テスト前に、なかなか到達のできないものである。よって、トレースツール等で原因・究明し、納期・コストを考えて重要なものから対応して行わなければならない。

この論文も診立てを募集します。clinic@a-ron.netにメールで送付ください。（以下次回）

１０月６日（月）まんな氏の治療②・・・論文治療医師　「資格本舗」先生の診断
ドクターです。まんな氏の診断には、ちょっと工夫を凝らしまして、ゲストの先生お二方に登場して頂き、診立てを行っていただくことにしました。

　今回登場いただく先生は著書もたくさんあるメジャーな先生なのですが、ご本人の希望により、ハンドルネームでの診立てになります。では、「資格本舗」先生、お願いします。

資格本舗と言います。エーロン先生に頼まれてきました。これから生意気なことをたっぷりと言いますが、実はＡＥ無免許医です。無免許のくせに偉そうなこと言うな！　と言われそうですが、耳を傾ける傾けないはご自身の自由です。

＜ドクター注：先生は、もっと難易度の高い免許を複数保有されています。念のため＞

　さて、本題に入りますが、論文を拝読しました。総論として「ツボは押さえている論文だな」と感じました。ただしこのままでは合格は難しいです。悪いところを中心に僕の意見を述べます。なお、（　）内は論文の章に相当します。

①　数字にもっと気を配ってください。
　数字が滅茶苦茶だと、すべてぶち壊しになります。

> 1件あたりに使用できる時間は０．４秒である。（１．２）

　僕の計算によれば、０．００３６秒／件になります。対象となるデータは３００万件ではなく３万件ではないでしょうか？

> を達成すれば合計時間が０．４秒で０．５秒以内という目標を達成できるため（２．２）

　え？　目標は０．４秒／件でなかったの？　設問アで書かれていることと辻褄が合っていません。

　それと「巨大システム」とか「たくさんの工数」という記述が散見され、気になります。具体的な数字がないためです。一方で、前述のとおり具体的な数字を出せば出したで辻褄が合わないという状況では「この論文はでっちあげだ」と簡単に見抜かれてしまいます。でっちあげは大いに結構ですが、見抜かれない程度のでっちあげにしないといけません。

②　もう少し文字数を稼いでください。
　換算したら、約２８００字程度でした。本番の試験だったら２８００字あれば、十分に合格圏内です。しかし練習で２８００字しか書けないと、本番の試験では規定の文字数をショートするおそれがあります。
　どうして文字数が不足気味なのか？　理由のひとつとして、「書くべきことが書かれていないため」があげられます。問題文では性能改善の施策として、チューニング、設計レベルの見直し、リソースの追加と３点が例示されています。しかしこの論文ではチューニングのことしか触れられていません。出題者からすると「え？　性能改善で工夫したと言いながら、チューニングだけしか努力していないの？」という気持ちにもなります。
　全部言及しろとは言いませんが、設計レベルの見直しかリソースの追加か、せめてどちらか一方について施策を述べないと、工夫が伝わってきません。

③　誤字を減らしてください。
　これは本人も苦手と認識しているようなので、あまり問い詰めたくもありませんが。僕が気がついた誤字だけでも次のようなものがあります。
・　始めて　→　初めて
・　とこ　→　ところ
・　痴当者　→　担当者
・　平行　→　並行
　その他にも誤字ではありませんが、国語としておかしなところもあるようです。せめて誤字は削減するよう努めましょう。そのためには練習で、一字一句について「本当にこの漢字で正しいのか？」と気にかけてみることも大切かもしれません。

　また、各論として、次の点も指摘します。

　設問アで「私は、Ａ社に勤務するシステムエンジニアである」と冒頭で言っておきながら、その後、Ａ社のＡの字も出てきません。だったらこの一文はなんのためにあるのかな、と考えてしまいます。もう少しＡ社の正体を明かしてもいいのではありませんか。どんな会社なのか？　Ｂ社との関係は？　とか。

> この２項目に関して、ほとんどの時間を費やしているとは、驚きであった。（２．１）

　そんなに驚きでしょうか？　ＤＢのＩＯに時間がかかるというのはごく当たり前と感じます。こんなことで驚いていては経験を疑われてしまいます。ここは「費やしていることが明らかになった」程度にしておきましょう。

資格本舗先生、お忙しいところ、本当にありがとうございました。論理的で鋭い指摘は先生の特徴ですね。私の感情的で抽象的な指摘とは異なる切れ味を感じました。まんなさん、指摘に関する感想があれば、お願いします。（以下次回）

１０月１１（土）まんな氏の治療③・・・治療中患者「さんしのごいさんの診立て」

ドクターです。もう一人のプロ論文治療医師の診立ての前に、治療中患者であるごいさんの診立てがきましたので見てみましょう

ドクターエーロン院長様

まんなさんの論文の診立てを行ってみました。
まんなさん、はじめまして。患者のさんしのごいと申します。本試験まで残り少なくなってきましたが、共に頑張っていきましょう。

（以下、診立て）
==================================================
１．大筋はずれていない

設問に対し、大筋ではずれていないと思いました。（少なくとも、去年私が書いた保守フェーズでのチューニングほどではないと思います。）

２．設問アの字数が不足気味

　エディタにコピーして２５文字で改行してみたところ、28行、つまり原稿用紙の下４行が空く計算になります。もう少しふくらませる必要があると思います。

３．口語体、情緒的な表現

　全体的に口語体に近い表現が多い気がします。

例）
　今回Javaを用いてオブジェクト指向開発による開発をしたが、=>今回行ったJavaを用いたオブジェクト指向の開発では、

　同一機能で同じデータを別の所で呼んでいるとこが見うけられた。=>同一機能内において、同じデータを重複して呼んでいる箇所が見つかった。

　ＤＢアクセス後のデータ取得のところであった。=>ＤＢアクセス後のデータ取得部分であった。

また、「驚きであった」、「幸いにも」は情緒的な表現で、論文にはふさわしくないと思います。
（ちなみに、かく言う私も「思いを馳せる」という表現を使ってしまい、ドクターチェックを受けた事がありましたが・・・）

４．解決策がわかりません

ＤＢアクセス回数削減の手段で共通クラスをストアドプロシージャ化する対策を取った。

とありますが、以下の理解に照らし合わせてみても、意味がわかりませんでした。

クラス：データとデータに対する手続きをカプセル化したもの。
共通クラス：クラスのうち、複数のクラスの継承元となるもの。
ストアドプロシージャー：ＳＱＬをコンパイルしてＤＢＭＳ側に登録しておき、名前だけで呼び出せるようにしたもの。

また、その解決策を採用した理由も書かれていません。書くべきです。さらに、この解決策は問題文中に列挙された、どの解決策にあたるのかも不明です。（プログラム構造の見直し、ということでしょうか？）

５．誤字、表記のゆれ

　　始めて => 初めて
　　平行 => 並行

また、トレースツールが３．１ではトレース・ツールになってしまっています。

６．長すぎる文がある

　この性能改善では２．１の①で共通クラス内の変更である点、２．１の②では、たくさんのクラスを修正しなくてよい、比較的簡単なクラスであった為、期間内に修正でき、又納期まで2ヶ月という段階で性能改善以外の妥当性確認について、結合テストを平行して進められ、無事納期までに完了することができた。

読んでいて疲れます。途中で切った方が歯切れも良く、読みやすくなると思います。

７．３．１が評価になっていない

結果と感想になってしまっています。

８．３．２の表題が設問と合っていない

３．２は「今後改善したい点」を書く場所であり、「効果的な方法」とは違うと思います。また、書いている内容も今後改善したい点とは違うと思います。

９．句読点

３で・がやたらと使われていますが、句読点（、）にすべきです。

以上です。
色々書きましたが、大筋はずれていないので、表現を見直せば治療は可能だと思います。

ごいさん、ありがとうございました。ごいさんも治療の甲斐あってかなり大人っぽい指摘ができるようになりましたね。本試験が楽しみです。まんなさん、いかがでしょうか。感想をぜひください。（以下次回）

１０月１２日（日）まんな氏の治療④・・・論文治療医師　「克元亮」先生の診断
ドクターです。さて、今回のまんなさんの診断はお待ちかねゲスト2人目の先生、克元亮先生の登場です。
克元先生はご存知の通り、論文対策サイトを運営されていらっしゃいます。先生はサイトだけでなく、本もたくさんかかれています。
日経ＢＰの３週間マスタ・情報セキュリティは先生とドクターの共著（他の著者も参加されていますが）です。
そうそう、ある団体主催のパネルディスカッションでご一緒したこともありました。

では、御紹介はこのあたりにして、早速プロの論文治療医師の診立てをみせていただきましょう。診立てスタート！

克元です。
まんなさんの論文、私の得意なＤＢ分野ということもあり、診立てをやってみました。大規模システムでオブジェクト指向開発をした事例、ということで興味深く読ませていただきました。

題意は、性能目標値を達成できていない場合に、原因調査の方法、改善方法の立案と評価、選択した改善方法の効果と残件です。
問題文の中に、ヒントになるシナリオとキーワードがあり、これを活用して具体性をもたせて記述すればよいと思います。

さて、まんなさんの論文ですが、目標設定として３時間以内で、３００万件の入金バッチ処理（０．４秒／件）。
→　計算があわないのですが。０．００４秒／件（正確には0.0036）では？　
つまりサーバスループットとして、１秒あたり２７８件の処理能力（俗に２７８ＴＰＳという）が必要でしょう。
ここは対策効果や評価とつながるわけで計算ミスに注意したいところです。

２．１．原因の調査と分析
オブジェクト指向開発で、「たくさんの・・・複雑・・・」とあり、ＡＰ構造が悪いと決めてかかっているかな、と感じます。
確かに、一般的には、オブジェクト指向の初心者が開発して、非効率な処理にしてしまうことがよくあります。ここは採点者も「おっほらきた」とうなずく
場面でしょう。ただ、結合テストでＡＰに手を入れるのは品質低下のリスクがあり、慎重に判断したいものです。

論文で記述しているように、どの処理にどの程度時間がかかっているのかを調査する、というアプローチはとても良いと思います。しかし、題意からは、チューニング、設計レベルの見直し、リソースの追加と３つの視点があげられており、機能ごとのトレースだけではなく、サーバ負荷やＤＢバッファの
使用率等まで範囲として分析すべきでしょう。

例えば、パフォーマンスモニタを使えば、サーバー負荷状況やＤＢ内部バッファの使用率などもとれるはずです。題意に沿って、３つの視点で対策を検討し、かかる期間・コスト（工数・機器費用）を評価した上で、現実的な対応策を選択するストーリーの方がより合格レベルといえるでしょう。

対策の優先付けをいかに行い、残された期間と予算でいかに対応したのか、「ＡＥとしての振る舞い」が問われているテーマのはずです。

２．２．対応策と検討内容
（１）ＤＢアクセスの減少　→　「ＤＢアクセス要求の減少」、つまり、ＳＱＬ発行コストが課題であると読み替えました。

ここでは、以下の技術的な面で疑問を感じました。

１クラス／１テーブルの構造だったために、２０テーブルをアクセスするのに２０のクラスを呼び出していたということですね。

これをストアドにしたからといって、アクセス対象のテーブル数が減るわけではないでしょう。つまり、ＳＱＬの発行→サーバでのＳＱＬ解析→テーブル
アクセスという処理で、ストアド化によってＳＱＬの発行とサーバでのＳＱＬ解析負荷は減るものの、テーブルアクセス自体は変わらないのではないか？

もしかしたら２０テーブルジョインという恐ろしいテーブル構造になっているのではないか、テーブル構造の見直しが必要なのでは、と思いました。
・・というような疑念がわいてきますので、ＤＢ構造の前提を記述しておくとよいのかもしれませんね。

（２）ＤＢアクセス後のデータ取得量の削減
２回を１回にする。項目チョイスはしない。というのは理解しました。ただ、（１）と合わせて、目標時間に対して、結局はどうだったのか（0.5？）。
また、そのための工数や期間が記述されていないので、釈然としません。

以上、細かい部分での指摘をしてきましたが、以下に総括評価をします。

■題意に沿っているか　：　△
　ＡＰ見直しに絞りすぎている。コスト・期間の評価が定量的でない。
■論理は一貫しているか：　△
　数字にミスあり、評価までつながらない。
■表現はわかりやすいか：　×
・根拠不明な箇所があり、すぐには理解しにくい。
「入金処理は、かなり複雑で５０以上のクラス」　なぜ複雑なのか？
「機能内で２回呼んでいる」なぜ２回呼んでいたのか？
・情緒的な表現が多い
「巨大システム」「かなり複雑で」「たくさんのクラス」「たくさんの工数」等々、主観的。

以上、診立ててみましたが、いかがでしょうか、エーロン先生。

先生、ありがとうございました。この試験前の忙しい時期に、資格本舗先生、克元先生ドクターの無理なお願いに嫌な顔せずありがとうございました。ごいさんも自分のことで精一杯な時期にありがとうございました。
　では、次回は、まんなさんの感想を御紹介することにし、その次回にドクターの診立てをお送りすることにしましょう。

ちなみに、明日、明後日は論文塾直前アドバイス会があります。面白いことがあれば、また御紹介したいです（以下次回）

１０月１３日（月）まんな氏の治療⑤・・・まんな患者の感想
ドクターです。まんなさんの感想が届きました。2つあります。では、どうぞ。

＜資格本舗先生、ごいさんへのお礼メッセージ＞

エーロン先生。こんにちは、まんなです。

診断ありがとうございます。自分の書いた論文をはじめてチェックしてもらったり、公開診断だったので、かなり緊張しましたが大変参考になりました。
エーロン先生、資格本舗先生、さんしのごいさんわざわざチェックいただきありがとうございます。

（ドクター注：ドクターははまだ診立てをお伝えしていませんが・・・）

それぞれののご指摘もさほど差がなく、各項目に関して納得できるご指摘で修正しなければいけないなぁと感じています。さんしのごいさんも試験受けられるのですね、共に頑張りましょう。試験まで残りわずかですが、最後まで頑張りたいと思います。

＜克元先生へのお礼メッセージ＞

こんにちは、エーロン先生。まんなです。

克元亮先生もご指導ありがとうございました。克元亮先生は、DB分野が得意ということで、ずいぶん論理の矛盾をご指摘いただきました。

直前のお忙しいことろ、無理なお願いしてご指導いただき大変感謝しております。お三方のご指摘により、さらに論文を修正して、成熟させたいと思います。そして本番にも生かせるように、あと１週間頑張ります。試験まで残りわずかですが、最後まであきらめず頑張ります。

今回は、本当に豪華な診立て企画でしたね。診立てをノーギャラで行っていただいたお二人の先生、友情出演ありがとうございました。ごいさんもありがとうございました。もう、残すところわずか。試験一週間前ですね。まんなさんは是非論文病を完治させ、合格連絡を行えるようにがんばってください。（以下次回）

１０月１４（火）まんな氏の治療⑥・・・ファイナルチェック！ドクターの診立て
ドクターです。論文塾の個別論文コンサルも終了しました。ＡＥコースはほぼ全員が合格レベルに達しました。あとは、試験で実力を出せるかですね。塾生の皆さん、がんばってください。
　さて、クリニックの方もそろそろ治療追い込みです。最後にドクターの診立てを行いましょう。でも、ほとんどは２名のゲスト先生とごいさんに指摘いただいたので、ドクターの指摘することはあまりないと思います。では、ファイナルチェックスタート！

まず、題意整合性です。題意整合性は、問題をどれだけ理解しているか、設問にどれだけ正しく対応しているかを診ます。では、設問の確認です。

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

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

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

　　　　　　　　　　　　↓

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

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

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

ごいさんの2つ目のときと同じですね。では、まんなさんのものを診てみましょう。構成チェック！

　　　（まんな患者のもの）　　　　　　　　　　　　　　　　　　　　　　　　　　（ドクターのもの）

1-1.システムの概要　　　　　　　　　　　　　⇔１－１　システムの概要（４００字）

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

2-1.原因調査・分析　　　　　　　　　　　　　⇔２－１　性能課題の原因調査分析手順（８００字～９００字）

2-2.対策案と検討内容　　　　　　　　　　　⇔２－２　実施した性能改善内容（８００字～９００字）

3-1.評価　　　　　　　　　　　　　　　　　　　　⇔３－１　評価（２００～３００字）

3-2.効果的な方法　　　　　　　　　　　　　　⇔３－２　今後改善したい点（２００字～３００字）

3-2は「効果的な方法」となっていますね・・・？細かいですが、今後改善したい（するべき）点に対して、効果的な方法のタイトルはどうかと・・・細かいので、別に減点はないと思いますが、気持ち悪いので、問題の言葉と一致させておいた方が無難ですね。それ以外は、一致していますね。では、それぞれの中身で書いてあることが的外れでないかチェックしてみましょう。

ピー！（注：ホイッスルの音）
　再利用等を高める為、クラサバに移管する？
移管とは、管理を移すということですね。表現が曖昧ですね。オープン系システムに組み替えるもしくは、再構築するという意味でしょうか？そうなら、そうかいてください。また、クラサバに組み替える理由が、舌足らずですね。「再利用等を高める為」は意味不明です。（意味はなんとなく分かるのですが・・・）ホストシステムが古いと何が問題でしょうか？クラサバに組み替えるのは何を目的とするのでしょうか？具体的に誰にも分かるように書いてください。

このシステムは、カード会員の顧客の入会・会員の属性情報・請求処理、またカードの支払いがあった後の入金処理、更には入金しない会員の延滞情報までも管理する巨大システムである。システム的には、会員の明細情報などを表示する画面オンライン機能と、一度に入金処理などをする夜間バッチ処理とに分かれる。その中でも月に一度の入金処理と、その後引き続き行われる延滞確定処理は大量のデータのDB反映、帳票作成をする処理がある。これを夜間に行い、日中のオンライン処理に影響が出ないようにする必要があった。私はこの入金・延滞確定の開発チームのリーダとして参加した。

ピー！　巨大システムという表現は不適切です。本当に書きたいなら、規模を表現する数字を入れましょう。たとえば、「ステップ数は1000万程度で、大規模に属するシステムである」などを書くとよいでしょう。1000万くらいあると大きいと思いますね。

１．２テストで発生した性能上の問題
　結合テストのフェーズで、性能上の問題が発生した。夜間処理として入金延滞の処理を行わなければならず、入金処理は3時間以内に終わらなければならなかった。３００万件のデータ処理をするので、1件あたりに使用できる時間は０．４秒である。しかしながら、1件あたり8秒もかかっているという現状であった。入金処理は、かなり複雑で５０以上のクラスを使っており、アクセスDBも２０テーブルアクセスしているものであった。

計算違いは皆さんのご指摘の通り。あと疑問なんですが、結合テストで性能上の問題が分かるのかな？１件あたりの処理時間×件数とすれば机上計算できるとは思うのですが、１件の処理時間見ただけで全体性能が測れるのか・・・疑問ですね。

２　原因の調査・分析と対応案と検討内容
２．１原因の調査・分析
　今回Javaを用いてオブジェクト指向開発による開発をしたが、ほどんとのメンバーがオブジェクト指向開発は始めてであった。又このシステムは大規模であるため、たくさんのクラスを深層に渡って呼んでいる複雑なものであった。よって性能改善するためには、原因と調査を明確にすることが重要であると考えた。よって、私はソフトウエア開発技術者と共同でトレースツールを用いて、どこで処理がかかっているかを調査した。するとトレース結果は

「処理がかかっているか」という表現ですが、処理時間がかかっているかということでしょうか。日本語表現がよく分かりません。

以下のようになった。
①DBアクセス約４５％
②DBアクセスのデータ取得約４０％
③データの加工・編集約１５％
(1)大規模な機能であるため、無駄なDBアクセス・データ取得はあるとは思っていたが、この2項目に関して、ほとんどの時間を費やしているとは、驚きであった。又、トレースツールで順に追っていくと、(2)同一機能で同じデータを別の所で呼んでいるとこが見うけられた。これは同一機能内でも一機能が大きいため複数の担当者が設計しており、重複したデータの取得となってしまっていた。

(1)の記述が気になります。担当者が能力不足で「何やってんだよ。おい、担当者しっかりしろ！」と言っているように思えてなりません。
　そもそも、ＡＥはリーダの立場ですから、こうなったのはＡＥの能力不足なんです。事前にこうなることを予想していなかったこと、手を打っていなかったのはＡＥの責任です。もっと、自分の問題として真摯に冷静に記述した方がよいでしょう。ここは、芦屋広太なら以下のように書くところです。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　↓
今回開発しているシステムは、実施すべき機能が多い。また、それぞれの機能の多くはデータベース上の項目を取得して処理を行う。
この特徴と今回の調査結果から、データベースへのアクセスと以降のデータ取得ロジックが必要以上に多くなっているのではないかと考えた。
　そこで、私はさらにトレースレースツールで詳細に調査することにした。その結果、同一機能内において、同じデータを複数の箇所で取得していることが分かった。今回の場合、個々の機能が大きいため、同一機能でも、複数の担当者が設計することになっており、それぞれが必要に応じてデータを取得するロジックを入れたため、重複したデータ取得となっていた。本来、このような非効率処理は避ける必要があったが、事前に標準化を担当者に徹底できていなかった。

ＡＥであるあなたの責任なんだから、反省しなさいということです。（以下次回）

１０月１５（水）まんな氏の治療⑦・・・ファイナルチェック！ドクターの診立て(最終回)
ドクターです。では、試験も近いので急ぎましょう。細かいところは赤で追記、修正します。

２．２　対策案と検討内容
（１）DBアクセスの減少
トレースの結果でDBアクセスが処理時間の４５%も占めていた。この入金処理は２０テーブルほどのアクセスがあり、１テーブル１クラスで実装されており、それぞれサーバからDBサーバに1クラスずつのアクセス、つまり２０回DBサーバにアクセスする仕組みになっていた。私はこの２０回のDBアクセスを減らすことが性能改善につながると考え、その対策を考えた。幸いにも、このDBアクセスは、１つの同じクラスから呼ばれている為、対応が取りやすかった。この解決策として、共通クラスをストアドプロシージャ化する対策を取った。これにより２０回だったDBアクセスが1回になり、処理時間も０．８秒まで減少した。

「共通クラスをストアドプロシージャ化する対策を取った。これにより２０回だったDBアクセスが1回になり・・・」？？？？複数の箇所から同じクラスで呼ばれているＤＢアクセスをストアドプロシージャにしたら１回になった？どういうことでしょう？ＤＢアクセス自体は２０回のままでは？そもそも、入金処理はサーバー内のバッチではなかったでしたっけ？ストアドにすると、なんかよいことあるんでしょうか？よく分からなくなってきました？？？

（２）DBアクセス後のデータ取得量の削減
　トレース結果で次に処理時間がかかっていたのが、DBアクセス後のデータ取得のところであった。この処理時間はデータ量に比例するので、取得データ量を減らすことが必要であった。~~無駄な~~不必要なデータ取得している箇所は2箇所あった。
① ２０テーブルアクセスする共通クラスを同じ入金処理内の機能内で2回呼んでいる
② 共通クラス内で取得するレコードは、必要な項目を持つテーブルはレコード全項目を取得しているため、入金処理で参照・更新等使用しない項目まで取得している。
② に関しては、どの項目を使用しているかの調査が必要であり、この大規模な機能で調査するのは、~~たくさん~~多くの工数がかかり、納期まで2ヶ月という段階では厳しいと考えた。また処理時間的にも①は、データ量を半分にするため、処理時間も半分になるという見込みより、①を達成すれば合計時間が０．４秒で０．５秒以内という目標を達成できるため、コストと工数を考えて②は実施しないことにした。①はクラス間で取得したデータの参照を引数で渡していくことにより実現できた（データの参照を渡すため、パフォーマンスは低下しない）

３　評価と効果的な方法
３．１評価
　この性能改善では２．１の①で共通クラス内の変更である点、２．１の②では、たくさんのクラスを修正しなくてよい、比較的簡単なクラスであった為、期間内に修正でき、又納期まで2ヶ月という段階で性能改善以外の妥当性確認について、結合テストを平行して進められ、無事納期までに完了することができた。トレース・ツールによる調査・確認・対策案・検討は、このような大規模な機能の追跡には、非常に有効であると再認識した。~~有効であるというより無くてはならないものであった。~~（←このような情緒的な感想は不要）
３．２ ~~効果的な方法~~今後改善したい点
　今回は、幸いにも~~上記のように今回は、~~結合テスト作業と並行して性能改善に関する作業を進めることができたが、の妥当性の確認とある程度平行並行して進められたが、性能改善すべき場所ややり方方法によっては、結合テストを一度止めて性能改善に関する対応を行わなければいけない場合もあるであろう。よって、性能課題の原因によっては、結合テストを中止せざるを得ず、スケジュールが大幅に遅延する可能性もある。このため、テスト開始以前に性能に関する考慮を十分にしておくべきであった。~~以前に、重要な問題点は認識をもって取り組まなければならない。無駄な~~非効率なサーバへのアクセス、重複ロジック等については、設計段階で考慮されているべき事項で、アプリケーション・エンジニアとして設計者に周知・徹底させることが常にできるようにしていきたいと考えている。しかしそうは言っても、目標レスポンスには、結合テスト前に、なかなか到達のできないものである。よって、トレースツール等で原因・究明し、納期・コストを考えて重要なものから対応して行わなければならない。

こんな感じですね。では、評価です。全体的に悪くはないのですが、文章表現がやや弱いですね。あと、説得力が弱いです。理由は各々の指摘を読めばご自身で分かると思います。題意整合性は問題ないでしょう。論文塾風に評価すれば、Ｃ評価（ボーダー）上でしょうね。結果厳しい指摘をしましたが、よくかけていると思いますよ。ここでの指摘をふまえ、本番でがんばれば十分合格できる可能性がありますよ。では、まんなさん、がんばって退院してください。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（2003/10/14　まんな氏の治療完了）

三連星氏の劇薬

エーロン様

こんばんわ三連星＠情報処理論文試験ゼロ勝です。

さて、まんなさんの論文ですが、課題論文と思います。
理由：数値の矛盾の結果、ＱＣのすすめかた自体が問題と判断される。（ただし、矛盾箇所とは、今まで指摘された箇所とは別のところです。）

その前に。
設問ウの書き方が他のかたと変わっています。
どこが？
通常、設問イの工夫の結果がどうなったかを設問ウに書いている例が多いですが、まんなさんは異なります。設問イの最後に書いています。
　※(1)を達成すれば合計時間が０．４秒で目標を達成できるとあるので、設問イの最後尾で書いたこととみなしている。
これでも良いかどうか？

私は賛成派です。

というのは、「設問イの工夫の結果どうなったか」は、あくまで結果であって評価にあらず。

よって、設問イの最後でも、設問ウの冒頭でもかまわない。
評価とは、「設問イの結果がうまくいったなら、どこに気をつけたからこそうまくいったかうまくいかなかったなら、それは何故か。次回どこを直せば良くなるか」というのが評価だから。

よって、この部分はまんなさんの支持にまわります。
私自身、設問イの工夫の結果は設問イに書いています。そして、それで書き方に問題があるとは思えないのです。現実に、論文をそれでクリアしています。　※念押し。ただし情報処理試験ではありません。

既に指摘された事項
> 1件あたりに使用できる時間は０．４秒である。（１．２）
　　実は０．００３６秒／件。もしくは、対象となるデータは３００万件ではなく３万件。
> 合計時間が０．４秒で０．５秒以内という目標を達成できる（２．２）
　　はじめのほうには目標時間は０．４秒とあるので矛盾。
私も、いちおう指摘はしますが、あくまで指摘するだけ。大きな減点とは見ていません。
　※これらは、単なる字ミスとみる。まあ、１００点満点のうち、１～２点程度の減点か？
　　字ミスとみない場合、「イで書いた工夫ではとてもじゃないが０．００３６秒／件は実現できないから論文としてアウト」となりますが、そういう解釈は、私はしません。

数値関連で気になるのはこちら。単なる字ミスと解釈できない事項です。

その１
> 1件あたりに使用できる時間は０．４秒である。（１．２）
０．３６秒を切り上げて０．４秒に丸めています。チューニングの結果、８秒を０．４秒に押さえ込み、目標達成と判断しています。でも、０．４秒で３万件なら３時間２０分かかることになり、目標未達となってしまいます。
ここは、切り捨て丸めが正しいところ。
午前問なら即アウト。でも実務なら、かならずしもダメとは限りません。処理時間３時間または処理件数３万件のどちらかが余裕をもった数値である可能性が高いため。でも、論文としてはおかしいです。
＞＞目標０．３５秒。チューニングの結果は０．４秒であるので２０分未達。
＞＞しかし、通常業務改善により３０分を捻出できたので、特に支障は無い
＞＞ということで了承を得た。
のようなことになります。

その２
＞データ１件あたり８秒。
＞２．１原因の調査・分析
＞トレース結果は以下のようになった。
＞１．DBアクセス約４５％　　　　　　　　（３．６秒）
＞２．DBアクセスのデータ取得約４０％　　（３．２秒）
＞３．データの加工・編集約１５％　　　　（１．２秒）
この分析が正しいものとします。
ここで、「分析が正しい」とは、＜１．から３．が独立事象として分離された＞という意味で用いています。
改善結果はどうなったか？
＞DBアクセスは１／２０に。
＞データ取得は１／２に。　（データ取得の一部だけダブり取得だろうから、
１／２というのはかなりオマケ。）
＞データの加工は変化なし。
ということは、
１．ＤＢアクセス　０．１８秒
２．データ取得　　１．６秒
３．データ加工　　１．２秒
合計　　　　　　　２．９８秒。　目標未達です。
そもそも、データ加工だけで１．２秒だから、ここにも何らかの手を打たない限り目標未達となるのは間違いなし。
何？ＤＢアクセス改善によりデータ加工の時間も減るから０．４秒になった？
それでは分析ミスになってしまいます。データ加工とは、あくまで、データがそろった後の処理時間のこと。そうでないと、分析した意味が無いことになります。
よって、目標未達かデータ分析手法の誤りかのいずれかに陥ります。いずれにしても、設問イの工夫点の論拠は壊滅します。

再び、設問ウに戻ります。
私が設問ウを書くと、それは自虐的になって....
＞あれが悪かった、これも悪かった、あそこでああしていれば良かった....
某国家試験では、論文試験合格者には面接があり、
「業務で失敗したことはありますか？」と聞かれたかた多数。
それなら、失敗業務で論文を書けばそもそも聞かれないじゃん。（爆）
で、本当に、「途中でコケたダム計画」を書き、それで大丈夫なんだ、というこ
とを自身で立証済です。
というわけで、まんなさんの論文ですが、私の言い分が正しいとして、設問イの誤りにあらず。設問ウの誤りとみます。
何故設問ウなのかって？
設問イ（工夫点）は、そのままとします。私の意見は、
＞設問イの工夫そのものが誤っている。
ですよね？
でも、設問ウで、こう書いたらどうなのか？
＞設問イの工夫で、目標を達成できる見込みであった。
＞でも、実際は３．０秒となりダメだった。ダメな理由は...を間違えたから。
業務報告書としては、間違いなくダメ。でも、論文としてつじつまが合っているから、ダメと言いきるわけにはいきません。

※たとえば、マイケルソン＝モーリーの実験（光速度の精密測定）は、エーテル検出に失敗したという、実験としては失敗に終わった例。
　でも、実験に失敗したおかげで、ノーベル賞受賞。つまり、設問イで間違った工夫を書いても、設問ウの書きかた次第では救える可能性があるということから、設問イでは敗着と断言できず、設問ウまで読んで、はじめて沈没決定。よって、設問ウの書き間違い。
でも、情報処理試験でこういうのもアリなのか実証したわけでない（私は失敗し続けている）ので、こういう離れ業を実験するのは個人の責任ということで。

では。