OSS コードリーディングでわかったこと

概要:

Githubに上がっているOSSやライブラリなんかのコードをできるだけ読むようにしてわかったことや得られたもののログ。

発端:

多分具体的な行動に移るきっかけになったのはRails Developers Meetup 2017から。 そこで紹介されたブログのコミットログを読むようになった。

y-yagi.hatenablog.com

あとKyoto.rbのSlackに参加しているのだけどそこにRailsのコミットログを流す rails_commit というチャンネルがあってそこにjoinした影響も少なからずあるかも。

結論:

具体的にいくつかのメリットがあったと感じている。

1. コミットの粒度とコミットログの良い書き方
2. コードのベストプラクティスな書き方
3. 英語を読もう/書こうという気持ち

ちょうどRailsチュートリアルを始めた影響やチェリー本を読んだ経緯などもあって「やってみるか」という軽い気持ちで始めたがそこそこ続いている。 軽い気持ちで始めた割にはそこそこいい感じだなと思っている、具体的な効果に関してはまだまだ出ていないというのが結論。

ただコミットログを見るのは文字を覚えるためのドリルのようなものだと思っているので焦らず今後も続けていこうかなと思っている。 なにより綺麗なコードを日々見続けるので汚いコードを読んで頭を悩ませる…みたいな無駄な時間を減らせるんじゃないかと考えている。

コミットの粒度とコミットログの良い書き方

ぼくが日頃読むようにしているコードは多くがrubyやrails、そしてvue。あるいはGolangだ。 だからなのか、非常に細かいコミットの粒度のPRを目にする。 多くのPRのコミット数が1〜5くらいで変更されたファイルに関してはほぼスクロールしなくてもいいくらいのコード量。

Railsなどのような利用者が多いOSSにおいて粒度の大きなPRというのは害悪だと思うので非常に納得がある。 鑑みるに自分のコードのPRはまだまだ巨大だなと感じており、改善すべき点だと改めて認識した。

ところで、どのPRだったのか覚えていないのだけどrubyかrailsのPRにとあるメソッドの返す値を変えたPRがあった。 そのコミットログに変更前と変更後の期待値が書いてあり、レビュアーにとって非常に助かるコミットログで真似していきたいなという学びがあった。 いままで他人の書いたコミットログで感心したことがあまりなかったのだけどこの件では大いに感心した。

これは業務で行うコミットの場合多くがコンテクストが取れている前提であるためだと思う。 OSSのような多種多様なバックボーンがある場合コミットログにbefore/afterな期待値が書かれているほうがレビュアーの普段が少ないということだろうと思う。 ただこの工夫は業務でも活かせるものだと思うので今後リファクタリングなどで期待値を変える場合に真似していく。

コードのベストプラクティスな書き方

読んでいるコードの多くがいままで携わってきたPHPではなくRuby/Rails、Vue、golangだからだと思うのだが その言語におけるベストプラクティスなコードの書き方というのが少しずつ自分の中に浸透している気がしている。 慣れない言語を書いていて「Aとも書けるがBとも書ける、どちらのほうが良い書き方なのか？」というのが気になることがある。

慣れ親しんだ言語であるとある程度経験則だったり、他のエンジニアのひとが書いたブログを読んでいて知識として知っているパターンが多い。 仕事などのプロダクトのコードの場合は既存のコードがどうなっているのか？を調べることである程度傾向がつかめることがある。

ところが学習時にそれらのコードをどう書けばいいのか？というのはなかなか判断しにくいものがある。 特にRubyやRailsはそのあたりの書き方がよくわからないケースが多い。

そんなときにGithubにガンガンコミットしているような第一線級のエンジニアが書いているコードというのは非常に有効な参考になるなと思った。 実際にはまだコードを読んでいたことで書き方の指標が出来たとは思っていないのだがジャブのように後々効いてくるんじゃないかなと最近感じている。 あと綺麗なコード、一読するだけで何をしているコードかわかるというのが具体的にどういうことか？という点においても非常に有用だなと思う。

