Richard Imaoka's Blog

Scalaプログラマ兼Explainer Video作家、リチャード・伊真岡のブログです。マーベリック株式会社で技術広報として働いています。

マーベリック株式会社に就職しました

2019年7月1日からマーベリック株式会社で技術広報として働いていますリチャード伊真岡です。

いわゆるツイッター転職での入社となりました。ツイートを拡散してくださったみなさま本当にありがとうございました。 声をかけて面接をしてくれた方々、面接してくれた会社の皆様とは今後も会社の壁を越えて交流していきたいと思いますし、その機会はたくさんあると期待しています。

ツイートを拡散してくださった皆さんには直接恩返しは難しいですが、もし界隈でツイッター転職する人がいたら私も拡散に協力しようと思います。

今の仕事は?

技術広報の仕事をしています。

会社外向けの活動として勉強会やカンファレンスでの登壇、技術ブログの公開などを通してScalaを中心とした技術コミュニティへの貢献をしていきます。

社内向けにはScalaに関する新技術の導入支援や開発環境整備などをやっていきます。例えば導入したい技術の事前調査や既存のシステムに対する影響調査、あるいは社内でのJDK更新やScala本体及びScalaライブラリのバージョン更新を支援していくことなどを予定しています。

何してた人?

転職前約2年間はScalaプログラマ、その前は9年間証券会社でプログラマ兼技術サポートをしていました。

なぜ前職をやめたの?

会社が清算されてなくなってしまったからです。前職でもScalaを使う仕事はとても楽しかったので、転職後もScalaには積極的に関わりたいと思って転職活動をしていました。

なぜマーベリックに入社したか

私が応募した中では技術広報というポジションの募集をしていたのはマーベリックだけであり、おもしろそうな仕事だったので入社することにしました。もともと登壇や発信の機会を増やそうと思っていたので仕事としてそういった活動ができる点に魅力を感じています。

ただ転職活動時に応募していた他社も非常に楽しそうなポジションばかりで最後まで迷いました。 応募した他社はほとんどが現場で手を動かす開発職、プログラマの仕事でした。各社それぞれに充実した開発体制や技術の運用があり、応募した中ではどこへいっても学ぶこともたくさんあっただろうと感じています。

登壇や発信についても、仕事で開発をしながら社外向けに積極的に発信することも不可能ではないでしょうし、実際私が尊敬するエンジニアの多くはそうしています。そして今回私は技術広報の仕事に就きましたが開発の現場から離れることで失ってしまう能力や感覚もあるでしょうし、そこは今でも大いに不安です。

ただ一方で同じ開発の現場であっても結局各社で学べることはちがい、どのポジションに就いたとしても得られるものと同時に得られなくなってしまうものもあるはずです。今回の転職では開発者でなくなることで失うことより、技術広報の仕事を通じて得られるものに挑戦してみようと思いました。仕事の一環として外部への発信を行うので、今まで開発業務をこなすだけで手一杯だった私でも外部発信を積極的に行っていけると思います。

またScalaのコアな部分、例えばScala本体であったり利用者の多いライブラリ、あるいは関数型プログラミングといった部分により多く自分の時間を使えることになります。 今まで私はScala歴が浅いこともあって、akkaというライブラリを中心に勉強して意図的に他の部分をあまり勉強していませんでした。 今後はこれまでの苦手分野についても積極的に勉強して発信していけると思うと楽しみです。

その一環としてまず、7月29日にFun Fun Functional、8月30日にbuildersconで登壇します。

opt.connpass.com

buildersconは8月29日 ~ 8月31日の3日間のイベント。チケット発売中だよ。

builderscon.io

そしてマーベリックではエンジニアを募集しています。興味を持ってくださった方はどうぞこちらから!

www.mvrck.co.jp

今後について

Scala 3.0 がもうすぐリリースされますし良いタイミングでScalaにより深く関わる機会を得ることができたと思います。やってみたい企画や発信していきたい内容はいろいろあるので、これからも技術コミュニティに関わりつつより積極的に情報発信していきたいと思います。すでに知り合いの方は今後とも宜しく、まだ知り合いでない方はこれから仲良くしましょう!

英語中級者向けに発音とアクセントを改善する方法 by Richard Imaoka

TL;DR

この記事は私が体験して効果的だと思った方法の紹介です。一言で言うとこの2冊の本を中心に学んでほしい、ということです。

Mastering the American Accent

Mastering the American Accent

American Accent Training: With Downloadable Audio (American Accent Traning)

American Accent Training: With Downloadable Audio (American Accent Traning)

ここから先はこの2冊をおすすめする背景と、適宜使うと良い補助の教材の紹介をしていきます。

私の英語力と英語履歴

新卒から9年間の外資づとめの後2年間日本の会社で働いて、今年の1月から英語ネイティブ並みの発音を目指して再特訓中です。9年外資に勤めてもずっと日本人なまりの英語のままでした。ちなみに大学卒業までは一歩も日本から出たことはありません。

英語で書かれた英語教材には世界中の英語学習者向けの知見が詰まっている

みなさんはEnglish as Second Language略してESLという言葉をご存知でしょうか?「第2言語としての英語」という意味で、アメリカ及びイギリスには世界中から非英語ネイティブの英語学習者が集まるので、ESL教育、つまり第2言語として英語を学ぶ人達への英語教育が学問としても研究されていますし、教育の現場でも長年に渡って知見が積み重なっています。

こうして積み重なった研究や教育現場の成果は「英語で書かれた英語教材」として出回っていて、結果英語で書かれた英語教材の方が他言語で書かれた英語教材より質の良いものがたくさんあると言える状態になっています。

もちろん、英語で書かれた英語教材を理解するにはそれなりの英語レベルに達している必要があるので、初心者は日本語で書かれた英語教材を積極的に活用するとよいでしょう。そして中級者以上になったら、この記事の最初に紹介した教材などを使って学習すると効果的です。これらは非英語ネイティブがネイティブ並みに上達する過程で使われることのある教材です。

他の分野は他の教材を

今回は発音とアクセントの話だけです。ライティングとか、他の英語技能は他の教材をつかってください。あとこの記事はアメリカ英語の話で、イギリス英語の話は別です。

網羅性と良心的な価格から今回紹介した2冊をおすすめ

英語のように学習すべき内容が安定している分野は、「定番の教科書」に頼るのが良い方法の一つと言えるでしょう。私が上に挙げた2冊も定番と言える本で、複数の版を重ねています。好きな方を買えばいいと思いますし、私のおすすめは2冊とも買って苦手部分を2冊目で補強することです。両方買っても6000円くらいですかね。どちらも購入後に音声教材がダウンロード可能です。絶対音声はダウンロードしてください。

最近は本だけでなくUdemyのコースやYouTubeの無料動画など動画形式の教材も増えてきました。良い動画教材もたくさんありますが、私が調べた中では網羅性を考えると上の2冊の本に敵うほどの教材は発見できませんでした。上の2冊をしっかり勉強すればその他の動画は「本で習ったことのある話」だと感じると思います。無駄な話が少なく、解説の洗練度合いも版を重ねた本のほうが良いと私は感じます。 ただし、補助教材として使うなら動画も効果的だと思います。

もちろん、どうしても私個人が探した中での話なので、私が挙げた本より良い教材があるかもしれません。あなたがもっと良いと思う教材を見つけたら積極的に試してみましょう。自分で探した教材で学ぶのが一番やる気が出ます。

