人生100年!生涯エンジニア人生!

楽しいエンジニア人生!

マイプロフィールLT会に参加してみた

f:id:hideaki_kawahara:20210316190416p:plain

マイプロフィールLT会に参加

かふぇさんが、面白そうな勉強会をしているので参加しました。

workwithsmile.connpass.com

参加するなら登壇だ!という謎理論で、2018年ぐらいに作った自己紹介資料を少々手直しして参加しました。

まさかの!?初登壇の人が3人!

登壇者が私の他に3人居たのですが、まさかの私以外は全員初登壇でした。
初登壇の人が居るの勉強会に参加して思うのは、勉強会の雰囲気が、みんなに勇気を与える感じになるので良いです。

また、登壇したことある人には、登壇する人が増えるよろこびと、自分の初登壇のころを思い出すなど、ふりかえりの機会としても、とても刺激になりました。

ちょっとフォロー

登壇後の全体ふりかえりで、色々と語りましたが、テキスト化していないので、私が言ったことをテキスト化しておきます。

リハーサルは必要?

事前にリハーサルはする方が良いです。
登壇するときは、持ち時間があるので、それに合わせるように、リハーサルを一度でもしておくと良いです。
リハーサルしなくても、10分のLTなら資料1ページにつき30秒で話せば20ページぐらい(表紙とシメの言葉を除いて)の資料になるようにすると良いです。

資料は増やす?減らす?

資料を増やすことは難しいですが、減らすことは簡単です。

そのため登壇資料を作るときはページ数は多めに作ります。
そしてリハーサルして伝えたいことが薄くなるようなページを削除して、登壇時間に合わせていきます。

登壇後の評価

自分自身で、ふりかえりをしましょう。

登壇すれば50点で、50点を超えれば合格です!そう、登壇することが重要なのです。
誰かの受け売りではないですが、エンジニア人口のうち登壇経験のある人なんて1割しか居ないんです。
登壇したら、その1割のエンジニアになるんですよ!

そこから、良かった点をどんどん加算していきましょう!
加算しまくったら、反省点を少しだけ減点しましょう。

そして、次も登壇しようと思いましょう。

補足

私は、自己紹介をベースとした勉強会は、自分のことを棚卸しすることができるので参加したくなります。
参加して良かったです。

また、自己紹介は、自分をアピールする物で、それを多くの人に知ってもらうためのものです。
エンジニアなので、職歴ベースで話すのが楽ですが、職歴があまり無いとか書きにくい方は、以下のようなドラッカー風エクササイズを参考にすると良いかもしれません。

  • 自分は何が得意なのか?
  • どういうふうに仕事するか?
  • 自分が大切に思う価値は何か?

偉そうに語りましたが、これも登壇者が増えることを願うからです。
そして、このような勉強会を開催してくれた、かふぇさんに感謝します。 (ファシリテーション良かったです)

「カジュアル面談のトリセツ」要項

f:id:hideaki_kawahara:20210224123616p:plain

背景

元々は、転職経験が多い自分のノウハウみたいなものをアウトプットしようとしておりました。転職という題材は広い範囲になりやすいのと、対象読者が見えにくいです。そのため執筆するモチベーションがあがらないので、ターゲットを狭めようと考えました。

そんな中、多くのIT企業で行っているカジュアル面談を数社受けているうちに、企業によっては手探りな状態と感じました。カジュアル面談という手法は成長過程にあり、カジュアル面談を受ける側はもちろん、カジュアル面談を行う企業側も含めて、知見が少ない多くないのではないかと感じました。

それならば、少しでもカジュアル面談を受けてきた自分の知見を共有できればと思い、本を作ることを考えました。

タイトルは、「カジュアル面談のトリセツ」です。

※なお、執筆者は人事部の人間ではないので、人事的な観点のノウハウではないです。

対象読者

下の読者を想定しています。

  • 転職を考えたことがあるエンジニア
  • カジュアル面談を受けたことないエンジニア
  • カジュアル面談を知らないエンジニア
  • カジュアル面談の楽しさを知りたいエンジニア
  • 企業の人材関係者(受ける側の目線が読めます)

目次

