最近思ったことの雑メモ part3

目次

概要

最近思ったことや経験したこと、考えたことを雑にメモします。

朝活し出してからめちゃくちゃ生活リズムが安定してきた

朝外でて、夜家に帰ってきた時には絶対にPCを触らないって生活をしてからめちゃくちゃ生活リズムが安定してきました。やっぱ外の方が集中できるし、物理的に場所を移動して体を疲れさした方が夜寝れます。家でキーボード叩いても脳は疲れているから疲れているように感じるけど、体的には疲れていないので全然寝れないです。やっぱ体は動かして疲れさした方が良いです。

できるだけ退職時に考えたことをもとにして就活を進める

僕含めてエンジニアが2人とか極端に少ないと裁量は大きいけど、その人に依存しないと仕事が進められない状況があるので、その人と仲悪いと結構きついです。あと、スタートアップは実力主義なところがあって、自分の実力で課題を解決できるんじゃって人じゃないと辛いなと思います。とく事業始めたてのスタートアップとかは特にその傾向があるなと感じます。事業初めたてだと、相当実力がないとなかなか難しいタスクも振られづらいので成長も鈍化するし。エンジニアとしてもっとできるようになりたいなって側面とチームでなんか課題を解決するプロダクトを作りたいって側面があって、でも今は割とエンジニアとしてもっとできるようになりたいなって気持ちが強いのかなと感じます。いざちゃんと就活する時には、過去を振り返った上で、最適な意思決定をしないとなと思います。

指摘されることは新しい知識を知れる良い機会。なので、あまり向きにならない。相手を肯定しつつ学びに行く。

結構指摘されると向きになりがちなのかなと思うのですが、相手を肯定しつつも学びにいく姿勢が大事だなと思いました。指摘しちゃダメってことは相手を常に肯定しないといけなくてそれもまた辛いなと思います。もちろん言い方も大事ですが。

うまく人とやりたいなら、普段からコミュニケーションをとっておく

やっぱ関係値が高い人の方が関わろうってなるので、普段からコミュニケーションとっておくのは仕事を進める上で大事です。

どうしても通したい提案があるなら、普段から伏線を張っておく

急に突拍子もないこと言うと、周りの人が混乱して「なんで急に言うのかな」と思い、その人の感情が置いてけぼりになってしまいます(その人の感情を考慮した意思決定になっていないと思われてしまう)。何かやりたいことや実現したいことがあるなら、周りに言いまくって普段から伏線を張っておくのが良いのかなと個人的には思います。例えば会社を辞めたい場合、急に会社を辞めたってことを伝えると、「この人忍耐強くない人なんだな」とか「この人社会人として大丈夫か」とか、「今後の家計のことも考えろよ。自分のことだけじゃなく人のことも考えろよ」と思われるでしょう(もちろん普段から仲良くしている人ならそんなことはないと思うけど)。そこで、退職予定日の1 ~ 2ヶ月前くらいから会社での悩みだったり今後のやりたいことのビジョンを普段の会話の中で話しておくと、いざ辞めることを話しても「そりゃやめるよね」と相手は受け入れてくれやすいです。 ただ個人的には伏線ってあまり好きじゃなくて、言いたことあるなら正直に言った方が自分にも相手にも親切だなと思ってしまうタイプなので、明らかに通りづらい提案とかをする際に伏線は使おうと思います笑。あの行動は実は伏線だとバラしちゃうと相手は興醒めして信頼も失ってしまうので、伏線を貼るなら絶対にバラしてはダメです笑。

伏線を張るの意味・使い方～布石を打つとはどう違う？ | 言葉力～辞書よりもちょっと詳しく解説

伏線回収とはなんですか？簡単に - Yahoo!知恵袋

この記事の「OS-1を机の上に置いておく」がそこまでするのかと思って、めちゃ面白かったです笑。なんか適当に理由考えて言えばいいのにと思います笑

