社会人になってから高等学校の情報の教員免許を取得する道のり（出願編）
ひょんなことから、高等学校の情報の教員免許を取得したく、そのことを書きかき。
私は、大学卒業時に高等学校の数学の一種免許状をGETだぜしているので、科目等履修生という枠で免許を取得する。
いつから準備しておけばよいか
科目等履修生なら、２月下旬から動けばよい。（シラバスの公開がそれくらいなので）
後期入学OKの大学なら７、８月ごろかな？（シラバスはもう出来上がっているとは思う）
募集要項の取り寄せや証明書の発行、教育委員会に行く人は行く時間の調整とか、そういうのに時間を要するので明日からGOとかはちょっと難しいかも。
大学生になるなら、それは別途準備を！
教員免許の取得に必要なもの
ずばりは単位！（社会人になってあまり聞かない単語）
教育職員免許法 | e-Gov法令検索
ここの法律を要チェック。
18歳未満はだめだよとか、中卒はだめだよとか（大学受験できる状態ならよし）、いろいろな資格がある。
短大や大学で教員免許取った人だけじゃなくて、臨時免許状とか特別免許状とか発行してもらえれば教師として働けるとか、実はな話もある。
実際に臨免で働いている先生に会ったことがあるので、実は自分もそういう人に教えてもらっている可能性はあるかも・・。
とはいえ免許状が違うからと言って、指導のレベルが変わるかといわれると関係ない。
授業うまい人はうまいし、下手な人は下手。なので、「えっ、心配！先生の免許の種類を聞かなきゃ」とかはしなくてよいと思います笑
そんなわけでどの免許でも持っていれば、教師として働ける。
ざっくりと、以下の条件で各免許GETできる。
- 専修免許状
大学院卒で、それ相応の単位を取得している
or 一種免許状を保有している人が追加の単位を取得する - 一種免許状
大学卒で、それ相応の単位を取得している
or 二種免許を保有している人が追加の単位を取得する - 二種免許
短大卒で、それ相応の単位を取得している
他にもすでに他教科の免許を保有していると、取得しないといけない単位数が変動したりとか、そんなこと書いてある。
別表第三（第六条関係）見てみると、
なので、必要な単位は免許持ってない人よりも少ないですよ、24単位でいいですよ、ということ。
単位はどこに落ちてるか
単位は落ちていません。取りに行きましょう。
高等学校教員（情報）の免許資格を取得することのできる大学：文部科学省
私は働きながら取得したいので、科目等履修生＆通信という道を選ぶ。（他教科取得なら大体科目等履修生でOK）
科目等履修生は読んで字のごとく、科目を履修するだけで学籍を置いて卒業という称号を得ることはできない学生種別。
大学教務システム作ってるときに、このデータにどれだけ悩まされ・・（略）
通信はとても少ない、関東にほぼ集中。
私はこてこて関西人なので、迷わず佛教大学を選択。
通信も数回はオフライン授業があるので、近い方がおすすめ。
数回程度なら旅行感覚で、というのもあり。
今はオンラインで出願可能で結構HPに情報はいっぱい載ってるが、念のために募集要項はもらっておいた方がよいと思う。
いつオフライン授業があるかは、募集要項にぎっちぎちに書いてあるのでチェックもできる。
佛大の場合は１週間かかるって言ってたけど、２、３日で届いた。（単に距離が近かったのかな？）
届いた募集要項を見て出願の準備
ここからは佛大ベースで書くが、たぶんドコモそう変わりないと思う。
用意するものはコチラ
- 写真（スマホで自撮りでOK）
- 履修する科目リスト
- お金
お金は履修する単位数 + 謎のいくらかの手数料によるけど、私の場合は20万チョット。
履修する科目リストは、住んでる地域の教育委員会に指導してもらってね、と書かれているので教育委員会へGO。
教育委員会の窓口はとてもとても空いてる時間が短いので、仕事では有給とか時間給もらって参るか電話するかが◎
私は口頭だけでの確認が不安だったので直接教育委員会へ参る。
この時、佛大の募集要項と成績証明書を持っていったが、全然意味がなかった笑
必要なのは「学力に関する証明書」なので、お間違いなく！
無事、単位指導をしてもらってweb出願が可能な状態に。
ちなみに、私は出身大学でも情報の教員免許を取得している学部があるので、たぶん授業しているとのことで。
そっちの科目等履修生になって単位を取ってはどうかとオススメされた。
数学と情報が近い科目らしく、既に取得している単位と科目被りしている可能性が高い。と言うこと。
強くてニューゲームにするか、はじめからセーブデータ作るか、みたいな選択に悩んだ末に佛大にした。
リアルキャンパスに行くのは、働きながらだとどうしてもきついな、と思い通信の佛大に！
※コロナだとオンラインかもだけど。
※教育委員会の人も京都の大学と思ってたかもしらないが、理系は滋賀だからな！！つらみ
Let’s web出願
基本迷うことはないので、入力をサクサクしていく。
決済画面まで行って、入金したら出願は完了。
※なぜか一回目、電話番号間違えてコンビニで入金できず、詰んでしまった。
入金しなかったら、出願は完了しないので放っておけばよき。
さいごに
通信よりもオフライン授業受ける方がいいんじゃない、とか、そんなんで免許取れていいの、とかそんな意見もありそうよね。
まあ法律でOKってなってるので、OKなんですけどね。
どんな形式でもメリットデメリットあるし、最後は勉強する意欲によるのかなと思う。
（大学生の時は眠たいとスヤァしてしまうし、単位くれる先生探しとかしてしまうし、そんな苦楽を共にした友人もちゃんとよき教師として立派に働いてるし）
人生お金があれば、教育に関してはある程度やり直せると思うので、「あー、とっておけばよかった」と思う人はちょっとでも私の経験談が参考になれば幸いです。
SQLServerの大文字と小文字区別しないので、単純にLIKEで検索してみたら思っていないものが引っかかる
あるあるですが、たまーに忘れてデータ調査するときに、欠落していると困る内容。
改めて、整理してみる。
公式ドキュメントはコチラ
docs.microsoft.com
2021/3/2時点では、SQL Server (サポートされているすべてのバージョン) とAzure SQL データベースが対象。（つまりはすべて）
事象
SteakTable
| ID | NAME |
|---|---|
| 1 | NIKU |
| 2 | niku |
| 3 | NINNIKU |
| 4 | ninniku |
| 5 | NinNiku |
| 6 | ninNiku |
| 7 | DemiSource |
SELECT * FROM SteakTable WHERE NAME LIKE '%NIKU%';
結果
| ID | NAME |
|---|---|
| 1 | NIKU |
| 2 | niku |
| 3 | NINNIKU |
| 4 | ninniku |
| 5 | NinNiku |
| 6 | ninNiku |
デミグラスソース以外がとれてしまう。
本当は、1のNIKUと3のNINNIKUが欲しいのに。。
原因
SQLServerの初期設定で、大文字小文字は区別しない設定になっている。
※公式では既定の照合順序と呼んでるそうな
区別したいんだぁ、と思ったときに解決方法としては３つ！
DBの設定を変更
新しいDBの場合
[データベース] > [新しいデータベース] > [オプション] > [照合順序]
一覧から照合順序を選択
既存DBの場合
[プロパティ] > [オプション] > [照合順序]
一覧から照合順序を選択
カラムの設定を変更
docs.microsoft.com docs.microsoft.com
新しいカラムの場合
CREATE TABLE dbo.SteakTable ( ID INT ,NAME NVARCHAR(50) COLLATE Japanese_CS );
CaseSensitivity CI を指定すると大文字小文字は区別されず、CS を指定すると大文字小文字が区別されます。
AccentSensitivity AI を指定するとアクセントは区別されず、AS を指定するとアクセントが区別されます。
濁点や半濁点のこと
KanatypeSensitive このオプションを省略すると、かなが区別されません。KS を指定すると、かなが区別されます。
ひらがなとカタカナのこと
WidthSensitivity このオプションを省略すると、文字幅が区別されません。WS を指定すると、文字幅が区別されます。
半角や全角のこと
Japanese_の部分
| 照合順序バージョン | 指定文字列 |
|---|---|
| 100 | Japanese_XJIS_100_ |
| 90 | Japanese_90、Japanese |
SQLServerのバージョンによって、照合順序バージョンも違うので指定にはサーバーのバージョンごとに気を付ける。
検索するときのみ指定（個人的にはこれ）
SELECT * FROM SteakTable WHERE NAME LIKE '%NIKU%' COLLATE Japanese_CS;
結果
| ID | NAME |
|---|---|
| 1 | NIKU |
| 3 | NINNIKU |
さいごに
公式ドキュメントってわかりにくいと思うのはワタシだけか
我思ふ、【AP】応用情報技術者試験と【SA】システムアーキテクト試験に合格するに必要なことは
基本情報技術者試験のこと書きまして、何を隠そうその３年後に応用情報技術者試験に合格し、シスアキそのあとすぐＧＥＴだぜ！したので、その時のことを書きかき。
▽基本情報技術者試験のやつはこれ
我思ふ、【FE】基本情報技術者試験に合格するには何が必要か - やまみの雑多ブログ
ただ応用もシスアキも2018年に取っており、情報としては古いので参考にならないかも。
そして、今回も性懲りもなく午前しか勉強しておらず。
そして、2017年秋期に応用を受けたのですが、一度落ち笑
その失敗の原因と対策込みで、書きかき。
※改めましてお断りしておくと、資格取得を保証するものではないです。
※問題の傾向や出題形式はしっかりIPAのページでチェックしてください。ここには詳細厳密には書きません。
結論
- ちゃんと早起きする（基本情報技術者と同じ）
- 毎日コツコツ過去問を解く（基本情報技術者と同じ）
- 問題を選択する（基本情報技術者と同じ）
- 基本情報と違って、甘くないからもう少し早めからスタートする
- どこかにアウトプットする
- 高度の資格は応用情報技術者試験と間隔開けずに受験する
- 毎日の仕事は当事者意識をもって向き合う
基本と同じことは書かないので、（基本情報技術者と同じ）はそちらのブログで。
我思ふ、【FE】基本情報技術者試験に合格するには何が必要か - やまみの雑多ブログ
応用で勉強に使ったサイトは道場
www.ap-siken.com
シスアキは道場がなかったので適当な過去問アプリ（ちょっとアプリ名忘れました）
その１）勉強のペース
基本と同じく、早めに開始しても失速はするので、早すぎず遅すぎず始めること。
私は応用情報は基本情報と同じノリで２ヶ月前に勉強開始して、落ちてしまう笑
むしろ、いけるだろ、と思い本気でやり始めたのは１ヶ月前だったので本気で時間が足らず。
覚える量と専門性は格段にレベルアップしているので、同じ期間では無理。
実務経験がある人は最遅でも３ヶ月前から、ない人はかなり努力をする時間が必要かと。
私は通算５ヶ月は勉強。（落ちた時２ヶ月、受かったとき３ヶ月）
※システムアーキテクトは問題数少なかったので２週間くらいで何とかなりました。ここでは主に応用情報のことを書いてます。
ごりごりプログラミングしつつも、企画・設計・構築・テスト・運用保守をするようになっていたので、幅広くテクノロジには自信があった。
が、専門用語はなかなか仕事で使わず、テクノロジでもかなり苦労。（社内ならまだしも、非エンジニアのお客様相手にそんなこと言わないので・・。社内でも専門用語ばっかりで喋るわけではないので。）
更に、マネジメント、ストラテジがただの暗記じゃ覚えきれないくらい、知らない単語だらけで難しい。
ゆえに、基本情報の知識も使えるが、応用情報技術者試験ではより多くの知識をインプットする必要があり。
その２）アウトプット
インプットの量が基本情報に比べて多いので、さすがにアウトプットしないと身につかない。
私の場合、一緒に応用情報受ける友人がいたので、お互いに自分の新出情報を説明しあうということで対応。
相手が知らないと一緒に学べたり、友人のコメントからその情報にストーリーがついて情報自体が意味を持って覚えられたり、かなり効果的。
基本情報を受ける前に先輩と雑談をしていて、「師匠の俺から一つ知識を与えよう」と言われDHCPについて教えてもらったことがある。
字面では覚えていたが、あまり知識が定着していなかったことにも気づけたし、たまたまその問題がその年の新出問題で出てきた。
※ちなみにDHCPは過去問でなかっただけで、知識としては範囲内です。（DHCPは特に、たいそれたものではありません。）
※私の中ではDHCPはただのDHCPではなく、先輩からいただいた大切な知識としてストーリー付きで今も強く記憶に刻み込まれている。（DHCPは特に、たいそれたものではありません。）
誰かに共有したり、誰かから教えてもらうのは定着しやすいと個人的に思う。
twitterなどのSNSで知らない人と協力できるコミュニケーションお化けは、お好きな人と、SNS苦手人間はリア友とか仕事場の人とか密に連絡取れる人を個人的におススメ。
私はテクノロジが得意で、友人はマネジメント、ストラテジが得意だったので、お互いに教えあったりできたのもよき◎
その３）高度の試験
高度には午前１、２、午後１、２と試験が４つある。
応用を取ると素敵な特典、高度の午前１を２年間免除できます権をＧＥＴできる。
そして、高度の試験をパスするとさらにそこから２年間免除できる。
そのため、多くの人はIPA資格ＧＥＴフィーバー状態になれる。（取るだけの資格は意味ないな＋コロナで試験が中止になり、私はもう受けることを辞めましたが。。）
高度で経験を積んで、取得できるレベルまで達していても、午前１で落ちる人がかなり多い。
午前１は受けたことないけど、応用情報レベルの知識を求められるので、そこが一番ハードルが高い。
午前１は広義的な範囲のため、苦手な分野も勉強が必要となるが、午前２、午後１、２は比較的範囲も問題数も少ない。
なので、フィーバー状態だと専門性があれば受かる状態なので、高度取るなら段階を踏んでまずは応用情報を取るのが◎
その４）仕事の向き合い方
私が受けたシステムアーキテクト試験は
- 午前２と午後１がこれまでの選択や読解でどうにかなるタイプの問題
- 午後２がみんな大好き論述問題
前者の方は応用情報技術者試験とそう変わらず、知識のインプットで何とかなるが午後２は普段の仕事のアウトプットとなる。
問題は後者の方が重要。
論述には3つの課題がある。
- 論述の書き方
- 問題の選び方
- 問題に解答できる経験
論述の書き方
わからない人はシンプルに勉強するしかない。
私は大学の英語の授業でも、教員採用試験対策でも、論述の対策をしたことがあったので、その時の思い出を流用。
良し悪しは知らないがざっくり、以下の構成を定型にしてます。
①最初に結論、そのあとに理由を２つくらい
②1つ目の理由詳細
③2つ目の理由詳細
④まとめと改めて結論（①と少し言い換え）
これがいいかは知らないが、道も逸れないし、収まりもいいし、大体どこのブロックを何文字書けば、最終的に何文字書ききれるかわかるのでこのパタンを使い続けている。
800文字の時は、200/250/250/100とかそんなボリューム感をイメージして書く。
あと書き始める前に、①②③④のそれぞれのキーワードと大体の流れはメモしてから文章を肉付けしていくとそれらしくなる。
時間は惜しいけど、最初からやり直しにならないように最初の５分で問題の理解、次の５～１０分で準備、残りで書くべし、書くべしとしてる。
オラ、理系だからそういうの苦手だ書けねぇわって人よく見聞きするが、オラも理系だ。
論述に理系も文系もない。
ただ、この時代に鉛筆で800文字以上書くのが辛いのはよくわかります。試験までに利き腕の筋トレをしておきましょう。
問題の選び方
論述問題は、３つのうち１つを選んで書いていく。
※自分の経験した業務の概要と問題に対する回答をつらつら書いていくので、嘘書くにもつじつまが合うように準備は必要そう。
私が当時受けた問題は「業務からのニーズに応えるためのデータを活用した情報の提供について」「業務ソフトウェアパッケージについて」「組み込みシステムのAI利用、IoT化などに伴うデータの増加量への対応について」の３つ。
組み込み式関係者は、黙って３つ目を、無縁者は２択で絞り込み、１つ目か、２つ目で書きやすい方を選ぶ。
今見てみると、
1つ目はマーケティング要素が強いなと思うので、オープンなシステム、WEB系やアプリ開発者の人は書きやすそう
2つ目は基幹系の人が書きやすそうと思う。
私は当時は大学教務システムの開発をしていたので、2つ目を選んだ。（当時の自分は判断力がGood Jobでした）
たまたま運よく書きやすい問題だったわ、と思っていたが、絶対に自分の関わっている開発はどれかに当てはまっていることが多い。
改めて見てみると問題は抽象的で範囲が広いものがあるし、どんなシステムでも大体引っかかるんじゃないかって思う。（どんなシステムにも大体同じ課題がある）
自分の経験をアピールしやすい方を選択できるといいので、自分の携わっているシステムの理解と今までどんな課題をクリアしてきたかは説明でき、考えを持っている必要がある。
問題に解答できる経験
悲しいことによく見かける高度の試験対策に、「こんなん経験ないから、捏造してそれらしいこと書きましょう」とか「こういうの書けるのって、リーダー職についてないと無理じゃね」とか書かれてる。
確かに、１、２年じゃ、なかなか書けないかもな、と思う。
※取る人あまりいないと思うけど、未経験じゃ絶対かけないと思う。
でもでもでも、私は実務経験２年で取ってます。
なんで取れたか、っていうと、自分が関わっているシステムに当事者意識を持って関わっていたことが一番書ける経験につながったと自負してる。
2年で任される仕事は知れてるかもしれないけど、首突っ込みまくったら、「若いなぁ、お前（ニヤニヤ」と先輩や上司はいっぱい教えてくれる。
結果、先輩からシステムのこと聞かれるくらい、システムマニアになり、
色んな課題に対するアプローチも知れるし、お仕事も任せてもらえる範囲広がるし、いいことばっかり。
自分に経験がなくても、そのシステムは歴史があるから、その歴史ごと自分の経験になる。
要件定義まとまったので、それに倣って、設計書書きかきしてます。だと、確かに書けない。
設計書回ってきたから、その通りに作ってます。だと、確かに書けない。
出来上がったやつがアップされたから、とりあテストしてみました。だと、確かに書けない。
別に知らなくても、どの仕事もこなせるかもしれない。
ここは、資格取るためじゃなくても、自分が作っているって自信をもって、どんなシステムで、どんな環境で動いてて、どんなお客さんが使ってて、どんな課題を解決するために設計・コーディング・テスト・導入してて、などなど
そういうこと普段からキャッチすることが誰かに語れる経験になる。
つきましては、それが論述で書ける経験となる。
信じなさい、信じなさい
とにもかくにも、自分が携わっているシステム、今の仕事を誰かに語れるくらいは理解するのはどの工程にいる人にも重要なことと思います。
さいごに
システムアーキテクト試験に合格した時に、自分は何のために資格を取ったんだろうと虚しくなりました。
IPA資格フィーバー状態で、次はDBとかPM取ろうかな、とか消化試合のように思ってましたが、今の自分にはよくないなと思い辞めました。
資格取るだけなら、傾向と対策、あとは時間でなんでも乗り切れると思いますが、身になる知識と使えるスキルの習得が重要だなと思います。（当たり前やけど、気づかず当時の私）
その過程の資格試験なら問題なしですが、私のような（インセンティブ狙いの）資格取得は全くおススメしません。
ただ、ほぼノー勉でシスアキ取れたのは日々の仕事との向き合い方だったと思うので、仕事の仕方ってところで、資格試験以外にも参考になれば幸いです。
我思ふ、【FE】基本情報技術者試験に合格するには何が必要か
twitterとかに基本情報技術者のお話がちょこちょこみられて、久しぶりに取ったときのことを思い出して書いてみる。
ちなみに私がとったのは2015年秋期なので、時代は移り変わりまったく参考にならないかも。
あと、応用情報技術者試験（AP）は2018年春期、システムアーキテクト試験（SA）は2018年秋期に取ったので、その時のことも別で書きます。
一つ要注意事項としては、私の資格は本当に傾向と対策って感じで取ったので、本来の目的は達成できてないです。
ちゃんと知識を身に着けて！という人は他の人の経験談を参考にする方がいいと思う。
資格だけ取りたい人向けです。
※お断りしておくと、資格取得を保証するものではないです。
※私は午後の勉強は基本したことないので、それも込み込みで違うと思えば参考にしないでください。
結論
- ちゃんと早起きして、会場に行く
- あまり早めから頑張らない
- 毎日ちょっとずつでもいいから、過去問を解く
- 自分の得意を理解して、問題を選ぶ
本当にこれだけで合格します。（詐欺っぽい、「しました。」が正しい）
でも、「私の場合は」ってところと「ポイント」を書きかき。
その１）早起き
これを一番初めに書くくらい、多くの人間が受験すら来ない。
多分、お金を寄付してる心優しい人たちなんです、きっと。
来てない人が３，４割な気がするので来てる人のほとんどが受かってると思う。（※個人的な意見です）
合格したいなら、とりあえず、会場に行くべし！！
その２）勉強ペース
ワタシとしては、早めに始めると失速して試験まで頑張れないと思っている。
最初って意欲あるから頑張れるけど、
- 途中で忙しいとか
- ちょっと忘れちゃったとかで途切れて
- そこから勉強捗らず
というのはありがちのイメージ。
なので、２ヶ月前くらいから午前の過去問やりまくるスタイルをレコメンド。
これはその人の状況によると思うので、私の状況を少し伝えると、
- 2015年4月に、未経験でソフトウェア開発会社に正社員で就職（駆け出しエンジニアってやつ）
- 就職した先はみっちりコーディングの基本を研修で６か月教えてもらう
- オブジェクト指向だとか、カプセル化だとか、で、その言語のC#、Javaだとか、最後はＳＱＬ学びーの、一つ基幹システム作る
なので、実務経験なし状態で資格に挑んでいる。が、研修で試験に出る技術的（テクノロジ系）の一部は理解している。
スクール行ってる人とか、実務でコーディングしてたり、DB触ってたりする人はある程度の知識が身についていると思うので、同じような準備でいいと思っていいる。
例えば、実務経験なく、経験も乏しい人は１，２ヶ月でやるには暗記力の勝負になりそうなので、もっと体系的に先に学んだほうがよさそう。
その３）勉強方法
冒頭にも書いている通り、私は午後の勉強はしていない。
午前で知識をぶっこんで、後は日本語読解力で乗り越えた。
答えは、問題に書いてあるパタンが午後の問題は多い。
普通に読んで、少しの論理的思考で6割は超える。運転免許証みたいな感じ。
超えない人は、読解力が低いか午前で勉強した知識を引き出しにしまってるだけで、取り出せていないと思う。
なので、午前の勉強法でおススメのサイトを紹介
www.fe-siken.com
無料で使えるし、使いやすいし、スマホでできるから通勤中とか暇なときにちょこっとしやすい。
私はずっと電車通勤だったので、往復で一日30分は問題を解いていた。
土日は少しリッチに１時間していた。試験が近づいてもこのペースは崩さず。
- 全部を指定して、１ヶ月間ぶん30分でもいいので、毎日回しまくる
（ソシャゲの新規ユーザーになったときみたいなね） - １年ずつ指定して、最新５年分くらいを試験までに正答率8割超えるまで続ける
やってると気づくけど、基本情報技術者試験はほとんど過去問と同じ問題が出るので、問題の答えを覚えるようになっちゃう。
新しい問題は毎回１、２割くらいしか出ないので、過去問をしっかりすれば、午前のボーダーラインの６割は余裕で越えられる。
傾向と対策で覚えて試験を受けるもよし、問題と解答についてしっかり理解してインプットをするもよし。
資格を取るという目的か、知識をちゃんと身に着けるという目的か、大きく分かつポイントだと思う。
その４）問題の選択
午前も午後も、そもそも問題の傾向が分類されている。
分類として、テクノロジ系、マネジメント系、ストラテジ系の３つがある。
細かいのはシラバスをちゃんと読んだ方がいい。どんなものが出るのか、ってのをせっかく書いてもらって入りうのでちゃんと見た方がよい。
※わざわざ、どういう魔法が弱点のモンスターが出てくるかわかるんだから、メモメモしておいた方が物語は進みやすいでしょう
ざっくりいうと、
- ゴリゴリプログラミングしている人はテクノロジ系の理解はしやすい
- SEやディレクタで企画をしたり、PJを管理したり、進行管理をしているとマネジメント系、ストラテジ系の理解はしやすい
でも、割合としてはどうしてもテクノロジ系が多くなるから、どんな人も理解しておく必要がある。
逆に、ゴリゴリプログラミングしている人もマネジメントやちょっとした法律についても理解しておく必要がある。
合格するなら、自分の得意なこと以外にも苦手なことも理解する必要があるが、６割取ればよいと割り切るなら取捨選択した方がいい。
私の場合、ストラテジ系の財務や法務は全く頭に入らず、ほぼ暗記で乗り切った。
テクノロジ系の計算問題はどうしても理解できないって人は、計算問題は諦めて、DBの少しの知識を入れるとか、オブジェクト指向の理解を進めるとか、他のところでカバーするがよし。
で、午前の理解は必ず午後につながる。
午後もセキュリティが必須？で、他は選択できるので自分が得意とするものを選択する。
ゴリゴリプログラマよりの私はDBとプログラムは絶対に選んで、あとは簡単そうな問題を選ぶようにした。
日本語を読めば解ける問題が多いので、苦手なものでも問題を見てこれわかりそう、って思ったら選択する。
組み込み系とは無縁の人生でも、内容をよく見るとただのアルゴリズムを考えるだけの問題だったり、マネジメントしたことないけど、普通に文章読解するだけの問題だったりするのでそこは見極めてチョイスする。
さいごに
お気づきの通り、資格試験では対策本とか買ったことがなく、傾向と対策で何とか合格してる。（嫌味に聞こえたらすみません）
仕事で学んだことがかなり活きているので、バッチリみんなに当てはまるとは思ってない。
プログラミングしたことのない、SQLも書けない友人は、テクノロジ系が全く分からず、何度も落ちてたので大きな割合を占めるテクノロジ系が苦手なのは確かにつらみと思う。
ただ得意と苦手を見極めながら取捨選択して、対策しっかりすれば誰でも取れる。（友人もちゃんと最後は受かってましたので、プログラミングしてないと取れないわけでもない。）
この資格を取るってことは何かしらＩＴに関わりあると思うので、得意や知見は少なからずあるはずでそこはしっかり極めるべき。
その上で、自分の仕事では知らないこともすんなり頭に入ったら、その分野を深めて好きと得意を増やすのがいい。
あとは私の場合、大学受験の感覚も若干残っていたので、センター試験とか大学受験の読解力は活きた。
理系だから文章読むの苦手、文系だから数字苦手、とか言ってたら仕事はどちにしろ大変と思うので、苦手との付き合い方というのも大切と思ふ。
【読書感想文】なんでも図解 絵心ゼロでもできる！爆速アウトプット術
www.shoeisha.co.jp
ITエンジニア本大賞2021のビジネス書部門大賞の「なんでも図解」読んだのでかきかき。
プレゼンされた本はどれも魅力的なので、他も読む予定。
ざっくりと紹介
著者の日高さんがとても素敵なプレゼンをされてたので、特に読むまでもない人はここスキップで。
主人公の田中くんが 異動してミーティングや企画がうまくいかない
→めちゃ図解で話をスイスイ進めて、決めていけるパイセン見る
→パイセンすげぇっすね、とすぐ聞く
→パイセンが人を紹介してくれる
→図解の術を教えてくれるえんま先生登場
そこからは、えんま先生がいろいろ教えてくれつつ、志高き田中くんが読み手に変わって質問してくれたり、FB受けてくれたりする。
図解と書いているだけあって、そもそも図が多くてわかりやすく、読みにくいところは一切ない。読みやすい。
後半はハンズオンで進めていけるので、頭のイメージだけでなく読んでる時点でアウトプットができる。
日高さんが当時の自分が田中くんだった、という話をしていて、そのときは、ほぇ～くらいにしか思ってなかった。
けど読んだ後にあのプレゼンが、この本がまさに田中くんの成長なのか！？と思うと感激。
印象に残った内容
持ち帰る前に
自分の認識を可視化して、相手との認識を合わせる。
基本的なことでも、何歳になってもとても重要と思う！
なるほど、わかりました～と言ってプログラム組んで、「おもてたんと違う」って言われてる人を何度見たことか。（ワタシも例外なく）
プログラムだけでなく、設計でも企画でもなんでも認識合わせは絶対に大切。
その上で、自分の認識はこうです、っていうのを言語化だけでも解決できるなら大丈夫だけど、可視化できる方がより情報共有レベルが上がるねと思う。
説得力
- 頭の整理
- ブレスト
- インプット
- プレゼン
こういう時に図解は活かせるよ～というケース4つ。
プレゼンの骨格を作ったりだとか、可視化することで情報が広がったりだとか、漏れている事象に気づけたりだとか、うまみがある。
その中で一番確かにと思ったのは、理解しやすいと説得力が増すということ。
わからないものには納得しがたいし、その場でOKしてもひっくり返ることもある。（その時点で勘違いして了解していて、「おもてたんと違う」となる）
図解ももちろん大切だけど、伝えるときに分かりやすくというのは何事にも意識した方がよい。
雑でよい
色んな説明がある中で、随所に出てくる「きれいな図ではなく、伝わる図を」というコメント。
きれいじゃなくても、伝わるものが書けるんだと思えるし、実際ポイントを押さえればある程度のものが書ける。（教師してる時に知りたかったよｗ）
最後の方に、使えるアイコン集もあるけど、基本が直線と丸で構成されている簡単な図でうまい下手はそんなに出なさそうなものばかり。
これを読むだけでは、正直劇的に図解がうまくなることは難しいと思う。
後半のワークも何度も何度もやって、会議でも実際にやって、ようやく極みの世界だと思う。
でも、ポイントを押さえて、ちょっとずつ実践するだけでも伝える力は、確実に伸びる。
絵がうまくなくたって、いいんだというメッセージを一番強く感じた本で勇気と少しの伝える力を手に入れました。
コンフリクト解消するときに競合したブランチの修正内容が反映されてしまう
手順
困ったこと
なぜ含まれるか、なぜ気づけないか
conflictの解消をGitHubから行うととしているが、別にGitHubで作業していることが原因ではない。
conflictの解消を行う作業として、ops/test_aにdev（マージ先）をマージしている。
※マージしに行く前に、相手の最新の状態を自分に取り込んでおいてマージする
この時に、devに既にマージされているops/test_bの情報が取り込まれてしまう
プルリクのFiles Changedにもdevとops/test_aにops/test_bに関する差分がないので、もちろん表示されず
仕組みを理解していないと思わぬものが混在してしまう
解決策
ひとまずの対応
プルリク main ← ops/test_aまでにこの事象に気づかず、ops/test_a、ops/test_bどちらも数回変更が加わり、devにプルリク＆マージしていた。
revertしてもエラーになってうまくいかず、乏しいGItの知識と差し迫るリリース時間に焦り、以下のようにした。
- ops/test_aは諦める
- conflictの解消前（ops/test_aの変更をコミット＆プッシュしたとき）のコミットでブランチ（ops/test_c）を切る
- ops/test_aで変更した内容をops/test_cに加える
- プルリク main ← ops/test_c
イケてないので、できればconflict解消後にすぐ修正しておくか、そもそも修正内容が混ざらないようにしたい。
競合解決をローカルで実施
ローカルでdevをマージ
$ git merge dev Auto-merging index.html CONFLICT (content): Merge conflict in index.html CONFLICT (add/add): Merge conflict in files/testa/index.html Auto-merging files/testa/index.html Auto-merging files/index.html CONFLICT (content): Merge conflict in files/index.html Automatic merge failed; fix conflicts and then commit the result.
エディタでtestbが見つかる（混入に気づける）
コマンドのほうでももちろん気づける
$ git status On branch ops/test_a You have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort the merge) Changes to be committed: modified: files/testa/index.html new file: files/testb/index.html Unmerged paths: (use "git add <file>..." to mark resolution) both modified: files/index.html both modified: index.html
正しく修正する
～～～～コミット～～～～
混入せずに、マージできるが、ops/test_bの修正内容は当然消える。
ので、再度ops/test_bの修正内容をコミットする必要がありそう。
これで気づかずにマージしてしまうことは防げそうなので、GitHubでコンフリクト解消するよりも、そもそもローカルで解消するほうがよさそう。
わかっていれば、GitHubでもよきかな。
（追記）混在したマージコミットをrevertする
そもそもマージコミットさえrevertできれば、よかったと気づいた
$ git revert -m [1or2] [マージコミットのハッシュ値]
1と2間違えたな～って時は以下で元に戻す
$ git reset --hard HEAD~
revertできなかった理由は、①SourceTreeを使っていたことと②マージコミットであったことが原因そう
SourceTreeでrevertをすると、コマンドを自動生成してくれるけど、通常コミット用のrevertコマンドのようでうまくいかない。
マージコミットには普通のコミットと違って親コミットが２つあるから、どっちの方をrevertするんだい！ってなってしまう。
SourceTreeをうまく使えばできるのかもしれないが、やっぱりコマンドがよさそう。
正規表現でよく使う( ..)φメモメモ
（関係ないけどアイキャッチ画像も作ってみた）
基本的にはいつもググって正規表現使っている。先人の方々、ありがとうございます。
murashun.jp
apacheでIP許可設定するとき
作業するときは以下の素敵ツールを使わせていただく
note.cman.jp
https://www.analyticsmarket.com/freetools/ipregex/www.analyticsmarket.com
