valid,invalid

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

Engineering Manager Meetup #2 をやりました & 第3回の告知 #em_meetup

Engineering Manager

Engineering Manager Meetup #2 を開催しました。

engineering-manager-meetup.connpass.com

前回は開催直後に熱と勢いだけで6,744字の雑文を書いてしまったので、今回は開催から約2週間経ってクールダウンした状態で振り返り記事を書いてみました。結果なんと5,044字に収まり、約25%の削減に成功です。

@aomoriringoさんにより振る舞われた至高のハム

3行まとめ

  • 第1回に引き続き盛り上がりを見せたことで再現性があるとわかった
  • 回を重ねることやBYOB*1など、主体的参加を促す工夫ができそう
  • 第3回はプレゼンありの形式でやります。2018-12-14(金) connpass ページはこちらです

Engineering Manager Meetup とは?

イベント開催の動機や趣旨については Engineering Manager Meetup をやります - valid,invalid を、第1回のようすについては Engineering Manager Meetup #1 をやりました #em_meetup - valid,invalid をご参照ください。

当日のようす

@beppu01 さんがまとめてくださった togetter や、参加者の皆さんによるブログをシュッと貼っておきます。

togetter.com

書いてくださった皆さん、本当にありがとうございます！（漏れていたら申し訳ありません、お伝えいただければシュッと足します）

OST再考

第1回と同じくOST（オープンスペーステクノロジー）でのディスカッションを採用しました。OSTをご存知無い方は OST（オープン・スペース・テクノロジー）｜キーワード｜HUMAN VALUE をご参照ください。

さて、第1回にて同方式を実施した結果が掛け値なしに最高だったわけですが、果たしてその結果に再現性があるのかどうか。その疑問に答えるためにEngineering Manager Meetup第2回もOSTを採用しました。

結論から言うなれば、再現性は有り寄りの有りでした。

「OSTは何について話し合うのかを参加者主導で決めるうえに、ファシリテーションも何もかもが参加者に委ねられています。なのでこの会が有意義なものになるかどうかは皆さん次第です」

この前説を毎度しておりますがこれは本当にその通りで、Engineering Managementやその周辺領域に関心や情熱があり、互いに意見を交わしたりファシリテーションをいとわない方が集まった時点で結果が約束されました。

印象に残った話

Engineering Managerをどう育てるか

@otoyo0122さんがファシリテーターとなったテーマ。こちらに僕も参加しました。

EM.FMでも語られていた話題だったのでpodcastをオススメしつつ、Engineering Managerが何をやっているのか、何が楽しいのかを伝えないことには始まらんなという話をしました。

とはいえ、技術の話をするのと全く同じように語るわけにもいかないよな、という指摘も出ました。特に"失敗談"。ポストモーテムとして語られることにとても価値がある一方、チームやメンバーの話をする場合それを聞いた当事者がどう思うかに気を配る必要があったり。（解決したならまだしも、「ローパフォーマーに困っている」「チームの雰囲気が悪い」みたいな現在進行系の話だと余計にきつそう）

Engineering Managementの話題は人に関わるセンシティブなところがあるので一歩間違えたりすると特定の人を傷つけたりするおそれがある。そのために気後れしている部分も少なからずあるのではないか、という雑談で悩み相談みたいなことができたのも良かった。

また、マネージャとしてのオンボーディングにも話が移り、「あなたは○月✗日からマネージャです、特にトレーニングも支援もないけどがんばりましょう！」みたいなやり方で成功すると思っているとしたら正気でないという突っ込み。社内に先達がいないのならマネージャ研修やコンサルタント・技術顧問登用などを使ってでもEngineering Managerの立ち上がりはしっかりサポートすることが大事。

エンジニアリングマネジメントの勉強法

このセッションに参加された@progrhymeさんのブログから引用します。

このトピックには私を含め5名の人々が集まったのですが、どうやら私のように「エンジニアリングマネジメントを学びたい」という人が多く集まったようです。 どの人もマネージャーになって1年未満ということでした。

勉強法としては以下のような方法が挙げられました:

  • 結論 「EM Meetupに来続ける」

😂

まぁーーーーーー、そうなんですよねぇ…！

僕の周囲もお手本みたいなものがあったわけでも人に教わったわけでもなく、どうにかして「知ってる人に聞いてみたい」という思いでEngineering Manager Meetupを始めたのでした。OSTを選んだのも自分が聞きたいことを知っている（かつ情熱がある）人に聞けるから、です。

おかげで色んな情報が入ってくるようになりはしましたが唯一解の存在しない問題ばかりなので、今でも射撃しつつ前進中です。

お前ら（Engineering Manager）の転職

お前らというか俺たちなのでは…ｗ

このセッションには不参加だったのですが、@aomoriringoさんが書いてくれた模造紙にはすごくわかりが深いワードがならんでいます。

詳しくはEngineering Manager Meetup #2に飛び込んできた。 - どこぞのエンジニアなマネージャーだった人のブログ。をどうぞ。

Engieering Managerもしくはそれに近いポジションでやっている業務が果たしてポータブルスキルなんだろうか〜という話があったが、自分の最近の考えはこんな感じ：

だし、それがポータブルなものになるかどうかは、月並みながら自分次第と捉えている。（が、同じジョブタイトルでもおそらくぜんぜんやっていることが異なる可能性がある…例えばめちゃめちゃ社内政治とかをメインにやっている人とは抱えているものが違う）

「マネージャをやめてプレイヤーに戻りたくて…」と言って門戸を叩く人はいるが「マネジメントをやりたくて！」と言いながら来てくれる人がいない問題。採用をやっている中でもこれはよく聞くところだが、掘り下げると各々が携わっている"マネジメント"にはとてもばらつきがある。そこを見逃すと噛み合わなくなりそうだな〜と思ったり。

その他にもいろいろ触れたいテーマはあるのですが長くなりすぎるのでこのあたりで。

総評・運営反省

前回の“”経験者“”がテーブルのファシリテーション等でリードしたり、BYOB (Bring Your Own Beer) スタイルで「飲み食いしたいものは各自持参」としたことで参加者がイベントを作っている感じが出ていたように見えました（途中の買い出しとかは文化祭ぽかった）。おかげでこのイベントでなら開示して大丈夫だという“”心理的安全性“”が醸成され、前回を上回るような“”"熱い“”"テーマが多数産まれたのかもしれません。