明日会社を休みたい… 前日にどんな伏線を張っておく？

できるだけポジティブに変換する

嫌なことがあってもできるだけポジティブに変換したほうが、その日一日を有意義に過ごせるので良いと思います。

定期的に振り返る

自分が今どのポジションにいるのかを把握するために、できるだけ定期的に振り返る方が良いです。

迷いをなくす

ポートフォリオ実装してて思うけど、実装が早いエンジニアって、迷いがあるかないかの違いなのかなと思った。迷いを消すためには、いかに迷う状況に自分を置かないことと、あとは、経験なのかなと思った。 (とはいえ、エンジニア始めたてなら、ある程度迷うことも必要だけどは思うけど)

何か別の環境に飛び込んでそこで何かを得るのは良いこと

今回参加したgoの勉強会でもみんなのレベルがめちゃ高くて、「失敗したらどうしよう、自分のサービスだけレベル低かったらどうしよう」と思って発表会で発表するの恥ずかしかったし、人前で発表するの苦手であまりやりたくないからめちゃ緊張したけど、終わってみると得られるものが多かった。 なので、斜に構えるのではなくて、異なる環境や比較的レベルの高い環境に飛び込んで、どんどん失敗して何かを得るっていうのはすごく大事だなと実感した。

せっかく自分の時間が有り余っているなら、自分の人生に向き合う

自分の人生を前に進めるためにも、自分がやりたいことに、時間をもっと注がなければなと思いました。見なくてもいいものをわざわざ見る理由はないなと思います。

こだわりがあることは面白くて良いこと

ハッカソンで知り合った方が、「僕はUXとかUIに対してとんでもなくうるさくいっちゃうからな」と言っていて、そこに対してのこだわりが強いなと思って面白かったです。どこにこだわりがあるかで、その人の人柄だったり個性が見えてくるなと個人的には思いました。

実現したい未来のために動くことが好き

結構この思考が最近はあるのかなと思った。

スプレッドシートでリストを作って、毎日見返す習慣を作る

自分が行動や経験を通して知ったことや気づいたこと、過去に考えたことをスプレッドシートにまとめて、10 ~ 15分/日に読むことで、同じ失敗を繰り返さず常に成長し続けられる習慣を作れる。 ブログもいいんだけど、毎日見返すのには向いていないのかなと思ったので、スプレッドシートを使うやり方は結構参考になった...(もちろん深ぼりたいならブログのが良いけど)

https://startuptimez.com/966f7d8e367142d693c1f28ecb59a2b8

同じことを言い続ける、同じ態度を取り続ける

行動に一貫性を持たせるためにも、上に書いたスプレッドシートの使い方はいいなと思いました。(もちろんなんか違うなと思ったら軌道修正した方が良いけど)

何を重視しているかが違う人が議論しても、議論は水平になりがち

相手の意見を肯定しつつも、お互いの意見をうまく取り入れられるのが理想。

チームで進めてる時に意思決定をしたいなら、一人一人に確認をとる。その上で決める。一人で勝手に決めない

リーダーは意思決定をして全体の舵を取る必要がある。その際に一人で独断で決めるんじゃなくて、一人一人に確認をとった上で決めたほうが、物事が円滑に進みやすいし協力してもらいやすい。

プライドが先行して、サンクコストが先行して、何も行動しない人にならない

行動して具体的なアクションを起こすことが大事。考えるのは行動してからでもできる。行動をとり続けるから中身が伴って、話にリアリティが付与されたり、熱量が伴う

完璧なものを作るために雑になる

「プロダクトは生き物だからまずユーザーに何かを届けて、そこからより納得のいくプロダクトに進化させるべき。完璧なものを作るために雑になろう。」

頭で考えても分からない問題に直面した場合、常に別のアプローチを試すべきです。完璧なブランドをローンチしたければ、まずは未完全なブランドをローンチすべきだと教わりました。

