yuki-uchidaの雑思考

Webエンジニアとして学んだことを記事にしてます

League of Legendsで上位帯であるダイアモンド1に到達しました

2017年に始めたLeague of Legendsですが、2024年sprit1でダイアモンド1 44LPに到達しました。

ランク推移

OP.GGによると上位0.5%程度、Riot公式の高レートの定義が「ダイアモンド2以上」のようなので、「俺LoL上手いよ」と言っても恥ずかしくないレベルにはなったのかなと思います。

2019年にプラチナ4に到達してから、ゴールド1(2020)、プラチナ1(2021)、プラチナ2(2022)と、プラチナ前後に4年ほどスタックしていたことになります。 プラチナは当時上位20%程度だったはずなので、ここ2年はかなり実力が伸びた(上位20%->上位0.5%)ことになります。


プラチナスタックしていた頃はTOPやJGばかりやっていましたが、最近は毎シーズンレーンを変えていたので、それによってLoL全体のゲーム理解が出来るようになったのが上手く機能したのかなと思います。

ちなみに今シーズンはTOPレーンをやっていましたが、ミクロ的な成長というよりかはマクロ的な成長によって上手くなったと感じています。

プレイ時間

大変恐ろしいことですが、4000時間以上だと思います。もはや計算することも難しいのですが、かなり昔にwastedonlolというサイトで2000時間という数値を確認しました。 それから時間も立っているので下手したら+3000時間くらい費やしています。

子供のころからそこそこゲーマーだったのですが、まさか大学生になってから出会ったゲーム1つに「高校生までにプレイしたゲームの総プレイ時間程度の時間」を捧げることになるとは思っていませんでした。(50時間*100作品程度の計算)

LoLに近寄ってはいけない

新規にプレイすることはお勧めしません。

あまりに奥深すぎるため、7年ほどプレイしているのにも関わらず一向に飽きる気配がありません。 昔は月に60時間くらいプレイしていましたが、毎日物足りないなと感じていました。油断するとプライベートの時間をゴッソリと持っていかれます。


歯応えのある趣味を求めている人にはお勧めします。「友達の中で一番ゲームが上手かった」レベルでは歯が立たないでしょう。

例えば僕の場合、スマブラ(確か3DSだった気がする)では30時間もあれば上位3%であるVIPに到達できましたが、LoLで上位3%に入るために3000時間では足りませんでした。 トップランナーを目指す場合にはどちらも変わらないかもしれませんが、「ゲームに自信があって色々ゲームを探した結果LoLを始めた」人がLoLには多いので、ビギナー帯(アイアンやブロンズ)であってもかなりゲームが上手いです。

歯応えという点では必ず満足するはずです。

今後の目標

こんなに時間を掛けて何をやっているんだろうなと虚無感に襲われますが、意外に成長を感じるのでここまで来たら上位0.1%位(マスター帯)は目指そうかなと思っています。(これがサンクコストか・・・)

正直もうLoL卒業したい、けど辞められへん。面白すぎて。

タバコ嫌いのエンジニアが水タバコ(シーシャ)にハマった理由

ここ1年くらいシーシャにハマっている。ハマりすぎてシーシャ機材も買った。

出会い

渋谷でお酒飲んだ後に友人とシーシャ屋さんに行ったのがシーシャとの出会い。 そこのシーシャ屋さんはPCを触っている人もたくさんいて、シーシャ屋を作業場所にしている人がいるというのをここでは初めて知った。

自分は週末にカフェに行って作業をすることが多いのだが、カフェ巡りも飽きてきた所だったので、シーシャ屋さんに行って作業をするというのが趣味になった。

シーシャ屋さんを作業場所に

週末になるとシーシャ屋さんを調べて3時間ほど勉強や作業をして夕飯を食べて帰るというのを趣味にした。 背の低い椅子だと腰が少しキツくなってくるが、カウンターで作業しやすいシーシャ屋さんもあるので、意外と作業場所適性が高いのだ。Wi-Fi・電源も当然のように対応している。 自分がよく行くシーシャ屋さんはシーシャのホースを保持するアームも貸し出しており、ホースを持つ必要すらなかったりする。

新しい趣味を見つけられたし、シーシャの世界に少し詳しくなれたので結構良かった。

家シーシャ

シーシャ屋巡りもそこそこやってみると、やはり値段がネックになってきた。長居しても3,4時間程度で、値段は3000円程度かかる。喫茶店であれば高くても1000~1500円だと考えると、高い趣味だ。

