システムアーキテクト試験の午後II対策として私がやったこと（その3）
（ その2の続きです）
平成30年のシステムアーキテクト試験、午後Ⅱの問3の設問は、
下記の通りでした。
（問題文全体は、公式Webサイトを参照ください）
設問ア
あなたが開発に携わった組込みシステムの概要と，どのような機能・性能の要求で処理するデータ量を増加させる必要が生じたかを800字以内で述べよ。設問イ
設問アで述べた組込みシステムにおいて，データ量の増加で発生した問題，及び目的達成のためにシステムアーキテクトとして考案した解決策とそれを選択した理由について，800字以上1,600字以内で具体的に述べよ。設問ウ
設問イで述べた解決策の達成度，開発段階で生じた未達事項などの問題，及び今後の課題について，600字以上1,200字以内で具体的に述べよ。
私が本番で実際のメモ書きは、以下の通りです。
メモ用紙1ページには収まり切りませんでした。
これを書くのに30分から40分程度かかっています。
具体的な行動計画におけるNGワードと、システムアーキテクト試験論述試験のNGワードの共通点
今週は、飯田剛弘『PMBOK対応 童話でわかるプロジェクトマネジメント』の
『桃太郎』を読みました。
「よし、みんな、まず鬼ヶ島に上陸する前後の情報収集作業を具体的にしていこう。キジくん、どう？」
「まず上陸前に島の状況を徹底的に把握します。次に鬼の屋敷をきちんと調べます。その情報を基に、今後の作戦を検討します。」
（p178）
キジくんの「徹底的に」「きちんと」「検討します」という表現について、
桃太郎は具体的にするようにアドバイスするわけです。
解説でも、
「誰が」「いつまでに」「何をすべきか」という具体的な行動の計画を立てるためには、まずは曖昧な表現を避けることが重要です。
（p182）
とあります。併せて、「具体的な行動の計画を立てる際のNGワード」として、
「管理する」「監督する」「把握する」「確認する」「チェックする」や、「検討する」「考える」「意識する」、「具体的に」「効率的に」「明確に」という表現を挙げています（全部で65単語紹介されています）。
似たようなことを最近聞いたなと思ったら、
システムアーキテクト試験の午後Ⅱの論述問題の参考書に、
同様のことが書いてありました。
金子則彦『システムアーキテクト合格教本』です。
“徹底的に”，“非常に”，“絶対に”，“確実に”，“全力で”といった強調表現を乱発しないほうが，良い論文になります。何事も“徹底的に”やれば，成功することが多いので，受験者が実行した工夫とはいいづらいからです。強調表現を控えて，“ここぞ！”という箇所のみで使うとよいでしょう。
（p495）
私も、こういう表現を「埋め草」的に使ってしまうことがあります。昔は気にしていたのですが（特に「検討」という表現を大きく嫌っていた時期がありました）、最近はそうでもなくなってきています。
「管理する」とか「チェックする」というのは、まだそこまで具体的に考えなくてもいい状況であれば、とりあえずの表現として使ってもいいのだと思います。しかし、具体的な行動を策定する際には使用するべきではないでしょう。
報告書的な文書でも、「検討した」なんていう表現は、わざと曖昧にしているのかと疑ってしまいそうです。具体的にできないということは、ホントは取り組んでいないのか、という疑念を持たれかねないという点で、論文試験での使用も控えるように指導しているのでしょう。
ガントチャートでプロジェクト管理する
プロジェクトマネージャ試験のお勉強の一環で、
ちょっとガントチャートを使ってみたいなと思います。
いや、本業でも使っていますよ、「日程表」という名のガントチャート。
勿論、個人個人が思い思いにExcelで作った日程表ですけど。
申し訳ないけど私はケチなので、
無料でガントチャートを作れるWebサービスを使いたい。
色々触ってみましたが、今のところは「Brabio!」というサービスに落ち着いています。
他には、「Trello」に「Elegantt for Trello」を連動させて使ってみましたが、
肝心のタスク関連は有料でしか使えない、何のためのガントチャートなのか、
というポンコツぶりを発揮したので、こちらは捨てました。
もっといいサービスがあれば、そちらに乗り換えるかもしれませんが、
暫くはBrabio!でいいかなと思っています。
サービスを選ぶ際に参考にしたサイト
プロジェクトマネージャ試験の勉強を始めました
さて、システムアーキテクト試験も終了したので、
念願のプロジェクトマネージャ試験*1の勉強でも始めましょうか。
ことはじめに、1冊本を買ってきました。
飯田剛弘『PMBOK対応 童話でわかるプロジェクトマネジメント』です。
すんなり読めて、プロジェクトマネージャ（PM）の雰囲気がつかめます。
一応本書でもWBSなどの各ツールの説明はありますが、
事前に別のところで最低限の知識が入っていると、理解の助けにもなりますし、
何より楽しく童話を読むことができます。
ちょっとだけ紹介します。最初の「3匹の子ブタ」の第3幕より：
末っ子の子ブタは、2匹のお兄さんブタの進め方をじっくり観察しました。
しかし、まだ具体的にどのような家をつくるべきか、お母さんブタの要求事項もよく把握しておらず、プロジェクトを通じてつくるべき成果物スコープを明らかにできませんでした。
（p27）
この本では、こんな調子で物語が進んでいきます。このお話の終盤では、優秀なPMの素質を持つ末っ子ブタの冷徹な一面も見られますが、それは読んでみてのお楽しみということで。
今月中に読み終えたいな、と思ったけど、今月は後数日しかないのか。
来月中だな。
*1:さっき誤って「プロジェクトマネジメント試験」って書いてしまった。念のためググっておいて良かった。「マネージャー」でも「マネジャー」でもなくて「マネージャ」なのね。
システムアーキテクト試験の午後II対策として私がやったこと（その２）
（その１の続きです）
まずは、設問イの問題文を見てみましょう。
設問イ
設問アで述べた組込みシステムの開発で使用した信頼性設計の設計手法・内容について，開発スケジュール，コスト設計などとの関係を含めて，ハードウェアとソフトウェアの両面から，800字以上1,600字以内で具体的に述べよ。
設問イは、一番ボリュームがあります。
最低でも800字ですが、目安は1200字と言われています。
メモ書きはこんな感じ。
このメモ書きを見ると、箇条書きが丸で囲ってあります。
これ、箇条書きの個数から、どれくらいのボリュームになるかをチェックしているのです。
1,2回演習した時点で、全然文字数を稼げないことが分かりました。
当時は800字に到達するのも大変で、だいたい900字くらいが限界でした。
対策として、メモ書きの時点でどれくらいのボリュームになるか推定できる
方法を編み出しました。それが、この箇条書きカウントです。
だいたい、箇条書き1つにつき3行分（75字）と考えます。
すると、800字がおよそ箇条書き11個分になります。
これを元に、
- 設問ア：箇条書き11個分
- 設問イ：箇条書き22個分
- 設問ウ：箇条書き16個分
という目標を立てながらメモ書きをしています。
実際には、小見出し等もあるので、この個数より少し少なめにしています。
上記の例でも、箇条書きを囲んでいる丸の個数は14個しかありません。
流石に14個は少ないと思いますが、この辺りの調整は、自身で演習をしてみて、
どれくらいがいいかを決めなくてはいけません。
箇条書き1つで75字は。あくまで私の目安です。
内容の方では、
まず、しっかりとハードウェア（H/W）とソフトウェア（S/W）の両方を、
そして、コストとスケジュールの両方を、文章の構成として組み込んでいます。
勿論、設問イの問題文を受けて、このような構成にしているのです。
何しろ論述は手書きであり、途中で軌道修正はできません。
最初のメモ書きの時点で、問題から求められていることをしっかりと把握して、
確実に押さえる必要があります。
また、課題の落とし込み方も、メモ書きの時点で決めています。
こういう課題が発生した、というところまでしか決めないで書き進めてしまうと、
その後の展開がうまくいかなかったときに、論述が苦しくなります。
メモ書きの時点で、落としどころまでしっかりと決めましょう。
勿論、ある程度の想像・妄想を含めても構いません。
設問ウの問題文は以下の通りです。
設問ウ
設問イで述べた信頼性設計によって，品質要件をどの程度満たすことができたか。定量的評価を含めた考察と，副次的に発生した利点について，600字以上1,200字以内で具体的に述べよ。
設問ウも、今までと同じような感じです。
問題文では、達成度を定量的に書くことが求められています。定量的とは、つまり数字で示せということですが、これこそ想像の数字を書くしかありません。メモ書きでも汚いです（そしてモザイクがかかています）が、○○ー●●%、△△ー▲▲%、と、数字で書いています。
（その3に続きます）
Scilab/Xcosをインストールしてみた
結構便利だなぁということを感じました。
業務では暫く使う機会がないので、忘れないようにプライベートでも
いじってみたいとは思うのですが、そこはMATLAB、個人でえいやと買える値段じゃない。
学生の頃に、自宅ではoctaveを使っていたように、
きっとSimulinkライクなフリーソフトもあるはずだとググってみたら、
ありました。Scilabに搭載されたXcosというフリーソフトです。
日本語での紹介は、例えば下記公式サイト（PDF）
このPDF内に、ダウンロードのリンクが含まれています。
インストールしてちょろっと触ってみましたが、
基本的な機能はSimulinkと大きく変わらないけど、
操作感は全然違います。これは慣れが必要だ。
システムアーキテクト試験の午後II対策として私がやったこと（その１）
今回は、システムアーキテクト試験の午後Ⅱ対策として
私が実際にやったことを書こうと思います。
実際のメモ書き
対策の効果を見るために、まずは、対策前（本番のおよそ2か月前くらい）の午後Ⅱ演習のメモ書きをご覧ください。
問題は平成25年秋期のSA、午後Ⅱの問3（組込みシステムと信頼性設計）です。
なお、諸事情により一部モザイクが掛かっていますがご了承下さい。
一応、設問アからウまで、書く内容の項目を挙げてはいますが、このメモ書きから論述を展開するのは中々難しいです。
実際、このメモ書きを元に論文を書いていますが、設問アで力尽きてしまいました。
一方、こちらは、何回か演習を繰り返し、メモの書き方を大方決めた後の演習のメモ書きです。大体本番1か月くらい前でしょうか。
実はこれも、平成25年秋期のSA、午後Ⅱの問3であり、問題としては先ほどと同じものです。
こちらも、諸事情により一部モザイクが掛かっています。
1枚目の上半分は、問題文を整理したメモですが、このメモ書きは最終的には書かなくなりました。
1枚目下半分から、2枚目にかけてが、設問アからウまでの書く内容を項目立ててメモしたものです。
これだけしっかり項目立てしてあれば、
後はガリガリ書くだけというところまで行くことができます。
メモ書きの中身
さて、では対策を行った後のメモ書きの中身を説明してみます。
その前に、設問アの問題文から見てみましょうか。
設問ア
あなたが開発に携わった組込みシステムについて，その性能，機能などの概要と，信頼性設計の対象となった品質要件を，800字以内で述べよ。
さて、メモ書きのほうですが、
形としては以下のような感じです。
まず設問アでは、２つの節を立てています。
１つ目が「私が開発に携わった組込みシステムの概要」、
２つ目が「信頼性設計の対象となった品質設計」です。
メモ書きにはそんなこと書いてないじゃないか、って？
そうです。メモ書きにはわかりきっていることは書きません。
そんな時間はありません。
節の見出しは、基本的に設問文をそのまま引っ張ってきますから、メモ書きには書く必要がないのです。
特に、問3の設問アでは、高い確率で「あなたが開発に携わった組込みシステムの概要」を聞かれるので、これに至っては見出しが書かれる丸しか書いていません。
1節目では、
- 会社の説明
- 製品の説明
- 製品の課題
- 自己紹介
- プロジェクトの制約条件
を書いています。
私は1節目では、常にこの5つを書くようにしました。
このうち、自己紹介というのは、自分の立場を紹介したものです。
「私はこのプロジェクトのシステムアーキテクトである」
という一文です。
私が参考にした参考書2冊の、どちらにも自己紹介文は書くようにとありました。
（書く位置は、節の最初に持ってくるパターンと、節の最後に持ってくるパターンがありましたが、私は後者を採用しました）
プロジェクトの制約条件というのは、プロジェクトに与えられた時間的・人員的リソーセスの制約です。
この制約が、後々解決策を取捨選択する際の指標として働きますから、必ず書くようにしましょう。
特に今回の問題では、設問イで
「開発スケジュール、コスト設計などとの関係を含めて」
とあるので、プロジェクトの期間を書くのは必須です。
後々、ある解決策を採用しない理由として、
「今回のスケジュールでは間に合わないから」
と書くことを念頭に入れているのです。
2節目では、信頼性設計の対象となった品質要件を挙げています。
ここでは「ハードウェア（H/W）」と「ソフトウェア（S/W）」の2つのキーワードを入れています。
午後Ⅱの答案をどのように採点しているかを考えると、
基本的には減点方式であるだろうことは容易に想像ができます。
まさか、例年2000人程度に及ぶ、採点対象となる（＝午後Ⅰまで合格した）
午後Ⅱの答案に対して、じっくり内容を読んで採点しているなんてことは考えられません。
設問で要求されていることがしっかり論述できているかを判断して、
論述されていないと判断されたら、その時点で不合格のボックスに放り込まれるのです。
では採点官はどうやって、設問で要求されていることが論述されているかを判断するのかと言えば、それはキーワードが含まれているかです。
設問イでは
「ハードウェアとソフトウェアの両面から」
という指示があります。
これを見越して、設問アの回答で既にキーワードを織り込んでいるのです。
※採点官がどんな基準で採点をしていそうか、については、
金子則彦『システムアーキテクト合格教本』が大変参考になります。
（その２に続きます）