英語を読もう/書こうという気持ち

当たり前だがOSSの多くは英語でissueやPRが書かれている。 タイトルをみても何書いてるかわからない、コメントをみてもわからない…だとかなりつらい。

その点Githubはよく出来ているなと思うのだがやりたいことがissueにかかれており、その解決策としてのコードと一緒にPRが出されているのでなんとなく「こういうことがしたいのかな？」と思ったときに英語の読解に自信がなくてもコードを見たときにやりたいことが伝われば英語の読解に対する補強になると最近感じるようになった。

特に生きている英語を使ってやり取りがされているので教科書でよくみかける「私はジョンです、彼女はミカです」といった お前はそれを日常会話でいうことが現実的にあり得るのか？みたいな英語じゃないし、 issueのdescriptionは仕方がないがタイトルやコメントは比較的短い英語であるので苦手意識を少しずつ減らしていけそうだなと思っている。

まとめ:

先日会社でも「最近GithubのOSSなコードを読むようにしていて、なかなかいいぞ！」といった主旨の発言をしたのだが せっかくなので文章ログとしても残しておこうと思った。

以前からOSSに貢献しようぜ！という話しは各所で聞いていたのだけどまずはコードを読むところから入っていくのでもいいんじゃないかなと思う。 結果、そこでなにか問題があればissueなりPRなりを出していけばいいしなにより美しいコードを読むのは勉強になるがそれ以上にワクワクするものがある。

まずは趣味としてのコードリーディングから入るのも悪くないんじゃないかなとおじさんは思いましたまる

〄！〄！〄！

タイトルは幼女戦記のLos!Los!Los!のパクり。

TVアニメ「 幼女戦記 」エンディングテーマ「 Los! Los! Los! 」

まとめ:

2017/05 にジョインした株式会社シーズ を 2018/04/30で〄ます、最終出社日は4/13。

www.seeds-std.co.jp

2018/05/01 からは株式会社トマルバでサーバーサイドエンジニア(アプリケーションエンジニア)として働くことになります。

www.tomaruba.me

いままではPHPエンジニアでしたが今後はRailsエンジニアになります、ヨチヨチRubistとしてよろしくどうぞ。

会社自体がスタートアップなのでサーバーサイドメインで開発することになると思いますが 多分フロントエンドやスマートフォンアプリなんかのコードもある程度読んだり書いたりすることになりそう。

他にもDockerメンテナンスしたりCI回せるように環境整えたりとか…横断的なことができそう、そういうところにワクワクしている。

〄理由:

〄理由書いても誰も幸せにならないの割愛。

詳細を聞きたいかたはぼくを飲みに誘ってください。 お酒は飲めないですが代わりにご飯をめちゃ食べます、よろしこ。

転職した理由:

いろいろ理由はあるんだけど大きく分けると↓な感じ。 他にもいろいろあるけど書く量がすごいことになりそうなので箇条書きでサラッと。

• 成長できそうな環境
• 働き方を自分たちで作っていける
• 自社サービス(受託開発はぼくには致命的に向いてなかった)
• シェアリングエコノミーなサービスに対して興味があった
• リモートワークできる

これから

周りのメンバーがみんな優秀なのでド底辺からやっていくぞ！という気持ちでいる。 元々転職前に副業で働いていて自分がまだまだ技術的に不足しているという状況なので成長が実感できて楽しい。

一方で「基本はオフィスで仕事すべきだと考えているが、特定の曜日に週1でリモートワークがしたい」というぼくの要望を採用してくれたりと環境面でも自分たちがよいと思える方向性に変えていくのを許してくれる空気があり、非常に心地よい。

とにかくスタートアップらしく、ガンガン変えてガンガンPDCA回していくぞ！という環境が自分にとって良い環境だと思っていてその辺が魅力的だと感じている。 まだまだこれからいろいろと変わっていく途上だと思うのでまずは期待されているバリューに見合う働きをしていく。

最後に