なので、家でもシーシャを吸えるように機材を購入した。メルカリでシーシャボトル・トップ・フレーバーが10000円程度で購入できた。 シーシャのフレーバーは50g(約4回分)で2000円程度なので、フレーバーだけで言えばシーシャ屋さんの値段よりも格段に安く吸うことが出来る。

しかし、家シーシャの場合、「外出先で作業や勉強をすることで気分転換になる」というメリットが得られない。そして何より「シーシャの味が安定しない・美味しくない」という大きな問題が発生する。

シーシャは炭を使ってフレーバーを加熱する関係上、熱量の管理が肝だ。この熱量の管理の仕方は使っている機材・加熱するフレーバーの耐熱性・吸い方によって変わるため非常に難しい。熱量が多すぎると焦げた煙になって喉が痛くなるし、少なすぎると生焼けになって煙が出なかったり味がうまく出なかったりする。

シーシャは作り手のスキルが味にかなり影響する。これはかなり誤算だった。 自分はコーヒーも好きで焙煎から行うこともあるのだが、感覚的にはコーヒーよりもずっと作り手のスキルが敏感に影響する。コーヒーは豆の質が良ければ多少変な抽出方法をしても不味くはならないが、シーシャは不味くなる。

ハードルが高いのであまり人にお勧めできる趣味ではないが、自身のスキル向上がわかりやすく現れるものでもあるので面白い趣味だ。

家で楽しめる趣味を探してコーヒーを趣味にした人はシーシャも合うと思うので、試してみたらどうだろうか。 最初は難しいかもしれないが、探究しがいがあって面白いはず。

ながら勉強のススメ

「ながら〇〇は良くない」と良く聞いていたのでしないように気を付けていたけど、最近はかなり頼っている。

特に音楽を聴きながらプログラミングや読書をするのはかなり頻度が高く、大学生の頃はアニメ見ながら作業したりもしていた。

マルチタスクは効率が下がるという話について

これは体感的にも間違いない。 音楽を聴いたりアニメを見たりしている以上、そちらに情報処理のリソースが割かれてしまうのは当たり前で、効率を考えればやるべきではない。

「ながら〇〇」の効果

効率を考えたらやるべきではないんだけど、実際には必要だなと思っている。 「ながら〇〇」の良いところは、下がっているモチベーションを無視して作業を行うことが出来ること。モチベーションに満ち溢れていて、勉強が楽しくて仕方がない状況にできれば最高だが、そういう状況は稀で基本的には嫌々ながらやることになる。 嫌なことであっても、音楽などの好きなことを並行でやることでモチベーションを維持することが出来る。

モチベーショングラフについて

モチベーションが上がらない時の対策法として、「やる気がない時は5分でいいから机に向かってみる」という方法が提案されることがある。 この方法は非常に有効だと思うが、これが有効な理由は、「モチベーションは最初は低くて続けていると段々と上昇していく」というのが理由だと思われる。 なので、最初のモチベーションが低い状況を無視するために「ながら勉強」をするというのはそこまで悪いアプローチではないだろう。

実際に、途中から勉強に集中できてきて音楽が聞こえなくなったりイヤホンを外したりすることは多い。 モチベーションが上昇するまでは「ながら〇〇」を行いモチベーションが上昇したら辞めることで、安定したパフォーマンスを出すことが出来る。

コードレビューの効果と時間のトレードオフを考えるのが難しい

エンジニア・チーム開発経験が5年以上ありますが、未だに「コードレビューは難しい」と感じています。この理由について、自分の中で言語化出来てきたので、それについてまとめます。

コードレビューの効果

一般的に、コードレビューは以下のような指標を満たしているかを確認するために行われます。

  • 良い設計になっているか
  • コードの可読性が高いか
  • 求める要件を満たしているか
  • バグがないか
  • セキュリティ上の問題がないか
  • パフォーマンス上の問題がないか
  • テストの網羅性が十分か
  • コードスタイルに一貫性があるか
  • コメントやドキュメントが適切に書かれているか

これ以外にも、チーム開発において良い副作用を求めて行われることがあります。

  • 技術的ノウハウの共有
  • コード責任を複数人で分散する
  • コードをメンテできる人数を増やす
  • チーム内のコミュニケーションを促進する

非常に多くのメリットがあるため、コードレビューというのはエンジニア組織では一般的になっています。

