全般的に、推敲していないので誤字や字余り生じています。

事例2
最初に図表1の各項目の変動を計算した。
人口は変化なしで、一人当たり消費量が25%減、リットルでは32%くらい減少。
図表2によると醤油は減っているが加工品は伸びている。ということは醤油から料理をするのではなく、加工品を使って料理することが増えているということになる。

第1問
長い歴史と、自社での仕込みによる深い味わいによるブランド価値を活かした高品質、高価格なニッチを狙った差別化戦略。

第2問
設問1
x市内外の健康志向の女性、シニア層を対象にしょうゆ加工品を販売する。特に、新規顧客獲得のためにブランドの知名度だけではなく、商品を味わう機会の創出を行っていく必要がある。

設問2
地元飲食店や、全国展開するファミリーレストランなどに健康的なレシピとセットで売り込みを行う。あわせて店頭でドレッシング等を販売してもらうよう依頼する。

第3問
最終消費者から直接レスポンスをもらえる接点となっている。商品にあったレシピなどマーケティング素材の開発の拠点となりうる。また、直接的に知名度アップの効果も生じている。

第4問

設問1
ブランド価値やz社との協力関係を維持するため、値引き販売は行わない。必要に応じてネット専売品を開発する。

設問2
購入された商品が消費し終わであろうタイミングで商品やその定期購読を提案するメールを送る。直営飲食店のヘルシーなレシピなどを継続的に更新し続けてホームページへの訪問頻度を高く保つことですロイヤルティを高める。





誤字や字余りがあると思いますがともかくアップロードしみす。

事例1

第1問

設問1
学校アルバム事業で蓄積してきた高度な印刷技術と社員教育で高めた企画力、デザイン力が活かせたため。

設問2
印刷技術や企画力、デザイン力といったA社の強みが生かされない事業だったため、他社と比較した時の優位性がなく差別化できていなかった。また、本業とのシナジー効果も薄かった。
第2問

設問1
学校関係者を相手に営業を行っていた学校アルバム事業と異なり、エンドユーザ向けとなるため、製造、企画、営業のコミュニケーションが重要となる。コミュニケーション円滑化のためローテーションや部署間の連絡会議、交流会などを設けることを提案する。

(事後追記:ユーザの要求の変化に柔軟に対応する必要があるため、各組織間の連携が重要になる、という説明が抜けてしまった)

設問2
定型的な作業が主となる学校アルバム事業と異なり、それぞれに異なる難易度や業務ピークを持つ事業を行うため、人的リソースを共用する必要が生じるため。

第3問
多彩な事業を行うため、担当する業務により評価に不満を持たれないような一貫性を持った評価の仕組みが必要である。また、新たなことにチャレンジすることに表彰や報酬で応える仕組みを設けて風土を変えていく。
午前II 76
午後I 70
午後II A
でした。午前1は免除です。
午後Iについて、思ったよりもかなり拾ってくれたイメージ。マニュアルではなく、本文中に無いFAQと書いたのは多分点もらえてるし、リスク要因を聞いてる問題も丸だったのでは無いかな。各社模範解答ではみんなリスクを答えてたので外したと思っていたが。

ともかくよかった。
TACの速報で午後1採点。

2,7,0,0,7,8,0

0,6,6,7,0,0,6,0
大甘で見て24点、25点で合計49点。
これは午後1敗退だね。論文書けただけに残念。
特に設問1は後から直して不合格にしてしまった。




アイテックの回答で採点。
配点はTACのもの。
0,7,0,0,7,7,0
0,6,6,7,3,6,6,0
大甘で合計55点。うーむ。

午前問題に関してはIPAより回答が発表になっています。

http://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2016h28.html


午前IIに関してはこちら。

http://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2016h28_1/2016h28h_pm_am2_ans.pdf

採点したところ18/25で72点。問題なし。

事前にやったのは過去問2年分だが、問10、問11は過去問で出た問題。

問10は答え覚えていたにもかかわらず計算式で週単位の計算できず時間がやたらかかった。ペース上げたので最後10分程度残ったが。

テストの際に自信があるものには○、微妙なものに△、だめだろうと言うものに×をつけるようにしているが、今回は

○14

△8

×3

だった。

多分誤字脱字が多いと思いますが直すのが面倒なので一旦アップ。

問1は25分で完答。やたら自信マンマンだったが後で見たらぼろぼろでラスト20分かけて修正した。

問2は答えが質問に対して明快な物が浮かばず、不確定だったので問3を選択。SPIの計算はすっぱり忘れていたので適当だけど。







問1

設問1



システム切替え日付が変更できないため、問題を早期に解決する。

設問2

(1)運用の変更により点検の手順を誤り、プラントが停止する。

 (冒頭の説明で触れられているビジネス上のトラブルを引用)

