プロジェクトマネージャー試験合格への近道！合格者が実際に使った効果的な勉強法

最終更新日：2023/11/24

　プロジェクトマネージャー試験に自分自身が受験して、一発合格を果たした際のノウハウを公開します。人それぞれ勉強法というのがありますので、この通りやれば大丈夫！という訳ではないのですが、何かのキッカケになれば幸いです。

とは言え、本当に特別な事は何もしていません。ことプロジェクトマネージャー試験に関しては良書揃いです。

必読！三好康之先生著の情報処理教科書

情報処理教科書 プロジェクトマネージャ 2018年版

　私の感想として、高度情報処理試験の鬼門は午後１試験だと思っています。
　個人的に午後１試験は、この本さえ読めば大丈夫なんじゃないだろうか・・・と思えるくらい午後試験のノウハウが習得できます。むしろシステムアーキテクトなどその他の試験でもこの本が非常に有効だと感じています。

　最初は何を書いているのか、何を説明しているのかさっぱり分からない箇所も多いと思います。反復して繰り返し読むように心がけます。本が重たいのであれば、Kindle版でもいいですし、裁断してもいいと思います。

　私は過去問を印刷して、ノートに貼り付けて直接書き込んでいました。通勤中に分厚い書籍を読むのは辛いですが、ノートならさほど重たくならないので。

本は徹底的に活用する

　私は、「合格（うか）る技術」という本の中で、書籍を裁断して勉強するという方法を知り、目からウロコでした。

合格る技術

どちらかというと、書籍系は帯まで大事に保管していたい性分で、折り目などもあまりつけたくない派でした。
でも試験対策本の目的はなんでしょう？後生大事に保管することが目的ですか？試験に合格する事が目的です。と言う事は、合格するために持ち運びやすい厚さに本を裁断することも合格への手段ですし、本に思いっきり書き込む事も合格への手段です。徹底的に本を活用するという観点を養えたと思います。

試験対策本は消耗品です。合格を勝ち取るために徹底的に汚していいと思います。

午前１・午前２対策

　午前試験に関しては「過去問のヘビーローテーション」で十分です。予想問題集とかテキストを読み必要性は無いと思います。情報処理試験の午前は４割程度が過去問と同じ問題が出題されます。と言う事は、残り２割を正解すれば合格水準の６割に達する訳です。１００点満点を取る必要はなく、６割合格すれば良いだけですので、午前対策は程々にしておいて、午後対策を進める方がいいでしょう。

　過去問は繰り返し解いて、間違った所だけを繰り返し解いていきます。

プロジェクトマネージャ 午前 試験問題集 (合格精選500題)

ちなみに私は少し古い本ですが、この本を繰り返し解いていました。

プロジェクトマネジメントのイメージを掴む

　普段業務でマネージメントをしている方でもなかなか難しいのがこの試験です。実際の業務と試験で求められる内容が乖離している箇所も多いからじゃないかなぁと思う訳です。イメージを掴むために、私は漫画でイメージを掴みました。

マンガでわかるプロジェクトマネジメント

午後２対策

　論文対策です。苦手な人も多いのではないのでしょうか。まず大前提としまして、「自分自身が経験した内容」を書く必要はありません。脚色してもいいですし、妄想でもOKです。（地に足の着いた妄想ですが・・・）
　プロジェクトマネージャーにはプロジェクトマネージャーの、システムアーキテクトにはシステムアーキテクトの観点と着地点があります。同じお題でも求められる箇所が違ってきています。この辺りの視点を説明してくれている書籍が、こちら。

情報処理教科書 高度試験午後Ⅱ論述 春期・秋期

　この本を読んで、視点の捉え方を学ぶことが出来ました。書籍などでは「実際に原稿用紙に書いて感覚を養う」とありますが、私はWordに書いていました。午後２は自分の中で定型フォーマットを作ってしまうのが一番だと思います。あとはいかにそこに当てはめていくか、という鍛錬を繰り返す事となります。

終わりに

　情報処理試験は取得していても、資格がないと出来ない業務があるわけでもなく、日常業務にもあまり関係ない事が多く軽視されがちです。ただ、自己の自信とスキルアップの向上には最適な試験だと思います。これから受験される方のお役に立てれば幸いです。

【書評】世界No1プレゼン術〜聴いてもらう人にハッピーな未来が訪れる

　プレゼンテーションの神と称されるマイクロソフト社の澤 円（さわ まどか）さんが、この度自身の極意とも言えるプレゼンテーション本を出版されました。

今回出版された本

世界№１プレゼン術

澤円さん関連記事

next.rikunabi.com

