あとは、サムネイルを貼り忘れたり意図しない画像がサムネイルになったりして困ることもよくある。
http://b.hatena.ne.jp/entry/s/:url のページに行く。
この次がめちゃくちゃわかりにくいのだが、記事タイトルの枠の右上にマウスを持っていく。すると「適切な情報に変更」という tooltip と編集アイコンが現れる。
クリックすると以下のモーダルが現れるのでタイトルを修正することができる。
なお、この操作はブックマークをしたユーザーであれば誰でも行えるようだ。
サムネイルを更新したい場合はブログ記事を更新したのち、このモーダルの左下にある「情報を更新する」をクリックする。数分から数十分で最新の情報を取得してくれる。
なお、この操作はブックマーク先のページのオーナーでないと行えない、らしい。（オーナーという概念をよくわかっていないが）ログインしているユーザーのはてなブログでないと行えないようだ。
iOSDC 2018 に参加しています。また、3日目の9/1に『サブスクリプションサービスにおけるIn-App Purchase再考』という発表をしました。
サーバサイドエンジニアとして In-App Purchase (IAP) とその他の決済手段を開発・運用してきた経験をもとに IAP を考えなおす、という内容です。
今回は比較する軸を「決済ゲートウェイ」としました。
決済ゲートウェイとしての機能・性能・サービス・サポート面においてAppStoreを選ぶことにはどのようなメリット・デメリットがあるのか。また、IAPを選択する前、運用する中ではどのようなことを考慮しなければいけないのか。これらの観点について考えてみました。
15分で63枚というボリュームになってしまったので発表では以下を省略しました。気になる方は資料でご確認ください。
気になったのでセルフまとめ
反応見たところ明らかな間違いもなかった…はず。そのうえで共感ありつつ聴衆の埒外からの知見も共有できたみたいで良かったです。感想を呟いてフィードバックをいただけるのは本当にありがたいです。
3回ほど通しで練習してみた経緯が以下です
23分→18分→15分
かなり巻いたのに23分かかった初回で絶望し、内容を削ることを決めました。とはいえ調査したことや大事な補足を削ってしまうと資料価値が薄れると思ったので、Google Slides の機能でスライドを残したまま非表示にするようにしました。
朝イチの発表、大学の薄暗い大教室、100人近い聴衆が各々のPCを見つめて待機している… という状況で自分の出番を待つのが耐えきれませんでした。なのでトークの頭で話そうと思っていたアイスブレイク的な話題を開始前にしました。
具体的には発表で使った Logicool Spotlight をデモ的に紹介し、「おお〜」という声が一斉に上がったのは嬉しかったです。
なお本日のトークでは Logicool Spotlight を使用します。これでCOOLなプレゼンをするぞ!!!https://t.co/rrXAyqErYr (アフィリエイトリンクです)
— 広島の粗大ゴミ (@ohbarye) 2018年9月1日
これを使うことで壇上を自由に動いたダイナミックなトークができた（かもしれない）。持っててよかった Logicool Spotlight。
全体を通じてトークテーマの幅が広く、新しいものを取り入れたり新しい人を取り込んだりすることに非常に好意的であるという印象を受けました。
自分も iOS のことやコミュニティのことはまったくわかっていなかったのですが、勢いで申し込んだCFPが通ったのでけっこう驚きました。
発表者にフィードバックを促すように運営の方が仰っており、実際に参加者の方がそのように動いているのに感銘を受けました。
自分も発表に対していくつも質問をいただいたり、発表後に用意された Ask The Speaker テーブルに追加の質問・議論をしたい方が訪れたり、非常に双方向的なコミュニケーションができて良かったです。（発表前に登壇者に向けてスタッフから「質問を受けたら必ず復唱をお願いします」という気遣いがあったのも Good）
参加者が過ごしやすい環境が揃っていました。
出る前はアウェイだろうな〜と思っていましたが開催者の長谷川さんからもフォローいただけてそこからも"ホスピタリティ"を感じました。
大丈夫！きっとお楽しみ頂けると思います！
— 長谷川智希 / とむぞう (@tomzoh) August 7, 2018
自分がイベントを開催するときにも参考にしたいことが沢山あった。
疲れたときに座れる場所があってすごい
理工キャンパスがかっこいい
早稲田理工キャンパスの""工業感""がとにかく最高じゃんという気持ちになったんだけど共感を得られるだろうか #iosdc #ナイスダクト pic.twitter.com/lgDaruz1Gc
— 広島の粗大ゴミ (@ohbarye) 2018年8月31日
今日も良かった #iosdc #ナイスダクト pic.twitter.com/2vXLmz05vw
— 広島の粗大ゴミ (@ohbarye) 2018年9月1日
休憩時間に懸垂ができるタイプのカンファレンス #iOSDC pic.twitter.com/VoGTyyImA2
— 広島の粗大ゴミ (@ohbarye) 2018年9月1日
緒方恵美さんがすごい
ということで、開催前はけっこうナーバスになっていたものの発表/参加して良かったな〜という気持ちになりました。運営の皆さん本当にお疲れ様です。
第5回 Roppongi.js に参加し、『続・貢献できるOSSの見つけ方 -How to find "Good First Issues"-』というタイトルでLTをしました。
リンク付きの原稿はこちら https://ohbarye.github.io/slides/2018/roppongi.js-5/
（近々 Netlify をやめる可能性はある＝＝この URL は死ぬかもしれない）
GUI作るぞという点で有限実行できてよかった（Firebase云々はさすがにてきとうすぎた）
そこそこ好評いただけたので面倒くさがっていたGUIもちゃんと作ろうという気持ちになった。バックエンドはfirebaseとかでドーンとやればバーンとできるやろ!!
— 広島の粗大ゴミ (@ohbarye) 2018年6月26日
また、web上で見知っていたが現実では見たことなかった方々を見ることができてよかった。特にazuさん、橋本商会さんは公開情報で助けられていることもあるので感謝したい気持ちはあったが話しかけられなかったのは残念。
Logicool SPOTLIGHT を初めて登壇で使ってみた。"掴み"で面白がってもらえたようで良かった。PCから離れて歩き回ることで聴衆の集中力を高める"先生"の技が使えるようになる。
一方、会場トラブルで投影状況がデグレしたので肝心のスポットライト機能自体は今回はあまり活きなかったかもしれない。
「頻繁に登壇するわけでもないから個人で買うには高い」と思う場合、会社の経費で購入すると社員で適宜使い回せて良さそう。
皆さんも Logicool SPOTLIGHT を買って COOL なプレゼンをしましょう！！！ https://t.co/rrXAyqErYr #roppongijs
— 広島の粗大ゴミ (@ohbarye) August 23, 2018
最近 js のミートアップ行くとほぼ必ず GraphQL と React Native の話題が出るので毎回 @mtsmfm と @hotchemi へのポインタを貼ってる #roppongijs
— 広島の粗大ゴミ (@ohbarye) August 23, 2018
Flow 使っている人もぜんぜんいなくて TypeScript の話は多めという感触
— 広島の粗大ゴミ (@ohbarye) August 23, 2018
発表内容にも次にやることを実現可能性無視して書いたが、その内容についてイベント参加者からフィードバックをもらえてよかった。
というわけで、さらなる改善をやっていったうえで『真・貢献できるOSSの見つけ方〜完結編〜』という話ができると良い
まともな（信頼できる）ステージング環境を用意できてるウェブ系企業、肌感だけど5%以下という印象
— たにみち (@ttanimichi) 2018年8月20日
このツイートを見て弊社は5%に入れるかどうかを考えてみたいと思った。
が、そもそも何をステージング環境と呼ぶか、何をもって"まとも（信頼できる）"と言えるのかわからないのでそこから考えてみた。
本記事中では「アプリケーション、システムの動作や表示を試験するための環境」とする。
試験の対象は機能・性能・外部連携などの多岐にわたる。また、試験を行うのはサーバサイド開発者、クライアントサイド開発者、デザイナー、カスタマーサポート、プロダクトマネージャ etc.…と、これも多岐にわたる。
少なくとも自分の感覚では、以下を実現できるのであれば良い開発体験（Developer Experience）が得られる、"まとも"なステージング環境を持っていると言えそうだ。
1. ステージング環境のアプリケーションが接続するステージング環境用データベースは、本番（production）のデータベースと同期されている
2. 任意のブランチを独立した専用のインスタンスにデプロイすることができる
3. 特定のブランチは常に特定の名前でステージング環境にデプロイされる
4. ステージング環境のアプリケーションのプロセスコントロール、環境変数設定は開発者が自由にできる
5. 外部連携の試験ができる
6. 本番相当の負荷試験ができる
7. multirepo構成の場合、協調して動作するアプリケーション群の任意のステージング環境から任意のステージング環境に接続できる
8. monorepo構成の場合、feature branchをそのままステージングクラスタにデプロイできる
9. アプリケーションの振る舞いに作用する環境変数を production と揃えている
RAILS_ENV=production で動かしていること他にもあるかもしれないがとりあえずの思いつきを列挙してみた。弊社 Quipper はすべて実現している（はず）
上述の要件のうち幾つかは互いにデッドロックしあってしまうので、たった1つの環境で補うのは不可能だ。そのため各々に適した環境のセットアップが必要になる。
Quipper で実現している環境を用途ごとにまとめた。
主にカスタマーサポート（非開発者）が利用している。開発者もデバッグ用途でよく使う。
主にQAを行う環境。
本番相当のデータをあえて用意せずに環境固有のデータを用意している理由は以下。
特に外部連携が曲者で、連携先が社外のベンダーでコントロールできないことがほとんどになる。
詳しくは非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog参照
うーん、思いつく範囲では"まとも"は満たせていると思うが、どうだろうか。
こういうのはあれば当たり前と思ってしまうが、そもそも体験したことが無いと存在の可能性にすら思い当たらないことがしばしばある。自分も現職に入ったときは「こんな便利な仕組みあったのか！」と思ったし、次の職場で何かが欠けていたら「開発体験が悪い…直さねば」と思うだろう。
なので、皆さんの考える"まとも"の(必要|十分)条件があれば教えて欲しいところ。
詳細の確認および参加申し込みは以下のページからお願いします。早速定員になってしまったようなのですが増枠も検討中です。
いちエンジニアリングマネージャとして、エンジニアリングマネージャ・エンジニアリングマネジメントに興味・関心・知見・意見・失敗談・一家言ある方々と話してみたい。
イベント概要欄に書いたとおり、（少なくとも自分が観測しているWebサービス業界隈では）エンジニアリングマネージャ職について統一された定義・見解を見ることはほとんどありません。
エンジニアリングマネージャというポジションは組織が成熟する過程において戦略的または偶発的に発生しており、会社や人それぞれによって思い描く姿やその実態・運用が異なるようです。*1
また、スタートアップ初期においては必要性が認識されることはあまりなく、CTOがその役割を兼ねていることも多いようです。*2
「いわゆるマネージャやテックリードとは何が違うのか？」という問を見るにつけて、プロダクトマネージャという役割が流行り始めた当初の「プロジェクトマネージャと何が違うのか？」と言われていたことを思い出します。
しかしプロダクトマネージャ職は今でこそ product manager conference や product manager meetup が開催されるほどにその専門性と職務内容の認知が高まり、組織ごとの知見や工夫・失敗談を交換する機会も多いものの、エンジニアリングマネージャは未だそれには及ばないと考えています。
そうした機会は少ないながらも、このポジションに就いている方はそれなりにいるようなので、各々の創意工夫や悩み、ドラマがあるのでしょう… 僕はそんな方々のうまくいった成功談、また、それ以上に失敗談も聞いてみたいのです。
…という思いを込めた tweet。
Engineering Manager Meetup 存在しないならやってみようかな
— 広島の粗大ゴミ (@ohbarye) 2018年7月20日
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 のやり方や研修関連の情報はそれなりに見かけるし、参考になる書籍もある。
評価は結構ナイーブな話題なのでオンラインで公開するのが難しい側面も含んでいると思う。
ネガティブフィードバックをどうするか。パフォーマンスの低い社員の扱い。解雇の権限（日本だとまず無さそうではあるが…）
また、エンジニアリングマネージャにメンバーの給与を決定する裁量があるのかどうか。
功利主義的に考えたとき承認制は本当に効用が費用を上回るのか？
意味ある承認、会社や法的に義務付けられた承認があるのも勿論知っていますが、世の中の89%ぐらいの承認って無意味ではないのだろうか。残り11%で失敗したときのリスクがでかすぎるというなら払うべきコストだと思うが…。承認業務が比較的少ない現状でもそんなことを考えている。
またまた『Work Rules!』を持ち出すと「マネージャは部下に権限を与えまくって、不安になるぐらいでちょうどいい」という話が良かった。
人々がマイクロマネジメントに走るのは、組織のパフォーマンスに関する不安を緩和するためだ。つまり、他人の行動を絶えず監督し管理していると気が楽になるのだ──これは、本質的には彼らの自信のなさを表しているにすぎない。そうすることで、マイクロマネジャーは自分が管理をしている（役立っている）という幻想に浸れる。もうひとつの動機は、スタッフの能力に対する信頼の欠如だ。マイクロマネジャーは仲間が『やります』と言っても、彼らが職務を見事にやり遂げる、あるいは責任を果たすとは考えないのだ
書き始めたら一言触れる程度では終わらなかったうえにあまり unobtrusive にもならなかったので、わりと話したいことがある気がしています。
ということで改めて応募お待ちしています。
Slack group も用意しました。“コミュニティのSlack廃れがち“問題はあると思うので何か面白いアイデアが欲しいところ
ちょうど読んでいる最中なので引用元が Work Rules! ばかりになってしまった
いつもお世話になっている TechRacho の以下の記事を読んでいて気になったこと、思ったこと。
TechRacho（自社技術ブログ）に関連したあれこれ、2年毎日更新してみて感じたこと
これだけ見てくれる人が増えたらちょっとは採用応募が増えるかなと期待しているのですが、アクセス増のわりには増えないですねー。TechRachoはわかるけど、BPSのことはよく知らないしなー、なのかしら。あるいは、コンテンツ配信だけだと、どんな技術者がいて、どんな開発をしているのかわからない、なのかしら。それとも両方？
おー、そういうものか…と驚きもあり、最近の自分の考えを補強するものでもあった。（確証バイアス）
TechRacho とは運営趣旨がだいぶ異なるものの、弊社もQuipper product team blogをやっている*1。PVは TechRacho にはまだまだ及ばない。
ブログのおかげで採用大成功していますと喧伝するほどではないし、そもそもブログ単体に採用への直接的貢献を求めていない*2けれども、以下のような事例が増えてきた。（定性的意見）
2の方の意見からいくつかピックアップして要約する：（N=2）
現時点では全くもって定量的ではないのだけど、採用を目的の一つに置くような会社ブログでは会社固有の事情や文脈やユースケースにフォーカスした方が良さそうだと考えている。というか自分ならそういうブログが読みたい。
以下は会社ブログに限らない話：
内容の"質"が高いことは大事だが、技術単体に関する話はたいてい公式のドキュメントを読めば良く、ものによってはすぐに陳腐化してしまう。
だからこそ、ある文脈でなぜそれを選んだか・どうやって抱えている問題を解決したか・またはなぜそのやり方で解決できなかったか・これからどうしていくか等々を語ることや、その実践のログを通じて発信者（会社・個人）の思考様式を外部から評価できることに価値があると考える。
「ユースケースや文脈抜きでの技術選択や評価を盲信するな」という意見にも通じる。
*1:同blogの趣旨については なぜこのブログは「エンジニアブログ」ではなく「プロダクトチームのブログ」なのか - Quipper Product Team Blogを参照
*2:AIDCAメンタルモデルによる Attention（注目）→Interest（興味）→Desire（欲望）辺りは期待している
以下のような 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 を参照