BYOBの結果、人よりかなり多くお金を出してくださった方もいたと思うのですがそのあたりが曖昧な感じになってしまったのは反省です。この場を借りてお礼申し上げます🙇

また、やっぱりOSTのあとに懇親会があると良いですね。そして懇親会があるならやはり金曜開催が良い！

オフ会のすすめ

上述の通り、"Engineering Managementやその周辺領域に関心や情熱がある"方さえ集えばいくらでも本イベントの再現はできます。なので、「OST良かった」ないし「参加したかったけど行けなかった」という方はぜひイベント外でもオフ会をやってみてほしいですね！

第3回はプレゼン形式

初回・2回と続いてOSTをやったのですが第3回はプレゼン形式を試してみます。

engineering-manager-meetup.connpass.com

形式は違えどOSTのときと変わらない主体的参加をしてくれる方々が集まってくれることを期待します。主体的参加のイメージ：

  • 発表内容・テーマについて登壇者にフィードバックを行う（イベント内外問わず）
  • 発表内容・テーマについて参加者同士で議論する
  • 発表内容・テーマについて考えた内容をTwitterやブログに公開する

こうした行動を起こすことでイベント全体での学びが最大化されれば良いなという思いがあります。さらに盛り上げていくぞ！ウォーッ

*1:Bring Your Own Beerの略。好きな飲食物を好きなだけ、参加者に用意いただくスタイル

エンジニアのチーム構成・組織構成の潮流、プロジェクトに付くかプロダクトに付くか

Engineering

海外と日本でのソフトウェア開発職の文化を振り返ってみた – reyabe – Medium を読んだ。

全体としてとても面白く読ませていただいた中で、特に気になるところがあったのでそれに関する所感を書いてみる。「エンジニアのチーム構成・組織構成」というパートだ。

ちなみに、どちらが良い悪いみたいな話でもなければ同記事に対する異論反論でもない、ということは初めに強調しておきます。

ヨーロッパの開発チーム構成

同記事の「エンジニアのチーム構成・組織構成」に以下のようにある。

それに対し、ヨーロッパの開発チームはよりプロジェクト・プロダクトを実現するための一時的なタスクフォースという意識の方が強いと思います。あるプロジェクトが完了して次に進む際にメンバーがシャッフルするのも普通で、場合によってはプロジェクトではなくタスク単位で、あるタスクをこなすスキルを持つエンジニアが必要であればその人が一時的にチームに加わるという移動の仕方もあります。

「おおー、それでうまく回る…のか？」というのが第一印象だった。

というのも、プロジェクトベースで開発するこのスタイルは僕が受託開発をやっていたときや、現職でかつて採っていたスタイルだが、デメリットを強く感じるようになり止めたものだったからだ。*1

プロジェクトベースの開発のデメリット

プロジェクトベースの開発のデメリットに関する私見。初めに書いた通り、良い悪いを論じたいわけではなく、こうしたデメリットをどう扱うのかが気になっている、という記事なのでメリットについては省略する。

長期的観点の不足

一般的に言えば、プロジェクトベースでの開発はリリース以降に起きることに対する長期的な観点が不足しがちになる。プロジェクトを終わらせることがチームの達成すべき目標であり、それ以外を優先するインセンティブが低くなるからだ。

長期的な観点の例は、運用・(技術的|プロダクト)負債・アーキテクチャなど、製品が継続的に改善・成長しつづけるためには避けて通れないが、初期開発のタイミングではある意味"ごまかし"がきくところ。*2

DevOpsを実践する現職においては、開発したものの運用は自分たちで行っているために起きにくい問題ではあった。

しかし前職のSIerで案件・プロジェクトベースで働いていたときは納品第一でいっときの完成を迎えたものの、運用において取り返しのつかないコストを払う羽目になった例も幾つか見た。

「短期的には安くつくが、長期的には高くつく」問題にどう対処しているのか気になるところ。

余談だが、システム開発における"外注"も短期的には安くつく（かもしれない）が長期的には高くつく可能性の高いものだと個人的に思っている…。このあたりは『エンジニアリング組織論への招待』にもより詳しい説明があるので深掘りしたい方はどうぞ。

適切な契約の交渉と納品物のクオリティを監督する能力が、社内に存在しない場合、仮に一時的に満足のいく関係を築けたとしても、長期的には、蓄積された取引コストを引き受けることになります。

もう一点余談だが、長期的観点という名目でのオーバーエンジニアリングは同記事中での指摘と繋がるものがあるかもしれない。

そもそも運用は？

これは単純な疑問で、そもそも開発したものの運用はどのように扱われるのか気になる。

受託開発における保守案件のようなプロジェクトが始まり、nヶ月単位でまた解散と集合を繰り返すのだろうか？

ビジネスとの分断

プロジェクトが発生するまでの流れを超大雑把に考え、

起案・企画 → 見積・予算確保 → 開発開始

という流れになるとすると、開発者が参加するのはどこからか。最右端の開発開始からだとすると、すでに作ること・作るものが決定してしまっていたりしないだろうか。

その場合、開発開始〜開発中にプロジェクトの根本的な欠陥に気づいたり、見積・予算の不確実性に振り回されたりしたときに「やることは決まってしまっているので覆せない」みたいなことが起きないだろうか。

そうしたなかでビジネスサイド（という言い方はあまり好きではないが）とエンジニアリングチームのパワーバランス（という言い方もあまり好きではないが）において前者が強すぎる事に対し、エンジニアリングチームから不満があがったりするかもしれない。

話が飛躍するかもしれないが、職能別にチームを区切ることで、開発者をテンポラリな労働力と捉える"外注感"や職能間の対立構造を生みやすいというのが個人の経験としてはある。

合わせて読みたい：

「開発チーム」で本当に大丈夫か考える - Speaker Deck

個人的観測範囲での潮流

個人的観測範囲においては、事業会社で製品開発しているところはプロジェクトベースをやめてメンバーを長期的に固定した職能横断型チームを作る方にシフトする潮流があると感じている。（それだけに上記記事の内容に意外性を感じた次第）*3

ざっくり言うならばタイトルの通りプロジェクトに付くかプロダクトに付くか、というのが一番の違いとも言える。

現職では上記のような問題（＋その他の幾つかの問題）に対処するため、特定のプロダクトの特定の機能・サービスについては個別のチームを設けることにした。このチームの中にWeb engineer, Designer, Product owner, iOS/Android Engineer, Data analystなど各々の専門性を持つメンバーを集め、長期的にプロダクトや機能を磨き込み、ビジネス上の目標を達成することを目指す、という形だ。