　なかなか個性が爆発している面立ちの澤円さん。自身のプレゼンテーションの中でも「サラリーマンにみえない」といったフレーズでアイスブレイクのネタにもされているようです。

　実際に私も生でプレゼンテーションを拝聴する機会があったのですが、それ以来すっかりファンとなりました。澤円さんのプレゼンテーションは何処が魅力的なのか？それは聴いた側の人間に共感を与えてくれるポイントが多い事だと思います。

　早速、書籍を購入して読んだ感想をまとめてみます。

ハッピーな未来が訪れるという伝え方を

　プレゼンテーションというと、「誰かに目的のものを説明する」というイメージが強いです。画面で映している資料を紙でも配布して、それをそのまま読んで説明しているというプレゼンも多く見受けられます。これでは駄目だと書籍のなかで語られています。まず、プレゼンを聴いてもらう人たちに「共感」してもらわないといけないというのです。共感を持って話をきいてもらう事で、プレゼンの内容から何かしらのアクションを起こそうという気になります。そして聴いた内容を他人に言いふらしたくなる。つまりは、「相手にとってどんなハッピーが訪れるのか」という点を意識して話を進めなくてはいけない、と語られています。
　これは「言うは易く行うは難し」で、ひたすらに練習を繰り返して、少しずつ身につけていく技術だと私は思います。まず「人をハッピーにする」という事は「自分がハッピー」でなくてはいけない訳です。毎日が疲れ切った営業マンには酷な状態かもしれませんし、プレゼンに不慣れな初心者にはまず高いハードルです。ハッピーとかそんな次元の話ではなく、うまく話せるかとか、間違ったらどうしようとか、不安でいっぱいなんです。原稿を丸暗記しようと必死になったりするケースも多く見受けられます。ただ、おしゃべりの技術は大事ではないと仰られています。私自身もよくやる失敗ですが、話す内容が多すぎて最終的に「何が言いたいの？」という状態に陥ります。これは目指すべき目標（羅針盤）がしっかりしていないからこそ、起こりうる失敗であったと書籍を読んで痛感しました。いかなる時も目指すべき目標は「聴いてもらう人にハッピーな未来が訪れるという、ワクワクした思いを抱いてもらう事であると学びました。

立場によって考え方の視点が異なる事を意識する

　頭では理解していてもよく忘れがちになるのが、立場によってかわる物事の「感じ方」「受け止め方」です。プレゼンテーションを聴く側の人達はそれぞれ目的や思想があります。当然、話す側も分かって入るのですが、自分の中の考え方や常識で話を進めてしまうという落とし穴に陥りやすい訳です。書籍の中でエレベータを例にされていたのが大変秀逸だなと思いました。エレベータはドアの中と外では数センチの差しかありません。ですが中にいる人はドアが開くと、早く出発してほしいので「早く閉まれ」と思います。逆にこれから乗ろうとしている人は「閉まるな！」と真逆の考え方をする訳です。
　これは普段の会話でも非常に有効で、自分の考え方に固執していると立場の違う人達と衝突してしまいます。逆に、この人の立場で考えるとどう映っているんだろうと「相手の立場になって考える」と見えてくることもあります。相手の立場になって考えるという事がプレゼンテーションには必要不可欠であると再認識しました。

心に残るエンディングを

　プレゼンテーションの最後を締めくくる際にも、徹底してこだわります。終わり良ければ全て良しとは少し違いますが、終わりの印象が悪いと総評も悪くなりがちです。現に私は2017年度のMicrosoft de:codeで澤さんのプレゼンを拝聴し、最後のフレーズ「わたしたちはテクノロジで人の幸せを創るためにここにいるのですから」が強くこころに染み渡りました。

　長い間忘れ去っていた感情を思い出させて貰えたと同時に、大変救われた気持ちでいっぱいです。あの最後のフレーズがあったからこそ、澤さんのプレゼンテーションの内容を色濃く記憶に留めていることが出来ていると思います。「プレゼントは、時間と空間を共有する」まさに一期一会の精神です。聴いてもらう人にハッピーな未来が訪れるという想いを持ってもらうためにも、「心に残るエンディング」をしっかり準備しないと駄目だと感じました。

最後に

　本の一部のフレーズに対して自分の感想なりを述べさせて頂きましたが、まだまだ素晴らしい考え方が満載です。この本は長く手元においておきたいと考えて今回はKindle版ではなく書籍で購入しましたが、紙質も良くさわり心地も良いです。

書籍版

マイクロソフト伝説マネジャーの 世界№1プレゼン術

関連書籍

外資系エリートのシンプルな伝え方　仕事が５倍加速するコミュニケーションの技術 (中経出版)

