どうも。株式会社プラハCEO兼エンジニアの松原です。 弊社はメンバー全員が業務委託なのですが、転職のお誘いをする際に「今は正社員に絞って探していて...」と言われることが結構多いので、業務委託契約をあえて選択している企業側の観点をどこかにまとめておいたら今後のエンジニアのキャリア選択に役立ててもらえるのではないか？ と考えつつ、もしかしたら読んでくれた人が興味を持って応募してくれるかも、という下心も込めてキーボードを叩いています。 ただ大前提として、人や会社によって最適な契約形態はそれぞれ異なるので、今回はあくまでプラハという会社にとってなぜ業務委託契約が適しているのか、という観点に絞って話していくので「そういう考え方の会社もあるんだ」ぐらいに留めていただけたら幸いです。決して業務委託契約が全ての状況で雇用契約を回るバラ色の契約形態だと言いたいわけではないよ！ 社風や理念との合致度 プラハ

2月になると「確定申告の季節ですね～」と言うエンジニアがいるのだ。 ぼくも「そうですねー」と話をあわせるのだが 「確定申告」ってなんなのだあああああああ～～～～？ 実はぜんぜん知らないのだああああああああああああああ ･･･って内心は思ってるのだ。 そんなことではいけないと思い、確定申告について調べてみたのだ！ 確定申告とは？ 一言でいうと「私は今年これだけ稼ぎました！」と税務署に報告することを指すらしいのだ。 うん、それは知ってるのだ。 中学生のときに「国民は納税する義務があるよ」と教えられたのだ。 でも、具体的に いつ？ どれくらい稼いだら？ どうやって申告する？ 税金の仕組みってどうなってるの？ など詳しいことは教えられていない気がするのだ。 そこらへんを掘り下げていくのだ。 その前に：会社員は？ 会社員の場合は、源泉徴収（げんせんちょうしゅう）というやつのおかげで、確定申告をしなく

どうも、株式会社プラハCEO兼エンジニアの松原です 最近若手エンジニアから「技術書や記事からのインプットが遅い、あるいは浅いことに悩んでいる」と相談を受けました。 (自分のインプットの巧拙はひとまず棚に上げて)自分は技術書を読む際は予習と復習を結構するタイプなので、自分なりに工夫していることについて書き残してみようと考えました。超オレオレ理論ですが、悩んでいる方の参考になれば幸いです 本の予習と復習 自分は技術書を読む前後でこんなことをしています: (予習)その本にかける時間を決める (予習)本から学びたいことを書き出す (予習)胡散臭い人に書かれたと考える (復習)仮説を作り、検証する (復習)自分の行動の変化を書き出す (復習)記事を書くか、人に話す 結構面倒だと思いますが、自分にとっては効果的でした 0. その本にかける時間を決める 自分がこれから説明する予習と復習は、めちゃくちゃ時

どうも、株式会社プラハCEO兼エンジニアの松原です。 弊社では中級エンジニアを育成するプログラミングブートキャンプ「PrAha Challenge」を2年近く運営しています。累計100名近くの方々が参加して、日々実践的な技術課題に取り組みながら、メンターと技術的な質疑応答を繰り返しています。 実はプラハチャレンジの第1期から第5期までのメンターセッションは全て私が担当しているため、累計100名近くのエンジニアの成長を間近に見てきた経験から「めちゃくちゃ伸びるエンジニアの共通点」を見つけた気がしたので、何かの役に立てばと思い、Zennにも書き残そうと考えた次第です。 ちなみに弊社が運営しているpodcastでも同じテーマについて話しているので、耳で聞く方がお好みの方がいたらぜひ以下のpodcastへ！ TL;DR めっちゃ伸びる人は 分からないことを言葉にするのが上手 情報を鵜呑みにしない

どうも、株式会社プラハCEOの松原です 先日社内のエンジニアに「このSQLクライアントがイケてそう！」と教わったので早速Arctypeを触ってみました TL;DR クエリの補完が最高 チャートやダッシュボードを通して簡単に可視化できる 操作性に優れていて、見た目が綺麗 クエリやダッシュボードごとに権限管理できる プレースホルダーを使えば非開発者ともクエリを共有しやすい 説明しよう、Arctypeとは なんかイケてるSQLクライアントです セットアップ それぐらいしか分からないので、ひとまずDBを立ち上げて実際に使ってみようと思います。こちらのmysql-employeesを使わせていただきましょう docker run -d \ --name mysql-employees \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=college \ -v $PWD/

どうも、株式会社プラハCEOの松原です 先日プラハチャレンジの参加者と雑談していた際に 消す前提で機能を作ると保守性が上がるかもしれない という内容に触れたので、思ったことを記事にまとめてみました。 企画には必ず切り戻し条件を明示する 少し話が脱線しますが、僕はエンジニアになる前はWEBサービスの新規事業企画を担当していて、当時所属していたチームではサービスに追加機能を立案するときは 何が起きたらこの機能を削除するのか という「切り戻し条件」がセットで求められていました。 例えば求人サイトの応募を増やしたいな〜と考えて新機能を立案するとしたら、こんな感じ： 機能概要：スマホ閲覧者にはフッターに応募ボタンを表示する 切り戻し条件：実験的に追加した画面の求人応募率が逆に5%低下したらフッターを削除する 機能を追加しているとき自分はサービスを改善しているように感じがちですが、正確には機能を追加す

こんにちは。株式会社プラハCEOの松原です。 弊社は主にスタートアップの新規事業に特化してデザイン・開発をするものづくり集団です。 最近改めて「プラハでエンジニアとして働く上で最低限必要なスキルって何よ？」という話になったのでリスト化してみました。 ついでにそれらにまつわる知識をうまくまとめてくれている情報源を追記しておくので、何かしらの学習素材として使っていただけると幸いです。 前提 前提として弊社が相手にしているスタートアップや新規事業の開発においては とにかく速く仮説検証し続けること が重要なので、継続的に機能改修しやすい柔らかなソフトウェアを作ることに重点が置かれています。他の事業であれば他のスキルが重視されますし、これらが新規事業の開発において絶対の指針だと言うつもりは全くないので 「あ〜新規事業の開発を主に手掛けているプラハっていう特定の会社(N=1)ではこんなスキルが求められ