俺のためのライフマネジメントブログ

良い人生を送るために、生活に関わることを書く

vueのcomputedとmethodsの使い分け

computedはリアクティブ(htmlとデータモデルをバインドしたいデータ)が変わった時に再計算されるもの zenn.dev リロードしようが値を保持続けるらしい。 なので、リアクティブな値を使った計算で使う。 メソッドは普通のプログラムのメソッドなので、リアク…

事業ドメインへの理解を武器にする事について

例えば物流を売りにするとする。 確かに、物流を扱う仕事では役に立つはずだ。 しかし、それを売りにしない仕事ではどうなるか。 役に立つ部分もいっぱいあるだろうけど、役に立たない部分もあるだろう。 なので、もっと汎用的な所を売りにした方が良いと思…

理想の会社を作りたい

常に思う。 客に媚びずに社会に需要のあるサービスを提供したい。 幸せ駆動な経営をしてみんなハッピーになる未来作れたら良いのに。 関係者全員がハッピーになるような会社作りたい。

今日の目標

事前の準備を大事にする。 早めの行動を意識する。 人の話を聞くための準備をする。 そのためには事前の行動が大事。 人に働きかけると時間がかかることを理解する。

明日気をつけたいこと

1 細かいとこまで覚えてる 2 準備は大事(昼休憩の時に済ませる、とか工夫すること。朝の時間期待して失敗することある) 3 人に見せたらなんか言ってくるので危険

「お前見え過ぎだろ」のエレベーターピッチ

エレベーターピッチ 「お前見え過ぎだろ」 というサービスは、 まだ知らない事による機会の損失を可能な限り無くしたい問題を解決したい 意識高い系ユーザー向けの、 ポエム&オピニオン投稿サイトです。 ユーザーは視野の広いユーザーの知見を閲覧する事がで…

強い人のコードを読んで

インターフェイス継承とか使って良い感じだった。 最初にインターフェイスに沿って実装するルールにすると、後から追加する際もルールに沿って実装する事になるので、混乱しないで済むようになる。

幸せ駆動開発な会社を作りたい ~ポエム

自分は幸せな会社を作りたい。 幸せを作る組織を作りたい。 商売のタネはなんでも良いので、お客さんと組織が幸せでいて欲しい。 ソフトウェアは目的を持って作られる。 何か機能を追加するとは、何か目的を叶えたいから作られるべきである。 意味あるサービ…

最初の苦労はつきものなのかな

て気がする。 色々試して色々分かるものなのかな。 最初の苦労には目を瞑った方が良さそう

デバック力がとってもいるな、という話

プログラムを書く以前に処理を追っかけっこして読み解かないといけない。 それがめんどくさい。 何が問題であるか 既存の処理がどうなっているか これを正確に読み解かないといけない。 これを読み解いて どうすれば望むように変更できるか それによって問題…

自分が製品のユーザーであることは強い

自分がユーザーであれば、ユーザー調査をする必要がないし、自分がユーザーなのでユーザーファーストになりやすい。 人は欲しい答えが返ってきた時に感謝をする。 「自分が作りたいものを作る」に注力したい。 僕にとってそれは組織なのかもしれない。 優秀…

とあるスクール生と会話した感想

良いとは思ったが機会の損失をしている気がした。 それがなければもっと強くなっていたのに、と思った。 コミュニケーションの活発な企業で働く得はありそう。 どういうメンバーと働くのか大事そう。 その人のおかげで周りのメンバーのモチベーションが上が…

アウトプットを頑張った日 ~自分を褒めたい

今日はアウトプットを結構頑張ったかな。 プログラムというより、組織づくりやコミュニケーション、心構えみたいなのを学んだ日だった。 開発者としてインクリメントを作るのも大事だけど、チームとして結果を出す、みたいなのも大事。 両方できるようになり…

マネジメント論を読んで

部下に責任を負わせる 「xxの責任者はあなたです」みたいな感じで部下に責任意識を持たせるのが良い。 エンジニアに当てはめるなら 話の長いエンジニアがいるから、相手を傷つけずに話を抑えてもらう必要がある。 そして話を出してもらう土壌を作る必要があ…

aws系の本は買わなかった話

僕の今与えられている仕事 + 役割的にAWSインフラの知見はそこまでは求められていない。 けど大事なのは分かる。 なので買うという判断をする自分でいたかった気もする。 僕が買った本は心理的安全性や組織論の本だった。 確かに一人の技術者が出せるアウト…

変わらない事を選んだ親戚を見て