仮の目次です。

  • カジュアル面談とは?
  • カジュアル面談の定義
  • 受けるメリット
  • 企業のメリット
  • 知見が広がるカジュアル面談
  • 転職サイトについて
  • SNSの利用について
  • 受ける前にやること
  • 受けている最中に注意したいこと
  • 受けた後にやること
  • カジュアル面談後に注意したいこと
  • 面接へ

頒布スケジュール

  • 2021年4月末頃
  • 技術書典11目標
  • 紙頒布も予定
  • 第5回 技術書同人誌博覧会(2021年6月19日)でも頒布予定

デブサミ2021に参加

f:id:hideaki_kawahara:20210220133447p:plain

今年はオンラインで開催されました。
codezine.jp

色々とセッションを聞いていましたが、仕事を優先しているときは感想をツイートしていないので、ツイートをしているを中心にブログにまとめます。
特に2021年2月18日は、割り込みが多かった・・・。

18-D-4

エンジニアが経営者になるとみえる、開発の大事なポイント
後川 菜穂子さん

  • エンジニアは強力な手段です。
  • 「全員が同じ変数」で「同じ結果」を出す。
  • 非エンジニアの見積もりは、モジュール分解ができていない。
  • ドメイン駆動開発などのエッセンスを使ってプロトタイプを作る。

このような経営者から目線じゃなく、エンジニアから経営者になったときの目線というのは貴重で非常に参考になりました。

togetter.com

19-B-1

デベロッパーからはじめるレガシー組織の景色の変え方~旧ノーマルからニューノーマル
沢渡 あまねさん[浜松ワークスタイルLABO]/新井 剛さん[レッドジャーニー]/【モデレーター】近藤 佑子さん[翔泳社])

あ!ゆうこりーん!って言うの忘れた・・・orz

ツイートでも感想を言っていますが、抜粋するとこんな感じかな。

togetter.com

  • 統制管理型を否定していない。
  • メリットは考えなくていい答えが出る、管理するだけ、しかし、変化に弱い。
  • 慣れた不便に名前を付けて共感者を増やす。
  • 新しいツールをエンジニアドリブンで始動する。
  • 新しいツールの砂場(サンドボックス)で遊ばせて、ファンにさせる。
  • 3つのファンを作る。
    • テクノロジーのファン
    • プロダクトのファン
    • カルチャーのファン
  • ファンを作るのはマーケット手法そのもの
  • デベロッパーズ・ルネッサンス

19-B-6

ニューノーマル時代のコミュニティは誰もがチャンスに満ち溢れている。
中道 一志さん[ニッセイコム]

見せる登壇でしたね。

speakerdeck.com

あまり感想ツイートはしてませんが、「やりたいからやる」「踏み出す勇気」など共感できることが多かったです。

19-A-9

コロナ禍でエンジニアイベントはどう変化していくのか? オンライン時代の技術と人との出会い方
【モデレーター】仲亀 拓馬さん[さくらインターネット]/赤川 朗さん[Forkwell]/草間 一人さん[CloudNative Days]/森川 晃さん[技術書同人誌博覧会])

Miroを使用しての双方向なセッションでした。
参加者が付箋を貼り、それを登壇者が読み取りながらのセッションで、参加者が80名ぐらい居たらしく、付箋がすごい数になりました。

Miroを使ってのセッションはオンラインでの良さと新しい可能性を実感できました。
オフラインで開催になっても、この感じは取り入れたいですね。

他の感想はツイートしてます。
togetter.com

↓Miroの付箋数が物凄い量でした。

f:id:hideaki_kawahara:20210220114608p:plain:w300

途中、お絵描きに話題が行ってしまったのも楽しかったです。

f:id:hideaki_kawahara:20210220114729p:plain:w300

余談ですが、この付箋を描いたのは私です。

f:id:hideaki_kawahara:20210220123855p:plain:w400

休憩時間

Eventinといサービスで、インターフェイスは良かったで使いやすかったです。
私は、ほぼ「技術書同人誌博覧会」のところに居ました。
参加者として、技術書同人誌を書いた人という感じで雑談しました。
3人ぐらいの方が、技術書同人誌を書く意思を示してくれたのは嬉しかったです。