完璧なものを作るために雑になるって考え方はスタートアップをやる上で結構大事だなと思いました。

18歳で渡米、シリコンバレーで事業を失敗して再挑戦する話｜だっつ｜大東 樹生

根底や全体の仕組みを作って理解する

• OSを作る
• Webサーバーを作る
• プロトコルを作る
• シェルやLinuxを理解する
• sshの仕組みを作る
• neovimをセットアップする
• 全体で何やっているか作って理解する

設計を完璧にやりすぎない

文脈に応じた設計をするのが大事。頭のいい人にありがちなのはすでに先人たちが確立してきた手法を使って設計を進めること。それって今の自分たちが今いる文脈だったり、解決したい課題に適しているかといえばそんなこともない。あくまで先人たちが確立してきた手法の一部分のエッセンスだけを抽出して課題を解決した方が文脈に応じて行動できている気がする。どういう課題を解決したくてこういう設計の一部分のエッセンスだけ抽出して適用したって言えるのが理想。設計をすることが目的になってはダメです。なぜなら設計は何かしらの課題を解決するための手段だと個人的には思うからです。 その課題がクリアになっていないのに設計を適用した場合、その行動は無駄になる可能性が高いですし、課題を解決できないままになる可能性があります。

設計の目的は問題解決 | データ化学工学研究室(金子研究室)＠明治大学 理工学部 応用化学科

非機能要件で違いを出す

機能要件を満たすのはもちろんのこと、ユーザービリティやセキュリティ、設計、保守性、仕様が追加された時にも耐えうる設計、UIの仕様になっているかなどの非機能要件をどれだけ考慮できるかで違いが出るなと個人的には思いました。 仕様通りに作ることは誰にでもできますが、仕様では考慮できなかったユーザービリティや設計面などもエンジニア独自で考慮できたら強いです。 例えばカルーセルの場合、仕様ではプレビューの部分は作らなくても良いと言われても、プレビューがあった方が圧倒的にユーザービリティが良いです。あるべきユーザビリティに持っていくのが大事ですし、その違いを生み出すのもエンジニアの仕事だと個人的には思います。プレビュー追加すんじゃねえと社長に言われたら、その部分だけ消せばいいだけの話です。仕様の枠組みを超えてそこらへんを考慮できたら強いです。プレビューの実装が技術的に難しいとか、開発に時間がかかるとか、そんなのは全て開発者側の都合です。ユーザーにとってはどうでも良いことです。自社開発やるならそういう思考を持った方が良いです。僕もエンジニアはじめたての頃は結構注意されましたが、今でも本当にそうだなと思います。ユーザーにとってどういうサービスであるべきか、どういうユーザービリティであるべきかを考えるのはめちゃ大事です。

つよつよエンジニアの成果物にある5つの特徴 #エンジニア - Qiita

一番大切なことは、ライフプランやキャリアプランを考えて自分なりに落とし所を見つけて充実した人生につなげることなのかなと思います。

このQiitaに上のようなことが書いてあったけど、本当にそうだなと思う。計画を立ててPDCAを回していくのが大事だなと感じる。

フィードバックをもらわないと独りよがりになりがち

自分がどの位置にいるのかも分かりづらい。できれば直近の上司からフィードバックをもらえるのが良い。サービスを作る上でもフィードバックはめちゃくちゃ大事。ある程度歳を重ねても、フィードバックは常にもらった方が良いです。

人脈を持ってくるのもCTOの仕事

昔CTOが言っていただけど、CTOって技術力だけじゃなくて総合的な面で強くないと事業を前に進められないので、そこがすごいなと感じる。

個人開発というか色んな属性の人を巻き込んでチームでやる。だから色んな属性の人とコミュニケーションを取るのは大事