　プレゼンテーションのみならず、何かしら人間関係に疲れたなーとか、仕事が嫌だなーとかいう時にも効果はあると思います。結構メンタル的な部分の見直しでも澤さんの考え方は私を助けてくれています。プレゼンテーションをする・しないに限らず一度は読んでみて欲しいなぁと思う一冊です。ブロガーさんにもお勧めできる本だと私は思います。何故ならブロガーさんの多くが「自分の知識が誰かの役に立てばうれしい」という具合に、人をハッピーにする為に記事を書かれていると思うからです。といいつつ、私が既に澤さんの書籍を読んで、共感した末、アクションを起こしたくなり、内容を他人に言いふらしたくなるといった「澤さんのプレゼン大成功！」にまんまとハマっているんですけどね！

【de:code2017】「変わらない開発現場」を変えていくと決めた瞬間

今年もMicrosoft de:codeに参加しました！

de:code（デ・コード）とは

マイクロソフト テクノロジのビジョンと、「クラウド」「モバイル」を最大限に活かせる最新テクノロジをすべてのITエンジニアの皆様にご紹介するイベント

『変わらない開発現場』はツボ過ぎる

昨年度のde:codeでは直接セッションを受けていなかったので、今年は先陣切って日本マイクロソフト株式会社 赤間信幸さんのセッション『変わらない開発現場』を変えていくために〜エンプラ系レガシー SIer のための DevOps 再入門〜を受講しました。

昨年度の内容はこの記事に想いを込めています。
shin21.hatenablog.com

SIerに欠けている「技術を熟知したアーキテクチャー」

SIerから協力会社へ開発を依頼する際に、軸となるアーキテクトに関してはSIer側のプロパーが押さえておくべきであり、そこは右から左へ流すモノでは無いという事に関しては、全くの同意見です。
中でどういう仕組みで動いているかも分からない、ブラックボックス的な代物をそのままお客様へ提供する事例もありました。大抵は後々揉めています。

ただ、大抵はプロパー側で進捗管理はしても、内部の技術部分は「おまかせ！」っていう形も多い訳です。
何故ならば、「アーキテクチャー」というキャリアパスが準備されている企業はまだまだ少ないといえるからです。

SIerのキャリアパスっていうと、大抵はプログラマーとして入社しても、仕様設計が出来るようになるとSEというポジションに昇格され、プログラムを組むという機会がだんだん少なくなります。じゃあプログラムは誰がするのか、というと外注業者さんに依頼して、管理側に回る（回らされる）事が多いです。現に私の会社でもそうです。

でも、中には最新技術を追いかけていたい、管理職なんて興味が無いという人たちもいます。そういった人たちの会社にいる居場所が少ない、というジレンマを取り上げられていました。
本当はその会社にいたいけれど、居場所が無い人たちは新天地を求めて会社を去ります。会社側も優秀な人員が離職し痛手を負います。双方不幸ですよね、と。悲しきすれ違いです。

継続的インテグレーションの目的は「ビルドの可視化」

継続的インテグレーションは自動ビルドを行い、自動デプロイする一連の自動処理です。
ビルドを自動化してどうするの？と言うことです。私自身もそう思っていました。

ビルドを自動化するのが目的では無く、そこから取得できる計数データや何件ビルドした、どれくらいソースを修正したという変更情報を取得し、それをグラフ化する事により、「自分の直感を客観的にとらえる」という事が目的である。

目から鱗とはこの事かと。真なる目的を知らずに目先の単語に惑わされていたようです。

近代的なプロマネは「サーバントリーダーシップ」

上の人が下の人にあれこれ指示を出し、下手すれば奴隷のごとく扱うかつてのプロマネのイメージとは真逆で、下の人たちが働きやすいように上の人が色々と調整し、メンバーのやる気やモラールを引き出す事が重要である、という事です。

トップダウンがかつてのシステム開発におけるイメージですが、ボトムアップも上手く取り入れることで、マネージャーの管理工数の負荷を減らし、皆が幸せに働ける道筋を作るという事がプロマネに求められていると感じました。

さいごに

今の環境に嘆くのでは無く、自分で出来ることを考えて、小さな事からコツコツと変えていく必要があります。

今回記事の中で触れていませんが、他にも色々と考えさせられる内容でしたので、画像でご紹介しておきます。

Visual Studioを使用中に「SQL Serverは動作を停止しました」が頻繁に発生する場合の対処法

特定の環境でVisual Studio 2015 または 2017 を使用していると、「sqlservr.exeは動作を停止しました」というメッセージボックスが頻繁に発生します。

現に私もこの現象に悩まされていました。一回一回のメッセージ表示は何ともないのですが、定期的に絶えず表示されるため、イライラが募るわけです。精神衛生上宜しくない。

