2002直前治療クリニック

９月２４日（火）　患者はどういう状態か？

ドクターエーロンです。後１ヶ月で本試験となった。今年ははじめて「論文塾」を開催し，生の患者を診る試みを行った。WEB上で診断していくのもよいのだが，やはり限界は感じる。どうして合格論文がかけないのか。何が病巣なのかが分からないからだ。そういった意味で，今回の論文塾はよい研究材料になったと思う。実際に参加された患者の皆様は，よい気持ちがしないかも知れないが，これもSE教育の進歩のためと思って，協力をしてほしい。

＜患者は総じてどういう状態か？＞

今回の１日の治療は以下の通り。

＜午前＞
�@合格論文の特性の講義
�A論文構成の講義
�B構文構成の実技

＜午後＞
�C論文の書き方
�D短文練習
�E２時間半での論文演習（オリジナル予想問題または，過去問題を選択し解答する）

この，�Eの結果は全て添削し，既に患者さんたちに戻したが，ここでの感想は以下の通りだ。

　　１．３割くらいは既に合格レベル

　　２．そのうち，１割は，すごくよい出来。（感心するくらい）

　　３．その他の７割のうち，４割はもうすこしがんばれば合格できる

　　４．残り３割は，もう少しでは無理。でも，１ヶ月努力すれば合格できると思う。

全体的には，「手遅れ，超重症，医者がさじを投げる・・」というものはなかった。（意外だが。）
どちらかというと，思ったより，レベルが高いことに気がついたのであった。ここで，気づいたのは，「多くの患者はもしかしたら，後一歩のところの，細かいルールで躓き，失敗しているのではないかということである。今回も，４割の患者はもう少しであったが明らかに合格論文が具備すべき内容がかけていた。ようは，大事なポイントを知らないのだ。

当然，今回講義したのだが，できる人は忠実に守ったが，多くの人は，３時間前に私が注意したことを忘れてしまっていた。

だから，合格論文に今一歩という状態になったのだと思う。では，どんなところが足りなかったのか・・・（以下次回）

９月３０日（月）　なにが弱いのか？

ドクターエーロンです。前回の続きを考えたいと思う。では，どこが弱いのか？気づいた事をいくつか挙げてみよう。これに該当する人は修正してほしい。うまく書ける患者（すでに合格レベルの人）は以下の課題がない人なのだ。

＜患部＞

まあ，こんなところであろうか。では，�@から解説していこう。
�@「私」の主張が弱く，論述内容が受身になっている。

多くの人が最初は指摘されるのが私の主張だ。文章を第３者からの目で書いてしまう。たとえば・・・

＜×論述例＞

　このシステムでは，○○秒パーセコンドのレスポンスが必要と決まっていたが，それを満たさなかったため非正規化して結合回数を減少させることが決まった。

この記述内容は×です。

　あなたは何をしたの？決まった経緯には参加したの？あなたがいないとこで決まったように思えるんですが？あなたは，いわゆる「やるだけの便利SE？」と思われます。だから，文章が第３者的で主張がない。これでは，合格点をつけたくないのが採点者の心情となります。

これを，修正するには・・・・（以下次回）

10月7日（月）　力強い文章にするコツ

ドクターエーロンです。前回の続きを話すことにしよう。
とにかく，「決まっていた」，「決まったのだった」は避けたほうがよいのだが，これがわかっていない患者が多い。本人も気がついていないのだと思う。とにかくSEとして受身にすごしてきた結果かも知れない。実は，日常業務の態度は文章に出る。このような文章を書く人は，受身であることを疑ったほうがよい。

では，どう書くべきか？　自分でよく考えて見てほしい。

（１分程度考えてください。）

どうだろう？分かるだろうか？

正解は，以下のように自分を中心に書けばよいのである。そうすれば，力強い文章になり，採点者は続けて読み続けてくれるのだ。しかし，この簡単なことが分からない受験生が多いから，なかなか合格論文にならないのである。

＜○論述例＞