余談ですが、スポンサーのところに人が、あんまり来ないのは、参加者が少ないと入りにくく感じるので、2~3人居ると良いのではないかな?と思いました。

懇親会

こちらもEventinを使用、途中家事などの割り込みが入ったりしていましたが、非常に楽しい懇親会でした。
誕生月でルーム分けをしていたのですが、2月が1人も居なかったので、不吉な雑談ルーム13を選びました。
そしたら、ファシリテーションをしてくれた方が良かったので安心して会話できました。
ありがとうございました。

会社から賃金振込で銀行口座を指定されることは違法について説明

バズった

めもりーさんのツイートがバズる。

そこにぶら下げた私のツイートも小さくバズる。

知らなかったといツイートが多い中、色々な疑問も出ていたので、会社から賃金振込で銀行口座を指定されることは違法について説明します。
※ブログでは給与のことを賃金と記載します。

賃金支払いの根本ルール

労働基準法第24条を参照してください。
elaws.e-gov.go.jp

第二十四条 賃金は、通貨で、直接労働者に、その全額を支払わなければならない。ただし、法令若しくは労働協約に別段の定めがある場合又は厚生労働省令で定める賃金について確実な支払の方法で厚生労働省令で定めるものによる場合においては、通貨以外のもので支払い、また、法令に別段の定めがある場合又は当該事業場の労働者の過半数で組織する労働組合があるときはその労働組合、労働者の過半数で組織する労働組合がないときは労働者の過半数を代表する者との書面による協定がある場合においては、賃金の一部を控除して支払うことができる。

② 賃金は、毎月一回以上、一定の期日を定めて支払わなければならない。ただし、臨時に支払われる賃金、賞与その他これに準ずるもので厚生労働省令で定める賃金(第八十九条において「臨時の賃金等」という。)については、この限りでない。

いきなり難しいですね。
これが世間で言われる「賃金支払の五原則」です。

厚生労働省のFAQがわかりやすいので、こちらを参照しましょう。
www.mhlw.go.jp

賃金の支払いは以下のルールがあると覚えておくと良いでしょう。

  1. 通貨で
  2. 直接労働者に
  3. 全額を
  4. 毎月1回以上
  5. 一定の期日

今回の件では「通貨で」と「全額を」が影響するので説明します。

通貨でというのは、現物支給の禁止で、価値が異なる現物で、支払うのは駄目です。
そして、ここで言う通貨というのは「貨幣及び日本銀行法の規定により日本銀行が発行する銀行券」で、物理的な紙幣と貨幣、つまり現金です。

全額をというのは、本来の目的は賃金の支払いを滞納することで実質的なタダ働きさせないためです。
ただし、法令に別段の定めがある所得税源泉徴収地方税など一部控除することが認められています。

このことから労働基準法第24条では「賃金の支払いは全額現金を渡す」ことが規定されいます。

次のルール

賃金を現金で払うのは手間ですし、1968年12月10日に発生した三億円事件という未解決事件もあり安全な方法として銀行口座を使うことが行われております。

それに対する規定は労働基準法施行規則第7条の2になります。

elaws.e-gov.go.jp

第七条の二 使用者は、労働者の同意を得た場合には、賃金の支払について次の方法によることができる。

一 当該労働者が指定する銀行その他の金融機関に対する当該労働者の預金又は貯金への振込み

ここで重要なのは「当該労働者が指定」とありますので、会社が銀行口座を指定することは違法になります。

振込手数料天引き問題

使っている口座を会社に指定したら、振込手数料を天引きされた話もよく聞きます。

これは労働基準法第24条の項目で書いたとおり、「賃金の支払いは全額現金を渡す」ことが前提になりますので、賃金から振込手数料を天引きすることは「全額支払う」こと反するので違法になります。

このことが是正されたが、過去に天引きされた分が返金されないことも言うツイートも見かけますが、善意が少しでも残っている会社ならさかのぼって返金するでしょう。
一応、2年間さかのぼって返金請求は可能ですが手間がかかるかもしれません。

会社がお願いする問題

会社が銀行口座を指定じゃなくて、お願いすることは問題ないという意見があります。
確かに、お願いという程度なら違法とは言い切れません