助教材としての動画紹介

これらの本に挑戦しようと思ったけど、その一歩手前のレッスンがほしいと思う方にはここに紹介する動画などを活用してみてください。まさに先に述べた「補助教材」としての使い方です。私もこれらの動画と本を行ったり来たりして今も学習を続けています。

youtube.com

上の動画はかなり古いですが、8分と短めの時間で英語母音の発声の仕方を一通り学ぶことができます。この動画のマネをしていくと、自分の苦手な部分や区別が付きづらい母音に気づくでしょう。母音だけでなく子音版の動画もあります。

自分の苦手な母音がわかったら次はこの

Interactive IPA Chart

で苦手な部分を繰り返し練習してみると良いでしょう。

母音だけのinterative chartで子音のinteractive chartはありませんが、役に立ちます。よく日本人はvとbの違いだとか、子音の区別が苦手だと言われますが母音も大概苦手です。そもそも英語の母音全部の種類把握している日本人英語学習者は少ないと思います。 私は英語学習11年目、つい2ヶ月くらい前にようやく把握しました。(学生時代含めると20年以上…)

本にそって練習したし上の動画も見たけど、母音と子音のいくつかについてはネイティブの音を再現できないという人もいるでしょう。そういう人にはこちらの動画。動画リストになっているのでリンク先へ飛んでいって、それぞれの苦手な母音または子音の動画へ更に飛んでください。

American English - UH [ʌ] Vowel - How to make the UH Vowel - YouTube

私が知る中では一番、一つひとつの音の出し方を丁寧に解説しています。その分全部この動画を見ながら繰り返し練習していたら時間がかかります。最後まで残った苦手の克服に使うと良いでしょう。

ELSA Speakは効果的、しかしカバーできない範囲もある

英語学習者には有名なELSA Speakというアプリがあり、スマホのマイクに向かって例文をしゃべるとアプリが「100%中の何%」という形で採点してくれます。

elsaspeak.com

確かに流行るだけあって良いアプリなのです。リアルタイムで自分の発音を点数化してくれるというのは他ではなかなかお目にかかれませんし、その精度がこのアプリのセールスポイントです。

ただしレッスンの構成に網羅性が足りず、子音系は充実していますが母音系は充実していません。そしてアクセントに関してはほとんどトレーニングしてくれません。やはりこのアプリも、補助教材として使うと有効に使いこなせるのではないでしょうか?私もそういう使い方をしています。

文章レベルのstressについて

抑揚の少ない日本語に比べ、英語では抑揚、stressを正しくつけることがネイティブらしい発音の最重要ポイントになります。

Word stressつまり一つの単語の中でどの音節にstressを置くかのルールは比較的単純です。

しかしsentence stress、つまり一つの文のレベルでどの単語を強調するかというのは英語アクセントの中でも非常に難しい技能です。これらは本や動画をみても、ルールの一部は解説されていますが網羅的で完璧なルールを解説しているものを少なくとも私は見つけられませんでした。

Sentence stressは本や動画で学んだルールをある程度覚えたら、あとはひたすら音声をきいて、自分で協調されている単語を聞き取って慣れていくしかないと思います。私の場合はこうやって文字起こしに黄色線を引くなどして練習しています。

f:id:richard-imaoka:20190602230757j:plain

最後にやる気の出るかもしれない話をちょっと

大人になってからはネイティブ並みの発音を身につけるのは難しいです。それは不可能だと思っている人もたくさんいると思いますが、私はそう思っていません。

エモい話を押し付けるのは嫌いなので、「努力をすればこの人のようになれる!」というつもりはありません。ですが練習量と環境によっては20歳を超えてからネイティブ並みの英語発音を手に入れた人もいるという例でこの動画を紹介します。

www.youtube.com

When I was 20 I moved to NY to study acting with a dream and a foreign accent. Today, 16 years later, I'm a speech and English coach that has worked with hundreds of students from all over the world. This is my story.

なんと非英語ネイティブなのに今や英語を教える側になっている人です。

これは私の持論ですが、この「大人になったらネイティブの英語発音を身に着けられない」説は能力だとか脳の機能的な話じゃなくて、時間の問題が一番大きいんだと思います。大人は学生に比べて英語学習のためだけに時間を作るのが非常に難しいです

英語の発音をスキルという観点から捉えると、正しい口の形と正しい舌の位置、正しい声帯の使い方さえできていればネイティブと同じ発音に聞こえます。これは筋肉の動作なのでスポーツと一緒、練習すればできるようになるものだと思います。別にエモい話ではなく物理の現象です。同じ音を出すための条件が整えば同じ音が聞こえるはずで、その条件は筋肉の動作によって作り出せます。

最後に冒頭で紹介した本のうちの一冊American Accent Trainingからこちらを引用して記事を終わりにしようと思います。

f:id:richard-imaoka:20190602230024p:plain

実際に私自身が読み上げてみました。まだネイティブには届きませんが、5ヶ月でだいぶナチュラルになってきたと思います。

youtu.be

参加記録: EventStormingワークショップ 〜かつてない図書館をモデリングしてみよう

EventStormingというのは、「みんなでワイワイ付箋はって議論しながら、ドメインモデリングやろうぜ!」という会だと思っていたのですが、実際自分でやってみないとわからんと思い以下のワークショップに参加することにしました。

readeffectiveakka.connpass.com

Event Stormingの詳細は冒頭のリンクを見ていただきたいと思います。Event Strorming推奨者(?)が執筆途中の本も販売されています。

やってみた感想は、Event Stormingは一手法に過ぎないので慣れればやり方を洗練させることができるし、他のドメインモデリング手法と組み合わせても効果を発揮するかもしれない、といったところです。最後にもう一度感想はまとめています。

当日の手順

今回のワークショップはEvent Stormingを使って「かつてない図書館」をモデリングするという会です。20人ほど参加者が集まり、各参加者の頭の中には野心的な「かつてない図書館」のビジネスモデルがある、という前提です。

当日は以下のような手順で進みました。

ここでベタベタとオレンジ色の付箋を大量に貼っていきます。オレンジ色はドメインイベント(後述)を表します。

3 ~ 9 は2の結果をフェーズごとに異なる視点で深く分析、そして整理していくイメージ。

  • 3: タイムライン強化 30分
  • 4: 人々とシステム 30分
  • 5: ウオークスルー 30分
  • 6: 逆光ナラティブ 30分
  • 7: お金を追加 30分
  • 8: 問題と機会 25分
  • 9: 問題の選択 30分
  • 10: クロージング 30分

(2: カオス探索) オレンジ色の付箋でドメインイベントをベタベタ貼っていくフェーズ

このフェーズでは参加者各々が「かつてない図書館」で発生する「ドメインイベント」をオレンジの付箋に書いて巨大なホワイトボードに貼っていきます。ドメインイベントは図書館で発生する重要な出来事を「動詞の過去形」で表したものです。例えば「本を借りた」「本を返却した」「本を本棚に並べた」などでしょうか。

各人が他人を待たずにどんどんドメインイベントを付箋に書いて貼っていく方がEvent Storming的にはよいとされているようです。この時点では他者と重複する内容を貼っても構いません。

注意点として、これはITシステムの設計パターンであるEvent Sourcingとは異なるので、Event Sourcingを念頭にITシステム内で実装するイベントを考えるのでなく、ITシステムを忘れた上で純粋に対象ドメインからドメインイベントを挙げていかなくてはなりません。