これらのメリットを最大限享受するのは難しい

一方で、これらのメリットを最大限享受するのは難しいと思っています。 複数人の知恵を結集させることで、より良いコードにできることは事実ですが、これにはトレードオフがあります。

それは、「コードレビューによる効果」と「コードレビューにかかるコスト」のトレードオフです。 コードレビューは、短い時間で終わらせることもできるし、何時間もかけて丁寧に行うことも出来ます。そのため、コードレビューによる効果を最大化させようとすると、どうしても時間がかかってしまいます。

このトレードオフを考えながらレビューをするのは、非常に難しいと思います。

トレードオフを考えるのが難しい理由

コードレビューの指標が多岐に渡っている上に複雑

コードレビューの指標に関する記事は非常に多くあります。例えば、Google's Engineering Practices documentationには、以下のような指標が記載されています。

しかし、これらの指標は一つ一つが非常に複雑で経験のいるものです。 例えば、「リーダブルコード」や「良いコード/悪いコードで学ぶ設計入門」などの書籍でこれらの技術について説明されています。

Googleの指標を元にコードレビューをするにしても、非常に多くの知識が必要とされるため、コードレビューの効果を最大化させるのは難しいです。時間をかけ過ぎても良いコードレビューが出来ると限らないため、ある程度の時間を掛けたらレビューを切り上げる必要があります。

トレードオフのどのラインを狙ってコードレビューするべきかが明確になっていないことが多い

僕の経験はまだまだ浅いものの、「コードレビューで担保したいライン」が明確になっていることは非常に少なかったです。そして、このトレードオフについて議論されている記事もあまり多くないように思います。

このトレードオフは、時と場合によって最適解が変わるため、あまり公開の場で議論されていないのではないかと思います。

プロジェクトによって重視する指標が異なる

プロジェクトによって、どの指標を重視するかは異なります。 金融系のプロジェクトであれば、バグやセキュリティ上の問題があると利益やサービスの信頼に関わるため、非常に重くレビューされるでしょう。一方で、PoCやOSSなどであれば、多少バグやセキュリティの重要度は下がります。

こういった理由から、コードレビューのトレードオフのベストプラクティスを話すのは難しいでしょう。

人によってスキルが異なる

コードレビューを行う上で、必要なスキルを持っているかいないかは人によって様々で、良いコードレビューを行うためのコストは人によって変わります。そのため、「コードレビューは何分以内で終わらせる」といった制約を決めるのも容易ではありません。

設計や命名に関してのスキルがあまり無い場合には、多くの時間を掛けなければまともなコードレビューは出来ないでしょうし、逆にスキルがある場合には短い時間でコードレビューを終わらせることができるでしょう。 特に、ドメイン知識に関してはプロジェクトに新しく入った人が十分に確認することは難しいです。

こういった理由も、コードレビューのトレードオフのベストプラクティスを話すのを難しくしている理由でしょう。

人によってコードレビューに関する心構えが異なる

明確にコードレビューの目的や役割について議論していない場合、レビュワーによってどの指標を重視するのか、どの程度時間をかけて行うのかがバラバラになります。

例えば僕の場合は「可読性」「保守性」を重視してレビューを行い、「機能性」「セキュリティ」に関しては薄くレビューしてしまうことがあります。これは、「レビュイーが機能性については確認しているだろう」「セキュリティ的なスキルが浅いので他のレビュワーに担当してほしい」という気持ちが出てしまい、「比較的スキルのある可読性や保守性を重点的にレビューしてしまう」ためです。 プロジェクトごとにコードレビューで担保したい部分を明らかにしておくのが理想だとは思いますが、コードレビュー基準などが明確になっていない場合は、無意識でこのような行動をしてしまいます。

また、バグやセキュリティ上の問題が発生するのを恐れて、効果が薄いのに時間を多く掛けてしまうこともあります。日々のコードレビューの中で、「自身のコードレビューが適切なのか」という疑問が湧くことが多々ありますが、これはこういった問題があるためだと思います。

コードレビューの費用対効果を最大化させるためにできそうなこと

レビュイー・レビュワーの責任を明らかにしておく

先述の通り、「比較的得意な部分は重点的に確認し、他が疎かになってしまう」ようなことがある場合には、レビュイー・レビュワーの責任を明らかにしておくと、問題が緩和されそうな気がします。