　私は，このシステムの特性上から判断し，○○秒パーセコンドのレスポンスが必要と考えた。なぜなら，（理由を書く）
今回，性能テスト時には，この目標を満足できなかった。そこで，私はチューニングを行う必要があった。
　調査すると，データベーステーブルの結合が多く，アクセスが頻繁になっていることが分かった。正規化を進めすぎた結果，テーブル同士の参照が頻繁になり，物理ディスクアクセスを多くしていたのである。
　そこで，非正規化して結合回数を減少させることが対応することにした。結果・・・

このように書いてくれればよいと思う。私が考えたことを私が中心に実施した文章になって力強いことが分かるだろうか？この文章は受身でなく能動的である。

では，次に「�A論拠（行動した理由）が書いていない」である。これはどういうことなのか次回までに考えてほしい。

（次回までに考えてください。）

10月15日（火）　論拠が書いていない文章

ドクターエーロンです。

論文塾も終わり，試験まで１週間になった。論文塾で治療した感じでは，AEコースは半分くらいの方が合格するレベルに達したように思う。

残りは，２回目の添削課題を提出されていないのでなんとも評価できないが，最初でC評価が２回目にはほぼ提出された方全員がA評価になったのは驚きだ。

はやり，指摘したことを忠実に直せば合格論文になることが分かったように思う。

２回目を提出していない方の理由は知らないが，ぜひ，今からでもよいから提出してほしい。かならずよくなっているはずだ。一番まずいのはあきらめること。せっかくもう少しの努力で合格できる力をもっているのに，最初の評価に落胆してあきらめてしまうSEが多すぎる。もっと自信をもってほしい。

試験には必ず参加して，最後までがんばること。あきらめない癖をつけないと，業務上もいつまでたても，一流にはなれないと思う。がんばれと言いたい。

さて，前置きが長くなったが，前回の続きを話すことにしよう。

�A論拠がないていない

＜×論述例＞

　非正規化をおこなって，テーブルに冗長性を持たせた。また，ビューを作成した。具体的には，販売明細テーブルに○○項目を持たせること，商品マスタに○○を持たせることである。また，ビューは・・・

ああ，またこのパターンか・・・この記述内容は×なんだよね。

　やったことしか書いていないのは作文となる。どうしてやったのかの理由を書かないとだめである。

なんどいっても分からない人が多く残念だ。

＜○論述例＞

　私は，非正規化をおこなって，テーブルに冗長性を持たせた。なぜなら，非正規化することによって表結合を少なくすることができ，レスポンスを向上させることができるからである。また，結合条件を指定しなくてすむ分，ユーザの使い勝手がよくなると考えたからである・・・　

このようにかかければよいだろう。

�B私の立場が書けていないか，かけていてもAEではない。

これも気づかない人が多い。

○私はアプリケーションエンジニアとして設計全般を担当した。
○私はアプリケーションエンジニアとして，リーダの立場で参加した。

×（そもそも，立場が書いていない）
×私は設計の一部分を担当した。（こんなのはAEではない）
×私は，プロジェクト管理全般を担当した。（これは，PMの立場）

設問アのどこかに必ず書くようにしてほしい。

�Cそもそも要求された内容を書けていない。

　設問をよく読んでいないか，書いていることを理解できないケースである。
これが一番重症なのだが，本人はなかなか気づかない。

　合格者に見てもらえばよいのだが，それもしない人は一生合格できない恐れがある。何回受験しても合格できない人は，書いていることがずれている可能性があるので，一度，通信教育かセミナーに参加したほうがよい。

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

10月16日（水）　まだまだある「不合格疑い」論文

ドクターエーロンです。

もうすぐ本試験なので，いそいでいこう。

では早速続きを！

�D漢字が明らかに違う。

　急いでいるのは分かるのだが，漢字が明らかに違うものがある。というか非常に多い。具体的には思い出せないが難しくない漢字まで平気で間違えるのは，非常に印象が悪い。このような字は当然ひらがなで書いても印象が悪い。

これは，文章を書きなれていないからであろう。最後は仕方ないが，よく使う言い回しで使う漢字くらいは正しく書けるようにすべきだ。注意してほしい。

�E設問ウの勘違い

