Node.js
npm
ポエム
転職

【退職】履歴書をGit管理したかってん【しました】

追記

 .JSONという気味が悪い拡張子 を使うのはやめて、YAML版を作ってくれた人がいますのでそちらを使いましょう

 LINK: YAMLで履歴書を作る

前書き

 この文章にはタイトルとは関係ない内容が多分に含まれています。ご注意ください。

本題

 5月末で現職場を退職することになり、先日最終出勤だった。転職しようと決めたとき、前回の転職からたった数行の差分で一から書かなきゃいけない履歴書を準備するのが死ぬほどめんどくさくなって(要はなくした)、どうせなら職務経歴書と合わせてGit管理下に置きたいと思った。ただ前回作ったやつがMS Wordで書いてて、さすがにGit管理するならプレーンテキストがいいでござる・・・と思い、気がついたらツール作り始めてた。

{
    "date": "YYYY年 MM月 DD日現在",
    "name_kana": "ヤマダ タロウ",
    "name": "山田 太郎",
    "gender": "男",
    "birth_day": "YYYY年 MM月 DD日",
    "address_kana": "トウキョウトスミダクオシアゲ",
    "zip_code": "〒131-0045",
    "address": "東京都墨田区押上1-1−2",
    "tel": "0120-XX-XXXX",
    "phone": "090-XX-XXXX",
    "mail": "example@example.com",
    "academic_histories": [
        {
            "year": "20XX年",
            "month": "4",
            "value": "YY高校入学"
        },
        {
            "year": "20XX年",
            "month": "3",
            "value": "YY高校卒業"
        }
    ],
    "work_histories": [
        {
            "year": "20XX年",
            "month": "4",
            "value": "株式会社ZZ入社"
        },
        {
            "year": "20XX年",
            "month": "3",
            "value": "株式会社ZZ退職"
        }
    ],
    "licenses": [
        {
            "year": "20XX年",
            "month": "1",
            "value": "普通自動車免許"
        },
        {
            "year": "20XX年",
            "month": "12",
            "value": "ITパスポート"
        }
    ],
    "free": "これはサンプルです。\nよろしくお願いします。"
}

上のようなJSONファイルから下のようなPDF出力します。

capture1.jpg

その他

  • リポジトリはこちら ⇒ https://github.com/PruneMazui/resume-maker
  • どうやって使うの ⇒ リポジトリのReadme参照してくだしあ
  • 一応履歴書のJIS規格なるものに即したつもりです
  • なんで Nodejs? ⇒ ヘッドレスブラウザをバンドルしやすかったから
  • YAML 対応してないの? ⇒ PRお待ちしてます
  • XML 対応してないの? ⇒ うっ・・・頭が・・・
  • NPM 登録しないの? ⇒ メアド公開されるって書いてて躊躇してしまった
  • 写真も埋め込めたらよくない? ⇒ 面接官の人によっては嫌がりそうな気がしたので・・・(チキン
  • 似たようなのあったよ ⇒ 原因ちゃんと覚えてないけどなんか使えなくて断念した記憶が

余談

 今回の転職にあたりほんとに色々な方に相談乗っていただいたり、力をお貸しいただきました。この場を借りてお礼申し上げます。今後ともよかったら仲良くしてください。ちなみに中規模SIerからFintech系スタートアップにいきます。


以下ポエム

発言力と個人の成長/組織の関係の考察

 アジャイルで言う自己組織化されたチームには課題に対して全員が向き合ったり、アイディアに対して全員でフラットに検討できるチームビルディングが重要だが、「問題を認識すること」「問題を提起すること」は後者は更に一段ハードルが上がると考えている。まれに思ったことを何でもド直球に言えるタイプの人もいるが、おそらく大半の人はバランスを取りに動こうとするし、自分自身も羨ましいと思う反面絶対にこうはなれないなと思う
 自身の心理的安全性を担保するためにそのような行動に出てしまっていることがほとんどだと思うが、下記のグラフのような相関関係があるのではないかという仮説を立てた。

2018-04-04_14h57_56.png

 上記のグラフでは各個人がそれぞれ許容できる非安全性レベルを持っていると仮定し、それに応じて発言できるレベルが変わってくるという図式になっている。この許容できる非安全性というのは「こんなことを言ってしまうとこの人にレッテルを貼られてしまうかも」とか「これを言っちゃうとあいつは出しゃばってくる」といった、あくまで個人が考える想像上の恐怖であり、この許容範囲は様々な要因が絡んで上下する。

 例えば新卒1年目のエンジニアは社会人経験がないことに起因する自信のなさや、会社の上下関係でいう一番下にあたることが多く、必然的に許容できる非安全性レベルが低くなる。その結果、当たり障りない発言しかできないという傾向にあることは容易に想像がつくと思う。(※まれに当てはまらない人もいる)

 今回、発言内容レベル=発言力として、この仮説を元に考察した。

個人の成長の指標としての役割

 そもそも個人が心のどこかで線引きしているであろう許容できる非安全性レベルというのは、様々な要因で上下する。パッと思いつくだけでも以下のような要因が含まれていると思う。

  • 年齢
  • スキル・実績・経験に基づく自信
  • 会社における立場・慣れ
  • 上司・同僚・部下・顧客との関係性
  • マウンティングしてくる何か:alien:
  • 契約形態
  • 本人の性格・謙遜
  • 詐欺師症候群・承認欲求
  • etc...

 これらを大別すると「内的要因」「外的要因」「どちらともとれるもの」の3つになるが、「内的要因」の中でも自分自身である程度コントロールできるものが「スキル・実績・経験に基づく自信」だと思う。

 もし自分が今の環境下において思っていることを言い出しづらいと感じている人がいたら、まずはこのスキルや実績、経験を高めていくことが一番手っ取り早い解決策であると思うし、逆に自分ができる発言内容レベルからある程度自身の成長を図る指標となれるのではないかと思う。(環境への慣れ等の要因も当然あるだろうが)

2018-04-10_15h47_36.png

 但し、自分の意見をぶつけるということと質問することは明確に線引きを行った方がよく、分からないまま放置してしまうリスクというのは確実に意識するべきだと思う。

参考)Fail Fastとは?

