Kaketan::Note

人生をやり直すときのバックアップ

やりたいことがない就活生は人的資本を増やすことに集中しようという話

やりたいことがない就活生へ

いきなりですが、やりたいことがないということは、世の中への関心が薄いのが原因かもしれません。
やりたいこと、特に仕事となる行いというのは需要がなければあり得ず、それは則ち世の中の動きに依るものであり、したがって世の中の動きに関心がなければやりたいことは見つからないかもしれません。
やりたいことがある人は、「就職活動」といったものをやる前から興味のある分野があり、既に自分が貢献できる範囲で何かしらの行動をしているものだと思います。

したがって、就職活動が始まって、なにをやりたいかわからないあなたはこれから自分の好きなものを見つけていく必要がありそうです。
そして、それは自分探しの旅に出るようなもので発見できるものではなく、世の中の様々な出来事について「なぜだろう?」と疑問をもち、調べていく過程で見つかるものだと思います。それが学習の本質だと思います。
なので、そういった学習は、仕事をしながらでも、本を読んだり、論文を読んだり、ググったりして行うのがよさそうです。

理想のライフスタイルから逆算する

では、具体的な職業としての夢がない場合どの仕事をすれば良いでしょうか。
ひとつの選択肢としては、自分の理想のライフスタイルから逆算してなにを仕事にするか選ぶとよさそうです。
それは例えば、満員電車に運ばれる通勤が嫌なのでリモートワークをしたいということであれば、営業やバックオフィス業務よりは、ソフトウェア開発や Web デザイン制作などを仕事にするとよいかもしれません。

人的資本を増やす

前述の学習にも通じますが、仕事をするうえでなによりも大事なことは学びつづけることです。なぜかというと、人的資本こそが稼ぐ力であるからです。
たとえば自分の資本ポートフォリオを人的資本、社会資本、金融資本の3つに区分したとします。

人的資本とは、自分の頭のなかにある知識や経験、技能などのことです。
社会資本とは、コネ、コミュニティの力、影響力、発信力などのことです。
金融資本とは、法定通貨、仮想通貨、不動産などのことです。

このうち、レバレッジが効くのが人的資本です。
つまり、人的資本によって社会資本を増やしたり、人的資本によって増やした金融資本をつかって時間を買い、人的資本を増やすなどの運用が可能です。
たとえば、自分が手を動かしてできることが増えれば増えるほど、それを教えることを仕事にできるかもしれないし、貢献によって人脈が広がるかもしれません。
とくに、人脈が広いとか、実家が金持ちとかではないのであれば人的資本を増やすことに特化すると費用対効果が高いといえそうです。

明日から使えるソフトウェア開発効率化 TIPS

今年、実務で Web アプリケーションのチーム開発をする中で「これは習慣化させたほうがよいな〜」と個人的に考えてメモしたものがいくつかあったので、それを共有します。どなたかの参考になれば嬉しいです。

設計

過去に似たようなことをやってないか探す

  • 大規模アプリの場合、似たようなことをやっているところが他にもあることが多いので参考にする(パクる)。

早めに具体レベルのコードを書いてツッコミをもらう

  • ミーティングなどで抽象的な議論で合意がとれたら、早い段階で具体のレベルのコードを書いてツッコミをもらう。(抽象的な会話だとそれっぽくよさそう感が出るけど...)
  • 目指すべきゴールが間違っている状態で道のりに時間をかけることは勿体無いので、自分が目指しているゴールと他のチームメンバーが思い描いているゴールが離れすぎてないかを早めに確認することが大事。
  • そのために、自分の頭の中はこういう状態ですというのを簡単にでよいので、プロトタイプとしてより具体的なコードのレベルのものを書いてみるとツッコミを貰いやすい。

実装

ドキュメントを読む

ログを読む

  • 自分が書いだコードによって実際に発行されるクエリや処理が意図したものであるかどうかをちゃんと見る
  • 意図したリクエストが行われているか、パラメータが適切かだけでなく、N + 1 が発生していないか、意図した render が行われているかなど、テストで漏れそうなところも含めて確認する。
  • ref: エンジニア初級者が意識すべき3つのこと - QKAKE::TECH

