先生: Jaclyn
教材: US University Grows Food on Rooftops
さっと出てこなかった言葉
siblings: 兄弟
only child: 一人っ子
public school: 公立の学校
private school: 私立の学校
vacant lot: 空いている土地(ビルの屋上を指して)
What do you make of ~: ~に対してどう思いますか。
office worker: 会社員
from a distant place: 遠くから
昨日よりも自分の思っていることを話せた気がする。 早く喋ろうとするよりも、まずはゆっくり(少し)文法を考えながら喋ったほうが相手によく伝わる気がする。
"This is the future [of] food," she says.
の [of] は彼女が言った言葉ではなく、筆者が補足したもの。
先生: Charol
教材: Over 1 Billion People Risk Hearing Loss From Loud Music
DMM英会話初回レッスン。もう少し音質良いかと思っていたけど、思っていたものの7割ぐらいだった。音声の遅延とかは無いので、回線が悪いわけではなさそう。相手のヘッドセットの問題かな。
教材の英語を読む部分は特に問題ないけど、自分の意見を言うところでかなり詰まる。教科書を読むのは学校でずっとやってきたからな。
次も教材を使ってやるか、フリートークにするかは悩ましいところ。とりあえず後半ディスカッションができる教材でやってみる。
無料レッスンは2回あったけど、2回では良さがわからないのでとりあえず1ヶ月ぐらい続けてみようかと思う。
最近USのスタートアップと一緒に仕事をすることがあって英語のミーティングをする機会があったり、とある企業から来たスカウトの面談で英語で話す必要があったりと、英語の必要性を感じるようになってきた。 そのうち機械翻訳が発達してきて、英語を喋らなくてもコミュニケーションできるようになるだとうと思って、英語の勉強を後回しにしてきたけど、その時代が来るには少なくともまだ数年はかかるように感じる。
ということでDMM英会話を始めてみようと思う。無料で2回レッスンが受けられるので試してみたけど、悪くなさそうなのでしばらく続けてみる。 基本三日坊主でなんでもすぐに飽きてしまうので、毎日記事を書くことにしたら周りの目もあるから続けられるかなと思ってやってみる。
毎日22:00から25分間やるぞ！
今年の7月から(スクラムにおける文脈の)プロダクトオーナーを担当していて、そろそろ4ヶ月ぐらいが経つわけですが、機能開発の優先順位を正しくつけるのはめちゃくちゃ難しいなぁと感じています。
BtoB のサービスを開発しているので、カスタマーサポートのメンバーからお客さんが普段どんなところに困っているかという声はちょこちょこ聞こえてくるのですが、それを統合して課題の大きさを判断するのは(情報がバラバラで)難しいし、同じテーマで顧客の声を吸い上げるにはヒアリングをする必要がありコストがかかるなぁという印象です。
ぼくは Steam でベータ版のゲームをやることが多く、面白そうだなーと思ったものは Steam に登録される前のアルファ版から手を出して遊んでいることもあります。(好きなジャンルが経営シミュレーション系なのですが、そもそも市場にゲーム数が多くないので、ベータ版が出た段階ぐらいから早めに目をつけています。)
最近のゲームは、昔のように完成したゲームをどーん！と発売するのではなくて、一通り遊べるレベルになったらベータ版としてリリースして、ユーザの声を聞きながら正式版としての完成を目指していくものが多いです。特にPC版のゲームはそれが顕著ですが、SwitchやPS4のゲームソフトでもあとからアップデートをかけられるような仕組みになっており、ユーザの遊び方を観察してそれに合わせてバージョンアップをしているように見えます。
(勝手な推測ですが) なぜ業界全体がそういう方向に向いているかというと、ゲームがどんどん複雑化していて1本のタイトルを作るコストが増大し、1本失敗すると大打撃を受けてしまうからでしょう。(スプラトゥーン2も発売当初は1年間だけバージョンアップしていくよ。と宣言していましたが、売れ行きが好調だったのでその期間を延長することになりました。)
この状況はWebサービスを開発しているスタートアップも同じで、(少し大袈裟ですが)自社プロダクトが失敗したら会社はおわりなので、ユーザの声を聞きながら市場にフィットするプロダクトに少しずつ方向修正していかなければなりません。
Steam がプラットフォームとして成功している1つの理由に、ユーザからの声がゲーム開発者に届きやすい構造になっているというものがあると思っています。
ゲームごとにフォーラムがあり、レビューも集まりやすいのでゲーム開発者にユーザの声がどんどん届くわけです。その意見を参考にしながらゲームを拡張していくことで、よりユーザのニーズに沿ったゲームを作ることができ、結果的に面白いゲームが Steam に集まることになるのではないでしょうか。
また、最近遊んでいた Oxygen Not Included というゲームは、起動するとゲームタイトルの部分に「次に開発して欲しい機能は次のうちどれですか」と四択で選択できるような機能がありました。これは、開発優先度を決める上で非常に有効な手段なのでは？と感じており、弊社のプロダクトでも取り入れてみようかなと考えています。
よく聞く話に「ユーザの声を真に受けるな」というものがありますが、私はこれに半分同意で半分不同意です。ユーザが(自由に発言した)「〇〇の機能が欲しい」という声は真に受けてはならず、その背後にある真の課題は何なのかを読み解き、プロダクトとして一貫性のある機能改善でその課題を解決すべきです。お客さんの声を鵜呑みにしてしまうとプロダクトの思想が失われていき、ぐだぐだなものが出来上がります。一方で、上の例のように、こちらで開発したい機能をいくつか提示してどれが欲しい？と聞くことは非常に価値があり、こちらが(製品の方向性を考えた上で)開発しようと思っている機能のうち、ユーザのニーズが高いものから順にリリースができます。 (すべての選択肢がイケていないこともあるので、「その他の機能」という選択肢が必要かもしれませんが…笑)
SaaSでそのようにユーザに直接開発順位を問うているプロダクトは今まで触れたことがなく、ユーザの声を聞きながらプロダクトの方向性を修正していくのはゲーム業界の方が進んでいたりするのかな？と思って記事を書いてみました。
プロダクトオーナーの皆さんはどこでベストプラクティスを学んでいるのでしょうか… 良い書籍などあれば教えてください。。
この記事では、ISHOCON2を皆で解くイベント を開催した際に使用したISHOCON2のベンチマーカーとポータルサイトの構築手順を紹介します。
ISUCONも今年で8回目となり、最近では多くの会社で社内ISUCONが行われています。 pixivさん(catatsuy/private-isu)、Yahoo! Japanさん(yahoojapan/yisucon)、Recruitさん(recruit-tech/r-isucon)では独自で問題を作成されており、他の会社で社内ISUCONを実施する際にはこれらの問題が再利用されることが多い印象です。(特にpixivさんの問題はISUCONのインスパイアとしては(ぼくの知る限りでは)最初に登場したため知名度も高く、よく使われているように思います。)
ぼくは社内ISUCON向けという形ではなく、個人で楽しむことを目的としてISHOCONシリーズを作成しています。
ISHOCON1は沖縄で開催されたISUCON模擬試験イベントや、Wantedly さんの新卒研修で使って頂いています。
ISUCONイベントを開催する場合、作成済みの問題を使用することで問題作成のコストは下がりますが、ベンチマーカーのインフラを用意したり、参加者がスコアを確認するポータルサイトを準備したりと意外とやるべきことが多いです。 そのハードルが高くてなかなか社内ISUCONが実施できない。という組織も多いのではないでしょうか。
この記事では、ISHOCON2を皆で解くイベント を開催した際に使用したベンチマーカーとポータルサイトの構築手順を紹介します。この記事で主催者の心理的ハードルが下がり、より多くのISUCON関連イベントが開催され、より多くのエンジニアがアプリケーションの高速化に興味を持ってもらえたら嬉しいです。
(とかいいつつ、ISHOCON2はベンチマーカーとポータルサイトでそれぞれ1点ずつ不具合を抱えているのですが。。ASAPで直します…)
ちなみに、今回のイベント準備は右往左往して結局15~20時間位かかってしまいましたが、この記事を読めば2,3時間で環境構築できるのではないかと思います。
(サーバーレスにしようとして上手く行かなくて、結局ECS使うことに落ち着いた話はまた別記事で書きます…)
ここからが本題です。
ISHOCON2はアプリケーションとベンチマーカーが別インスタンスで動くようになっており、(現時点での)最新のベンチマーカーAMIは ami-78b66107 です。ただしこれは個人で取り組む用の実装になっているので、こちらは使用しません。
使用するのはこちらのコンテナイメージです。 showwin/ishocon2_bench_for_contest
このイメージは、HTTPリクエストを受け取ると、ベンチマーカーが起動して、ベンチマーカーの実行ログを Firebase に吐き出されるようになっています。
(WebアプリケーションはPython, Flaskで書かれており、このあたり に実装があります)
Firebase の Database は現在 Cloud Firestore と Realtime Database の2種類がありますが、今回は後者の Realtime Database を使用します。
ベンチマーカーの実行のためには POST /run に以下のパラメータをJSON型で投げますが、今回説明するポータルサイトとセットで使う場合には、特に意識する必要はありません。
| key | 説明 |
|---|---|
| ip | ベンチマークする対象のIPアドレス |
| name | 実行した人の名前(ポータルサイトに出す用) |
| workload | ベンチマークの負荷量 |
コンテナを動かす環境はどこでも問題ないですが、ぼくは使い慣れているECSを選択しました。
ECS + SpotFleet な構成だと金額的にかなり低コストに収まると思います。
コンテナを起動するときに以下の環境変数を設定してください。
| key | 説明 |
|---|---|
| FIREBASE_URL | 結果を投げるFirebaseのURL。(e.g. https://xxxx.firebaseio.com ) |
| MYSQL_USER | 後述するDBにアクセスするためのユーザ名 |
| MYSQL_PASS | 後述するDBにアクセスするためのパスワード |
| MYSQL_HOST | 後述するDBのホスト |
ベンチマーカーのバックエンドにはデータベースが必要で、アプリケーション実装の初期値と同じデータが入っている必要があります。 ISHOCON2/ishocon2.dump.tar.bz2 at master · showwin/ISHOCON2 · GitHub にDBのダンプファイルがあるので、こちらを解凍してデータベースに流し込んでください。
ベンチマーカーのクラスタサイズの目安としては、25人が参加したイベントで、1コンテナあたり2CPUを割り当てて、20コンテナぐらい用意したところ、クラスタ全体のCPU負荷が常時<20%でした。
少し余裕を持つとして、1コンテナあたり2CPUで、参加者2人につき1コンテナぐらいの割合で良いかと思います。(競技終盤はガンガンベンチマーカーが実行されるので、終盤だけ少しスケールさせておくと良さそうです。)
DBはRDSでt2.microを使用していましたが、もう一つ上のインスタンスサイズでも良かったかなと感じました。CPUへの負荷はかかりませんが、ベンチマーカーからの接続数はそこそこな数があるため、メモリにもう少し余裕が欲しかったです。
注意すべき点として、後述するポータルサイトからは workload 30 までしか実行できませんが、workload > 50 ぐらいで実行するとベンチマーカーが途中で止まる可能性があるバグが存在しています。(https://github.com/showwin/ISHOCON2/issues/27)
ポータルサイトはこちらのレポジトリにあります。showwin/ISHOCON2-Portal
使い方は こちら をご覧ください。
設定しなければいけない値としては、上で用意したベンチマーカーのURLと上で用意したFirebaseのデータベースURLの2つになります。
Issue に上げていますが、webpack の1系でしか動作確認できていないので、注意してください。
今回のイベントで使用したものを元にテンプレートを作ってみました。よろしければ使ってみてください。 https://gist.github.com/showwin/8c2ff3f3c57c0135f7fbf4383942e1b8
showwin/ISHOCON2#関連リンク に追記しますので、イベントレポートを書いていただいて、@showwin まで連絡いただけたら嬉しいです！
Enjoy ISHOCON Life !
会社で5月ぐらいからホラクラシーという組織のフレームワークを試験的に採用していて、3ヶ月が経った。 結論から言うと、3ヶ月ではまだ良いかどうかはわからない。 ホラクラシーの恩恵を十分に得られていない感じはするが、Pros/Consはいくつか思うところがあるので忘れないうちにメモしておく。
ホラクラシーを導入しよう！となったのは、だれかが組織に関する本を読んで…のような理由ではない。 もともと会社の採用方針が「社内の人間が持っていないスキルを持っていること」であったので、そもそも今社内でどういうスキルが足りないんだっけ…？今後どういうスキルを持っている人を集めないといけないんだっけ？と考えることが多かった。 HR担当が入ったタイミングで今の採用状況を上のように伝えると、それってホラクラシーの考え方に近いから社で導入してみる？という話になった。(実際にはそこまで近い考え方ではなかったが、、、)
(話は逸れるが)HRの専門家がいなければホラクラシーなんて言葉も知らなかっただろうし、社内にない知識が外から入ってくるのはいつも大変嬉しいことだなと感じる。
HR担当も含めて、ホラクラシーの詳細は社内でだれも理解していない状態だったので、HOLACRACY 役職をなくし生産性を上げるまったく新しい組織マネジメントを読んで勉強した。Holacracy One というホラクラシーの組織管理ツール(GlassFrog)を作っている会社の代表が書いている本で、ホラクラシーを導入すべき理由からホラクラシーの運営方法まで一通り書いてある本でよくまとまっている。 現在日本語で読める本はこれ一冊のみ！という感じなので、丁寧に翻訳されていてよかったという感想だ。
英語ではWebでホラクラシーの運用方法が公開しており、うちの代表が抜粋して和訳している。 本を買う前にどういう組織運営をすることになるのか知りたい方は読んでみると良いかもしれない。
個人的にはホラクラシーを導入したときに得られる一番大きなメリットは現場のメンバーが経営層の目から届かなくなった時に得られると考えているため、まだ社員20人弱のうちの組織ではホラクラシーのメリットが十分に得られていない可能性がある。それでもいくつか良い点を感じることができた。
実際にあった例でいうと、Product Manager と UX Designer がそれぞれ製品の仕様を決めるときに、ホラクラシー導入前、つまりお互いがどこまでを担当するか明文化されていなかったときには、お互いの考えが衝突したときに「PMがそこまで言うならもうそれでいいよ」というように決めてしまうことがしばしばあり、時間をかけて議論した結果お互いスッキリしない意思決定を下してしまうこともあった。ホラクラシー導入後はUX Designerのドメインを「プロダクトの情報設計 / インラタクションデザイン」と明確にしたことにより、UX Designer が最終決定権を持つことになり、意思決定の速度を早めることができるようになった。PMや開発者など周りのメンバーも「こういうデザインのほうが良いのでは？」という意見は投げるし、Bizサイドからもお客さんの声をUX Designerに投げるが、それらの意見を聞いて総合的に判断した結果、なにをどうするかはUX Designerの独断で決まる。そういった意味では、ホラクラシーはお互いを尊敬し信頼し合えるメンバーで構成されたチームでないと上手くワークしないフレームワークかもしれないと感じるところがある。
(うちはスクラムで開発しているのだが)最近ぼくはスクラムで言う「開発チーム」を抜けて「プロダクトオーナー」になった。まだ小さな組織なので意識的に共有しなくてもBizチームもその変化を知っているが、これが100人超の組織になると今だれがどういう役割を担って仕事しているのか正確に把握するのは難しくなる。 そうなったときにも、ホラクラシーで役割が明確化されていれば、今自分が持っている課題は誰に相談しに行くべきか瞬時に把握することができ、「誰に相談してよいか分からないからとりあえずマネージャーに相談する」というような非効率なコミュニケーションルートはなくなるだろう。 ただしこの一覧性/検索性はツールに依存するところもあり、一番メジャーであろうGlassFrogではそれが実現できていない。
(また脱線するが) GlassFrog は本当にひどいプロダクトで、ホラクラシーが広がらない理由の一つにこのプロダクトがイケてなさすぎることが挙げられるレベルだと思う。 今から真面目にホラクラシーの組織管理サービスを作ったら容易に世界No.1を取れるので、暇をしている人は作ってみると良いと思う。
ホラクラシーのミーティングは特殊な進行方法を取っており(詳細は割愛)、これは普段あまり声をあげない人の意見も汲み取るためのプロセスのように感じる。良くないMTG例の1つに、声の大きい人の意見がなんとなく通ってしまって、なんとなく意思決定が行われてしまうものがあげられるが、ホラクラシーのMTGはそういった事はない。 それはそれで良いのだが、1つの意思決定を行うために複数のフェーズで全員が発言をする必要があり、予想以上に時間が取られる。成熟したチームにおいては、もう少しそのプロセスを簡略化するほうが効率的かもしれない。
久しぶりに記事をかいたら、「です・ます調」から「だ・である調」に変わってしまっていたが、書き直すのも大変なのでこのまま公開することにする。
読み終わってから2週間ぐらい経ちますが、新1分間マネジャー――部下を成長させる３つの秘訣
私はマネジメントをしたことがなく、そこまでガッツリマネジメントもされたことがないのですが、このような人が初めてマネジメントをする立場になった時に、初めに読む本としてすばらしい本だと感じました。
「1分間マネジャー」は1982年に書かれたもので、当時はトップダウン型のリーダーシップが当たり前だったためそれを前提に書かれた内容になっていましたが、「新1分間マネジャー」は2015年に出版されており、現代的な横並びの協調的関係が反映された内容になっています。
「自分自身に満足している人は満足できる結果を生み出す」という真理が書かれていました。最近1年の仕事振りをふり返ってみても、確かに自分自身に満足している時の方がパフォーマンスが高かったように感じます。例えば、スケジュール通りに開発できていて、自分の開発速度に自信を持てるようになってさらに高速に開発できるとか、新しい技術を身につけられている実感があってさらに新たなことに挑戦したくなる等ですね。
これからは1on1で「あなたは今の自分に満足していますか？」と聞いてみるのも良いかなと思いました。
マネジャーが意思決定をしてしまうのではなく、部下に自分で意思決定させることが大事だと書かれていました。自ら意思決定することで、"自分で" 成功を掴み取ったという自信になり、そしてその自信が高パフォーマンスに繋がっていくようです。(上で言及した内容ですね)
部下が困っている時には
というように自分で答えを見つけるための道筋を提供してあげると良さそうです。
マネジャーは複数の部下を持っており、また自分自身のタスクもあるため、マネジメントに多くの時間をかけることはできません。その中でどう効率よく部下のパフォーマンスを上げるのかが大事になります。1分間でマネジメントするために「1分間目標」「1分間称賛」「1分間修正」という3つの秘訣があります。
私は子供のころから「すごいね！まぁでもできて当然でしょ〜」という感じであまり褒められることなく育てられたことが影響してか、他人を褒めることがニガテです。笑
本には小さなステップごとに褒めるという方法が書かれていて参考になったため紹介します。
覚えたての段階では最初から100点を求めるのではなく、60点ができたら褒める、80点ができたら褒める、最後に100点ができたら褒めるということが大事です。
例えば、「水をください」と幼子に言わせたいとする時、最初は「みじゅ」と近い音を発しただけで褒めてあげます。そうすることで、この発音は正しそう！ということが理解できます。しばらくしたら「みず」と正しく言えた時だけ水をあげ、次のステップでは「ください」まで付けて言おうね、と教えます。
概ね正しい方法でやっていたらその都度褒めてあげることが大事なようです。
物語になっていて2,3時間で読める短めの本でしたが、勉強になることが大変多い本でした。 気軽に読めるので、定期的に読み返そうと思っています。
この方法は仕事だけではなく家庭でも使えると書かれていました。
1分間目標の存在を知る前から私も取り入れていて、「一緒に住んでいて相手の気になる部分を3ヶ月で2つ直そう！」といって彼女と一緒に紙に改善目標を書いて壁に貼り、月末にお互いの行動を評価しています。(お互いコレを直そう！と共通認識化するのと、3ヶ月で2つという少数に的を絞って行動を改善するのが肝)
まわりの人にも勧めていますがこれが結構オススメで、問題を目標化しておかないと「また今日も指摘された…」「もうわかってるよ…！！」「4つも5つも一気に言われても困る！！」と喧嘩のもとになりがちですが、重要度の高い問題1つ2つを目標として管理しておくと「最近ちゃんとできてるね〜！」や「これ未だに習慣化できてないけど、どう工夫したら良いかな？」などポジディブなコミュニケーションが増えるような気がしています。 みなさんも是非試してみてください！
