オンボーディングは3ヶ月で3連勝を目指す - id:onk のはてなブログ
先日 ヘンリーで活躍中の id:Songmu を訪問 | はてな卒業生訪問企画 [#3] - Hatena Developer Blog という対談記事でもオンボーディングについて話したんだけど、社内では最近「3ヶ月で3連勝」を標語にしている。 オンボーディングとは 採用や異動などでチームにジョインした後に行う、早期戦力化のための施策のこと。開発環境のセットアップやチームの説明だけじゃなく、戦力になるまでのプロセス全部を指していそう。 僕らは各アカウント作成や開発環境構築はチェックボックス化してドンドン進められるようにしている *1 し、事業の説明、組織の説明、システム構成の説明をする場を設定したり、技術スタックへの入門のための実績解除システムを用意したりしてきた。 これらのドキュメントに従って作業を進め、実績を解除していくことで、作業的・技術的な道標はあるものの、オンボーディングプロセス
デュアルトラックアジャイルとの向き合い方。あるいはエンジニアとビジネスの距離感 - id:onk のはてなブログ
昨日（もう日付余裕で回ってるので一昨日だな）Findy さん主催のイベントで話してきた。 speakerdeck.com 背景 近年「エンジニアは事業貢献してこそ」「エンジニアもユーザファーストでビジネス貢献」といった言説がIT界隈で増えて来ている感じがしている。 ……とたまたま昨日関連してるようなしてないような話をしている エンジニアとビジネスの距離感の難しさ｜ばんくし｜note という記事があったので書き出しを真似してみたんだけど。 昨今、ビルドトラップに陥るな、アウトプットじゃなくアウトカムに着目しろ、って言われることが増えてますよね。でも僕は逆張りして、アウトプットにまず着目しろという声を上げておきたいのです。 開発生産性（いろいろある*1）の話をするときに、ディスカバリーとデリバリーの 2 軸で考えるのはコモディティ化してきたと思う。でも、それによって、デリバリーの重要性が薄くな
ストーリー性のあるプレゼン - id:onk のはてなブログ
発表資料作り、全体的な流れは 1 週間ぐらいかけて構想して、半日使って 15,000 字ほど書いて (コード片含む)、半日使ってスライドに起こす(結果として 6000 字ぐらい使う)、って感じですね。貯めた文字列を組み合わせている最中に構想とは別のストーリーが降ってくることも多い。— Takafumi ONAKA (@onk) July 3, 2018 このツイートの「文字を組み合わせる」のところについて、もうちょっと掘り下げてみる。*1 この記事は はてなエンジニア Advent Calendar 2022 の1月2日の記事です。昨日は id:stefafafan で 『UNIXという考え方―その設計思想と哲学』を読んだ - stefafafan の fa は3つです でした。 3 つのポイント 知っていること 7 割、聞いたことがあること 2 割、知らないこと 1 割 引用しやすいワー
git push -f が更に安全になる --force-if-includes - id:onk のはてなブログ
歴史改変、してますか？ 私は歴史改変が大好きで、毎日 rebase しています。なので割と毎日 git push -f することになっています。 口で -f と言っても、実際には --force-with-lease --force-if-includes をしているので、これらのオプションのご紹介。 この記事は はてなエンジニア Advent Calendar 2022 の 18 日目です。昨日は id:rokoucha さんで 壊れたデータベースとの向きあいかた - rokoucha でした。 qiita.com -f の危険性 ...--F--G--H <-- main という状態で push した後、H をコミットし直したとしよう。 ...--F--G--H' <-- main \ H <-- origin/main このまま H' (main) を origin/main に p
積極的フィルターバブルで価値観を破壊する - id:onk のはてなブログ
と成長への近道なんじゃないかという仮説。 積極的フィルターバブルとは resize.fm #100 で id:nagayama が語っていた概念。44:10 辺りから。 anchor.fm 新しいことを始めるときに、Instagram でサブ垢を作って、その関係の人しかフォローしない タイムラインは全部スケボーになる 自分の価値観が、いかに板に乗って高く飛ぶか、に変わっていく 業界用語や技術のトレンドとかが自然に入ってくる 以前僕も似たようなことを言っていた。 短期間で新技術を学ぶ技術 from Takafumi ONAKA このときは情報を浴びてインデックスを自分の中に持つことを目的としていたが、いわゆる近接性バイアス、接触頻度が価値観に与える影響というものも大きいんだろうな、と思う。 これを聞いたので、僕も Instagram でサブ垢を作って、#kendama タグで検索して、100
最近買ったイヤホンたち - id:onk のはてなブログ
密閉型イヤホン以外でWeb会議アドベントカレンダーに遅れて参戦！ こういう状態。 ここ3年で増えたヘッドンホホたち SONY WH-1000XM4 www.sony.jp ヘッドフォンですね。2020-09 に買った。 外音取り込みは、外の音が聞こえるイヤホンを↓でいっぱい買ったので、むしろ外音を取り込まないために使うヘッドフォンになった。 ノイズキャンセリングは最高に便利。僕も妻も机を並べて WFH しているので、同時に会議すると声が混ざって困り、この子に付け替えている。 AfterShokz OpenComm OPENCOMMjp.shokz.com 骨伝導。2020-11 に買った。 耳を塞がず (外耳炎にならなくて最高) に外の音が自然に入ってくる (在宅作業しやすくて最高) のはものすごく快適で、しばらく「最高〜〜〜〜！！！」と思って暮らしていた。 完全ワイヤレスではなく、ヘッド
git revert -m1 の -m は --mainline - id:onk のはてなブログ
TIL merge commit は親が 2 つ (以上) あるので、revert するときはどちらの親に戻したいかを -m (--mainline) で指定する。 起きたこと 「意図せず feature branch を main に混ぜて push しまった」と呼ばれて飛び出したんだが、コミットツリーがこうなっていた。 525adcbf69 ●─╮ [main] {origin/main} Merge branch 'main' of ... de745c8669 │ ∙ commit for main 2060e2be19 │ ∙ commit for main 813528befb ∙ │ commit for feature 9ed9cb80a9 ∙ │ commit for feature 9f8e1bb2e1 ∙ │ commit for feature 元々の main 最
Ultimate Hacking Keyboard のキーマップメモ - id:onk のはてなブログ
どこかに書いておかないと確実に忘れて困る。 UHK とは コレです。 ultimatehackingkeyboard.com 割れてる、60%、row-staggered、半田付け不要で、これ以上沼に踏み込みたくない人間には最高です。 v1、v2 と 2 台買ってきた。 UHK 2 台目届いた。茶軸からピンク軸にしました。 pic.twitter.com/apft63dNxW— Takafumi ONAKA (@onk) May 1, 2022 キーマップ 専用アプリでキーマップを変更し、キーボードに書き込める。接続されているキーボードをそれぞれ認識してくれるので、複数台持っていても安心です。 以下に設定していますが、とりあえずで使っているので全然拘れてない。丸 3 年ぐらい使ってて全然カスタマイズできていないのでだいぶ老化したと自分でも思う。 左右の Space（？）手前の謎キーを Mo
意識的に職位を下げる - id:onk のはてなブログ
僕はチーム join 時に、Docker は初手で剥がすし、GitHub Actions でやっているワークフローの全体像を把握するのを次に行う、というのを基本的にはやっている。これはシステム構成やデプロイ周りの全貌を把握するのが好きなのと、何かが起きたときにコレをやっているのといないのとで問題切り分けの精度に圧倒的な差があるからなんだけど、join 直後にやるのが最適解とは限らない場面もある。 チームの人員構成として、テックリード業を既に担っている人が居る場合、追加人員にはテックリード未満の「プラスの工数として数えられる戦力」となって欲しい。この戦力というのは、「目の前に積み上がった問題を一緒に解いて欲しい」という期待。問題と言うよりも、既にタスクになっているものを消化したい、という期待の方が大きいと思う。 そういう期待があるときには、ちんたら Docker を剥がしている場合ではなく、
使用頻度とコマンド (エイリアス) の文字数を合わせたい - id:onk のはてなブログ
1 文字エイリアスのすゝめ 1 文字エイリアスが好きで、例えば alias s="git status -sb" している。 入社してからの 4 年半で溜めた 53 万行の .zsh_history から集計すると、 $ history 1 | awk '{ print $2 }' | sort | uniq -c | sort -nr | head 121714 g 114128 s 57124 v 34210 cd 26095 tig 23281 rg 11382 plenv 10837 t 9647 :q 6867 ll となった。ちなみに以下の略です。 alias g="git" alias s="git status -sb" function v() {vi -p ${${=*/:/ +}/:*}} alias t="tig" alias :q="exit" alias ll=
期待値をチューニングする - id:onk のはてなブログ
吉祥寺.pm30 で、チューニングがテーマだったので、マネージャとメンバー間で期待値をチューニングするという LT をしてきた。 トークタイトルは熊とワルツを。トム・デマルコの本です。 熊とワルツを リスクを愉しむプロジェクト管理 作者:トム デマルコ,ティモシー リスター日経BPAmazon 「管理」という言葉 「管理」と訳される単語は色々ある goo 和英辞書 によると 〔経営〕management 〔経営，運営〕administration 〔統制〕control 〔監督〕supervision 英辞郎 on the WEB によると administration〔【略】admin. ; adm.〕 caretaking（建物・土地などの） caretaking〈英〉（学校などの公共施設の） charge conduct（業務などの） control custody（大事な物の） d
先回りするコツとミカドメソッドという手法 - id:onk のはてなブログ
実装を進める上で障害になりそうなところを先回りして直してるように見えるけど、一体どうやって検知しているかという話題。 結論から言うと「慣れです」なんだけど、こういう考え方があるよというのを紹介しておく。 mikadomethod.info ちょうど10年ぐらい前に話題になった手法だけど、考え方としてはまだまだ現役です。 概要は本家なりこの辺のリンク先なりを見て貰って。 開発者のためのソフトウェアテストのスキルアップ | Think IT（シンクイット） 大規模コードをリファクタリングする方法『ミカドメソッド(Mikado Methood)』について | Futurismo テストとリファクタリングに関する深い方法論 #wewlc_jp レガシーソフトウェア改善ガイド | Amazon 僕の理解は 1 ループ目 やりたいことを実現するコードを書く ギャップが無ければサクッと実装して終わり
はぴば - id:onk のはてなブログ
おはようございます。onk です。2021年12月18日の、朝です。11時なので、朝というか、昼ですね。ここでタイマーをセット。 この記事は、やんちゃクラブリスナー Advent Calendar 2021、18 日目の、記事です。 やんちゃさん、誕生日おめでとうございます 本日 18 日は yancya の誕生日です。 知ったのいつだっけな。 @chiastolite による誕生日 Advent Calendar 界隈でよく話題に上がるので以前からワイワイしている。 adventar.org 誕生日 Advent Calendar、@yancya 氏に取られたｗ— Takafumi ONAKA (@onk) November 4, 2014 @onk 実は同じなんですよねｗ— yancya (@yancya) November 4, 2014 @chiastolite @onk おめでと
ソフトウェア式年遷宮という概念の歴史と、Hatena::Let での実例 - id:onk のはてなブログ
Hatena Engineer Seminar #17 にて発表しました。 hatena.connpass.com Hatena::Letの式年遷宮 from Takafumi ONAKA www.slideshare.net 発表内容をかいつまんで記事にも書いておきます。 Hatena::Let とは はてラボ のサービスの一つ。 僕も入社するまで、はてラボ == ベータ版、だと思ってたんですが、 ラボならではの挑戦的なサービス 運用費が会社持ちで、会社の名前で出しても良い、はてなスタッフの有志が運営するサービス、という制度 も含んでいます。 で、Hatena::Let は、現在は主に id:onk が開発している、ブックマークレットをかんたんに作成・公開できるサービスです。 ソフトウェア式年遷宮とは 初出は 2013 年の id:kenjiskywalker によるもので、このときはイ
フルタイムでやる仕事を作る #wantedlydev - id:onk のはてなブログ
先日 Wantedly さんのエンジニアリングマネージャー座談会に出演させていただいた。 wantedly.connpass.com テーマは、「エンジニアリングマネージャーの課題を相談したい人が多い」「その相談パブリックにしよう」なので、自分が最近課題に思っている「変化の速度感」についてざっくばらんに会話できたらなーというのが期待だった。 イベント中には、大きく 4 つの話をしたのかな。それぞれ会話の中では話しきれなかったことも補足しつつ書いていく。 技術スタックが違うチーム プロダクトと専門組織のバランス 専門組織を立ち上げるポイント 採用と oss-guild 技術スタックが違うチーム リンク先を見て貰うと顕著に分かると思うけど、はてなでは、そこそこバラバラな技術スタックを使っている。 hatenacorp.jp インフラは AWS、Google Cloud (オンプレはやっと撲滅し
チームに浸透させるのが近年では難しくなっている - id:onk のはてなブログ
昨日「動いたけどチームメンバーを説得するのが面倒で、秘蔵のブランチになってしまう」って言ったけど、この気持ちはどこから出てくるのか。 分かりやすい Cons があると、反発が予想できて、その反発を解決するところまで労力を割くほどの気持ちが無いので困る。「直ちに問題になるわけじゃないが、どちらかというとやった方がいい、でもリスクもある」という選択肢を選べずにズルズルと現状維持に向かう圧力は、ある。チームの同質性が高いうちはほとんど困らないんだが、人数が増えたり、別の職種が増えたりするごとに「面倒」さはどうしても増していく。 我々の信念として以下を持ってはいるが、現状維持に向かう圧力がある中で変化を加えるのはそこそこ労力が要り、閾値を超えると変化が発生しなくなってしまう。 業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。 素早く変えてもし仮にダメだったら素早く
branch を寝かせるときは TODO.txt を置いている - id:onk のはてなブログ
タイトルがすべて。 思いついたら手を動かしてしまう性質なので、秘蔵のブランチを大量に持っている。 秘蔵のブランチというのは、動いたけどチームメンバーを説得するのが面倒とか、テスト書くのが面倒とか、だいたい動いているけどやりきるのが面倒とかで main にマージしていないヤツ。 例えばフレームワークのメジャーバージョン上げるブランチとか、依存ライブラリをより一般的/現代的なものに交換するブランチや、より良い設計を思いついたのでガッと書き換えてしまうブランチが多いかな。 だいたい 1 年所属していると 80 ブランチぐらい溜まるので、週 1 つ以上は何か作りかけてる計算になる。 ローカルブランチの数、プロンプトに出しておくかな……。(秘蔵のブランチが溜まってる— Takafumi ONAKA (@onk) March 28, 2017 もちろん自分でいいアイディアだと思っているから実装している
体制を考えるときに意識していること - id:onk のはてなブログ
1on1 で伝えたので外にも書いておく。 プロダクトやチーム、メンバーのフェーズ まず現状分析。 自プロダクトは PPM で言う花形、金のなる木、問題児、負け犬のいずれに当たるのか 勢い MAX でめっちゃ盛り上げるのか、地味に役割を達成するのか。自チーム全集中なのか他チームのフォローに回るのかみたいな方針が変わる 自チームは エラスティックリーダーシップ で言うサバイバルモード、学習モード、自己組織化モードのいずれに当たるのか チームを改善しなければいけないのか、プロダクトだけを見ていて良いのか。チームで改善できるのか、リーダーや外部の強い意志が必要なのか 各メンバーは、期待される役割において SL理論 で言うとどのフェーズなのか 指示的行動が必要だとマイクロマネジメントすることになり、マネージャ/メンター的な人/行動を増やす必要がある 役割を網羅しているか こういう軸で考えていることが
Smart UI パターンが再評価される世界 - id:onk のはてなブログ
設計ナイト2020 を受けて、今どんなアーキテクチャを選ぶべきかという話をしたくなったのだ。 kichijojipm.connpass.com 設計ナイトで高ぶった結果1時間コースの発表資料が完成したので供養場所を探しています。聞いてくれ！！！— Takafumi ONAKA (@onk) 2020年11月1日 お前誰よ 2000年代前半に SI 2000年代後半にブログ、SNS 2010年代にソーシャルゲーム 2020年代に UGC サービス をやってきた人間。数百万〜数億行のデータ、月間数千万〜数十億 imp 程度を主戦場にしています。 今日の話 DDD と PofEAA から学ぶパターン/アンチパターン Rails によって発見された、密結合で速く走れるソフトウェア 今求められているアーキテクチャ 昂ぶって 15,000 字ぐらい書いてしまった。 DDD と PofEAA から学ぶパ
書類選考時に見ているポイント - id:onk のはてなブログ
2019-04-01 に「チーフエンジニア」という肩書きを手に入れてしまった。 はてなのエンジニア組織にはチーフエンジニアという役割のエンジニアがいて、評価や採用、その他大小諸々の施策を通じて、技術部門全体の生産性と幸福度を向上させるのがその仕事です。 はてなのエンジニアのバリューズ - Hatena Developer Blog 前職でも新卒採用、中途採用のお手伝いはしていたのだけれど、今は主業務の一つとして担当しているので、僕がどこを見ているのか、というのを書きとめておこう。 履歴書 チラ見しています。 「通勤片道1時間ぐらいかかりそうだけど大丈夫かなぁ？」とか「趣味がルービックキューブじゃん！ はてなの speedcubing 部と戦わせたろ」とかを見ています。 職務経歴書 まぁまぁ見ています。 プロジェクトで使った技術、特にアーキテクチャについてを一番見ていると思います。次にプロジ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