チームに対する帰属意識は高い一方で「何をするために集まっているのか」を中心に据えているため、記事中にある「日本の開発チーム」（以下に引用）とはやや趣が異なるかもしれない。

日本の開発チームはより参加しているメンバーによってアイデンティティを持つ団体になっている印象を受けました。何をするために集まっているのかより誰が集まっているのかの意識の方が高い気がします。チームの人と飲みに行ったり、チームビルディングのアクティビティーがあったり、社員旅行で基本チームメンバーとしか行動しなかったり、よりチームというユニットが中心になっている事が色々なところから伝わってきます。日本は元から上下関係を大切にする文化もあり、チームに関してもメンバーを育てる・メンバーの面倒を見る・チームの先輩から学ぶという意識が強いと感じました。

とはいえプロジェクトベースの開発とは異なるのは明らかだ。「ひとまとまりで動くことで意思決定の質と速度を最適化できるチームの最小単位」*4による開発は、SquadやTribeといった概念を用いて説明されるSpotifyモデルにも当てはまる。

これについてはWantedly社の記事などが大変参考になる。

SquadとOKR - 開発チームが無駄なく高い成果を出すために大事にしていること | Wantedly Engineer Blog

full-stack agile - Team Organisation: Squads, Chapters, Tribes & Guilds

また、近年隆盛を見せるMicroservicesの実践に伴うチームのマイクロ化においても達成したい組織・チーム構造はSpotifyモデルと似通ったものがあるのではないかと思う。

「これらはヨーロッパでなくアメリカでは？」という突っ込みがありそうだが、紹介した記事のタイトルでも「海外と日本でのソフトウェア開発職の文化」と二分してたので、まぁそこは大目に…。

所感なのでオチもないが、プロジェクトベースでも上述のような問題をうまく解決する手法があれば知りたく、もしくは上述のデメリットをプロジェクトベースでの開発に帰するのは誤りだといった指摘も歓迎です。「うちはこうしているよ」話も更に大歓迎です

*1:全てが同時多発的に頻発していたわけではなく、ぼんやりと感じつつあったものが爆発する前に舵を切った

*2:もちろんプロジェクト終了後に変更や運用が発生しない製品については関係のないことだ

*3:これに対する課題もあるのは承知の上 https://daipresents.com/2017/cross-functional-team/

*4:https://www.wantedly.com/companies/wantedly/post_articles/134301 より

半年間、自分を騙しながらアウトプットに積極的になってみた

この半年間はソフトウェアエンジニアとしてのアウトプットに積極的になるよう意識的に行動してみたので振り返ってみます。長くなってしまったので3行でまとめるとこんな感じです。

  • 成長と刺激を求めて OSS contribution や登壇やイベント運営を頑張ってみた
  • 成長したかはわからないが、知り合いが増えたりして刺激を受けることが多くなった
  • これからも続けていくが持続可能なペースにしたい

だいたい2018年上半期の話ですが一部期間外の話もあります。

なぜアウトプットを増やすか

唐突ですが、現職では日常の業務を漫然と続けるだけで成長するフェーズは終わったのかなぁと思っています。新しく何ができるか、何をすべきか、もしくはしなくてよいのか。昨年、転職から2年が経過したときにそんなことをぼんやり考えていました。そのときに書いた記事 (now = ohbarye.hired_at.since 2.years) から意識が高まっている箇所をセルフ引用します。

ドメイン知識以外のところでもっと勝負したいとかいう気持ちがある。

Be the worst の精神を忘れたくない、技術系のコミュニティから刺激を受けたいという思いもある。直近では勉強会やカンファレンスでの登壇や週1~2での副業を積極的にやってみるというのも卑近な方法だろうか。

また、乃木坂太郎氏の『医龍』という漫画が好きなのですが、話中の天才医師浅田の言葉にも刺激を受けました*1。

“腕ってやつは、上がってると感じてなきゃダメなんだよ。維持してると思ってんなら、落ち始めてるってことだ。”

上述のお気持ちだと抽象的すぎるので、達成したかったことをもう少し言語化すると以下の2点に集約されます。

成長する

"成長"の定義は「僕が理想とするソフトウェアエンジニア像と現在の自分とギャップが埋まること」。*2

刺激を得る

無限不断努力をできるタイプではないので自分の""やる気スイッチ""を押せる手段が欲しい。*3

やったこと

上述の「成長する」「刺激を得る」が"目的"で、以下は"手段"です。

1. OSS contributionを増やす

実は最近あまりやれていないのですが GitHub を見る限り2018年内だと50本ぐらい pull requests を出したようです。

また、その過程で貢献できるOSSを探せるツール (goofi)を自作したり、このツールに関する発表が出来てよかったです。

しかしこの点についてはまだまだです。継続的に特定のプロダクトに関わっているわけでもなく、小さな修正を重ねても「contribution できたぁ〜」と「だからなんだ…？」の間を意識が行き交っています。もちろんコードを読んだり書いたりする機会が増えているのはポジティブなのですが、contribution を通じてでなくても良いのかもと思ったり。もちろん、contribution するに越したことはないのですが。

2. GitHubのプロフィールを充実させた

「自分や他人が良い/欲しいと思うツールやライブラリを作って公開しているエンジニア」に憧れがあります。なので GitHub のプロフィールを見て「やっていき手かな？」と思う兆候の1つに star が集まっているレポジトリが並んでいること、というのがあります（ohbarye基準*4）。

さて自分のがどうかというと、1年ぐらい前は kpt-bot が10 stars 集めるぐらいだったのがややマシになりました。

ohbarye (Masato Ohba) · GitHub

image

充実させるためには手を動かして何かを作らなければいけないので、とても小さい課題でも解決するツールを書けないか考えたりするようになりました。まぁ、たいてい既存の組み合わせでなんとかなってしまうのですが… それでも作ったものについてまとめたり紹介してフィードバックを貰えるととても刺激になります。

3. 登壇を増やした

プレゼンに関するメモをちまちま更新し、自分のプレゼンは改善されていると自己暗示をかけていかないと不安を抑えられないぐらいには人前で話すのが苦手です。

心の中で「やるぞ!!」と強く決意しても、すこし放っておくだけですぐにやる気が""無""になってしまうのを知っています。