個人でできるものには限界があるし、そもそも個人で何でもかんでもできるって思うのが烏滸がましい気がする。 自分の視野を広げるためには、エンジニア以外の層(営業、CS、デザイナー、マーケター等)と交流するのが大事なんだなあと思った。今やっているハッカソンでも優秀なエンジニアはめちゃいるけど、エンジニア同士で絡むとどうしてもエンジニアリングに対する課題解決に目が行きがちで、解決すべき課題を見つけられないことがあるから、めちゃもったいないなと感じる...

【芹澤雅人】20代で技術のスペシャリストになるのを諦めた“文系出身エンジニア”がSmartHRでCTOになれたワケ - エンジニアtype | 転職type

英語に強くなりたい

外国人の方とハッカソンでチーム開発をしているのですが、英語の情報にアクセスできて誰よりも早く解決策を提示してきたので、やっぱ英語やなと思うようになりました。英語を使って一時情報にアクセスできるのは強い。

ChatGPTをつかうにしても、何が課題なのかを事前に考えた上で、そこをピンポイントに聞いた方が良い

ログを見たら解決するパターンも全然あるので、まずはログを見て考えた方が良いと思います。

運動習慣がないとすぐバテる

久しぶりに運動したら、その日の半日疲れて何もできなかったので、常日頃から運動するのは大事だなと気付かされました。

自分のこと見てってタイプは気をつけた方が良い

嫌いではないけど、人の注意を引くためにわざとどうでもいいことをやり出したりしたら、めんどくさいなと感じます。

自分が何をしたいのかを意思を持つ

エンジニアって仕事の色々な側面が好きだが、何をしたいのかどうなりたいのかがいまだに明確ではない気がする。そこをどうするかが今後の課題だな。今はフリーランスってよりかはチームで働きたいって気持ちが強いな。一人でできないから色んな人の人脈が必要って感じ。

意見を肯定し合う環境を作る

意見をどんどん出してった方が結果的にいいものは生まれやすいと個人的には思います。 なので、意見はどんどん出して、最初は肯定して、なんか違うと思うなら、修正案を必ず提案するようにした方が良いです。

白黒思考ではなく、文脈を大事にする

決めつけるのは良くなくて、文脈を大事にしましょう。 自分と同じような境遇でも、全く一緒ってことはなくて、その人ごとに文脈が違います。 自分ができたから自分と同じようにやればできるでしょと当たり前のように考えるのは安直で、その人ごとの文脈を考慮した上で行動した方が良いです。 「〇〇の時は〇〇する」と覚えるのもあんま良くなくて、なぜなら文脈によってそれらの正しさは変化するためです。AならばBを覚えるのではなくて、文脈とその時の手札に応じて適切な意思決定ができると良いのかなと個人的には思います。

『白か黒』か『0か100か』でしか考えられない極端思考は『究極の生き抜くさ』｜新里哲也｜人をプロデュースするプロ/沖縄ビジネスプロデューサー

色んな人と関わったり、色んなサービスを使って視野を広くする

なんだかんだ視野を広くするのは大事。視野が狭いと狭い世界でしか物事を考えられなくなる。視野を広くするためにも、いろんな人と交流したり、いろんなサービスを使って視野を広げるのは大事だなと思います。

気合いが足りないだけみたいな体育会系みたいな話はしたくないけど、でも気合いって大事だなと思う

人に強制するのは論外ですが、個人的には気合いって大事だなと思います。気合を見せるためには行動で示すしかないなと思います。

自分が熱意があるものほど、人に熱意を持って話しやすくなる。その結果、人の感情に訴えやすい

やっぱ熱意は大事なんだなと思いました。

プルリク書く時は、なぜやったのか、どのようにやったのかの手順を書く

なぜやったのかは共通認識なら書かなくても良いのかなと思うのですが、どのようにやったのかは書いた方が親切だなと思いました。なぜなら、レビュアーはどのようにやったのかをコードを読み解かないと理解できないためです。辛いです。事前にコンテキストが共有されていると脳への負荷が減少されて良いです。

人に興味を持った上でアクションをする

