最近喋ったことの雑メモ

目次

概要

最近友人と喋って、知らなかったことや印象に残ったこと、考えたことをメモします。

自分が見ている自分と、他人が見ている自分が一致していない時に認知の歪みが起こる

認知の歪みを治すのが大事なんじゃなくて、認知の歪みがあるものだと事前に知っておくのが大事なのかなと思います。理想に近づけたいならレベルアップすれば良いし。たいして興味ないならそのままにしておけば良いし。

認知の歪みとは？代表的な10項目と具体例を紹介｜オンラインカウンセリング うららか相談室

楽しいのが良い。ただ、現実世界の課題を解決したい。DXしたいって感じ

なんだかんだサービスって楽しいのが良いなと思った。しかし、個人開発のレベルで現実世界の課題を解決できたら、嬉しいなと感じる。個人開発で現実世界の課題を解決するには難しさを感じているので、どうにかしたい。

クラウドフレア触ってみたい

全く未知の世界なので、気になる

エンジニアの専門家ポジションでやっていくなら、この考え方は大事

確かにそうだなと思った。気をつけたいのは、成長したいが目的になると結構辛いということ。自分の経験曰く、成長って自分のやりたいことを全力でやった後に、「以前の自分に比べて、実は成長してたんだ」と後から気づくものなので、成長が目的というよりかはやりたいことをやるのを目的にした方が良いのかなと思った。

昔初めてエンジニアなって退職した時、エンジニア出身の社長に以下のことを言われた。 「キャリア初期に開発を3年経験した場合、その後、開発行って専門家目指すか、マネジメントを絡めてPdM/PM行くか、もしくはビジネスからめて起業するか、もしくはフリーランスになるか等、多くの選択肢を持てるので自由度が高くてそっちのが強い」

この時、また人生の分岐点に立たされているなと今でもこの状況を覚えています。 エンジニアをやるとしても3年がピークだなと感じました。自分は飽きそうなのでどうなることやら笑。現実世界の課題解決をすることに関心があるなと最近は思います。

エンジニアの初期キャリアについて

たまたまマターモストを見てたら参考になる文章があった

僕は最初の企業を事業共感100%で選んだのですが、ぶっちゃけスキルがないとその事業に貢献できないし、成長できる環境がないとそのスキルをつけることさえできないので、最初の企業は成長環境を最重視するべきだと思いました。 僕は日本人初のバックエンドエンジニアとして入社したので、技術やコードのことを聞ける人がいなくてかなり詰まることが多かったので、そのように思いました。 なので、、、 ・最低限のエンジニアがいて、聞ける環境が整っていること。 ・数年先になりたいエンジニア像の先輩（目標としたいようなエンジニア）がいること。 ・技術的につよつよのエンジニアやコミュニティが活発で切磋琢磨できる環境が整っていること。

僕も事業共感というよりかは、誰と働くか何のフェーズでを何をするかで会社を選んでいたけど、シードのフェーズはエンジニア1年目とかには結構きついなと感じた。なぜきついのかというと、上の意見と一緒で、自分の実力が伴っていないからマーケットフィットするサービスを作るのに時間がかかるし、マーケ的な施策をやろうとしてもコードをどう書くか分からないから協力したいのに、協力できないもどかしさがあるため。しかもシードのフェーズはエンジニアが2人とかしかいないため、人をサポートする余裕もなく難しいタスクが振られづらい。成長環境としてもどうなんだと思った。以上から考えて、転職するならこれがまずは大事だなと思った。

• 気軽に聞くことができる強エンジニアが2人以上いる
• そこそこ重めのタスクが振られてもどうにかなるフェーズ
• 同じくらいのレベルの人がいる

自社開発向いていないなと感じた

アイデアを自分の力で考えて実現して、他者に良い影響を与えるのが好きだなと感じた。なので、そういう意味だと自社より受託のが向いているのかなと思う。サービスを成長させたいって思考に自分はなれないなと思った。ただ、やるからにはただ早く作るんじゃなくて、ちゃんと保守性や拡張性、インターフェースの使いやすいプロダクトを作りたいなと思う。

リマインド系はすでにいる

限られたデータセットで、人と被らずに、どんなサービスを出すのか考えるのは結構むずいなと感じた。

サービスを使ってもらうこと

自分でアイデアから考えて、デザインも考えて、サービスを作って、マーケティングもして、お金を稼ぐってマジですごいなと感じた。言ってみてー。 人の可処分時間で自分のサービスをつかてもらうってほんとすごい。 個人的には、スマホアプリに可能性を感じている。一般層にアプローチしやすいし、何より課金までのプロセスがすごく楽。もちろんWebの方が間口は広いが、個人開発はスマホアプリのほうが向いているのでは？と思った。 スマホアプリってサブスクリプションまたは広告が主な収入源だなと思った。うまいのがマッチングアプリとかで、マッチしていざトークしようって時にサブスクリプションの登録を要求されること。そんなの払うしかないやんけ。サブスクリプションの登録をどこに出すかは、サプスクリプションモデルのサービスでは大事だなと思った。

