情報処理技術者試験☆合格への道

ライフワークとしての資格取得ブログ presented by Pman






Since 2005/01/10

ブログ内検索↓

カテゴリー


ブログランキング

にほんブログ村 資格ブログ 国家試験へ にほんブログ村 資格ブログ IT系資格へ
 にほんブログ村 資格ブログへ
 ブログの殿堂
資格・スキルアップ Ranking  ナレコム おけいこブログランキング

アンケート


広告エリア1




参加トラコミュ


SEO/サイト価格

SEO対策・SEOとは
IT  資格  ブログ
受験  日記  合格  論文


最近の記事


リンク集




自己紹介など

    くつろぐ

  • ニックネーム:Pman
  • プロフィール:
     情報処理サービス会社に勤務。主に金融業のソフトウェア開発、システム運用・保守を担当。メインフレームからオープン系まで広く浅く経験。資格取得はライフワークとなりつつある。
    保有資格
    システム監査技術者
    プロジェクトマネージャ
    アプリケーションエンジニア
    テクニカルエンジニア(システム管理)
    ネットワークスペシャリスト
    情報処理技術者(一種、二種)
    電気通信主任技術者(第一種伝送交換)
    工事担任者(デジタル第1種)


  •  質問、要望、感想、応援などは
     下のメールフォームから、直接
     私あてに送ることができます。


     当ブログはリンクフリーですが、
     リンクした場合は、メール又は
     コメントで知らせていただくと
     ありがたいです。

メールフォーム

名前:
メール:
件名:
本文:

広告エリア2












スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

2008読書録『ウェブ進化論 本当の大変化はこれから始まる』

 まだ読んでいない人は、今すぐに読むべし。

ウェブ進化論 本当の大変化はこれから始まる (ちくま新書)ウェブ進化論 本当の大変化はこれから始まる (ちくま新書)
(2006/02/07)
梅田 望夫

商品詳細を見る

 インターネットを使うと、リアル世界では決して訪れることがないであろう地球の裏側の国までの様子をうかがい知ることができる。また、ネット世界に生きるあまたの人々と交流を持ったり、欲しい情報がすぐに入手できたりする。この十年もの間で、我々がインターネットの恩恵を授かってきたことは明らかであろう。こうした背景があって本書の話は展開されていくのだが、じつに読みごたえのある内容だった。アマゾンレビューにも既に多くのコメントがあり、反響の大きさを物語っている。私も気がつくと、読み終わるのが惜しいとさえ思いながらページをめくっていた。個人的には、第四章「ブログと総表現社会」に最も強い関心を抱いた。この社会に住む一人として、これからも発信しつづけていきたいと思う。
 大変化は、もう始まっている・・。

スポンサーサイト

論文講座-20-最終回 合否の分かれ目は?

 まだ言い足りないことがたくさんある気がしている。でも、講座と呼ぶからには最後のまとめをして、締めくくらなければならない。きょうは最終回として、私の思うことを述べてみたい。次の数字は、平成19年度の論文試験における午後2のスコア分布(ランク別の人数)である。

  AN  A:398 B:541 C:177 D:102 計:1,218
  AU  A:397 B:390 C:180 D: 93  計:1,060
  PM  A:916 B:668 C:230 D:161 計:1,975
  AE  A:785 B:681 C:287 D:473 計:2,226
  SD  A:221 B:146 C: 46  D: 71  計:484
  SM  A:331 B:291 C: 86  D:129 計:837

 たしか以前の記事に、通常はBが最も多いなどと書いたりしていたが、必ずしもそうでなくなったことがわかる。昨年は、アナリスト(AN)を除いた残り5つの区分において、Aが最も多かったのである。この数字を見て、あなたはどのように感じるだろうか。
 受験者のレベルが年々高くなれば、Aが増えて合格率が上がっていくのだろうが、昨年の結果を見るかぎり、もしや評価基準が少し甘くなっているのではないかと思えてくる。こうした状況からみて、大きな失敗さえしなければ、かなりの確率でAランクを獲得できると考えられる。

 これまで様々な角度から述べてきたが、ややテクニック寄りというか方法論に傾倒しすぎたかと思っている。テクニックも必要だが、それだけで簡単に書き上げた文章は恐らくBランク止まりだろう。自分の書いた論文を読んで採点する相手がいることを忘れてはならない。もし私が採点者だとしたら、少しくらい文が下手であっても、題意を汲み取って素直に丹念に書いてある人を評価するだろう。現場の泥臭い話であっても、論理的な主張の裏付けになっていれば、それは採点者の心の琴線に触れるだろう。つまり、論文試験によって採点者との意思疎通ができれば、合格である。

 皆さんの健闘を祈って、当講座を終了とします。
 がんばってください。

論文講座-19-直前1週間でやること

 きちんと論文対策をやるような人は、当然のことながら合格を目指しているものと思う。この記事を書いている今は春の試験が目前に迫っていて、最後の追い込みにはいっている人も多いだろう。その一方で、思いどおりに勉強が進まず、焦ったり困ったり悩んだりもがき苦しんだりしている人もいると思う。むしろ後者のほうが多いかもしれない。では、試験の直前はいったい何をやればいいのだろうか。これは人それぞれの事情があるので一概には言えないが、考えられる対策をいくつか挙げておく。

1.受ける試験区分の論文になっているか確認する
 これができていないと、どんな名文を書いてもだめである。例えば、システム管理の論文なのに開発者の視点で書いてしまう、システム監査の論文なのに監査基準に反する内容を書いてしまう、などというのは論外だ。そんなこと当たり前と思っていても、自分の書いた準備論文をもう一度よく読むと、意外な穴があるかもしれない。自分の立場を再認識すること。