しかし、やってみるとこの「ドメインイベント」として何を挙げていいかなかなかわからない。「本を借りた」くらいならすぐ出ますが、ちょっと考え始めると「司書もモデリング対象…?司書にひもづく動詞って…」と悩んだり、「図書カードが発行された」というドメインイベントに対して「図書カードが発行された、に関連する他のイベントってなんだろう。そもそも図書カード何をするためのものなのか決めないとわからないのでは…」と結構手が止まること多数。

Event Stormingの本を読んだだけでは、一旦このフェーズで勢いが出始めたらどんどん付箋が貼られていくようなイメージでしたが、実際には悩んで手が止まることが多いかもしれません。これは本を読むだけでは得られない発見でした。スムーズに行かない部分も含めて貴重な経験です。

3 ~ 9 のフェーズ

ドメインイベントを洗い出すフェーズ、カオス探索が終わったら、あとは整理と分析のフェーズが続きます。ドメインイベントを時系列に並べたり、関連する登場人物や第三者・システムを列挙したり、時系列に並べたイベントを時系列の逆からたどって漏れがないか検討したり、と様々な手法と視点を用いてドメインモデリングを深く行っていきます。

ホワイトボードと付箋を使うのは同じで、各フェーズごとに付箋の色を使い分けていくことになります。

3番目以降のフェーズでも必要に応じて漏れていたドメインイベントを追加していっても良いのですが、やはり2: カオス探索でのドメインイベントの網羅性と質がその後のフェーズでの分析の質を大きく作用するような印象です。

3 ~ 9 のフェーズ、あるいはEvent Storming全体の質を向上させるには、いかにして2: カオス探索をうまくやるか、質と網羅性の高いドメインイベントを挙げていくかに集中するのが良いと思います。その点について記事の後半で私の意見を述べています。

やってみてわかったこと、事前のEvent Stormingに対するイメージとの違い

Event Stormingも実際やってみないといいところも悪いところもわからないもの。本を読んだだけではわからないことを発見することができました。

まず1つ目は、Event Stormingはドメインモデリング手法であって、斬新なアイデアを思いつくための方法ではないだろうということ。参加対象者として、まだ明確に文章化や図解にはできてないが、豊富な経験をもとに頭の中には複雑で細かいルールが詰まっている、というような人々が集まって対象ドメインを分析し、明確な共通理解を得るには良い手法だと思います。でもこれで参加者のなかから100億円儲かる斬新なアイデアが出るわけ無いですし、当たり前だけど斬新なアイデアなんて「手法」で思いつくものじゃないですよね。

それから2つ目は、ついついソフトウェアエンジニアはITシステムを実装するときの事を考えてモデリングをやってしまいがちだということです。先にも述べましたが、Event Storming自体はITシステムのことを忘れて純粋にドメインモデリングのみに集中するものです。図書館の例だと、本を借りる、本を入荷する、といった図書館自体の仕組みについて考えるのであって、図書館のITシステムについて考えるわけではありません。わかっていてもなかなかこれは難しいことでした。

反対に、ITシステム上の制約がドメインイベントの種類を決めるケースもありました。図書館に普通の貸出フローと同時にオンライン貸出予約システムを導入するとなると、普通の貸出フローに沿って利用者が本棚で本を手にとって貸出カウンターに行くまでに、別の利用者が同じ本に対してオンライン貸出登録を済ませている事が考えられます。これは純粋なドメインモデリングの話ではなく、ITシステム側で考える非同期処理の競合の話のようですが、これによって「本を借りた」というドメインイベントが「本を手に取った」「貸出カウンターにおいた」「貸出申請をした」などより詳細なレベルのドメインイベントへの分割を要することがわかります。

3点目として法律も重要であり、ITシステムがドメインイベントを決めるケースがあるという他にも、法律がドメインイベントの種類を決めるケースもあるとおもわれます。今回のワークショップでも一部法律に明るい参加者が関連法案に対する知識をもとに「ここで利用者からお金を取るなら、どうじに著作者にお金を払わなくてはならない」といった指摘をしていました。当然こういった手順は対応するドメインイベントを必要とします。しかし、現実の世界では関連法規を全部暗記している人などほぼいないと思われるので、ドメインイベントの洗い出しに法律の理解が必要な場合、実際には時間をかけてやる必要がありそうです。

2回目以降ワークショップをやるなら…改善案

馴染みのある対象をドメインモデリング対象にしる

今回特に2: カオス探索のフェーズでドメインイベントの洗い出しの網羅性が低い箇所があり、適切なイベントを思いつけず悩んでしまうといった状況になることがあったと思います。

おそらくその原因は現実の事業に対するモデリングと違って、「かつてない図書館」という対象ドメインは参加者全員にとって未知のものであり、かつ事前に「どのあたりがかつてないのか」を明確できていなかったので、ドメイン対象に詳しくない人たちが悩みながら話す状況になってしまったからかなと思います。

今回はワークショップという形でしたが、「実際の」Event Stormingは現実の事業に関わるドメインモデリングするため重要な関係者、つまりステークホルダーをよんでEvent Stormingを行います。Event Stormingの本にも「適切な参加者を招待する」ことの重要性が書いてあります。つまり、視点は違えどそれぞれがモデリング対象のドメインに対して一家言もっているということが重要なのだと思います。

ワークショップを練習の場と考え、そこで一家言持つ人々が参加している状況を再現するために、普通の図書館をモデリングしてもよかったし、エンジニアに馴染みのある既存のサービスをモデリングしても良かったかもしれませんね。

とはいえ、特に後半になるにつれ他の参加者から自分が考えていなかった分析の視点が提供されることがあり、手法自体の可能性は感じることができました。

一旦2: カオス探索をやった後にドメインモデリング対象を狭める

「かつてない」部分だけでなく、既存の図書館にもある機能だけに絞っても、たくさんの複雑な領域があることがわかりました。たとえば「図書カード」周りの処理は考えれば考えるほど複雑です。あるいは図書館の利用者が本を探してから借り、返すまでも、紛失や延滞、貸出登録の間違いなどを考えるとどんどん複雑になっていきます。本を本棚に並べるのも、多くの図書館では書架と呼ばれる普段は利用者に見えない場所に保管するなど、分析によってどんどんその管理の複雑差が明らかになっていきますし、さらに本の在庫管理を別ドメインとするか、図書館のメインのドメインとするかなどなかなか難しいところではないでしょうか。

ここで挙げた項目ひとつひとつが、一日がかりのEvent Stormingの対象となりうるような複雑さを持っていると思います。いったんEvent Stormingのカオス探索の段階で、これはモデリング対象が広範すぎてドメインイベントを網羅できない!となったら複数のEvent Stormingの開催に分割してもよいのかもしれません。

Event Stormingを分割する話は確か本には載ってなかった気がするのですが、あまりEvent Stormingばかりやって時間をとるのも現実の事業の中では難しいので悩みどころですね。

ブレインライティング

2: カオス探索の手順についてはブレインストーミングに近い手法だと思います。ブレインストーミングについては私が前にこんな記事を目にしていて、

いいアイデアなんか思いつくはずがない – 東京工業大学エンジニアリングデザインプロジェクト – Medium

その記事内では

「いいアイデアが浮かばない」「使えないアイデアを出す」