例えば、「レビュイーが機能的に問題ないことを確認し、レビュワーが可読性や設計についてレビューする」といった形で、責任を明らかにしておくと、それぞれがレビューを通して行わなければならないことがわかりやすくなるでしょう。 コードレビューを通して、レビュイー・レビュワーがそれぞれチェックした部分を明記していけば、漏れているレビュー観点なども都度相談することが出来ます。

コードレビューを通して担保する内容を明らかにしておく

これは一つ前の内容と被るところですが、コードレビューを通してどのような部分を重点的にレビューするかの認識を合わせておくことで、より良いレビューができると思います。 「とりあえず問題がないか見てほしい」という曖昧な依頼だと個々人によってレビューの質に差が出過ぎてしまいますし、「十分なレビューが出来ているだろうか」という精神的な負担になってしまいます。

適切なレビュワーアサインをする

個々人によってスキルが異なる以上、レビューの質を保つためにはレビュワーのアサインを適切にする必要があるでしょう。 例えば、プロジェクトの重要な処理を変更する場合に、プロジェクト経験の浅い人だけをアサインするのは危険です。プロジェクト全体の設計やドメイン知識などは、一朝一夕で身につくものではないので、個々人のスキルをある程度把握した上で、適切なアサインをすることで、コードレビューの質を担保することが出来ます。

コードレビューに必要なスキルを明確にする

前述の通り、コードレビューには非常に多くの指標があり、時間をかけてチーム全体でそのスキルを身につけていき、「チームとして適切なレビューができるようになる」必要があります。 全員が全体的にスキルを身につけていく方法もあれば、「Aさんは設計が得意だから設計に関するレビューを行い、知識を共有する」「Bさんはセキュリティが得意だからセキュリティ上の問題が発生する可能性がある場合にはレビューを行い、知識を共有する」といった方法もあるでしょう。

まとめ

  • コードレビューは難しい
  • コードレビューにかける時間と効果のトレードオフが存在する。そのトレードオフの最適解は(恐らく)人・チーム・プロジェクトによって変わる
  • チームやプロジェクトごとにコードレビューの目的・役割分担を議論して明確化しておくことでより良いコードレビューができる(はず)

コードレビューは非常に多くのエンジニアが経験することですが、多くの人が行う作業にしてはかなり難しく、暗黙知になっている部分が多いと感じています。コードレビューに悩んでる人達から話を聞いて、自身の状況にあった解決方法を探していきたいですね。

コメント大歓迎です。是非お話聞かせてください

副業データサイエンティストが5年間で読んだ本

この記事について

バックグラウンド

本業はTypeScriptを主に書いているWebエンジニアで社会人5年目。副業ではデータサイエンティスト/機械学習エンジニアをやっていてこちらも5年目。

この記事を書いた理由

最近読んだ「科学的根拠に基づく最高の勉強法」という本の中に、「思い出す頻度が高ければ高いほど定着する」という話があった。 なので、読んだ本の内容を思い出し定着させるきっかけとするためにこの記事を書いている。

紹介する本のラインナップについて

統計や機械学習の理論をガチガチにするのは難しいと判断して、理論寄りの書籍は非常に少ない。PRML機械学習プロフェッショナルシリーズなどの本についても、読んだ本もあるが、最近はほとんど諦めて読んでいない。

なので、紹介する本を読んだら優秀なデータサイエンティスト/機械学習エンジニアになれるというわけではないので注意してほしい。あくまで自分が副業でデータ分析案件に関わっている中で、必要な知識を得ていったらこのようなラインナップになった。 (PRMLやら機械学習プロフェッショナルシリーズは業務から遠いがジワジワと効いてくるタイプの本なので、読みたいとは思っているが、今後のキャリアを考えたときにここに投資するべき悩んで動けていない)

また、そこまで印象に残っていなかったり、エンジニアリング全般の書籍、プロダクトデザイン・マネジメント的な本は除外している。

読んだ本

Pythonで始める機械学習

この本は、学生の頃に読んでいた本で、機械学習系の本で一番ヨレヨレになっている。

当時はscikit-learnが鬼門で扱いが難しいなと感じていた。今ではデータの型とか一次ドキュメント読んでエラーの理由が理解できるようになったが、昔はそうではなくて、この本を進める中でもエラーにめちゃくちゃ悩まされた。しかし説明している内容は非常に良く纏まっていたと思う。 自然言語処理でよく使うBag-of-wordsについては「プログラミングで文章を処理するときはこうやって文字のまとまりを作るのか」と非常に興味深かった。

