技術士試験(情報工学部門)合格&書籍執筆のお知らせ
はじめに
だいぶ長い戦いだったのですが、ついにこの日が来ました。
#技術士 二次試験(情報工学部門)合格しました。
— dimeiza@技術士(情報工学部門) 攻略ガイドブック (@dimeiza) 2021年4月29日
私が受験したソフトウェア工学は全員合格です。
…同時に統計資料が出ていたので見てみたんですが…情報工学は7.6%で全部門中最難関だったようです。
むしろ受かった本人の方がビビっており、身の引き締まる思いです。
ありがとうございました。 pic.twitter.com/sdCrbMKFaq
2021/4/30、技術士試験(情報工学部門)に合格し、技術士(情報工学)となる資格を得ました。
今回はいつもと若干違う…。
で、本来はいつもの通り、
- 技術士とは?
みたいな話から始めて、勉強法の説明等を含めた感想戦をするところなんですが。
今とても忙しくてですね。
技術士(情報工学部門)に関する書籍執筆
というのも、今、Zennで本を書いている最中なんですよ。
Twitterでも話をしたんですが、技術士(情報工学部門)に関する書籍ってほとんどなくて。
先日令和3年度の技術士試験申込みの時に、選択科目の選び方についてTwitterで話をした最後で、こんな事を言っていたのもあってですね。
まだ結果が出てないのにデカイ口を叩いていますが、 #技術士 情報工学部門合格の暁には、この辺の体験記やノウハウ系をZenn辺りで書籍化でもしようと思っていますので、情報工学部門のノウハウが欲しい方は私の合格でも祈ってやってください。
— dimeiza@技術士(情報工学部門) 攻略ガイドブック (@dimeiza) 2021年4月2日
(フラグっぽくて怖いけど)
どうせ感想戦をやってノウハウを書くなら、ここは1つ、技術士(情報工学)の界隈に欠けている書籍として自分のノウハウをまとめ上げ、後に続く人に渡したほうが良いのではないか、と思いまして。
令和3年度の受験生は今頃論文の勉強をしているでしょうから、それに間に合うように論文作成方法&合格答案だけでも共有しておこうかと思って、GW中ずっとキーボードを叩いていました。
というわけで、執筆中と言いつつ第二次試験(論文試験)対策と合格再現答案&解説は既に公開中です。技術士(情報工学部門)の受験生、今後目指すかもしれない人は是非一読してみてください。
一次試験、口頭試験は追って追加の上、追加が完了したら多分このBlogでもアナウンスします。
感想戦はその後に改めてやりましょう。ノウハウとは別に、今般の技術士試験は特別扱い続きで、例年にない険路でネタもたくさんありますからね。
ではまた。
技術士(情報工学部門)攻略ガイドブック 本冊 付録1 実際に使用した参考書、道具類
このページは、『技術士(情報工学部門) 攻略ガイドブック』(本冊)の付録で、私が技術士試験を受験した際に実際に使用した書籍や道具類を紹介するページです。適宜ご活用ください。
(いきなりこのページにたどり着いてしまった)『技術士(情報工学部門) 攻略ガイドブックって何?』という方はこちらをどうぞ。
書籍類
私が受験した当時、情報工学部門特化、かつ新制度に対応可能な書籍はほとんどなかったので、色々と当たっています(私が読んだ時から改版されているものもあります)。
第一次試験(基礎科目&適正科目)
基礎科目と適正科目はこの2冊を使いました。
後者は一部地域で2019年度の第一次試験が再試験になった影響で、再試験前に最新の問題を確認するために買っています。
あと、3群(解析に関するもの)では力学系の問題がでてくるので、この本を。
4群(材料・化学・バイオに関するもの)の化学系知識については、この本を読んでいました。
第二次試験(論文試験)
情報工学部門だと、おそらく唯一参考書と言えそうなのは、新技術開発センターが出しているこれでした。
毎年出版しているようなので、買って読んでみてもいいと思います。
この回答事例集は一応技術士の講師が書いているそうで、私も技術士論文答練の取っ掛かりにしました。
新制度受験生の合格答案ではない点、回答の事例が若干古かったりするなど、多少割り引いて読む必要があるなぁ、というのが個人的な感想です。技術知識は自ら調べて補いましょう。
分野横断の本だとこの辺りを読んでいます。
第二次試験(口頭試験)
口頭試験の類書は(情報工学部門に限らなければ)結構出ています。
個人的には本書の内容だけでも何とかなると思いますが、さらに備えたい方は以下をどうぞ。
道具類
ここでは、第一次試験、第二次試験実施時に、実際に私が使用した道具類を載せておきます。
技術士試験、特に峻厳を極める第二次試験においては、小道具と言えども軽く見てはいけません。
第二次試験の章にも書きましたが、試験中で使用する道具類は集中力や解答効率、ひいては勝率を左右しかねないので、慎重に選択、採用しましょう。
筆記具
シャープペンシル
万が一に備えて予備も持っていきましょう。筆箱に入れつつ、筆箱以外のカバンのどこかに入れておいたりしています。
消しゴム
黒のほうが消えると思っていたのですが、性能は同じらしいです。
1文字消す時はこれで。他の字を巻き込むリスクを最小限にできます。
電卓
特に第一次試験では必須です。私はこれを選びましたが、特段優秀という感もなかったので、お好きなものをどうぞ。
時計
ベルトを外して胴だけ持ち歩き、机に置くのが私のスタイルです。スマートウォッチとかは当然ダメですのでご注意。
身体のケア
これはどちらかと言うと、天下分け目の天王山、関ヶ原とも言うべき第二次試験(論文試験)向け。
目薬
特に第二次試験における目の疲労はかなりのものです。使うかはさておき持っていくと良いでしょう。
栄養ドリンク
これは当日コンビニで買っていきました。試験開始前と休み時間に飲むので2本。
鎮痛消炎用ゲル、クリーム
第二次試験における肩と腰への負担は想像を絶します。
ボルタレンは対肩こりとしてはオーバースペック感もありますが、ないより遥かにマシでしたね。
マスク
防御性能は不織布の方が優秀ですが、個人的に布の方が負担が少なくて楽でした。
オミクロンが感染し始めた昨今は、普通の不織布マスクを使ったほうがいいかも知れません。
その他
原稿用紙
第二次試験の答練では自作の原稿用紙を使いましたが、配布しているところもあります。
Oculus Questで”寝ながらリモートワーク環境”を作る
はじめに
COVID-19の強制力ってのは凄まじいもので、リモートワークに強い抵抗感があった弊職場でも、大分導入の動きが起きています1。
そんなわけで、私もなるべく自宅で作業を進め、職場や社会におけるソーシャルディスタンス確保に貢献しようとしていたんですが、ある日、急に魔女の一撃を食らってしまったらしくてですね。
自宅の椅子は一応アーロンチェアなんですが、この椅子を持ってしても長時間着座がキツイぐらいになってしまい。
2,3日安静にして、急性期はやり過ごしたんですが、それでも座っていると結構疲れる状態でした。
まずはVRに助けられる
仕事は仕事として、職場と話をしながら無理のない範囲で進めていました2。
一方でこの状態だと、業務時間外の各種活動も、必然的に座りながらではなく、寝ながらになっていくんですよ。
そんな時に活躍するのがこのデバイスです。
COVID-19が発生して以来というもの、Oculus Questには大分世話になってるんですが、前機種のOculus Go同様、寝ながらコンテンツを視聴するには非常に適しているんですよ。
急性期は正直寝ているしかないので、朝から晩までYoutubeをこれで視聴していました。
とあるゲームがもたらしたヒント
一方、直近、私はとあるHIDEO KOJIMA GAMEにどハマリしておりましてですね。
(2021/9/7)Directors cut版が出るらしいので、これからプレーする方はぜひ(私もやりたい)。
ぎっくり腰発症前もずっと椅子に座ってプレーしてたんですが、発症後は座るのがキツイじゃないですか。それでもプレーしたいなぁ、という情熱があったわけですよ。
その時、ふと手元のコントローラ(XBox 360 Wireless Controller)に目が止まりまして。
ん? これって無線コントローラだよね?
ひょっとして、この組み合わせ(↓)なら行けるんじゃないの…? と。
で、実際にやってみた動画がこれです3。
DeathStranding with Oculus Quest.
— dimeiza@技術士(情報工学部門) 攻略ガイドブック (@dimeiza) 2020年8月30日
最近腰の調子が悪いので、寝ながらDeathStrandingをしてたんですよ。こんな感じで。
そうしたらふと思いついたアイディアがあったので、試しにやってみてYoutubeに上げてみました。
もうだれか思いついてそうな気もしましたが、ひょっとすると役立つかもなぁと。 pic.twitter.com/aPl4uT8343
追従度も結構高くて、普通にゲームプレーできるなぁ、というのもあるんですが、この後数時間ぐらいずっとこの姿勢でゲームしてたんですよ。
こりゃぁ椅子に座らんで良い分、腰痛的には楽だわぁ、と。
思い出したこと
この態勢で何日かゲームした後で、ふと思い出したんですよ。過去に上げた動画とその反応のことを。
昨年、Oculus Questでコーディングってできないのかな、と思って試した動画だったんですが、いろいろ質問が来ましてね。
Is it like coding with a huge screen? Was it comfortable? I’d like to hear your experience
(デカイ画面でコーディングするのってどうよ? 快適?)
で、実際にやってみた感想としてはこうだったんですよ。
1.Headset is heavy and stuffy.
During a short time, I don't mind this, but in long hours, It became an obstacle of concentrate.
(ヘッドセットが重くて息苦しい:短い時間ならいいけど、長いと集中力が削がれる)
2.Font size vs legibility.
Legibility of codes through oculus depends a font size, and reading a code is harder than with desktop App directly.
(フォントサイズと見えやすさの問題:フォントサイズが小さいとモニタで見るより見えづらい)
ところが、ここにDeath Stranding With Oculus Questの経験を持ち込むと、この辺、実は意外に問題ではないのでは? と思い始めてきたのです。
- ヘッドセットの重さと息苦しさ
- 横になってかぶっていると重さが頭に直接かからないので大分楽。
- フォントサイズと見えやすさ
- Death Strandingの文字は解読可能だった。
- ひょっとしてコントラストと画面サイズ調整の問題では?
後は
- PCに対して入力をワイヤレスで伝えれられる環境と、
- 寝ながらキーボード、マウスを操作できる環境
が揃えば、ゲームするのと同じ方法で寝ながらコーディング(あるいは仕事)ができるんじゃなかろうか?
というところまでアイディアが出てきたので、試してみることにしたという次第です。
やってみた
キーボードとマウスはすでに無線化可能な状態が揃っていました。
キーボードはこれで、
マウスはこれだったので。
後はどうやって寝ながらやるかだったんですが、試しに普通のノートパソコンスタンドを使ってみようかなと。
過去のソリューション的には分離キーボードとかもあって、個人的には興味があったのですが、いかんせんこれは敷居が高い。
なので、まずは安価な投資で試してみることにしました。
結果
ご覧のとおりでございます。
メリデメの棚卸し
とりあえず現状環境のメリデメとしては。
- メリット
- 寝ながら作業できる(唯一にして最強のメリット)。
- PCの単一画面でできることは大抵できる。
- 座り仕事由来の疲労が軽減される。起きていると作業が辛い向きにはオススメ。
- 病気とかハンディキャップがある方には、救いのある作業環境になるのでは。
- 寝ながら作業できる(唯一にして最強のメリット)。
- デメリット
デメリットはたくさん書いてるんですが、作業者のコンテキストによっては、メリットがデメリットを補って余りあると思います。
実はこの前後に、Oculus Questのブラウザ経由で英語の技術文書を読んだりしているんですが、ドキュメントを読む分には問題なく内容読解できていて、フォントの見づらさについては実際の所調整で何とかなります。
この辺のメリデメは、今後の技術進歩で間違いなく変わってくる所なので、数カ月後、数年後には確実に状況が変わっていると思います。鵜呑みにせずにいろいろ試してみるといいと思います。
あと、こういう技を使うと変化があるよ、という話があればぜひ教えてください。私も試してみるかもしれません。
Virtual Desktop以外の候補
VirtualDesktopの代わりにimmersedVRを使うとマルチモニタ、Linux対応にできます。
Linux環境だと操作のタイムラグがひどくて作業にならなかったのですが、Windowsだと複数画面出力でDeath Strandingもできます。
Immersed VRはLinuxで接続するとラグがきつかったんですが、Windowsで接続すると、3画面出力でも操作がスムーズに追従しました。#OculusQuest
— dimeiza@技術士(情報工学部門) 攻略ガイドブック (@dimeiza) 2020年9月6日
寝ながらDeath Strandingしてます。 pic.twitter.com/KzjvMaiUem
この後、実際にBlogを書く作業をしてみたんですが、特に問題なく追従できたので、これを使うのも手です。
Simula VRを使うとLinux環境で作業できるようですが、Oculus Questは対象外なので私は使えませんでした。Linux Driverを持っているVRヘッドセット(HTC Vive等)であれば使えるはずなので、お持ちの方は試してみてもいいかも。
さいごに
必要は発明の母とはよく言ったもので、
- COVID-19というリモートワーク推進のフォースと、実際にリモートワークしている労働者
- ぎっくり腰というさらなるチェンジエージェント
- ゲームプレーというPoC実施を推進する要因
道具が一通り揃った上で、これらの環境が可能性を一つ後押ししてくれた、という印象があります。
ここまで書いていてちょっと気づいたのは、Death Strandingを作った小島監督が紹介している、ヨハン・ホイジンガの『ホモ=ルーデンス』(遊ぶ人)という概念と、今回の活動の類似でした。
人間文化は遊びのなかにおいて、遊びとして発生し、展開してきたのだ。
小島監督自身もこう述べています。
遊びとはただの暇つぶしなのではなく、根源的な創造なのです。ホモ・ルーデンス(遊ぶひと)とは、同時にホモ・ファーベル(創るひと)でもあるのです。
遊びの中には不確定性と創造性があって、これらを単なる消費ではなく、生産的思考につなげて何かを創ろうとすることで、この世に存在しなかった概念や知識体系を創ることができるのではないか。
今回の活動もそうですが、最近の私自身の技術的活動の中で、
- 業務的強制よりも自発的な遊びや探索活動こそが、新たな仕事のやり方や技術知識につながっていることが多い
という気づきを得ていて、あるいはこれがポストコロナにおける知的労働者の指針の一つなのではないか、などと若干大げさなことを考えています。
ちょっと小難しいことを言ってしまいましたが、以上、役に立ちそうであれば試してみてください。
技術士(情報工学部門) 攻略ガイドブック 別冊 第二次試験 論文攻略 IT系論文試験に常勝する力 付録1 参考文献
このページは、『技術士(情報工学部門) 攻略ガイドブック 別冊 第二次試験 論文攻略 IT系論文試験に常勝する力』の付録で、技術士試験、IPA試験の論文攻略をする際に利用した書籍群です。
(いきなりこのページにたどり着いてしまった)『技術士(情報工学部門) 攻略ガイドブック 別冊 第二次試験 論文攻略 IT系論文試験に常勝する力』って何? という方はこちらをどうぞ。
テクニカルライティングに関する書籍
古くから鉄板とされているのはこれなんですが、
- 理科系の作文技術
個人的には大学で1,2度読んだきりで、今となっては正直古さを感じます。
私が今おすすめするとしたら以下の本です。『数学』とありますが、作成、推敲の作法は数学に限定されません。書き方も平易なので読解しやすいです。
基礎編、推敲編は両方読んでおいたほうが良いです。本書の前段として、平易で簡潔、誤りの少ない日本語記述力を付けるために使うと良いでしょう。
- 数学文章作法 基礎編
- 数学文章作法 推敲編
実務書系
私がIPA高度情報処理技術者試験を受験する際には、各区分の攻略本とは別に、区分に関係した実務書を読んでから試験に挑みました。
システム監査技術者試験を受験するときにはこれを、
- よくわかるシステム監査の実務解説(第3版)
ITストラテジストのときはこれを読んでいました。
- この1冊ですべてわかる 経営戦略の基本
組み込みエンジニアが目指すIoTストラテジストへの道(5)(完)
午後Ⅱ
最後の事前準備
午後Ⅰ終了後、私は手持ちのタブレットを取り出して、こんな絵を眺めていました。
以下に書かれた数値をまとめなおしています。
- IT戦略に関する基本データ集<デジタル化の現状と課題> 平成31年3月22日 内閣官房情報通信技術(IT)総合戦略室 https://www.kantei.go.jp/jp/singi/it2/senmon/dai16/sankou1.pdf
これの出典はここ。
午後Ⅱにおいて組み込み系問題(問3)を解くに当たって用意してきた懐刀です。
前述の通り、午後Ⅱ問3は過去数年間に渡って市場分析をテーマにしてきています。
これに対し受験者としては、例えば前々回で書いたように、PEST分析結果を定性的に記述することでもある程度の体裁を整えられますが、私はそこにダメ押ししておこうと思っていたのです。分析そのものに定量表現を付け加えることで、きちんと数字に当たった経験があることを確実に伝え、他の受験者よりも一歩先んじるために。
あえて衒った言い方をしていますが、実際の所ITストラテジストの仕事は分析を含むので、実務経験の一部として、自己のスキルアップとして必要なことをしているに過ぎません。
あと、最初の図を見ると分かると思いますが、私は数字に対して自己の見解を付け加えていて、(結果的に同じになっているとはいえ)内閣官房の大本営発表を鵜呑みにせずに傾向性を把握しています。自分で分析をしておくと、万が一数字を忘れてしまっても、自分の言葉で傾向性を伝えられるので。
というわけで、市場分析系問題が出てきたら百倍返しにして回答してやろうと手ぐすねを引いていたのですが、結果的にこれらの情報を使うことは全くありませんでした。
実際の問題
というのも、午後Ⅱの冊子を開いて目に飛び込んできた問題は…。
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2019h31_2/2019r01a_st_pm2_qs.pdf
問3 組込みシステムの製品企画における調達戦略について
そう来たか。
先程の数値関連は無駄になってんじゃん、とお読みの方は思われたでしょうが、この時私はほくそ笑んでいました。あぁ、ちょうど進行中の案件、これで悩んでたな…と。
やはり経験があるのは午後Ⅱにおいては強いです。
今年は18歳の青年がITストラテジストに合格したと聞いていますが、経験値を論文に敷衍できる人がたくさんの経験を持ったうえで試験に臨むと、おそらく勝率は彼/彼女の数倍になるんじゃないか、と今書きながら思っています。
いかなる敵が出てきても撃ち払える、という意味で、経験値は勝敗というより勝率に響くんじゃないでしょうか。
論文設計
とはいえ、思い浮かんだ事例をそのまま答えても、問3の問題文で示唆されている各種の論文ネタを十分に回答することはできないので、問題文のセンテンスを洗い出しながら、書くべき事柄に対応する事例記述を構築していきます。注意したのはこの辺の文言。
必要な技術を洗い出す必要がある。
中長期的な展望を視野
外部調達との棲み分け
コスト削減
外部の専門家を要請するケース
自社との関係・実績、強みとなる技術評価、長期的な供給の安定性、見積もり提示価格、品質管理体制
外部へ情報を開示するリスク
前々回で伝え損ねたところですが、こういう 問題文の中で"誘いをかけてきている箇所"に対して、きちんと誘いに乗る(実例を対応させて明示的に記述する) というのも論文テクニックの一つです。
これら全てに対応する必要はないですが、私が念頭に置いていた実例では、外部の専門家を要請するケースが欠落していたので、ここを補完しています。
で、本試験中にメモ用紙に書いた論文設計はこんな感じ。製品名は白埋めしています。
何度か本試験のメモ用紙を公開してるんですが、受験記を書く段になってみると、本文は丁寧に書いたとはいえ、よくこの記述を読んで本文を書けたなぁ、と思うんですよね。まぁメモに過ぎないとはいえ、この辺火事場感があります。
- 第1章 私が企画した〜
- 1.1 概要
- セキュアセンサ遠隔確認システム
- (セキュリティモジュールを)組み込んだ環境センサボードのセンサ情報ネットワーク表示
- セキュアセンサ遠隔確認システム
- 1.2 背景
- D社はセキュリティモジュール製造者→IoT方面のセキュア化に進出
- 半導体大手A社と製造業B社より、工場内センサのセキュア化と監視システムの要望
- 1.3 調達戦略の概要
- D社は(セキュリティモジュールの)セキュリティノウハウ
- A社はSoCノウハウを持つ
- NWノウハウが両社にない
- センサ、ボードは汎用品
- D社はノウハウを出したくないが、NWノウハウは取り入れて拡販したい
- A社のOSはフリー、OSを変えても(セキュリティモジュール)の拡販をする
- 1.1 概要
- 第2章 調達戦略の検討
- 第3章 調達戦略の評価
- 3.1 妥当性
- 導入後、調達したNWシステムを他案件に流用中
- 納期も達成、セキュリティも事故なし
- →妥当
- 3.2 リスク配慮
- 施策は奏功
- 品質が低かった → コーディングガイドラインやA社側担当の強化要
- 3.3 将来展望
- D社セキュリティモジュール拡販のために、分野と資産を洗い出しロードマップ化
- 優先度を付けて能動整備
- D社セキュリティモジュール拡販のために、分野と資産を洗い出しロードマップ化
- 3.1 妥当性
うん、長い。こういうのを数分で書きなぐるのも高度区分論文試験の固有技 ですよね。
論文設計を読んでもちょっと伝わりづらいので補足すると。
論文設計の補足(論文の趣旨)
セキュリティモジュール開発に定評のあるD社(自社)が、ある日、半導体大手A社と製造業B社に、『B社の工場で使われている組み込みボードとセンサのセキュリティを、D社のセキュリティモジュールで安全にしつつ、ネットワークで遠隔監視できるようにしてくれない?』って頼まれたのが事の始まりです。
で、D社は自分の技術だけでは達成できないので、
- 組み込みボード(SoC)とセンサ、OSはA社から調達
- 工場設備はもともとB社のものなのでB社から調達
- セキュリティモジュールとドライバはD社から調達
- クラウドを使ったネットワークシステムはどの会社にもノウハウがないので外部調達
- システム構築はD社と顔なじみのC社に委託開発
- システムのセキュリティチェックは社外のペンテスターに依頼 (外部の専門家を要請するケース)
という技術の棲み分けをしよう、というシナリオになっています。
ここで特殊なのはD社の思惑で、D社は『今回構築したネットワークシステムを、セキュリティモジュール販促のために他の案件で使いたい』と思っているんですよ。これが 『中長期的な展望』で、この論文になくてはならない戦略の根拠です。
なのでD社は、欠如しているネットワークシステムを顔なじみで融通も効くC社に委託開発させようとするわけです。ちなみに論文設計には記述がありませんが、ネットワークシステムの費用負担はD社が、ペンテスターの費用負担はA社、B社、D社の折半、って本文には書いてあります1。
リスクについてはシステム監査技術者試験を経験している人にはお手の物でしょう。外部調達系のあるあるリスク(成果物の権利関係と自社ノウハウの欠如)を列挙して、第3章で回収する、という基本の流れです。
将来展望はITストラテジストらしく戦略性のある書き方にしておきました。ここで技術的な詳細を書きなぐってしまうと戦略から技術にレイヤが下がってしまいます。大所高所からの打ち手を印象づけておくことで、戦略系の論文として良い読後感にすることを狙いました。
(私のために用意されたかのような)落とし穴
経験にも即しているし、割と手応えありそう、ってことで、勢い込んで論文を書き始めます。早速設問アを埋めていきます。
えーっと、セキュリティモジュール大手のD社はA社とB社に頼まれて…って関係者が多いな…あとC社の記述も入れなきゃ…。各社の背景も書いておかないとわからないよね…。
没頭しながら筆を走らせて、よし、設問ア終わり。
じゃあ次の設問イだ。論文設計メモを見て、いざ書き始めるぞ、と思って設問イの解答用紙を見たその瞬間、私は凍りつきました。
設問イの解答用紙の上半分、300字目ぐらいまで、すでに記述がびっしり書き込まれてるんですよ。
誰が書いたって、私が書いたに決まってますよね。
そう、設問イの解答用紙の上半分を埋めていたのは、設問アの本文 だったのです。つまり設問アを書きすぎていた んですね。
『策士策に溺れる』って有名な言葉があるじゃないですか。今回のをそれっぽく言うと 『文章上手、文章に溺れる』 って感じでしょうか。
論文熟達者へのアドバイス
試験終了後に知ったのですが、趣旨は違うものの実は事前に回避する方策を教えられてはいたのです。
(6)設計書作成時の注意点
設問イ、ウを作成したあと、設問アを作成せよ!
この注意点の示唆自体は、設問イ、ウの前提を設問アで後付で強調する効果を狙ってのものでしたが、同時に 無意識下の書き過ぎ の対策にもなっています。
ということで、ITストラテジストを狙うレベルの論文熟達者に対して、私が実経験から学んだ最も重要なアドバイス はこれです。
- (無意識下、緊張状態下での)書き過ぎに必ず備えよ!
文章書けなくて困っている人からすると信じられない話かもしれませんが、実際にこういうことがあったので、時間配分上も、各設問に対して書きすぎないようにブレーキをかけることは大事です。情報処理教科書に記載のある通り、解答用紙の余白にマーキングするなどして備えておいたほうがいいでしょう。
緊張下で自制力が損なわれるという点もありますが、特にITストラテジスト試験では、
- 論文のステークホルダが多く、複雑な状況を説明するために多くの文章を費やしがち
という 試験区分特有の理由があるので、文章力に自信がある人ほど、書き過ぎの落とし穴に注意しておいたほうが良い です。
文章記述戦略の転換
…と、終わった今だからこそサラッと言ってられるんですが、この時の私は顔面蒼白で、気が気ではありませんでした。
この状況が発生した時点で、書きすぎた文章を全部消した上で、設問アの本文再構築を行って800字で体裁を整え直さなければなりません。設問アの文章も削除、加筆が必要になるので、これだけで20分以上のロスです。
そしてこのペースで設問イ、ウを書き続ければ時間切れは必至。敗北の二字が脳裏をよぎりました。実際ここで慌てていたら敗北していたでしょう。
そこで(心理的に)ぐっと踏みとどまった上で、以降の文章構築について戦略を練り直しました。
いつもは網羅的に理由をガッツリ書きなぐった上で、最大字数ー400字ぐらいをベースに隙のない論文を書くようにしていましたが、真逆にしよう、と。すなわち、まず最小字数を達成することを念頭に置いて骨子だけを記述し、論文完成後に記載不備を補足していく 方向で記述しよう、と。
いかなる環境下においても 『試験時間内に論文を完成させる』 は鉄則で、回答者にとっては、これが論文作成戦略の根本になります。この点に基づいて論文作成ルーチンの切り替えを行ったのが、今にしてみれば起死回生の打ち手でした。
この基本戦略さえ確定してしまえば、後はその戦略に従って、持ち前の文章記述力でひたすら記載を続けていくだけです。文章力で落ちた落とし穴を、戦略の切り替えと文章力でなんとか字数を埋めて這い上がった、というのが、私の本試験午後Ⅱのストーリーでした。
字数の補足に対する考え方
そういう意味では、提出された論文自体は私の本来出力の7割も出ていません。 字数的にもギリギリ+α、って感じでした。
ただまぁ、怪我の功名もあったかなぁと思うのは、各設問の末尾を補足するときに、少し話に深みと言うか、きちんと付加情報を追記できたかなぁ、と思っています。
例えば、さっき触れた費用負担の話と、論文設計で書いたノウハウの形式知に関する話を本文に書いた後で、末尾の補足で少し掘り下げたりしています。
ベンダーがシステムを納品した後、納品された方が文書だけ見て即日そのまま使えるわけないだろうと思ったので、引き継ぎ期間中のサポート契約は必要だよね、と。一方でサポート契約の費用ってのは実務でもよく交渉事になっていたので、交渉しに行きましたって書く、なんてことをしていました。
字数不足については、補足のための時間さえあればあまり心配することはなくて、本文内に記述した事実をフックとして、色々膨らました内容を追記すればフォロー可能 なんですよね。やはり書きすぎの方を警戒すべきだなぁ、と思います。
試験時間終了後に訪れた、私の試験終了
どうにかギリギリで文章を書き終え、製品、システム概要説明用紙を埋めた後2、誤字脱字のチェックと、最小限の流れの確認をしたところで試験終了の合図。いつも演習で実施していた設問の充足度や論旨の妥当性を確認することなく、私の論文は手元から回収されていきました。
周りの受験者が開放感あふれる顔で帰り支度をしていく中、ただひとり私だけが浮かぬ顔をしていて。ずーっと頭の中で、
- 問で聞かれたことを、きちんと論文で回答できていたのだろうか?
と検証していました。私の中で試験はまだ終わっていなかったのです。
ほとんどの人が退出した後で、おもむろに立ち上がり、帰路につこうとするも何となく帰れず。そのままキャンパス内のベンチに座って、ずーっと問題用紙の問3を眺めていました。
もちろん、論文設計上は各設問に対して章構成で備えているので漏れはないはずなんですが、記述内容が読み手に響くだろうか という点を、まだ脳内に残っている論文の残滓と問題文を照らし合わせながら、じーっと考えていました。
そのまま15分ぐらい経ってから『まぁ何とかなるだろ』と、私の口からふいに言葉が出た瞬間に、私のITストラテジスト試験は終わりました。
私はよく旅行をする際に、観光地を堪能する暇のない忙しない旅行をした後で、旅行記を書きながら回顧して追体験することが多いんですが、まさかそれを情報処理技術者試験でやるとは思いませんでしたね。
で、それから2ヶ月後に、頭書の報に接した、という次第です。
さいごに
大分長くなってしまったので、この内容がどれだけ役に立つか、どこまで受験者の血肉になるかはわからないのですが、
- 企画部門、事業戦略部門、コンサルタント以外のエンジニアでも、
- エンプラではなく組み込みのエンジニアでも
(一応最難関ということになっている)ITストラテジスト試験を突破できる、ということを伝えられれば、と思っています。
ITストラテジストの前身であるシステムアナリストは、私がIT業界に入った頃は雲上の資格で、どういう立場でどういう知識が必要なのか想像することさえできませんでしたが、気づけば私もスタートラインに立つ資格を得たのかなと。
机上とはいえ、技術を商売の観点で捉えなおして理解する発想と立ち位置の転換を体験しつつ、エンジニアの思考、フレームワークとは異なる考え方を体感できたという点、今後の職場で求められる立ち位置的にも有意義な活動だったように思っています。
ひとまずこれで私のキャリアパス上必要となる高度区分はすべて取得したので、私は一足先にIPA試験から卒業します3が、以上、IPA資格を通して知識と視野を広げようとする方々の参考になれば、私としても何よりの幸いでございます。
-
D社としては『だって御社で稼働させるんでしょ?』って言いながら費用負担を折半させつつ、自社資産のセキュリティを担保するという、だいぶ虫のいい話なんですけどね。↩
-
『あなたの役割』の所で、ITストラテジストにぴったりハマる役割がなかったので、"システムアーキテクト"に丸を付けて答えてましたね。設問アでも定番の『私は、ITストラテジストとして〜』って書く余裕がなかったので、"システムアーキテクトとしてストラテジスト的な仕事をした"みたいな伝え方になっているはずです。↩
-
残り4つは私にとっては『ラスボスを倒した後のエンドコンテンツ(やりこみ要素)』。挑戦も可能ですが、もっと他にやりたいことがあるので、さしあたりそちらを優先します。コンプしたくなったら戻ってくるかもしれません。↩
組み込みエンジニアが目指すIoTストラテジストへの道(4)
本試験
というわけで本試験の会場にやってきたのだ。
会場
半年前にシステム監査技術者試験を受けた会場と同じ大学で、勝手知ったる会場。
午前Ⅰの終了時間を過ぎてもしばらく教室に入れなくて、午前Ⅰ免除者が数分待たされてましたね。
午前Ⅱ
いつもどおり過去問でたいてい押さえられますが、ちょくちょく新問が入っていて、そこから聞いてくるのかー、ってのはいくつかありましたね。
問2 官民データ活用推進基本法などに基づいて進められているオープンデータバイデザインに関して、行政機関における取り組みの記述として、適切なものはどれか。
問11 企業や組織の目標管理の仕組みとしてOKR(Objectives and Key Results)を活用する時、OKRの目標(Objectives)及び主な結果(Key Results)に関する記述として、適切なものはどれか。
この辺りはボーナス問題と言うか、知っていたほうがベターという位置づけなんでしょうけど、受験者の予備知識次第で難易度が変わってきそうな印象でした。
いずれにせよ、ここは私も含めて空気のように乗り越える、って感じでした。過去問をちゃんとやってきていれば6割は普通に超えるはず1。
午後Ⅰ
問題選択
ITストラテジストの午後Ⅰは4問出題、かつ1問が組み込み系問題(問4)なので、問4の選択は確定として、あと1問をどうするか、と。
問1は最近自社でもよく耳にするようになったDX(デジタルトランスフォーメーション)の話だったのですが、いかんせん問題文が長い。
ITストラテジスト試験の午後Ⅰ過去問を解いて自己採点評価したとき、私自身の傾向として気づいた点があって。
- 問題文が長い問ほど、正答率が低下する
という傾向だったんですよ。なので、事前に設定した本試験の問題選択ポリシーの一つは、
- 長文の問題は避けよ。
という極めてシンプルなポリシー。
午後Ⅰの問題選択にあたっての最適なポリシーは、区分によっても、受験者の予備知識によっても大きく変わるところなんですが、ITストラテジスト試験の午後Ⅰ攻略の一般原則としては、上記は結構有効だと思っていて。
他の試験区分だと、表や図を探したり、複雑な計算をする代わりに長文の問題を解く、って選択の仕方をしたりするんですが、ITストラテジスト試験の答えは、基本的に日本語の問題文にしかないわけですよ。
午後Ⅰの解答時間が90分しかなく、自身の日本語読解量が有限であることを考えると、なるべく早く問題文を読み解いてしまったほうが、解析と解答に要する時間を多く取れるな、と。
このポリシーで2019年度問1〜問3の問題を選ぶとしたら、選択肢は一つしかありません。設問記述含めて4ページしかない問3で確定です。
で、実際問3を解いてみると、何の予備知識も要求していない割にはかなり簡単で。おそらくここの問題選択は適切だったなぁと思っています2。
組み込み系問題(問4)
問4は、Web系やオープン系と違って、どうしてもB2Bの商流に束縛され、会社の殻にこもりがちな組み込み系メーカ企業にあっては非常にあるあるな環境の中、顧客からの要求に答えるだけでなく、逆にレバレッジをかけて自社の価値を高めていくという、組み込み屋として非常に理想的な戦略が書かれていて。
問題を一通り解いた後で、理想事例ながら、そのたくましさに思わず感心してしまいました。組み込みストラテジストとしてはかくありたいものです。
ひとつだけ残念だったのは、設問3(2)で、『空飛ぶクルマ事業』を答えそこねたこと。
災害時の救急搬送や迅速な物資輸送などを想定した"空飛ぶクルマ"の構想と、その実現に向けたロードマップを示した。
このフレーズは見てたんですが"事業"という言葉には結びつかなかったですね。ここに書かれているのは政府の構想であって、直接事業化することはできないもの、という印象を問題文から受けたので。私の予断といえば予断なんですけど、問題文として両者をつなぐ表現があったほうが、誤解がなくて良かったですね3。
さて。今回はちょっと短いですがここで切りましょう。
午後Ⅱはこの試験の特徴通り、これだけ練習してきた私にとって(むしろ私自身のために用意されたかのような)大きな罠が待ち構えていて、文字通り最後にして最大の敵になったので、次回に詳しく書いておきたいと思います。
組み込みエンジニアが目指すIoTストラテジストへの道(3)
午後Ⅱ
さて…ここが正念場ですよ。
ITストラテジスト試験が情報処理技術者試験最難関と呼ばれる最大の理由…それはおそらく論文の難易度です。
普通のエンジニアからすると、大きく2つの障害があると思っていて。
- 事業課題と直接対峙した経験がない
- 論文スキルの高いライバルと競わなければならない
敵が持つこれらの特性を変えることはできないので、合格したければ自分を変えていくしかありません。 気を引き締めていきましょう。
あ、論文試験初めてって人は、システムアーキテクトの論文に関する過去記事をお読みください。そこに書いてあることは知っている、という前提で書いていきます。
事業課題と対峙する
多分ですが…実装とか設計とかプロジェクト管理といった、現場で開発力を駆使してきたエンジニアのほとんどは、こんなことしたことないと思うんですよ。特に所属する企業の規模が大きければ大きいほど。
ところがそれを容赦なく迫ってくるのがITストラテジストの論文です。
例えば2018年度。これなんかは大上段で来ます。
問1 事業目標の達成を目指すIT戦略の策定について
設問ア あなたが携わったIT戦略の策定について、事業概要、事業目標、実現すべきビジネスモデルまたはビジネスプロセスについて、事業特性とともに800字以内で述べよ。
設問ウ 設問イで述べたIT戦略の実現のために、あなたは経営層にどのようなことを進言し、どのような評価を受けたか。
経験がある向き、例えば企画部員、事業戦略部門の人、コンサルタントといった人々は、自分の経験を書けばいいでしょう。
一方で、正攻法でITストラテジストの論文に挑む我々エンジニアとしては、まず最初に、
- 持ち込んだ開発経験を元にして、どうやって事業課題と対峙するか
ってのがポイントなんだろうな、と。
(かつて存在したであろう)事業課題を想起した上で対峙する
システムアーキテクト試験以来発揮され続けてきた妄想力を、今回私はこの方向で使うことにしました。
というのも、我々が日々開発しているプロダクト、サービスにしても、源流をたどると必ず事業課題にたどり着くはずなんですよ。会社は伊達と酔狂で仕事をしているわけではないので。
例えばですね。2017年度問2。
問2 新しい情報技術や情報機器と業務システムを連携させた新サービスの企画について
この演習で私が持ち込んだシステムは『画像認識を用いたリテール売り場向け顧客行動分析システム』。新技術としてIoT(カメラ)とAI(動画認識)を使うことになりますね。
仮に書き手がこのシステムを設計実装したエンジニアで、システムの全体像や概要設計を知っているのだけれど、このシステムの企画背景を知らないとしたらどうするかと言うと、社会情勢や顧客、作り手の状況を含めて推察していくわけです。
- このシステムの顧客は誰だろう? → リテール向けってことは小売店か (事業概要:顧客)。
- このシステムを作ったのは誰だろう? → SIer? もっとマーケに関心のあるプレイヤーでは? 広告代理店とか (事業概要:自社)。
太字で記述したのは設問ア、イで求められている項目です。こんな形で、お題として与えられたシステムから、逆方向にニーズを遡って想起していくと、論文設計の基本的な所はざっと埋められるようになります。
もちろん、受験者がこれらの情報を直接知っているのであれば、そのまま記述すればいいんですが、知らなければこうやって妄想力を働かせ、自分が携わってきたシステムの 『事業上の必要性』を浮き彫りにして論文設計 することで、ITストラテジスト午後Ⅱの論題とひとまずは渡り合うことができるはずです。
こうしたビジネス上の必要性に迫ることなく、単に『システムを導入しました、効果はこんな感じでした』程度だと、多分勝たせてくれないんじゃないかなぁ…と思います。
"分析"を示す
事業課題の次に考えるべきなのは、ITストラテジストとして、どのように吟味、検討、分析したかということでしょう。大抵設問イのメインの質問事項です。
特に事業環境、投資効果、実施結果等の 分析については、IPAのページにもある通り『期待する技術水準』にはっきり示されています1。
https://www.jitec.ipa.go.jp/1_11seido/st.html
(1) 事業環境分析、IT動向分析、
対象となる事業・業務環境の調査・分析を行い、
で、求められる分析の中で意識すべき分析が2種類あってですね。
- 効果分析
- その戦略を実行することで見込まれる投資効果や、実施した結果得られた利益など。
- 市場分析
- 参入する市場や自社、他社の立ち位置を含めた環境分析。主として問3で多く求められる。
効果分析
例えば先程の問2だと、
設問イ 設問アで述べた事業戦略を実現するために…(中略)検討したビジネスモデルまたはビジネスプロセス、利用者の便益、投資効果を明確にして、800字以上1600字以内で具体的に述べよ。
『投資効果』を『具体的に述べよ』なので、コスト削減万歳とか、市場拡大で爆益とか、そういうフワッとした話をしているわけには行かなくなります。数字で出さないと具体的とは言えないでしょうから。
これについても、最初から数字を持っていれば、それをそのまま書けばいいんですが、持ってない場合は、投資判断に必要なレベルである程度数値を作ってしまってもいいと思います。
例えばさっきの『画像認識を用いたリテール売り場向け顧客行動分析システム』の例で書くと。
イニシャルコストはカメラとクラウドへの回線接続料 1店舗当たり100万程度
A社システム構築費用は店舗数で分散させて店舗単位で賦課 1000店舗導入させて店舗当たり100万程度
顧客側のランニングコストは1店舗当たり月数万程度、A社運用費を増分して月額20万程度
顧客側の改善効果は1店舗当たり月150万円程度を見込み
よって初期投資費用が店舗当たり200万程度を要するが、顧客側の改善効果が月130と非常に大きい
A社側では無駄なダイレクトメールを打たずに済むので、全体で月50万程度のコストを低減できる
A社側の収益は初期費用100+ランニング15万/店舗、かつ月50万のコスト削減だが、店舗数が少ないうちは旨味が少ない
A社側のシステム構築費用回収は店舗展開速度次第だが、A社は小売り業の顧客を多く抱えているので、水平展開すれば数年で回収可能と試算している
この数字が事実かどうかはさておき、とりあえず収支がプラスになりそうな目論見、ってのは分かるんじゃないでしょうか。よほどおかしな算数をしていない限り、これが事実かどうか、結局の所採点者に判断する術はないのですから。
きちんと数値ベースでシステムを検討して投資判断をできるかどうか、裏付けする数値を出せるかどうか、というのは、具体的に述べよ、という題意から見ても重要なので、怠りなきようにしましょう。
市場分析
これは組み込み系問題の問3でよく出てくる分析です。
例えば2018年度問3。これはテーマそのものが市場分析です。
問3 組込みシステムの製品企画戦略における市場分析について
2017年問3。
問3 組込みシステムにおける事業環境条件の多様性を考慮した製品企画戦略について
設問イ 設問アで述べた製品企画の際に分析した内部環境、外部環境の各要素を挙げ、それぞれどのように分析したか。
前回話をした、
午後Ⅱを分析演習の場とするのです。
の出番はここで、論文演習中に、求められている分析を実際にやってみればよいのです。
2018年度問3の設問イを何度かやってみる、というのが面白いかもしれませんね。
設問アで述べた新製品の投入を考えた市場について、どのように調査したか。分析手法の選定理由、分析方法、分析内容及び立案した戦略について、800字以上1600字以内で具体的に述べよ。
私はIoTセキュリティデバイスを新製品として市場分析を行う演習をしてみたのですが、ここでPEST分析と5Force分析を併用する、という論旨展開を行いました。
そもそもA社にとって当該デバイスの投入は、過去に類を見ない新製品開発であり、市場の評価自体が存在していない。このため、投入市場そのものの周辺環境を調査したうえで、まずは開発投資に値するか否かを見極める必要がある。このためにPEST分析を用いてIoTデバイス市場自体の将来性を検討する。
次いで、当該デバイスはセキュリティの汎用部品であるため、具体的な応用用途が存在しない限り、需要を想起しづらい。よって、売り手としては需要が発生し得る産業分野を特定し、当該産業分野に対する販促活動や技術蓄積を行うことで、速やかに、かつ確実な市場収益につなげる準備をしておく必要がある。よって、候補となる産業分野を絞り込むために5Force分析を行った。
分析手法は他にもアンゾフのマトリクスとかSWOTとか色々あるんですが、外部分析を伴う分析手法を展開したほうが、自社の独りよがりになりづらいので良いと思います。
結果を作ってみる
で、実際にやったかのように結果を作ってみます。
ガチで調査会社に頼んでリサーチする必要はありません。5Forceなら、現在の自社の立ち位置を流用してもいいですし、PEST分析なら、Google先生に動向を聞いてみるのもいいでしょう。
例えば、Google先生から得られた情報や、IoTセキュリティに関する資料を読み込むことで、こんな感じで実際にPESTを行ったかのように論旨展開することができます。
結果、以下の傾向が明らかになったことから、IoTセキュリティデバイスは、市場から需要が発生する可能性が高いと見極めた。
・E:IoTにおける産業界の投資が活発になっている。
・S:Miraiに代表されるようなIoTセキュリティ攻撃が活発化し、社会不安が増大している。
・T:Webセキュリティ等のソフトウェアセキュリティが、ハードウェアのバックアップを必要とし始めている。
PEST分析の結果をこうして論文に書こうとすると、PEST分析がどういうものか、よく考えて記述することになると思うんですよ。分からないと頓珍漢な論文になってしまいますから。
こんな感じで、実際に分析結果を作るときに、分析手法が肌感で分かるってわけです。分析手法が今ひとつ頭に入らない、って人は、こういうきっかけを作ると論文事例蓄積も兼ねられてお得なので、お試しあれ。
経営陣との対話
最後の関門はこれです。大抵設問ウで、面倒くさいオジさん連中に目論見を説明して、フィードバックを受けることになります。
設問ウ 設問イで述べた新サービスにおいて、新サービスの導入でどのようなことを検証するためにどのような対応策を立案し、経営層に提案したか。
ただ、経験がなければここは結局ロールプレイです。
経営層と話をしたことがある人であれば、その人の顔を思い浮かべながら、自身の職場でどういう趣旨で資料をまとめ、どういうフィードバックが得られる 『であろうか』 を想起しながら書くことになります。
私も役員クラスと話をしたことは数回しかなかったのですが、
- 基本的に経営層は技術そのものには全く関心を示さない
ので、何を伝えるにせよ、予算、会社の立ち位置、体制、収益のようなレイヤで話をすることになろうかと思います。
個人的に気をつけていたのは、
- 自身の立てた戦略、目論見が満点である、という評価には絶対にしない
ことですかね。他人なんですから絶対考えの相違はあって、経営視点からの何らかのダメ出しはあって然るべきもの、として評価を記述するようにはしていました。
いわゆる 『打たせて取る』 戦法で、このダメ出しを受けてフィードバックとして自身の目論見を改善した、という流れにすると、話としては自然ですし、オレオレストラテジストではないことを暗に示すこともできます。
論文スキルの高いライバルとの戦い
これについては正直なところ、楽に勝てる方法はありません。
システムアーキテクト試験の論文の記事で示したような、論文設計の基本を身に着けた上で試験に臨む、ってのは当然なんですが、正直な所大半の人間がその辺を弁えた人たちなので、差別化要因にならないんですよね。
私から何が言えるだろう、と思ったんですが、強いて言うならばこの辺でしょうか。
- 空気のように読み、空気のように書ける ようになっておくのが最強。
- たくさん本を読み、たくさん文章をアウトプットすること。
- 要は国語力を鍛えよ、ということ。Blogを書き続けていたら論文パスした、って人もいましたが、おそらく両者には大きな相関があります。
- 今回、私がどれぐらい空気のように書けたか、というのは、本試験でやらかしたヘマも含めて後でご紹介します。
- 設問で聞かれていることを 題意を外さず、漏れなく答えること。
- おそらく論文評価C以下の人は、設問で聞かれている事項に対して『題意を外しているか』『漏れがある』んじゃないかと推察しています。
- 自分が言いたいことではなく、出題者の聞きたいことを答えてあげましょう。手持ちのネタを出題者の聞きたい内容に合わせて書けるようになりましょう。
- HowよりもWhy,Whatに重点を置くこと。
- ITストラテジストの場合は、具体的な要素技術、実装方式ではなく、企業やユーザが欲しい物 の話をしましょう。例えば収益、新しい仕事、新しい市場、利用者の便益などです。
- 良きストーリーテラーになる こと。
- システム監査技術者以外の試験には、大抵流れがあるんですよね。現状→受験者が実施したこと→内外の評価とフィードバック、という。
- この流れを自然に伝えられることで、論文がある種の物語性を帯びるようになり、読み手の頭に入りやすくなります。
- 自然に伝えるためには、以下のことが重要になってきますが、一言で言うと 『読み手のことを考えた文章になっている』 かどうかです。
- 事実を必要なだけの言葉で過不足なく伝え、
- 前の文章と後の文章に連続性がありつつも、
- 段落で話題が区切られており、
- それぞれの行動に必然性がある
まぁなんと言うか、『合格したければ、合格できる実力をつけることだよ』みたいな、言われる側からすると何の役にも立たないアドバイスをしているような気もしますが…論文スキルという話をするなら、結局のところ、
- 事実でない事項も含めて、いかに自然に、論理的に相手の頭に文章を入れるか
ってことでしかなくて、結局は論理的文章の記述力に帰着してしまいます。
私は毎回これを培うために、試験1回あたり大抵10本ぐらい論文作成をしています。結局の所練習は嘘をつかないんですよ。
ただ、どうしても文章が苦手でしょうがない、って人は、先述した『合格論文の書き方・事例集第5版』を最初の足がかりにすると良いです。
Blogを書くなり、自分のペースで毎日文章をアウトプットしてもいいでしょう。
その上で、上手な文章を書きたくなってきたら、この本をおすすめします。
- 作者:結城 浩
- 発売日: 2013/04/11
- メディア: 文庫
- 作者:結城 浩
- 発売日: 2014/12/12
- メディア: 文庫
『数学』とありますが、技術文書全般に通用する名著です。最初は意識しながらだと思いますが、型が身につくと、良い文章が自然に出てくるのではないでしょうか。
こんなことを考えながら、前述の通り10本(PC5本、手書き5本)ぐらい書いて本試験に望みました。
これだけ書いてまだ書き足りないことがあるような気もしますが、気がついたら適宜補足します。
いやー長かった。以下次号。