なので会社の GitHub issues で「登壇やっていき表明」というイシューを立ててお気持ちを表明し、2018年度上半期の目標にも設定しました。ohbarye は退路を自ら断ったのだ…。

image

あとは強い人たちが言っている（と勝手に思っている）「勉強会の類は登壇するときぐらいしか行かない」の真似。プレゼン枠があるのにそれを避けて一般参加枠で申し込むのを止めました。

成果としては上半期で10本ぐらい登壇経験を積むことができました。「LTばかりだ」とか「やっている人はもっとやっている」とか、そういうセルフ突っ込みが止むことはないですが、2017年末までは一度もやったことがなかったのに比べるとだいぶ前進したと思ってはいます。

Presentations by Masato Ohba - Speaker Deck

image

得意領域ではない frontend を伸ばすために勉強した JavaScript 周りを JS コミュニティで発表したり、1回もiOS開発やったことないのに iOSDC に登壇したり、だいぶコンフォートゾーンを出たつもりです。

4. イベントを主催した

Quipper Product Meetup

7月に Quipper Product Meetup というイベントを開催し、この運営を担当しました。

StudySapuri Product Meetup を開催しました #sapurimeetup - Quipper Product Team Blog

会社とプロダクトのブランドやバリューによる成果ですが、定員120名に対して事前申し込みが400件超えしていた人気イベントを仕切るというのはなかなかのプレッシャーでした。

エンジニアコミュニティで知り合った方なども来訪してくれて「お、こういう風に人が繋がっていくのは楽しいかもしれない」と感じられたのが後続の Engineering Manager Meetup などにも繋がったと思います。

Engineering Manager Meetup

つい先日、Engineering Manager Meetup というイベントを主催しました。動機や感想は以下の記事にまとめています。

Engineering Manager Meetup をやります - valid,invalid

Engineering Manager Meetup #1 をやりました #em_meetup - valid,invalid

テーマがテーマだけに上述したような「ソフトウェアエンジニアの成長や刺激という狙いから少しずれるかも」と企画した当初は思っていたのですが、それは間違いでした。

僕が尊敬する、インターネットで見知っていたようなエンジニアやエンジニアリングマネージャ・CTO・VPofE、影響を受けた本の著者といった、普段生活をしているだけでは絶対に会えないような人たちと出会い、意見を交換したりすることができるようになりました。

刺激が欲しいとは言っていたものの刺激が強すぎて"熱"が出てきました。

Meguro.rb

イベントで何回かトークをさせてもらったり懇親した流れで、第19回Meguro.rbのスポンサーを Quipper がやることになりました。

僕が何もしなくてもそうなったかもしれないけど、アウトプットを出すことを通じてこういうチャンスが流れてきたこと、そこに関われたことを嬉しく思います。

5. コミュニティづくり(継続中)

Engineering Manager Meetup の Slack workspace の中でオフ会が生まれたり、色んな方が意見を交換できるようになってきました。

コミュニティやイベント運営について遥かに知見あるカルパスさんからこのようなコメントを貰えて嬉しいです。

僕が参加したイベントの中でも、カルパスさんが主催する Rails Developer Meetup は本当に素晴らしいのでこれからも背中を追っていきたいと思っています*5。

その他の細かいアウトプット

Dev.toに記事を書く

仕事で書く機会が減り気味だったので英語の練習がてら書いていました。

Masato Ohba - DEV Profile

dev.to には #showdev という「作ってみた」的な tag があり、これで自作のツールやWebサイトを紹介したり。このブログや Qiita に書くよりも like (いいね) や star が集まりやすいな、という感覚があります。純粋にリーチする数の問題とも違い、英語圏はポジティブフィードバックに前向きな気がする (暴論)

ISUCONに出た

出て惨敗しました

ISUCON8にチーム"sayotan"で参加し、予選落ち (Best Score: 23,553, 最終結果: fail) でした - valid,invalid

Open Processing

ゴールデンウィークの頃は P5.js にハマっていたので Open Processing に登録してお絵かきしたりしていた

ohbarye - OpenProcessing

アウトプットを続けてわかったこと/変わったこと

「勉強会の類は登壇するときぐらいしか行かない」の意味

以下の事柄に価値があるとはもう何万回も言われていることだと思うのですが言葉でなく心で理解しました。

  • 発表するために調べたり手を動かす
  • ポジティブ/ネガティブフィードバックをもらう
  • 同じ関心を持つ人が見つかる
  • そうしたエンジニア同士で質問したり議論したりできる

上記の体験を得るにはやるしかないんだよなぁ…。

『「全て」を敢えて差し出した者が、最後には真の「全て」を得る』…*6

ぼっちじゃなくなってきた

konifar さんが アウトプット増やしたらぼっちじゃなくなってきた - Konifar's WIP で書いていることとまんま同じです。3年以上遅れて背中を追っている感覚です。

昔は勉強会やミートアップに参加しても「まぁ、アルコールも飲まないし、懇親会はいいや…」という気持ちでスキップしていました。出るにしても知り合いがいないのでぼっちになるか、たまたま近くにいた人と雑談して終わるだけであまり楽しくなかった。自分の引き出しの少なさや未熟な話術のせいといえばそれまでですが…。

その頃に比べるとだいぶ楽になりました。登壇することで話しかけてもらえるようになり、また、自分のことを知ってもらった状態で会話がスタートするので最初の方の自己紹介プロトコルを省略できたり（できなかったり）。

コミュニティ/イベント運営が好きかもしれない

たまたま携わったイベントが上手くいったからのぼせ上がっているだけなのかもですが、コミュニティ/イベント運営のこと、好き…かもしれない…です。

やる前は「めちゃくちゃ面倒くさそう」で「やっている人に感謝しなきゃ」ぐらいの気持ちだったのですがいざやってみるとやっている側の楽しみもあることに気づきました。

コミュニティやイベントを提供する人の元にこそ人や知見や繋がりが集まってくるのは、勉強会の類で登壇した人が多くを得るのと似ているなぁ、と。

プレゼンはやっぱり苦手

はい。引き続き自分にあったやり方を模索していきます。

これから

折れない心、または自己修復力

筆が乗っているうちに良い話ばかり書いてしまったのですがアウトプットを通じたつらいこともありました。

資料準備などで追い込まれてストレスになったり、可処分時間がなくなったり、プレゼンで話した内容の理解があいまいで質問にうまく答えられなかったり、滑ったり、主催したイベントを無断キャンセルされたり*7、絶対流行ると思ったアイデアが見向きもされなかったり。

