柚子胡椒さん

ソフトウェアエンジニアです。VPoEではないですが、補佐したり似たようなことしてます。

柚子胡椒さん

ソフトウェアエンジニアです。VPoEではないですが、補佐したり似たようなことしてます。

フリーランスについて調べてみた

フリーランスエンジニアになりたいということをゴールにしている人を良く見かけますが、実際どうなんだろうと思って調べてみました。 自分自身は正社員のエンジニアとして10数年働いてきており、フリーランス経験はありません。 そのため、周りに聞いたことや調べたことをまとめてみたいと思います。 「フリーランスになると稼げる」=> △「会社員の給与」と「フリーランスの売上から経費を引いたもの」を同等の収入とした場合の手取りはそれぞれ以下のようになります。 これだけを見た結果としては

柚子胡椒さん

    • ソフトウェアエンジニアのチームがサイロ化する問題

      ソフトウェア開発は当たり前のようにプログラミングだけでなりたっているわけではない。 そのため、エンジニアがプログラムを書くこと以外の仕事をすることも多分にあるのだが、そのときにちょくちょく「できる人がコードを書く時間をうまくとれない」ことが課題としてあがってくることがある。 自分が思うに、これはある程度人数が増えたチームになると発生する。人数が少ないと、どちらにしろ誰ががすぐにやらないといけないため「効率どうこうよりもガンガン行くんだよ」っていう思考だったり、あと、専門性

      柚子胡椒さん

      • 最高のチームってどんなチーム？

        「最高のチームってどんなチーム？」 の問の回答を持ってる人は、過去にそう思えたチームにいたことがある人はなんだと思います。 自分もあります。 なるだけ、一般化してみて最高のチームの条件を洗い出してみます。 自分は最高のチームは次の条件を満たすと考えます。 ・メンバーそれぞれがスペシャリティを発揮している ・メンバーそれぞれが他のメンバーのスペシャリティを認知し、尊敬している ・メンバー間の連携が滑らかで、強固である ・アクシデントが発生し、一時的にあるメンバーの生産

        柚子胡椒さん

        • 課題発見力を分解する

          課題とは「解決しなければいけない問題」と定義されてます。 で、課題発見力はそのままで課題を発見することができる能力です。これがないと、とても悪い状態に陥ってるが、なんかもやもやするだけだったり、はたまたまったく気づかないという自体に陥ります。 どうやって課題発見力を身につけるか。 この能力が高い人は妖怪アンテナ的ななにかがあるわけではありません。 課題とは「解決しなければいけない問題」なのですが、これは「あるべき姿と現状との差分」とも言い変えることができます。 という

          柚子胡椒さん

        フリーランスについて調べてみた

        柚子胡椒さん

        マガジン

        • ざつな思考メモ
          16本
        • わりと丁寧な記事
          1本

        記事

          エンジニア向けのいい感じな会社説明資料まとめ

          自分も作ってみようと思って、参考のため。 ただ認知に寄与するだけでなく、さらに魅力付けもできているような会社説明資料を集めてみました。 mercariVision / Mission / Value だけでなく Foundations があるところがユニーク。 株式会社10xカルチャーがわかりやすい。そしてレンジがすごい。 YOUTRUSTnotionで作られている。 Ubie評価なし & 会社成長連動報酬は思いきってる。 Autify英語が公用語だけど、学習プロ

          柚子胡椒さん

          エンジニア向けのいい感じな会社説明資料まとめ

          柚子胡椒さん

          自戒「難しい」と口に出してはいけない

          何か新しい概念や知識に触れたとき、数秒で理解できるものじゃなかったときに「難しい」という言葉を軽く使ってるケースをよく見ます。 これ、自分の思考がマッチョだからなんでしょうけど、自分はこれを避けるようにしています。人が言うのはいいけど、自分が言う分に関しては意図的に言わないよう、言ったら負けみたいな感覚でいます。 いろんな概念や知識に対して理解するのに難易度は確かにありますし、中には確かに難しいこともあります。ただ、自分は「難しい」と口に出すことは、すなわち「苦手」なこと

          柚子胡椒さん

          自戒「難しい」と口に出してはいけない

          柚子胡椒さん

          1on1むじい

          上司側の立場、部下側の立場のどちらの立場でも1on1をよくやってます。 自分が部下側の立場のときは、予めアジェンダ組んで話したいこと話したら、あとは雑談して、と基本的に満足しているのですが、上司の立場はむじい… ・上司側のお悩み相談の場になる ・話したところで上司は別段なんにもしてくれない みたいなことには絶対にならないようにしています。 ただ、アジェンダが毎回ほぼない人との1on1がとてもむじい… 開始して、シュッと最近の話して議題がなければ10分くらいで終わる、

          柚子胡椒さん

          1on1むじい

          柚子胡椒さん

          Twitterリテラシー for ソフトウェアエンジニア

          Twitterなんて個人の場なんで、好き勝手言わせろよいと、何でもかんでも書いてしまう人がいます。基本的にはそのスタンスでも良いです。 ただ、それでもやってはいけないこともいくつか存在します。 まずは「誹謗中傷」です。言わずもがなです。やめましょう。 誹謗中傷まで行かずとも口が悪すぎるものも控えたほうが身のためです。そういうツイートを見かけた側は嫌な気持ちになることが多いですし、見た人が「絶対一緒に働きたくないな」という感情を抱くのは不自然ではありません。チームで働く業

          柚子胡椒さん

          Twitterリテラシー for ソフトウェアエンジニア

          柚子胡椒さん

          言語化能力を分解する

          言語化能力が低いと悩んでる方を見かけます。 言語化能力とは大雑把にいうと「自分の考えを言葉にし、さらに相手にわかりやすくして伝える能力」と考えています。 そして、これはさらに今から言うようなものに分解できると考えています。 「自分は言語化能力が足りない…」と悩んでる方は、その中でもどこが苦手なのかを把握してからトレーニングなどしてみると良いかもしれません。 ① 考えをつくる力うまく言語化できない、と考えている人の中にはそもそも言語化する対象の考えがないことがあります。

          柚子胡椒さん

          言語化能力を分解する

          柚子胡椒さん

          「なぜ内製で開発するのか？」に対する解答がないと脆い

          ソフトウェアを自社で作っている会社には、内製で開発するためエンジニアを採用して自社で抱えてます。 「なぜ内製で開発するのか？」 この問いに対する答えが浸透してない場合、開発組織はただのコストが高い部門と見らることがあり、縮小の対象となることがあります。 「エンジニアは自分より給料が高いけど、そのわりに…」と考えている人は正直たくさんいます。そしてこう思うことは責められるべきことではありません。 そういう方が着々と昇進して、体制を考える側となった場合に「よし縮小しよう」

          柚子胡椒さん

          「なぜ内製で開発するのか？」に対する解答がないと脆い

          柚子胡椒さん

          「社内政治」という言葉、嫌いですか？

          「社内政治」って言葉をポジティブにとらえてる人ってあんまりいない気がしています。 ただ、自分としてはこれらの言葉に必ずしもネガティブなイメージを持ってはいません。というのも、「社内政治」とは、つまるところは「信頼関係築けてるか？」という話に行きつくと思っており、信頼関係の構築は仕事において必須であると思っているからです。 そもそも「社内政治」ってなんやねんってのを考えてみると、人によっていろんな定義がありそうですが「誰の意見を誰が聞いてアクションをするか否か」等の関係性そ

          柚子胡椒さん

          「社内政治」という言葉、嫌いですか？

          柚子胡椒さん

          テックリードのあるべき姿

          ソフトウェア開発において「テックリード」という役割を設けている会社は多くあります。会社によって、その役割は違うものなんですが、自分なりの解釈を戯言としてメモしておきます。 テックリードのゴールは主に次の二つだと感じています。 ・技術を使って事業を成功へ導く ・事業が成功できる状態までチームを導く よく「技術に優れている人」が「テックリードである」という場所も見かけるのですが、自分として「リード」すなわち「導く」という部分のほうが重要じゃないかなと考えています。 もちろ

          柚子胡椒さん

          テックリードのあるべき姿

          柚子胡椒さん

          チーム開発における課題解決アンチパターン

          この記事を読みました。とても首を縦に振る記事でした。 読んでる中で、本人は十分に自分は課題を解決しているつもりでも、実際はそうはなってないことっていうのがよくあるなぁと思いました。この記事では、思いつくままにどういうパターンがそんな事態になりやすいか、つらつらと書いてみようと思います。 早速。 ① 「不快」を表明するだけパターン冒頭に紹介した記事にあるここのところ。 例えばあまり理にかなっていないと感じる制度に対して「これなんでずっとこうなってるのか謎」「こう変えれば

          柚子胡椒さん

          チーム開発における課題解決アンチパターン

          柚子胡椒さん

          ソフトウェアエンジニアやEMの面接でどういう質問をするのか？（スタンス面の話）

          ここら辺は会社によって違うのかなと思います。会社が求める人物像に依存して質問が変わってくるためです。 ただ、次のような項目はどこの会社でも共通してるのではないのでしょうか。 ・ネガティブメンバーではない人 ・ロジカルな人 ・HRTが守られる人 ・適切な視座を持っている人 ・他責すぎない人 ネガティブメンバーについては、 誰も教えてくれないネガティブメンバーマネジメント の記事を見てください。 また、視座については「 視座の可視化 」も参考になります。 これらのこ

          柚子胡椒さん

          ソフトウェアエンジニアやEMの面接でどういう質問をするのか？（スタンス面の話）

          柚子胡椒さん

          開発組織をテコ入れするなら何をする？

          いま自分は開発組織の生産性向上に取り組んだ仕事をしているのですが、自分が新しくまた別の開発組織に所属したりお手伝いすることになった場合、どういうことを大体どういう順番でやるのか考えてみました。 根っこについて① そもそもなぜ自社で開発組織をもつのか？ への回答を持つ ② どういう人が活躍しているか？活躍して欲しいか？ を決める まずはそもそもなぜ自社で開発組織をもつのか？そこを明確にしていきます。この問いの答えがなければ、さらにはこの答えについて役員同士での理解がなければ

          柚子胡椒さん

          開発組織をテコ入れするなら何をする？

          柚子胡椒さん

          心理的安全性と匿名性について

          「心理的安全性を高めるために、まずは匿名でも意見を集める」みたいなケースをたまに見かけます。 が、自分は正直ほとんどの場合で、これは成り立ないと感じています。 心理的安全性が高い場とは「誰でも意見を言える場」であって、それは誰が意見を言おうと何も不利益がないという信頼関係が構築されている場です。 一方で、「匿名なら意見を言える場」は、実名では言えない理由があることの現れであって、すなわち実名で言えば不利益を生じるかも知れないとみんなが知っている場そのものです。 心理的

          柚子胡椒さん

          心理的安全性と匿名性について

          柚子胡椒さん