お詫び
タイトルの「哲学の話」はウソになるかも知れません（現在執筆中）
本稿は哲学は専攻どころか独学もやってないど素人が、講師業というテーマで哲学っぽい表現で話します。
とはいえ、無知で哲学と表現するのはどうかな、と思ったので哲学の解説をしている方の動画をBGMに、執筆中に哲学の知識を入れながら書き進めていきます。
本稿の目的
「哲学」というからには、本稿の目的を明確にしておきます。
- アウトプットをして、講師生活で得た知見を思考して自身の中で結論づけたい
- エンジニアは講師をすべきか？という命題を自分に問いかけ、自分の解を見つけ出す
- とはいえ、せっかく時間を割いて読んでくれているのだから、読者にはなんか持って帰ってほしい
と、いうことで完全に読者を置いてけぼりにして勝手にべらべら喋ります。哲学ってそういうものじゃないの？
ところで、Qiitaにおいてポエムと哲学の違いって何なんでしょうね？
よく分からなかったんで、タグには両方いれておきます。
大事な事
- 本稿の執筆に際して公開する目的
- 業界全体としての業務改善、満足度向上が主目的であり、批判の意図は全くありません。
- スクール事業社側が今後このような観点に意識される事で増収または顧客体験の向上を見込めるかの参考になる事を期待しています。
- スクールに入所したい方が、スクールの運営を知る事でスクール選定の参考にしていただける事を期待しています。
- 人によっては有料級の内容である事を、情報商材アフィリエイターの観点でも正しく認識した上で無料公開しており、リスクについて承知しています。
- 本稿の執筆に際して公開する情報について、NDAは既に失効しています（念の為、過去の契約書類などを確認しています）
- 哲学らしく長文なのにオチはありません。許してください
それでは、以下本文です。
発端
今回のアドカレのタイトルを「俺のカレンダー2022」から「エンジニア講師カレンダー」にかえてしまおうかと思うぐらい、講師の話ばっかりしてしまっている事に気付きました。
普段の開発案件と比べると接する人が増えるため、問題が人の数だけ複雑化する関係で印象に残りやすいのかもしれません。
去年も似たような話をしたような気がしますが、今年はよりそんな実感があります。
結論（持つに至った自論）
- 講師とは、一時的にでもエンジニアとしては開発現場から離れるため、エンジニアリングスキル（開発）を伸ばすならやるべきでない
- 講師とは、本当の意味で教育が必要とされる場（学校など）が出来ない専門教育のサポーターであるべき
- 収益化を重んじる現在のITスクール事業において、プロパー講師（スタートアップメンバー）として本当に必要なスキルは「教え方のうまいエンジニア（顧客が説明した要件）」ではなく「エンジニア経験がある、スクールの事業運営に同調できるIT営業」である
エンジニア向けに、エンジニアリングスキル以外（この例では後進育成力）を意識してもらいたい理由
この記事はQiitaアドカレに上げる事が第一目標なので、顧客が本当に必要だったもの（IT営業）ではなくエンジニアに向けて書き進めます。
元々は、きちんとしたポートフォリオとしてサイトを使うなら、個人でサイトを作るより集客力の高いサイトでコンテンツを書いて、類似したものや利用規約的に沿わないコンテンツをポートフォリオ側にまとめつつ、いい感じに作るのがベストだなと思っていました。
それで、去年（正しくは一昨年かそれ以上前からで、アドベントカレンダー自体を作成するのを忘れてしまったという経緯がありました）アドベントカレンダーを書くぞ！と決めていたのがズレて今年から開始した次第だったりします。
まぁ、こういう話はいいんですよ。これ自体に意味はありません。
今回アドカレに投稿した内容は受講生・スクールメイト向けに書いていたり、開発経験があったりなかったり読者の幅を広げつつ色々な知見をお話していたわけですが、その全てに講師になりたい・興味がある方向けにお話している小話があります。
これは「エンジニアも開発スキル以外に目を向けたほうがいいと思っているけど、何を学べばよいか分からない」方向けに「講師という道もあるよ」とステマ提案するものでもありました。
（これは環境故と思いますが、独学で実力をつけて来られた方とメンターに師事した方では講師業への考え方が異なるため、あまり有効な方法だとは感じていませんが、やらないよりはやった方が良いと判断しています）
なお、元エンジニアのIT営業さんは思っている以上に多いです。講師業がある程度固まったら開発やりながらIT営業もやる、みたいな事ができたらいいなぁなんて思ってます。
（スカウト・エージェント各位におかれましては、平素よりお世話になっております）
エンジニアを目指す以上、高度技術を身につけたい！
ですよね？
本稿どころかこのアドカレ自体も、ましてやSNSなんてやってないのでロクに宣伝もしてないですし、知人にすら「読んで」なんて案内も出していません。
そもそもこんな時期にQiitaの、このタイトルを読みたい方なんてタイトルの内容にガチで興味ある方かうっすらとでも転職を考えている方ぐらいだと思ってます。
なので、高度技術を求める熱意は本稿の読者なら当然持っている前提でお話を進めます。
「エンジニアには今も興味なくて、給与を上げたいから仕方なくエンジニアスキル磨いてる」という方も本稿では含みます。
何が言いたいかというと、都合よく意識高くなる系の人間がエンジニアリングスキル以外の話をしますよ、という記事である事を認識していただくと誤解が解きやすくなるかなと思いました。
エンジニアの業務姿勢は理路整然な正しさに勝るものはないが、講師の業務姿勢は曖昧さを残してでも受講生の認知度を優先する事がある
やや運用保守・インフラ畑っぽい事を言いましたが、ここで言及したいのは「人に教える時に曖昧さを許容する」という事です。
この辺りの対コミュニケーションではよくある話です。「話の流れを読む」という事ができれば、説明する時に省略して伝える事は多いと思います。
無理やりコードにしてイメージすると、
/** 運用ルール
* 1. このプロジェクトのオブジェクトは、毎日朝礼会議があり全オブジェクトに下記ルールで運用します。
* 2. 弊社の朝礼は、cronで言うと`0 9 * * 1-5`（平日毎朝9時）です
* 3. 出社については完全フレックスタイム制なので朝礼に参加していないメンバーがいるかもしれません
* 4. 出社したらタイムカードを押して自身をオブジェクト生成できます。
* 5. 誰が何時に出社したかを知る事はできません。
* 6. 朝礼に参加したオブジェクトはPM_userからmeeting_copy()したとみなされます。
* 7. 全てのオブジェクトはtalkメソッドを使えます
* 8. 朝礼に出ていない事で知らない事もあると思いますので、知らない事（変数）はエラーではなく聞いてください（対話しているオブジェクトからもらう）
* 9. PM_userが朝礼に参加できない場合は、他の方が代理でPM_userになって朝礼を進めてください
**/
// 記事化すると口頭フォローができないのでルールを細かく書きましたが、要は普通に出社してミーティングに参加したら最新情報共有されるよね？っていうイメージです。
// これ以上は疲れたので勘弁
// 朝礼
meeting_copy() {
/**
* 1. このメソッドは時間経過でのみ実行する事ができます。
* 2. meeting_copy()を実行したオブジェクトのAモジュールのバグ = バージョンを上げたら動かなくなった件 を初期値とします
* 3. 現実には会議に参加したぐらいで他の人の作業内容まで完璧に理解できませんが、ここは全員優秀だと仮定します
**/
}
// 話に辻褄を合わせたいので、早く来たユーザーを暫定PM_userにしておきます。実務では本物のPM_userが遅れる場合は必ず連絡しましょう。
var PM_user;
var request_user;
var response_user
// 朝礼会議
request_user = PM_user.meeting_copy();
response_user = PM_user.meeting_copy();
// 業務開始
response_user.Aモジュールのバグ += "の修正後のPRで別人に指摘された件"
request_user.talk("{(request_user.)Aモジュールのバグ}って取れたんだっけ？")
// request_user.Aモジュールのバグ = バージョンを上げたら動かなくなった件
response_user.talk("{(response_user.)Aモジュールのバグ}ですか？ まだ終わってないです")
// Aモジュールのバグ = request_user.Aモジュールのバグの修正後のPRで別人に指摘された件
request.talk("(注：暗黙的な{Aモジュールのバグ})終わるのに時間掛かりそう？")
// 他に任せたいモジュールあるんだけど、作業振って大丈夫かな
response.talk("(後述コメント内)たぶん大丈夫だと思いますよ。")
// (注：暗黙的な{Aモジュールのバグ})のPRレビューで言われたところは直したし、レビュー漏れがなければ〜
ここでポイントになるのが、Aモジュールのバグという同じ表現で違う事を指している（＝新卒研修時に「こういう現象が起こるのが多態性だよ、って説明すると結構ウケが良かったのと、筆記試験などで多態性の説明時にすごく印象に残っていて点が取れた、とのお声も多かったです）のに、一見して問題なさそうな終わり方をしています。
今回はどちらもAモジュールのバグを共通認識が取れていて、粒度こそ違えど目的が同じなので問題になりにくいものです。
おそらく、ほぼほぼこんな感じのコミュニケーションをしていると思います。
これがプログラムだと、Aモジュールのバグなんて変数名ではなく、変数展開してきちんとバージョンを上げたら動かなくなった件とかバグ修正後のPR指摘の件といいます。
新規開発とか、機能追加だったらこのレベルでも問題になりにくいんですが、運用中のシステムでデグレなどを起こした場合はこんなコミュニケーション（変数名パターン）をしていたら大惨事になる（修正して本番デプロイが完了したのに同様の問題が再発する）可能性があります。
response側は多少くどいかな？と感じても、認識が合っているか確認するために、敢えて変数展開してrequest側に結果を返してあげてください。
こういったエンジニア間のコミュニケーションが発生する場合は、聞かれた側が重要なキーワードだと思った部分を変数展開して聞いた側に返してあげるように意識するとコミュニケーションエラーがないか相互確認できます。
無理やりな例ですが、こういった厳格さのようなものを、ここでは「理路整然な正しさ」と定義します。
たとえば講師として指導している場であれば、講義時間が無限に使えたり、比較的余力のある状態で講習を進行できるのが理想
議題に上げたい話とは無関係な会話内容の圧縮テクニック
今回は解説用に最低限しか書いていないので、これ以上まとめるのは難しいです。
が、実際はもっと長い文章でのコミュニケーションになる事が多いはずです。
内容や説明が難しいと感じるもの、たとえば３文以上会話をする必要がありそうだなと感じたら、最初に質問への回答をY/N形式か、結論から言ってくれると、聞いた側が楽になります。
また、会話時間そのものを短くする事で、その時間分を聞いた・聞かれた人の他の時間に充てる事ができます。
ここでは「会話」としましたが「講義」にすると、その効果は莫大です。
ただし、聴衆の理解度を担保できていない状態で時間を作って聴衆にアクションを起こしてもらおうとすると、聴衆が何をどうすれば良いか分からず（考え、求められず）学習効果が薄まるリスクがあります。
なお、自分で考えるべき内容と、解説・指導して導くのが望ましい内容と、どちらが良いのかは会場や聴衆のスキルとも相談しましょう。
本題：対入門中エンジニア向けコミュニケーション
「入門中の方向けコミュニケーション」というのが一番言葉の定義が曖昧だと思っています。
- 非エンジニアならなるべくIT用語を使わないようにするか、IT用語は使うけど身近な例に例えてどういうものか説明しながらプロジェクトを推進・調整していくことになると思います。
- エンジニア同士のコミュニケーションは、非エンジニア向けに言えばプロ棋士（将棋・囲碁など）が会話だけで対局・感想戦をしているようなものだと思ってください。
実際のエンジニアは、そもそも話している内容が通常の将棋なのかどうぶつ将棋なのか、はたまた中将棋や大将棋なのか、どの将棋の話してます？ と確認しあいながらやっています。
一般的にいう将棋だったとして、平手なのか駒落ちなのかによっても異なります。
囲碁で言えば、9路盤か13路盤か19路盤なのか、置石はあるのか、などですね。
マニアックな話をすると、定跡が大きく違うので少し変わるだけでも別物です。
麻雀もですかね、符計算や牌効率も考えるぐらいには嗜んでいますが戦術面については多面張とリーチ筋騙しのシャボ待ちトイトイ地雷ぐらいしか知らないのであまり詳しくないです。
彼らは戦術考察の際に必ず手牌と捨て牌、ドラや何順目（あと何回ツモれるか？）を確認しているはずです。
麻雀のアガりが分かる方なら、手牌33345の3,6両面待ちより45の3,6両面待ちの方がアガる確率は高いよね、という意味が理解できるかなと思います。
同様に、23445の3,6両面待ちも45の3,6両面待ちよりアガる確率は低くなりますが、うまく決まれば（3でアガれば）１飜増えるからトータルではこっちの方がいい事が多いよね、みたいな話です。
おそらく、こういった「アレの話ね」で通じる関係性かどうかで話し方も変わりますよね？っていう事がここでのテーマです。
問題の再認識
/**
* 疲れたので前提条件とか準備とか略
**/
teacher.talk("変数とは、物を入れられる箱です")
// teacher.expected_var = "箱"; を実行
studentA.think("箱…？よく分からんけど、とりあえず言われた通りにしよう")
// studentA.box = "はこ"
studentBB.think("箱…？どんな大きさでもええんか🤔")
// studentBB.box = "引っ越し段ボール大"
studentCCC.think("🤔物ってなんや…？ とりあえず魚運べそうなやつにするか")
// studentCCC.box = "長方形の発泡スチロール"
studentDDDD.think("よく分からんけど物を入れられる箱、りょーかい")
// studentDDDD.teacher_message = "物を入れられる箱"; なおboxはnull
// 〜〜〜
teacher.talk("作った箱の中に物を入れる事を代入といいます。")
// teacher.expected_var = ["物"]; ← 「代入のイメージ」の説明イメージ
studentA.think("箱の中に物を入れるのが代入？…つまり？")
// studentA.box = "は物こ"; これが代入
studentBB.think("箱に入れるって事は、まだ入れられる可能性あるよね")
// studentBB.box = "引っ越し段ボール大 (以降、空白スペース)"
// 代入自体に備えており、作業をしている感覚で話を理解している途中
studentCCC.think("釣った魚を漁獲すればええんかな")
// ノートへの書き取りミスなどで、このように理解した
// studentCCC.things = "魚"
// studentCCC.keyword = "代入"
// studentCCC.image = "発泡 （魚） スチロール"
studentDDDD.think("よく分からんけど、箱の中に物を入れたら代入やな！")
// studentDDDD.teacher_message = "物" 「物を入れられる箱」が入っている時に"物"を入れる＝上書きすることを代入
講師の発言を受けて考えられる理解の仕方を、変数と代入を使ってイメージとして書き起こしました。
説明を受けて色々なイメージをして、なぜだかめちゃくちゃな事をやっているように見えれば私が伝えたかった意図としてはきちんと伝わっているので大丈夫だと思います。
座学一回やって説明したぐらいだと、聴衆の理解度はこういうものだったりします。
こうならないために、図解したり（テキストを配布）実際のコードを書いてみたりして
- 最初説明を聞いて理解した内容と
- 実際に見聞きあるいは実行して理解した内容と
- 差・食い違いは何か見つけて、単元を超えて自分の理解が根本的に間違っていないか
を確認しながら学習を進めていく事になります。
こんな裏技あったら人生楽なのか、つまらないと考えるのかは人それぞれ
この問題はteacherとstudentが同じHumanクラスで、Human.(static)varに"箱"と入れられれば、誰に聞いても同じ答えが返ってくるようになります。
同様に、teacherクラスからstudentクラスを拡張で作れたら（日本語で子クラスとも言うため）teacherが最初から間違っていたり、後で勘違いしてvarを書き換えない限りは問題を解消できます。
つまり講師の知識を最初から受講者が活かせればこんなに苦労する事はないんですが、現実的にそうなってないです。
ただし、解釈の仕方によっては講義の場や時間をteacher変数にあるオブジェクトからstudent変数（配列でもいいです）へ一つ一つハードコピーをしようとしている時間とも言えなくはないです。
（今思ったんですが、これは値渡しと参照渡しの説明の例としても使えそうです）
このように、人間から人間への知識のコピーは決して簡単ではありません。
もしかしたら、普段何気なく使っている[Ctrl(Command)] + [C]やcopyメソッドはとても大変な思いをして精度100%のコピーを作っているかも知れませんよ？
ましてや、[Ctrl(Command)] + [Z]のアンドゥ・リドゥなんて神業ですね。現実世界でもほしい機能です。
営利主義のITスクールの運営はなぜエンジニア講師に合わないのか
そもそもの教育哲学が違うからです。
エンジニア講師をやっていて困りがちなシチュエーションと言えば、運営がやっている拝金主義にしか見えない教育システムや運営体制が気に入らないとか、受講者から講師にされても困るクレーム（講座量が高すぎる、教材がわかりにくい等）の窓口にされている、講師間でのコミュニケーションを認めない（これは引き抜き防止のためです）などで苦労をされている方なんじゃないかと思います。
つまり経験者の方が抱く不満にありがちなものですね。
これは、法人向け新卒研修でも個人のスクールでも起こり得ます。
大体の講師はフリーランスだと思いますし、私もフリーランスなんですが、敢えて誤解を恐れずに言いたい事を言わせていただくと、会社の方針に従えないなら自分でスクール事業を立ち上げてやってください。
どれだけ会社の方針が間違っていると思っても、会社に属している限りは会社の人間であるように振る舞うのは当然（フリーランスの立場で言えば仕方のない事）です。
三国志的に言えば、袁紹と田豊の関係を当時でも現代でもやって良い事は何もないです。
ただし、現場意識としては何とかして講師をサポートしたいと考えてくれる方は多いので、そこだけは間違えて欲しくないです。
彼らにも立場があり、本音と建前は違います。
「受講生の満足度」という謎パラメーター
受講生をディスる意図は全くありませんが、そのようにしか思えないお話をします。
スクール事業として見ると、受講生も講師も替えが利く存在です。
だとしたら、お金をくれる受講生とお金を持っていく講師のどちらを大事にしますか？というお話です。
これの答えは言わなくても分かりますよね？
そのため、講師が自身の査定や評価を受けるために、講義風景を録画し提出したり、あるいはクライアントなり担当者が潜伏調査のために入室する事もあります。（なお、受講生に同意を取る場合は「講義の品質向上のため」と説明して同意を得ます）
繊細な未経験講師（エンジニア）なら実情を知ったら胃が痛くなったり憂鬱になりかねません。
（従業員を監視しても生産性が上がらない話に似ていませんか？）
色々書いてますが、最も正しそうなデータは受講生に直接アンケートを取るのが一番です。
多いのは一ヶ月毎など区切りを決めている場合でしょうか。
今まであった面白かったケースとしては、受講生の質問を受けるたびにアンケートを書いてもらったなんて事もありました。これは受講生も質問＝アンケートの手間があったから逆に面倒だったんじゃないかなぁ、なんて思ってます。
裏を返すと、嫌いな講師を質問攻めして低評価を送りまくれば簡単に左遷・解雇できるので、受講生コミュニティもあったし犠牲者もいるんじゃないかと思います。
この制度のすごいところは、
- 運営が気に入らない講師がいる
- 色々な事情で簡単に契約を終了させることができない
というケースでも正当な理由（受講生から嫌われている）で簡単に解雇できる事です。
- 運営の人間を受講生として参画させる
- 過去の受講生の質問からテンプレートを使って講師に質問をする
- 回答がどうであれ、悪い評価を送る
- ある程度評価を溜める
追跡調査や解雇した講師からの言及が怖くなければ、実態はともかく評価を非公開にすれば中身をでっち上げて解雇してもバレないです。
運営にとって、対講師の切り札が「受講生満足度」なのです。
「受講生満足度」を運用する場合は、まず真っ先に講師と運営が連携して改善点や、どうしてこのような評価をされたのかヒアリング・相談を行うはずです。
その上で、低評価をつけた受講生（またはこの傾向が見られる方）に向けてより良い学習体験を提供するために対策を講じるはずです。
講師案件を安定的にこなし、獲得するためにはフリーランスでも社内政治は出来た方が良い
何のためにフリーランスをやっているか分からない話をします。
残念ながら本件は実体験に基づきます。
私の経歴をご存じの方は、大手も数社渡り歩いてきた経験（うち、社内コンサル含）があるので社内政治力もご評価いただけるかと思います。
で、こういったスクール事業社でも社内政治ができる場合は居心地の良い環境づくりのためにステークホルダーを探したり、組織体制を抑えたりプロダクトリードやったりする（元々の目的としては、報酬の未払いが起こった時に直接やり取りできる窓口を複数持っておく事で、有事の際に連絡が取れなくなったり、話を曲解される事を防ぐため）んですが、パッケージ提供側として教育システムについて知っているべき内容を教育されなかったために、システムトラブルが発生した時にアナログ・マンパワーな対応を行う事が何度かありました。
大体の場合は「障害発生→暫定対応→復旧次第運用を戻す」で解決する話なので、これで終わればいい話です。
が、運営側の内情を把握するチャンスでもあります。
こういった機会をうまくゴニョゴニョしていくと、実は使っている教育システムが薄氷の上で成立している運用である事にすぐ気付けます。
今までで多かったのは、テキスト教材の致命的な誤字・内容不備だったりテスト問題のややこしい表現の変更申請時に、すんなりと修正できる場合もあればシステムの都合で差し替えが難しいので、実施直前などに注意喚起をする方法で対応するケースです。
これ自体はあるある（※システム屋としては、本来はあってはならない事だと思うのですが）だと思います。
こういった問題に対して、次回または来年度施策として今回の事象、対応内容、改善案を出していくと、教育システムのコードを１行も読む事も見る事もなく理解が深まっていきます。
（ただし、システム管理者アカウントが見えている「出来る・出来ないの判断」と運用管理者アカウントが見えている「出来る・出来ないの判断」は異なるため、混同しないように留意しておきましょう）
で、システムのサポートチームと同等の予測や見解を持てるようになると、「現場講師＋システムサポートメンバー」の景色が見えてくるため、これらを使って更に他の業務内容も垣間見ていきます。
そこでも（現状起こっていないかも知れないが）将来的に課題になりそうなお話を先にしておくと、既に実績とチーム間での信頼を得る事ができれば更に今回の業務（案件）の経緯や背景、またはクライアントとエンドの関係などが窺えたりします。
実はこれは現場で動く時にも非常に重要な情報なんですが、なぜかキックオフの時までにお話がありません。
おそらく、本来は社外秘扱いされている情報が含まれているからだと思います。
（ちょっとヤバいニオイがしてきたので、ここからはぶった切ります。ご容赦ください）
講師になりたいエンジニアが探すべき求人の裏キーワード
「エンジニア 講師 ニート」で求人サイトを探してみてください。
ただし、求人の掲載日が古かったり同一案件を複数出していたりする可能性があるため、応募時は複数送らないように注意しましょう。
そもそも、複数送ってしまいそうな求人の出し方をするなよ、という声には同感ですが、求人サイトのシステムの都合とか色々大人のアレコレがありそうな気がしますね。
SNSに強いエンジニアならではのテクニック
入るスクールは第1期生のものを探してください。
つまり、普通の方法では応募すらできないプログラミングスクールの募集を見つける事です。
そのスクールには講師の立場で入るのはまず不可能（※お察しください）なので、受講生として入ってプログラミングを学び？つつ、講師のやり方を盗みましょう。
講師スキルを高めたいなら、コースや講師が多いスクールがおすすめですが、講師になりたいなら講師がいないスクールを選んで受講生として潜り込めば内部採用される可能性があります。
あとは、第1期生が講師になったとブランディングして社内に発信するようにしていくと、外部講師を切って内製講師を作った方が事業化できるしコストも安くなります。
穿った見方をすると外部講師から仕事を奪ったように捉えてしまいますが、外部講師と会社との取引実績を認めるかあるいはあなたが外部講師の方に指導していただいた経験をお話することで、その方の株を高める事になります。
そもそもあなたはSNSに強いはずなので、こういったアピールポイントは会社あるいは個人が許す範囲で発信する方があなたにも良い印象を持っていただく事ができます。
SNSを使っていくと「何を言ってもダメな方がいる」事は認識していると思いますので、こういった方々をケアするのか付き合わないようにするのかは、あなたのSNS戦略に合わせてご対応ください。
運営を改善したい
その会社は諦めて、あなたを中心とした組織を立てて事業化してください。
エンジニアが会社を興す時に、絶対必要なのに足りないスキルが「営業力」です。
もし営業面に自信がないなら、いったんエンジニアを３年休職してでも営業スキルを習得した方が将来的にどこでも活用できます。
エンジニアだけど営業修行がしたいです、と言ってくる応募者は間違いなく採用担当者に刺さります。
長期的に活躍できる人材しか求めていない会社なら採用される事はないですが、これはあなたが悪いのではなくタイミングが悪いので落ち込む必要はありません。
独立の機運が高い会社だな、と思ったらどんどん書類を出していけば、未経験者が普通に就活・転職するより高い確率で採用されると思いますよ。（私なら採用してみたい側の人間です）
と、運営を改善したいと常々考えている人間が自分の話を他人事のように語っておきました。
新卒カードをなくした場合でも使える研修のある案件とは
タイトルだけ鵜呑みにすると、メリットしかないお話だと思いますが、ちょっと待ってください！
これは罠の可能性に注意してください。
というのも、ひとくちに研修と言っても、企業が雇用して研修するタイプ（無料・給与別）ではなく、派遣登録して研修サービスが受けられる（有料）というのが正しいです。
また、派遣で無料の研修があったとしても、短期間参加するだけのいわゆる勉強会を研修と定義している事もあります。
今回は、プログラミング未経験で新卒カードがない方が無料で研修を受ける方法を考えたいので、勉強会を研修とするのは難しいです。
社員（正社員・契約・派遣・アルバイト・パート）が使える裏技
ここの要件は失業保険の対象者であることです。
つまり、社保を持っていて半年以上連続的に働いており、開業届を出していない方が該当する事が多いので、対象者はかなり広がります。
なお、自営業の場合は、この方法を使う場合は事前に廃業届けを出しておいてください。
（アルバイトと自営業を兼務している場合、アルバイトをやめても失業扱いにならないようです）
失業給付期間中に条件を満たす職業訓練校に通うのが一番です。
お金（失業給付金）をもらいながらITの専門学校１回生相当の内容で実務よりの勉強が体験できます。
独学でプログラミングの勉強をしていた方にとっては、無料でチーム開発を体験できる機会にもなるので、機会があれば（ない方がいいかも？）参加も一考の余地があると思います。
所感
本稿で一番時間がかかったのが運用ルールの漏れ抜けを塞ぐことだったので、登壇して解説した方が早いと思う気持ちに溢れてつらかったです。
これアフィリエイトで記事書いていたら一番最後におすすめのエージェントをランキング形式で紹介して広告とか貼りたいですね。
残念ながらアフィリエイト記事でもなければ、自分のページに誘導するためのサテライトでもないのでエージェントはご自身で見極めてください。
お詫び２（所感２）
遅れてすみませんでした、
この記事は14日に「記事を書く」ボタンを押して、思った以上に難産した結果、15日本日現在に投稿する運びになってしまいました。
普段講師の話を真面目に語らないので、気持ち的にはスッキリしています。
あと、所感でも書いたんですが運用ルールの漏れ抜けについては、口頭説明で解決していた部分なのであれもダメこれもダメと条件を書き出すと結構制限だらけでしんどかったです。
こういう事を経験すると、文章（メールなりチャットなり）で伝えるより電話一本で済ませたくなるおぢさんの気持ちになります。
都合のいいところだけ切り取って使いたいです。