valid,invalid

関心を持てる事柄について

はてなブックマーク側でタイトルやサムネイルが残念だったときの修正方法

具体例

f:id:ohbarye:20180902231427p:plain

f:id:ohbarye:20180902231456p:plain

あとは、サムネイルを貼り忘れたり意図しない画像がサムネイルになったりして困ることもよくある。

修正方法

http://b.hatena.ne.jp/entry/s/:url のページに行く。

この次がめちゃくちゃわかりにくいのだが、記事タイトルの枠の右上にマウスを持っていく。すると「適切な情報に変更」という tooltip と編集アイコンが現れる。

f:id:ohbarye:20180902231710p:plain

クリックすると以下のモーダルが現れるのでタイトルを修正することができる。

なお、この操作はブックマークをしたユーザーであれば誰でも行えるようだ。

f:id:ohbarye:20180902231902p:plain

サムネイルを更新したい場合はブログ記事を更新したのち、このモーダルの左下にある「情報を更新する」をクリックする。数分から数十分で最新の情報を取得してくれる。

なお、この操作はブックマーク先のページのオーナーでないと行えない、らしい。(オーナーという概念をよくわかっていないが)ログインしているユーザーのはてなブログでないと行えないようだ。

#iOSDC で『サブスクリプションサービスにおけるIn-App Purchase再考』という発表をしてきました

iOSDC 2018 に参加しています。また、3日目の9/1に『サブスクリプションサービスにおけるIn-App Purchase再考』という発表をしました。

iosdc.jp

発表

資料

サーバサイドエンジニアとして In-App Purchase (IAP) とその他の決済手段を開発・運用してきた経験をもとに IAP を考えなおす、という内容です。

今回は比較する軸を「決済ゲートウェイ」としました。

決済ゲートウェイとしての機能・性能・サービス・サポート面においてAppStoreを選ぶことにはどのようなメリット・デメリットがあるのか。また、IAPを選択する前、運用する中ではどのようなことを考慮しなければいけないのか。これらの観点について考えてみました。

15分で63枚というボリュームになってしまったので発表では以下を省略しました。気になる方は資料でご確認ください。

  • 開発〜テストまわりの比較
  • 運用における加盟店サポートの比較

反応

気になったのでセルフまとめ

togetter.com

反応見たところ明らかな間違いもなかった…はず。そのうえで共感ありつつ聴衆の埒外からの知見も共有できたみたいで良かったです。感想を呟いてフィードバックをいただけるのは本当にありがたいです。

準備について

3回ほど通しで練習してみた経緯が以下です

23分→18分→15分

かなり巻いたのに23分かかった初回で絶望し、内容を削ることを決めました。とはいえ調査したことや大事な補足を削ってしまうと資料価値が薄れると思ったので、Google Slides の機能でスライドを残したまま非表示にするようにしました。

発表にあたって挑戦してみたこと

朝イチの発表、大学の薄暗い大教室、100人近い聴衆が各々のPCを見つめて待機している… という状況で自分の出番を待つのが耐えきれませんでした。なのでトークの頭で話そうと思っていたアイスブレイク的な話題を開始前にしました。

具体的には発表で使った Logicool Spotlight をデモ的に紹介し、「おお〜」という声が一斉に上がったのは嬉しかったです。

これを使うことで壇上を自由に動いたダイナミックなトークができた(かもしれない)。持っててよかった Logicool Spotlight。

iOSDC

全体を通じてトークテーマの幅が広く、新しいものを取り入れたり新しい人を取り込んだりすることに非常に好意的であるという印象を受けました。

自分も iOS のことやコミュニティのことはまったくわかっていなかったのですが、勢いで申し込んだCFPが通ったのでけっこう驚きました。

相互コミュニケーションを推奨/実践しててすごい

発表者にフィードバックを促すように運営の方が仰っており、実際に参加者の方がそのように動いているのに感銘を受けました。