そういう時は結構オチて何もしたくなくなるのですが「半年間はやる」と決めて退路を断ったのでなんとか発破をかけながらやれました。タイトルにある「自分を騙しながら」というのはそういうことです。

自身の力でコントロールできることであれば「ある種の後悔は取り戻すことができる」という気持ちでやっていくしかない。コントロールできないものは割り切る。

もしくは、成功体験・良かったときのことをイメージしたり、同じコミュニティで繋がった人を見て受ける刺激で再起したりする。

そういうメンタリティを持った高レジリエンス人材になりたいです。

ペースダウン

上半期はアウトプットするマイルストーンを置きつつ締切駆動×不安駆動でがむしゃらにやったのでちょっと疲れました。

短期的には走りながら考える体力が身に付いたというメリットもありますが、少しペースダウンして長期的に持続可能なスタイルを模索したいです。*8

引き続き、エモいポエムはほどほどに、サステイナブルで高レジリエンスにやっていきます。射撃しつつ前進。

*1:「漫画に影響された」と書くと途端に信憑性が落ちる類のものごとがあるのは理解していますが、それはそうと『医龍』は本当に面白いので未読の方は是非読んでみてください。

*2:「理想とは何」という話は長くなるので省略します

*3:無論、成長意欲を高く保てて頑張れる人もいるが…少なくとも自分は違う

*4:他にも尖っている言語を書いていたりとか、すごそうなorganizationに入っているとか、いろいろ

*5:その他にも、iOSDC, builderscon あたりの big events はやはり運営の努力と技術が凄いと感じています

*6:『STEEL BALL RUN』

*7:まぁ、よくあることなんですが、主催側で体験するとまた違ったショック

*8:と言いつつこのブログと並行して CfP を書いている

Meguro.rb#19で『決済のトランザクション管理術』というタイトルでLTをしました

Ruby

第19回 Meguro.rb に参加し、『決済のトランザクション管理術』というタイトルでLTをしました。

言い足りないことと反省

うーん、5分LTでやる内容じゃなかったかもしれないなぁと思っている。

だいぶ早口でザーッと喋ってようやく決済機能の開発に親しんでいる人に「わかる〜」と言ってもらえる内容だった。が、本当に聞いてほしかった対象はもう少し決済機能の開発経験が浅い方であり、そういう方にはもっと詳細な説明が必要で、そうすると10分は少なくとも必要になってしまう…と葛藤した。

たとえばベースとなったクレジットカード決済のシーケンス図を丁寧に追っていくとか、そもそも決済ゲートウェイって何？みたいな話からするとか。*1

f:id:ohbarye:20180929234239p:plain

葛藤しながら結局早巻きになってしまったのが反省。

Meguro.rb

自分にとっては、色んなところで見知った方々がなんだか多く集まった回だったような気がしていて、終わった後も話し足りないな〜と感じた。

初めて行ったのは第15回でそのときは知らない方だらけで心細かった。それがこの数ヶ月でこんな風に変化したことに思うところがあり、以下のツイートに繋がる。

Quipperによるスポンサー

今回はQuipperによる初めてのMeguro.rbスポンサー回だった。

※スポンサリングの裏側については別の機会で触れそうな気がするのでここでは省略

僕がオーガナイザーの皆さんから声をかけられてスポンサーを買って出たのだが、会場設営・食事準備・司会その他諸々に至るまでQuipper社員の圧倒的当事者意識でサクサクと事が進んでしまった!!

イベントに貢献したのはゲストにトルティーヤを巻いたことぐらいだ

引き続きやっていきます

*1:そのへんの話はサブスクリプションサービスにおけるIn-App Purchase再考では丁寧にやったので興味ある方はそちらを参照

ISUCON8にチーム"sayotan"で参加し、予選落ち (Best Score: 23,553, 最終結果: fail) でした

ISUCON

もう2週間も前のことというのに驚きつつ、ISUCON8に出場して予選敗退した記録。来年に向けたメモ。

チーム編成

メンバーは2人で、両名とも「ふだんやらないことをやりたい」という動機で初参加した。

  • @RyotaKatoh
    • 機械学習エンジニア
    • GoによるWebアプリも書ける
    • Webアプリをチューニングするようなのは「ふだんやらないこと」なのでアプリのコード変更をやることに
  • @ohbarye
    • Webエンジニア
    • Ruby on RailsによるWebアプリ、ReactなどによるSPAがメイン業務
    • Golangやインフラまわりは「ふだんやらないこと」なのでh2oやmariadbを見ることに
      • Golang力は、前日までにTour of Goを流し読みした程度

選択言語はGolang。

チーム名 sayotan は参加できなかった第三のメンバー名から。

結果

さきに結果を書くとBest Score: 23,553で最終結果: fail (fail前 20,304) だった。

f:id:ohbarye:20180929151448p:plain

得点が跳ね上がってから不安定になったのは認識していたものの、最後のベンチマーカ実行で pass していたので再起動試験の結果が発表されるまで自分たちが fail で終わっているとは気づかなかった…。

f:id:ohbarye:20180929151450p:plain

f:id:ohbarye:20180929151453p:plain

経過

主に自分の視点で思い出しつつ書いてみる

  • まずsshでつなぐ
  • RyotaKatoh がtable schemaを出してくれた
  • マシンのスペック（CPU, メモリ）確認したりした
  • とりあえずベンチマーカ実行してみた
    • どのぐらいかかるのかと思ったら1分強で終わった

f:id:ohbarye:20180929151502p:plain

  • top

    • mysqldのほうが頑張っているなーと理解

  • ちゃんとボトルネックを特定しながらやっていくかーと思ったが計測ツールを調べてこなかった情弱ぶる

  • ググりながらmysqlslowdumpを試す
    • 一番時間かかっているやつ、一番ロックしているやつをつぶす
    • indexいくつか増やしたがこの時点ではあまり影響なかった
  • RyotaKatohはコードリーディングしてN+1に気付いたりしていたと思う
  • デプロイの自動化はやらず、git pullで頑張ることにした
    • 2人なので声かけながらやれば大丈夫そう

午前は得点への貢献が特になかった。

