2021-12-21

2021 近況

この記事は Rubyist近況[1] Advent Calendar 2021 の 20 日目の記事です。すみません、1 日遅れです。完全に 21 日目のつもりでいた。。

忘年会が無いのでご挨拶代わりです。皆さんお久しぶりでーすﾉｼ

昨日は 1 スレ目は id:Sixeight さんの近況 - ちなみに、2 スレ目は id:shucream さんの 2021-12-19 | けんちゃんくんさんのWeb日記でした。似たような年齢なのでマネージャが続きますね。私もです。

今年の目標

達成見込みです。

予約したので目標達成に限りなく近づいた。あとは行くだけ https://t.co/LIPT8lJMxt
— Takafumi ONAKA (@onk) December 18, 2021

丸 2 年切ってないので 25-30cm ぐらい伸びてんのかな。髪ブラできる長さになってしまった。人生最長。

ヘアゴムで止めるのがちょっと大変になって、最近かんざしを挿すようになっていました。どれだけ伸びててもまとまって便利。

来年は？

もうちょっとアクティブにコミュニティ活動したいなと思っています。さすがに 2 年経つと飽きてきたというか、既存の知り合いとしか会話できていないのが気になるようになってきた。

2021-12-18

はぴば

おはようございます。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 おめでとうございます！
— yancya (@yancya) December 17, 2015

おめでとうございます too！
— Takafumi ONAKA (@onk) December 18, 2018

さて、今回のやんちゃクラブリスナーアドベントカレンダーについてだけど、

周りを煽ってみる

やんちゃクラブリスナーadvent calendar、みなさんが次に引きずり込みたい沼の入門を書くといいんじゃないかと思っている。
— Takafumi ONAKA (@onk) November 12, 2021

もちろん煽り返される

onkさんは何日なんですか!!!????https://t.co/RijFdJeofK
— Kakutani Shintaro (@kakutani) November 12, 2021

用意していた断り文句を言う

12月18日被っていて取られちゃったんですよねぇ。。 #誕生日アドベントカレンダー
— Takafumi ONAKA (@onk) November 12, 2021

なんと 18 日が空く

空けておきました https://t.co/n3xrgIBN8c
— yancya (@yancya) November 12, 2021

という流れで参加することになったんだけど、誕生日を理由にしたことで @chiastolite に完全な流れ弾が飛んでしまった。

これ、最終日は俺が書くやつ？#誕生日アドベントカレンダー
— 馬美肉 (@chiastolite) November 12, 2021

大変申し訳ありません。楽しみにしています。

やんちゃクラブ濃度

この時点では実はやんちゃクラブ見てなかったんですよ私。

みんなが会話しているので、毎日上がってるとか、フェーズ1が第二次小バエ戦争で幕を閉じたとか、んーんっんキューブやってるとかは知っていて、今日は何の話かなと想像しながら TL を眺めていた。

YouTube なんか苦手なんですよね。UI が。

YouTube Live のチャット欄にコメントしようとすると「チャンネルを作成してチャットに参加」ボタンになって、コメントしたいだけなのに意味分かんねーって思いながら仕方なく Twitter で実況する程度には苦手。「チャンネルを作成」って何？コメントと何の関係があるの？

のでイマイチ見ることができてなくて、けまらしさを覚える日々を送っていたんだけど、

#やんちゃクラブを Podcast として聴けるようにしてしまった… これでますます捗りそうだな…#おつかれシャワーも音声だけを切り出して Podcast としても配信してもいいかもなあ、と思うようになった🚿 pic.twitter.com/yo9KcM8dwj
— Jun OHWADA 🚿 (@june29) October 19, 2021

うぉっ！！ポッドキャストは UI 分かる！使いたい！

けどコレどうやってやったのか分かんないので気になりながら待ってる！ってやってたら、アドベントカレンダーの12日目の投稿で方法が明かされた。Listenbox なるほど！！！

www.youtube.com