自分も発表に対していくつも質問をいただいたり、発表後に用意された Ask The Speaker テーブルに追加の質問・議論をしたい方が訪れたり、非常に双方向的なコミュニケーションができて良かったです。(発表前に登壇者に向けてスタッフから「質問を受けたら必ず復唱をお願いします」という気遣いがあったのも Good)

ホスピタリティがすごい

参加者が過ごしやすい環境が揃っていました。

  • ノベルティがすごい
  • ランチがすごい
  • コーヒー提供がすごい
  • Wifi、電源の充実がすごい

出る前はアウェイだろうな〜と思っていましたが開催者の長谷川さんからもフォローいただけてそこからも"ホスピタリティ"を感じました。

自分がイベントを開催するときにも参考にしたいことが沢山あった。

会場がすごい

疲れたときに座れる場所があってすごい

理工キャンパスがかっこいい

緒方恵美さんがすごい

緒方恵美さんがすごい

www.youtube.com


ということで、開催前はけっこうナーバスになっていたものの発表/参加して良かったな〜という気持ちになりました。運営の皆さん本当にお疲れ様です。

#roppongijs で『続・貢献できるOSSの見つけ方 -How to find "Good First Issues" part 2-』というLTをしてきました

第5回 Roppongi.js に参加し、『続・貢献できるOSSの見つけ方 -How to find "Good First Issues"-』というタイトルでLTをしました。

リンク付きの原稿はこちら https://ohbarye.github.io/slides/2018/roppongi.js-5/

紹介したアプリケーション

github.com

https://goofi.netlify.com/

(近々 Netlify をやめる可能性はある==この URL は死ぬかもしれない)

発表に関して所感

GUI作るぞという点で有限実行できてよかった(Firebase云々はさすがにてきとうすぎた)

また、web上で見知っていたが現実では見たことなかった方々を見ることができてよかった。特にazuさん、橋本商会さんは公開情報で助けられていることもあるので感謝したい気持ちはあったが話しかけられなかったのは残念。

Logicool SPOTLIGHTが良い

Logicool SPOTLIGHT を初めて登壇で使ってみた。"掴み"で面白がってもらえたようで良かった。PCから離れて歩き回ることで聴衆の集中力を高める"先生"の技が使えるようになる。

一方、会場トラブルで投影状況がデグレしたので肝心のスポットライト機能自体は今回はあまり活きなかったかもしれない。

spo

「頻繁に登壇するわけでもないから個人で買うには高い」と思う場合、会社の経費で購入すると社員で適宜使い回せて良さそう。

話題

発表内容にも次にやることを実現可能性無視して書いたが、その内容についてイベント参加者からフィードバックをもらえてよかった。

というわけで、さらなる改善をやっていったうえで『真・貢献できるOSSの見つけ方〜完結編〜』という話ができると良い

"まともなステージング環境"を考える

このツイートを見て弊社は5%に入れるかどうかを考えてみたいと思った。

が、そもそも何をステージング環境と呼ぶか、何をもって"まとも(信頼できる)"と言えるのかわからないのでそこから考えてみた。

ステージング環境とは

本記事中では「アプリケーション、システムの動作や表示を試験するための環境」とする。

試験の対象は機能・性能・外部連携などの多岐にわたる。また、試験を行うのはサーバサイド開発者、クライアントサイド開発者、デザイナー、カスタマーサポート、プロダクトマネージャ etc.…と、これも多岐にわたる。

まともであるために、ステージング環境で実現したいこと

少なくとも自分の感覚では、以下を実現できるのであれば良い開発体験(Developer Experience)が得られる、"まとも"なステージング環境を持っていると言えそうだ。

1. ステージング環境のアプリケーションが接続するステージング環境用データベースは、本番(production)のデータベースと同期されている

2. 任意のブランチを独立した専用のインスタンスにデプロイすることができる

  • feature branch を GitHub などに push するとCIでテストが実行され、テストがパスした場合のみステージング環境が自動的にデプロイされる

