もう2月になってしまったが今年の抱負
コードを読み書きする習慣をつけたいね、ということでGitHubの草を生やし始めてみた
2024年の1ヶ月の実績は毎日書くことに成功!
2023年を振り返ってみると一見よくやったじゃんと見える
しかし、会社のSSOを外してみてみると...
なんということでしょう...
ということで表題通りですが、コードを書くようにしていこうと思っています
とはいえ、思っているだけだと途中で理由をつけて辞めそうなのでちゃんとやります.
まぁだとしても意外と書いていてきづいたりもっと書きたいじゃんとなったりすることが起こっていて個人的にはポジティブに捉えている
もう11ヶ月もやっていこう
最近はゼルダにハマりながらも子供とともに夜10時に寝ることの多いid:d-haru です。
チームのスクラムマスターとして独り立ちしてもうすぐ1ヶ月が経とうとしています。今回認定スクラムマスター研修を受講し、晴れて認定スクラムマスターになることができました。
正直に言うと、すでにある程度スクラム開発を経験していたのと、実際に研修を受講した方やスクラムに詳しい方とお話する機会も多く、ここでどのぐらい学びとれるかいささか不安もありましたが、思いの外気づきもありました。
スクラム開発そのものは本格的には今の会社に入社してから経験してスクラム歴半年と少しという状態でした。その前にもウォータフォール開発、アジャイル開発もどき?の経験はありました。
直近ではチームのスクラムマスターを引き継ぐ形となり、自分なりに役割や改善方法を模索している毎日です。
今回の研修は agilergo のJames Coplienさんが講師でした。
https://www.jp.agilergo.com/online-csm-coplien-202306www.jp.agilergo.com
オンラインの受講で、ワークなどはどうしてもやりづらさもありましたが話に集中してメモを取りつつ質問しながら参加するような形でした。
メモを振り返りつつ気になったところとかを振り返っていきます。
スクラムのルーツがそもそも製造業から、というのはなんとなくは聞いたことがありましたが、思いの外トヨタ生産方式の具体的な話（アンドンやカンバンなど）がでてきて驚きつつも懐かしんでいました。（かつて製造業で働いた）
正しいプロセスを作ることで正しいものができる
これも元々製造業由来の考えだと思います。自分はプロダクトの開発とソフトウェア開発は似て非なるものと思っているので製造業を単純に真似るだけではうまく行かないというのは身にしみて感じていたので、最初は懐疑的なところありました。
ただ、不確実性が高いからこそ絶対の正解はなく、正解を探すというアプローチであるという話があり、これは納得感がありました。
月曜にやることは、マネージャーを廃止することだ
ただの感想ですが、これめちゃくちゃ何回も言っていて面白かったです。マネージャー不要論について語るとそれだけとずっと書いていそうですが、スクラムにおいては不要であるというのはその通りだと思いました。
スプリントプランニングでは「なにを」「どのように」よりもなぜ?を考えるよう
これは最近リファインメントのタイミングでも、まずは「Why」が腑に落ちないと具体的な話をするのは危険だなぁと思っていました。
ある程度チームが成熟しているとプラニングの時点ではこれらを語ることはない、あっても少量のはずというのはそのとおりだなぁと。
ビジョンがあってそのためにはPBIができる
当たり前だけど改めて言われるとPBIに何が書かれているべきかという問題は結構陥っているし整理したいと思っていたので興味深い一言でした。
アジャイル開発宣言には、早いという言葉はない
これもハッとさせられる一言でした。トヨタの製造に対してのアプローチはプランニングに時間をとることである、という話もあり改めて各スクラムイベントの役割を再認識しました。
予測の大変さは、当初と条件が変わること
これは共感です、という気持ちがメモを見ると高ぶっていた。
開発している最中に前提条件が変わる ということもあるし、理解が進むことで必要なもの、あるいは不要なものが見えてくることも多いです。
ウォーターフォール開発は当初の条件から長期間の予測をする手法だが、最悪なのは見込みがずれるとわかったときに期間の修正ができなかったりやらなかったとき。
これは本当に地獄なんですよね。。。
開発者に期待するのはチームがベストを尽くすことだけ:
POに許可を求めるな、謝罪せよ
自分のことだけどこれめっちゃ求めがちだ、、、と思ったやつです。
ちょっと挑戦してみたら? というものに対しては許可を求める時間が無駄とのこと。つまり、もっと失敗すべきでそれを容認していくような信頼関係を構築しろということだろう。
これは自分よりも他のメンバーの方が丈夫なんじゃないかと感じているので、もっと背中を押したり、ゴールやプランにだけ引っ張られすぎないような視座が必要そうだと感じている。
優れたスクラムマスターは障害リストを持っている
似たようなものをは運用しているが、初期フェーズではないため少し様子が違う気がしている。
チームを巻き込むようにはしているが、その仕組みはまだまだ改善余地がある、という感じなのでここは引き続き考えていきたい
スプリントは50%は失敗する
わかりつつも成功できるような計画を組みがち、、、これも挑戦意欲が少し弱いということだろうか?
スクラムにおける挑戦がどういうものなのかまだわかっていないような気がするが、それこそ開発手法やアプローチを抜本的に変えるとなるとこういうことが起きるかも。
ユニットテスト不要論について
理屈としては、
ちょっと極端じゃないか?とは思ってはいるのでまぁ参考程度に止めようかと思っている。テストコードだけでは不十分というのはそう思う。
そしてDHHのTDDについての話も一緒に共有されていたが、システムテストに偏るのもやめてくれという話もあるのでここもベストを模索していく類のものだと理解している。
スクラムマスターの目標を立てるのが難しいなと感じています。効果的な考え方、具体例などあるでしょうか。なんとなくプロダクトオーナーに比べると社内での評価が軽視されている気がして、うまく評価されるような方法はあるでしょうか。
A: 過去、自分は評価に関しては捨てていた。会社の文化もあるので難しいところもあるが、チームとしての成果が上がれば一緒にあげられるかもしれない
まぁそう言うしかないよなぁという感想をもった。
スクラムマスターが外部からの攪乱や進捗の妨げになるものを取り除く上で、ある程度の権限（役職）が必要になるケースが多いと思っています。役職が低いうちからスクラムマスターのロールを実践していくうえで、何かコツのようなものはありますか。（往々にしてスクラムマスターを飛ばして上位役職者に相談したほうが早い）
先輩のスクラムマスターにきいてみると良いかもしれないが、役職が低いからSMができないということはない。多くの企業は管理職に話をするのは気が引けるものと思っているが、管理職は問題を知りたいと思っているはず。25年前の日本とは違っていると思っている。一方で話しづらいのもわかるがやるしかないと思う
個人的には役職がなくてもできると思っている。役職を言い訳にしているケースもあると思う。もちろん本当に話が通りにくい組織があるのも事実だとは思うが、意外と現場を変えていく人は役職関係なく変化をさせられると思っている。
バックログに何が書かれているべきか?
プロダクトオーナーの頭の中にあるものを言語化したもの。仕様というのはQ&Aで作っていくものである、PBIの中身は情報としては少ないが要件はビジネス側のもの、プロダクトの管理になる
PBIには仕様を書きがちだったが、本来は何をしたいかが書かれているべきなのはたしかにと思う。対話で仕様を決めていくというのもその通り。
見積もりについて、悲観的ベロシティが15, 楽観的ベロシティ20
これはいろんな話題があるが、まずはひとりでやらないことと見積もりは進むに連れて変化する可能性があることを認知してもらうよう努力すべき
バーンダウンチャートが最後の方に一気に下るようなスプリントが多い。無事にゴールを達成しているが、このままで良いか？それともPBIの細分化をすべきか?
そもそもバーンダウンを直線的にする必要はない。ただし、うまくやっていれば直線に近づけることはできる。PBIが代替同じサイズになることで、上記に近づけることができるだろう。また、チームでPBIを分担して進めているのではないか？Swarmingをすれば後はあまりならないと思う。これはスクラムマスターは注意すべき
個人的に一番ためになった質問だった。自分のチームもそうだったので、チームにも共有しSwarmingの機会を増やせないかといった話がレトロスペクティブ（ふりかえり）でできていてとても良い話だった。
改めて自分のチームがどういう状況か、どうなっているとよいか見ないな部分を考える良いきっかけになりました。
そして質疑応答で垣間見える他社のスクラム開発の状況や課題などがやっぱり興味深かったです。当たり前ですが、こちらの方が現場の話なのでスクラムらしいというか、この状況のベストがなにか?を考えるほうが面白かったです。
ワークも面白かったですが、他の参加者ともう少し懇親会的に話してみると意外と発見ありそうだなぁと思っていました。
最近チームのスクラムマスターをやり始めたid:d-haruです。
それはそれとして、5/12~14は松本で開催しているRubyKaigiに1ユーザーとして参加させていただきました。
結論から書くとめちゃくちゃ刺激になったし、子育て以外で疲労困憊になって爆睡するという経験も含めて久しぶりに子供のように楽しませていただきました~
いわゆるWebアプリケーションエンジニアとして働き始めたのは2019年で, その年に子供を授かり, 同時にコロナも来てしまいオフラインのイベントとは全く無縁のエンジニア生活を送っていました。
そんな中、少し時間もとれるようになりなんとかオンラインでもいいから参加してみたいと思い昨年のRubyKaigi2022 に参加させていただいたのが初でした。
朝イチですがなんとか初回のセッションに参加したかったので6時頃にそっと家を出て最寄りのJR中央線から特急信濃でまっすぐ松本を目指して到着しました。
きたぜ〜 pic.twitter.com/ZmqQWandsD
— d_haru (@d_haru91) May 12, 2023
なかなかに気持ちも高ぶっている様子です。
Gemの依存関係をどう解決しているのか, というないようでした。
バージョン管理ツールなんて便利に使わせてもらうことはあってもその内部実装については正直気にしたことなかったので知らないことばかりでした。
ただ、結構概要レベルの話からモデリングまでお話していただけたので非常に勉強になりました。
特にRuby Gemsが遅い原因などをRuby GemsとBundlerの内部実装の違いからきていること。requireやwarnの拡張していることなどはへぇ〜となりました。
また、めちゃくちゃニッチですがローカルに存在するgemがインストールできないという原因を愚直にデバッグして直した話など、バグの再現から修正の話はすごいと思いつつも、同時にめちゃくちゃ泥臭い対応もやってくれていて親近感(?)を感じました。
高速な並列テストを復活?させるという内容でした。
「1日は86400秒しかないのにCIで何10分も待てないよね」 「まずは現場的には金を出してとにかく高速に回せるようにするのがいい」 などなど、プロダクトに関わるエンジニア的にはめちゃくちゃわかる!!!と思わせるキャッチーなワードチョイスが印象的でした。
Rails6以降は並列テストの機構があるそう。minitestは標準ということもあってかちゃんとできていてプロセスを並列実行できるらしいです。
Rspecではシンプルに事前に分割して並列テストをしている感じのようです。これの問題として1番遅いworkerに終了時間が依存するというのはどこかで聞いたな...なんて思っていました
他にもOSSのメンテナンスの話もかなり大変そうながら、その場で特定バージョンのサポート切ることのコンセンサスをとるというムーブをしていて大規模OSSのメンテナーに必要な振る舞いを感じました。すごい。
koicさんにはDay2の2日目になんと直接紹介してもらって少しだけ会話させていただけて感激でしたが緊張MAXで何も質問とかできなくてごめんなさい。。。
感想はここに書きます、Rubyメソッドかるたもらえて嬉しかったです!
ShopifyのAlexandre Terrasaさんの発表でRBSとRBI/Sorbetの比較についての話でした。個人的に別言語で型を書く体験も増えてきていたこともあり、かなり面白かったです。
Rubyの型の歴史からRBSとRBIの比較をしていました。特にSteepの型解析が大規模なコードベースだと非常に遅いという課題があり、それをSorbetで.rbiに変換して解決しているという話のようでした。
資料がシュッと見つからなかったですが、かなりわかりやすかったです。英語全然聞き取れないタイプなんですがシンプルなスライドで前知識がそこまでない自分でもそこそこわかった気になれる講演でした。
この発表とは別ですが、Rubyで型付けが進んでいる一方で型定義に仕方については参加者の中でもいろいろな派閥がいるのもRubyならではの悩みっぽかったです。
スタンプラリーもやっていてちゃんと制覇してピンバッジもゲットしました
わいわい#rubykaigi pic.twitter.com/C964DKMvcK
— d_haru (@d_haru91) May 12, 2023
エムスリーさんの手書きサイン気に入ってます。
ブースはクイズがあったり、プロダクトの一部を体験できたり、wasmで弾幕シューティングゲームを公開していたりしてめちゃくちゃおもしろかったです。
DIGGLEさんのブースでゲームやってきた
— d_haru (@d_haru91) May 12, 2023
弾幕シューティングゲームは得意だと思っていたのは勘違いだった。これ10時間で作れるのruby wasmの可能性を感じるhttps://t.co/sX0KqpuNJe#RubyKaigi2023
松本は水も野菜も美味しいこともあって非常に沢山たべております。
初日はどうしてもここのラーメンを食べたくてぼっちで突撃しました。
麺匠佐蔵きた#rubykaigi pic.twitter.com/HhrJtGz9tC
— d_haru (@d_haru91) May 12, 2023
次の日飲んだ後にまた食べていてびっくりしています。
結局2日連続で来た麺匠佐蔵さん、つけ麺もうまかった〜#rubyramen #rubykaigi pic.twitter.com/dgnEh6gqTD
— d_haru (@d_haru91) May 13, 2023
珈琲美学アベさんで朝からパフェたべてます。ホテルのバイキング食べて30分後の出来事のようです。
ホテルバイキングからの喫茶アベで朝から豪遊してきた#rubykaigi pic.twitter.com/KFemwMxnBC
— d_haru (@d_haru91) May 13, 2023
ちゃんと松本城にもいったり、井戸を巡って水を飲んだりもしました。徒歩圏内に意外と観光するところもあって短い時間で色々堪能できました。
夜の松本城もなかなか良い pic.twitter.com/YfZ03KMWnj
— d_haru (@d_haru91) May 12, 2023
他にもバウチャーが余っていたので一人で蕎麦食べたりと楽しんでおりました。
最終日のお昼は初日に雑談させていただいた角谷さんが下記の投稿をしてくださったのをみて参加させていただきました。
“Day3もやる予定なのでこの記事を読んだ人はお昼の時間になったら1Fのインフォメーションのあたりに来てください。旗振りをしている人に「あそなすさんのブログを読んだ」と言えば通じるはずです” #rubykaigi …令和最新版アンチぼっちランチ…!!!! 激アツだ。ぜひ活用してください〜!!! https://t.co/JIKuChFy5H
— Kakutani Shintaro (@kakutani) May 12, 2023
ここでも全員別々の会社の参加者の方々と仕事の話やら、スクラムの相談やら、ゲームの話まで色々お話できて楽しかったです。
初日はラーメン食べてから散歩しつつタイムラインを眺めていたら登壇者の方が二次会募集していたので便乗して参加しました。我ながらアクティブ過ぎてびっくりする。松本マジックです。
とはいえ、お店のお客さんがほぼ全員Rubyist（おそらく100%）しかいなかったのもすごかった。もし他のお客さんいたらすみませんでした。。。
最終日はSTORESさん主催のAfter Partyに参加しました。
たまたまここで前職の同僚に会うことができ近況だったり、今の会社の方々たちを紹介してもらい色々とお話できたのも楽しかったです。
他にも同じくエンジニアの参加者、プログラミングスクールの現役生、運営スタッフ、コミッターとたくさんの方とお話することができました。
2日目からのぼっち参加でしたがそんなことを感じさせないぐらいたくさんの方とお話させていただけました。
最初にきっかけを作ってくださったid:onkさんには本当に感謝です。そしてその後人から人へとつながり、お話してくれたRubyistの皆様や運営の皆様にも感謝を。
わーい #rubykaigi #rubyfriends pic.twitter.com/DV75upYgEZ
— hokkai7go (@hokkai7go) May 12, 2023
「#rubyfriends」タグの復活もめでたい!
本当に楽しい時間でした、どうにかして来年は沖縄いきたい〜
最近は先人たちのブログなどを読むことにハマりつつあるid:d-haruです。
3月は結構イベント目白押しということもあってこれまでに比べると考えさせられることが多い月でした。
割と業務中心の振り返りではあるけども整理してみます。
業務でフロントエンドの複雑な箇所を紐解きリファクタリングを試みる開発合宿というものに参加させていただきましたのですが, 結構反省多めで振り返ります。
あくまで自分自身のことであるが, 圧倒的に事前準備が足りなかったのは1番大きな反省点でした。
というのも, 合宿開始するまで具体的にどのコードを修正するのか, どういう難しさがあるのかを自分から能動的に調べられていなかったです。（一緒に参加した皆さん、ごめんなさい）
が頻繁にあるというわけではないですが, 珍しくはない.次回なにかやることがあればちゃんと準備しておき, リード出来ずとも自身の意見をもって臨むなどしていれば初速が全然違っただろうなぁと感じている.
全体的に後手に回るような動きになってしまったことが一番の反省点という感じではあるが, 次はもっとうまくやる
書いてあるとおり. 致命的な問題ではなかったかもしれないが, やはりここを無視していてはだめだろうと思い書き始めました。
個人でも本格的に触り始めて、だんだんもとのJSを見るとTSにしたくなる気持ちはわかるようになってきました。とはいえイベント周りの型付けがかなり難儀だなぁ、、、とか文句言いながらやっているのでもっと仲良くなりたいと思っております。
こうしたイベントに参加するのは初めてではありませんでしたが, こういうときにこそ自力が出るというか, 自身の課題がよく見えたように思います。
こういう場面でもパフォーマンスを発揮できるようにするためには, 上記であげた反省点だけでなく日々のインプットを増やさねばと思うイベントでした。
上の話題を受けたころもあり, 個人的にはTSに触れる機会の多い2年前ぐらい放置していたNext.jsプロジェクトを最新化したりライブラリを入れたりしていた
おもちゃアプリではあるのだが, こういうところでライブラリの検証などを色々していけると良いのかなと思い触り始めています。
その過程で時刻操作系のライブラリ周りについて調べたりしていました。意外と知らないことも多かったが雑談のネタにもなったりして面白かったです。
下記でも書いているのでここでは割愛.
オフラインカンファレンスは初だったけれど非常に刺激をもらいました...
本格的にスクラムについて能動的に考える機会は増えていると感じています。
一方で基本的なことはわかってきたが更に良くするための手法などの知識をもっていないと思う機会も多かったです。他のチームの人と話す機会があるので結構このあたりの悩みは相談して答えをもらうんですが, 逆にこういうときのプラクティスを「知らないだけ」というものも多いのでインプット量を増やしたいなと思いました。
自分は大規模チームでスクラムに参加しているので, そうしたチームの情報を見だすようになりました。
あとはFour Keysの記事を度々読んでいます。（計測は十分にできていない。。。）
なかなかに刺激的で今後の自分のキャリアとかも含めて結構考えることの多かった月でした。
これまでのキャリアから色々できるようにならなきゃという考えがどこかにありましたが最近はそれよりも自分にできることをしっかり伸ばしていきたいと思考にシフトしつつあります。（できることはまだまだたくさん増やしたい気持ちもありますが）
特にYAPCでも本当にいろんなエンジニアの方の話を聞くことができたおかげもあっていろんなあり方があることを知ることができたの自分にとって大きな価値がありました。
5月はRuby会議いきたい!!（まだ申請してない。。。）
きっかけは会社からスポンサーチケットがあるよ〜との通達でした
正直言うと、愛知在住なのもあって最初はどうしようかなぁ〜ぐらいの気持ちだったんですが京都に行く機会もそんなにないし、せっかくだい行ってみるか!!
という非常に受動的なきっかけですがYAPC::Kyoto 2023 に参加してきてめちゃくちゃ楽しかったのでちゃんとブログ書きます!
それぞれの感想もまた書きたかったですが本日は受けたセッションだけ列挙するのに留めます。（また書くかも知れない）
Perlの話に限らず多種多様なレイヤの技術の話が聞けて面白かったし, 非常に刺激になりました。
共通してChatGPTのネタが多かったのも笑ったw
運営, 登壇者, 参加者, 出展ブースの様子などからコミュニティ全体の様子などを見ることができました
個人的にですが, YAPCは運営も参加者もみんなで盛り上げようとするような空気感があるような気がして, 良い意味でアットホームさを感じました。（最後のキーノートめちゃくちゃエモかった）
はてなに入社してもうすぐ半年というところですがリアルであったことがある人は数名という状態でした
今回たくさんの方に会うことができ, ランチや飲みをすることができたのでこれだけでも来たかいがありました（ランチで食べたハンバーガーの写真を取り忘れてしまったけど美味しかったです）
前日祭からものすごい盛り上がりを見せているのをSlackでも観測していて、お祭り感に浸ることができました
非公式? というかYAPCが終わった後にもお酒を飲みつつ交流する機会がありました。
YAPCの感想だったり, 最近の開発事情やOSS事情だったり技術の話を中心に盛り上がる楽しい会でした~
え、あのライブラリ作ってる方なの?みたいなことの連続でビビりました。。。
残念ながら小吉でした, 気を引き締めます
以前Ruby Kaigi にはオンラインで参加したことはありましたがやっぱりカンファレンスはコミュニティとのつながりや熱量をもらえるのがおもしろポイントなのでオフラインの体験はめちゃくちゃ良かったです！
別の会社の人と技術の話をしたり、リアルで会うのは初めての自社のメンバーと話したりとセッション以外でも得られるものもたくさんありました。
運営の皆様, 登壇者の皆様, 素敵な会をありがとうございました！！
3月は初旬からもろスギ花粉にこてんぱんにされて振り返るのが遅くなってしまったid:d-haruです
2023年2月にブックマークしていた記事をみつつ、2月の振り返りをしてみた
昨今 Native ESM という単語を耳にする機会が増えてきたものの、イマイチ説明できないなと思っていてちょっとみていた
CommonJS に変換せずにそのままESMを使うということはわかっていつつも、そこにどんな課題があるのか、どうすればできるのかみたいなところまで知らなかったのだが、このあたりめちゃくちゃ丁寧でわかりやすかった
ほかはCORSやXSS絡みのふわっとした理解を補完しようと調べていて気になった記事をブクマしていた
お作法的に対策している感が否めないので対策していなかったときや攻撃したらどうなるかを触ってみると理解が早そう
1月にGoでWebアプリつくるときに使いそうなライブラリをちょこっと調べていた流れで今月も少し見ていた
Go言語大好きな人を観測することが多かったので逆張りが気になってみていそうで、自分もがっつりRuby書いていた身だからかGoへの感想は結構似ててテスト周りの所感も確かなぁ、と思った
スクラムチームにいることもあり、気になったことなどをブクマしていた。
id:yigarashiさんのfour-keysの話はなかなか興味深くて、リファクタリングをすることを効果をfour-keysで言語化するなどは使えそうな手法だった。
たまにTDD派だったので非常に腑に落ちた
アトピー患者なので助かるし、すごくわかる、、、となった
参考に色々させていただきます
関心が高いジャンルは結構長らく変わっていないが、フロントエンドの情報をキャッチする量が結構増えていそう
もうちょっと実コードを触りつつ理解を深めたいものが多い
スクラムについても関心が上がってきていて他社の事例とかを目にしている
このあたりは今後担う部分も増えていきそうなのでもう少しアンテナが広げていきたいです
株式会社はてなに入社して3ヶ月近くが経過しました。期も区切りがついたところで納会終わりの夜のテンションで振り返りをしていきます。
id:d-haru です。
はてなの京都オフィスに所属しておりますが、愛知県に住んでおり初日以外はリモートワークで仕事をさせてもらっております。
前職ではRubyを中心に新規事業や大規模なWebサービスの開発をしていました。
転職した経緯とかは色々あるので割愛しますが、はてなに最終的に決めた理由は採用面接の体験が非常に良かったことが大きいです。
というのも、中途採用では（新卒も?）技術ディスカッションがまぁまぁ長い時間あるのですが、思いの外盛り上がりました。
自分は設計だったりチーム開発における課題だったりを議論して解決策を模索していくのが結構好きなこともあって、この場で「はてなで働いている自分」の解像度をあげることができました。
Webアプリケーションエンジニアとして、はてなブログの開発を担当させていただきました。
あまり前職で触ってはこなかった技術スタック（Perl・TypeScript + React）だったのですが、Perlに関してはRubyに長く触れていた経験をベースにしつつチームとペアプロをすることでそこまで学習コストをかけずに開発できるようにはなったかなと思っています。
はてなブログはかなり規模や機能も多いサービスのため、ドメイン知識の足りなさを補いつつ埋めるために大声で作業することを心がけました。
この考え方は入社して3日目ぐらいにチームメンバーの方に教えてもらって知ったのですが、まさに今の自分がやるべきことだと思い、scrapboxとSlackなどで雑ながらもアウトプットし続けながら仕事をしていました。
幸いにも、自分の悩みなどを素早く拾っていただけて、狙い通り自身の足りない部分を埋める事ができたんじゃないかと思います。評価面談のフィードバックでもここの動きについては言及してもらえて嬉しかったです。
これはサービス全体で感じたことですが、はてなのサービスを好んでくださっている方が多くいるということを感じています。
ユーザーからのフィードバックを目にする機会があり、もちろん全てがそうではありませんが、ファンレターのような応援するというメッセージだったり、ユーザビリティ向上に気づいてコメントしてくれたりという反応があるのはとても新鮮で嬉しかったです。
また、一般のユーザーではなくto Bの取引先の方からも「良いものが作れました」といったフィードバックをもらえる場面も多々あるようでした。（本日の納会で沢山知りました）
Webサービスの開発は、ときには数値として結果に現れないこともありますが、上記のような数値とは違う何かを生み出し、それを分かち合えるのは簡単には味わえない面白さだと思っています。
はてなではいわゆる「サブ会」という制度があり、有志があつまって技術的な勉強だったり、ディスカッションをしております。
たとえば、スクラム開発をよくしていくためにいろんなチームの事例や困りごとについて話題を持ち寄ったり、フロントエンド界隈の最新の技術動向について調査したりなどをしています。
いつもの開発チームだけでなく、あくまで有志の活動なので横断的に話をすることができるのも特徴的です。
また、これをスムーズに動かすために10%ルールというものがあり、横断的な活動の障壁を減らす仕組みとして非常にうまく機能しているんじゃないかと思っています。
2016年の記事ですが、詳細はこちらでも書かれていそうで今もなお機能し続けております。
個人的には結構画期的な制度で、うまくバランシングされていると感じました。特に10%ルールが結構肝なんじゃないかと思っていて、うまくバランシングされているのかなと思っています。そのためか、今のところは全く心理的なハードルを感じずに活動に参加できています。ありがたや〜
後半は採用担当みたいになってしまったけども、誰に言われたとかでなく1個人の感想です。本当に。
2月から新しい期では、より事業に踏み込んでいきチームとプロダクトの成長に寄与するような行動をとっていければと思っております。
来期も頑張れよ、俺。