(2)必要な情報が一覧できないなど、効率を悪化させる要因がないか。

 (当初「器具の使用や設備の操作が阻害されないこと」といった回答を書いていたが、下線部②の前を見ると「タブレット端末に、従来及び新しい点検票のフォームを順番に表示し」とあるので、それによって確認が可能な項目ではないためおそらく間違い)
(後日追記。やはり器具の使用や設備の操作で良かったようだ。日常点検の現場で、とあるので)

(3)事務所に戻らなくて済み、工数が削減できたかどうか。

(この問題、質問が良くなくて、どうやって貢献するかを求めているのか、どれだけ何が起きたか測定対象を答えてほしいのかよくわからなかった。何度見ても質問の日本語が曖昧)

(4)紛失・盗難による点検項目の外部への流出

設問3

取引のないZ社へ開発を発注すること。

(リスクではなくリスク要因を答える必要があるので、それにより発生する具体的なリスクではなく、その要因として最も大きいものを挙げた)




設問2(2)や設問2(3)、設問3で自信マンマンに誤答していて見直しで気づいて慌てて全部直した。危なかった。




問3

設問1

個々の機能の作業で対応が必要な問題が起きている可能性があるため。

(個々の機能の作業の中で、「全体で対応が必要な問題が起きているかもしれない」ため、というふうに取れない変な文章を書いてしまったので微妙な回答)
(某巨大掲示板を見たらSPIが落ちてるとこがあったので、というのが正解な気がしてきた)

設問2

(1)0.89 (割り算逆?)

(2)未決事項一覧表

 (課題管理表とするか悩んだが、全体会議での報告なので従来使用しているフォーマットのほうがわかりやすいと判断。が、課題管理表のほうが解決済みのものの解決に時間がかかったり納期を破っていたりといった事情がわかってよいのではないかとも推察)

(3)D社の仕様検討者に情報システムやs社パッケージに対する理解が不足している。

(4)システム化した場合の処理のイメージ図

(本文中そのまま⋯⋯)

(5)プロジェクト全体のスケジュールを遅延させる状態。

設問3

(1)外部設計時の問題が解決しているか、実装を確認できる。

(2)FAQ



iPhoneとbluetoothキーボードで書き起こしたので非常に誤字が多いと思う。
特に勝手に変換候補に助詞がつけられていて削除するのが漏れていることが多い。
多分。
それから、iPhoneのメーラーで気づいたのだけど、一旦ドラフトに保存すると行頭のスペースを削除してくれるのね。いい加減にしてほしい。

とにかく脱線しがちで、残り15分でとにかく最後まで行き着いたが支離滅裂。
後で修正しやすいよう、各項目の間に空行を入れておいたのが大いに活きた。
設問ウは稚拙だし流れぶった切りだがプロジェクトマネージャ的な感想を述べられたのではないかなと思う。


文字数についてはMicrosoft Wordに貼ったときの文字数を記載したが、実際には空行多く、答案用紙上は2400文字当たりまで行っていたはず。特に設問アはプログラムがないってのはどういうことかをやたらと書いてしまって(回収しない伏線にもかかわらず)いた。最後に振り返ったときに何とかしたかったが修正不可能で、とにかく下に3行くらいつけていた空行を使って無理やり説明をつなげた。

ということで怪しい部分は(怪しくないところも一応)段落や項目の間に空行を入れておくのはお勧めです。
空行が入っていても採点上はほとんど失点にならないと思うが(心象は悪化するだろうけれども)、後から何か書き足したいときにやりやすいので文章の質は上がるはず。
空行がなかったら無理矢理文言削って押し込めないといけないので時間もかかるし。



午後2
問1

設問ア (648文字)
本論文では、メーカーA社の資産管理システム(以下B システムと略す)の老朽化に伴うサーバーに接続リプレースプロジェクト(以下、本プロジェクトと略す)を扱い、成果物の再利用について述べる。なお本プロジェクトにおいて私は請負先会社のプロジェクトマネージャーという立場である。

1.プロジェクトの特徴
本プロジェクトの最大の特徴は、プログラムの修正を含まない点である。A社では情報システム投資について既存システムへの支出を抑制する方針であり、本プロジェクトでも老朽化へ対応するために必要なサーバーとOSの入れ替えと、その上で必要最小限の修正のみ行う事が前提となった。極力プログラムの修正は不要な形とし、もし発生する場合は本プロジェクト範囲外でうこととなる。プログラムの修正がないため、本プロジェクトではミドルウェア以下の基盤部分の作業が主となる。基盤部分の作業の特徴としては、使用するソフトウェアと非機能要件が同一であれば設計が大きく異なることはないという点である。

2.再利用した範囲と方法
(1)範囲
本プロジェクトでは、過去に同じA社より受注して行ったXプロジェクトより、設計書、パラメータシート、手順書を再利用することとした。これは、使用するソフトウェアと非機能要件が類似していることから再利用に適していると考えたためである。