3. 特定のブランチは常に特定の名前でステージング環境にデプロイされる

  • 後述する Edge, Develop などの環境が常に存在し、継続的にアップデートされることを保証する

4. ステージング環境のアプリケーションのプロセスコントロール環境変数設定は開発者が自由にできる

5. 外部連携の試験ができる

  • 外部連携先の保持するデータとこちらのデータに一貫性がある
  • この要件は外部連携先のステージング環境に依存するので本番相当のデータを使えないことが多い

6. 本番相当の負荷試験ができる

  • 本番相当のアクセス数・データ量・サーバースペックがある
  • 常時その状態にする必要はなく、特定のタイミングでその状態にできればよい

7. multirepo構成の場合、協調して動作するアプリケーション群の任意のステージング環境から任意のステージング環境に接続できる

  • たとえばクライアントサイドのSPAとサーバサイドのAPIエンドポイントを同時に開発しているとき、前者の feature branch に対応したステージング環境から後者の feature branch に対応したステージング環境に接続したい

8. monorepo構成の場合、feature branchをそのままステージングクラスタにデプロイできる

9. アプリケーションの振る舞いに作用する環境変数を production と揃えている

  • Rails でいえば RAILS_ENV=production で動かしていること
  • 開発中の機能を production では隠す、staging では表示する、みたいな feature flag は揃えなくてよい

他にもあるかもしれないがとりあえずの思いつきを列挙してみた。弊社 Quipper はすべて実現している(はず)


ステージング環境の種類

上述の要件のうち幾つかは互いにデッドロックしあってしまうので、たった1つの環境で補うのは不可能だ。そのため各々に適した環境のセットアップが必要になる。

Quipper で実現している環境を用途ごとにまとめた。

本番で発生したバグや問い合わせを再現したい

主にカスタマーサポート(非開発者)が利用している。開発者もデバッグ用途でよく使う。

  • 本番相当のデータ+本番にデプロイされているのと同じバージョンのアプリケーションが動作する環境
  • 弊社では Edge 環境と呼んでいる

開発中の最新の動作を見たい

  • 本番相当のデータ+develop branch のHEADのアプリケーションが動作する環境
  • Edge 環境とは異なるデータベースを用意している
  • 弊社では Develop 環境と呼んでいる

次回リリースされるバージョンの動作を見たい

主にQAを行う環境。

  • 環境固有のデータ+Develop環境のある時点でfreezeしたバージョンのアプリケーションが動作する環境
  • 弊社では Release 環境と呼んでいる

本番相当のデータをあえて用意せずに環境固有のデータを用意している理由は以下。

  • 外部連携をテストする(外部のデータベースと一貫性を保つ必要がある)
  • テストデータが自動的に上書きされないようにする(current streak とか連続ログインボーナスとかの試験をしたい)

特に外部連携が曲者で、連携先が社外のベンダーでコントロールできないことがほとんどになる。

開発者、非開発者がある機能のレビューをしたい

詳しくは非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog参照

  • 本番相当のデータ+各開発者の feature branch のアプリケーションが動作する環境
  • 弊社では Staging 環境と呼んでいる…が正確ではなく、Feature Staging などと呼んだ方が良さそうだ

結論

うーん、思いつく範囲では"まとも"は満たせていると思うが、どうだろうか。

こういうのはあれば当たり前と思ってしまうが、そもそも体験したことが無いと存在の可能性にすら思い当たらないことがしばしばある。自分も現職に入ったときは「こんな便利な仕組みあったのか!」と思ったし、次の職場で何かが欠けていたら「開発体験が悪い…直さねば」と思うだろう。

なので、皆さんの考える"まとも"の(必要|十分)条件があれば教えて欲しいところ。

Engineering Manager Meetup をやります

詳細の確認および参加申し込みは以下のページからお願いします。早速定員になってしまったようなのですが増枠も検討中です。