原因はSQL Server Local Db

Visual Studioインストール時におそらくSQL Server Local Dbも一緒にインストールされているのですが、古いバージョンのLocal Dbがこのメッセージボックスの原因でした。

実際にSQL Server 2016 Express LocalDB に更新すると、今までのメッセージボックスが嘘のように、現象は回避されました。

ダウンロード

SQL Server 2016 Express LocalDB
Download Microsoft® SQL Server® 2016 Service Pack 1 Express from Official Microsoft Download Center

インストール手順

下記のサイト様が大変判りやすく記載されています。

www.hiskip.com

自分の備忘録を兼ねて。。。

sqlservr.exe has stopped working

AutoMapper6でのプロファイル設定とユニットテスト

AutoMapperという自動マッピングライブラリーが便利なのです。ただ、少しばかり使い方を誤っていたようで、下記のサイトを参考に再勉強させて頂きました。

iyemon018.hatenablog.com

この記事のお陰で、今までの自分があまりにも恩恵を受けない無駄な記載をいっぱいしていたという事に気づきました。例えば、逆マッピングもわざわざ定義を書いていたとか、同じ名前のオブジェクトもわざわざ定義書いていたりだとか・・・。

いざ自分でも定義をプロファイル単位にしようと試していたのですが、どうも仕様が違っている様子・・・。
最新のAutoMapperは6.0.2になっており、プロファイルのオーバーライド辺りが変更になっていたようです。ですので、自分の備忘録も兼ねて手順を記載します。

マッピングの定義

以前のAutoMapperでは、Configure()メソッドをオーバーライドして定義を書いていましたが、バージョン６以降は互換がなくなったようで、コンストラクターに定義を記載する事になります。

public class HogeProfile : Profile
{
    // コンストラクターでマッピング定義を記載します
    public HogeProfile()
    {
        CreateMap<SourceClass, DestinationClass>()
            .ForMember(d => d.XXXXXXXXXX, o => o.MapFrom(s => s.YYYYYYYYYY))
            .ReverseMap()
            .ForMember(s => s.XXXXXXXXXX, o => o.MapFrom(d => d.YYYYYYYYYY))
            ;
    }
}

上記のように、必要な定義ごとにクラスを分ける方が管理しやすくて良いと思います。以前一つのクラスの中に定義をまとめて書いていたのですが、数が多くなると判りにくくて仕方が無いという経験からの意見です。

作成したプロファイル設定は、ASP.NET MVCであればGlobal.asaxなどに呼び出しの記述を行います。

Mapper.Initialize(config =>
    {
        config.AddProfile<HogeProfile >();
        config.AddProfile<HogeHogeProfile>();
    });

// マッピング設定の検証
Mapper.AssertConfigurationIsValid();

マッピングのユニットテスト

基本的にそのまま値の受け渡しが行われるので、ユニットテストは不要という考えもできます。
但し、型が違うことによりAutoMapperで変換をかけたり、固定値を入れたりなど絶対不要か、といえばそうでも無いと思います。ユニットテストを書く癖をつけるためにも書いてみました。

簡単ですが、MSTestで書いたテストクラスはこんな感じです。

[TestClass()]
public class HogeProfileTests
{
    [ClassInitialize]
    public static void ClassInit(TestContext context)
    {
        Mapper.Initialize(config =>
        {
            // Global.asaxの呼び出し代わりにClassInitializeでプロファイルを呼び出しておく
            config.AddProfile<HogeProfile>(); 
        }); 
    }

    [TestMethod()]
    public void マッピング設定の検証()
    {
        // マッピングエラーならException
        Mapper.AssertConfigurationIsValid();
    }

    [TestMethod()]
    public void コピー元からコピー先へのマッピング検証()
    {
        var srcModel = new SourceClass()
        {
            // コピー元の値を適当に設定
        };

        var destModel = Mapper.Map<DestinationClass>(srcModel);

        // コピー元とコピー先で値が同じか
        Assert.AreEqual(destModel.xxxxxx, srcModel.xxxxxx); 

　　　　//以下・・・省略
    
    }


    [TestMethod()]
    public void コピー先からコピー元への逆マッピング検証()
    {
        var destModel = new DestinationClass()
        {
            // コピー先の値を適当に設定
        };

        var srcModel = Mapper.Map<SourceClass>(destModel);

        // コピー元とコピー先で値が同じか
        Assert.AreEqual(srcModel.CategoryId, destModel.CategoryId);

        //以下・・・省略

    }
}

名前や型が同じプロパティー部分は比較検証しなくてもいいかな、というのが率直な感想です。
AutoMapperで何かしらのマッピング定義を施した箇所を中心にテストを作成するのが合理的だと思います。