天命を待つ…システム完全統合で背水の陣 三菱東京ＵＦＪ銀----- 引用開始 -----
三菱東京ＵＦＪ銀行のシステム完全統合が１２日に正念場を迎える。１２月までの統合計画の中で、同日は旧東京三菱銀行の全店舗約２５０店を一斉に新システムに切り替えるという最大の山場。約４０００万口座を抱え、１日に約１億件の取引を処理する巨大システムでトラブルが起きれば、日本の金融システムへの影響も避けられないだけに、経営陣は背水の陣で臨む。
----- 引用終了 -----
【産経新聞：2008年05月09日】
金融業界をはじめ日本中が注目する一大イベントがやってきた。合併に伴うシステム統合といえば、６年前のみずほグループを思い出す。その時に起きた大規模な障害がどれほどの影響を及ぼしたのか、詳細な記憶は薄れつつあるが、とにかく深刻なものだったことは確かである。その二の舞を演じるわけにはいくまい。
新システムの稼動開始といえば、華々しい幕開けを想像する一方で、その裏では汗をかき、血眼になって移行作業に取り組む人々がいる。私も昔、大きなシステムのカットオーバーの日、ピリピリした気持ちで稼動の瞬間に立ち会った。無事にシステム立ち上げが完了したとき、そこにいた数十人のメンバーが一斉に拍手し、第一関門の突破に胸をなでおろした。しかし、問題はそのあとである。見かけ上は正常に動いているシステムも、完全ということはない。必ずバグが潜んでいるものだ。そのバグが顕在化すれば障害になるが、ひょっとしたら永久に見つからないバグもあるかもしれない。いや、大規模システムなら必ずあるだろう。
そういった観点からすると、次の記事は気になる内容を含んでいる。
三菱東京UFJ銀行の勘定系統合「Day2」の内情 障害の未然防止と障害発生時の迅速かつ的確な対応が、システム統合の成否を決めるのではないかと思う。
名著 "ウェブ進化論" とセットで読むべし。
不惑の年代に突入してもなお、自分のやってきたこと(過去)、やっていること(現在)、やろうとしていること(未来)に対して、本当にいいのだろうか・・と考えることがある。大変化が着々と進みつつある社会の中で、自分はどのように働くべきなのか。これは私にとって、Web2.0とは何ぞや？ということよりも切実な問題である。組織の中で働いてはいるが、現状維持が一番いいという考えと、現状を打破しなければ・・という考えが両方あり、そのジレンマを抱えつつ行動できない自分がいる。
本書は、私のような優柔不断でどっちつかずな人間に一筋の光明を与えてくれる本である。『ウェブ進化論』ではその鋭い視点と指摘に目からうろこ状態だったのに対し、こちらの『ウェブ時代をゆく』はIT業界で働く者として共感する部分が多々あったし、著者の真摯な態度に学ぶことも多かった。『ウェブ進化論』完結篇と呼ぶに値すると思う。
当ブログの累積アクセス数が、ついに20万件の大台に達した。10万件に達したのがブログ開始から800日目の2007年3月20日で、きょうはその後410日目であることから、確実にアクセスアップが実現できたと言っていい。たいへん喜ばしいことだ。これからも、次の大台に向かって邁進していきたいと思う。
参考：
感謝！100,000アクセス達成 今後とも宜しくお願い申し上げます。
まだ読んでいない人は、今すぐに読むべし。
インターネットを使うと、リアル世界では決して訪れることがないであろう地球の裏側の国までの様子をうかがい知ることができる。また、ネット世界に生きるあまたの人々と交流を持ったり、欲しい情報がすぐに入手できたりする。この十年もの間で、我々がインターネットの恩恵を授かってきたことは明らかであろう。こうした背景があって本書の話は展開されていくのだが、じつに読みごたえのある内容だった。アマゾンレビューにも既に多くのコメントがあり、反響の大きさを物語っている。私も気がつくと、読み終わるのが惜しいとさえ思いながらページをめくっていた。個人的には、第四章「ブログと総表現社会」に最も強い関心を抱いた。この社会に住む一人として、これからも発信しつづけていきたいと思う。
大変化は、もう始まっている・・。
まだ言い足りないことがたくさんある気がしている。でも、講座と呼ぶからには最後のまとめをして、締めくくらなければならない。きょうは最終回として、私の思うことを述べてみたい。次の数字は、平成19年度の論文試験における午後２のスコア分布（ランク別の人数）である。
AN Ａ：398 Ｂ：541 Ｃ：177 Ｄ：102 計：1,218
AU Ａ：397 Ｂ：390 Ｃ：180 Ｄ： 93 計：1,060
PM Ａ：916 Ｂ：668 Ｃ：230 Ｄ：161 計：1,975
AE Ａ：785 Ｂ：681 Ｃ：287 Ｄ：473 計：2,226
SD Ａ：221 Ｂ：146 Ｃ： 46 Ｄ： 71 計：484
SM Ａ：331 Ｂ：291 Ｃ： 86 Ｄ：129 計：837
たしか以前の記事に、通常はＢが最も多いなどと書いたりしていたが、必ずしもそうでなくなったことがわかる。昨年は、アナリスト(AN)を除いた残り５つの区分において、Ａが最も多かったのである。この数字を見て、あなたはどのように感じるだろうか。
受験者のレベルが年々高くなれば、Ａが増えて合格率が上がっていくのだろうが、昨年の結果を見るかぎり、もしや評価基準が少し甘くなっているのではないかと思えてくる。こうした状況からみて、大きな失敗さえしなければ、かなりの確率でＡランクを獲得できると考えられる。
これまで様々な角度から述べてきたが、ややテクニック寄りというか方法論に傾倒しすぎたかと思っている。テクニックも必要だが、それだけで簡単に書き上げた文章は恐らくＢランク止まりだろう。自分の書いた論文を読んで採点する相手がいることを忘れてはならない。もし私が採点者だとしたら、少しくらい文が下手であっても、題意を汲み取って素直に丹念に書いてある人を評価するだろう。現場の泥臭い話であっても、論理的な主張の裏付けになっていれば、それは採点者の心の琴線に触れるだろう。つまり、論文試験によって採点者との意思疎通ができれば、合格である。
皆さんの健闘を祈って、当講座を終了とします。
がんばってください。
きちんと論文対策をやるような人は、当然のことながら合格を目指しているものと思う。この記事を書いている今は春の試験が目前に迫っていて、最後の追い込みにはいっている人も多いだろう。その一方で、思いどおりに勉強が進まず、焦ったり困ったり悩んだりもがき苦しんだりしている人もいると思う。むしろ後者のほうが多いかもしれない。では、試験の直前はいったい何をやればいいのだろうか。これは人それぞれの事情があるので一概には言えないが、考えられる対策をいくつか挙げておく。
１．受ける試験区分の論文になっているか確認する これができていないと、どんな名文を書いてもだめである。例えば、システム管理の論文なのに開発者の視点で書いてしまう、システム監査の論文なのに監査基準に反する内容を書いてしまう、などというのは論外だ。そんなこと当たり前と思っていても、自分の書いた準備論文をもう一度よく読むと、意外な穴があるかもしれない。自分の立場を再認識すること。
２．論述する項目を体系的に整理しておく 特にむずかしいことを言っているのではなく、論点を箇条書きにでもしてみよう、という意味である。用意する項目数が多いに越したことはないが、個々のトピックについて十分な説明ができれば、数はさほど気にする必要はない。箇条書きにすると全体が見えるので、試験当日に見るメモとしても有効に使えるだろう。
３．テンプレートの記述内容を確認する 試験のときは、問題を解く前に、論述の対象となるシステムやプロジェクトの概要について15項目ほどの質問に答えることになっている。テンプレートと呼ばれるもので、市販の過去問題集などに見本が掲載されているはずだ。これは、きちんと書かなければいけない。すばやく記入できるように準備しておき、論文との矛盾がないようにチェックすること。
４．再度、過去の問題に目を通しておく 論文試験というのは、どうしても書くほうばかり気になってしまうが、じつは読むほうも大切である。題意を正確に読み取らないと、望ましい解答が書けないからである。試験直前には、過去の午後２問題をいくつか選んで読み、実戦イメージをつかんでおくこと。
５．自分の解答ペース＝時間配分を確認する 対策本などには、標準的な時間配分について記載されていたりする。それはそれで参考にはなるが、結局は自分で決めるべきだろう。ちなみに私の場合、以下のような配分を事前に決め、本番でもこのペースをほぼ守っている。
読解及び設計 14:10〜14:25（15分）
設問アの記述 14:25〜14:50（25分）
設問イの記述 14:50〜15:50（60分）※監査のみ14:50〜15:35（45分）
設問ウの記述 15:50〜16:10（20分）※監査のみ15:35〜16:10（35分）
本当は論文設計にもっと時間をかけるべきかもしれないが、実際に書くための時間がたくさん欲しいので、さっさと書き始める場合が多い。また、最後の見直しは今までやったことがない。やりたくても時間がなくてできないのだが、仮にまずい所があったとしても手書きの修正は難しいので、見直しは行わないことにしている。
次回へつづく。
与えられたテーマに対して臨機応変に対処できれば何も困ることはないのだが、本番でそれを実行するのは、決して容易なことではない。私の場合もいろいろ経験してきたが、何回受験してもやはり難しいと思う。しかし、難しいけれども、不可能なことではない。以下に例をあげて考えてみたい。
（
SM合格時の再現論文から抜粋）
パッチ対象のデータ件数が大きいほど、今回のような障害発生による影響も大きくなる。そこで、今までは作業結果をＤＢダンプリストの取得による目視確認としていたが、検証ツールによる自動確認に変更することを考案した。ツールは表計算ソフトのマクロ機能を利用したものであり、確認作業の省力化が期待できる。 どのようにして改良・改善するのかを述べるだけなら、これでもいい。ところが、最近の出題はいろいろな要件を含むことが多い。ただ単に方法や手段を述べるだけでなく、もう少し踏み込んだ論述が要求される。仮に、改善策を実施するにあたっての「
制約」を求められたとしたら、次のような展開になるだろうか。
パッチ対象のデータ件数が大きいほど、障害が発生した場合の影響も大きくなる。このため私は、ＤＢダンプリストの目視確認を、検証ツールによる自動確認へ変更することにした。ただし、パッチ作業などの例外運用として使える予算には制約があるため、ツールによるチェック機能は優先度の高いものだけに限定した。 あるいは「
問題点」を求められた場合は、次のように書ける。
パッチ対象のデータ件数が大きいほど、障害が発生した場合の影響も大きくなる。そこで、ＤＢダンプリストの目視確認を、検証ツールによる自動確認へ変更することにした。しかし、ツールの入力となるチェック用データを作成するための作業負荷が大きいと予想され、この問題を解決しなければならないと私は考えた。 以上３とおりの内容を１つに集約することも可能だし、１つ１つをさらに膨らませることも可能である。つまり、論文というのは書き方一つで自由自在にアレンジできるのだ。本番でそれを実行するためには、手持ちのカードを充実させ、いろいろなカードを場に応じて使い分けられる訓練をしておくべきだろう。
次回へつづく。
ようやく書き上げた準備論文。しかし、必死にこれを暗記するのは、あまりおすすめしない。暗記するほど読んだり書いたりしていいのは、せいぜい設問アの前半ぐらいだろう。この部分は、論述の対象となるシステムやプロジェクトの概要を述べればいいのだから、目をつぶっても書けるぐらいに準備しておきたい。出だしがスムーズにいけば、以降への弾みがつく。
設問アの後半および設問イになると、準備していた論文をそのまま使えない場合が多い。例えば、発生したシステム障害の「事象」を書いて準備していたところ、本番では障害発生による「影響」まで問われた、などというケースが想定される。この場合でも、まず障害の事象を書いたあとに影響を書くという流れにすれば問題はない。以下の例で考えてみよう。
経理システムの夜間バッチ処理で異常終了が発生した。当処理は、勘定系システムから提供される入力データをもとに統計帳票を出力する月次処理である。システム稼動後、初めて走行した処理であったが、入力データの必須項目に値が設定されていなかったことにより、業務プログラムでエラーが発生したという事象であった。 これでは影響がわからない。そこで、このあとに次の内容を続けて書いてみる。
月次帳票は、Ａ社にとって経営上の意思決定を行うための重要な情報源となる。こうした帳票を毎月定められた日に納品することは、Ａ社と取り決めたサービスレベルの一つでもある。したがって、異常終了によりバッチ処理が停止したため帳票が出力されなかったり、対応後の再処理により納品が遅れたりすると、Ａ社からの信頼を失うことになりかねない。 このように展開できれば、設問に対して忠実な論文になる。
準備論文はあくまでも準備にすぎない。試験では「
その先の一歩」が要求されるものと覚悟し、臨機応変に対応しよう。
次回へつづく。
論文試験の時間は120分、設問アを800字以内、イ・ウを合わせて1600字以上の字数という条件がある。このため、仮に2400字の論文を書く場合、単純に計算して2400÷120＝20（字／分）つまり３秒間で１文字のペースで書く必要がある。問題文を読んだり段落設計をしたりする時間を差し引くと、理想的には3000字を100分で書くとして3000÷100＝30（字／分）つまり２秒間で１文字というペースになる。何も考えずに、ひたすら手を動かし続ければどうにか書ける。しかし、実際の試験で考えずに書くなんてことは、ありえない。考えながら、なおかつ書き続けなければならないのだ。これは、経験した人なら分かると思うが、想像以上に過酷な作業と言わざるを得ない。
したがって、手書きの練習は是非ともやってほしい。最初はパソコンを使ったほうが構成の組み替えや内容の修正がしやすいのだが、それで終わりにせず、一度は本番を意識して紙に書いてみる。すると、思わぬことを発見する場合がある。時間が足りない、漢字が書けない、手が疲れる・・など。結局のところ、手書きに慣れるしかない。
少し話は変わるが、論文試験を手書き形式で行うことに疑問の声があるらしい。今どき業務で、これだけの文章をパソコンも使わずに手で書くような作業はしない・・つまり非現実的なのだという。これはもっともな話である。実務では、ワープロソフトを使って良い文書を作れるほうが、ずっと役に立つだろう。しかし、やはり試験では、手書きのほうがいいと私は思う。受験する側にとって相当の負担になることは確かだが、読み手に対してより深い印象を与えたり主張を伝えたりするには、手書きがもっとも有効なのである。採点する側の苦労もあるだろうが、手書きの文字には人格が滲み出るので、パソコンの無機質な文字を読むのとはまた違った目で、総合的な評価ができるのではないか。
私は初めて論文試験を受けたとき、これは大変な試験だと思った。考えながら書き続けるという荒業を、自分ができるとは思えなかった。けれども、何度も練習を重ねていくうちに、できるようになった。以下に、練習のコツを挙げておく。
・いきなり手書きしない。内容が固まってから手書き練習にはいること。
・時間を計って練習する。最初は120分にこだわる必要はない。
・ノートでもいいが、なるべく原稿用紙（横書き）を使う。
・全体に、漢字より平仮名を少し小さめに書くと、読みやすくなる。
・消しゴムはなるべく使わないように、集中して書く。
・書いている途中で内容の不備に気づいたら、即興で修正してみる。
→こうした状況は本番でも起こり得るので、効果的な訓練になる。
・時間があまり無い場合は、設問アだけ練習してもいい。
→特にアの前半は、テーマによって大きく変わることはないため。
・ひととおり書いたあと、重要な部分だけ抜き出してもう一度書く。
次回へつづく。
しばらくの間さぼっていたが、ここでまた少し書いておこう。
論文の準備は、ある程度まとまった時間が必要なので、平素忙しく働いている人は休日をうまく利用するといいだろう。私の場合、だいたい土日で集中的に論文の下書きをしておき、平日の通勤途中に論文の見直しや推敲、午後１の演習をやるというパターンが多い。とにかく時間を有効に使わないと、あっという間に月日が過ぎ去ってしまい、気がついたら試験日がすぐ目の前に迫っていた、なんていうことになる。そうならないためにも、先の見通しを立てて準備しておきたい。
推敲とは、文章を十分に吟味して練りなおすことである。これは、私の経験上、論文対策ではとても大切なことだと考えられる。極端な言い方をすると、準備論文を書いただけでは対策にならない。書いたものをよく読んで、不足はないか、修正すべき点はないか、あるとすればどのように追加・修正するか、そうしたことを十分に検証するのが論文対策である。検証のポイントは、これまで本講座で述べてきた８つの観点ということになる。
我々の日常を省みてもわかるが、他人に読んでもらうために書いた文章を少なくとも一度は読みかえし、手直しするだろう。大切なビジネス文書であれば、何度も見直しするだろう。それと同じことだ。
参考として、私の推敲手順の一例を以下に示す。
１. 土曜に、準備論文のテーマ選定、構成作り・章立てを行う。
２. 日曜に、論文の下書きをパソコンで行い、印刷する。
３. 平日に、電車で、印刷したものを読み、手書きで推敲していく。
４. 平日に、帰宅後、時間があれば、推敲した内容で電子文書を更新する。
５. 休日に、推敲後の論文を印刷し、それを見ながら手書きする。
要は、生活のリズムに合わせて自分流のやり方を確立することが大切である。はじめの文章はボロボロの穴だらけでも、やり方次第でだんだんと良くなっていく。文章が成長していくプロセスは、心地よいものだと思う。
次回へつづく。
今年の春期試験は、受けないことにした。そのせいか、２月末ごろから試験に対する関心が急速に薄れてきて、しばらくブログを更新しない日が続いた。今回の受験をやめた理由は、受けたい種目がないからである。SV:テクニカルエンジニア（情報セキュリティ）あたりを狙ってみることも少しは考えたが、自分の仕事との関連があまりないことと、来年のSC:情報セキュリティスペシャリストも気になることから、今回はやめた。DB:データベースやES:エンベデッドは全く考えておらず、そうなると残った候補は１つ、AD:初級シスアドだ。
これは意外におもしろい選択かもしれないと思った。振り返ってみると、私は今まで、主にシステム開発者向けの試験を受けてきたが、システム利用者向けの試験を受けたことが一度もない。今までとはちがう視点からアプローチというのも悪くないと考えた。利用者側の試験は現在、SD:上級シスアド、SU:情報セキュアド、AD:初級シスアドの３つであるが、SDとSUは秋なので、今回選べるのはADのみとなる。初級シスアドは、部門の情報化推進者として備えているべき知識・技能を問う試験であり、個人的には興味があった。
受けても無駄にはなるまい。知識を体系的に整理する意味で、受けないよりは受けたほうがいいだろう。しかし、書店にたくさん積まれている対策本の一冊をぱらぱら見て、やめようと決めた。何か自分の目指す方向ではない気がしたからだ。
評価ポイントの８つ目「表現力・文章作成能力」とは、どういうことか。
これまで様々なポイントについて論じてきた。そして、この８つ目がいよいよ最後となる。ただし、文章作成能力に関しては、当講座の最初のほうで既に述べている。論文試験では、内容だけでなく、文章の形式・構成も重要なポイントになると考えたほうがいい。
表現力については、文章を書き始めると悩む人が多いのではないか。私もその一人で、準備論文を書いているとき、もっとうまい表現はないものかと思い、書いては消し、消しては書いてのくり返し。どんなふうに書いてもしっくりとくる表現が見つからず、もがき苦しむ羽目になる。こういう時は、そこで止まらずに、とりあえず思いつくまま書き進めていったほうがよい。最後まで書き上げたあとで読み返してみると、もっといい表現がひらめいたりするものだ。表現力は、一朝一夕に向上するのでなく、長い月日をかけてトライ＆エラー即ち
試行錯誤をくり返すうちに少しずつ向上するものだと思う。
ここで、今まで述べた評価ポイントを振り返ってみよう。
１．設問で要求した項目の充足度
２．論述の具体性
３．記述内容の妥当性
４．論理の一貫性
５．見識に基づく主張
６．洞察力・行動力
７．独創性・先見性
８．表現力・文章作成能力
論文を書くうえで最も重視すべき項目は１〜３である。この３つを満たさないと、Ｂランク以上を取るのは難しいと考えられる。１〜３に加えて４〜８をバランスよく満たすことができれば、Ａランクを獲得できるだろう。
次回へつづく。
評価ポイントの７つ目「独創性・先見性」とは、どういうことか。
独創性というのは、他人の真似ではなく、自ら考えて何かを生み出すことだと私は思っている。もとから存在するものと同じようにすれば問題ないだろうと考える人は案外多く、特に日本人はこの傾向が強い。しかし、世の中は時々刻々と変化していくので、いつも同じで良いということは通常あり得ない。状況に応じて、独創的で柔軟な発想を持つことが必要だ。一方、先見性というのは、将来を見抜くことである。ある時期さえ乗り越えればいいのではなく、今後についても視野に入れたうえで、今どうすべきかを考える必要がある。
論文で独創性をアピールするのは「
あなたが工夫した点」である。工夫とは、独自に良い方法を考えて行動したプロセスを指す。私がよく悩むのは、こんな論述が果たして工夫と言えるのだろうか？ということ。この悩みを解決するには、テクニックが必要である。具体的には、次のような論法を用いるといい。
通常は、○○○である。しかし、今回は△△△のため、
×××によって□□□ができるように工夫した。
例文：
通常は、定められた保存期間が過ぎるとデータを削除している。しかし今回は、三段階に分けて移行するため、保存期間の延長によってデータ破壊等のリスクを低減できるように工夫した。 要するに、
いつもとは異なる状況を説明し、だから私はこうした・・という展開にする。上の例文は、ありきたりな内容であるが、意外に見落としがちな盲点に触れていると思う。また、リスクを低減という一言で、先見性もさりげなくアピールしている。
次回へつづく。
評価ポイントの６つ目「洞察力・行動力」とは、どういうことか。
洞察力というのは、簡単に言うと、物事を見通す力である。問題の奥底にある原因や人の心理などといったものを見通すことは、決して容易なことではない。リスクという言葉がよく使われるが、リスクとは問題点そのものを指すのではなく、問題の原因になり得る事象を指す。洞察力とは、こうしたリスクを識別する力であったり、物事の本質を見極める力であったりと、幅広い意味をもつ。
行動力というのは、適切な振る舞いができる力と言える。例えば、政治家はどんなに素晴らしい政策を打ち立てて国民から支持を得たとしても、実現するだけの行動力がなければ意味がない。同じように、情報処理技術者の場合も、システムを知っているだけの生き字引や、指摘・批判するだけの評論家ではなく、積極的に行動できる人物が求められる。静の洞察力、動の行動力とでも言おうか。
以下に、PM論文例を挙げてみよう。
システムテストの初日、通信制御プロブラムの一部にバグが発見された。このため私は、共通開発チームに根本的な原因の究明を指示すると共に、単体テスト及び結合テストの実施状況を確認し、品質上の問題がなかったか調査した。一方、システムテスト工程はまだ初日であることから、現時点でスケジュールの変更は必要ないと判断した。 実務を経験した人であれば、不適切な行動であることに気づくと思う。システムテスト工程は、時にはユーザも参加して業務の流れを確認するなど、重要な工程になることが多い。その初日に障害が起きたのにもかかわらず安易に判断を下すのは、PMとしての洞察力に欠けると指摘されても文句は言えないだろう。では、次のように修正してみよう。
システムテスト工程の初日、オンライン処理が異常終了した。原因は、通信制御プロブラムのバグである。当工程の最初の５日間は疎通確認を行う計画であり、クリティカルパス上の作業であることから、遅延は回避すべきと私は判断した。そこで、主管の共通開発チームに対して、バグの解消を最優先とし、その後に根本原因を究明するよう指示した。 このように書けば現実みを帯びてくる。やみくもな行動ではなく、その
試験区分における立場・役割にふさわしい行動であることが重要だ。
次回へつづく。
評価ポイントの５つ目「見識に基づく主張」とは、どういうことか。
まず、受験するからには、その試験区分についての十分な見識を持っている必要がある。知識や技能に加えて経験があれば、少なくとも論文試験にチャレンジする権利はあると思っていい。しかし、物事を知っていることと、実際に論文を書けることはちがう。午前から午後１までは知識レベルの評価が中心となるのに対し、午後２は思考レベルの評価も加味される。つまり、午後２の論文試験では、ただ単に知っていること、見たこと、聞いたこと、やったことを書き並べるだけでなく、自分なりの主体的な考えを述べる必要がある。
あなたの経験と考えに基づいて、設問ア〜ウに従って論述せよ。
これは、問題文の最後で決まり文句のように出てくる一文である。ほとんどの論文問題が、この文言でほぼ統一されている。さらに設問ア〜ウを読むと、何回も出てくる言葉がある。
あなたが携わった情報システムの概要を・・・
あなたはどのように検討し、・・・
あなたが個別に工夫した点を含めて・・・
あなたはどのように評価しているか・・・
採点者は、マス目に書かれている文章を評価するのではなく、この世にたった一人しかいない「
あなた」を評価するのである。きちんと自己主張のできる人物かどうかを判断するのである。
主張といっても、風変わりで奇をてらったものでなく、じつに当たり前のことのほうが無難である。当たり前のことであっても事実や根拠に基づいた主張であれば説得力があり、確実に評価は上がるだろう。主張をうまく述べるには、論文対策を進めるときに、
主要テーマに対する決め台詞を用意しておくといい。本番でこんなテーマが出題されたらここを必ず述べよう！と決めてシミュレーションしておく。そうすることで、単なる業務報告書のような文章ではなく、あなた自身の論文が自信をもって書けるようになると思う。
次回へつづく。
| ホーム | 次のページ