と散々なこき下ろしようでした。わたしはブレインストーミングがそこまで使えないかはわからないのですが…

…少なくとも先に述べたようにこの2: カオス探索は斬新なアイデアを出すためのものではありませんので、ブレインストーミングに似た手法でも問題ないかと思います。ただ、それでもなかなかその場でドメインイベントを思いついて書き出すというのはハードルが高いので、可能なら記事内でも紹介されている「 ブレインライティング」を事前に行っていくと良いかもしれません。

もっとも、Event Stormingは参加者の全員が協力的でない場合も想定した手法なので、かならずしも参加者が事前に時間をかけて「ブレインライティング」をやってくれるというのは非現実的な想定かもしれません。

まとめ

記事の最初で言ったように、個人的にはEvent Stromingは一手法だと思っていて、手法であるからにはだんだん慣れて洗練させていくことができ、またEvent Stormingだけでなく複数の手法を組み合わせていくことでさらに有効な手段になる可能性もあると思います。ユーザーストーリーマッピングなどの手法と、もしかしたら組み合わせることができるかもしれませんね。

ドメインモデリングというITシステムの実装から離れた文脈で議論し、その手法の練習をするというのは新鮮な体験でした。ソフトウェアエンジニアとしてドメインモデリングの腕をもっと上げて行きたいと思うきっかけになりました。

それから話はそれますが、斬新なアイデアを思いつくためのものではないはずの会で、最後の方になってからなぜか一部の参加者から怪しげな(?)図書館のビジネスモデルが湧き上がっていたのは興味深かったですね笑

レガシーをぶっつぶせ。現場でDDD!に行って聞いたトークごとの感想

こちらのイベントに行ってきたので感想を書きます。

genbade-ddd.connpass.com

登壇者、主催者には参加者からのフィードバックがたぶん一番嬉しくて、次回開催のモチベーションにもつながるのでみなさんもブログを書くととても喜ばれますし、ブログが大変ならツイッターでも伝えるとすごく良いと思います。わたしも勉強会の手伝いをやったことがあるのでその辺はわかります。

ソフトウェアの核心にある複雑さに立ち向かう 株式会社ギルドワークス 増田 亨

初めて増田さんを直接みてお話を聞きました。サンプルコードが出てこない抽象度の高い内容の発表だったのに、参加者に「それそれ!」と思わせるトークはさすがだと思います。基本的には増田さんの著書の内容の復習みたいなものだと思いますが、著者本人がライブで強調する部分、例えば型を使うことの効用を説くのを見られるのは伝わり方が違う、本を読むだけとはまた違うなと感じました。増田さんの本を読んでない参加者も多かったと思われるので、そういう人たちには良い導入になったでしょう。

www.slideshare.net

レガシーシステムからモダンな環境への移行 ~Y!プレミアム・バックエンドシステムのリニューアル~ ヤフー株式会社 清水 将貴

Y!プレミアムの会員数がすごくて、ソフトバンクユーザーが自動的に無料でY!プレミアム会員になっている分を差し引いても、エグい金額稼いどるなーとか考えながらトークを聞いていました。

レガシーなシステムがアドオンに次ぐアドオンで膨張していったり、新規処理フローから既存の処理フローを内部的に呼び出す形で実装することで既存フローを活かしつつ既存フローの破壊を防いだりなど、私もレガシーなシステムの多い証券会社で働いていたので身につまされる話が多かったですね。

欲を言えばもうすこし具体的に「この変更をやったらココがぶっ壊れて、こんな影響が出て、だから以前の実装はまずかったよね」みたいな臨場感のある話、障害例や失敗例を聞きたかったけど外に出せない話も多いのでしょう。

登壇者の清水さんには私から質問をして「レガシーコードをある程度までリファクタリングしてからDDDでの再設計を本格化しましたか?それともレガシーコードはだいたい放っておいてDDD再設計にとりかかりましたか?」という質問に「後者です」と答えていただきました。ありがとうございました。

ちなみに私は前者のアプローチでDDDの導入を試みて失敗しています。(先程の証券会社をやめたあとの別の会社)レガシーシステムを開発したメンバーが抜けてしまった後だったので、知識の醸成のためレガシーリファクタリングをしながら業務を学びゆっくり頑張ろうと思っていたら先に会社の方がなくなってしまったのです。(正確には会社は精算して事業は別会社に譲渡)

DDDサンプルコード ライブリファクタリング 関西Javaエンジニアの会 irof 株式会社ギルドワークス 増田 亨

irofさんのコードを書くスピードが非常に早く40分間でもガシガシ進捗が出る、まさにライブ感のある面白いセッションでした。なにより「なれた人がSpringBootを使って実際にリファクタリングを行う手順」を見られたのが大きいです。現場でDDDをベースにした議論とコーディングのイメージが湧いた人も多かったのではないだろうかと思います。わたしはSpringBoot使ったことない分、そのあたりがとても勉強になりましたね。

コードが公開してあるのも素晴らしい、後で見たいです。本当に本当にありがたい。

github.com

セッションの中でクラス間の関係をダイアグラムであらわすJigというツールを使っていたけど、これもirofさんが書いてたのか…すごいな。

github.com

劇的ビフォーアフターBIGLOBEのDDDの昔と今〜 ビッグローブ株式会社 曽根 大作

個人的にすごく良いと思ったセッションでした!BeforeとAfterを対比させることで以前の問題点とDDD適用後の改善点が対比されわかりやすいく、DDD本によくある施策具体的にやってみたらどうなのよ?という疑問に対する回答例を与えてくれたと思います。そしてDDD適用後もまだ疑問や課題が残っていることを示してくれたことが教科書的でなく生きた実例としてさらに学びがありました。

あと概念図、なんとか図(名前忘れた)と3段階くらいにDDDで使う図を分けるのも「それそれ!そういうのが知りたかった!」と個人的ヒザパッシーンの瞬間でした。自称図解大好きマンの私としては、多くの人がすぐ一枚の図に情報詰め込みすぎるのを苦々しくおもっていたので、こういう図を分けて複数使うプラクティスが実践されて紹介されるのは大いに学びがあります。

実録!LOHACOにおけるDDDとCleanなArchitecture アスクル株式会社 佐藤 大典、中村 俊之

軽量DDDや一周戻ってきてサブドメインを統合すべきじゃない?という話など、チームみんなで学びながらDDDを実践している様子がわかる良いセッションだったと思います。個人的には「DDD本の境界づけられたコンテキストの図がわからん」の話がツボでした。いや、あれは確かにわからない笑。

ビジネスルールの複雑さに立ち向かう実践技法 株式会社ギルドワークス 増田 亨

朝の増田さんの発表の続き。途中アメリカの大学でのマーケティングの授業っぽい話が出てきたけど、業務を理解するというのはそういう一面もあるのかなと思いました。携帯電話会社の料金プランからDDDモデリングをやってみるというのはいい練習になりそうですね。世の中お金に関するルールは複雑になりがちで、多分みんな余計なお金は一円でも払いたくないし反対にお客さんを獲得するにはいろんな創造性に富む(笑)方法で金を突っ込むからかなーと思うのですが、そういうところはDDDの効果が大きい領域なんでしょうね。

www.slideshare.net

パネルディスカッション&質疑応答&クロージング