午後

  • h2oの設定を見る
    • 静的ファイルの配信はちゃんとh2oがやってくれていた
  • access logをshellで整形
    • 静的ファイルへのアクセスがあまりないのでここは頑張ってもしょうがないかなと理解
    • reports系はそこそこだけど一発がおもそう
      • データをメモリをロードしまくっているが削ったりはできなさそう
      • for updateは要らなさそうなのでけずった
  • RyotaKatohがget_eventのN+1を解消、SQL一発で解決するようにすることでscoreが跳ね上がり、20,000点を超えるようになる
    • しかし性能があがるとテストケースが変わって(?)failするようになる
  • 複数台構成を諦める
    • 午前は複数台に挑戦するつもりだったが、1台で頑張れるところまで頑張れるかー、となった
    • 戦略的にやったわけではないが、結果として/initの罠にはまらなくてよかった
  • ログイン周りのアクセスが多かったのでsha2による暗号化とかを効率化しようとした
    • しかしGolang力が足りず結局revert

f:id:ohbarye:20180929151459p:plain

感想

書き出してみると「8時間近くあったのにこれしかやってないの…？」感がすごい。また、基本的な予習がまったく足りていなかったことを終わってから後悔した。

逆に言えばきちんと対策をして基本的な計測ツールの使い方やボトルネックの特定のしかたを理解したり、戦略的な進行管理ができればもっといけたかもしれない、という希望も持てた。

また、自分が力を発揮できそうなWebアプリ周りを今回はほぼやらなかったのでその辺でどれぐらいできるかも試してみたくなった。

来年もふだんやらないことをやるために出場してみるか〜

余談

f:id:ohbarye:20180929154809j:plain

誰がジュニアを育てるのか -出題編-

採用 Engineering エンジニア 育成

過熱する採用市場の盛り上がりにあわせて感じたことについて言語化を試みているが未だ納得解が得られずにいる。書きかけの Scrapbox は随時更新していくとして、現時点での dump をとっておく。

誰がジュニアを育てるのか - ohbarye

主にソフトウェアエンジニア採用の文脈で「誰がジュニアを育てるのか」ということについて。

f:id:ohbarye:20180929013900p:plain *1

「優秀な人間だけを採る」という採用戦略

著名テック企業が自社の採用戦略について語った本が出版されるたびに話題になる中で「優秀な人間だけを採る」というのが採用戦略として認知されるようになってきたのを感じる。Netflixの最強人事戦略やWork Rules!あたりが代表的…かどうかは知らないがあくまで自分が読んだ中の代表。世には同じことを謳う書籍や記事がもっとたくさんあるかもしれない。

※「優秀」という言葉を定義するのは難しく、そしてまた常に相対的なものだが、わかりやすくするために「在職者と並べた時に上位50%に入るスキルを持つ人」はその企業にとって「優秀な人」としておく。

この採用戦略はいち企業としての成功を追い求めるうえで圧倒的に正しい*2。人材育成に投資する余裕のないスタートアップであれば尚更そうせざるを得ないというのは誰でも合点がいくところだと思う。

局所的な正しさ

正しい、とはいえ採用市場にて大多数の企業がこの戦略を選択すると、この定義において優秀でない人間を雇用する企業が減る。言い換えれば就職先がなくなる。この定義において優秀でない人間とは、新卒や第二新卒、またはキャリアチェンジして業界に参入するキャリアが浅いエンジニアなどだ。長いので"ジュニア"と呼称することにする*3。

優秀であればキャリアに関係なく採用される、というのはわかる。だが「在職者と並べた時に上位50%に入るスキルを持つ」のはごく一握りで9割8分ぐらい*4のジュニアはあてはまらない。

彼/彼女らの就職先がなくならないにしても「優秀な人間だけを採る」戦略をとり、その恩恵を享受するような企業や環境では働けない。そこで起きるのは、優秀な同僚と一緒であれば成長したであろう人の芽が出ずに終わってしまうという問題*5や、優秀な同僚と働きたいのであれば相対的に劣るかもしれない環境の中で自ら成長して優秀にならなければいけないという問題だ。

スタートラインからビハインドしている者がこうした努力と転職を繰り返すことで初めて求めていた職場にたどり着くことはもちろん不可能ではない…不可能ではないが、厳しい。

誰がジュニアを育てるのか？

前置きが長かったものの、誰がジュニアを育てるのか？それが問題だ。

ジュニアの受け皿になる企業は教育コストを支払うだけ支払って彼/彼女が成長した折に"卒業"されてしまうのか。

教育コストを払いたくない企業が生む"ババ抜き"になってしまわないか。

さらに長期的に見ると、優秀だったエンジニアたちが定年を迎える頃には後輩が誰も育っていない、なんてことにはならないか。中途で問題に気づいて新たな解決策が出てくるか。

まだまだ勉強不足なので自分の観測範囲では納得解が得られていない。もしかすると歴史ある他業界や他職種では既に起こったことなのかもしれない。

引き続き考え続けていく。

「優秀な人間だけを採る」に乗らない

別の観点で、「優秀な人間だけを採る」戦略に乗らないことで得られるメリットも存在するという話。

ジュニアを採用することで一時的に平均的なレベルが低下するがそれを許容してでも得られるものはあるのかもしれない。それまで荒野だったオンボーディングが整備されたり、チームで技術力を向上させる仕組みを作る方向に向かったり、Engineering Manager や Tech Lead を志向する社員にメンターの機会を与えたり。

これらのことはジュニアを採らずともできるものではあるが、より強く必要性を認識させる手っ取り早い手段にはなりそう。

引用

以下、記憶にあって探せたものからの引用

Netflixの人事制度

経営陣が従業員のためにできる最善のことは、一緒に働く同僚にハイパフォーマーだけを採用することだと学んだ。これはテーブルサッカーの台を設置したり、無料で寿司を提供したり、莫大な契約ボーナスやストックオプションを与えたりするよりずっと優れた従業員特典だ。

Work Rules!

採用の質で妥協することは、間違いにほかならない。間違った採用は有毒だ。本人のパフォーマンスが損なわれるだけでなく、周囲のパフォーマンスとモラルと活力を堕落させる。

自分より優秀な人だけを採用する

10 人の新規採用者のうち 9 人が自分より優秀なら、採用はうまくいっている。