(2)方法
全ドキュメントにおいて、Xプロジェクトと使用するソフトウェア・非機能要件が同一の部分に関しては修正を行わずにそのまま使用し、その他の部分は新規に設計・作成を行うこととした。
設問イ (767文字)

3.期待した効果
Xプロジェクトからドキュメントを再利用することで、設計・作成工数の削減を期待した。また、過去に成功裏に完了したXプロジェクトの成果物を元にするため各成果物の抜け漏れを防ぎ品質向上が図れると考えた。

4.再利用にあたっての課題
(1)各ドキュメントごとの再利用範囲の相違による誤認
2にて述べた通り、ソフトウェア・非機能要件が同一かどうかにより再利用対象・対象外を決めているため、ドキュメントにより再利用の部分とそうではない部分が混在する形となっている。このたメンバーが設計や作成を行う際に再利用対象かどうかを誤認し、設計漏れや二重作業を行うことになることが想定された。
(2)不整合の発生
一つのドキュメントの中で再利用する部分とそうではない部分が混在するため、新規設計部分と再利用部分とで不整合が生じる可能性がある。

5.課題の対策
(1)各ドキュメントごとの再利用範囲の相違による誤認
再利用部分とそうではない部分を明確に区別する必要があるため、本プロジェクトの成果物一覧を作成する際に再利用のレベルについても決定し記載することとした。成果物そのものについても、再利用部分は網掛けにして誤って修正をすることがないようにした。
この対策の結果、実作業に入ってから作業者が再利用すべき部分かどうかで誤認することは防ぐことができた。一方で、主に要件の変更に起因して再利用範囲の変更が度々発生し、その際に成果物の一覧と、成果物の網掛けについても修正をする必要が生じた。

(2)不整合の発生
各成果物それぞれ一貫した確認を行うため、レビューの際には再利用部分についても全てレビュー対象とすることとした。この結果再利用有無により不整合が起こることは防げたが、レビューの際にそもそも当初の再利用可否判断が誤っていた箇所についても発見することとなった。
設問ウ (605文字)

6.期待した効果の実現状況
5に述べた通り、要件の変更や当初の再利用可否判断の誤りをなどにより再利用範囲が変更になったことから対応工数が増え、全体として工数は削減できたが当初想定した数値はクリアすることができなかった。ただし、本プロジェクト開始にあたり、今回のような事象が発生するリスクを予期しコンティンジェンシー予備として積んでいたことから、予算数値は守ることができた。
一方で品質については、再利用範囲の変更によるものを除き極めて良好な状態で、過去の類似プロジェクトに比べて懸案発生数は約半数程度となった。

7.評価と改善点
当初想定した削減工数を達成することができなかったが、これは逆に言うと「再利用」するという判断の裏には再利用すれば作業がなくなるため大幅に工数が削減できるであろう、という期待がステークホルダーにあったと考えられる。プロジェクトマネージャーとしては、より正確な情報を元に、理解しやすい形でプロジェクトオーナーやその他のステークホルダーへ説明を行い期待をコントロールすることが重要であると考える。
具体的な施策としては、特に品質について大きな効果が見られたことから積極的に適用を推進していきたいが、その際には再利用範囲の決定が非常に大きな影響を及ぼすことから①再利用範囲の決定時点で有識者によるレビューを行う、②要件変更による再利用範囲への影響を事前に洗い出す、といった改善が必要であると考える。


平成27年度 春期

プロジェクトマネージャ試験 午後II(午後2) 問題

の問1をといてみました。

すみません、かなり投げやりです。


前半の伏線を後半で回収できない、後半で関係ない話をしているなど、結構ひどいできです。

が、準備はここまで。

午前II(午前2)は無勉強でも7割は超える、午後I(午後1)も同様で、たまに難しいのがあるとそうとわかる状態。(=難しいのは飛ばして、違うので7割前後をそろえられる)

午前I(午前1)はシステム監査の合格があるので免除です。


さて、日曜日はがんばりましょう。




設問ア (566文字)


本論文では、私が、所属するメーカーA社においてプロジェクトマネージャとして関与した資産管理システムBのサーバーリプレースプロジェクト(以下本プロジェクトと略す)を題材に、請負契約での調達について述べる。


1.プロジェクトの特徴
 本プロジェクトでは、老朽化してOSのサポート期限切れを迎えるBシステムサーバリプレースを行った。
 本プロジェクトでは費用低減が優先であり、新たなプログラム開発を極力排する方針であった。このため、サーバーとOSの更新に伴い必要となる最低限のミドルウェアのバージョンアップに伴う修正などのみを実施した。
 本プロジェクトの特徴は、サーバー、OS、ミドルウェアのバージョンアップによるプログラムへの影響が事前に測れないという点にある。