さすがにこの時間になると疲れてきたので、主催者や登壇者はその何倍も疲れているだろうから大変だなーと感心しながら聞いていました。質問で印象的だったのは「ゲームなど速度の要求される領域でもDDDは使えるのか?」というものですが、

  • 「DDDでレスポンスの速度を出すために工夫やトレードオフを検討した経験はあるか?」
  • 「ゲームを始めとする速度を要求される場面でパネリストがDDDを使ったことがあれば、その経験を聞きたい」

という質問に変えてみたらもう少しわかりやすかったのかなと思います。個人的にはこのあたりはDDDとは関係なくて、だからDDDをやりながらでもできる話で、結局はパフォーマンス要求水準を決めて、ベンチマークをやって、プロトタイプ作りつつ計測を重ねていくという方法しかないと思っています。そのあたりの実践については樽八さんの本、

背景理論についてはBrendan Greggさんの本やWebサイトが一番のリソースですね。

詳解 システム・パフォーマンス

詳解 システム・パフォーマンス

www.brendangregg.com

最後に

主催者の皆様、登壇者の皆様、非常に良いイベントを実現してくださってありがとうございました。レガシーをぶっつぶせ!といいつつも、現実世界ではレガシーのほうが開発者をぶっつぶそうとしてくるので、そんな力に抗うまさに「ドロドロした」現場感の溢れるセッションが多かったと思います。私はレガシーにぶっつぶされた開発者として(笑)登壇者のみなさんの勇敢な取り組みを心強く思い、いつか仕事でDDDを使うときのため腕を磨いていこうと思います。

個人で初めて作ったwebサービスでの技術選択と調査の振り返り

今年1月に個人としては初めてwebサービスをリリースしまして、そいつはpinviteというやつです。機能としてはwebから入力フォームで文字入れて、ボタン押したら自分のツイッターアカウントからこんな画像つきツイートを投稿しますってだけです。本当にツイートを投稿するだけ。

f:id:richard-imaoka:20190507134402p:plain

構想ではもっと広がる夢があったけど、これだけの機能作るために構想開始から6ヶ月、実装開始から3ヶ月かかりました。プログラミング難しすぎるよ!マジ会社作って新規のウェブサービス作るやつとかバケモノだヨ!どこにそんな元気あるの…

せっかく作ったんだから採用した技術や行った調査のまとめをしておきたいなーと思っていたのでこの機会にやってしまいます。

UIはWebサービスで作る、モバイルアプリは作らない

私はモバイルアプリを作りたかったわけではなく、作る能力もなかったので「画像つきツイートをする」という単純な機能を、私としてはモバイル技術より馴染みのあったWebアプリとして作ることになりました。

バックエンドは運用の簡単さと安さからFirebase一択

バックエンドのインフラを運用したくなかったので、開発の初期段階でFirebaseで実装することを決めました。そしてFirebase安い。今もアプリケーションは走り続けていますが毎月2円の請求しか来ていません。

FirebaseにはFirebase AuthenticationというTwitter OAuth連携をほとんどやってくれる素晴らしいサービスがあります。個人開発でやるとき、ログイン周りはすっごくめんどうですからね。これがあるとありがたい。

画像生成部分はCloudinaryという画像ホスティング + 変換サービス

入力フォームからの情報をもとに画像生成する部分は、このサービスのコア機能です。先ほど載せたツイートの画像部分はオレンジ色の背景画像の上に文字をオーバーレイして画像にしています。

f:id:richard-imaoka:20190507130026p:plain

いろいろなクラウド画像変換サービスからCloudinaryを選びました。他にも似たような事ができるところはあるでしょうが、昔ちょっとだけ私が使ったことがあり、今回の文字オーバーレイや無料プランで賄えることなど要件を満たしていたのでCloudinaryでいくことに決定。

Cloudinaryではこのように非常に長いURLを作成して、前もって用意しておいた背景画像にオーバーレイする文字列やフォント、位置などを指定します。

https://res.cloudinary.com/pinvite/image/upload/c_fit,g_north_west,h_400,l_text:NotoSansJP-Black.otf_60_left:helllooooooooo,w_1000,x_100,y_500/background.png

f:id:richard-imaoka:20190507100811p:plain

pinviteでのコードはコレ(リンク)。CloudinaryのNode.js APIを使っていますが最終的にはこれで上で述べた形式のURLが得られます。詳しい文字オーバーレイ画像の作り方の情報はここに載っています。

Image Manipulation for Developers | Cloudinary

フロントエンドはReact

今にして思えばReactとか使わなくてプレーンなHTML + テンプレートエンジンでもよかったかなという気がしています。

React楽しかったけど。本当に楽しかったよw

共同開発者のAkira YamamotoさんがReactが得意であり、私も3年ほど前にちょっとだけReactを触ったことがあり、私の安易な判断でReactを使うことにしました。

TypeScript マイグレーション

途中から共同開発社のAkira Yamamotoさんとノリと勢いで「TypeScript入れちゃいましょうか」「いいっすね入れちゃいましょう!」って言って2週間ほどかけてTypeScriptへの移行を果たしました。下記のガイドに従って、ファイル一つずつ拡張子を変え、中身を書き換えてtypeを導入し…という手順でした。JavaScriptとTypeScriptが共存できるのでマイグレーションがやりやすいです。

Migrating from JavaScript · TypeScript

union typeとかあっておもしろいですね。そして最近ではいろんなライブラリがTypeScript対応していてすごいですね。勢いを感じます。他のライブラリのtype script APIを見ているだけでいろいろ勉強になりました。

Atomic Design

時代はAtomic Designだろ!ということでAtomic Design的な画面の作り方をしてみましたが、あんまりうまく実装することができませんでした。デザイン難しいなー。

「Templateはページに必要な全ての要素が詰まったワイヤフレーム」「Pageはワイヤフレームを埋める画像や文字が入ったもの」という点は意識しましたが、よくある「どれをAtomでMoleculeでOrganismにしよう」問題は実感がわかず終わりました。奥が深いね。

それから実装上の細かいやりかたとしてはコレ参考にしましたが、好みが分かれそうだなコレ。私は好きです。

alistapart.com

サーバーサイドレンダリングとの格闘

このサービスの実装における最大の障壁はサーバーサイドレンダリングでした。

ツイッターに画像つき投稿をするんですが、「画像添付ツイート」ではなく「Twitter Card」を使います。Twitter Cardはリンク先URLを含むツイートで、Twitterがリンク先WebページにあるOGPタグから情報を取得して、この記事の最初にあるツイートのような画像つきツイートを投稿することができます。Twitter Cardを使うことで、ただの画像ではなくリンクとしての機能を持つことができるのです。

コレを実現するため、一旦Webページを生成し、そのページが目的の画像をOGPタグの値としてもつ必要があります。そしてツイートするときは生成されたWebページへのリンクつきで投稿すると、Twitterカードとして展開され画像が見えるという仕組みです。(冒頭の図を再掲)

f:id:richard-imaoka:20190507134402p:plain

すなわち生成されるWebページが、ページごと(URLごと)に異なるOGPタグの値を保つ必要があります。そしてWebサーバーから返送されるHTMLの中ですでにOGPタグの値がURLごとに書き換えられていないといけないので、Reactの世界でいわれるサーバーサイドレンダリングが必要になります。

当初静的ホスティングであるFirebase HostingでWebサービスを作ろうと思っていましたが、動的処理を担当するFirebase Cloud Functionsを導入することになりました。