実は昨年末 #しがないラジオ にゲスト出演した際に転職するかどうか迷っていたという経緯があったりなんかした。

現職に対する不満だとかはまーやっぱりあるんだけどそれを辞める人間がどうこういっても仕方ないなって気持ちのときにカイゼンジャーニーを読んでいろいろ考えたけども結局ぼくは転職するという選択肢を取った。

新しくジョインする会社のメンバーでぼくと同じくらいのプログラミング歴(だいたい10年くらい)で大学生(今年新卒で別の会社にジョインする)がゴリゴリコード書いて、 ガンガンcommitしているのを目の当たりにして「こりゃうかうかしてられんぞ！」みたいなヒリヒリとした緊張感とモチベーションがあって次の職場に対する期待値が非常に高まっている。

ぼくたちはこういう新世代と今後闘わねばならぬのだ！と思い、恐ろしい反面頼もしいと感じていてすごく刺激的な職場だと感じている。

相対的に若いメンバーが多いので、期待の若手にまずは追いつくのが当面の目標。 しばらくして開発が落ち着いたらチームビルディングとかコーチングあたりに噛ませてもらいたいなーと思ってるけどまだまだ先の話かな。

現職の在籍は4月末までだけど最終出社が4/13なのでそれ以降は週休7日(仮)になるので温泉旅行とかリフレッシュ期間に当てたいなと思ってる。 というわけで今後も京都でやっていくぞ！という感じで頑張ります。

おまけ:

今期アニメはヴァイオレットエヴァーガーデンが最高だな！って感じ。 からかい上手の高木さんで癒され、ダーリンインザフランキスで02の可愛さとかっこよさに骨抜きにされている。

3月後半にスパロボX、戦場のヴァルキュリア4を購入予定で大変(ゲームで)忙しいことが予想されるなか天地無用!GXPの新刊が出たりするので時間が足りない。

【PS4】スーパーロボット大戦X プレミアムアニメソング&サウンドエディション【早期購入特典】スーパーロボット大戦X「早期購入4大特典」プロダクトコード (封入)

戦場のヴァルキュリア4 10thアニバーサリー メモリアルパック 【限定版同梱物】1.追加ストーリーDLC「第7小隊との共同戦線」プロダクトコード 2.10thアニバーサリーサウンドトラック 3.10thアニバーサリーイラストブック & 【初回特典】追加ミッションDLC「先行特別作戦」プロダクトコード 同梱 - PS4

真・天地無用!魎皇鬼外伝 天地無用!GXP16 簾座編 (ファンタジア文庫)

誰か精神と時の部屋用意してくれ〜。

カイゼンジャーニー たった1人からはじめて、「越境」するチームをつくるまで

昨日から読んでるがめっちゃいい話しなのでいまのうちに書いておく。 感想はまた後日。

この本は「いまの会社やめようかな…」と考えている人や「うまくチームが回ってないな」と感じている人向け。 どこかで聞いたことがあるようなどう改善していくのか、またその仕組みを取り入れる目的や目指す地点が丁寧に書かれている。

ストーリー仕立てで進行するため「あるある〜」という感じでスラスラ読めていく。 いまのチームや会社で働いている人に対してはないが組織やマネジメントなどで不満があるという人には是非一読してほしい。

そこから何を感じるか、どう動くかは個々人毎に違うだろうけども、その際の1つのガイドブックとしてカイゼンジャーニーはよい手助けをしてくれるだろう。 なお、↑ではアフィリエイトリンクを貼っているが現在出版元の翔泳社では電子書籍半額セールを行っている。

www.shoeisha.co.jp

期限が2/21までということなのでぼくの中では異例であるが読んでいる最中に書籍紹介をさせてもらった。 どうせならぼくのアフィリエイトリンクから購入してほしいがちょっと興味ある程度の本だからなーと躊躇しているかたは翔泳社さんの半額セールを利用するといいんじゃないかな！ っていうか発売日に半額セール対象になるってどういうことだよ！！！