たとえば大学生を評価するなら、ＧＰＡの点数は考慮すべきかなり重要な要素だと思えるかもしれない。だが、日本からの応募者に関してはそうでもない。日本では大学への入学は主として全国的なテストの結果で決まる。そのため、高校生はそのテストで好成績をあげることに注力し、数年にわたって毎週 15 から 20 時間も塾に通うことが多い。しかし、いったん一流大学に入ってしまうと、成績をまったく気にしない。歴史的に、日本の大学生は塾での鬱々とした時間と「サラリーマン」（過去の日本に特有の年功序列と終身雇用を土台とするキャリアを示す用語）生活の単調さとの狭間で、遊びと自由という最後のあがきにふける。日本の大学の成績は採用データとしては実質的に意味がないが、どこの大学に通っていたかを知ることは、少なくとも新卒者の採用については役に立つ。

クックパッド

日雇い労働者だった赤髪エンジニアがクックパッド技術部長になるまでのストーリーより

その人が入ると、クックパッドのエンジニアの技術力の平均が上がるということを求めてます。

すごくわかりやすく技術力を数字で表わすと……いや、そんな単純じゃないのはわかっていますが、説明のために数字で表わすと、いまのエンジニアの平均値が5だとしますよね。

そこに「いまどうしても人が足りなくて・・・」と、4.5の人を入れる。すると平均は4.83。5と5と4.5。そこにもう一人5を入れても4.87。5に戻らないので、レベルが下がります。

*1:いらすとやより https://www.irasutoya.com/2015/03/blog-post_53.html

*2:なぜ正しいかは上述の本を読むと書いてある

*3:著名テック企業にもジュニアという肩書があるのは知っているがそれは業界全体で見たら優秀層なので例外的とする

*4:要出典

*5:その才覚を見抜くのも採用テクかもしれないが、在職者と並べた時に上位50%に入るスキルを持っていないから入れない、としておく

Engineering Manager Meetup #1 をやりました #em_meetup

Engineering Engineering Manager

Engineering Manager Meetup をやります - valid,invalidで宣言した通り Engineering Manager Meetup #1 をやりました。本記事では感想と振り返りを、イベント運営者と参加者の両視点から忘れないうちに記しておきたいと思います。

connpass.com

本記事の主な想定対象読者はイベントに参加されなかった方です。#em_meetup ハッシュタグ を目にして興味が湧いた方や、Engineering Manager Slack に入っているがイベントには来られなかった方々に""現場の様子""をお伝えするのが目的です。

（参加された方にとっては既知のことばかりかもしれませんが、イベントを追体験したり主催者の思考をのぞき見することで楽しめる可能性があります）

3行で要約すると

気づいたら6,000字以上も書きなぐっていたので要約しました。

  • Engineerng Manage(r|ment) に関心と情熱がある人は少なからずおり"需要"があるとわかった
  • 圧倒的当事者意識を持って参加してくださった皆さんが出会って"何か"が生まれた
  • 早速フィードバックを貰えて"情熱"が伝播したので第2回開催を決めた

Engineering Manager Meetup とは?

イベント開催の動機や趣旨については Engineering Manager Meetup をやります - valid,invalid をご参照ください。

当日のようす

当日のようすです。写真上の文字は各テーブルで話し合われていたテーマです。

f:id:ohbarye:20180926231722p:plain f:id:ohbarye:20180926231727p:plain f:id:ohbarye:20180926231733p:plain

OST形式の魔力

今回のイベントではゲストによるトークやプレゼンは抜きでOST（オープンスペーステクノロジー）形式でのセッションを2回行いました。

オープンスペースは「興味関心の拠り所は明確だが誰もその問題について正解や答えを知らない」chaotic な問題に向き合うのに適したディスカッション形式です。*1

オープンスペースとは、各自が喋りたいテーマを持ち寄り、その中からテーマと進行役(セッションオーナー)を選出し、各グループに分かれて自由に発表、議論、雑談などを行うイベント形式です。

セッションオーナーはあくまで進行役、その時間の枠で何をするかを決めるだけで、そのテーマについて必ずしも詳しい必要はありません。

https://www.meetup.com/ja-JP/GraphQL-Tokyo/events/251782724/ より

この形式を選んだ理由は以下です。

  • 「Engineering Manager」というロール自体が不明瞭であったり、付随する周辺課題についても唯一解がないものばかりなので、そんなテーマたちを話し合うために優れた形式だと考えた
  • 参加者同士が関心を持つ事柄について話し合い、共感したり意見を交わし合うことで横の繋がりを生みたかった
  • イベント全体でのインプット・アウトプットの総和を最大化したかった

振り返ってみてもこの形式を選んで良かったと思っていますが、OSTが成功するか否かは何よりも参加者の姿勢に依存するので、圧倒的当事者意識を持って参加してくれた皆さんに改めて感謝です。

オープンスペースのメリットをまとめると

  • 主体的であることにインセンティブがある
    • セッションオーナーになれば自分の聞きたいことが聞ける、話したいことが話せる
    • セッションオーナーだからといって問題に詳しい必要がない
    • 主体的になればなるほど多くを得ることができる
  • 参加者全員に主体的な参加を促すことができる（運営者視点）
    • 話を聞きに来ただけ、という人には向かない
  • プレゼン準備が必要なくて楽 ;-)（運営者視点）

参加した人にのみわかる熱気のようなライブ感にも似た良さがある一方、デメリットを挙げるとすれば

  • 未経験の方に良さが伝わりづらい
    • 参加者の中にはOST未経験の方も少なからずいたのですが、終了後には「この形式初めてやったけどいいですね」というフィードバックをいただきました
  • 発表資料が残るわけではないのでイベント終了後に拡散しづらい（運営者視点）
    • 皆さんの tweet や blog や口コミで広めていただくほかない
  • テーマがなかなか挙がらないこともあるので仕込みはあった方が安心（運営者視点）

という感じです。

いずれ劣らぬテーマたち

以下のテーマについてそれぞれのグループに分かれて30分ずつディスカッションをし、各グループ2分ずつ発表して共有する、という形で進めました。

  • 目標管理・評価制度
  • 『エンジニアリング組織論への招待』について広木さんと語る
  • Engineering manager とは何者
  • 1-on-1のやりかた
  • managerのキャリアパス
  • 採用・ブランディング
  • 給与
  • チームビルディング
  • Engineering Manager の魅力を伝えるには

@cobasparxxx さんの tweet にあるように、全てのテーマが魅力的で参加するグループを選ぶのに本当に、本当に悩みました。。

参加者の感想ツイートもセルフでトゥギャり、参加しなかったグループの雰囲気の一端を味わおうとしました。@dskst9 さんがアップロードしてくれたホワイトボードから"何か"が伝わるかもしれません。