2.請負で調達した範囲
 本プロジェクトではインフラ構築の外部設計からシステムテストまでをC社へ請負で発注した。プログラムの修正に関しては企画段階では規模が不明確であり見積ができない点と、運用保守を行っているA社内の人的リソースを当てたいという考えから除外した。企画、要件定義に関してはベンダではコントロールが行えない部分であるためA社にて責任を持つ必要があった。また、移行に関してはプログラム修正による影響が大きいことから本契約には含めず、C社とは別途準委任契約を行って参加してもらう形とした。


設問イ (824文字)


3.管理において留意した点
 請負での発注が他の契約と最も異なる点は
① ベンダには成果物責任がある。
② 指揮命令できない。
という2点である。このため、ベンダにして欲しい作業を明確に成果物に含める必要がある。進捗の管理、品質の管理のために行った工夫をそれぞれ述べる。


3.1.進捗の管理における工夫
 請負での発注の場合、前出のとおり指揮命令ができない。このため、進捗の報告、フェーズゲートの設定を行った。
 進捗の報告については、報告様式と粒度を定義することで各作業の進捗を誰でも明快に確認できる数値での報告とした。例えば主観的な%での報告は禁止した。また、進捗の議事録も成果物に含めることで、認識の相違がないことを文書で確認しながら進めることとした。
 フェーズゲートについては、具体的には外部設計、内部設計などの各開発フェーズの完了時に成果物を確認するレビューとして設定した。これにより各フェーズでの残作業を明確にし、共有することでプロジェクト全体の問題として明らかにし、ベンダ内だけに埋もれさせないようにした。
 フェーズゲートは品質の観点でも大きな効果を期待して設定したため、3.2でも再度触れる。


3.2.品質の管理における工夫
 請負での開発におけるもっとも大きな問題は上流肯定での発注者側とベンダ側との認識の相違が訂正されないまま進捗し、納品において発覚することである。これを防ぐために本プロジェクトではA社提示のフォーマットでの成果物納入を求めるとともに、フェーズゲートで成果物の中間確認を義務付けた。
 成果物のフォーマット指定については、各設計書において必要事項も定めることで設計の抜け漏れの予防になるとともに発注側のチェックにおける見逃しを防ぐことになる。
 フェーズゲートについては、各フェーズでの成果物を現物で確認することで要件が具体化され、実装、テストでの確認までされていることを一貫して確認し、実現できない要件があれば早期に発見できるようにする目的も兼ねていた。


設問ウ (655文字)


4.管理の実施状況と評価、改善点
 3と対応する形で状況と評価、改善点を述べる。


4.1.進捗の管理状況と評価、改善点
 進捗管理のフォーマットに関してはおおむね適正に運用できたが、懸案事項があり解決方法を検討する場面では単なる遅延としての表現となりプロジェクト全体への影響が見えにくい面があった。
このため、マイルストーンを細かく設定し、ベンダ作業とプロジェクト全体のWBSとのリンクを取りやすくすることで改善ができると考えている。


4.2.品質の管理状況と評価、改善点
 こちらもフォーマットについては有効であった。当初よりフォーマットを指定していたことで、C社のリーダーからも、求められる品質が明らかであり管理が容易になる、との意見があった。
フェーズゲートに関しては、ベンダよりも発注側で問題があり対応方法を急遽検討する必要が生じた。具体的に述べると、C社にて試行用環境を構築し、A社にて試行を行ったところ、新たなOSとミドルウェアの組み合わせではプログラムの修正が想定以上に必要となり、システムテストが当初予定通り完了できないことが判明した。
この結果としてシステムテスト完了時のフェーズゲートレビュー実施が困難になったが、最終的にはステークホルダーへ説明の上、ベンダ側の了承を取り、システムテストは一部作業をスコープ外として別契約をもって行うこととした。
 今後は発注側事由による遅延についても契約に明記するとともにリスト登録簿に手管理し、事象発生時のコストへの影響も算出してステークホルダー、特にプロジェクトオーナーへ周知する。


CACCのBでした。

ちなみに再現解答の採点いただいたのはサクセスレッスンアトリエ(SLA)という教室でした。
http://slat.co.jp
個別指導で、今年はレギュラーコース受講者は全員合格とのことでした。

全員!?

うーん、一対一だと四十万近いですね。
当然ながら私には手が出ませんが優先度次第では充分ペイする投資だと思いますね。

ちなみに採点は丁寧にポイントが指摘されており大変ためになりました。
無料とのことでしたので是非おすすめです。

なお、私の採点結果は若干高く出ていましたが、再現解答がやはり再現だけあって試験本番で書いたものよりもまとまりがあったのかなと思います。


ちなみにアフィリエイトなどではないです。
大変ありがたかったのでご紹介まで。