connpass.com

動機

いちエンジニアリングマネージャとして、エンジニアリングマネージャ・エンジニアリングマネジメントに興味・関心・知見・意見・失敗談・一家言ある方々と話してみたい。

"エンジニアリングマネージャ"の曖昧性

イベント概要欄に書いたとおり、(少なくとも自分が観測しているWebサービス業界隈では)エンジニアリングマネージャ職について統一された定義・見解を見ることはほとんどありません。

エンジニアリングマネージャというポジションは組織が成熟する過程において戦略的または偶発的に発生しており、会社や人それぞれによって思い描く姿やその実態・運用が異なるようです。*1

また、スタートアップ初期においては必要性が認識されることはあまりなく、CTOがその役割を兼ねていることも多いようです。*2

「いわゆるマネージャやテックリードとは何が違うのか?」という問を見るにつけて、プロダクトマネージャという役割が流行り始めた当初の「プロジェクトマネージャと何が違うのか?」と言われていたことを思い出します。

しかしプロダクトマネージャ職は今でこそ product manager conference や product manager meetup が開催されるほどにその専門性と職務内容の認知が高まり、組織ごとの知見や工夫・失敗談を交換する機会も多いものの、エンジニアリングマネージャは未だそれには及ばないと考えています。

そうした機会は少ないながらも、このポジションに就いている方はそれなりにいるようなので、各々の創意工夫や悩み、ドラマがあるのでしょう… 僕はそんな方々のうまくいった成功談、また、それ以上に失敗談も聞いてみたいのです。


…という思いを込めた tweet


話すテーマについて

Connpass ページに書いたとおりオープンスペース形式でやりたいと考えています。LTやプレゼンの準備は不要です。その代わり「何を話してみたいか」のタネが大事です。

興味が沸くように、あるいはイメージが湧くように、Connpass に書いたテーマのいくつかについて一言ずつ触れてみたいと思います。

「自分はこんなことを話してみたいな」ということを書きます。(議論の方向性を決定づけないように自分の意見は控えめで)

エンジニアリングマネージャの仕事内容

少なくともコードを全く書かないポジションではなさそうだと思うものの、どのぐらい書いている、あるいは書くことが期待されているのか。オレは毎日書いている…お前らはどうだ…???

エンジニアの上司はコードを書ける人間であるべきか?という問をよく見るが、個人的にはどちらの視点から見るかによって意見が変わりうる。

例えば自らの立場がメンバーだとしたら「マネージャはコードを書けなくても良い」と答える。コードを書けなくても頭の切れるマネージャのもとで働いたときの経験からそう思っている。エンジニアリングや目標設定に関するフィードバックは同僚から貰うこともできる。

だが、もし立場がマネージャであるときは、コードを書ける人間であるよう自分が自分に要請する。前述した自分の元上司ほど頭が切れるわけではないので、メンバーのエンジニアの抱える問題や挑戦をより深く理解するためには一定のエンジニアリングスキルは間違いなくあったほうがよい。

ちなみに『Work Rules!』によると

グーグルの採用の信条は、エンジニアリング部門のマネジャーは最低でも自分のチームのメンバー並みの技術力を備えていなければならないというものだった

エンジニアリングマネージャの仕事、キャリアパス、求められるスキル

この辺は先述の、エンジニアリングマネージャ何する人かという問いの答え次第でもある。

また、エンジニアリングマネージャを続けた先に何があるのか?VP of Engineering なのか CTO なのか分からないが、それがオレたちの望んだ未来なのか...???

テックリードなど他職種との違い

エンジニアリングマネージャからピープルマネジメント除いたらテックリードになる、みたいな会社もあるようです

エンジニアリング組織論

はい

本の感想を語り合う場所であっても良さそう

給与

エンジニアリングマネージャの給与の話だけでなく、マネジメントするメンバーの給与に関して裁量があるのか、どのように決定しているのか。そのあたりが気になります。

