Re: 技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience - @kyanny's blog
技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience - Speaker Deck 「品質と速度はトレードオフの関係ではなく、比例する」みたいな話を見聞きするたびにモヤッとするのが、 本当に短期的な話、三十分以内に変更してデプロイしたい、みたいな「短期的」な話であれば「テスト書いてる時間はない」は間違いではない、一分将棋みたいなギリギリのプロジェクトに従事している人のことを考えろ（？） 「ちゃんと設計せずに作った（そうせざるを得ない外圧があった）→ちゃんと設計する余裕があれば負債を溜め込まずに済んだ」みたいに聞こえるが、十分な時間があったら負債が出ない高品質の設計ができたとでも思っているのか？ ↑に書いた「三十分か一時間か」みたいなギリギリの状況ならいざ知らず、日・週単位でスケジュールが組まれてるソフトウェア開発プロジェクト
二要素認証（TOTP）のトークンをどこに保存するか問題 - @kyanny's blog
2 要素認証に 1Password を使うのはよく考えてから | はったりエンジニアの備忘録 AWSの多要素認証に1passwordが使えたけど使っちゃダメだと思った話 - Qiita TOTP のトークンを 1Password に保存するのはセキュリティ強度を弱めるので良くない、という話は知ってたので避けてたのだけど、ちょっとよくわからなくなってきた。 Windows（具体的には社有のSurface Pro）上の1passwordとiPhone上の1passwordの両方でMFAの二段階目をクリアできたということは、もうこの2段階目は特定のデバイスを持っていることに依存しないということだ。僕のIDで他のデバイスに1passwordをインストールすることができれば、さらにそのデバイスでも2段階目をクリアできる。「AWSのパスワード」と「特定のスマホ（デバイス）」ではなく、「AWSのパスワー
Re: cakesサービス終了のお知らせ | cakesからのお知らせ | cakes編集部 | cakes（ケイクス） - @kyanny's blog
cakesサービス終了のお知らせ｜cakesからのお知らせ｜cakes編集部｜cakes（ケイクス） エクスポート機能くらい言われなくても作れよnote株式会社のソフトウェア開発者たち。エンドユーザー向けに提供する品質で作るのが厳しくても、テキストと画像をぶっこ抜いて s3 あたりに置くスクリプトくらい書けるでしょ。事業判断として人的リソースも投入しない、という以外にも「古いシステムなので把握してる人がいない」みたいな理由もあるのかもと邪推するが、だとしても難しい仕事ではない。 やはりエクスポート機能もないサービスに大事なテキストを預けるのはリスキーだ、という意見もちらほら見かける。noteが選ぶに値しないプラットフォームであることには同意するが、それはエクスポート機能がないからでもクリエイターへのリスペクトが感じられないからでもない。クリエイター？クソくらえだ。Twitter でちょっと
組織デザイン - @kyanny's blog
たしかこの記事で存在を知って、そういえば組織について論じたり組織作りをしたりしてる割に「組織とは何か」について体系的な知識を持ってないし勉強したこともないなと気づいたので 2018/07/04 に買った。なんでこの記事を見つけたのかはよく覚えてないけど、スターかブクマがついてブログ見に行ったら書いてあったんだと思う。 j5a.hatenablog.com ものすごく良い内容。文章は平易だけど情報密度が高くてちょっとずつしか読み進められない。なのでまだ読み終えてない。 この本を読むまで知らなくて、この本から学んだとても重要だと思うことは、 組織は「分業」と「調整」を行うためにある 調整の方法には、問題が発生しないようにあらかじめ行う「標準化」と、問題が発生したあとに対処するための「ヒエラルキー」がある 長年、組織ってものができてくるとなぜ調整が増えるのだろう、面倒くさいのに、と不思議に思って
技術顧問ブームの流れを汲んだエンジニアリングマネージャーブーム、という考察 - @kyanny's blog
というか、（かなり偏見を含む）空想。 blog.kyanny.me 「技術力が衰えつつあるおじさんエンジニアのキャリアパスをどうするか」という命題に対して業界は「経営がわかるCTO」「技術顧問」などの回答を示してきた しかしCTOも技術顧問も椅子に限りがあるため、業界は新たな受け皿を必要としていた 業界の平均年齢が上がり、他の業種と同様におじさんエンジニアたちは「管理職」になることを受け入れなければならなくなったが、この業界は「マネージャー（管理職） = 悪」という価値観が根強いため、業界人たちの意識変革が必要だった そういうもろもろの問題意識やら個々人の思惑やらが交錯した結果、どこかの誰かが「エンジニアのマネージャーは無能な管理職なんかじゃない！『髪の尖った上司』なんかじゃないんだよ！」といいだし、キャリアに不安を抱えていたおじさんエンジニアたち（と、そんなおじさんの背中をみてぼんやりと
採用基準についてトレードオフスライダーを使って議論した - @kyanny's blog
開発者の中途採用をやっていくにあたり、「チームの誰もが採用担当」というポリシーでインタビューやコードテストのレビューなどをみんなでやってきたが、「どういう人を採用すべきか？」についての認識が合わなくなってきたと感じたので、認識を合わせるために議論の場を設けた。議論を進めるためのツールとしてトレードオフスライダーを使ってみた。うまくいくか確証はなかったが、事後にアンケートをとったら過半数からフィードバックをもらえ、全て好意的だった（五段階評価で4と5が半数ずつ）ので、まぁまぁうまくいったのだろうと受け止めて、もろもろ公開します。 使った資料はこちら。 以下、意図とか進め方とか学びとか。 最終的な目標は「採用基準についての認識が合うこと」なのだが、全員の認識・見解が一致することなどありえないと思っていて、むしろ各人の認識がどれくらいズレているのかを明らかにすることのほうが重要だと思っていた。そ
GitHub のメール通知を見直した - @kyanny's blog
流量の多いリポジトリを Not watching にするだけではさすがに絞りが甘すぎたので、もう一段絞った。 ポリシーを変えたポイントは Pull Request は mention の有無にかかわらず全て通知を受け取っていたが、流量も内容も流し読みするのは無理になったので、見るのを諦めた 浮いた時間を Pull Request を能動的に見にいく時間にあてたい mention されていないイシューコメント等も同様なので、見るのを諦めた その代わり mention されているものを見落とさないようにしたい カスタマイズしたのは GitHub の Notification settings で以下を変更 Watching の Email 通知をオフにした Participating のみ通知を受け取る Email notification preferences の Pull Request
Quipper に入社して丸4年が経った - @kyanny's blog
blog.kyanny.me 一年経ってしまった。いろいろあった。一年前はオフィスのことしか書かなかったので、今年は自分のことだけ書く。 Engineering Manager 今年の1月に会社の組織変更があり、 Engineering Manager というポジションができた。国単位・技術分野単位などで開発者をいくつかのチームに分け、それぞれに Engineering Manager がいるという、いわゆるふつうのピラミッド型の組織になった。で、俺が東京オフィスの Web Developer チームの Engineering Manager になった。 上司（CTO）から話があったのは去年の11月頃だった。プロダクト開発チームがグローバル全体で50名くらいになってきて、そろそろ CTO 一人で見るのは無理がでてきた、そこでローカルに Manager をつくり各種の業務や権限を委譲していき
デプロイ作業の属人化を徹底的に排除したい話 - @kyanny's blog
ここ数カ月、デプロイとリリースについて、同僚や友人と議論したり雑談したりする機会が数多くあった。そんな折に、友人から Facebook のリリースエンジニアリングチームについて教えてもらった。曰く、 Facebook ではリリース作業を専門とするチームがあり、そこのメンバーは開発ブランチのコミットとそれに付随する ITS の議論を精査した上でリリースに値する変更をリリースブランチへ cherry-pick するのだそうだ。 2012/07/25 追記 Facebook のリリースエンジニアリングについては Facebook のリリースと文化 - Kato Kazuyoshi を参照のこと cherry-pick は無いわー、というのは置いておくとしても、リリースという極めて重要な作業が特定の人たちに委ねられている点に恐ろしさを感じた。嫌だと思うのはなぜなのかしばらく考えて、デプロイ作業の属
エンジニア立ち居振舞い: ルーズボールを拾う - @kyanny's blog
お題「エンジニア立ち居振舞い」 チャットや課題管理システムを使って非同期コミュニケーションをしていると、誰かに向けて発せられたけど誰も応答していない、ルーズボールのようなメッセージができてしまう。こういうのを見かけたら、できるだけ拾うようにしている。 Quipper の Slack には #development という公開チャンネルがある。開発者が開発にまつわる話をする場で、開発者向けの #general チャンネルといった位置づけだ（なお、開発者向けの #random に相当する #slackoverflow というチャンネルもある） #development は公開チャンネルなので、開発者だけでなく、営業・マーケティング・カスタマーサポートなどの部門で働く人たちも参加している。時折、彼らがシステムのことで何か困っていて、開発者の手助けが必要なことがある。そういうとき、誰でも構わないか
私のソースコードの書き方 - @kyanny's blog
note.mu なるほど自分も同じような感じでやっているなぁ、と思った。もうちょっと詳しく書くと、 まず変更しようと思っている部分の周辺のコードを読んで、「ここらへんをいじればよさそう」と当たりをつける（当たりのつけかたにもいろいろあるのだが後述） 土地勘を養ったところで具体的な変更の仕方を考える。必要に応じて紙に下手くそな図を書いたり、考えを箇条書きにしたり、実際にコードを試しに変更してみたりする この方針でいけそう、と道筋が見えたらいよいよコードを書き始める。細かい単位でコミットするかどうかは場合によるが、少なくとも git add はこまめに行う（エディタの undo でせっかく書いたコードを失わないため） 道筋が見えなかったり、プロトタイプ的に書いたコードが望み薄そうだったら潔く諦める。煮詰まっていることを自覚して、コーヒーを買いにいったり、オフィスの外を散歩したりして頭をリフレッ
なぜ Quipper のエンジニア採用面接には必ず候補者の同僚となる人が参加するのか - @kyanny's blog
ohbarye.hatenablog.jp Quipper のエンジニア採用には必ず候補者の同僚となる人*1が参加する。いつからかはわからないが自分が候補者として採用面接を受けた昨年の7月頃にはそうなっており 2015年の5月か6月ごろ、俺がエンジニア採用活動に関わるようになったタイミングで、強く希望してそういう仕組みにした。なぜか。 いちスタッフとして、自分が意見を表明する機会が無いまま、自分の同僚になるかもしれない人が選考・採用される状況に納得できなかったから。そして、自分自身は採用活動に関わるようになって不満を感じなくなっても、他の人は相変わらず同じように感じているかもしれない、そういうアンフェアな状況にも納得できなかったからだ。 なので、採用活動に関わるべき人たちに対して、採用活動における各種の情報ができるだけ多く共有されるように、少しずつ仕組みを変えていった。例えば: 試用期間を
Atom実践入門 - @kyanny's blog
著者の id:tomoya さんから本をいただきました。ありがとうございます。 d.hatena.ne.jp 宣伝に偽りなし。 Atom の操作方法から内部構造まで丁寧かつ徹底的に解説した一冊だ。 Chrome DevTools しかり、 Web Components しかり、 2016 年に書籍で読む価値のある Web 技術の話であり、それぞれ単体で一冊の本になってもおかしくないトピックだ。それをテキストエディタの解説書でカバーしてしまう発想には脱帽する。 本題のテキストエディタの解説部分も抜かりない。まず目次からしてひと味違う。操作の名前（日本語）と対応するコマンド名（英語）が併記されているので、目当ての操作を見つけたらコマンドパレットにコマンド名を入力してすぐに使うことができる。さらに各項目の解説ページにはそのコマンドを呼び出すデフォルトのキーバインドも掲載されているので、メニューか
How Quipper tests software - @kyanny's blog
Excelなテスト仕様書をMarkdown/GitHub/CircleCIに移行した話 - トレタ開発者ブログ という記事を読み、「最初から Google Spreadsheets を使えばいいのに」と思った。 実際 Quipper では一年以上前からテスト仕様書として Google Spreadsheets を使っていて、それなりにうまくまわっている。 サービスごとにテストケースは異なるので、こういうスプレッドシートが複数ある（インドネシア・フィリピン・メキシコで展開している Quipper Video / Quipper School 用がそれぞれと、日本で展開しているスタディサプリ用が一つ）これは Quipper Video 用で、 Quipper Video は利用者数の関係からインドネシア向けのアプリケーションに対してテストを実施するので、テストシナリオは英語で書かれているがとこ
エクストリームプログラミング - @kyanny's blog
「ペアプログラミング」を読んだ流れで読み始めた。「古典をたしなむのも悪くなかろう」という気持ちで読み始めたが、古典どころか現在進行形の内容ばかりだった。 いきなり具体的な話からはじまり、思想的な話は後ろの方でやっとでてくる構成は意外だった。 実践のための本なのだから実践的な、行動に繋がる内容に重きをおくのは当然だしそれを先に持ってくるのには好感を持ったが、思想的背景抜きにいきなりプラクティスやプリンシプルを延々と紹介されると説教くさく感じてしまい、途中で一度投げ出しそうになった。 しかし後半に入るにつれて面白くなっていって、「なぜ私は XP をやるのか」という個人的な動機などの話に至りすべてが繋がる、というまるで映画を観たような読後感だった。 XP についてなんとなく知っているつもりになっていただけだったので、いろいろ気づきもあった。最も印象に残ったのは、「XP は TDD を必須とはして
最近読んだもの - @kyanny's blog
情報処理2015年12月号特集記事「20年目のRubyの真実」インタビュー-情報処理学会 「rspec の should_not be とかだいぶ予想外」「マクロが無くても rsepc を書けるので（Lisp の）マクロは無くてもいいかな」のあたりが面白かった。「ふううのコンピューターの CPU コア数がこんなに増えたのも、メモリが案外増えなくて未だにボトルネックになってるのも予想外」というあたりは非常に興味深かった。そして昨年末の RubyKaigi で mruby 触ろうと思ったものの仕事が忙しくてすっかり忘れていたので今年こそ触ろう。 持ち場で頑張ることを誇りにしている人の話 - ベンチャー役員三界に家なし 本題とずれた話だが、おれは「真面目で自分の持ち場意識が高い人」こそが組織を官僚化させると思っている。その人個人に罪はない。真面目で（良いことだ）、与えられた仕事に忠実で（良いこと
RubyKaigi 2015 - @kyanny's blog
二日目の夕方からと三日目の二コマ目から参加した。 この一年ほどは Ruby/Grape,Rails よりも CoffeeScript/Backbone,Marionette を書いてる時間の方が圧倒的に長く、仕事以外でも特に面白いものを作らなかったので、トークに応募しなかった。準備せず手ぶらで参加するだけのカンファレンスは、ラクだけどやっぱりどこか物足りないなと思った。もっとも、この冬の忙しさでは準備できたとも思えないが。 今年は「Ruby にこだわる」姿勢というものを感じるトークが多かった（自分が聴いたものの中では）特に mruby は、数年前に出てきたときは全然ピンとこなかったけど、今年はなぜか「Rubyist ならパフォーマンスが出ないからとかいって Go なんか選ぶんじゃなく Ruby でパフォーマンスを出す方法を考えるのが筋だろ？」と言われているような気がして身が引き締まる思いだ
第二次CTOブームから技術顧問ブームへの流れについての考察 - @kyanny's blog
「エンジニア組織のトップには最も技術力が高い人が立つべき」という価値観にもとづいて、多くのWeb事業会社においてエース格のスターエンジニアがCTOないし類似の肩書と地位と権力を持つポジションに就いたゼロ年代のムーブメントを第一次CTOブームと呼ぶことにしよう それを踏まえてテン年代に入り、「スタートアップのような小さな組織ではそれで問題なかったけど、組織が大きくなり成熟していく過程では、経営者の視点からエンジニア組織をマネジメントできる人がいないと組織力を発揮しきれないのでダメだよね」という価値観を後ろ盾に、そこそこ年齢を重ねて気力体力的に現場の第一線がつらくなったりライフステージの変化によって以前に比べパフォーマンスを発揮できなくなった元エースや、技能ではエースに及ばないがそれ以外の格（社歴など）で勝るシニアな人材などの思惑が重なり、「次のキャリア」としてCTOという役職に再びスポットが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
tig でいま見ているコミットをブラウザで開く - @kyanny's blog
Wantedly Open API を試してみた - @kyanny's blog