…失礼、電子書籍版を定価で買った負け犬の遠吠えでした。

ということを昨晩Twitterに #しがないラジオ のハッシュタグつきで連投してしまったのでブログに書いてます、はい。

カイゼンジャーニー、まだ冒頭しか読んでないんだけどめちゃくちゃいい本なんだが。
これ #しがないラジオ とか聞いてる人向けな気がすごいする。

— るっか和尚 (@lucca0show) 2018年2月15日

とりあえずパーソナリティーのガミさんは買ってくれたらしいので、「よっしゃ！」という感じです。 きっと読み終わったらpodcast内で紹介してくれるやろー！とか雑な感想です。

RubyKaigi 2018のSuper Early Birdに申し込んだ

rubykaigi.org

多分日本で一番有名なカンファレンスなんじゃないかと思うが初RubyKaigiのSuper Early Bird枠が買えそうだったので思い切って買ってみた……ところ買えてしまった。 ということでよちよちRubistsだけど参加することになった、あったことある人やTwitterとかで知ってまっせ！というひと気軽に声かけてくだされ〜(知り合いがほぼいないので)

1月のやっていきログ

先月は中盤くらいまでいいペースだったけど後半に体調不良で一気にペースダウンしてしまった。優先順位の設定とかやろうかな…。

昨年末、やっていくぞ！という思いを新たにしたところ、さっそくフラグを回収してしまいました。 どうしてこうなった…。

やったこと:

• [x] プロを目指す人のためのRuby入門を読了
• [x] 知識ゼロからの小さな会社の始め方を読了
• [x] プログラマのためのDocker教科書 インフラの基礎知識＆コードによる環境構築の自動化を読了

やり残していること:

• [ ] テスト駆動開発を読了
• [ ] Railsチュートリアルの写経を完遂
  • 元々はWebページみながらやってたが面倒くなって電子書籍版を購入してKindleに突っ込んだ、PDFだと日本語になるのだがKindle形式に変換すると英語になってしまった。完全に謎。
  • Cloud9がAWSになっていて面倒くさい
• [ ] Go言語でチャットアプリ開発する

できなかった原因:

1月中旬くらいまでは遅れ気味だがそこそこのペース配分でいろいろ進められていたと思っている。 問題はそれ以降から月末まで体調を崩し気味だったこと。

早く治そうと早めに寝たりしていたのだが一向に回復しなかったせいでインプットに当てる時間やアウトプットに当てる時間がほぼなくなってしまった。 それどころか完全に体調を崩して熱がでて何日も寝込んでしまった。

これによって大幅に計画が狂った。

リカバリー:

とりあえずまずはRailsチュートリアルを最優先でやっている。 これは1月中旬まではインプットが順調だったため、2月は多少インプットを減らしても挽回できそうだなと思っているから。 なのでやり残していることを「Railsチュートリアル写経」→「Go言語でチャットアプリ作る」→「テスト駆動開発読む&写経」で考えている。

テスト駆動開発はRubyでやっていきたいと思っているがGo言語でもいいかもしれない。

最後に

ゼノブレイド2が全然終わってくれなくて非常に時間的制約が厳しい。

合議制の話しからプロジェクトマネージャーとプロダクトマネージャーの違いに思いを馳せてた

合議制は駄目なシステムか？

medium.com

製品開発の目的は社内の人を満足させることではない

とあってここ最近似たようなことを考える機会があったのでかなり得心がいった。 合議制はある種リスクの分散を目的としてる節があるとぼくは感じていて、 その結果リスクを分散する代わりにあなたの意見も取り込みますよというスタンスにみえる。

結果、合議制で出来上がったものはどこかでみたことのあるようなもの、あるいは劣化版ということになりがちだ。

少なくともスタートアップやベンチャーのような企業やチームであれば合議制で同意をとっていくのは悪手だと思う。 そんなコンセンサスをとってどこにでもあるなにかを作るくらいなら「これしか出来ないがこれだけはどこの製品よりも尖ってる」製品を作るほうが生産的であると感じる。