また、各社エンジニアリングマネージャの給与をそれ以外のメンバーに比べて高く設定しているのだろうか?

個人的には"マネージャ"と付く名前の役職にならないと給与が頭打ちになるような会社は嫌だという思いがあります。

自分が新卒入社したSIerで、エンジニアリングスキルを伸ばすよりもプロジェクトマネジメントスキルを伸ばした方が評価されるような状況にて悩んだ経験から強くそう思っています。

ちなみに U.S. 全体で$108,849 per yearが推定平均給与 by Indeed (8/13時点)

https://www.indeed.com/jobs?q=Engineering+Manager&l=United+States

Indeed Japan だと給与どころか募集があまり多くなく、推定平均給与の記載もない

https://jp.indeed.com/%E6%B1%82%E4%BA%BA?q=Engineering+Manager&l=Japan

エンジニア採用

会社によっては採用もやるようだ。

自分も採用活動に関わっているが、エンジニアリングマネージャだからやっているとか、エンジニアリングマネージャだから採用権限があるわけではない。

そういえば、マネージャに採用権限を与えるのはアンチパターンだと『Work Rules!』にはある。

採用に関する権限をマネジャーに手放してもらう必要がある。前もって言っておかねばならないが、グーグルが新たに雇うマネジャーはこれを嫌う! マネジャーは自分のチームを選抜したがるものだ。ところが、意欲に満ちたマネジャーでさえ、人材発掘の作業が長引くと採用基準をゆるめてしまう。


マネジャーに採用決定を任せると、チームのメンバーに対して彼らの権力が大きくなりすぎてしまう

評価、育成、1-on-1

1-on-1 のやり方や研修関連の情報はそれなりに見かけるし、参考になる書籍もある。

評価は結構ナイーブな話題なのでオンラインで公開するのが難しい側面も含んでいると思う。

ネガティブフィードバックをどうするか。パフォーマンスの低い社員の扱い。解雇の権限(日本だとまず無さそうではあるが…)

また、エンジニアリングマネージャにメンバーの給与を決定する裁量があるのかどうか。

許可より謝罪 権限とか承認とか

功利主義的に考えたとき承認制は本当に効用が費用を上回るのか?

意味ある承認、会社や法的に義務付けられた承認があるのも勿論知っていますが、世の中の89%ぐらいの承認って無意味ではないのだろうか。残り11%で失敗したときのリスクがでかすぎるというなら払うべきコストだと思うが…。承認業務が比較的少ない現状でもそんなことを考えている。

またまた『Work Rules!』を持ち出すと「マネージャは部下に権限を与えまくって、不安になるぐらいでちょうどいい」という話が良かった。

人々がマイクロマネジメントに走るのは、組織のパフォーマンスに関する不安を緩和するためだ。つまり、他人の行動を絶えず監督し管理していると気が楽になるのだ──これは、本質的には彼らの自信のなさを表しているにすぎない。そうすることで、マイクロマネジャーは自分が管理をしている(役立っている)という幻想に浸れる。もうひとつの動機は、スタッフの能力に対する信頼の欠如だ。マイクロマネジャーは仲間が『やります』と言っても、彼らが職務を見事にやり遂げる、あるいは責任を果たすとは考えないのだ


書き始めたら一言触れる程度では終わらなかったうえにあまり unobtrusive にもならなかったので、わりと話したいことがある気がしています。

ということで改めて応募お待ちしています。

connpass.com


Slack group も用意しました。“コミュニティのSlack廃れがち“問題はあると思うので何か面白いアイデアが欲しいところ

https://join.slack.com/t/engineering-manager/shared_invite/enQtNDEyMjM2NzY3OTY4LWY5NjgwMzVhMGM0MDUwZDE5OTgxNjE3MTQxMjc5NGM0YjRmMGQ4ZDYwYzVmNjdlZmRkMzAxZDQ1NWYyM2ViMWY

