個人開発をテーマに、社内でLT会をやったら、やっぱり楽しかった話
個人開発をテーマに社内でLT会を主催したら楽しかったし勉強にもなった。
これがそのときのスライド。個人開発している三文小説というサービスについて話した。
登壇者は６人で、発表７分・質疑応答３分で、1900からざっくり一時間くらいのイベントだった。50人くらい参加してくれた。社全体で約250人くらいのはずなので、5人に1人参加してくれた計算になる。トークテーマは自分を除いて、いわゆるクソアプリ、個人開発歴史振り返り、LineBot、IoT、月間何十万アクセスの個人開発というラインナップ。
プライベートでもLT会を何度か主催したことがあるのだけれど、やっぱりLT会は面白い。何が面白いのかというと、やはりどうやっても発表者の個性が出てしまうことにある。発表しないかと誘ってみると、「いやー面白いか自信がなくて」と答える人が多いのだけれど、僕の経験上、面白くなかったことはない。もちろん、発表する内容や話術や構成それ自体に見劣りする部分はあるかもしれないが、観客はその発表だけではなく、発表とその人自体を含めて受け止めることになる。だから内容に多少キズがあったとしても、総体的には面白くなる。
たとえばサービスそれ自体の技術的レベルは低くて、UIもそれほどリッチではなく、ユーザーもついていない場合でも、そのサービスを作ろうと思った経緯から発表者が普段どこに注意をどのように払っているかが垣間見れる。また、そのペインを解決してどのようなベネフィットをもたらそうと考えているかを聞けば、その人の想像力とかがわかる。なるほどそういう観点はなかった、そこを解決しようとすら思わなかった、という感想が持てる。そして何より発表者が少しだけ身近に感じることができる、というメリットがある。僕はこれがめちゃ大事だと思う。リモートワークのなかで、その人となりを知る接点になるだろうし。
とはいえ今回の発表者してくださった方々はみんな技術的なレベルが高くて、個人開発のモチベーションがもりもりと出てきた。特に弊社GM（グループマネージャー、要するに開発部門のトップ）の細川さんの発表には感化された。月間何十万アクセスあるサービスを複数作ってる！SUPER STUDIOに入ろうと思ったきっかけの何割かは、彼とのカジュアル面談で紹介された個人開発にすげーっと思ったからだ。懐かしい。今回のLTではそのうちの一つを深く紹介してくれたので、また企画して他の個人開発の紹介も聞きたい。企画からリリースの要点とかのテーマでも聞いてみたい。
LT会ではないけれど有志でエンジニアによるセミナーが不定期に開催されている。めっちゃGiveでめっちゃいいなーといつも思ってたので、僕も何かやろうかしら、と思うきっかけになった。それらは基本的にエンジニア対象でエンジニアにのみ周知されていた。しかし今回は個人開発だったので、技術的な話も出るだろうが、別部署の人も面白いと思えるだろうと思って、全体のチャンネルで周知した。正確には計測していないけれど、他部署の方が5,6人くらいは来てくれたと思う。面白かったと感想が聞けたのでやってよかった。
反省としては、まず発表7分を管理するのに失敗したことだ。スマホのベルアプリの音を流そうとしたけれど、ヘッドホンがその音をうまく拾えなかった。その場の対策として7分経ったらお声がけをする方式にした。アナログ。終了時にアンケートURLを貼らなかったのも失敗した。翌日に周知したけれど参加者がホットなタイミングを逃してしまった。
個人的に、喋って欲しい人がたくさんいるので、またLT会をしたいなーと思う。あと別部署の人にも登壇してほしいなー。
（了）
早く寝るチャレンジweek
仕事のプレッシャーなのか３０歳を越えたせいなのか、朝７時前に目が覚める。覚めるだけで、活動できるレベルの覚醒ではないので、二度寝をする。だいたい９時前くらいになると活動できそうになるので、ようやっとベッドから体を起こすことができる。
便利といえば便利な身体機能なのだが、夜25時とかに寝ても自動的に７時に目が覚めるので、睡眠不足になっている。二度寝を合わせれば睡眠時間は８時間を超えるが、やはり質が悪いのを体感している。最近仕事に２３時とかまで取り組んでしまうことが続いていて、「一時的７時自動覚醒」のせいで日中のパフォーマンスが悪い。一日中体と精神と魂の深層がぼんやりとしていて気分が良くない。午前中にひと仕事終えるくらいが、気分的にはちょうどいいのでそれを目指したい。
ということで、早寝を実行したい。というわけで、今週は２３時に寝るのを目標にしたい。そのためには２２時３０分くらいには部屋の電気を消す必要がある。飲み会やらなんやらの夜の誘いも断る気概で臨む。そして仕事は21時までにはあがりたい。
（了）
HTML・CSS・JavaScript
フォームに新しい項目を追加するチケットを担当している。別のページで使用している箇所を別のページに移植させることで達成できるので、一見簡単に見えるが、どうもフロント周りが苦手だ。というか理解が不足していることがわかった。
たとえばHTML。Railsのビューヘルパーでなんとかやってきたので、ビューヘルパーを使ってないコードを読むときに、inputのname属性って何だっけ？どうやってコントローラーに送るんだっけ？みたいな基本的な疑問を抱いてしまった。進捗は当然悪くなる、、、
CSS、これは鬼門。なるべく避けてきた。わからん、、、。たぶんやればできそうだけど、こうコツがわからん。
JavaScript。最近いけるかも？と思いはじめてる。サービスの一部でJQueryで実装を使ってるのだけど、DOMを特定してメソッドでよしなにやる、という一連の流れが身についた気がする。
一歩一歩やるしかないのよな、と毎日思う。チームのみなさんが優しいので、なるべく早く報いたい。
（了）
褒められるとうれしい
チームの中でエンジニア歴が長い人に褒められてうれしかったので、せっかくなので記録しておく。
少し複雑なフォームから値を受け取ることができなくて詰まっていた。わかれば簡単な部類の悩みだった。しかし時間をかけてもわからないので、素直に聞いてみた。45分くらいコードを画面共有しながら見てもらい、結局うまくいった。自分で複雑にしているのが原因のようだった。フォームから値が送れてるかどうかは検証機能のネットワークタブで確認できることを教えてもらい、さらにノイズを消すやり方も教えてもらった。
こんな簡単なことですみません、進捗出せてなくて、、、と言うと、2年目でこれだけやってたらすごいっすよ、あとは経験ですよ、とあっけらかんに言ってくれた。文章にしてみればあっけないが、すごいっすよ、と言われると素直にうれしかった。仕事ぶりを見てくれてたんだ！という単純な驚きもある。
やっぱり言葉で伝えるのは大事だなーと身にしみた。褒め合うコミュニケーションはウェットでクールじゃない、なんて思う節もあるけれど、お互いを認めあって生産性を上げるのも違ったクールさがあるので、そっちを深めたい。前者は若い頃に実践してあまり効果はなかったように思えるし。その話はまた別のときに。
質問してよかった。ありがたい。
（了）
nilガード
book || = Book.first
上記のコードの || = が nilガードと呼ばれるイディオムだ。よく見るし、体で覚えてしまっているけれど、もう一度頭で理解しておく。
これは省略せずに書くと、こうなる。
book || book = Book.first
book変数にnil / false以外が格納されていれば、そこで式が評価されて、book変数の値を返す。もし、book変数がnil / falseの場合は、book = Book.firstが実行される。なので、こうしておけば、book変数がないときのデフォルト値を設定することができる。便利だ。変数がnil or falseならデフォルト値を右側で用意している、と考えれば良い。
（了）
My Brandを作ってみた
読んだ。就活する子供に向けたキャリアの考え方の本、とざっくりまとめることができる。実用的な考えが読みやすい文章で語られている。就活のときに読みたかった本。キャリア戦略なんてクソくらえ、サラリーパーソンなんて嫌だね、と考えているけど普通に就職するその他大勢のひとりだった。もう３１だけどいまから取り組んで変わるのだろうか。ということで、紹介されているキャリア設計の参考になるフレームワーク「My Brand」を作ってみた。自分をブランディングすることでいろいろメリットがあるみたい。これを判断基準、行動基準にすることで、選択に一貫性が出て、それが相手にも認知されることで仕事が進みやすい、とか。もちろん理想の要素を入れていい。
個人的には、キャリアの目的を定めることで、どんな仕事をしたらいいのかを逆算するという当たり前？の思考が新鮮だった。いきあたりばったりで面白そうな方向に進んできた人生だったので、新しい視点を持って生活できそう。適宜立ち返ってみたい。
人生の目的（仮）
面白い人生を歩みたい。
キャリアの目的
事業・サービスを作れるスキルと経験を積むこと
市場
エンジニア市場？
WHO
ST（Strategic Target）
- 同僚たち
CT（Core Target）
- 上司
- 上司の上司
WHAT
便益
- 徹底した顧客目線で開発仕切ることができる
RTB(Reason to beleive)
- 顧客目線での提案、泥臭く知識を集める、バグのない実装の実績
HOW
- 顧客に寄り添った開発ができるエンジニア
- 個のエンジニアとして平均点以上の技術力
- チームの改善点の洗い出しと効果的なネクストアクションの提案力
- 部門横断の交流を生んで組織の風通しをよくする行動力
- ブランド・キャラクター
- 粘り強い、自然体、冷静
（了）
いや、成長していることもある
成長してない箇所だけフォーカスするのはフェアじゃないと思ったので、仕事でvalueを発揮してるかも？とか上司や同僚にもらったポジティブなフィードバックを洗い出してみる。どんなときに、どんなふうに思ったり、評価されたのか。
- たくさんのコードを見たときに
- 思考停止しなくなった。なんとか読もう、と前向きな姿勢になっている。
- もうわかんないってなったときに
- チームで抱えるチケットの進捗が良くないときに
- チームの仕組みの改善点を探して、効果が出るかわからないが提案している。個人＜チームの成果を重視している、と思う。
- 出社したときやオンラインで雑談するときに
- 積極的に他部門や他チームのエンジニアとコミュニケーションを取るようにしている。これは現職の社員やエンジニアの人たちがいい人で技術力あって経歴おもしろくていい人が多いから。
- M1で環境構築したとき
- 手順書を作成した。新入社員の環境構築のお手伝いでちょこっと活躍できた。
- はてブロでトレンドに載ったとき
- 全体チャンネルで紹介された。（仕事のvalueとはまた違うか、、、）
- 開発するときに
- ローカルテストで仕様漏れを見つけたりしてQAの人に褒められた。
- スプリントレビューのときに
- 説明がわかりやすかったとPOに言われた。事前資料はなるべく作るようにしている。
- バックログリファインメントのときなどに
- 顧客目線の意見を言えた。確かに便利ですけど、こういうデメリットを感じるかもしれないから顧客のヒアリング必要っすね、みたいな。
- 開発した機能がデプロイされたとき
- 本番での障害はまだない。開発が遅れて延期にしたことはあるけど、、、
- キャンペーンの内容を全社定例でデモを自発的に勝手にした。（前職）
- 別部署のマネージャーに、とてもわかりやすかったと評価してもらえた。そのとき出た質問で他部門の方との認識をすり合わせることができた。
結構挙がったので、素直にうれしい。全くないかもと思っていたので。認知の歪みですね。もちろん主観的な列挙なので、普遍性はないですが。自分のために書いているので、あしからず、、、
人と人の情報連携や助け合いがいい感じに動いているのを見ると気持ちよくなるし、逆の場合だと仕組みで何とかならんものかと考える傾向があるっぽい。 チームの生産性があがると、メンバーとしてもがんばろうと自然に思えるので、そういう取り組みが好き。とはいえ個としての戦闘力を上げねば、、、と当たり前のように思うが、今回はいいことだけ書きたいので、深堀りせずここで終わる。
（了）