2.論述する項目を体系的に整理しておく
 特にむずかしいことを言っているのではなく、論点を箇条書きにでもしてみよう、という意味である。用意する項目数が多いに越したことはないが、個々のトピックについて十分な説明ができれば、数はさほど気にする必要はない。箇条書きにすると全体が見えるので、試験当日に見るメモとしても有効に使えるだろう。

3.テンプレートの記述内容を確認する
 試験のときは、問題を解く前に、論述の対象となるシステムやプロジェクトの概要について15項目ほどの質問に答えることになっている。テンプレートと呼ばれるもので、市販の過去問題集などに見本が掲載されているはずだ。これは、きちんと書かなければいけない。すばやく記入できるように準備しておき、論文との矛盾がないようにチェックすること。

4.再度、過去の問題に目を通しておく
 論文試験というのは、どうしても書くほうばかり気になってしまうが、じつは読むほうも大切である。題意を正確に読み取らないと、望ましい解答が書けないからである。試験直前には、過去の午後2問題をいくつか選んで読み、実戦イメージをつかんでおくこと。

5.自分の解答ペース=時間配分を確認する
 対策本などには、標準的な時間配分について記載されていたりする。それはそれで参考にはなるが、結局は自分で決めるべきだろう。ちなみに私の場合、以下のような配分を事前に決め、本番でもこのペースをほぼ守っている。
  読解及び設計 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分)
 本当は論文設計にもっと時間をかけるべきかもしれないが、実際に書くための時間がたくさん欲しいので、さっさと書き始める場合が多い。また、最後の見直しは今までやったことがない。やりたくても時間がなくてできないのだが、仮にまずい所があったとしても手書きの修正は難しいので、見直しは行わないことにしている。

 次回へつづく。

論文講座-18-ろんぶん七変化

 与えられたテーマに対して臨機応変に対処できれば何も困ることはないのだが、本番でそれを実行するのは、決して容易なことではない。私の場合もいろいろ経験してきたが、何回受験してもやはり難しいと思う。しかし、難しいけれども、不可能なことではない。以下に例をあげて考えてみたい。

SM合格時の再現論文から抜粋)
 パッチ対象のデータ件数が大きいほど、今回のような障害発生による影響も大きくなる。そこで、今までは作業結果をDBダンプリストの取得による目視確認としていたが、検証ツールによる自動確認に変更することを考案した。ツールは表計算ソフトのマクロ機能を利用したものであり、確認作業の省力化が期待できる。

 どのようにして改良・改善するのかを述べるだけなら、これでもいい。ところが、最近の出題はいろいろな要件を含むことが多い。ただ単に方法や手段を述べるだけでなく、もう少し踏み込んだ論述が要求される。仮に、改善策を実施するにあたっての「制約」を求められたとしたら、次のような展開になるだろうか。

 パッチ対象のデータ件数が大きいほど、障害が発生した場合の影響も大きくなる。このため私は、DBダンプリストの目視確認を、検証ツールによる自動確認へ変更することにした。ただし、パッチ作業などの例外運用として使える予算には制約があるため、ツールによるチェック機能は優先度の高いものだけに限定した。

 あるいは「問題点」を求められた場合は、次のように書ける。

 パッチ対象のデータ件数が大きいほど、障害が発生した場合の影響も大きくなる。そこで、DBダンプリストの目視確認を、検証ツールによる自動確認へ変更することにした。しかし、ツールの入力となるチェック用データを作成するための作業負荷が大きいと予想され、この問題を解決しなければならないと私は考えた。

 以上3とおりの内容を1つに集約することも可能だし、1つ1つをさらに膨らませることも可能である。つまり、論文というのは書き方一つで自由自在にアレンジできるのだ。本番でそれを実行するためには、手持ちのカードを充実させ、いろいろなカードを場に応じて使い分けられる訓練をしておくべきだろう。

 次回へつづく。

論文講座-17-準備論文からの展開

 ようやく書き上げた準備論文。しかし、必死にこれを暗記するのは、あまりおすすめしない。暗記するほど読んだり書いたりしていいのは、せいぜい設問アの前半ぐらいだろう。この部分は、論述の対象となるシステムやプロジェクトの概要を述べればいいのだから、目をつぶっても書けるぐらいに準備しておきたい。出だしがスムーズにいけば、以降への弾みがつく。
 設問アの後半および設問イになると、準備していた論文をそのまま使えない場合が多い。例えば、発生したシステム障害の「事象」を書いて準備していたところ、本番では障害発生による「影響」まで問われた、などというケースが想定される。この場合でも、まず障害の事象を書いたあとに影響を書くという流れにすれば問題はない。以下の例で考えてみよう。

 経理システムの夜間バッチ処理で異常終了が発生した。当処理は、勘定系システムから提供される入力データをもとに統計帳票を出力する月次処理である。システム稼動後、初めて走行した処理であったが、入力データの必須項目に値が設定されていなかったことにより、業務プログラムでエラーが発生したという事象であった。

 これでは影響がわからない。そこで、このあとに次の内容を続けて書いてみる。

 月次帳票は、A社にとって経営上の意思決定を行うための重要な情報源となる。こうした帳票を毎月定められた日に納品することは、A社と取り決めたサービスレベルの一つでもある。したがって、異常終了によりバッチ処理が停止したため帳票が出力されなかったり、対応後の再処理により納品が遅れたりすると、A社からの信頼を失うことになりかねない。

 このように展開できれば、設問に対して忠実な論文になる。
 準備論文はあくまでも準備にすぎない。試験では「その先の一歩」が要求されるものと覚悟し、臨機応変に対応しよう。

 次回へつづく。
 | HOME |  ▲ page top


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。