シングルサインオンとは

シングルサインオンとは、IDとパスワードを一度入力するだけで複数のサービスにログインして利用できる仕組みです

シングルサインオン（SSO：Single Sign On）とは？意味・定義 | ITトレンド用語 | ドコモビジネス | NTTコミュニケーションズ

メガベンは人脈形成に向いている

ビジネス方面の人との人脈形成に向いているなと感じた。後キャリアに箔がつけれる感じもする。ただ部署と仕事内容と給料がコントロールできないのがネックではある。

アイデアを実現して課題を解決する

最近はもっぱらこの考え方をしているな。実現できて現実の課題を解決することに重きを置いている気がする。やっぱ現実の課題を解決できたら嬉しい。

サービスをどう拡大させていくか

サービスをどう拡大させていくかは、成長企業でしか学べないので、参考になるなと感じる。

数字を追う

エンジニアやっていると、数字に対しての意識があまりないので、いつか追ってみたいなと思った。

考えるだけでは何も生まれない。行動だけに価値がある。

やるのが大事。 成功したいなら、つまらないプライドを捨てて、目的のために自分を犠牲にできるか、死ぬほど恥をかけるかが大事ってこの記事では言ってたけど確かにそうだな。　 勉強するだけで、何も行動してないと、何も生まれない。

ホリエモンが教える「美人の横に座れる人」と「ビジネスで成功する人」の共通点｜新R25 - シゴトも人生も、もっと楽しもう。

お金には色がついている。誰が投資したかは大事。

誰が投資したかは大事。孫さんとホリエモンの1億は違う。孫さんが投資しているなら、競合の会社に投資しないでおこうっていうのも全然ある。

辛い思い苦労をしたからこそ人一倍人に優しくなれる

上場経験する前の辛い時期を知っているからこそ人に優しくなれるんだなと、理解した。

辛い経験をした人ほど優しい人になれるのはなぜ？【辛い経験を乗り越えた人ほどオーラがある】 | ファイナンシャルフリーダム

VPoEに就任しました - ITANDI Engineer Blog

卵は一つのカゴに盛るな

卵を一つのカゴに盛ると、そのカゴを落とした場合には、全部の卵が割れてしまうかもしれないが、複数のカゴに分けて卵を盛っておけば、そのうちの一つのカゴを落としカゴの卵が割れて駄目になったとしても、他のカゴの卵は影響を受けずにすむということ。

卵は一つのカゴに盛るな｜証券用語解説集｜野村證券

エンジニア以外にも人生の楽しさを見つけていきたい

エンジニアリングも良いですが、１回限りの人生、エンジニア以外にも、他にも楽しいことややりたいことに視野を広げてみたいなと思いました。仕事をやっていると視野が狭くなりがちなので、他の可能性にも視野を広げるようにしたいなと思いました。

バリューを出すには根性論ではない。しかし体力は必要

バリューを出すとは、違いを出す、変化を起こす、つまり、「何らかの課題を解決して、状況を変える」ということ。エンジニアは経験や知識に左右されるのでバリューを出しづらい。しかし、そうとは言っても体力は必要だなと思いました。

【コンサル業界志望必見！】コンサル志望者に求められる三つの基礎力

ビジネスドメインを理解してコードを書く。保守性や設計を考慮してコードを書くのが難しい。

コードで実現するのが難しいのかなと思っていたのですが、それも難しいっちゃ難しいのですが、上に書いた、「ビジネスドメインを理解してコードを書く、ただ書くんじゃなくて、保守性や設計を考慮してコードを書く。」のが難しいのかなと思いました。

保守性や拡張性が損なわれるとカスタマーサクセスに迷惑をかける

バグが発生しやすい構造になっていると、カスタマーサクセスに迷惑をかけるんだなと思いました。

選択と集中

選択肢が多いと人は悩みがちでなかなか行動に移せない。選択肢を2個にした方が集中しやすいなと感じた。もちろん全てにおいて選択肢が少ない方がいいってわけではなくて、選択肢が多い方が人生の可能性が広がるよねってパターンもある

アイデアを実装するスピードを高める

スタートアップやっていると、本当にこれだなと思う。

フェーズによって楽しさや自分の仕事に対する目的が変わってくる

例えばもうすでに成長し切った会社のフェーズだと、自分が実行したからサービスが成長したのかが分かりづらく、楽しさを見出しづらい。また、会社に入るフェーズによって自分の目的が変わってくる。例えば本当に一から事業を作り上げようって会社に入った場合、サービスをリリースする実現することに全力をかける。もし、成長途中のサービスを持つ会社に入った場合、いかにこのサービスを成長させるかに全力をかける。つまり、どんなフェーズに入ったかによって、その人の目的が変わったり、やりたいことが変わるのが面白いなと感じた。自分もおそらく成長途中のサービスの会社に入ったら、成長させたいって思うのかもしれない。まだ入ったことないのでわからないが。