www.youtube.com

生Reactを使っていれば上の動画に従うだけでサーバーサイドレンダリングができたのですが…実はその時点で生Reactではなくgatsby.jsを使っていてそこそこの量のコードを書いてしまっていたので上の動画で説明されている方法が使えなかったのです。

そして…gatsbyでサーバーサイドレンダリングを行う仕組みを考えるのに2週間以上手を止めて考えることになりました。非常に紛らわしいことに、gatsbyにはすでにサーバーサイドレンダリングの仕組みがあるのですが、gatsbyの言うサーバーサイドレンダリングは世間一般のWeb開発者のいうサーバーサイドレンダリングではありません。

www.gatsbyjs.org

Gatsby produces optimized static content by invoking server-side APIs at build time.

世間一般でのサーバーサイドレンダリングは、HTTPリクエストがサーバーに到達したときにHTMLページが生成されることを指します(もちろん、同一URLに対するリクエストにはキャッシュされたページを返しますが)。

f:id:richard-imaoka:20190507180609p:plain

しかし、gatsbyのサーバーサイドレンダリングは「ビルド時」にHTMLファイルおよびjs, cssファイルなどのアセットを生成することを指しており、ビルド時にHTMLファイルが持つOGPタグの値が決定されます。これではURLごとに異なるOGPタグの値を実現することができません。つまり、pinviteの根幹に関わる機能を実現できないということです。

f:id:richard-imaoka:20190507180502p:plain

コレにはめちゃくちゃ困りました…技術的に正しい選択はgatsbyを捨てて、「本来の意味での」サーバーサイドレンダリングができるフレームワークに乗り換えることだったのですが、結構な量のコードをすでにgatsby前提で書いてしまっており「2週間方法を探してみて、ムリだったらgatsby捨てよう」ということにしました。そして…見つけてしまったのです、力技サーバーサイドレンダリングをw

方法としてはとても原始的なもので、単純な文字列置換です。OGPタグの値を「*|twitter:card|*」のような置換しやすい文字としておき、その状態でgatsbyのビルドを完了させます。

<meta name="twitter:card" content="*|twitter:card|*">
...
...
<meta property="og:url" content="*|og:url|*">
<meta property="og:image" content="*|og:image|*">

ビルド後Webアプリケーションをデプロイしたら、HTTPリクエストはFirebase Cloud Functionsで処理されます。Firebase Cloud Functionsはgatsbyが生成したHTMLファイルを読み込み、URLに応じてそのHTMLファイルのOGPタグの値を文字列置換で書き換えます。

const html = usersHtml
  .replace('*|twitter:card|*', ogpValues.twitterCard)
  ...
  ...
  .replace('*|og:url|*', ogpValues.ogURL)
  .replace('*|og:image|*', ogpValues.ogImage)

これによって、HTTPリクエストが来た時点で、URLによってHTMLの中身を変えるという本来の意味でのサーバーサイドレンダリングを実現することができました。そしてgatsbyを使って書いた既存のコードはそのまま活かすことができます。

この仕組を思いつくためにgatsbyのビルドパイプラインの説明をひたすら眺めることになり、「ここに処理を挟めばサーバーサイドレンダリング行けるんじゃ!?」「やっぱダメだったww」を繰り返し、知るつもりもなかったビルドの仕組みに詳しくなっちまいましたw

もう忘れたがね!!!

XSS脆弱性とそのパッチ

「文字列置換」ということで嫌な予感がしてデプロイ前に調べていたら、やっぱりXSS脆弱性を作ってしまっていました。つまり「置換すべきOGPタグの値のフリをして、悪意のあるコードをユーザーが差し込めば…」というやつです。直前に読んだ徳丸本のXSSの章が役立ちました。

OWASP XSS Cheat Seatを参考にXSS対策をして入力文字列のクリーンアップ、そして安全な文字だけがFirebase上に保存されるようにし、たとえ悪意のある人間が攻撃コードを埋め込もうとしても、無害化された上で不正のないOGPタグの値として出力されるように書き換えました。めでたし。

本当は信頼性のある入力値無害化ライブラリを使いたかったのですが、デファクトスタンダードみたいなjsのXSS対策ライブラリを探し当てることができず…なので古典的な方法で、自分で調べて対策な必要なケースを網羅するという方法を取りました。こういう事すると対策漏れが起きがちなので本当は他人の書いたツールを使いたかったんですけどね…

Twitter OAuthとの格闘

OAuthもかなり苦労しました。とにかく調査に時間がかかりました。いまだにOAuthよくわからんw

Twitter OAuthは「ツイッター投稿を肩代わりするアプリケーション」には必要ですが、TwitterのOAuthって1.0aなんですよ。世の中の他の多くのサービスはOAuth 2.0に移行しています。それでもFirebase Authenticationの力を借りればTwitter OAuth対応はそれほど苦もなくできるのですが、理解していないものを導入するわけにも行かず調査をすることに。

FirebaseでWebアプリケーションを作るときはSingle-Page Application構成を取ることはよくあり、client-side JavaScriptで全ての動的処理を済ませてしまう事が多いのですが、Twitter公式になんか恐ろしい文言が載っています。

Twitter libraries — Twitter Developers

Reminder: It is strongly discouraged to use OAuth 1.0A with client-side Javascript.

「なんでじゃ?」と思って私が調査した限りで、なぜTwitter OAuth 1.0aをclient-side JavaScriptで使ってはいけないかを説明します。TwitterへOAuth連携でツイート投稿するばあい、「サーバー側API key/secret」と「クライアント側OAuth token/secret」両方が必要になります。つまりclient-side JavaScriptでOAuth連携ツイート投稿をしようとすると、クライアント側で「サーバー側API key/secret」と「クライアント側OAuth token/secret」両方のシークレットを持つことになり、それは「サーバー側API key/secret」がクライアント側に漏洩しているということです。

client-side JavaScriptでツイート投稿させるわけにはいかず、サーバー側の処理でツイートをする必要があるので、ここでもFirebase Cloud Functionsを利用することになりました。

そしてこのTwitterのツイート投稿用APIが独特でツラ…おもしろい。ツイートのたびにSignatureというやつを生成するんですけど、その生成の仕方が地獄のように複雑。

Creating a signature — Twitter Developers

これを自前で実装するわけにはイカンということで以下のライブラリを使いました。最近はコミットが少ないけど、Twitter APIが枯れたからあまりすることがないのかな?とにかくちゃんと動いてくれました。ありがたや。

github.com

Twitter OAuthトークンどこに保存するんだ問題

さて、twitとFirebase Cloud Functionsの組み合わせによってTwitter OAuth連携でのツイート投稿はできるようになりましたが、まだ重要なセキュリティの問題が残っていました。secretの「保存」です

「クライアント側OAuth token/secret」はTwitter OAuth連携のフローを一巡すると得られるのですが、ツイート投稿の度に同じユーザーに毎回この画面を表示するわけにはいかないですよね。ユーザーにとってはめんどくさくてしょうがない。

f:id:richard-imaoka:20190507114914p:plain

初回OAuth連携後は「クライアント側OAuth token/secret」を保存しないと2回目のツイート投稿以降は「クライアント側OAuth token/secret」が取得できなくなってしまいます。そして厄介なことにFirebase Authentication側(サーバー側)では「クライアント側OAuth token/secret」を保存してくれません。

Can Firebase admin SDK retrieve user auth tokens? - Stack Overflow

