情報処理試験の最難関と言われるITストラテジストに勉強時間をとらずに合格しました。
・・・という「勉強なし」の部分はかなりの誇大広告気味で、
ITストラテジスト専用の勉強時間をとらずに合格したよ。という意味です。
実際は他のことで勉強になっています。学問に王様のための道は存在しないのです。
この記事では主に午後２の論文試験について書きたいと思います。
特にITC(ITコーディネーター)が今回の合格のキーになっており、
万人向けの再現性はないかもしれませんが、同じようなケースの方への参考になればと思います。
なぜ資格とろうとしたか
もともとステップアップとして戦略層の資格をとろうとしていました。
その際、色々調べていたら中小企業診断士とITストラテジストがよく比較されていて、社会的には中小企業診断士のほうが価値が高そうだったのでそちらを取得しました。
が、いざ経営やコンサルタントの世界に足を踏み入れてみるとDX化需要でITコンサルタントの需要が高いことがわかりました。
ITコンサルタントと名乗るからにはITストラテジストくらいとっておかないと、という浅い理由で受験しました。
試験に貢献したと思われる周辺資格
上記のような浅い理由なので、そこまで勉強時間を確保するつもりはなかったのですが。
午後1までは他情報処理試験の合格実績があるのでなんとかなるだろの精神でとりあえず申し込みしました。
関連している資格は以下です。
- 午前1
各種情報処理試験 - 午前2
中小企業診断士 - 午後1
ほかの高度情報試験もそうですけど、記述回答っていっても与件文からの抜き出しなので午前1,2くらいの知識があれば後は現代文の試験な気がしてるんですけどどうですかね？
どの高度情報試験も午後1のクセ(自分で考えて記述というよりは与件文からの抜き出し重視するのと、抜き出す際に午前2の知識を使った視点を使う)を抑えてれば、午後1用の勉強はあまりいらない気がします。 - 午後2
プロジェクトマネージャー試験
ITコーディネーター
論文試験
やはり高度情報処理試験のネックは論文試験だと思います。
個人的には論文なし高度情報試験と論文あり高度情報試験でレベルの位置づけを変えていいんじゃないかと思っているくらい難易度が変わってきます。
さらに論文を記載する前に質問シートも書く必要あります。
対象の企業概要などを記載するのですが、具体的数値を書いたりする部分があるので存在を忘れてると結構焦ると思います。
論文の組み立て方
高度情報処理試験の論文は2時間で3000字弱ほどの小論文を記載する必要があります。
まずは論文の組み立てという戦略が必要です。
これはどの高度情報処理試験でも共通なので一度ほかの試験を受験していれば共通の戦略で大丈夫です。
ここら辺は他の方もたくさん書いていると思うので読みたい方だけ
論文は問ア、イ、ウに分かれており、概ね以下を書く形になります。
- ア、事業背景と事業戦略を事業特性を踏まえて(800字以内)
- イ、アにたいして具体的にどのような〇〇〇をしたか (800～1600字)
(〇〇〇は具体的な計画や実行部分。ビジネスモデルであったり、システム検討、計画や事業戦略に対する個別戦略など） - ウ、元の戦略との乖離や。顧客の評価、指摘、改善点(600～1200字)
個人的なタイムスケジュールとしては以下ですがあんまり気にしないほうがいいです。
特にプロット作成の時間がオーバーしたからと言って、論文記述に移るのはNGです。
あらかじめプロットに時間を多く計画しておくかバッファをいきなりそこに使うかしてでもプロット作成をしっかりやりましょう。
| 時間 | |
|---|---|
| 5分 | 問題確認・質問回答 |
| 25分 | プロットの作成 |
| 20分 | 設問ア |
| 35分 | 設問イ |
| 25分 | 設問ウ |
| 10分 | バッファ |
プロット作成のポイントは二つ
- 結局この論文は何が言いたいの？を一言でまず書く
- 設問でいわれていることをそのまま登場させる
この論文は何が言いたいの？を自分で持つ
プロットはWBSの形で組み立てていくことになるのですが
WBSを組み立てる際に設問順に書いていくのではなく、概要から詳細へ書いていく感じです
ア、背景と事業概要と事業戦略
├ 背景
│ └インテリア会社で、各地に事業所があり～・・・
│ └部門：セグメンテーションかしており～・・・
↓ ├
のように設問順に組み立てるのではなく
でっかいストーリー：既存ビジネスで行き詰ったインテリア会社がIT活用で提案システム作ってCX(顧客体験)あげた
と、アホっぽくてもいいのででっかいストーリーを決めてから
3行で細分化してから
既存ビジネスで行き詰ったインテリア会社がIT活用で提案システム作ってCX(顧客体験)あげた
→
- 既存のビジネスのデータを使えてない
- データ活用して新システムつくった
- 現場の意見と調整した
それをさらに細分化して、ア、イ、ウへの割り当てはそのあとでつじつまを合わせたほうがいいと思います。
深さ優先じゃなくて幅優先な感じです。
さらにいうとイのストーリーを先に考えてから、アはそれにあうような背景を用意したほうがいいです。
アの章は導入と伏線をばらまく役割の章だととらえ、イですべてを回収しなくてはいけないので先にイをソリューション考えてからそのソリューションの課題となる伏線をアに仕込む感じにしましょう。
ウは最終調整です。「評価」というのが「めっちゃ褒められた」って書いてうかったら苦労しないので、
「良かったけど、もっとこうしたらいいね」を仕込む形になります。
かといって、あまりに無策で書くと「それってイのフェーズで対策できなかったの？」って話になるので、現場固有の事情やクライアントの好みの事情、またはプロジェクト途中に状況が変わりそれへの柔軟な対応をしたとか
「やってみてからわかる問題」「触ってもらわないとわからない要望」「不確実性への対応」
一言でいうとリスクとそれが顕在化した時の対応を仕込む感じです。
設問でいわれていることをそのまま登場させる
設問は与件文と設問で構成されています。
与件文には「DXといえばこうだよねー」とか「こんな事例があるよ」という紹介文のようなものにとどまっており、
午後2の論文を書く上では基本的には自分の経験を書くので与件文は全く読まなくても論文を書けるように見えます。
が、基本的に題意に沿うために与件文に登場した例はそのまま使うべきだと思います。
「ITで新たな顧客接点や魅力的な顧客体験を実現」と例で書いてあったら、自分が書く論文のテーマもそれにアジャストさせていきます。
しかし、そうなると様々なパターンで論文を書けるようになっている必要があり、自分の実際の体験だけでは対応しきれないところがでてくるかもしれません。
また、ウなどを書くときに様々なリスクなどのパターンの引き出しを自分の中に持っておく必要があります。
論文のテーマ
前述のように自分の体験の数パターンではお題の与件文に対応できない可能性があるので、
本来であればここにかなりの勉強時間を割きます。
プロジェクトマネージャー試験を受験した時は1～2か月ほどここに勉強時間を割き以下のようなことを行いました。
- サンプル論文の読み込み
- 自分の事例や体験、あるいは想定を元にプロットを数種類用意
- 用意したプロットに対して実際の試験問題を見てカスタマイズして論文が書けるかの練習
等
しかし今回は勉強時間を確保しません/できませんでした。
ITCケース研修
ここで周辺資格のITコーディネータが登場します。
ITコーディネーターにはケース研修というものがあり、概ね以下のステップを踏みます
https://itc-shikaku.itc.or.jp/case/
- 経営視点での変革構想の検討
- ヒヤリング(の結果があるのでその分析)
- 現状分析
- 気づきの抽出
- 課題抽出
- あるべき姿の検討
- ソリューションの方向性(具体ソリューションではなく経営課題に対しての解決策)
- ビジョンやビジネスモデル
- 変革構想を受けての経営戦略の策定・実行
- 経営戦略から組織戦略への分解
- 業務改革プロセスとIT戦略プロセスとの分解
- 現状業務/現状IT状態との不足点の改善点
- IT導入の具体的な実現手段、調達、スケジュール、リスクの検討や
- 戦略の効果に対するKPI/KGIの設定
- IT導入後の評価や問題発生時のハンドル
- 利活用に対するKPI/KGIの設定
- 次期変革に生かすためのフィードバック
と想定企業に対して経営戦略、IT戦略、IT利活用の検討を行っていきます。
もう、ほぼ論文のストーリーにそのまま使ってもいいくらいです。
経営戦略がITのソリューションありきの視点になってはいけない
基本的にエンジニアからステップアップしてきた人は
思考がソリューションを中心に組み立てられがちになると思います。
しかし実際にはBizDevOpsというか、ビジネスと利活用と開発がそれぞれリンクしていなければなりません。
すばらしいITシステムを使うために戦略を立てるのではなくて、
最初に見つけた経営課題を解決するためにIT導入を行うのです。
ですので、論文のウの「評価」もV＆Vが必要です。
システムがうまく動いたかの評価(Verifcation:検証評価)だけでなく、もともとの戦略を解決できているかの評価(Validation：妥当性評価)が必要です。
イメージは以下の通りです
その点ケース研修はソリューションありきではなく、経営変革から経営戦略、組織戦略と降りてきてからようやくIT戦略を設定しITソリューションを検討します。
ITストラテジストは素晴らしいITシステム構想を発明する役割ではなく、戦略に適合したIT導入を行う役割なので、
引き出しに必要なのは技術シーズのバリエーションというよりは、問題に対する課題設定と課題に適合するソリューションの方向性の設定、そしてそのV＆Vをきちんと検討できるかになってきます。
その視点が少なくてすこし自信がないなぁという方でもITCケース研修はグループワークで研修を行うためグループ内の他メンバから、あるいは他グループからも引き出しのネタを提供してもらえます。
さらに、講師がダメ出し/指摘までくれるとなれば論文の校正までしてくれているようなものです。
まとめ
ITストラテジストなどの論文は時間をかけて「受験勉強」をすることでも当然合格はできると思います。
しかしながら、ほかの資格試験にも言えることですが試験合格後の実践を意識して勉強をしないとそのあとの身にもならないと思います。
そういう意味でITCのケース研修は実企業への経営戦略/IT戦略を想定して行う研修なので、ちゃんと研修を受ければ実戦でもそのまま使える研修となっており、
今回は「ITストラテジスト資格勉強の確認テスト」よりも「ITストラテジスト実践テスト」の意味合いになっていたんじゃないかと思います。
ただもちろん補足しておくと、ITCのケース研修が万能だよと言っているわけではありません。
ITCのケース研修も同じで正直漫然と時間を過ごしてもパスすることができます。
やはりこちらも実務を想像しながら検討したり、このようにITストラテジストのような周辺の試験のネタ作りを想定したりすることで
イメージがつきやすくなることによりケース研修の検討の密度も濃くなると思います。