成長させたいプロダクトに会うのも大事だが、成長させたいプロダクトがどんな設計で描かれているのかは大事

どんな設計なのかは大事。

自社開発はプロダクトに思い入れがないと辛い

プロダクトに思い入れがないと、なんで成長させないといけないんだろうってなって、辛い。

エンジニアのクリエイティブな側面

話していて、エンジニアの仕事ってどうしても誰かが作った既存のサービスの機能追加やバグ修正がメインになるので、本当の意味でのクリエイティブさはないのかなと思った。自分で課題設定をして、アイデアを考えて、実際に作って、マーケティングして、ユーザーの現実の課題を解決してお金を落としてもらう。実際に行動している人。これがすごいなと感じる。ユーザーの可処分時間を利用してサービスを利用してもらって、しかも実際にお金を落としてもらうのがすごい。ユーザーの現実の課題を解決できるような人になれたら良いなと思った。

【個人開発】世の「家事やれよ論争」を撲滅するスマホアプリをリリースしました #AWS - Qiita

現実の問題を解決したい

個人開発をするとしても、現実の問題を解決したいなと思った。 本当は粗大ゴミの廃棄をline上で完結できる、DXできるようなサービスを作りたいけど、結局また別のサービスを作ることにした。今後サービスを作るときは現実の課題を解決できるサービスを作りたいなと思った。

CRMとは

CRMシステム（Customer Relationship Management：顧客管理／顧客関係管理システム）とは、 顧客を中心としたあらゆる情報を一元管理する営業活動の活動プラットフォームです。

CRMとは? 顧客管理システムの基本機能と導入メリット、選び方 | Zoho CRM

RDBの設計や仕様の先を読むことを怠らない

RDBの設計をする際は、ただ仕様に沿ったものを作るんじゃなくて、「今後ビジネスの展開的にこういうマーケティングをする可能性があるな、だったらこういう拡張性のある設計にしよう」とか、目先の仕様に沿ったDB設計をするんじゃなくて、この仕様から起きる未来の仕様も考慮して設計できると良いなと思いました。

https://zenn.dev/soyanchu/articles/7854f3fe9e7c97#%E8%AD%B0%E8%AB%96%E3%81%AF%E3%81%BB%E3%81%A9%E3%81%BB%E3%81%A9%E3%81%AB%E3%80%82%E7%A9%B6%E6%A5%B5%E7%9A%84%E3%81%AB%E3%81%AF%E4%BD%9C%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%AA%E3%81%84%E3%81%A8%E5%88%86%E3%81%8B%E3%82%89%E3%81%AA%E3%81%84

この事業はこういうことをして作られたとか知りたい

最近flierというサービスを目にするが、出版社とどういうコネクションがあって実現できたのか気になる。まあそれを公開したら意外と出版社とコネクション作るのって簡単やんって思われて、競合がててくる可能性があるけど。toB SaaSはコネクションと業界を経験してきた知識と優秀な営業が必要。一回使ってもらったらなかなか戻れない。toCサービスの場合、アイデアの面白さと広告が必要。ただユーザーの情報が漏洩したら大変なのでハイリスクハイリターンなのと、コンテンツを常に生成しないといけないもどかしさがある。

誰に相談するかは大事

信頼できる人に相談しましょ。そういう意味でも自分は周りに良い人や尊敬できる人ばかりいて、本当に恵まれているなと思います。

真の問題解決にはコミットできそう

ビッグタイトルを１回くらい経験してみたい

人生一回なので、ビッグタイトルを１回くらい経験してみたい。エンジニア3年やるとしたらあと2年後やな。

問い合わせ対応

問い合わせ対応はユーザーのエラーを調査して、自社のバグの場合は報告する。コードを読み解く必要があるそう。

多くの人がやるからそうするんじゃなくて、自分がやるからそうするって考え方でありたい。

実践が伴って初めて自分の血肉になる

知識を蓄えすぎるのは気をつけた方が良いです。

人を巻き込むと強制力が湧く。それか環境を変えても強制力が湧く

個人的には人を巻き込んだ方が自分がしっかりやらないとってなって強制力が湧くなと思う。死ぬほど恥をかいたとしてもこの人を巻き込む経験は大事だなと思った。

答えのない問題に対してのコードを書く

よくエンジニアをやっていると答えのコードを写経してやった感が出る時がありますが、答えのない問題をやるのが一番力つくなと個人的には思います。もし、答えがあるなら最後に答え合わせをしても良いのかと。要は自分のやり方を作るのが大事。

リモート自己管理難しい

リモートは自己管理がむずいのと、バリューを出しづらいなと感じました。出社をするならその分やってる感も出せるので。