だけど、会社がお願いすることは拒否できないと感じる人も居るし、会社の経費節減のためだと周りが言い出すことで「同調圧力」になる可能性があるので、問題ないという点には疑問を感じます。
特に同調圧力が生まれることは非常に危険なことで、これに歯止めがかからないことで、そこからパワーハラスメントなどを生むきっかけになり、その結果、多くの悲劇を生むことになります。

経験者ならわかりますが、同調圧力は本当に良くないことです。

そして、同調圧力は法を無視することを良しとする風潮が生まれてきます。
この関連ツイートや、引用ツイートを見てくださるとわかりますが(あえてリンクしませんが)、「会社の損は労働者にも降りかかる」とか「会社の不利益を推進するな」とか、そんなことを言う人も居ます。

そもそも「会社の損」とか「会社の不利益」とか、会社の利益って何だろうね?
会社が違法な行為をして利益をあげることが正しいのでしょうかね?

例えをあげるとすると、スポーツ競技でルールを無視して勝つことに意味があるのでしょうかね?

融資問題

この問題には、さらに闇があります。
真相は不明ですが、銀行口座を作ると融資を受けやすくなると言われることがあり、口座を作らせる行為もあります。

これこそ「同調圧力」になりますし、その行為を銀行の行員が黙認しているのなら、それは銀行のコンプライアンス違反となります。
また、その行為を黙認する行員を信用して良いのでしょうか?
結局は、行員の業績を上げることがメインなので融資をしてくれるとは限らないです

融資のためというのは絶対に従ってはいけません。

まとめ

労働基準法第24条において「賃金の支払いは全額現金を渡す」と規定してます。
労働基準法施行規則第7条の2において「労働者が指定する銀行」と規定してます。
上のことから、賃金の振込で、会社から銀行口座を指定されることと、振込手数料を天引きされることは違法となります。
会社から銀行口座をお願いされることは、ブログ主としては違法とは言い切れませんが、同調圧力を生むことになるので推奨しません。
こういう言葉のニュアンスで苦しむ人も居るので、ブログ主個人としては違法に倒したいぐらいです。

余談ですがブログ主は、ここに書いたこと全部経験しております。
蛇足になるかもしれませんが、融資問題について書きます。

遠い昔に、会社にお願いされて融資のため親族に口座を作らせるなどの協力を行いましたが、このときは、これが同調圧力とは気付きませんでしたが、今思い出すと、これが同調圧力なんだなーと思います。
そして、結果として会社は融資に失敗して、全社員に融資失敗したのを、罵倒とともに、お前らの責任だと言われたことあります。
この後は、社員と経営者の罵倒合戦が始まり、その結果、メンタルが弱い人はつらい思いをし、耐えきれない人は会社を去りました。
こんな地獄のような環境で働きたいですか?
同調圧力は不幸しか生まれません。
そして、善意で会社に協力しても、経営者は貴方を罵倒するんですよ。
会社は貴方を守りません。
それなら法律を守るほうがマシです。

GitHubは悪くない、ソースコード漏えい事件、ソースコードは正しく管理してる

概要

GitHubに会社の機密情報に該当するソースコードが漏えいする事件があり、多くの報道が出ているので、詳しくは、それらの報道を読んでください。

www.itmedia.co.jp

これらを読んで思うことは、ソースコード漏えい事件でGitHubは悪くないです。
そもそも、ソースコードの扱いは多くの会社で適切に正しく管理しております。
今回の事件の根幹は、当該者のモラル欠如と言っても良いです。

社内ドキュメントの扱い

ソースコードの扱いについて話す前に、社内ドキュメントについて思い出してほしいです。
そうです、社内ドキュメントは閲覧できる権限が設定されています。
どこの会社でも内容を精査して秘密定義を行ったのち秘密分類を行います。
下のような管理分類が定義されていることが多いと思います。
また、管理分類においてデフォルトは秘にすることで判断に困るのを回避できます。