今日は親戚と話をした。 親戚は変わらない事を選んだ。 成長を望んでいないように思えた。 正直話しても学ぶ所が少ないように思えた。 今は営業マンしてないかもしれないけど、昔は部下もいて営業部長をしていたのなら、その時の知見を話して欲しかった。 残…

スピード感あるチーム開発とは

プロダクトはフィードバックを含めて、高速に改善していくのが理想。 アイディアを思いついたらそれを要検討し、市場に放つ。 それに伴うフィードバックを受け、また改善する。 IT企業において、webサービスがユーザーと接するインターフェイスであるならば…

開発したいもの ~with 考えた

考えたい ざっくり ユーザーに使ってもらいたい 利益を産むのは難しいし、金を取るとユーザーがつく可能性は低い 色んな領域に関わることだったら最高(色んなジャンルの人巻き込みたい) コードを書くだけでなく、動画コンテンツでも問題ない 写真コンテンツ…

「起業を考えたら必ず読む本」が最高だった

現実を教えてくれる良い本だった。 起業は甘くない。 金を稼ぐのは大変。 安く売れば良いでは死ぬ。 同僚や友達と経営は死ぬパターン。 資金繰りで苦労する というのが分かった。 起業はカッコいいビジネス用語でやるもんじゃない。 時間もかかるし、しばら…

if文は条件によって実行される部分とされない部分を記述するために使うもの。 例外処理は処理中にエラーが発生した場合に、エラーオブジェクトを補足してログに書き込んで処理を続行したりする際に使う。 apiは戻り値を必要とすることが多い(オブジェクト or…

自分の人生を生きられる人間になりたい

自分で自分の人生を選んで生きる人間になりたい。 自分の人生をコントロールしたい。 ゆるく毎日を積み重ねたい。 ゆるいけど、明確なサボるはしたくない。

ドメイン理解と、実装も含めたプログラミング力を付けたい

両者を磨きたい。 ビジネスの中で、アプリを使ってビジネスをするなら、当然ビジネスの中でアプリがあるので、ビジネス知識がいる。 アプリケーションを実装する際は、仕様や使われ方を考える必要があるので、ドメインの理解が大事。 なぜなら、アプリは利用…

今を頑張ることがキャリアに繋がるのかな

と思う。 入る会社やポジション、メンバー大事だな。。

利用規約の本読んでみた

法的な知識を付けたくて読んでみた。 新しいプロジェクトを始める際に、法的観点の問題も大事で、議題に上がったが、知見がなさ過ぎて困っていた。 まだ何も分かってはいないが、何かサービスを提供する、という行為をする際は、法的観点もなければならない…

PMFやプロジェクトマネージャーの本を読んでみた

まだよう分かってない。 勝てるプロダクトは勝つべくして勝っている 市場のニーズのある商品を投下せよ てのは分かったけど、人員の面は簡単に解決できないし、市場のニーズのある商品を投下するのも簡単なことではない気がした。 ただ、自分の会社での成功…

プロマネ的な知識と設計の知識どっちが対峙かな?

設計の知識 意外と良い気がする。 細かい知識も面白いではあるが、設計の知識も社会人として商売をする上で役に立つ知識な気がする。 仕事は一人ではできず、複数人で役割分担をするが、その際にルールを作る必要がある。 その際に、設計の知識が生きる気が…

本質的な仕事をしないと無駄になりがちなんじゃないか?

て気がしている。 リッチにしようとし過ぎてるから無駄なことを考える気がする。 相手に媚びず、こちらが相手が欲しいものを提供すれば良いだけな気がする。 こちらが追いかけるから、相手に媚びてしまうんだと思う。 そうじゃなくて、相手を追いかけさせた…

独り言

抽象と具体について タグやカテゴリーのようなものが抽象だと思う。 DBの外部キーについて それがあれば、他のテーブルを参照できるもの。 このレコードは、他のテーブルの特定の行を知っている、という概念を表現できる。 それを使えば、親テーブルから子を…

色んなステージで色んな課題があるっぽいな

IT企業における企業の成長を支える、とか、運用をして利益を上げていく、という行為に対して、考える事がいっぱいあるっぽい。 機能追加やバグ修正は容易にはいかない。 色んな事を考慮する必要がある。 俺の頭の中をクリーンにしたい 関心ごとが多すぎる。 …

自社開発と受託だと、自分で会社作る時どっちが良いんだろう?

自社開発 自社製品を客に提供している。 自社製品を売り込んで、それをサポートする体制まで学べるよな気がする。 俺の会社はオペレーションを社内の従業員で回しているが、 外注してオペレーションさせてる会社もある(コルセンとか) 自社製品を売り込むため…