f:id:richard-imaoka:20190507185107p:plain

つまりツイート投稿時に必要となる「クライアント側OAuth token/secret」は、クライアント側からサーバー側Firebase Cloud Functions側に飛ばしてあげないといけません。これを「クライアント側でOAuth token/secretを保存し、からツイートのたびに毎回サーバー側に飛ばすのか」と「サーバー側で一旦保存してクライアント側からは初回のみサーバー側に飛ばすのか」は悩みました。

クライアント側で保存し毎回サーバー側に飛ばす処理だと:

  • secretをインターネットに晒す回数が増えるから危険じゃない?
  • 実はFirebase側では内部的にlocalStorageを使ってOAuth token/secretを保存してるんだけど、それをライブラリ経由で取り出す方法はない
  • 無理やりFirebaseで使っているlocalStorageからOAuth token/secretを引っ張り出すこともできるけど、それは実装依存なのでFirebaseのバージョンアップで動かなくなる
  • そうなると自前でlocalStorageにOAuth token/secretを保存する仕組みを作る必要があって、でもlocalStorageはそもそもsecretを保存する場所じゃないし…(いやでもFirebaseは内部的にやってるじゃん。)

サーバー側で保存すると:

  • いざ脆弱性が見つかってsecretが漏れたときに全ユーザのsecretが漏れる

という困った点がありました。結局こんかいはサーバー側でsecretを保存する手法を取りました。

DeployとCircleCI

デプロイの流れはちょっとこだわりました。なにが大事だったかと言うと私にはお金がない!!!お金が沢山あればGitHub Flowに書いてあるような「Gitコミットのたびに個別テスト環境をCircleCIで立ち上げ…」みたいなことをやりたいところですが、何分個人開発なので金がありません。

https://githubflow.github.io

CircleCIの無料枠内で収まるだけのテスト実行回数にしないといけません。Circle CIの無料プランは1000分/月。そしてgatsbyを利用したこのwebサービスは一回のビルドからテストまでに10分ほどかかります。つまり、100回コミットして100回CircleCIが走ったらその月はもう開発できません。サービス初期など一気に開発の進捗を出したいときにコレでは心もとない(いや課金しろよ…)

そこで以下のような仕組みを導入しました:

  • stagingというブランチを作って、stagingに対するコミットは全てCircleCIを走らせる
  • 全ての開発ブランチはstagingに対するPull Requestをあげる。直接開発ブランチからmasterにマージしない。
  • masterへのコミットはstaging -> masterへのマージのみ
  • gitの履歴を保つため、staging -> masterのマージはSquash Commitしない

最後の4点目については、自分で注意して「Squash Commitしない」というふうに気をつけないといけないので、あまり嬉しくありません。一方で、開発ブランチではSquash Commitは使いたいため、一律にGitHub上のルールでSquash Commitをはじくことはできません。なんかいい方法があれば良いんですけどね。

まとめ

ここまで。単なる羅列なのでまとめはありません。

転職面接で私がよく受けた質問とその回答

こんな考え方をする人もいるんだっていう参考になるかもしれないと思ってこの記事を書きます。

先日参加した転職イベントで登壇者の方が転職ブログを書く理由の一つとして「これから転職を目指す人にとって自分がロールモデルとなるように」という発言をされていて面白いなと思いました。私は自分がロールモデルになるにはまだ早いかなと思いますが、参考にはなるかもしれません。

そして自分自身同じ質問を何度も受けることで考えが明確になってきたので、自分自身の振り返りのためにもここに残しておきます。

転職のきっかけは?

前所属先企業がごにょごにょ(ここでは言えない)したので、思い切って退職した上で転職活動に専念しています。

もう一つの理由として、現在6社応募しているので仕事しながら転職活動はムリだな、と。

どんな基準で転職先企業を選んでいますか?

Scalaをやりたいです。

なのでScalaをメインの技術として触れられるポジションを探しています。 それ以外は「理想の職場」をあえて絞らないようにしています。応募しているA社にはA社の面白いところがあり、B社にはB社の…最終的に内定を頂いたところから比較検討する形になりますね。

業種についてもこだわりません。どんな業種でも仕事に打ち込めば面白いところが見つかると思います。

応募している企業は私の知り合い、技術カンファレンスやツイッターでのフォローなどを通して直接・間接的に知っている人がいる企業ばかりなので、「彼らが続けている仕事なら面白さのある仕事に決まっている」と楽観的に考えています。反対に入社前から偏見で判断したくはないですね。

(実際の面接ではここで他の応募先企業とポジションを挙げています)

(もちろん「明らかに効果のない〇〇」とか「騙して売る高額商品」とか、どうしても受け入れられない業種はありますけど、そんなところ応募してないので面接で話さなくてもいいかなと。)

なんでScalaをやっていきたいんですか?

Scalaが好きだから。好きな理由は直感とか感情の話なんで理路整然とは説明できないです。

いくつか理由をあげるとすれば型があることによってリファクタリングがやりやすいとか、ライブラリなどエコシステムが好き、Scala界隈の技術者のフレンドリーさなどありますが、他の言語や技術スタックでも同じ・似た利点が得られるので、Scalaだけが素晴らしいわけではありません。

たとえ話ですが…「腕時計を買う!」って決めるときは直感と感情でもう「買う」って決めちゃう人が多いと思います。その後でオメガだったりロレックスだったり比較検討して、性能を調べたり歴史を見比べたりしてどっちがいいか考えますけど、最初に「買う」と決めた瞬間ははっきりとした理由って説明できないと思うんです。

それといっしょで「Scalaやる!」って決めた理由は、それっぽくは説明できますけど、結局は「ビビッときた」なんですよ。そしてそれが2年以上も続いているので、今も間違いではないと思っています。

長期的に「どんなエンジニアになっていたい」というイメージはありますか?

ないです。5年先とか10年先とか長いスパンでの目標はあえて持たないようにしています。世の中のソフトウェア技術の変遷ってものすごく早いですし、5年経って自分が何に興味を持っているかはまるで予想できません。

2、3年位の短いスパンではScalaメインでやっていきたいと思っています。ただ、Scalaだけをやっていきたいんじゃなくて他の技術も触りたいので(現在の興味はレジュメにかきました)その中で興味が広がっていくといいですね。

あ、あとマネジメントよりは手を動かすエンジニアを続けていきたいです。これは私の人をマネージする能力がクッソ終わっているからなんですけどw

でも他人に教えるのは好きですし、会社が私にマネジメントの才能を見出してくれるなら(ないと思うけど)そっちの方面も面白いかもしれませんね。

あとは流れに任せて好きなことをやりつつ、嫌なことにも耐えつつwどんな方向であれ、だんだん自分の能力が拡大していけばいいかなと。

どんな人達と一緒に働きたいですか?

これも選べないので、あまりこだわりはないです。どんな人ともそこそこうまくやれるんだと私自身は思い込んでますw

あるいは「どんな人とは働きたくないですか?」っていう事を考えるとこの質問への答えは見えるかもしれないですね。だとするとエンジニア前提で、たとえ技術力が高くても自分の考えを絶対譲らないようなタイプは苦手です。チームとして導入する技術を一緒に検討して…という学習のサイクルに意味があると思うので、最初から正解を出せる人が大きな価値を持つとは思えないし、そもそも絶対の正解なんてないでしょ。