管理分類 内容
極秘 社外に漏れたら会社経営に重大な損害を与えるもの、会社の合併情報や顧客の個人情報などが該当します。
秘(部内秘) 社外に漏れたら会社の信用情報に損害を与えるもの、プロジェクトの内容や議事録が該当します。
社外秘 社外に漏れたら会社の信用情報に損害を与える可能性が低いもの、ハウスルールや座席表などが該当します。
公開情報 一般に公開している情報、会社の住所やWebサイトに公開している情報が該当します。

適用範囲も分類します。
「役員」「正社員」「派遣社員」「委託先従業員」などが該当します。

これらを組み合わせて、社内ドキュメントは管理されています。
※細かな表現の差異などはあります。

ソースコード管理にもレベルを設定している

ソースコード管理にも管理分類を設定しています。
ざっくりですが、社内ドキュメントと同じレベル感で分類すると下のようになります。
また、社内ドキュメントと同様にデフォルトは秘にすることで判断に困るのを回避できます。

管理分類 内容
極秘 認証など、このソースコードが漏れたら直ちにシステムに損害を与える情報があるソースコードが該当します。
秘(部内秘) 各プロジェクトごとのソースコード、直ちにシステムに損害を与えることは無いが、このソースコードを調べることで将来的にシステムに損害を与える可能性があるソースコードが該当します。
社外秘 社内で共有使用するソースコード、社内で横断的に使用するユーティリティに対応するソースコード、認証をカプセル化したソースコードなどが該当し、これらが漏れることは望ましくないです。
公開情報 利用しているOSSなど

GitHubも、Enterpriseプランなら、Repository単位ですが細かな設定が可能になりますし、ソースコードが漏えいした企業もGitHub管理じゃなくても、同様な管理レベルの設定をするだろうと思います。

FYI:Enterprise アカウントで Organization のポリシーを設定する
docs.github.com

厳重に管理されている

このように社内ドキュメントとともに、ソースコードも厳重に管理されています。

情報にアクセスするときは認証を行ったのちにアクセスが可能となります。
その上で、アクセスするときにはアクセスを開始した日時や、サーバーにログインするときなどはVPNを経由したり、キーボードで入力した内容なども記録しています。

会社によっては極秘に該当するものにアクセスするときは、物理的な認証(指紋認証や顔認証など)を行いセキュリティー完備な区画に入室して、そこで作業することもあります。
また、その区画に入室するときは、個人のスマホなどを預けたり、その区画では外部のアクセスが完全に制限されていることもあります。

これぐらい社内ドキュメントやソースコードは厳重に管理されています。

また、社内から外部にアクセスするとき、禁止された場所へのアクセスを禁じているところは多く、外部へ容易に持ち出せない会社も多いです。
この辺りは専門的なツールを使用しているので、持ち出そうとしても持ち出せないと思います。(個人的には試したくない)

ただ、管理コストの面や開発効率などを考えると、極秘以外は認証だけで許可する方が多いです。
そのため極秘以外のソースコードは、モラルがベースとなって管理運用することが多くなっています。

つまり、極秘に該当するものは性悪説で管理する。
それ以外は性善説で管理する。

モラル教育

性悪説での管理は先程述べた通り、予算をかけていくことで脳みそに記憶されること以外の防御ができるようになっていきます。

しかし、性善説での管理はモラルに依存します

社内ドキュメントがきちんと区分されている会社なら、社内教育で機密情報の扱いを教育されています。
これらの教育は社員区分隔たり無く教育することが望ましく、多くの会社でも行っています。
そのため、派遣構造がひどいと言っても、モラル教育や機密情報の扱いについての教育は行われていると思われるし、そもそもソースコードは外に持ち出さないのは常識レベルなので、今回の事件は発生したのは当該者のモラル欠如と言っても良いです。

ただ、残念なことに、モラル欠如による情報漏えいは後をたたないです。
こうなってくると、性善説で扱える業務が狭くなる恐れもありますが、機密情報を適切な管理をしているところは、この管理を継続していくことが大事であり、そして、モラルの教育や機密情報の扱いについての教育を、社員区分の隔たり無く行うことで減らすことは可能だと思います。

性善説の運用は教育でしか向上することはできないのです。
そして、個人のモラルを向上することが我々エンジニアにできる最善策だと私は思います。