　設問ウに書くことが間違っている人がいる。そもそも設問ウで多いのは，�@評価と�A改善策である。この改善策は「今後どうしたいか」と問われる。

この「今後どうしたいか」が曲者だ。多くの人はなんて書くか？

＜×論述例＞

　今後は，今回作ったシステムの不便なところを改善し，さらに便利なシステムを作成していきたい。

　うーん。この記述が間違っているのではないと思う・・・これを書いて不合格になるとも思わない。でも何か違う。院長としてはそう思う。気持ちは分かるのだが・・・つまり，誰がそのようなことを望むのか？ということだ。

　SEはシステムを開発する人であって，開発のオーナーではない。オーナーは顧客である。顧客が便利なシステムを望めば作成してあげればよい。しかし，SEが便利なシステムを作成したいのは自己満足以外の何者でもない。そんな抱負を聞いているのではないのだ。

設問ウの改善点は，設問アで書いたシステム構築の背景を受けて，設問イで工夫した点，進め方がどうだったか？（これは設問ウの評価のところに書く）もし，その工夫や進め方に一部問題があった場合，これをどう改善したいかを書くべきである。今後，すばらしいシステムを作りたいという抱負を聞いているのではないと思う。

たとえば，ユーザが使って「なんぼ」の分析系システムでは，ユーザの使い勝手を重視すべきであろう。導出データを保有したり，ビューを多様したり，関数を用意したり。これで，ユーザは使いやすいだろう。でも，トレードオフとして，保守は確実に大変になる。このような場合，設問ウには，以下のように書くべきだ。

＜○論述例＞

　�@評価
　　今回は，ユーザが使いやすいシステムが必要であった。その観点でいえば，うまくいったと自己評価している。

　�A改善点
　　しかし，使い勝手を重視し，導出項目を許したため，保守は大変になった。現在，このシステムは稼動中で保守が頻繁に発生するが，ユーザからの導出項目追加が相次いでいる。使い勝手と保守性はトレードオフの関係だと思う。効果のない導出項目は，コスト対効果の観点から断ることも必要である。今後は，この基準を整理し，ルールに則った運営をしていくことが必要と痛感している。

こんな感じでかければよいと思う・・・（以下次回）

10月18日（金）　さらにある「不合格になりそう」論文

ドクターエーロンです。

あと数日だ。どんどんいこう。ところで，最近このサイトの参照回数が多くなっている。もともと，AE向けなのでさほど多くもないのだが，直前との理由からか増えている。この時期まで，参照しないのはいただけない。もっと早くからきてくれればよかったのに。でも，今からでも間に合う。しっかり，論文病を治してほしい。

�F設問アの記述量があまりにも少ない。

　解答用紙には，設問アは８００字書けるようになっている。基本的には，設問アは８００字を超えない範囲で８００字にできるだけ近づける必要がある。多くの人は，これができていない。

　論文塾では，５行くらい空白にする方もいたが，「よくない」と指摘した。空マスは残さないほうがよい。もし，書くことがなくなったら，設問イに向けての布石を書いておこう。たとえば，性能改善がテーマだったら・・・

（×論文例）

〜であった。
□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□
□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□
□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□
□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□
（×空欄が残っていて印象が悪い）

（○論文例）

〜であった。
　このシステムは全国オンラインの基幹システムであり，レスポンスも５秒/Sが要求されていた。
したがって，私はこのシステム開発のポイントは，どのように要求性能を満足するかだと考えていた。
そこで，当初から，性能を意識した設計を意識する必要があった。また，性能テストの方針も大きなポイント
であると考えていた。

このように，とって付けた追加論述を空マスに応じて書けるようにしておくことがよい。さらに注意してほしいのは解答用紙の１枚目の途中から，設問アを終わらせて設問イを書き始めることだ。これはルール違反だから，やめたほうがよい。というか，ルール違反で，採点されないので，さびしい思いをするだけだ。

�G読みづらい（うまく箇条書きを使えていない，字が乱雑，うすい）

　箇条書きで，以下のような書き方は読みにくいのでやめたほうがよい。