人は自分に興味を持って実際に行動を起こしている人に対しては、好意的に接するのかなと個人的には感じます。なので何かしらお願いをしたかったり、交流を深めたいなら、事前に興味を持って何かしたらアクションをとった上で、その人に声をかけるのが良いのかなと思います。

なんか手土産でお菓子を渡すとかも良い気がします(昔業務委託の人がやってた)。その人の印象がアップします(返報性の原理ってやつ)。 その際にも何にも理由がないのにいきなり手土産を持っていくと「この人打算的だな、計画的だな」と思われてたり、「なぜ買ってきた？」が分からず感情が置いてけぼりになってしまいます。3日くらい旅行に行ってたなどの伏線を事前に会話の中で張っておいて、旅行に行った際にめちゃ美味しかったから食べてほしいって買ってきたお土産を渡すのが自然で良いのかなと個人的には思います。自然じゃない行動をすると人は疑いやすいので気をつけましょう。

返報性の原理とは？4つのパターンとマーケティングで活用する際の注意ポイントを解説 | 株式会社Sprocket

言語を極めるというよりかそのさらに下の土台を極めた方が、どの言語行っても対応できる

その言語特有の機能を知ることは大事ですが、下の土台が固まってないならまず下の土台を固めた方が学習効率が上がりますし、その言語特有ではない問題にぶち当たった時に解決しやすくなります。

エンジニアは勉強しすぎない。行動しながら勉強するか、なんか作る。実際に行動したものじゃないと忘れがち。教科書そのまま見て概念的に理解しても80%忘れる

自分の経験上、概念理解しても80%以上の物事は忘れるので、概念を作って理解できると最高です。忘れにくくなります。

バックエンド強くなりたいなら、Railsから一旦離れてみる

Railsはチャーハンの素みたいなもの。それとご飯を混ぜて炒めれば簡単にチャーハンが作れる(この場合、チャーハンはWebアプリケーションのこと)。 しかし、本当にうまいチャーハンを作りたいなら、油は何を使うか、火加減どうするか、鍋は中華鍋を使うか、玉ねぎの大きさはどうするか、ご飯は冷凍ご飯を使うか、醤油をどのタイミングで入れるか、食材はどこの市場から仕入れてくるか等など、色々考慮すべきものがあります。

何が言いたいかというと、Railsしかやったことなくてバックエンドもっとできるようになりたいって思っても、Railsだけずっとやってたらバックエンドエンジニアとして大きく成長するのは難しいということです。僕はバックエンドはRailsしかやったことなくて、最近3ヶ月間Goを教えてもらって、Goで一からWebサービスを作ったのですが、Railsでは考慮しないものをいろいろ考慮しなくてはならなくて、バックエンド力がめちゃくちゃ上がりました。 Goで0からフレームワークも何も使わないところから開発することで、 Railsをやる際にRailsではこのように抽象化していたんだと気付かされます。その気づきがあることで、今まで手順として暗記していたことが、「そりゃこの手順やらないとDBに接続できないでしょ」と気づくことができます。他にも「これやらないと〇〇できないけど大丈夫か？」と気づくこともできます。気づくことが当たり前になります。なので、バックエンドを極めたいなら一回Railsから離れてみるのは個人的にはオススメです。Railsをどんだけ極めてもRailsで早くサービスを作ることを極めるだけで、チャーハンでいう、チャーハンの素を使って、手順も暗記してめちゃくちゃ早くチャーハンを作ることができるようになるだけです。それだと海鮮チャーハン作れとか、あんかけチャーハン作れとか、カレーライス作れ、ミネストローネ作れってなった時に対応できないです。なので、その下のレイヤーを学んで作ることは大事です。 (いろいろ経験した人が最終的にRailsに落ち着くのは分かる気がする。アプリ作るのがめちゃ楽だから。Goだと例外処理を毎回書かないといけない辛さもある)

