bunty's blog

ググったこととか勉強したことのメモ

エンジニアとラッパー

エンジニアが OSS や自分のプロダクト作りなどでコードを書かずに、技術ブログや勉強会の登壇などだけで評価されるのはうんぬんかんぬんってツイートを見た。(正確な表現は忘れたしどのツイートだったのかもわからんから間違ってるかも)
仕事でめっちゃコード書いてるならそれを発信していくのは大事だよねって気持ちと、確かに何を持ってその人の能力を測るかというとコードが書けるかだよなという気持ちの両方を感じた。

普段日本語ラップを聞くことがあり、特にラップバトルが好きでよく YouTube でみたり Abema で見たりしてる。
ラップバトルってラップの初心者にもわかりやすく色々な人にリーチしやすい。バトルはその場の雰囲気や相手との相性、(ちょっと語弊があるが)短い時間で盛り上げられると人の目に留まりやすく、自分の知名度を上げるにはバトルに出るのが大事だったりもする。
反対に音源となるとそうもいかず、作るのも大変だし、ラッパーとしてのスキルや人柄、全てが詰まっているのにバトルほどバズることもない。 ラッパーという括りの中でやっていくなら、音源を出すことが重要っぽくて(知らんけど)、バトルの中でも「お前音源出してないじゃん」と言われてたりもする。

それぞれの仕事のなかで一番コアな部分が、エンジニアでいったらコードを書くこと(プロダクトを作ること)、ラッパーでいったらラップをすること (音源を作ること)だとした時に
そのコアな部分をやらずに、やりやすいものだけをやってて良いの?ってのは通じるものがあるし自分の中に刺さるものがあった。 ちなみにラッパーの世界は全く知らないので、とんちんかんなこと言ってるかもw

自分が知らない技術を学ぶことの大切さ

最近改めて感じたことがあったのでメモ。何が言いたいかというと、学んだ技術をそのまま使わなくても、背景にある考え方や設計から学ぶことが多いなあという話。

ちょうど仕事で文章解析ができないかという話すが出てきて、MeCab と fastText を使ってみたり色々と検証をしている。fastText をそのまま使うことはできないかなという印象なのだけど、単語をベクトル化する、数値として扱うという考え方自体は使用できそうだと感じる機会があった。

fastText を使ってなかったら、そのアイディアは出てこなかったし、今回 fastText を使わないにしても概念は他で使えることができた。

前に関数型言語を学んだときも同様だなと思っていて、仕事の中で関数型言語を書かないにしても、その考えを自分が書くコードに取り込むことはできる。

最近あまり新しい技術のキャッチアップができていないなと思っていて、そこにはたぶん自分がそれを使うにしてももっと先になるだろうなという気持ちがあるからだと思う。直接使うものを学ぶのではなく、その背景から学ぶ姿勢に変えることで、新しいものを触りつつ自分の学びも最大化できると良いなーと思った。

「広木さんに聞く! 開発者体験向上のためのエンジニア組織づくり最前線vol.6」に参加した

今週これに参加してきた。ちょうど開発者体験について考えることが多くなってきていて、具体的にやりたいことを会社でも話すことが増えてきていて自分的にはタイムリーな内容だったな。 findy.connpass.com

主にこの 3 つについて話がされていた。

・良い組織文化づくり
・生産性向上
・採用力強化

生産性と採用に関しては自分もよく開発者体験の話をする際に話題に出していたけど、確かに文化としても良いよなと感じた時間だった。(安心して開発できるなどは生産性向上の方に含めて考えてた)

特に新しいものに挑戦ができることや、嫌だなと思うもの不満に思うものに向き合って改善ができるという文化は、働く側としては生産性の高さよりも重要に感じる。

じゃあまず何からやろうかと思うだが、話の中でCTO 協会が監修している DX Criteriaというものが紹介されていた。(クライテリアは基準という意味らしい) あるべき姿やアンチパターンがたくさん記載されていて、まずは自分たちの現状を把握するという意味でこの診断を行ってみるのは良いのではと感じた。 dxcriteria.cto-a.org