＜×だと思う箇条書き＞
�@・・・・・・・・・・・・・・・・・・・・・・・。�A・・・・・・・・・・・・・・・・・・・・・・・・・�B・・・・・・・・・・・・・・・・・・・・・・・・・・・

＜○だと思箇条書き＞
�@・・・・・・・・・・・・・・・・・・・・・・・・
�A・・・・・・・・・・・・・・・・・・・・・・・・・
�B・・・・・・・・・・・・・・・・・・・・・・・・・

箇条書きをつなげられると本当に読みにくいからだ。あと，字が乱雑なのもよくない。時間がないのは分かるが，丁寧に書いてほしい。字が綺麗か綺麗でないかの問題以前に，読ませる丁寧な字か，読む人のことを考えない字かははっきり分かる。多少汚くてもよいが，丁寧に書こう。また，うすいのもつらい。目が疲れるし，迫力がでない。残念ながら，説得力が出てこないので，損をすると思う・・・（以下次回）

10月19日（土）　もう一声「不合格っぽい」論文

ドクターエーロンです。

明日は最後の土曜日だ。もう勉強できるのは１日。直前治療も終わりだ。ではいこう！

�H本当か？と思える事例（そんなこと普通しない・・・）が書いてある。

論文塾で書いた人には本当に申し訳ないが，ぜひ，悩める他の患者のために紹介させてほしい。（論文医学の進歩のためである）

データベース設計で，正規化のネタがあった。正規化の問題で定番なのが，正規化を崩して「レスポンスを確保した」というやつ。でも，更新異常をどうにかしなくてはならない。これを論述で理路整然と書かなくてはならないのだ。

通常，このお手本記述は「参照専用DBである」ということである。参照専用なら，更新は当然ないわけで，更新異常が発生するわけがない。これを書けばよいのだが，中には，どうしても嘘がつけず，更新系システムを題材にされる方がいる。

このケースで，以下の論述があった。

非正規化（正規化崩し）を行うことで，テーブルの参照を減らし，応答性を確保した。このような場合に問題になるのは，データの２重保有による更新異常の問題である。そこで，私は，同じ内容を持つ項目間のどれかが更新されると，トリガー機能で，常に同期をとるように設計した・・・・・・

本当か？こんなことをすべきなのか？確かに，間違ってはいないし，実際にこのように設計し，運用されているかも知れない。しかし，普通しない。少なくとも，私が絡んだシステム開発では，ぜったいに許さない。いびつだし，保守も大変で，末代まで，禍根を残すはずだ。

このため，この患者さんには，添削治療時に「本当だったらよいが，本当に，本当か？」と赤ペンで大きくチェックを入れてしまった。後日，直前質問会であったときに念押ししたら「作り話です」とのこと。やっぱり，普通こんなことしないのだ。このような記述は，危ないのでやめるほうが無難である。（しかし，実は，院長も合格論文集で書いているような気もする・・・・）

�I文章が冗長，口語体！

結構います。なかなか，日本語をチェックしてもらう機会がないからだと思う。多くの人が冗長だったように思う。（本当に文章がうまい人も結構多かった）

これは，ある程度は許してもらえると思う。これは，日本語を多く書くしかない。院長もこのサイトでつぶやきを書き始めたころから，１０冊以上の単行本，雑誌のコラムを書き，冗長性はかなり排除されたと思う。（編集さんはやっぱりうまい！）ただし，基本的なものは押さえてほしい。

　・形容詞の修飾が異常に多い。
　・口語表現（普通の場合，○○をしないといけない⇒通常，○○すべきである，一般的に○○せねばならない）
　・言い回しが長い。（○○だと思われたが，結局，○○だと思ったので，そうした）
　　　　　　　　　　　　（○○だと思い，○○を実行した）
　・２重否定

以上，論文塾で判明した患者の病巣である。皆様の論文病克服に貢献できれば幸いである。なお，この事実を院長に分からせてくれた論文塾患者の皆様。公表してしまった院長を許してほしい。これも論文医学の進歩のためである。この場を借りて，厚く御礼したい。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　直前治療　　完了

　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　Copyright ©2000 ：2002　OFFICE A-RON all right reserved