ITストラテジスト試験に受かってたぞ！
ところでWikipediaを見ると、この試験に合格することで貰える報奨金に100万円(!!!!)を超える額を設定している企業が世の中にはあるらしいんですが、それってどこですか？？？？？？
私、その企業にとても行きたい！
それはさておき、今回も例によって、独学でITストラテジストに合格するための勉強法を記載する。
ちなみに、これまでの資格試験に関する記事は次のとおり。
amemiya-a.hateblo.jp
amemiya-a.hateblo.jp
前提
受験者の想定
私自身は非IT系の仕事をしており、専門のスクールにも通っていない独学受験者である。
もっぱら趣味で勉強していて、前回（2020年秋季試験）で応用情報技術者試験に合格したところ。
ただし、金融・経済・経営・会計については資格試験レベルの知識があり、仕事でも活用しているから、その点はストラテジストの受験にあたって有利に働いたと思う。
スマートドラッグで記憶力アップ。
これも例によっての紹介となるが、記憶力、短期的な集中力を増大してくれるサプリメントであるスマートドラッグの有効性は、今回の試験においても大いに発揮されたと思う。
amemiya-a.hateblo.jp
試験でカンニングしたら失格だが、こういうサプリをいくら飲んだって当然ズルにはならない。
みんなもこういうのを飲んで、他の受験生を出し抜こう。
受けた感想
IPAの高度試験は初体験で、論文をがっつり書くタイプの試験も初めてだった。
とりあえず設問で要求されている事項には答えられたが、「あんなので良かったかな？」と手応えなし。しかし、きちんと受かっていた。
それなりの読解力・文章力さえあれば、追加的なIT知識に関する勉強はそんなに無く、難易度的には応用情報かそれ以下だと感じられた（少なくとも応用情報の勉強のほうが苦労した。）。
勉強方法
ここから本題。
ITストラテジスト試験など、情報処理技術者試験の高度試験は、択一試験（午前１，午前２）と、記述試験（午後１）、論文試験（午後２）に分かれている。
従って、それぞれの試験形態に分けて、独学での勉強法を記載する。
①．択一試験（午前１，午前２）対策
ただただ過去問をやる。
以上、終わり。
この勉強法（？）については応用情報でも述べたが、高度試験でも午前試験はほとんど同じ問題の使いまわしなので、過去１０年間の過去問を暗記しておけば、問題なく合格点は取れる。現に私は８８点（25問中３問ミス）でパスした。それが６０点でいいんだよ！？
もっとも、中には新しい論点の出題もあるが（令和３年度試験でいえば、DX関係の出題など）、仮にそれら新傾向の問題を全て間違えたとしても余裕をもって合格する。だって６０点でいいんだよ！？
ただし、ITストラテジスト試験などの高度試験ともなると、有能ウェブサイトである「過去問道場」が使えない（筆者が調べた限りでは「応用情報」までしか対応していなかった）ので、過去問集を買うべき。
また、これも繰り返し言っていることだが、分厚い「テキスト」は絶対に買わないほうがいい。過去問集とその解説で十分だし、そんなテキストを読む時間があったら鬼門の午後試験のために時間を使おう。だって６０点でいいんだよ？
②．記述試験（午後１）
さて、ここから本番。
記述式となる午後試験は、さすがに過去問の繰り返しだけで受かるとは限らない。
それなりの「コツ」が必要になってくる。
ところで、同じ記述式でも、午後1（短答記述式）と午後2（論述式）の違いは、答えが１つに決まるかどうかだ。
IPAが発表している模範解答を見ればわかるように、午後1には「これしかない」という答えがある。コナン風に言わせれば「真実はいつもひとつ・・・」。
そのような１つの答えがあるということは、すなわち、問題文をきちんと読みさえすれば、必ず「それ以外に無い」という答えが特定できるということだ。
だから、問題文を精読する。
唯一の攻略法がコレなのが、ITストラテジスト試験は国語の試験だと言われる所以だ。
でも、どうやって問題文を読めば良いんだろうか？
そこにもコツがあるから、それを教えよう。
「上手くいっていないこと」が超重要。
問題文を読む時、全文をただダラダラと読むのではダメ。
というのも、問題文の中には、意味がありそうで無い「ノイズ」と、後々「答えそのもの」になる超重要箇所が混ざり合っているからだ。その重要性の違いがわかっていないと、設問を読んでから「えーっとどこかに書いてあったよな・・・」と問題文を探し回ることになり、時間がかかる。
逆にいうと、その超重要箇所がどれだかわかってさえいれば、問題文を読む効率はグッと上がるし、後々の設問にも楽勝で対応できる。だって答えが書かれている場所がわかってるんだもの。
では、その「答えそのもの」になる超重要箇所とはどこか？
ずばり、「現状で上手くいっていないこと（＝課題）」に関する記載だ。
そもそも、ITストラテジストの役割は、ビジネスにおける「課題」を発掘、分析して、それをITの力で解決するという「企画力」が求められている。
だから、試験でも「この受験生は、きちんと課題（うまくいっていないこと）を把握できる力があるか？」を確かめているんだな。
実際、ITストラテジストの試験問題（午後１本文）は、概ね次のような流れで展開する。
1.わたしはこんなビジネスしてます。
2.でも、上手くいっていないことがあります。
3.そこで、ITでこんな解決をしました。
ほとんどコレ。
そして、この問題文を受けて設定される設問において問われる箇所もだいたい決まってい。
3.の解決法に関し、
「どうしてこんな解決法が必要になったのか？」
「これによってどんな課題が解決したのか？」
「これを行ったことのメリットは何か？」
という『そもそもの課題が、きちんと把握・分析できているかどうか』に関してだ。
だから、それを見越して、最初から『課題は何か』をきっちりと把握しておけば、その後の設問にも即答できるってこと。
例えば、令和3年度試験の午後1から抜粋すると、次のような文言は「上手くいっていないこと」として注意すべき記載であり、実際に設問でも問われ、回答となった箇所だ。
「手続きが煩わしく、顧客から不満が出ている」
「入荷するまで時間がかかり、顧客、店舗とも不満がある」
「すぐに価格設定できず、販売機会を逃している」
※引用：IPA主催 【令和3年度春期 ITストラテジスト試験（ST）】
このように、問題文の中から設問（および答え）となりそうな箇所は決まっているので、そうした箇所はアンダーラインを引くなどし、とりわけ注意しながら読んでほしい。
裏を返すと、他の箇所、例えば、どんな場所でビジネスをしていて、顧客はどんな人で、これまでどんな実績をあげていて…だのという『舞台設定』みたいな話は（設問になる可能性が無いとは言わないが）相対的にあんまり重要ではないため、読む際にもそこに時間を取られてはいけない。
回答時は、問題文の用語をそのまま使うこと。
さて、ここまでで「問題文の重要そうな箇所」から、案の定、設問への回答になりそうな部分を発見することができた。
で、回答にあたっては、なるべく「問題文そのものを」書き写すということを推奨する。
裏を返すと、問題文に書いてある用語を使わず、自分の言葉で書くと不正解または減点となる可能性がある。
例えば、問題文には「卒業アルバムを作成するビジネス」と書いてあるにもかかわらず、回答時にその部分を抜き出す際には「写真集を作ること」などと書いてしまうとまずい。
令和3年度に出題されたこの設問では、学校にカメラマンを派遣する新規ビジネスについて問われているから、「写真集」では不正解に近いだろう。
もっとも、『問題文から抜き出せ』という指示でなければ、厳密に一字一句同じである必要はないが、どうしても文字数が合わないという事情でもなければ問題文に書かれている用語などはそのまま使用したほうが無難だ。
設問文もしっかり読んでね。
問題文はしっかり読むんだけど、設問は適当に読んでいる人が多い。
これは気をつけたい。
『何が問われているか』を正確に把握しなければ、そのものズバリの回答を書くことはできないからだ。
例えば、令和3年度の試験では次のような設問があった。
『中学校の保護者へのメリットのうち、写真レコメンド機能が提供するものを答えよ』
これは、この問題文で紹介された写真購入システムのうち、写真レコメンド機能に限ったメリットは何かと聞いている。
でも、設問に注意を払わないと、「写真購入システムそのもの」のメリットが聞かれているのだと誤解して、不正確な答えを書いてしまうようになっている（正確には、答えを一つに絞ることができないようになっている。）。
問題文を精読することは必要だが、そこで気を抜かず、同じくらいの注意力で設問も読むこと。後から単純な読み違いに気がつくと後悔するものだ。
③．論文試験（午後２）
これがITストラテジスト試験の最終関門であり、かなり多くの不合格の受験生が「論文が駄目で落ちた」という状況ではないだろうか。
この論文の評価は点数でなく、A～Dまでのランク付けによって行われ、このうち最高評価である「Aランク」以外の論文は全て不合格となる。だから、きちんとした対策が必要なのだが、他方で「論文はどんな対策をすればいいのかわからない」という人がかなり多いのではないだろうか。
でも、大丈夫。Aランクの論文を一発で書く方法を教えよう。
まず講評を読んでみる。
論文に模範解答はない。だから、自分の論文のどこが駄目だったのか調べる術がない。
このように、適切なフィードバックが受けられないという点が、論文試験の対策を難しくさせている大きな理由だ。
だが、試験団体（IPA）のウェブサイトには「お前達の論文見たけど、こういう点がダメだった。」という総評が公表されている。それが「講評」というものだ。
そこでは「こういう論文は落ちますよ」と、採点者の目線での辛口コメントが試験ごとに掲載されている。これを使わない手はない。
もっとも、だいたい書いてあることはどの試験でも同じで、
・設問の趣旨とは違うことを書いている。
・設問で「書け」と言われていることを書いていない。
・具体的に書けと言っているのに、全然具体的じゃない。
など、「あれが書かかれてない」「この記述が足りない」「具体的じゃない」などの「論述不足」だ。
指示されたとおりに書く。
こうした論述不足の原因は、「問題文・設問をきちんと読んでいない」ことに尽きる。
書こうと思って書けていないというより、そもそも書くべきこととして認識できていない。
言い換えると、知識や技術が不足しているというより、そもそも「指示通りにやっていない」のだ。
指示通りにやっていない──これをシステム開発に置き換えると、お客様の仕様や要件を無視したものを勝手に開発しているというわけで、たしかにそれはまずいだろう。
こうした論文の採点方法は、自由にすると採点者の主観が入り過ぎてしまうから、加点ポイントは極めてシンプルにしているはずだ。すなわち、「設問の指示通りのことが書かれていれば加点する。」。
裏を返すと、指示されたことが書かれていないってことは、他の択一試験でいえば、解答用紙を空欄で提出するのとまったく同じ行為だ。
更に、これを裏返すとつまり・・・「指示通りに書けば」受かる。
この「指示通り書く」ということ、これこそが合格ランクの論文を書く唯一の方法だ。
そして、この対策を行うのに必要なのは、IT知識などではなく、冒頭で述べたように「設問をきちんと読む力」、つまり、注意力だ。
だが、それが難しい。
わかります。なにせ、こっちは急いでいるんですからね。
論文試験である「午後２」は、１２０分という時間の中で、与えられた設問を読み解き、自分の知識や経験をもとにした論理的文章を4,000字弱も書かなければならない。
文章の構成を練ったり、自分の経験や知識をひっくり返しつつ、それなりに丁寧な文字で書き込んでいくと、この120分という時間はかなり短く感じる。
実際短いから、設問の見落としや、論述不足が多発するのだろう。俺も割とギリギリで書き上げた。
このことから、論述の攻略法は、まず、設問の内容をなるべく短い時間で「抜け・漏れ」無く把握しつつ、文章の構成を決めることだ。これを先にやる。
それを決めずに、書きながら考えてしまうから、設問で求められていること抜け落ちるし、文章自体も支離滅裂になるのだ。
が、それができりゃ苦労しねえよと皆さん思うだろう。
そこで、良い方法がある。以下に説明する「設問をそのまま論文の目次にする手法」だ。
設問を論文の目次にする手法。
この方法だと、設問で求められていることに「抜け・漏れ」が発生しないうえ、文章構成も手軽に決まってしまう。
あとは内容を書くだけという状態を速やかに作り出すことができるのだ。
やり方はとってもかんたん。
具体的に、実際にあった設問で説明しよう。
ここでは令和3年度に実施されたITストラテジスト試験の「午後２試験 問２」から抜粋する。
設問ア：あなたが携わった個別システム化構想の策定において、背景となった事業目標、事業戦略に掲げられている変革の概要、関係するステークホルダについて、業務特性とともに８００字で述べよ。
一見して、設問が入り組んでいて、何と何を書けばいいのか分かりづらい文章になっている。
このため、「書きながら考える」タイプの書き方をしていると、たいてい最後の「業務特性」なんかが抜け落ちるんだな。そして採点講評には「単なる事業内容の紹介に終始しており、その事業が持つ特色である【業務特性】について触れられていない論文が目立った」などと書かれるのだ。
こうした「抜け・漏れ」を防ぐには、書き始める【前に】、設問そのものを分解して、論文の目次とする方法が良い。
具体的には、上記の設問を見たら、メモ欄に、次のような「論文の目次」を書くことから始める。
【私が携わった個別システム化構想の策定について】
１－１．システム化の背景となった事業目標について
１－２．事業戦略に掲げられている変革の概要について
１－３．関係するステークホルダについて
１－４．業務の特性について
これは、設問の内容をまるごと移植してきた、論文の目次構成だ。
要するに、設問に沿って、先に論文の章立てを決めてしまう。
「設問をまるごと」論文の構成にするというのがポイントで、こうすることで「設問で求められていることが抜け落ちない」かつ「構成がすぐ決まる」。
これぞ一石二鳥だ。
また、このように整理することで、論文で記載されていない事も書かないで済む。
例えば、「何をどうシステム化したか」という基本的な話は、この段階ではまだ求められておらず、設問イでようやく指示があるのだが、アの時点で書いてしまうと、後で書くことが無くなってしまう状態に陥り、論文全体の構成を見直すハメになる。
このように、「何が問われているのか」をきちんと整理することは、論文作成のうえで必須なので、ぜひ身につけてほしい。
同年の出題から、例示を続けよう。
設問イ：設問アで述べたステークホルダについて、個別システム化構想案に対してどのような意見の相違があり、あなたはどのように意見を調整したか。個別システム化構想案の概要と意見の調整で工夫したこととともに、800字以上1,600字以内で具体的に述べよ。
この設問でも、論文作成者に対して求められていることが入り組んでおり、急いでいると何らかの要件が抜け落ちてしまう恐れが高い。
でも、設問をそのまま論文の目次にすれば大丈夫。具体的には次のようなメモを作る。
（アの論文の続きとして章立てする）
２－１ システム化構想案の概要について
２－２ ステークホルダとの意見の相違について
２－３ 意見の相違の調整に関し、私が工夫したことについて。
このように章立てすれば、設問をきちんと整理できるとともに、章立てもすっきり決まるんだな。
また、設問で要求されている事項ごとに目次を作ることで、要点が小分けになるから、記載内容も（何も意識していなくても）具体的になりやすいというのもこの手法のメリットだ。
ついでだから最後の設問も見てみよう。
これは、実際に自分ならばどのような目次とするか考えてみてほしい。
設問ウ：設問イで述べた意見の調整結果を反映した個別システム化構想について、経営層からどのような評価を受けたか。評価を受けてあなたが改善したこととともに、600字以上1,200字以内で具体的に述べよ。
どうでしょう？ 目次のイメージが湧くだろうか・
あくまで俺の場合だが、次のように目次を作るだろう。
３－１ 調整結果を反映した個別システム化構想について
３－２ 経営陣の評価について
３－３ 評価を受けて、私が改善したことについて
「どんな評価を受けたか」書くにあたり、まず、前の章まで書いた意見調整の結果、最終的にどのようなシステム化構想となったのか書いたほうが、次の項目に論理的につながるから、一応書いたほうが良い。
この程度であれば「趣旨と違ったことを書いた」ことにはならないだろう。
試験勉強では、目次を作る練習をする。
以上が「設問を論文の目次にする手法」の全てだ。実際に見てみると簡単でしょ？
なにせ、目次にすべきことは全部設問に書いてあるのだから、それをほぼコピペするだけで良い。
でも、試験会場で初体験はさすがにまずいから、このように目次を作成する練習はしておくこと。
ついでに余裕があれば、その目次の内容として「だいたいどんなことを書くか」という下書きを作る練習もすると良い。
例えば、今回の問題を使用すると次のとおり書ける。
１－１．システム化の背景となった事業目標について
今回、弊社がシステム化をする背景となった事業目標は、・・・を、・・・するというものである。これは、具体的には・・・を・・・することであり、弊社全体にとっても大きなプロジェクトのひとつとなっている。
１－２．事業戦略に掲げられている変革の概要について
上記の目標達成のための事業戦略として、現在の事業のプロセスを一部変革する必要があると判断された。変革の概要としては、現在、手動で行っている・・・を、個別システム化することにより、業務コストを削減することである。これにより・・・・が、・・・となり、より効率的に事業目標が達成されるものと考えられた。
１－３．関係するステークホルダについて
個別システム化するにあたってのステークホルダについては、弊社内で・・・といった事業部のほか、ユーザーとしては・・・といった者が該当した。
１－４．業務の特性について
今回の業務の特性については、他の業務とは・・・という点について特色があり、システム化をする上で配慮が必要な事項であった。
この下書きまで完成したら、次に、IPAが公表している「講評」を読む。
そこでは「業務特性についての記載が無かったり、具体性が乏しい論文があった」とか書いてあるから、自分の下書きではその点についてフォローできているかどうかをチェックする。
これが論文の練習法の全てだ。
内容の書き出しのルールも決める。
各目次における本文の書き方についてもポイントがある。
例えば「業務の特性について」という目次であれば、その内容の書き出しも「業務の特性については、」とすることを推奨する。
このように書き始めることで、目次はきっちり設問に沿っているものの、肝心の本文が全く関係ないことを書いてしまっている（ありがちな）ことが避けられるのだ。
本文の１行目には、目次に書いたことそのものズバリを書く。
２行目からは、その補足を具体的に書く。
これは「パラグラフ・ライティング」という技術そのもので、文章を書く社会人ならば身につけておくべきスキルだともされている（俺はしばしばこのブログでそれが出来ていないが・・・。）。
信じられないようだが、恐らくかなり多くの不合格論文が、「最初はそのテーマについて書こうと思っていたけど、気がついたら全然違う話になっていた」とか、その手の類ではないかと推察している。それを防止するファイアーウォールとして、「書き出し」を定式化してしまうことをおすすめする。
書く内容に困ったら問題文を読む。
目次は作ったものの、まだ学生などで、経験が乏しく、肝心の本文が全く想像できないとしよう。
実は全然大丈夫。
そういう場合のため、問題文の本文に、「思いつかなかったらこういうことを書けばいいよ。例えばね・・・」と書いてある。これは本当にそう書いてある。
例えば、令和３年度のITストラテジスト試験では、システムのステークホルダとの意見調整についてどのように工夫したかが、設問の大きなテーマとなっている。
この点、例えば目次として設定した、
２－２ ステークホルダとの意見の相違について
２－３ 意見の相違の調整に関し、私が工夫したことについて。
などは、経験がなければなかなか書きづらかったのではないだろうか。
「うーん、今まで誰かと誰かの調整したことなんかないぞ」と。
そのように困ったら、問題文を読む。
すると、「調整の例」として、次のように書いてあるではないか。
例えば、次のような調整をすることがある。
人的リソース不足に懸念を示すIT子会社に対しては、開発スケジュールを事業部門、IT子会社部門とともに見直して、IT子会社の負荷調整を図る。
これ、そっくり自分の経験としてパクって、「IT子会社を調整しました！」と書いていい。事実、俺はこれに近いことをやって、今回の試験に合格した。
このように、経験が少ない人が「詰まないように」試験側が「こんなこと書けば良いんですよ～」と教えてくれてるんだな。こんな親切なことってありますか？？
なので、未経験者でも恐れることはない。妄想を膨らませればなんだってできる。
なんでこんな方式になっているのか？
それは、ITストラテジスト試験が、「これまでの凄い体験」の順番に評価をするのではなくて、あくまで「自分ならこうする」という論理的思考力や、企画力、問題認識力を計測しているからだ。
だから、問題文にある「例」をそのまま使った妄想でも、全く問題なし。これなら事実上「書けない論文はない」。
ただし、 三好 康之氏の「情報処理教科書 プロジェクトマネージャ」という本によると、「私は全く経験がありませんが、もし私が当事者になったらと仮定して論述します」と書いたところ、不合格になったそうだ。
問題文の例をそのまま使うのも良いが、あくまで自分の体験として語ることが重要だろう。
システムのレベルは「そこそこ」でいい。
以上により、設問の要求どおりに目次を設定したうえ、どんな内容を書くかも決まった。
さて、その内容で紹介する「自分が考えた最強のシステム」は、ろくでもないもので構わない。ろくでもないものっていうか、「今更そんなものをシステム化するの？というか、まだシステム化してなかったの？」と思われるような低レベルのものでも問題ない。
事実、俺が今回の試験で書いた「システム化」も、これまで手作業でデータを持ち込んでいたことを、ウェブからアップロードできるようにしました、とかそんなモノだ（しかもでっち上げた話。）。
それでも全く問題無い。なぜか？
それは、先程も述べたように、ITストラテジストに求められるのはシステム化したもののレベルそのものではなく、そこに至るまでの企画・調整力だからだ。
どのように課題を把握し、企画し、調整してシステム化にこぎつけたか・・・システムそれ自体よりも、それ以前のことがしっかりと論述されていれば、きちんと評価されるから安心してほしい。
むしろ、それなりにまとまりのある、手頃なサイズ感の、シンプルなシステム化計画をネタとして持っておくほうがいい。そうでないと、「システム化の概要」だとか「システムの全体」だとかの論述に、やたら時間を食うからだ。
役に立つ参考書
TACの「オールインワン」を推奨する。
午前２～午後２まで、必要な知識＋試験テクニックがまとめられており、この１冊で必要十分。
この作りであれば、他の論文系試験でも同シリーズで攻略できるだろう。
今後の予定。
秋にプロジェクトマネージャを受ける予定。