実際 DX Criteria を使って改善した話は、ここにいくつも参考のブログが記載されている。

dxcriteria.cto-a.org

何を持ってして開発者体験が良くなったのか?を示すのは難しいよなぁと感じていたので、このように数字で出せるものがあると OKR など目標管理にも含めやすいので助かります! まずは DX Criteria を使って現状の可視化・数値化を行い、そこから優先度をつけて改善していくということをやっていきたい。

スマホは Brave、PC は Sidekick をメインのブラウザとして使い始めた

もともと全部 Chrome を使用していたが、最近は Brave と Sidekick をメインのブラウザとして使い始めて、もう Chrome には戻れないなという感想。

www.meetsidekick.com

brave.com

Sidekick のスマホ版のアプリがないので、Brave を使用しているが、広告が全てブロックされるのでそれだけでかなりよくなった。自分もブログに広告貼ってるけど、広告があるページなんて見たくないので、スマホChrome はとてもじゃないけど使えなくなってしまった。

Sidekick に関しては、Chrome の上位互換という感じの印象で、Chrome拡張機能は使えるし設定も Chrome から引き継げるので移行は簡単。デフォルトで広告を削除してくれるし、サイドバーによく使うアプリを登録しておけたり、セッションの切り替えができる。Chrome でもプロフィールの切り替えで似たようなことができるけど、拡張機能も含めて別物になってしまうので正直使いにくかった。 特に個人的におすすめなのは、Sidekick のトップページにある検索機能。ブックマークや履歴、使用しているアプリのコンテンツなども含めて検索をかけてくれる。(表現が合ってるかわからんが) あのドキュメント(もしくは記事)どこでみたんだっけみたいな時に一気に検索かけられるので、めちゃくちゃ便利。Notion のドキュメントだったり、自分の履歴などから検索をして候補を表示してくれるので、必要なページを見つける手間が省ける。

ブラウザなんて Chrome があれば十分でしょと思っていたけど、まさか他のものを使うようになるなんて自分としては意外だった。ツールも含めて盤石に見ててても変化があるよなと改めて認識した。

前提を変える大切さ

最近仕事が忙しくて、残業ありきでスケジューリングをしてる。シンプルに量が多いので残業が発生することはしょうがない面もあるのだが、残業しないと終わらないという前提のもと取り組んでいるのはあまり良くないのではと思った。

コーチングに関わり始めてから思うこととして、できると思ってやらないとできないというのがある。できると思えていない時点で、理想像の解像度が低かったりそこに近づくために何をするべきか、何が使えるのかがわかっていない。もちろん解像度を上げた結果、それはできないものであると判断することもあるが、ほとんどの場合はそこまでにいかない。よくわからないから自信が持てない、そこに意味を見いだせないというケースが多いように思う。

なんでこんなことを書こうかと思ったかというと、週末に NLP の本を再度読んだことがきっかけだった。本の中で紹介されていた事例に、毎日ホワイトボードにその日の退社予定時刻を書くことによって、残業せずにその時間に帰るようになったチームの話があった。その時間に帰る、つまりそれまでには仕事が終わっているという前提になったことで、良い変化が生まれたという話だった。

なるほどと思ったので、今自分の中にどんな暗黙の前提があるんだろうと考えてみると、タスク量が多すぎて残業をしないと終わらないということが思い付いた。 確かにタスク量は多いけど、時間を意識したらもっと集中してタスクを終わらせられる感じもするし、タスクの順番を変えることで他の人から早めにヒアリングをしたり FB をもらったりして、余計な作業はなくせるのではないかと思ってる。そもそもやらなくても良い仕事もあるとは思う。 あと、英語に関しても話せると思うのか話せないと思うのかでかなり違いが出てくるなと感じた。これも話せると思っていると、自分ができる表現で伝えようとしたり、言葉が出てこなくても焦らずに探すことができる。逆にできないと思っていると、何も思いつかなかったり、そもそも話そうと思わなかったりする。