この次の書籍の「達人データサイエンティストによる理論と実装」と似たような内容なのでどちらかでもよいが、複数冊あると「重なるトピックは重要」だとわかるので、そういった意味でも複数冊勉強した。定着にもなってよかった。

達人データサイエンティストによる理論と実装

この本は、大学生の頃から新卒一年目くらいの間に読んだはず(その時は第二版だった)。この記事を書くために5年ぶりくらいに開いたが、絶対に必要な知識が纏まっているなと感じたので、機械学習の入門したい人にはお勧め。

ロジスティック回帰やサポートベクトルマシン(SVM)、決定木などの非常に有名で強力なアルゴリズムを学ぶのに非常に役になった。また。データの前処理(欠損値処理・カテゴリカルデータの処理)やパラメータチューニング、アンサンブル学習など、今でも前提知識として必要な内容だと思うので、入門としては非常に良かったと思う。

Tensorflowを使って畳み込みニューラルネットワーク(CNN)やリカレントニューラルネットワークを動かすチュートリアルもあり、深層学習入門としても有効だった。

詳解ディープラーニング / つくりながら学ぶ!PyTorchによる発展ディープラーニング

「詳解ディープラーニング」も、大学生の頃から新卒一年目くらいの間に読んだはず(その時は第一版だった)。学生の頃はこの本が非常にわかりやすくて重宝していたのを覚えている。 この本でKerasを学んで卒論を書いたし、インターン中にも何度も読み返した。最近ではKerasではなくPyTorchが普及していると思うが、第二版ではPyTorchも採用されていてそこは安心して良さそうだ。ただし、第二版も2019年出版なので、情報としてはかなり古いかもしれない。

深層学習で必要な線形代数に関する内容も軽く含まれていて、ニューラルネットワークから始まり、ディープニューラルネットワークに進む。 学習の効率化のためのドロップアウトや学習率の探索、Early StoppingやBatch Normalizationなどによって深層学習モデルの精度が上がっていくのが非常に面白かった。

また、当時はとしてはかなり応用的な話題だった「Attension」や「Encoder-Decoder」についても踏み込んでいて、入門から応用までカバーしていたので、当時は「今後どうやって勉強していけばよいのか」を考えるうえでもかなり解像度を高くしてくれた書籍だった。

この書籍は既に情報が古くなっていそうなので、今だとこちらの書籍のほうが良いかも。 残念なら自分は最後まで読み切れていないが、「OpenPoseによる姿勢推定」「GANによる画像生成」「Transformerによる感情分析」など、面白いユースケースごとに章が分かれていて、少なくとも読んだ範囲では良書っぽかった。解説もかなりわかりやすい。

データビジュアライゼーションの基礎

この本は、「データの見せ方・伝え方」を学べる本で、一度は読んでおいた方が良いなと思って読み始めた本。

データ分析関連の仕事をやる上で、「適切な可視化方法を扱える」ことは大きな強みになる。 機械学習エンジニアの場合は、精度改善をするためだったり、データの特性を理解するために様々なアプローチで可視化する必要があるし、データサイエンティストの場合は、ユーザー情報やらビジネス的な数値をを可視化して他人に見せる必要が出てくる。

グラフにも非常に多くの種類があり、棒グラフ・円グラフやヒストグラム、散布図以外の可視化も沢山行うことになる。箱ひげ図・バイオリンプロット・エラーバー・ツリーマップ・パラレルセットなど、飛び道具的な可視化方法も知っておくとかなり役立つ。これらは知っておけばパッと出てくるが、知らないと知っている可視化手法をこねくり回して時間をかけてしまうからだ。

「データ分析では必携!」というほどではないが、手元に置いてあるとたまーに仕事が数時間短縮できるかも。

Kaggleで勝つデータ分析の技術

機械学習をやる上では特徴エンジニアリングや評価指標・パラメータチューニングに関する書籍は持っておいた方が良い。 この本は2019年出版なので、もしかしたらもっと良い本があるかもしれないが、当時はほとんどKaggleの本がなかったので重宝した。

出版当時と今を比較しても、LightGBMやxgboost, CatBoostなどのライブラリで使えるGradient Boosting Decesion Tree(GDBT)が強いままなので、Kaggleで必要な知識が昔とは違うわけではなさそう(Kagglerじゃなくて、Kaggleのソリューションを参考にするくらいの人間だが、多分そう)。であればこの本の価値は今でも十分あると思う。