傲慢であればよい？

じゃあ意見を聞かない傲慢なマネージャーになればいいのか？というとそれは極端すぎる例だと思っていて、 1人が持ち得る視野の広さは有限であり、またバイアスがかかっている。 それはバイアスに関しては属人性が高いので良い面もあり悪い面もあるという感じだが視野の広さという点では個人が持ち得る視点はどうやっても限界がある。

全てを見通す神の眼でも持ってるなら別だが、人類にはレベルキャップ解放されていないので神の眼は装備できない。 つまり、人海戦術でマネージャーにとっての考慮外を潰すのがベターとなる。

大企業などであれば凡庸な製品を作っても問題ない部分が存在する。 大多数の人間を満足させ得るプロダクトを作るとなると合議制で決まったような平凡だが堅実な製品が好まれることもあるだろう。 ただそれはブルーオーシャンだから許されるとも思っている。 レッドオーシャンになったときに同じことをしていても他社だって同じようなものを作るだろうからそことの差別化を図らないと遠からず追い抜かれて、時代遅れの産物になってしまう。

おうさまとさいしょう、あるいはしょうぐんのはなし

閑話休題。 そうして考えていたときにふと「プロダクトマネージャーは製品の絶対的な決定権を持っている役割でその分多くのリスクも抱えた存在なのではないか？」と思い至った。 いままでプロジェクトマネージャーとプロダクトマネージャーの具体的な違いがいまいちピンとこなかったのだが以下のような理解をしたところ少しだけ靄が晴れたように感じた。 全体としてはまだまだ理解が甘いと思っているが少しだけ理解できた気分になっている、今は少なくともこれでいいのかなと思う。

つまりプロダクトマネージャーとは王様なのだ、そしてプロジェクトマネージャーは宰相や将軍という役割なのだ。

王様が「ここ最近税収さがってるから農業改革するぞ！」と号令をかける ↓ 宰相や将軍がそれを受けて「税収下がってるのは川が氾濫しているから。じゃあ農業改革して税収増やすには治水工事だ！」と道筋立てていく。 ↓ それを元に官僚たちが詳細を詰めていく

こんな感じの理解であってるのかわからないがそうすると確かに2つの役割は明確に違うし、同じにしてはいけないということがわかる。

プロダクトマネージャーはプロダクトの成否まで含む全てのリスクを負い、何故それが必要なのかを示しつつ、進むべき目標を定める。 プロジェクトマネージャーはそのプロジェクトが円滑に回るためのリスクを負い、そのために必要なものを揃えていく

こう考えたところ、自分のなかで妙にしっくりときた。

まとめ

両方とも略称がPMだったり、いままでプロダクトマネージャーとプロジェクトマネージャーが(少なくとも明示された)仕事をしたことがなかったのでいまいち理解できていないなと思っていたが少し理解が進んだように思う。

大きなリスクを負うからこそ彼ら、彼女らは大きな報酬を得ているわけなんだけども、たまーにそのリスクを背負わず(背負えず？)にその席についている人がいると不信任決議案を出したくなるという気持ちにもなり「マネジメントとか人の評価って本当に難しいなー」という雑な締めくくりで終えたいと思う。 ここから先は藪蛇というか生半可な知識で足を踏み入れるとものすごい数のマサカリが飛んできそうだなーと思うので自粛しておく。

しがないラジオ sp 14の補完・補足

紹介:

sp.14a【ゲスト: lucca0show】楽しいコミットメントの始め方

shiganai.org

sp.14b【ゲスト: lucca0show】楽しい積ん読カンバン術

shiganai.org

ゲスト出演しました！ …がいくつか話していて説明不足であったり、うまく説明できていないなと感じることがあったので補足話を書いておこうと思います。

好きなことを仕事に！だけでは難しい:

よく「好きなことで食べていく！」とかキャッチフレーズみますよね？ ぼくは割りと好きなことを仕事で生活できていると思っているんですがゲーム業界で働いていたときに「ゲームが好きってだけだとこの業界で働き続けるのは難しいなー」と実感したということが伝えたかった主題です。

実際にゲーム業界で働く前は「好きのレベルが低いんじゃない？」という疑念が頭の片隅にあったのですが業界で働く内にその幻想は木っ端微塵に砕け散りました。 主に悪い方向で。

podcast内で補足してもらえましたが好きにもいろんな形があって、ゲームを作るのが好きなのか、作ったゲームを遊んでもらうのが好きなのか、ゲームをプレイするのが好きなのか…それぞれいろんな形の「好き」があります。 アニメや漫画、ゲームなどのエンターテイメント系はこれらの境目が曖昧なことが問題の1つだとぼくは考えていて、 そのときに「好き」だけではなく「楽しめる」という軸がないとうまくいかないのだと実体験から結論を出しました。

なんというかこの2つはどちらが上とかではなく車輪の両輪のようなものだと思っているというのが正直なところです。 「好き」という原動力が「楽しむ」というエンジンで加速エネルギーを得ていく…とでもいうのでしょうか？ どちらかだけでは疲弊してしまい、人によっては好きが反転してしまうこともある…ということを伝えたかったのです。 説明ベタで申し訳ない。

Write Code EveryDayを4ヶ月してみた:

podcast中で語ろうと思ったままついつい忘れてしまったのですが実はぼくはいま現在毎日コードを書いているわけではないです。 というのも自分の課題として基礎的な技術力が不足しているという思いがあります。 その基礎的な技術力を向上させるためにはまず質の良いインプットが重要だと考えました。 ところが毎日ある程度とはいえコードを書いているとなかなかまとまった質の良いインプットを行うのが困難であるということに気づきました。

そこで意図的にインプットの質と量を担保するためにそれまで継続して書いていたコードを毎日書くのではなく、書けるときにだけ書くという方針に変更しました。 これはGithubの草を生やすことが主題になってしまっているように感じていたことも1つの理由です。 「イシューからはじめよ」でいうところの「犬の道」に自分が陥っていると感じたからです。 これはpodcast内でブログをただ書くだけでは難しい…といった発言にも共通している思いです。

結果はまだまだついてきていませんが、目的の部分がブレているとはまだ思っていないのでそのうちまた毎日コードを書く日々に戻ってくると思っています。 いまは充電期間のようなものだと考えて、しっかりと質の高い、あるいは高くなるようにインプットに専念したりしています。

ブログ執筆の話し、書いてるだけではうまくならない問題が難しすぎる:

この問題は多分ぼくにとってある種の転換点を迎えたからこそ発生しているのだと思っています。 昨年、期せずしてElastic Leadershipという書籍を紹介したところ変な形でバズることとなってしまいました。 そのときに「伝えたいことがしっかり伝わらない」という思いをしました。

ここが転換点だったのだろうと思います。 その瞬間からぼくは「ぼくだけのブログ」から「読者に伝えたいブログ」に変化していったのだと思います。 いわゆるコンテキストを共有している人からは好意的なコメントをいただきました。 一方、コンテキストが共有できていないと感じる方からは「コミットメント言語は日本人の文化にあわない、圧迫されてしまう」というコメントを沢山いただきました。

コミットメント言語は手段であって、目的ではないのですがそこがしっかりと伝えきれなかったなと今にしては思います。 バズっていたときは「それはチームの問題でコミットメント言語自体の問題ではない」と思っていたのですが コミットメント言語を手段として用いるその目的や目標をたしかに明確にしていなかったなと最近は考えることがあります。

先程もちらっと書きましたがそのことに気づいたとき「ぼくのブログを書くのはただ「犬の道」になってやしないだろうか？」という思いが頭をよぎりました。 そういう思いや考えから件の発言元である「ただ書くだけで上達するわけではないので難しい」という主旨にたどり着きます。

自分のスキルに不安があるので転職迷う問題:

概ね自分の考えはpodcastで語った通りなのですが一点だけうまく伝えられなかったと聞き直していた際に感じたことがあったので補足しておきます。 ぼくがpodcast内で「フリーランスを意識するほうがよい」という主旨の言葉を使っていますがこれは実際には正しくなく「自分の価値を常に意識する、そのための方法として転職やフリーランスを常日頃から意識すると良い」というのがぼくが考えていた思いに一番近い回答となります。

フリーランスになることそのものが重要なのではなく、「自分の価値を自分で見極め、知る」ことが肝要ということが伝えたかった全てです。 podcast内でも語っていますがぼくは自分の副業先の給与を時給換算でいただいています。 そして副業をしているときにふと自分の価値を客観視し、「ぼくの技術力はたったこれだけの価値しかないのだろうか？」と感じる結果となりました。

実際問題、副業先のスタートアップはそこまでお給与を支払えるわけではなく(フリーランスの人のほうがコミットメント率が高く重要だったとかの理由はある)ボク自身も契約当初はどれくらいコミットできるかわからなかったこともあり、納得の上で給与を決めたのですがそこには「これだけ高い給与もらって結果が出せなかったら怖いので低く見積もろう」という心理がありました。

結果から言うとそれは大きな間違いでぼくは自分の価値をもっと真剣に査定すべきだったのだと思います。 いまだにぼくは自分の価値の適正値がわからないです、ですがそれは自分の価値と向き合わないということと等価ではないとも思っています。

ぼくらは自身が持つ自由な時間を労働して成果を出すことで会社から給与をもらっています。 もちろん諸々の経費などは差し引かれているでしょうが、そこにはそれだけの価値があると会社に認められているわけです。 自分の価値を低く見積もるというのは自分自身を卑下して貶めているようなものだと最近は考えるようになりました。 その行いは自分と、自分の価値を認めてくれるひとたちに対して不義理で、あまりに失礼な行為ではないかとも思っています。

とはいえ、スキルがないと自分の価値を認めにくいのも真理です。 だからこそフリーランスや転職のように他人から見た評価を参考にするのが良いとぼくは思っているのです。 いまの自分のスキルセットはどのくらいの市場価値なのか？を意識することは十分価値があるし、またもし転職することになった際にも話のネタになります。 転職するしないは関係なく、自分の給与が実力に対して適切に評価されていない場合1つの提示する資料にもなります。

転職サービス側からすると迷惑千万な行為だと思いますが、市場価値を知るために転職サービスに登録しておくのは割りとコストパフォーマンスのよい施策でないかなと思っています。

出演してどうだった？

概ねいいたいことは言えたかなと感じています。 ビブリオバトルについては語れなかったので次回出演するか、自分のpodcastでやろうと思ってます 反省すべき点は多々あるのですがパーソナリティのお二方に助けていただいて非常によい体験をすることが出来たと思っています。

どうしても対話というベースや技術系の話しではないため、議論的というか話しが盛り上がってしまい時間が長くなってしまったのがpodcastというものの難しさを改めて実感しました。

どうしても1人だとうまく掘り下げられない内容もパーソナリティーの方がいるといい感じにまとめてくれたり、思わぬ方向からの意見をいただいて改めて考えるきっかけになるなと感じました。

ぼくはネット弁慶の割に打たれ弱いので基本的にあまりエゴサをしないようにしているのですがついつい誘惑に負けてしまいTwitter上で検索してしまいました。 いろんな意見やぼくの意見の補足、共感、反論諸々読んでいて自分の発した一言が与える影響がこんなにあるのかと新鮮な驚きを得ています。 そして改めて自分のためのpodcastをやっていこうと思いを新たにしました。

いつになるかはわからないけども自分の中でこのくらいの時期に行いたいなという獏っとした思いがあるのでリリースしたらTwitterやブログで報告させてもらおうと思います。 あと、今回ヘッドフォンから自分の声が聞こえてきたり、思った以上に早口だったのでしがないラジオにリベンジしたいですね！