質問する

何を伝えるか

質問するときに伝えたほうがよさそうなことは 3 つあるなと思っていて、

  1. 自分がどういう仮説を立てて検証したか
  2. そこから何がわかって、何がわからなかったか
  3. いまどういう仮説を立てているか

これを一度言語化することで、フィードバックが貰いやすい気がしている。
このときどういう仮説を立てているのか(どう考えたのか)が重要だと思っていて、なぜなら、わからないこと(検証がうまくいかないこと)だけ伝えても、仮説の立て方が間違えている場合があり、その2つは連続しているので検証結果だけ伝えると「何を言っているかもわからない」状態になりがちだから。 だから上の 3 つくらいを押さえるとよさそうな気がしている。

いつ質問するか

ググってわかるようなことは自分でググって解決してしまったほうが早いので、じゃあいつ質問したらよいかというのが議題にあがることがしばしばあるが、個人的には、質問するタイミングは、1つの課題について仮説を検証する作業が 3 回以上になってしまったときかなと思っている。
基本的には、課題発見、(1)実装・ググる(仮説を立てる)、(2)動作確認(検証する)、(1)、(2)、解決、課題発見、(3)実装・ググる、(4)動作確認、解決...といった感じで開発すると思うけど、(1) -> (2) や (3) -> (4) の回数が増えてきたときは問題を正しく理解していないことが多いので、効率的に自分の気づいてないこと(あるいは知らないこと)を知るために他の人に質問してしまったほうがよさそうな気がしている。

また、質問したときにどういう回答が来るかを想像してみるだけで「質問している間に自己解決する」現象を再現できることもあるのでオススメ。

テスト

どういうバグが生じるか考える

  • どういうバグが想定できるかを考えて、それが生じないことを示してあげる

責務を意識する

  • テストしたいメソッド、クラスの責務はなにかを考える
  • (1) User がお気に入り登録されたときにメールを送る Job を呼び出すメソッド
  • (2) お気に入りされたことを知らせるメールを送る Job
  • があってそれぞれテストを書くときに (1) のテストの中では「(2) の Job によって正しくメールが送られるか」ついてのテストは書かない。

レビュー

ルフレビューを行う

  • 自らツッコミモードになって、椅子の高さを調整して姿勢も変えるなどして GitHub の Files changed などを客観的に見てみると単純なミスに気づくことがある。
  • 保守性があるか、DRY かなど様々な視点でチェックする。
  • コードレビューの文化がある場合、「レビューしてもらう」「取り込む」「再度レビューに出す」というこのプロセスをいかに少なくするかが時間を効率的につかうためのキーなので、自分で気づけることは自分で気づきたい。
  • それでも気づかないことはしょうがない!そのためにレビューがある!

【MySQL】Using filesort について調べた

Using filesort とは

  • MySQL のクエリの実行計画をみたときに、Extra 列に Using filesort; と表示されること。
  • インデックスを利用しないクイックソートが用いられていることを示している。

なにが問題か

  • Using filesortはインデックスを利用しないクイックソートにより速度が低下する。
    • filesort が何ソートなのかは以下が詳しい。

blog.shibayu36.org

いつ発生するのか

  • ORDER BY 句があるときに適切なインデックスがないと Using filesort が出る。
  • ソートに必要なメモリが sort_buffer_size より大きくなったとき。
    • テンポラリファイルが作られ、メモリとファイルを併用してクイックソートが実行される。
    • ちゃんとインデックスが利用されるようにして、インデックス順で行をフェッチできるようにすれば filesort は不要である。

どう解決するか

mysql>EXPLAIN SELECT name, type, from users WHERE type = 3; 

上記でクエリの実行計画をみて、適切にインデックスが貼られているか確認する。複数のカラムにまたがるクエリの場合、複合インデックスを追加するなどする。

mysql>EXPLAIN SELECT name, type, from users WHERE type = 3 \G 

末尾に \G をつけると結果が縦に表示されてみやすくなるっぽい。

refs