ところで、データ分析コンペの知識が昔と比べて大きく変わってるわけじゃない(2019年前後で流行ってたアルゴリズムを使っても勝負になる)のを考えると、競技プログラミングみたいに一分野として固まってきたのかなぁという気がしている。昔は「Auto MLとかが出てきて全部やってくれるようになるの?」とか思っていたが、今のところはそうではなさそうだ。

機械学習のための特徴量エンジニアリング

機械学習の精度を上げるためのテクニックが纏まっている本。非常に薄いので読み物としても軽く楽しめた。

自然言語処理では文章の中で重要な単語の重みと高めるためにTF-IDFという技術を使ったり、ストップワードを定義して無駄な単語を除去することがある。こういった自然言語処理での細かいアプローチだったり、カテゴリ変数のエンコーディング方法、次元削減の方法など、特徴量をいい感じにする手法が多く載っている。

個人的に推薦システムが好きなので、協調フィルタリングに関する情報が載っていて面白かった。この本読んでから映画の推薦機能とか試したりした覚えがある。

今となってはここまで細かい手法を書籍で学ぶ必要があるかは怪しいところ。当時はあまりここまで細かい特徴量エンジニアリング手法に踏み込んだ書籍はなかったのでとても良い本だったと思うが、今では新たな特徴量エンジニアリングの書籍も出ているようなので、そちらを検討してもよいかも。

AIアルゴリズムマーケティング

この本は推薦システムの勉強をしていた時に読んだ。あまり期待せずに読んだのだが、実際にはめちゃくちゃ面白かった。

Spotifyのレコメンデーション機能に感動して、漠然と推薦システムが好きだったが、この本の「レコメンデーションサービスのカギとなるビジネス目標として適合率だけではなく、ユーザーからの目新しさや意外性、多様性も考慮する必要がある」という記載をみて「そうそう、意外性とか多様性が考慮されてるレコメンドは面白いんだよ」と気づくことができた。 この本を読んでから、RecSysという推薦システムのトップカンファレンスの論文読んだり、論文読み会に参加したりしたので、レコメンデーション機能の面白さを教えてくれた本だと思っている。

推薦システムのサンプルコードが書いてあるわけではないので、実際に手を動かしたい人にはお勧めしない。次に紹介する「推薦システム実践入門」が良いだろう。

推薦システム実践入門

ずっと待ってた、もっと早く出てほしかった、推薦システムの入門ができるサンプルコード付きの書籍。

推薦システムを実現するためのモデル作成方法や、精度の評価方法が書かれていて、この本があればなんとかそれっぽい推薦システムを作ることができる。 深層学習が流行るまでは、推薦システムは協調フィルタリングが一般的で、コンテンツの情報を利用せず、「ユーザー属性が似ている人が好んでいるものを推薦する」仕組みが多かった(はず)。 しかし、最近はコンテンツ情報も含めて推薦システムを組んでいることも多いようだ。Spotifyも昔は協調フィルタリングで、ユーザー属性ベースの推薦をしていたが、ハイブリッドになったそうだ。

学生の頃に以下の記事を読んで、「なぜSpotifyの推薦システムが素晴らしいのか」がわかって感動した覚えがあるので非常に思い出深い。(Spotifyは音楽を好きにさせてくれたサービスで大好きだ) www.forbes.com

この本は協調フィルタリングだけではなくコンテンツベースの推薦機能についても記載されていたり、普通の機械学習モデルの評価には使わない推薦システム専用の評価方法であるMean Reciprocal Rankやnormalized Discounted Cumulative Gainなどもきちんと書かれていてとてもよい。

話は変わるが、推薦システムは人間が「その推薦を良いと感じたか」がベースとなっていて、結構「感情的」な世界だと思っている。

例えば、推薦結果に「なぜあなたにこの商品が合うのか」という文章を付与すると購入率が大きく向上するらしい。これは、人間が「その理由はともかくなんとなく納得できる」「自分のことを理解してくれているという感覚」が大きいと思う。これが自分の中では推薦システムの面白いところだなぁと思っているので、心理学的なアプローチで実装されている推薦システムがあったら面白いなーと。

A/Bテスト実践ガイド

通称カバ本。僕はあまり知らなかったが有名っぽい。 とある会社で推薦システムのA/Bテストやったときに読んだが、入門から実践までカバーしていて、A/Bテスト始めてやるなら絶対に読んだ方が良いなと思った本。