june29 のおかげで快適生活が始まった (Listenbox -> Google ポッドキャスト pic.twitter.com/i0YOaHnrHn
— Takafumi ONAKA (@onk) December 12, 2021

というわけで 12 日にようやく視聴開始して、90 本一気に聞きました。等倍で聞いているので生活の 1/4 がやんちゃクラブ。世界で一番やんちゃクラブ濃度が高い自信があります。

4K で配信云々って話を耳で聞いてるのは、こう、申し訳なさがありますね。

喋りが圧倒的に上手くなってるのも連続して聞いてると実感できて、継続するってすごいなぁ、という気持ち。

やんちゃエフェクト

以前からカートに入ったまま悩んでいた Ember の温度制御スマートマグ2 をカートから削除したぐらいですかね……。いやなんかいっつも電池切れてるし、あーそうですよね、みたいな。スピンカップNEO も 1 年ぐらいカートに入っていたけど、ついでに消しました。

あとは日記ノートの冒頭にトークスクリプトを書くのが良いなぁと思って、試し始めました。

日記(？) は元々書いてたんですよね。10年ぐらいかな。Slack やターミナルにコマンド打ち込む前にこっちに書いてコピペしたり、Twitter に書きかけて止めたことを行き場が無いからココに残ってたりしている。思考の過程が残ってるので、あとからめっちゃ検索してる。

$ wc -l 2021*.md
    1027 202101.md
     359 202102.md
     916 202103.md
     722 202104.md
    1100 202105.md
    1978 202106.md
    1457 202107.md
    1503 202108.md
    1711 202109.md
    1476 202110.md
    1030 202111.md
     366 202112.md
   13645 total

トークスクリプトというか、TODO リストだな。今日やることを毎日コピペすることで意識に上げる作業。愚直な泥くさいやり方でも、効果があるし、やってみると良いかなぁって。

ノートと言えば、クアデルノ買いました。電子ペーパー。オライリーや達人出版会、ラムダノートで買った本は全部放り込んであって、無意識に Twitter 開くみたいな意識の逸れ方をしなくなったので、読書体験は向上したし、メモ書きたいときもとても便利に使っています。

っと、タイマーだ。じゃ、こんなところで。

ばいばい

2021-12-18

ブログから技術記事を抽出・集約してワイワイする

この記事は、はてなエンジニア Advent Calendar 2021 の 18 日目の記事です。昨日は id:dekokun の bitcoinのfull nodeをAWSでなるべく安く運用してみる - でこてっくろぐねおでした。

full node の存在知らなかったし EBS SC1 を使うって発想もなかった (最近 gp3 以外選んでない) ので面白かった。Bitcoin 思ってたより善意に支えられてるんですね。

dekotech.dekokun.info

さて本題。

はてなスタッフの日記

はてなスタッフは、だいたい個人ブログを持っています。また、技術ブログと日記とを分けずに一つのブログに書いている人もそこそこ多くいます。僕も分けてないので年末は「今年買ったもの」を投稿していたりする。今年も書きます。

onk.hatenablog.jp

技術記事を Hatena Developer Blog (会社のテックブログ) に書くこともありますが、個人ブログの集合体がコミュニティなんだよって気持ちから、個人ブログに書くのももちろん推奨されています。

月次のブログ紹介

毎週木曜日に技術勉強会を開催していますが、その中でも月初は特別編として、社外向けに書かれた技術記事をまとめて眺めています。

月初の勉強会は月に一回の特別編です。前月に書かれた技術エントリ（社内ではなく社外向けに書かれたもの）にブックマーク数100usersを超えるものがあったら寿司とビールでお祝いをします。

developer.hatenastaff.com

今はリモート開催なので寿司ビールはやれてないんですが、月次でのみんなの記事の共有は引き続き変わらず行っています。

入社時の儀式

これを実現するためには個人ブログの技術記事を集約する必要があり、そのデータとして全員のアウトプット先を YAML として持っています。

こんな感じ。

- owner: hatenatech
  url: https://developer.hatenastaff.com/
  kind: hatenadeveloperblog
  weight: 2
- owner: onk
  url: https://onk.hatenablog.jp/
  kind: hatenablog
- owner: onk
  url: https://www.slideshare.net/takafumionaka/
  kind: slideshare
- owner: onk
  url: https://blog.onk.ninja/
  kind: other

owner, url は見たまんま。 kind はパーサ向けの情報。 weight は面白機能で、Hatena Developer Blog に書いた場合は、特上寿司獲得ランキングにおいて 2 倍のスコアになります。

入社時に、自分のブログやスライド投稿先を足して PR を出す、というのが、エンジニア職で入社した人の儀式になっています。

投稿されたらワイワイしたい

月次で眺める会を実施しているのは前述の通りなんだけど、もっとワイワイしたいので、リアルタイムにも眺めたい。

リアルタイムにワイワイする、イコール Slack の #engineer に流す、をやりたい。

日記は車だったり釣りだったり育児だったり VTuber だったりと、まぁ本当に日記で、#engineer に流すにはちょっとノイジーなので、技術記事だけに絞り込む必要がある。

つまりこうです。

ブログリストから
新着をポーリングして
技術記事かどうかを判定して
Slack に流す

もうちょっと詳しく

ブログリストから

YAML をパースする

技術記事かどうかを判定して

本文を抽出する
技術記事かどうかを判定する

をやる必要があります。

本文を抽出するのは、フィードに全文が入っていたらそれを使えます。サマリーしか入っていない場合は、フィードの URL から HTML を取得して、本文っぽいところを推測します。「それ Pla」とか「LDR Full Feed」というワードが頭をよぎりますね。

LDR Full Feed はサイトごとに XPath を用意していました。全サイトについて XPath を用意するのは少し大変なので、フォールバック先として「いいかんじに推測する」という実装も用意しておきたい。本文抽出は Webページの本文抽出 (nakatani @ cybozu labs) とか HTML::ExtractContent とかのようなライブラリが存在します。

技術記事かどうかを判定するのは、意外とヒューリスティックな方法でもそこそこの精度が出ます。ですが、自分にドメイン知識がある内容の 2 値分類機を作るのは難しくない (日々の生活の中でアノテーションできる) ので、ちゃんと育てていきたいですね。とまれ今は技術ワード 200 個ぐらいについて正規表現でマッチした個数で判定を行っています。

HTML を除去して
- 特に外部サービスの埋め込み (YouTube や Instagram 等) を行うと、要素や属性で誤判定される (非技術記事が技術記事と判定される偽陽性)
正規表現でマッチ
- Go とか UI とかが誤爆しまくるので単語境界を上手くやる必要がある
- 単純に \b ではダメで、スペース区切り言語文字と非スペース区切り言語文字の境界も単語境界とみなすで対応する

Slack に流す

はい。

というのをやって 2 年が経ちました

体感としてはすごく良いし、このまま継続していきます。

技術記事判定ができているので、スタッフの個人ブログをまとめて公開することもできるようになったなぁと考えています。公開したい技術記事としたくない日記とが一箇所に書かれるので、単にブログ記事を集約するだけだとイマイチなんですよねー……。ブログのカテゴリ機能等を使うことで配信する/しないを選ぶことも可能ですが、できれば書き手に手間を掛けさせずに、全自動でやりたい。

お裾分け

ブログの URL を入れると技術記事のみの title, url が帰ってくる API を用意しました。どうぞご利用ください。裏側は API Gateway + Lambda なので、意図的に殺さない限り動き続けるかなと思います。

$ curl -G -d url=https://onk.hatenablog.jp/ https://tech-entry.onk.ninja/entries | jq .
[
  {
    "title": "ソフトウェア式年遷宮という概念の歴史と、Hatena::Let での実例",
    "url": "https://onk.hatenablog.jp/entry/2021/11/28/070728"
  },
  {
    "title": "フルタイムでやる仕事を作る #wantedlydev",
    "url": "https://onk.hatenablog.jp/entry/2021/10/18/200338"
  },
  ...
]

https://github.com/onk/tech-entry

はてなエンジニア Advent Calendar 2021、明日は id:astj さんです。お楽しみに！

qiita.com

2021-11-28

ソフトウェア式年遷宮という概念の歴史と、Hatena::Let での実例

登壇

Hatena Engineer Seminar #17 にて発表しました。

hatena.connpass.com

Hatena::Letの式年遷宮 from Takafumi ONAKA

www.slideshare.net

発表内容をかいつまんで記事にも書いておきます。

Hatena::Let とは

はてラボのサービスの一つ。

僕も入社するまで、はてラボ == ベータ版、だと思ってたんですが、

ラボならではの挑戦的なサービス
運用費が会社持ちで、会社の名前で出しても良い、はてなスタッフの有志が運営するサービス、という制度

も含んでいます。

で、Hatena::Let は、現在は主に id:onk が開発している、ブックマークレットをかんたんに作成・公開できるサービスです。

ソフトウェア式年遷宮とは

初出は 2013 年の id:kenjiskywalker によるもので、このときはインフラの B/G デプロイメントのことを指していた。*1 blog.kenjiskywalker.org

JAWS DAYS 2014 Immutable Infrastracture Track のパネルディスカッションで id:antipop によって紹介されて更に広まる。*2

Immutable Infrastracture の文脈のまま、クックパッドのサーバプロビジョニング事情 - クックパッド開発者ブログやクックパッドの継続的な成長のために開発と運用が何をしてきたのか、その失敗と成功について - Speaker Deck でも語られていく。

この Cookpad TechConf 2016 での id:mirakui の発表では「作り直すことを前提にすることで長寿命化」というキーワードが出ている。2014 年に Martin Fowler が犠牲的アーキテクチャという名前を付けたものとも紐付いたのだろう。

bliki-ja.github.io

rebuild.fm

id:takahashim の発表でも、犠牲的アーキテクチャ＝式年遷宮で技術の継承を行うのだとされている。

青空文庫と式年遷宮アーキテクチャ: 青空文庫200周年に向けて from masayoshi takahashi

www.slideshare.net

2018 年、ソフトウェアを定期的に全て作り直すという拡大解釈が @edvakf により行われる。作り直せる規模にしておくというのは、マイクロサービスの流れとも合流しているんじゃないかな。

inside.pixiv.blog

2020 年、id:daiksy により、ブラックボックスになりかけている要素をリプレースする過程でドメイン知識を継承する、と意味が加えられる。

productzine.jp

といった感じで、

定期的に一部、または全てをリプレースする
リプレース時にモダンな技術にし、メンテナビリティを高める
リプレースの過程で、ドメイン知識を継承し、チームのスキルを維持する

というのが「ソフトウェアの式年遷宮」なのだろう。

「はじめからやり直したい症候群」とは違い、難しいものを難しいと認めた上で、運用し続けられる体制を維持する、というのがポイントなのだと思う。

Hatena::Letの遷宮

サービスを引き継いだので、コードベースの隅々まで把握するために遷宮しました。

なんと次の Hatena Engineer Seminar ではコードベースの隅々まで把握する方法という話をするつもりです…… https://t.co/2SPlj5LtIp https://t.co/jWCneFEoje
— Takafumi ONAKA (@onk) November 13, 2021

サービスの全貌を我が物にするためには、

システム構成を把握する
データ構造を把握する
エンドポイントを把握する

をやると良くて、*3

インフラ移行 (EC2 -> ECS)
ORM 移行 (MoCo -> ActiveRecord)
routes/controller の移行 (Ridge -> Sinatra)

とそれぞれリプレースすることで実現した。

技術選定を ActiveRecord にしたのは DB リファクタリングのためで、狙い通りにリプレース後にリファクタリングすることができた。次はフロントのリプレースや機能開発をやっていく。

まとめ

サービスを引き継ぐ際に Perl から Ruby に全て書き換えた裏側にあった目論見、つまり仕様を完全に把握するための遷宮と、遷宮時の技術選定について話した。また、定期的に (＝式年) 遷宮する必要があることも示した。

*1:当時の URL から変わっている

*2:「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - 栗林健太郎

*3:ソフトウェアアーキテクチャのためのC4モデルや知らないWebアプリケーションの開発に途中からJOINしたとき、どこから切り込むか？ / PHPerKaigi 2020 - Speaker Deck をよく意識しています

2021-10-18

フルタイムでやる仕事を作る #wantedlydev

登壇

先日 Wantedly さんのエンジニアリングマネージャー座談会に出演させていただいた。

wantedly.connpass.com

テーマは、「エンジニアリングマネージャーの課題を相談したい人が多い」「その相談パブリックにしよう」なので、自分が最近課題に思っている「変化の速度感」についてざっくばらんに会話できたらなーというのが期待だった。

イベント中には、大きく 4 つの話をしたのかな。それぞれ会話の中では話しきれなかったことも補足しつつ書いていく。

技術スタックが違うチーム
プロダクトと専門組織のバランス
専門組織を立ち上げるポイント
採用と oss-guild

技術スタックが違うチーム

リンク先を見て貰うと顕著に分かると思うけど、はてなでは、そこそこバラバラな技術スタックを使っている。

hatenacorp.jp

インフラは AWS、Google Cloud (オンプレはやっと撲滅した)。コンテナ運用基盤も ECS、k8s それぞれある。バックエンドでは Scala、Go、Perl、Python、Node。Web フロントエンドは TypeScript/React/GraphQL に統一しつつあるが、Apollo と Relay を敢えて使い分けていたりする。(基本的には Apollo Client だけど、遊べる余地のある小さなプロダクトでは Relay を使おうみたいな)

1 プロダクトの中でも複数言語が使われていて、はてなで Web アプリケーションエンジニアをやるならマルチリンガルであることは求めていくことになる。

こうなっている理由は、事業のために最適な技術を選んだ結果なんだけど、これを成立させるためにどうしているかだと、1 プロダクトの中では専門性が足りなくても、会社全体で見ると統制が取れている、にしているつもり。そのために技術選定時に DesignDoc を書いているし、サブ会があるし、はてな教科書がある。

developer.hatenastaff.com

全社で 1 プロダクトでしか使っていない技術はあまり存在しなくて、横のつながりで同期を取ったり、専門性を高めたり、入門のハードルを下げたりしている。

プロダクトと専門組織のバランス

「横のつながりで同期を取る」と言ったが、本当にそんなことが可能なのか、という話題。10 年以上、技術イベントで登壇できる程度の位置は維持できているので「可能である」と思っています。

ここの肝は情報の透明性だろう。同じインプットを入れると同じ結論が出てくるので。どのチームがいつ何をやるか、どんな課題があるかを知っている状態である。毎週やっている技術勉強会や、スタッフが発信している社内ブログ、個人/社の技術ブログ。また、サブ会の会合を通して、技術選択や、技術ロードマップの優先度、スケジュール感の共有が行われている。

情報の発信が上手い人、情報の pull が上手い人、情報のハブになるのが上手い人がそれぞれいるので回っているんじゃないかと思う。リモートシフトで少しサイロ化が進んでいるので、すべてのベースが情報共有にあることを強く認識して、是正していきたい。

プロダクト側が、会社/世間の標準から外れすぎないよう意識して行動できているチームだからというのもあるかもしれない。

全体で緩やかな意思決定をしていると、緩やかなので、意図した変化速度にならないことが多い、というのがこの体制での悩み。その気になったら3ヶ月〜半年でグイッとやれないこともないが、やれる範囲でやると1〜2年かかってしまう、という速度感です。借金を返しきることがないが、返済に困り果てもしないぐらいで生きて行けているんじゃないか。

専門組織を立ち上げるポイント

サブ会のような、プロダクト側 90%、残りの 10% で参加する、という形だと、速度感が足りないし、専門性も高めきれない。サブ会の主軸のメンバーに対しては調整して 50% ぐらい持って貰うようにしてきたが、それにも限界がある。本当に力を入れたいならハコ (組織) を作ることになる。

が、かろうじて回ってしまっている中で、どう組織を立ち上げるか、というのが僕の悩みだったが、@kawasy がサクッと答えてくれたのが表題の言葉。

片手間では解ききれない量・質の問題がそこにあることを示し、その上でフルタイムで取り組む範囲を定義して、これで何が解決するのかを言語化することで、組織としてやる価値を示すのだろう。「フルタイムでやる仕事を作る」のが僕の仕事だなーと感じた。

採用と oss-guild

こういう緩やかな繋がりで「各位いい感じに」で回せる人をどう採用するかという話。これは OSS と地続きであることを是とする文化であれば採用も育成も実現できるんじゃないかと思っている。

前職のときに書いた内容だけど、大枠で言うとこういう意思です。

クローズドソースから始めるオープンソース from Takafumi ONAKA

これをやっている人を採用するのだと書類選考から見ているし、

書類選考時に GitHub アカウントを貰ったら初手で https://t.co/yMLD9XHecn を見ています。次に継続的に手を入れているリポジトリや dotfiles、あとリポジトリ一覧を眺めて興味を引いたヤツ。
— Takafumi ONAKA (@onk) August 18, 2021

育成も含めてやっていくぞというのは社内の文化醸成として頑張っているところです。

tarao.hatenablog.com

まとめ

楽しい会だった。呼んでいただいてありがとうございます！

【PR】はてなも Wantedly さんも、積極的に採用しているのでお声掛けください！

d.hatena.ne.jp (キャリア採用中途の転職・求人 - 採用情報 - 株式会社はてなや、Twitter 等で直接お声掛けください＞＜)

www.wantedly.com

第 4 回のゲストは id:Songmu さんです。楽しみですね。 wantedly.connpass.com

2021-09-30

チームに浸透させるのが近年では難しくなっている

昨日「動いたけどチームメンバーを説得するのが面倒で、秘蔵のブランチになってしまう」って言ったけど、この気持ちはどこから出てくるのか。

分かりやすい Cons があると、反発が予想できて、その反発を解決するところまで労力を割くほどの気持ちが無いので困る。「直ちに問題になるわけじゃないが、どちらかというとやった方がいい、でもリスクもある」という選択肢を選べずにズルズルと現状維持に向かう圧力は、ある。チームの同質性が高いうちはほとんど困らないんだが、人数が増えたり、別の職種が増えたりするごとに「面倒」さはどうしても増していく。

我々の信念として以下を持ってはいるが、現状維持に向かう圧力がある中で変化を加えるのはそこそこ労力が要り、閾値を超えると変化が発生しなくなってしまう。

業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。素早く変えてもし仮にダメだったら素早く戻せばよい。

Mackerel開発チームカイゼンの旅（振り返り・モブプロ・スキルマップなど） - Hatena Developer Blog

現代の Web アプリケーションを作るのに、「PdM、エンジニア、デザイナーの 3 人で作る」というのは難しくなっていて、そもそも 6 人とか 10 人とか 30 人とかのチームでやる場合が増えています。そうすると、変化を始めるのは勢いだけでも可能かもしれないけど、やりきるのは以前より難しくなっていませんか。

この問題を倒すのに、進め方を知っていると楽になるよね、というのが今日の主題です。

進め方 is 問題解決や意志決定、組織変革のプロセス。

例えば

トヨタ生産方式の 5S
- 躾が含まれている
問題解決の 8 ステップ
- 目標設定や計画、定着させることが含まれている
ADR (Architecture Decision Records) や Design Doc
- 意志決定をテンプレ化し、記録を取っていく
インセプションデッキ
- 前提を丁寧に揃える役に立つ
DACI フレームワーク
- 意志決定に関わる人の役割を明示することで推進力を出す
コッターの 8 段階プロセス
- 変革に当たっての 8 段階プロセス
ADKAR モデル
- 同じく変革のための 5 段階プロセス

辺りを僕は意識しながらやっているかしら。

勢いだけでは導入することができない場合があり、そういうときはちゃんと変革をマネジメントしなければいけない、という意識で物事を進めていくと、導入できない・最後までやりきれない問題を倒しやすくなる。前提を丁寧に共有しようねとか、共有用のいいテンプレートがあるよとか、やりきるところまで含めて計画しようねとか。

横から細かい Cons を刺され続けて疲弊する場合に対しても、DACI フレームワークを使うと、「Informed ですよね？」と封じ込めることができて (というか、すべてに対応する必要は無い、Approver が判断できれば十分である、という意識に全員を持って行くことができて)、進めやすくなることもあるかもしれません。

定着までをゴールに見据えていると、外部登壇を経由して社内により効率的に広めるとか、意識を向けるための定例の場の設定とか、横展開のためにあらかじめ楔を打っておくとか、そういう動きをやっていくこともあります。

開発合宿のようなイベントを企画して、勢い MAX で乗り越えるという手段を執ることもありますね。

この話はどこに向かっているのか

変化が大変になっているという事実があることを認識する
進め方が世の中にあることを認識する
- 試しに使ってみて、馴染むものを普段使いする

というのをやっていけると、変化を起こしたり、浸透させたりするのが難しい問題に対応しやすくなる。

んだけど、その上で「丁寧に進めなければいけないことは分かっているがめんどくさい」は乗り越えられないので、こういうエンジニアのエンパワーメントを一緒にやってくれる人や、丁寧に進めなくても良いチームを一緒に作っていく人を強く募集しています。

まずはカジュアル面談からいかがでしょうか。

meety.net

2021-09-30

branch を寝かせるときは TODO.txt を置いている

タイトルがすべて。

思いついたら手を動かしてしまう性質なので、秘蔵のブランチを大量に持っている。

秘蔵のブランチというのは、動いたけどチームメンバーを説得するのが面倒とか、テスト書くのが面倒とか、だいたい動いているけどやりきるのが面倒とかで main にマージしていないヤツ。例えばフレームワークのメジャーバージョン上げるブランチとか、依存ライブラリをより一般的/現代的なものに交換するブランチや、より良い設計を思いついたのでガッと書き換えてしまうブランチが多いかな。

だいたい 1 年所属していると 80 ブランチぐらい溜まるので、週 1 つ以上は何か作りかけてる計算になる。

ローカルブランチの数、プロンプトに出しておくかな……。(秘蔵のブランチが溜まってる
— Takafumi ONAKA (@onk) March 28, 2017

もちろん自分でいいアイディアだと思っているから実装しているので、何か起きたときに「こんなこともあろうかと」と出せるのが強み。脆弱性が見つかったときとか、データ量が増えたこと等で設計の悪さが発火したときとかに、スッと懐から出して、爆速で修正リリースできることがある。何かしら問題が起きた後だと、多少の体裁の整ってなさは些細な問題になるので、エイってやりやすい。

秘蔵のブランチというとカッコイイ（？）んだけど、要は仕掛かり品です。在庫。完成させていないのでリリースできない、JIT 生産方式で嫌われるヤツ。稀に繰り出せると最高に気持ちがいいので、ついやってしまうんだよね。。

秘蔵のブランチが火を噴くときがきた
— Takafumi ONAKA (@onk) October 28, 2013

で、一晩グワーッて書いた後に、完成していないと数日〜数ヶ月寝かせることがあって、そういうときは続きは何をやろうとしていたのか完全に忘れているので、最後に TODO.txt を commit しておくようにしている。

例えば

本家が対応していないので issue #xxx が解消するまで待ち
xxx の場合にエラーになるので対策する必要があるんだが、そういう仕組みがまだ存在していない
model の a-h 始まりまで終わったので、残りの 200 ファイルやる
先に Route53 に移管する必要があった……。
xxx の場合の動作確認まだしていない
全員のローカル環境を更新させるのが面倒

とかとか、完成させていない理由を書いてある。*1

TODO を書いておくことによって、次にブランチ一覧を眺めたときに「これ何だっけ」というのが減って、1 年後でも続きの作業ができるというのがオススメポイントです。異動/退職するときも、あと何をしたらいいのかが書いてあるので、続きを人にやってもらいやすい。

秘蔵のブランチを片っ端から _wip 付けて push するお仕事をしている(ゴミの押し付けとも言う
— Takafumi ONAKA (@onk) March 30, 2018

ブランチに限らず、あまりヨシヨシできていないリポジトリは TODO.txt を書いて commit しておくと、次に作業をするときに当時の記憶が蘇りやすい。僕はよく TODO.txt を読んで脳のワーキングメモリに乗せた後に git reset HEAD~1 して作業開始しています。

*1:1 行で済むことは滅多に無いです！それぐらいの障害物なら完成まで持って行ける

今年の目標

最近のお仕事

Ruby との関わり

最近の私生活

箱庭諸島2

今年買ったもの

ケータイ

スマートホーム関連

机周り

今年のオススメマンガ

完結したもの

1 巻良かったので買ってくれ