2001年4月，試験日を目前にして，私には少しばかりの計算違いがあった。論文の解答例を手に入れられなかったのだ。私が受けようとするテクニカルエンジニア（システム管理）は，前年までシステム運用管理エンジニアという名称だった。その頃はあんまり人気がなかったようで，情報処理技術者試験の中でも受験者数は下から2番目。そのためか，問題集はほとんど出版されておらず，ましてや論文例が載っている本は見つからなかった。おかげで「いつもの」イメージトレーニングができなかった。

誰もが経験していることが出題される

　情報処理技術者試験における全13区分のうち，6つの試験に論文がある。この論文を苦手とする人は多いと聞く。なにしろ出題された3つのテーマの中から1つを選び，120分で2400〜4000字を埋めねばならないのだ。問題用紙を開いてから考え始めたのでは，たいていの人は時間が足りない。だから論文試験には入念な準備が欠かせない。出題されるテーマを事前に予測し，論文の題材を用意するとともに，実際に何本か論文を書いてみることが，合格の秘訣とされている。

　しかし私はそんな準備をしたことがない。もちろん論文が得意ということもある。それ以上に3つの「お題」を初めて目にしたときの高揚感，120分という時間制限からくる緊張感が，いい論文を生み出すのだ。

　「こんな経験あったかーッ!?」「そんなの考えたこともないぞ!!」。「お題」を目にしたとたん，頭には血が昇り，大あわてで過去の経験を総点検することになる。しかし，3つの「お題」についてよく考えてみれば，意外に自分のこれまでの仕事と関係があるものだ。それは短期間の経験かもしれないし，全面的なかかわり方ではないかもしれない。だがその経験を思い出し，あとはペース配分を守りながら，設問に沿って序論，本論，結論に展開するだけだ。

　まず5分ほどで「お題」を選び、それに沿った経験を思い出す。次の10分で書くことのポイントを余白にメモする。こうすることで「自分には書けるネタがある」と自信を持てる。そして序論には，自分が携わった業務やシステムの概要をキッチリ書く。この概要は論文には必ず盛り込まなければならない要素なのだが，それを書くうちにそのプロジェクトに携わっていた当時の気持ちがよみがえる。苦労したことや工夫したことなど頭の中に浮かんできたことを整理して，本論，結論を書いていく。

イメージトレーニングさえできていれば，即興演奏の楽しさで乗り切る

　そのペースを守るためには，初めて「お題」を見たときにカーッと高まるテンションを保つことが大切だ。だから下手に事前に題材を準備することを私はあえてしない。というのも題材を用意すると，どうしても準備した題材と設問が適合するかを冷静に検討することから始めてしまうからだ。そしてその整合性に悩み，時間を気にしながら書くので，どうしても文章がギクシャクしてしまう。

　論文を書くときの私は，即興演奏に臨むミュージシャンのようなつもりでいた。その場のノリを重視して，体の中からほとばしり出るエネルギーを解答用紙のマス目に叩きつける。そしてこのやり方で「システム監査技術者」，「プロジェクトマネージャ」，「システムアナリスト」と，連戦連勝を続けていた私は自信を深めていた。

　私が論文対策として唯一実践しているのは，イメージトレーニングだ。情報処理技術者試験は13もの試験区分に分かれているが，13の職種があるわけではない。情報処理技術者には13の側面があることを示している。つまり，1人の人間が幾つもの面を持ち合わせることがあり，最大で13の面があり得るというわけだ。

　だから試験で重要なのは，今回受験する試験区分で求められている面をはっきり打ち出すこと。システムアナリストならシステムアナリストとしての，プロジェクト･マネジャーならプロジェクト･マネジャーとしての側面をアピールしなくてはならない。別の面を出してしまうと，問われている知識・経験・実践能力を示すことにならない。

　そこで私は試験前にイメージトレーニングをして，その試験区分の人材像になりきるように努めてきた。とはいっても，具体的には問題集を購入し，通勤電車の中で論文の解答例に目を通すだけだ。あんまり時間をかけても仕方がないので，論文は3本も読めば十分だ。ネタは自分の中にある。だから，なんとなくイメージができあがれば，それでいいのだ。

「システム管理はプロジェクトではない」

　試験はまず午前中に選択式問題，午後1番で記述式問題があり，その後いよいよ論文になる。当日の「お題」は「ネットワークの変更について」「システム移行のリハーサルについて」「システム管理業務の見直しについて」の3つだった。

　ここで私は少々悩んだ。どうもピッタリな事例が思い浮かばなかったのである。やがて「ネットワークの変更」についてなら，ちょっとした苦労話を書けそうな気がしてきた。120分の時間内で規定文字数をバッチリ埋めて，私は意気揚揚と試験会場を後にした。ところが3カ月後，情報処理技術者試験センターの合格発表のWebページに，私の受験番号はなかった。

　『ITコーディネータ プロセスガイドライン(β版)』によれば，プロジェクトとは「独自の成果物またはサービスを創出するための期限が定められた活動」である。「期限が定められた」というところがミソだ。「プロジェクトマネージャ試験」に限らず，情報処理技術者試験のどの試験区分でもプロジェクトの経験が問われる。情報戦略立案に重点を置くにしろ，システムの監査を実施するにしろ，定められた期限に向けて活動していくという点ではすべてプロジェクトだ。

　しかしシステム管理だけはプロジェクトとして捉えてしまってはダメなのだ。情報システムを管理・運用していく仕事は，システムがある限り存在する。もちろん個々の業務システムは廃止されたり統合されたりするだろう。しかしシステム管理者に求められているのは，それら個々の業務システムに携わることではなく，業務システム共有のシステム資源である基盤部分の管理なのだ。これは業務や組織が存続する限り，決してなくなることはない。

　だから永続する現場において，いかに適切に管理し，日々改善を施すか，そういう視点が求められる。運用手順を定型化して，作業簿の項目を上からチェックすれば業務が完了するように工夫するとか，メンバーの理解度が均質化するように訓練の機会を設けるとか。どちらかというと地味な活動が中心となる。

　それが私には書けなかった。13の側面のどこを打ち出すのか，ハッキリさせることが重要であると判っていたはずだった。ところが「こんなに大掛かりなプロジェクトで，とっても苦労しました」なんてことを書いてしまった。自分の経験を論文に書くはずが，いつのまにか論文の形式に合いやすい経験を自分の中に探していた。不合格になるのも当然だ。

2度目の挑戦，論文を難なくクリアして合格に

　1年後の2002年4月，再びシステム管理に挑んだ。論文の「お題」は「ヘルプデスクの運営について」「パソコンの管理について」「24時間連続サービスを提供するオンラインシステムの運用について」の3つ。

　私は小躍りしたい気分だった。どれも書きたいことがタップリある。迷いながらもヘルプデスクについての思い出話を書き始めた。2400字を超えても書きたいことが尽きない。「ヘルプデスクのメンバとは苦労もしたけど，面白いこともたくさんあったなぁ」と考えながら，あれも書きたいこれも書きたいという気持ちを押さえつけ，どうにか終了1分前に書き終えた。