A/Bテストをどうやって開始して結果を分析すると良いのかがわかる。A/Bテストで初心者がよくハマる分析の罠とか、分析で必要な統計知識などが纏まっている。 最近はA/Bテストをやっていないので内容について忘れてきているが、また必要になったら必ず読み直すと思う。

実践的データ基盤への処方箋

所謂データ基盤を作る立場のエンジニアにお勧めしたい本。 機械学習やデータ分析をするのが普通になってきた昨今では、大量のデータを格納し、整理されたデータ基盤を構築しなければならない。格納されるデータも音声だったり画像だったりcsvだったりテキストだったりと、非常に多様だ。

データ基盤の以降は簡単にはできないので、膨れ上がるユースケースに対応するためには事前に綿密に検討されたデータ基盤が必要となる。

僕はそこまで大きなデータ基盤を作ったことがないので、この本で書かれていることの10%~20%くらいしか身についていないと思うが、データ基盤構築の上でどんな役割が必要がかとか、デザインパターンとかは軽く読んでおくだけでも脳内インデックスができてよいと思う。

その他に読んだ本

上記で挙げた以外にも、PythonSQL(Database)周りの本は結構読んだ。データを扱うエンジニアはPythonSQL(DB)からは逃れられないから読むしかない。

SQL系はミックさんの本をたくさん読んだり、DBスペシャリスト試験の勉強したりした。

Pythonに関する本ではロバストPythonが良かった。Pythonは動的型付けなこともあり、雑に書くと頑健なコードにならないので、mypyなどを使って型推論ができるようにしたくなる。型に詳しくない人は手元に置いておいて、たまに読み返すと価値がありそうだ。

ここまで読んだ本を列挙してみて「あれ?もっと読んでたはず・・・」と思ったのでもう一回部屋を見回してみたら、組織の本とかプロダクトマネジメントの本の方が多いことに気づいた。データサイエンティスト(というかデータアナリスト?)はビジネス指標をベースにビジネスチームと話をすることが多いのでビジネス方面の知識(もしくはコミュニケーション能力)が必要だったのかもしれない。

「きょうのはてなブログ」機能が面白い

一昨日書いた ↓の記事のアクセス数がかなり伸びていたので少し調べてみると、「きょうのはてなブログ」に選ばれていたようだ。 yuki-uchida.hatenablog.jp

きょうのはてなブログとは

調べてみると、「きょうのはてなブログ」ははてなブログ編集部が手動で探して特集を組んでいるらしい。 僕の記事も、X(Twitter)以外で告知しておらず、特集に選ばれるまでは20PV程度しかなかった。なので、この「きょうのはてなブログ」に選ばれるのにPV数は関係ないようだ。 正直なところ、「毎日大量の記事が出るのによく見つけたな・・・」という気持ち。

詳しくは下記記事参照。 blog.hatenablog.com

きょうのはてなブログに選ばれると

きょうのはてなブログに選ばれると、はてなブログTOPページに表示されるため、多くの人に見てもらえる。特集に載るまでは20PV/日だったが、特集された日は200PV/日来た。スターも貰える。嬉しい。嬉しくなってこの記事も書いているので、書き手のモチベーションを上げる効果もあるらしい。

また、普段見てくれる人とは違う層にも見て貰える。僕のSNSはエンジニアとしか繋がっていないので宣伝してもエンジニアしか見に来ないが、選ばれたきっかけでエンジニアじゃない人達にも見て貰えた。元々は技術系の記事ばかり書くつもりだったので、技術系以外の記事も書こうかなという気になっている。こちらも書き手のモチベーションを上げる効果がある。

以下の画像は「きょうのはてなブログ」に選ばれた記念で撮ったスクショ。 編集部がリード文的な物をつけてくれるので、ちゃんと読んで内容を分かった上で選んでくれているらしい。

きょうのはてなブログに選ばれた記念

所感

ブログプラットフォームとして、「編集部がちゃんと読んで発掘してくれる」機能というのは意外と珍しいんじゃないかなと思った。大体のプラットフォームは、アルゴリズムによってホットな記事を見つけたりはしてくれるが、一つ一つ読んで推してくれることはあまりしない(あっても人手かどうか分からない)。 人手でこれを実現するのはコストが掛かるのでやらないのが普通だと思うが、はてなブログ編集部は強い気持ちを持ってこの特集を組んでいる。