資格は考える前に答えを出すための訓練として有効。ただ、実戦で使えることの方が大事。

資格は思考せずに答えを出すための訓練としては有効。ただし、実践で使えないと意味ないので、資格を取るなら実践の練習もした方が良いです。

最高のプロダクト、最高のチームを作る

この記事見て、チームもいいなと思ってきた。

https://dev.icare.jpn.com/recruit-interview_06

どう伸ばしていくかを考えれると強い

これは尊敬している友人に教えてもらったのですが、LLMが今後成長していく中で0→1ができるよりもどうやってこのサービスを伸ばせるか、そこを考えれるのが強いしLLMにはできないと言っていたので、なるほどなと思いました。

今の世の中を見て、5年後10年後どうなるかを予測して行動する

予測して行動するのが苦手なので、こういうのできる人はほんとすごいなと尊敬します。

全体を見渡せるから、開発の問題点もわかるようになる

今参加しているハッカソンではなるべく手を動かさず、全体の方針や仕様の決定、今何を作るべきか、それぞれの人は何の作業をすれば良いか等を考えるようなポジションで活動しています。そのようなポジションで活動していて思ったのが、やはり開発だけやってても全体の景色は分かりづらいなということです。木をみて森を見ずとも言いますが、森が分かるから木における問題点がわかるし、木でこだわるべきところこだわらなくても良いところがわかってくるなと個人的には思いました。

流行りに乗りすぎない、文脈で理解する

ある記事を見てこれが流行っているんだなと思うのも良いですが、文脈で理解したり、解決すべき課題が明確になっている方が大事です。

人を積極的に巻き込む

個人開発者が一時期流行っていたけど、個人でデザインやマーケティング、営業など何でもかんでもやるのは限界があるのかなと感じている。自分一人でなんでもできる人ならいいと思うけど、やっぱチームでやった方が大きな成果は出やすいのかなと個人的には感じる。

誰のどんな課題をどのように解決するか

プレゼンする時は、誰の、どんな課題を、どのように解決するかを話した方が、人に刺さりやすいです。あと、プレゼン以前に、解決すべき課題が明確な方が良いです。これは人の反応を見てればわかるもので、人に話したときに「それめっちゃわかるわ」と相手のテンションが上がると方向性が見えてきます。そこで相手のテンションが上がらないなら、その人が顧客にならないか、もしくは解決すべき課題ではない可能性が高いです。なので、自分一人でこれめっちゃいいアイデアだなと思うのではなくて、そのアイデアを思いついたなら、自分の親しい人や、ズバズバ指摘をくれる人、いろんな属性の人から「それは本当に解決すべき課題なのか、そのアイデアは解決すべき課題を解決できるアイデアなのか」をフィードバックをもらった方が良いでしょう。フィードバックをもらわないと独りよがりのアイデアになりがちなためです。

自分が責任を負いたくないから、人に決めてもらおうとしない

最後は自分で決める癖をつけましょう。

やらないことを決めることが大事

全部載せして最強の状態を作ることもできますが、人の時間は有限なので、何をやって何をやらないか決めるのが大事です。特に何をやらないかを決めることが大事です。

リモートでセルフマネジメントは難しい

リモートでセルフマネジメントは難しい体も疲れないので、もし今度リモートの会社に行く時はコワーキングスペースでも登録しようと思います。

仕事なら作ることが先行するんじゃなくて、課題が先行しなくてはダメ

趣味でやるなら作ることが先行するのは全然アリだと思います。仕事なら、課題が先行してなくてはダメだと個人的には思います。課題を解決するためにソフトウェアが存在するので。

応援する言葉を送る

ダメ出しよりも、応援する言葉を送った方がその人のモチベーションを上げてくれたり、その人がフィードバックを肯定的に受け入れて行動してくれるので、自分も何かアドバイスを求められた時は、できるだけ応援する言葉を送ることを心がけます。

終わり

以上です！