ただ「何に対しても絶対自分の意見を譲らない!」なんて人はめったにいないので、普通こだわる部分とそんなにこだわりが強くない部分があるものです。そこはバランスを取りつつうまくやっていくってことかなと。

リモートワークにこだわりはありますか?

事前に公開したレジュメで「リモートがいい!」って言ったからこの質問が来たわけですね。

リモートワークができると嬉しいし、その頻度が高いほど嬉しいです。しかし、絶対条件ではありません。 現実としてリモートワークできる会社は少ないし、Scala使ってるポジションという空きが少ない探し方をしている以上リモートワークは「あれば嬉しい条件の一つ」ってところですね。

ちなみに、リモートワークが嬉しい理由は主にタバコの煙です。オフィスでも電車内でも、タバコの煙にさらされると一気に精神を摩耗します。もちろん電車に長時間乗ること自体も嫌いなんですけど、タバコの煙が何より苦手です。

自分で見た感想

多くの質問に真正面からこたえず「そういうのはないです」みたいに答えるあたり、中二病感あふれる答えですね。実に恥ずかしい限りですが、私は根っからの中二病マインドなのでそこは仕方がないと思います。隠せないw

2ヶ月半で多分50,000kcal燃やして体重が61.5kgになった

エンジニアの皆さん、ダイエットしていますか?

ダイエットに成功すると急にドヤりだすやつ、ウザいですよね!というわけで私もそんなウザい彼らの仲間入りをすべく2ヶ月半かけたダイエットの記録をブログにしてみました。

TL;DR

  • 摂取カロリーと消費カロリーの差で多分50,000kcal燃やした
  • 体重はだいたい6~7kg減って、61.5kg(身長は170cm)、ウエストは77~78cmくらいから68cmになった

ダイエット目標の立て方

今回私は摂取カロリーと消費カロリーだけに注目して、その差を毎日積み上げることだけを目標にしました。例えば:

  • 摂取カロリー = 食べた分 = 2500kcal
  • 消費カロリー = 運動での消費 + 生きてるだけで勝手に消費するカロリー(※) = 700 + 2000 = 2700kcal
  • 差分カロリー = 2700-2500 = 200kcal

とこんな感じの計算になります。消費したカロリーを摂取したカロリーより多い状態にし、これを毎日積み上げていけば痩せるはずです。その差分を記録して(赤線)、目標(青線)と比較したのが下のグラフです。

f:id:richard-imaoka:20190310085023p:plain

最初のうちは一日500kcalの差分を目標に、途中から「もっと行けるんじゃね?」と思い一日1000kcalを目標にしました。が、一日1000kcalは無理があったようで、グラフの右端の方は期間を延長して目標の青線がフラットになっているのですが、それでも届きませんでした。

(※)生きてるだけで勝手に消費するカロリーは、自宅勤務が多くジム以外にほとんど家から出ない私は35歳男性としては少なめの2000kcalに設定しました。

目標の立て方の背景

今回「2ヶ月半で〇〇kg減らす!」とか「ウエスト〇〇センチにする!」という目標の立て方はしませんでした。体重や体型はダイエットの結果でコントロールが効かないからです。

私は7年位ダイエットとリバウンドを何度も繰り返していて、「あれ、こんだけ動いて、食べるの我慢したのに体重増えた…」というのを何度も経験しています。たとえ途中経過でも体重増えるとやる気なくすんですよね。なのであえて途中経過では体重や体型は気にしないようにしました。

反対に摂取カロリーは「食べなければ減る」消費カロリーは「動けば増える」と自分でコントロールしやすく、やった分だけ毎日積み上がるのでここだけに集中しました。

エネルギー保存則という強烈な物理のルールが働くので、消費カロリーが摂取カロリーを上回る状態をずっとつづければ、どこかで痩せるはずなのです。物理の法則に反する体の変化はおこらないので気長に待つつもりでダイエットを続けました。本音を言うとそれでも途中体重を測ってイライラしたりするんですけどね。

2ヶ月半の記録

詳細なカロリー収支の記録はこんな感じで記録していました。

f:id:richard-imaoka:20190312165918p:plain

グラフのオレンジ色のプロット(左軸)は毎日の摂取カロリーと消費カロリーの差分です。プラスの数字が「燃やした」つまり消費カロリーが摂取カロリーを上回った状態を表しています。大体一週間に一回くらいの頻度でこのオレンジ色の棒が下に大きく伸びている日がありますが、これは暴飲暴食をやらかした日です。

ひどいときは3000kcal越えるくらい食べすぎてますね。これ「超過分」が一日に3000kcalなので、1日の摂取カロリーは合計5000kcalです。「生きてるだけで勝手に消費するカロリー」を一日2000kcalとして設定していたので、3000+2000 = 5000kcal。一日3食しっかりたべて、さらにポテチ8袋くらい食べる感じですね。ダイエット中とは思えない愚行。そして超過分を取り返すために必死で走り回ってヘトヘトになるという惨めな行いを何度も繰り返しました。

というわけで、特に面白いとか目からウロコな手法はないんですけど、食べては動いてを繰り返し、私の計算によると2ヶ月半で50,000kcal燃やしました。正確なカロリー計算なんてむりなので10,000kcalとかもっとずれててもおかしくないです。で、結果はこちら。

f:id:richard-imaoka:20190312172139p:plain

乳首は性的なのでモザイク処理をかけています。左がダイエット4週間ほど経過し13,000kcal燃焼したころと、右がダイエット2ヶ月半終わって50,400kcal燃焼したころです。ダイエット前の写真は取り忘れました。

最初の方に書いた結果をもう一度貼ると:

  • 体重はだいたい6~7kg減って、61.5kg(身長は170cm)、ウエストは77~78cmくらいから68cmになった

脂肪1kgあたり7200kcal燃やせば消えると言われているらしいので、50,400 = 7200 X 7 だから最終的にはだいたい期待通りの体重減少が起きたようです。これはラッキーでした。途中経過ではカロリーの差分から予測されるよりずっと体重の減少が少なかったんですよね。最後の2週間位で一気に痩せた感じです。

実のところ体重なんて水分量で大きく変わるんで参考にしかならん数字ですが、ウエストが減ったことはとても嬉しいです。予想以上に細くなりました。

考察

20歳以降でこんなに痩せたのは初めてですね。過去7年間のダイエットの失敗を経て、コントロールできる摂取カロリーと消費カロリーだけに注目したのが良かったと思います。

「自分でコントロールできるものだけをコントロールする」ことに集中するのは仕事でも使えそうですが、あんまりいうと怪しい自己啓発になるんでやめときます。なんかそれっぽい自己啓発の本みつけたらアフィリエイトのリンク貼っとくので買ってください

ダイエット期間中、私は何度も暴飲暴食をやらかしているのですが、それでも痩せられたのは単純に暇だったからです。自宅勤務な上にほとんどまともに仕事をしておらず(おい)、ドカ食いしてジムで3時間走るとかいう、あきらかに無駄な行為にいそしむ時間的余裕があったからです。当たり前ですけどダイエットに集中している間は他のことがおろそかになりますよね。

他のことを疎かにしたくなくて体重も減らしたい人はもっと効率よいダイエットしてください。私は食欲が我慢できない精神力の弱い人間なのでこんな形になりました。

いかがでしたか?もしこのダイエット記事が気に入ったら、写真の乳首をポチッと押してください!