参考

ちょうど読んでいる最中なので引用元が Work Rules! ばかりになってしまった

*1:要出典

*2:要出典

会社ブログでは固有の文脈・ユースケースにフォーカスした話を読みたい

いつもお世話になっている TechRacho の以下の記事を読んでいて気になったこと、思ったこと。

TechRacho(自社技術ブログ)に関連したあれこれ、2年毎日更新してみて感じたこと

これだけ見てくれる人が増えたらちょっとは採用応募が増えるかなと期待しているのですが、アクセス増のわりには増えないですねー。TechRachoはわかるけど、BPSのことはよく知らないしなー、なのかしら。あるいは、コンテンツ配信だけだと、どんな技術者がいて、どんな開発をしているのかわからない、なのかしら。それとも両方?

おー、そういうものか…と驚きもあり、最近の自分の考えを補強するものでもあった。(確証バイアス)


TechRacho とは運営趣旨がだいぶ異なるものの、弊社もQuipper product team blogをやっている*1。PVは TechRacho にはまだまだ及ばない。

ブログのおかげで採用大成功していますと喧伝するほどではないし、そもそもブログ単体に採用への直接的貢献を求めていない*2けれども、以下のような事例が増えてきた。(定性的意見)

  1. 面接時に「ブログで知りました」「ブログ読んで応募しようと思いました」と言ってくれる
  2. 最近入社された方が「ブログも入社を決める一因となった」と言ってくれる

2の方の意見からいくつかピックアップして要約する:(N=2)

  • 普通は見ることができない社内のやりとりを見られることで、どんな雰囲気で仕事をしているのかがイメージできて親近感が持てた
  • 情報発信をしている企業は結構あるので、どちらかというと量より質が大事
  • 採用ページや Job Description はどうしても抽象的な話になるので実務ベースの話の方が参考になる

現時点では全くもって定量的ではないのだけど、採用を目的の一つに置くような会社ブログでは会社固有の事情や文脈やユースケースにフォーカスした方が良さそうだと考えている。というか自分ならそういうブログが読みたい。


以下は会社ブログに限らない話:

内容の"質"が高いことは大事だが、技術単体に関する話はたいてい公式のドキュメントを読めば良く、ものによってはすぐに陳腐化してしまう。

だからこそ、ある文脈でなぜそれを選んだか・どうやって抱えている問題を解決したか・またはなぜそのやり方で解決できなかったか・これからどうしていくか等々を語ることや、その実践のログを通じて発信者(会社・個人)の思考様式を外部から評価できることに価値があると考える。

ユースケースや文脈抜きでの技術選択や評価を盲信するな」という意見にも通じる。

*1:同blogの趣旨については なぜこのブログは「エンジニアブログ」ではなく「プロダクトチームのブログ」なのか - Quipper Product Team Blogを参照

*2:AIDCAメンタルモデルによる Attention(注目)→Interest(興味)→Desire(欲望)辺りは期待している

必要なときだけ Polyfill.io のCDN から polyfill を読み込むようにする

以下のような script tag を HTML の最初の script tag として埋め込む。

<script>
(
  function(doc){
    if([].find&&window.fetch)return;

    var firstScript = doc.getElementsByTagName('script')[0];
    var scriptToInsert = doc.createElement('script');
    scriptToInsert.src='https://cdn.polyfill.io/v2/polyfill.min.js?features=Array.prototype.find,fetch';
    firstScript.parentNode.insertBefore(scriptToInsert, firstScript);
  }(document)
)
</script>

無名関数の1行目で polyfill が必要かどうかを判定する。

必要であれば、cdn.polyfill.io から polyfill を得るための script tag を document に埋め込む。

doc.getElementsByTagName('script')[0] より前に insert しているのは polyfill が読み込まれる前に script が実行されるのを防ぐため。


Polyfill.io については https://polyfill.io/v2/docs/api を参照