組織文化の考察

 さて、ここからが本題。チームや組織において心理的安全性がどの程度確保されているかでも(先述した外的要因)発言力というのは変動し、おおよそ以下のグラフのような関係にあるのではないかと思う。

2018-04-10_15h54_09.png

 そして激しく今更だが、この記事でなんでこんなこと書いてるかというと、転職活動を行う中で一番気にしていたのが社風というか文化みたいなところで、特に誰でもフラットに意見を出すことが許容されている文化かどうかはエンジニアチームはもちろん、自身のパフォーマンスを発揮する上で最重要視している。

 ところがどこの会社でも「風通しの良い職場です!」とか「みんな仲良い明るい職場です!」とか謳ってて、とてもじゃないけど全部の会社がそうなってるわけないだろ!!と思うわけで会社の口コミサイトを見たりするのだが、大企業でない限りいかんせん母数が少ないし、当事者の意見ともなると配属された部署や上司の影響の方が強く出る、所謂局所的な見解になりそうっていう懸念もあった。

 本当ならこういった会社の文化をせめて応募する前にせめて定性的に評価できる仕組みがあればいいのに・・・ということを転職活動中に思ったのだが、そもそもこういった会社の文化というものはどうやって決まるのかすらよく分からなかった。少なくとも社長が「うちはフラットな組織だから何でも言っていいんだよ」と言っていてもそうはならないと思っている(体験談)。

で、以下の軸で考察なり調査してみたのだが、詳細はいずれまた別のお話で・・・

  • ビジネスの観点:ビジネスモデルとして都合がいい方に寄っていく可能性
  • 人の観点:MBTI (心理テストみたいなやつ)でどのタイプが組織のヒエラルキー上位を占めているか
  • 会社の観点:会社としてのビジョンが落ちてないだけの可能性

終わりに

 結論なんてないし全然まとまりない文章だけどポエムなのでご容赦を。最後にエイプリルフールネタでやらかしちゃったテスラCEOが全社員に送った、僕が大好きなメール張り付けておきます。

引用元: 東洋経済オンライン

件名:Tesla内のコミュニケーション

企業内で情報がどのように流れるべきかについて、2つの考え方があります。
これまでのところ最も一般的なやり方は、指揮命令系統に従う方法です。
つまり、あなたは常に上司に指示を仰ぎます。
この方法の問題点は、上司の力を強化するものの、会社のためにならないということです。

本来なら、問題が発生した場合はその部門の人が関係部門の人と話し、
正しい行動を起こして迅速に解決するべきです。

にもかかわらず、指揮命令系統の下では、人々はまず上司に報告せねばならず、
その上司がそのまた上司に報告して、その上司の上司が他部署の管理職に相談し、
その管理職が部下に相談するといった流れをとります。
その後、もう一度同じ経路を逆流し情報が伝えられます。

これは信じられないほどバカげています。
こんなことをしている管理職、ましてや推奨している管理職は、すぐにうちの会社で居場所を失うでしょう。
冗談で言っているのではありません。
テスラにいる全員が、誰にメールしても会話しても構わないし、またすべきなのです。
企業全体の利益のために、自分が考える最速の解決方法をとるべきです。

上司の許可なく上司の上司に相談しても構わないし、別の部門のトップに直接相談してもいいし、
私(*イーロン・マスクCEO)に相談してもらっても構わない。
誰かと話すことに誰かの許可は要らないのです。
さらに、問題が解決されるまで、自分にその義務があると考えるべきです。

この狙いは、手当たり次第に世間話をすることではなく、超高速で確実に実行することです。
我々が大手自動車企業と規模で競争できないことは明らかなので、
我々は知性と機敏さで勝負しないといけない。

最後に1つ言っておきたいのは、管理職が注力すべきなのは、
企業にサイロ(*縦割り組織の例え)が生まれないようにすることだ。
サイロは他者との間に精神的な壁を作り出し、コミュニケーションを阻害するのです。
残念なことに、サイロができるのは自然な流れなので、積極的に戦う必要があります。

部門間に障壁を立てたり、会社全体ではなく組織内の相対的な成功を重視したりすることが、
どうしてテスラのためになるでしょうか。
我々全員、同じボートに乗っています。自分の部署ではなく、
会社の利益のために働くことをつねに意識してください。

イーロン