サービス運営の間では、時間が経つと競合が大体似通った機能を実装してきて、差別化が難しくなってくる。その上で「ユニークさ」のようなものが感じられるとサービスを好きになりやすい。(そんなに簡単に差別化できたら苦労しないが、ちゃんと差別化できているのは凄い)

記事執筆のモチベーションを維持するために「人の役に立つ」ことを諦める

2024年は、「技術発信を頑張る」というのを目標にしている。 この目標は1月に設定して、既に3か月が経過しているが、今のところ上手くいっていない。

書いた記事はまだ二つだけで、この記事を書くにもかなり苦労した。

zenn.dev zenn.dev

目標を設定したときはモチベーションに満ち溢れていたが、記事を書こうとしたときには既にモチベーションの低下が始まっていて、一週間くらいかけて”頑張って”記事を書いた。 なんで「モチベーションが下がっているんだろう」というのを考えて、自分なりに理由が見つかったのでまとめておく。

モチベーションを低下させる要因

一つ目は、「記事を執筆して出すまでのリードタイムが長くなるとモチベが低下する」という点。

以下の記事に以下の記載があった。

私が記事を書くときはネタの賞味期限を意識しています。 これは読み手が考える賞味期限ではなく、書き手である執筆者のブログを書くモチベーションが切れる賞味期限です。 例えばプロジェクトをネタにしようとしたときに、リリースして半年以上経ってしまうとそのプロジェクトの内容や苦労した点などブログに書いた方が面白そうなところを結構忘れてしまいます。結果としてブログを書くモチベーションも下がりお蔵入りとなることもあります。 tech.yappli.io

これは非常に共感できるところがあって、自分の感覚では「記事を書き始めてから出すまでの賞味期限は3日」だと感じる。 仕事が忙しかったり、プライベートの予定が詰まっていたりすると、どうしても「来週は暇だから来週書こう」と思ってしまうが、一週間後には記事を書こうと思った当時の気持ちは忘れてしまっていて、どうでもよくなってしまっていることが多い。


二つ目は、「読む側の気持ちを意識しすぎてしまう」という点。

技術系の記事を書く時には、読みやすいように前提知識を丁寧に書いたり、読み手が得られる知見をわかりやすくしたりすることを意識していたが、最近は「書き手のモチベーションという観点では読み手を意識しすぎるのもよくない」と考えるようになってきている。 技術系の記事を書く時のモチベーションとして、「新たな知識を得たのでそれをアウトプットすることで整理したい」「同じような立場の人が同じ問題に陥らないようにしたい」というモチベーションで書くことが多いが、「出来るだけ多くの人が」「前提知識含めて技術を理解できるように」記事を書いてしまうと、本来書き手が書きたい本質から遠ざかってしまう。

自分が書きたいことにフォーカスした記事を執筆するためには、知識レベルは自分と同じくらいであることを前提にする必要がある。多くの人に見てもらえなくなる可能性はあるものの、それでも刺さる人には刺さるし、記事もコンパクトになるので執筆しやすい。

記事執筆のモチベを維持するために

最近は以下のことを意識して記事を執筆している。

  • 勢いに任せて数日で公開まで行う
  • 自分のために記事を書く
    • QiitaやZenn等の、ほかの人の役に立つためのプラットフォームは利用しない

この記事も、書き始めてから1時間掛からないくらいで公開まで行っている。このくらい軽い気持ちで記事を出せるのであれば、続けられそうな実感がある。 また、「他の人の役に立つ」事を諦めて「自分のために書く」ということを意識すると、文章の推敲や説明の付け足しが不要になるので、「自分が書きたいこと」だけに集中できる。はてなブログに書いていることもこれが理由で、QiitaやZenn等に記事を出そうとすると、「自分のために書く」のがやりづらくなる。

記事の質としては落ちてしまうかもしれないが、はてなブログに書いておいた断片的な情報を整理しなおして「他の人の役に立つ」記事に再編成することも可能なので、「他の人の役に立ちたい」というモチベーションが湧いてきたときにそれ用の記事を書けばよさそうだ。

僕はエンジニア5年目だが、「それ公式ドキュメントに書いてあるやん」「もう既に誰か書いてるでしょ」という感覚もあって、記事を書くモチベーションが下がることがある。 脱初心者したくらいのエンジニアは、似たような悩みを抱えている気がするので、「自分のために記事を書く」というのをお勧めしたい。