自分1人で自分が当たり前だと思っていることに気がつくのは難しいので、ここで誰かと話す中で気が付けると良いんだよなと思う。 また外部でコーチングを受けようかなという気持ちになってきた。

モチベーション大百科読んで内発的動機付けの重要性を感じた

図書館にあったので、全部は読んでないけどさらっと読んでみた。「自主的な行動に対してごほうびを与えると、内発的動機づけが損なわれる。」という話を読んだときに、ブログが続かなくなった理由がこれだなと思った。

もともとは Qiita で技術ブログを継続して書いていたけど、徐々にそれが継続できなくなってきていた。

自分のために始めたもので、自分の学習効率をあげたり同じ問題につまらないようにすることがメインだったのに、途中からいいねが来ることを気にするようになっていた。Qiita の仕様が変更されたこともあり、あまりいいねが付きにくくなり、そこをモチベーションにすると続かなくなっていった。

そこからはてなブログで書くようになったけど、こっちはこっちで PV 数を気にしたりし始めて、自分のために書けなくなっていたなあと振り返って思う。「外発的動機 < 内発的動機」にしていく必要があって、もっと内発的動機の解像度をあげるなり意味づけをするか、外発的動機を消してしまうか。外発的であれ動機があること自体は良いと思うので、やっぱり解像度をあげると言うのが大事だな。

なんでブログ書こうと思ったのかを考えると、思考の整理と経験に再現性を持たせるためというのが思いついた。なんとなく考えていることを言語化するプロセスによって、思考が整理されるし言語化できると次似たようなことがあった時にも同じ結果を出しやすくなる。

技術ブログも同じで、同じようなエラーで自分が詰まったり他の人が詰まったりするから、このエラーが起きたらこうすれば良いよねということを残すことで、何度も問題を乗り越えられるようになる。どんな背景・考えで設計したのかを言語化できると、次に設計する時にも同じ観点で設計するべきなのか他の観点を取り入れるべきなのかがわかりやすくなる。ちょっとずつ解像度をあげていこう。

習慣を作るときはイレギュラーをなくす

先月のコーチングでブログについて話をした。継続したいけどできないというあるあるな内容。話した内容は省略するけど、毎日継続するためにどうしたら良いかを考えて、お昼休みに毎日 5 分でも良いからやることにした。

朝は起きれないし、夜は残業をした場合やお酒飲んだらやらなくなるので、一番確実に時間が取れるのが昼だなということで、昼の時間の一部をブログ継続のために使うことにした。

最初の方はうまくいっていたけど、MTG がお昼に急遽入ってしまったりして、休憩が細切れにしか取れなかったりした。こういうケースがあると、お昼に 1h 纏まった休憩が取れなくなって、30 分 30 分に分けて分けて取ったりしている。ただ 30 分しかないと、書くところまで行かないので、毎日ちゃんとまとめて 1h 休憩を取りたい。

そんなことを考えていたら、イレギュラーなケースをなくすことって新しい習慣を作ろうとするときには大事だなと思った。よくあるのが夜何かやる予定でも飲み会の予定が入ったとか、前日遅くまで起きてて、毎日朝やってたことができなかったとか。

もちろん飲み会であれば自分で管理できるが、仕事の MTG となるとある程度どうしようもない部分がある。そうなると、じゃあどうやってイレギュラーを取り除くかというよりも、イレギュラーなことが入らないであろう時間を見つけることが結構大事だなと。そう思うと朝なんだよね。そこまで早過ぎなくて良いから、8 時からで十分だ。そうすると 7 時半には起きたい。

イレギュラーなことがあってもやろうと思えるほど、解像度を上げることも大事なんだろうなと思いつつ、なんとしてでもやり切るってのは結構エネルギーが必要なので、無理せず続けられるようにしていきたい。