ITストラテジスト午後2 論文の書き方・論文対策方法 何気ない業務をITストラテジストの論文に！！
論文のモジュール作成の重要性に触れました(こちら)が、論文を書いたことがない人にとっては何の事だかわからないと思います。私も同様で、最初はどうやって論文を書いていいのかわかりませんでしたし、論文を書けるようになる気がしませんでした。
そこで、私がどうやって合格基準を満足する論文を書けるようになったのか具体的に説明していきたいと思います。
■論文を書けるようになるまで
私が論文を書けるようになるまでに、以下のステップを踏んできました。
・午後Ⅱで求められていることを理解する。
・論文に書くためのネタを見つける。
・ネタを基にストーリーを作る。
・ストーリーを分解しモジュール化する。
もちろん試行錯誤を重ねて、遠回りもしてきた結果、振り返って、このステップが必要であると判断しています。
■午後Ⅱで求められていることを理解する。
最初は、「午後Ⅱを知る」です。
「経営とITを結びつける戦略家」
と定義されており、
「高度IT人材として確立した専門分野をもち、企業の経営戦略に基づいて、ビジネスモデルや企業活動における特定のプロセスについて、情報技術を活用して改革・高度化・最適化するための基本戦略を策定・提案・推進する者。また、組込みシステムの企画及び開発を統括し、新たな価値を実現するための基本戦略を策定・提案・推進する者」
と説明されています。
簡単に言うと
「何らかの業務を」（＝ビジネスモデルや企業活動における特定のプロセス）
「ITを使って」（＝情報技術を活用して）
「よくするための」（＝改革・高度化・最適化するための）
「業務を行っている人」（＝基本戦略を策定・提案・推進する者）
です。
午後Ⅱの論文は、あなたは上記のような人物ですかと問われています。
このような視点をもって、論文を作成していきましょう。
■午後Ⅱの設問を理解する。
さて、実際に午後Ⅱを分析していきましょう。
よく問われる論文の基本的な内容は、
設問ア
・事業概要・特性
・事業の課題や背景
設問イ
・検討内容
・実施内容
・工夫した点、重視した点
設問ウ
・提案方法
・評価
・改善点
が多いです。
簡単にいうと
・設問ア＝なぜこのプロジェクトをやるのか。
・設問イ＝どういうことをするのか、検討したのか。
・設問ウ＝プロジェクトはどうだったのか。
を論述します。
これがITストラテジストの午後Ⅱです。
当たり前の話ですが、私は、この設問で問われていることを常に意識していました。
これが理解できていないと論文は書けません。書けたとしても不合格論文になると思っています。
■論文に書くためのネタを見つける。
次は、論文に書くネタ集めです。
【結論】ネタ集めの方法
自分の取り組んでいる（または取り組んだ）業務をネタにしましょう。
自分の業務をITストラテジスト視点で表現すれば十分です。
どう表現すれば、ITストラテジストの論文のネタになるのか考えていきましょう。
ITストラテジストのような業務経験がないので論文が書けないと思われている方が多くいらっしゃいます。
論文対策開始当初は、私も同様の考えを持っており、(IT戦略系部門に所属していましたが)ITストラテジストの論文にかけるようなネタは自分の業務の中にないと思い、参考書が取り上げているネタを使っていました。
しかし、うまく論文が書けませんでした。
その原因は、自分の言葉で論述できないからだと思っています。
参考書のネタをもとに対策すれば、対策した問題の論文は書けるようになるかもしれませんが、問題が異なると書けなくなるのではないでしょうか。
そこで、私は上記「ネタ集めの方法」の考え方の通り、自分の業務を見直しました。
午後Ⅱで問われていることを意識して業務を見直すと意外に見つかるものです。
例えば、簡単な業務改善を行ったとか、なんらかの目的のために業務の役割を変更をしたとか、お客様から感謝される仕事をしたとか。
まったくITが関わっていない業務は、ITストラテジストとしての論文にならないかもしれませんが、ITが少しでも絡んでいれば十分です。
例えば、メールを利用しただけでも大丈夫です。（実際、私は本番試験でメール配信を想定した情報共有施策を論文に記述して合格しました。）
【具体例】
私が用意した論文のネタ集めのプロセスを紹介します。
私はサービス業に勤めていて、私の会社では正社員がお客様にサービス提供している業務がありました。
私はそれを契約社員が業務を行うことにしました。
見栄えよく表現すると「業務改革を行い、コスト競争力を向上させた」です。
正直に書くと「正社員を派遣社員に変えた」だけです。
これでも十分にネタになります。
本当に何もしたことがないと言う方は、こういうことをしたいなどを具体的にイメージしてみてください。
※業務経験の少ない方は参考書などの例文や経営者が執筆している書籍からネタを集める方法しかとれないかもしれません。ここでは、自分の業務をいかにITストラテジスト試験用の論文に仕上げていくかを説明していきますのでご了承ください。
■ネタを基にストーリーを作る。
ここからは問われている内容：設問ア～ウにあわせて、ネタをストーリーに変えていきます。
・設問ア＝なぜこのプロジェクトをやるのか。
【結論】設問アのストーリー
事業概要（昔は良かった）
↓
背景（最近調子悪い）
↓
プロジェクトの目的（調子悪いところを解決するぞ）
というストーリーを意識しましょう。
さて、具体的に説明していきます。
ここでも、私の「正社員の業務を派遣社員の業務に変えた話」を具体例として説明していきます。
企業の活動の目的は2つのUPだけ。極論を言えば、これを背景にすれば、設問アはどうにでも書けます。
【2つのUP】
○売上UP
○業務効率UP（コスト削減）
つまり、利益（＝売上－コスト）を上げることです。
事業概要では、 2つのUPを中心に記述します。
事業概要はポジティブなことを書くことをお勧めします。
例えば、
○売上UP
高品質なサービスを武器に売り上げを伸ばし、
業界トップクラスのシェアを占める。
○業務効率UP
社員教育制度により、社員の業務効率は高く、
社員教育制度は、業界内外から注目を集めている。
などです。
背景では、事業概要で説明した2つのUPが悪化しているということを書きます。
○売上UP
社員が顧客対応に追われ、欠品などが発生している。
社員が十分に顧客対応できていない。
競合他社が追随してきて売上が伸び悩んでいる。
○業務効率UP
人件費の高騰で利益を圧迫している。
これらを背景とします。
お気づきかと思いますが、背景は一般的なことで十分です。
会社が直面している問題は、大凡似ているものです。
（もちろん、問題の原因は多様なので解決策も多様になります。）
上述の背景により、プロジェクトが開始されます。
具体的に正社員の業務を派遣社員の業務に変えた理由を考えていきましょう。
○売上UP
サービス、品質UPによる他社と差別化で、売上UPにつなげる。
※実際の論文ではもう少しわかりやすく丁寧に表現します。
正社員の時間が確保できるため、波及効果などが書きやすい。
○業務効率UP
一般的に派遣社員は正社員より給与が低いです。つまり、
人件費削減によるコスト削減です。
※一般的に派遣社員は、正社員と比較し、品質が低いため、
マイナス面をどう克服するかなどの話がしやすくなります。
これをプロジェクトの目的にします。
・設問イ＝どういうことをするのか、検討したのか。
【結論】設問イのストーリー
こういうプラス面があるので、こういうことを検討しました。
↓
こういうマイナス面があるので、こういうことを工夫しました。
というストーリーを意識しましょう。
設問イでは実施内容を具体的に説明していきますが、設問イで最も重要なことは、施策を実施した時の影響（主にマイナス面）を改善する対策（つまり、工夫！！）について記述することです。これがITストラテジストとしても腕の見せ所です。何かを変えるときに目的だけきれいに達成できることはありませんからね。
プラス面やマイナス面を整理する観点は問題文を参考にしましょう。
さて、具体例に移ります。
－検討内容
①サービス・品質向上のため、人員を投入する。
②コスト増を抑えるため、派遣社員をお客様が多い時間帯に集中して投入する。
結果、派遣社員はサービスに集中できる。加えて、正社員はマネジメント業務に専
念できるようになり、他の業務の品質も向上する。
③品質低下を抑えるため、派遣社員の教育方法を確立する。
－実施内容
①派遣社員の投入。
具体的には土日、平日の夕方の時間帯に投入
②正社員と派遣社員の業務を定義する体制を策定。
具体的には担当コーナーそれぞれに1人の社員と複数の派遣社員をつける体制
③自社ノウハウを活用して、派遣社員の教育制度の策定。
具体的には派遣社員が間違えやすいものにFAQ作成。（情報は各派遣社員から収
集する。作成の段階から派遣社員が入る）
－工夫した点
工夫した点は実施内容に含ませたほうが書きやすい。
例えば、効率化するために派遣社員を投入する時間帯を絞ったことや派遣社員にFAQ
を作成し、現場の視点を意識した等です。
・設問ウ＝どう評価されたのか。
【結論】設問ウのストーリー
誰に、どのように提案した。
↓
提案内容が認められて、実行されました。
↓
現場の皆様の協力もあり、こんないい効果がでました。
↓
でも、こんな改善点があります。それについては、今後、このような対策を実施します。
というストーリーを意識しましょう。
提案方法や評価はモジュール化しやすく、参考書で紹介されている定型文を用意するだけで対策できます。なぜなら、提案方法は提案内容によって変わらないし、評価は良いと書かないと提案内容が実行されることはないからです。（実行されなければ、次に問われている改善点も出てこないから論文に書けない。）ここだけは、参考書の文章をほぼそのまま引用しても問題ないと思います。
改善点はITストラテジスト的な書き方ができます。実施したプロジェクトによって、できるようになったことや当初想定していなかったことを書くとよいです。
さて、具体的な話に移ります。
－提案方法
費用対効果の測定や定性的な効果を経営陣に説明したなど。
－評価
私の提案は評価され、中期経営計画に組み込まれ、実行された。想定した効果を達成
しており、期待通りの結果だったといえるなど。
－改善点
①当初は適正な量であったFAQが次第に膨大、複雑になり、整理が必要になった。
②派遣社員を投入したことにより、以前よりお客様の声が収集できるようになった。
そのため、商品開発部への情報展開を検討する。
②のような新たな取り組みにつながることを記述するとGood！！
以上で各設問のストーリーの説明を終わります。
ここからは応用編です。
■ストーリーを分解しモジュール化する。
これは応用編であるため、必須ではありません。ただ、モジュール化ができれば、論述の幅が広がるため、問題の内容が多少変わったとしても、論述できるようになります。
モジュール化の手順は以下の通りです。
①ストーリーを複数作成する。（ネタを用意する）
②設問単位で論文を区切る。（これがモジュール！！）
③モジュール間をつなぐ文章を作成する。
図にすると下記のようなイメージです。
最終的にはモジュールを自由に組み合わせてストーリーを作れるようになること、そして、その種類、数が増えていくとどんな問題にも対応できます。（どんな問題にもというのは言い過ぎですが・・・）図でいうと通常は実線のストーリーを書いて、問題にあわせて破線のストーリーを書くイメージです。
モジュール化手順の詳細についは、改めてまとめます。
（・・・まとめるの難しいです。）
（2016/09/02 読みにくかったため、修正しました。読みにくい文章ですみません。）
（2016/09/20 何度読んでも読みにくかったため、また修正しました。わからないところがあれば、コメントください。）