togetter.com

イベント参加者として

「Engineering manager とは何者」→「給与」それぞれのセッションに参加しました。

Engineering manager とは何者

実に本質的な問いすぎて頭がクラクラするのですが、他社における定義や責任範囲を聞くことで改めて多義性・曖昧性があるなぁと実感しました。それでもぼんやりと共通項みたいなものが見えてきており、広木さんの tweet がその辺を絶妙に突いてくれていました。（ちなみに広木さんはこのテーブルにはいなかったｗ）

給与

インターネットに残せない話が出ました、それだけで大満足です。

書けることの中で興味深かったのは、給与という切り口一つから初めても色んな周辺の問題を議論できるんだな、ということでした。「Engineering Managerは給与を決定する"権限"を持つのか」「"採用"（オファー金額）にどう関わるか」「"評価"への納得感と給与への納得感は一致しない」「"1-on-1" で給与に関する本音を引き出す」などなど。

Engineering Manager の魅力を伝えるには

こちらのセッションには参加できなかったものの実に興味深いテーマでした。

感想ツイートに並ぶ「エンジニアリングマネージャも人間である」がヒットしている様子を見るに、皆さんはふだん人間と思われていなくて辛い思いをしている可能性が濃厚になってきました。

こうした雰囲気が続くとエンジニアリングマネージャを誰もやりたがらなくなってしまう。だからこそ楽しさも伝えていったほうが良いはずだという流れから、何やらこのイベントをきっかけにすごい"戦闘潮流-ムーブメント-"が生まれそうです。

f:id:ohbarye:20180926105637p:plain

イベント運営者として

まずは終わってほっとしました。

イベント運営の知見がないために至らないところが多々あったかと思いますが、 圧倒的当事者意識のある皆さんのおかげでなんとかなったところが多分にあると思います。

特に@dskst9 さんを始めとしたアスクル社の皆さんは会場提供のみならず受付・設営・ホワイトボードや文房具の準備など本当にありがとうございます。セッションが始まった瞬間に何も言わずとも皆さんがホワイトボードを活用し始めたのを見て勝利を確信しました。

第2回

濃度の高い方々（第1回に参加してさっそく第2回を望む方と、今回参加できなかった方）だけで相当数集まることがわかったので第2回も企画します。ご期待ください。

余談

イベント関連の知見、というかメモみたいなものを貼っておきます。

参加者数

  • 申し込み 76名
  • キャンセル 35名
  • 実際の参加者 27名

connpass の統計ページで見ると、公開直後と増枠のタイミングで波ができています。

f:id:ohbarye:20180926111001p:plain

（イベントでの集客のコツはこまめな増枠で波を作ること、というのを広木さんから聞いた。あと少しで定員という状況を作ると申し込みしたくなる心理）

当日のキャンセルが22名ぐらいあってドキドキしたが初心に帰って"濃度"を意識しました。

事前の仕込み

大きく2つやってみました。

Engineering Manager Slack

Engineering Manager Slack を作って事前に参加者同士の繋がりを作ろうとしました。

これはかなり良かったと思っていて、おかげでイベント参加前からすでに"エンジンが暖まっている"人々を集めることに成功しました。「この人たちが参加してくれるなら無限に安心だ」という心持ちになりました。（まぁ、そのうちの何名かは参加できなかったのですが…次回に期待！）

イベント会場にて「Slackでお見かけした○○さんですね？」みたいな会話が偶発的に生まれたときの「あ、"オフ会"…!?」という感動的瞬間もありました。

一方でSlackに参加されずに来場された方もいたと思うのでそうした方々から見た時に内輪っぽい感じになるというか、"クラスのLINEグループに自分だけ招待されてない"時みたいな気持ちになってほしくはなかったのでSlack上で起きた会話を前提とした進め方は極力避けました。（もし出てしまっていたらすみません）

また、有志4人による先行オフ会が行われたのも非常に良かったです。そのときの異常な""濃度""はそのままイベントにも引き継がれました。

Topic bucket

当日話すテーマが挙がらなかったときのために Topic bucket sheet を用意して事前に書き込んでもらおうとしました。

こちらはいまいちで、内容を見れば分かる通りなのですが僕がSlackの雑談の中でちょくちょく上がっていたトピックを転記したのがほとんどです。これは単純にあまり集まらなかったからです。

雑談の中で諸々出てきていたので「ネタはあった」「しかし書き込まれなかった」というのが実態だと思い、書き込むハードルがやや高かった or 導線が悪かったと反省してます。

横の繋がりをつくる

もともと予定にはなかったのですが、終了間際に参加者の皆さんにSNSアカウントや名刺を交換する時間を設けました。

人間だと思われていない者たちが抱えている孤独を分かち合ったからこそ生まれた"何か"があった、そしてこれから生まれる"何か"があると信じます。(何か言っているようで何も言っていない文)

その他の反省と改善点

  • ohbaryeの会場到着が18:57と開始3分前で余裕がなかった
    • テーブル割りとかを事前にチェックしておけばよかった
  • 司会進行・タイムキーパーあたりを同時にやるとけっこうきつい
  • 途中参加した方に対するフォローがなかった
    • それぞれのグループにぬるっと紛れ込んでもらうほかなかった
  • 飲食物の提供がなかった（個人のイベントなので省エネでやった）
    • 食べながらの議論は難しいので食料は無くても良かったが、よく喋るイベントなので飲み物は用意しても良かった
  • スライドを投影していたohbaryeのPCの電源が途中で落ちた
    • いろいろ慌ててしまったが参加者の方の機転で助かった
  • 各セッションのアウトプットを良い感じに共有できる仕組みがほしい
    • 2分間の発表でも伝わるものはあったが、それをストック情報にしたい
    • 口頭で「ブログや tweet で今日の input / output を教えてください！」と呼びかけてはみたがスマートではない
  • イベント運営に気を揉んだために100%ディスカッションに集中できなかった
    • セッションオーナーへの立候補も自重し、ある意味""サーヴァント""していた
    • イベント片手に回しながらセッションオーナーも余裕を持ってできるぐらいになりたい
  • ohbaryeが名刺を切らしてしまった
  • OSTのあとに懇親会をやりたい（めっちゃ盛り上がりそう）

長々6,700字も書きましたがとにかく楽しかったので優勝です。

*1:http://www.humanvalue.co.jp/hv2/our_theory/ost/ost.html