ピアノはじめました – 息子もがんばってます

今日は今まで書いたことがない話でも書きます。今年の早春ごろから、ピアノを始めました。
もともとは息子が昨年秋から始めたものだったのですが、いつの間にか自分も始めていたというものです。

「現状」「きっかけ」そして「息子への影響」の3点について書きます。

現状

5歳(保育園 年長)の息子と一緒に、週1回 45分/人(合計90分)のプライベートレッスンを受けています。明確に先生から分類を言われたわけではありませんが、以下のようにテキストを使い分けています。

クラシックが増えているのは、先生と雑談している時に「POPSでもYOSHIKIみたいにクラシックがちゃんとできる人はいいですねー」と言ったら出てきてしまったテキストであり、弾きたい曲は「ShakatakのInvitationsとかNight Birdsってかっこいいですよね」と話したら「昔弾いてたんでやりましょうかー」となり、いつの間にか増えていました(?)。

3月からレッスンを始めて、昨今の状況で春はオンラインレッスンを挟みつつ、二人で続けているという状況です。どのくらいのレベルになったかは、いろいろ書くより、実際に弾いている動画をアップしておきます。実はYouTubeへアップするのはこれが人生初めてです。

アルペジオの音がでかいというか硬いというか表情がないのもありますし、鍵盤を叩く手がコンピュータのキーボードを叩くその時とほぼ同じで、いろいろ改善点が多いです。実際、レッスン中にも指摘されます。少しずつ良くしていく気持ちはあります。

進捗としては、「バーナム ピアノテクニック 導入書」は先日終了、「おとなのためのピアノ教本 1」は6月までに終了、という状況です。バーナムは1週間あたり3つクリア、楽曲は1週間2曲クリアを目標として取り組んでいます。

自宅での練習はこんな流れです。

  1. レッスン日に課題曲を先生にデモを弾いてもらいiPhoneに録音する
  2. スコアを読む
  3. 先生のデモを聞く
  4. 弾いてみる
  5. 「スコアを読む」〜「弾いてみる」をループする
  6. 録画してセルフチェックしさらにループする
  7. レッスン日に評価をしてもらう

スポーツでもなんでもそうなんですが、録画して確認すると、自分なりにセルフチェックしやすいのでおすすめです。

どんなタイミングで弾いているかというと、最近は在宅勤務なんで、平日はお昼休みに生音を出しながら練習しつつ、終業後の夜はサイレントモードにして取り組んでいます。休日は、息子と一緒に or 邪魔されつつも(!)練習しています。特に、平日に弾くのは気分転換に大変良いです。それに、弾いている時はプログラミングをしている時と同じように集中しているような気がします。

なお、練習して間違っていると、息子や相方から「あ、そこ間違ってる!!!」と指摘され、割と凹みます。褒められることはありませんwww 特に、息子はいつの間にかスコアを見ていたり、耳コピして覚えてしまうため、間違うとすぐ気になるみたいです。

きっかけ

息子のレッスンの引率に行った際、先生の家にあったグランドピアノ(YAMAHA C3)が、当時家で使っていた電子ピアノ(YAMAHA CLP-645)と違って、アコースティックピアノは倍音が出ていいなぁ…なんてふと思ったことが口に出たのがきっかけでした。そして、いろいろ話しているうちに、お父さんもいかがですか?となり、お試しをしたところいい感触だったのではじめた、という流れです。

それだけではなくて、前々から一緒にライブを聴きにいく人ですとか、実際に演奏している人に、こえむさんもなんか楽器やってみるといいですよ?と言われていたのも少なからず影響はありました。ただ、小さい頃から始めていないと厳しいんじゃないかなーという先入観があり、実行には至っていませんでした。

また、実家に父が使っていたアップライトピアノがあったのですが、僕は全く触る機会はありませんでした。今考えれば惜しいことをしたかもしれません。

相方も、仕事とは違った脳味噌を使うしいいんでないの?ということで、ポジティブには思ってくれているみたいです。

ちなみに、お試しレッスン後に弾いた時の様子を、息子がiPadで撮っていたのでそれもアップしておきました。2月中旬のものなのですが、ほんと第一歩感あります。

その後は、自分がハマるにつれて、いつのまにか山野楽器 銀座本店の担当者のMさんを先生から紹介されて、気がついたらアコースティックのアップライトピアノ、それもサイレント機能付き(YAMAHA YUS3SH2)が家にある、という状況です。なお、電子ピアノは先生の新しい生徒さんのもとに旅立っていきました。

息子への影響

以前、小中学生向けプログラミング教室を手伝っていた時のように、一緒に取り組む、それだけなのですがそれがどうやら好影響を与えている、というのが先生と相方の評価のようです。

プログラミングは職業として取り組んでいるため、あわよくば「教える」なんて行為ができるのですが、ピアノは教えることはできません。しかし、横でお父さんがやっているのを見て、どうやら、僕も負けないぞ!という気持ちが高まるらしく、それが継続の原動力になっているようです。プログラミング教室の手伝いの時に、共に学ぶという感覚を掴んでおいてよかったなと振り返っています。

親になると、どうしても「〇〇(例:勉強)しなさい!」と言いがちなのですが、皆さん振り返ってください、まあしないものです。それでする子は動機付けが素晴らしい親御さんです。そこで、一緒に取り組み、一緒に学ぶというのは、それほど難しくなくかつ自分にも効能がある取組方法なのだなと思います。学校の勉強だといつか限界が来そうな気がしますが、広く教養のことになると、レベルに関わらず取り組むことができそうな気がします。

息子があまりやる気がないと、息子の現時点での課題を僕が弾いてしまいます。そうすると、息子が僕が鍵盤の前から押し退けて弾き始めます。邪魔すんな!と思いつつも、やる気があるのは良いこととも思うようにしています。そうそう、子供用のスコアは手が小さいことが考慮されているせいか、度数がそこまで大きくないので、割と取り組みやすいです。

あと、うまい人はどうかと、YouTubeのピティナの公式YouTubeチャネルを一緒に見たりしています。ここは、手元をちゃんと映してくれるので、いろいろ参考にしやすいです。最近はなんでも動画があがっているので、練習も捗ります。

なお、最近は息子の課題に「連弾」があり、僕が連弾の先生パートを弾けないと普通の合格止まりで花丸合格にたどり着けない、というハードルができました。なので、息子に「ちゃんとやってよー」と言われるようになりました。連弾は息が合わないと難しいですね…。

まとめ

最近、ピアノをはじめました、ということで、「現状」「きっかけ」そして「息子への影響」について書いてみました。在宅勤務での良い気分転換になること、そして息子の動機付けにもよさそう、ということがわかってきました。

いつかはライブとかに出てみたいですね。そのときまで、家でじっくり練習しておくつもりです。

プログラミングを始めたきっかけ – 1997年にさかのぼって

今年は2020年。まもなく30代を終えようとしている歳になった今、改めてなぜプログラミングを始めたのか。そのことを振り返ってみようと思います。

6つの節「コンピュータを購入するきっかけ」「購入してから開発を始めるまで」「インターネットに接続できるようになってから」「PDCAを自然と知り始める」「就職に至るまで」そして「今、昔の自分に何を伝えるか」にわたって書いていきます。

まあ、思い出話なので、軽い気持ちで読んでください。そして、現代は状況がまるで違いますから、この状況をそのまま適用できるわけではなく、今の生き方に参考にはならないことを、あらかじめお断りしておきます。

TL;DR

ソフトウェアエンジニアリングは、僕が社会につながって価値を提供することができる、素晴らしい技術であることを10代の頃に知ることができました。

でも、学校の勉強はちゃんとしておくべきで、ストレートで大学院を修了して、人生の選択肢をたくさん持てる状況を作ることが大切だと今は思っています。

コンピュータを購入するきっかけ

1997年、23年前、僕が高校1年生の頃にまでさかのぼります。父に、高校入学祝いにコンピュータを買って欲しいとお願いしたのが直接のきっかけです。

そもそもコンピュータを購入したい理由は、中学校の技術家庭科でN88-BASIC(86)でプログラミングの授業を受けた時、教科書にあったコードを写経して発表する際、友達からRND命令(乱数)を教えてもらって、コードを改造して図形の花火を飛ばしてみんなを驚かせることができ、「プログラミングって人を驚かせられるのか、こりゃすごいな!」という原体験がありました。

また、当時アマチュア無線をしている際に出入りしていたアマチュア無線機店が店舗オリジナルの自作PC/AT互換機のキットを販売しており、コンピュータって組み立てできるのか、面白そうだなということを知ったのもありました。ちなみに技術家庭科のプログラミングの宿題は、アマチュア無線機屋に置いてあったコンピュータでやっていました。

こうして、当時としては結構高めのPC/AT互換機、CPUがPentium 200MHz(単位はGHzではありません)、RAMが64MB(こちらもGBではありません)と共に、プログラミングを始めるためにMicrosoft Visual Basic 4.0を添えて買ってもらったのでした。

購入してから開発を始めるまで

当時、コンピュータを買ってもすぐにはインターネットに接続はしていませんでした。今のように常時接続の固定回線は一般家庭には普及しておらず(OCNエコノミーが最も安くて38,000円/月(3,800円ではありません), 128Kbps(Mbpsではありません)のベストエフォート)、一般家庭からはアナログの電話回線にモデムを繋ぐか、ISDNのTAかルーターを使って、従量課金またはテレホーダイという11pm〜8amまでの時間限定固定料金で接続するのが主流でした。

では、どうやってプログラミングの勉強をするかというと、公式ドキュメントか本しかありません。しかし、当時高校1年生の僕には公式ドキュメントをどこから読めば良いかさっぱりわからず、本屋に行って限りあるお小遣いから入門書を買うのでした。

先生や質問できる人は誰もいなかったため、一通り写経して、あまりよくわからない時に、Windowsのヘルプ形式で割と検索しずらかった公式ドキュメントを開いて、それを往復するというのをやっていました。

そのうち、だんだん慣れてきた頃に、なんか作ろうかと考え始めた際、アマチュア無線機屋さんで「フォントの管理って大変だよな」「フォントをいっぱい入れるとWindowsのリソースを食ってよくない(当時フォントを入れすぎるともともと不安定なWindows 95がさらに不安定になった)」そして「フォントはディスク容量を食うから選別して入れたい」という話を耳にしました。

それなら、試しに管理ツールを作ってみようと考えて作り始めたのが、Font Managerというフォント管理ツールでした。このWindowsアプリケーションは僕のソフトウェアエンジニアとしての原点となるソフトで、この後も言及していきます。

インターネットに接続できるようになってから

親にどうしてもネットに繋がせて欲しいとずっとお願いして、学校の成績が良ければ敷こうという約束を取り付けました。その約束を達成すべく、その時だけ勉強をし(!)、見事にクリア。33.6Kbps(やはりMbpsではありません)アナログモデムからでしたが、インターネットに接続する環境を得ることに成功しました。

直ちにWebサイトを作成(記録では1997/10/27)し、続いてFont Managerもフリーソフトウェアとして公開を始めました。これを機に、様々なオンラインソフトウェア収録サイトや雑誌から収録依頼があり、少しずつですが拡散していく手応えを感じることができるようになっていました。
検索してみましたら、インプレスの窓の杜にある新着ソフトウェア一覧にピックアップされている記録が残っていました(1998年「8月28日掲載のオンラインソフト」にあります)。
また、ソフトバンクの月刊紙「PCJapan」をはじめとした雑誌に定期掲載をしていただけるようになり、コンピュータ雑誌が自由に読めてよきかなよきかなと思っていたりしたのでした。

Webサイトを公開するようになると、当時多くの人が手を出したのが「掲示板」のCGIアプリケーションでした。Webアプリケーションの走りですね。
CGIレスキューさんをはじめとしたコードを公開しているサイトからコードを取り寄せ、プロバイダのマネージドのWebサーバにFTPで(もう使わないですね…)Putし、パーミッションを書き換えて、実行…しようとしたら動かない、というご経験をされた人はおそらく30代以上です。
printデバッグを駆使してコードを書き換え、なんとかHTTP 200が返って来るようになってうれしかった覚えがあります。

開発情報を取り寄せる方法は、もっぱらニュースグループでした。ニュースグループとは、ニュースサーバ間をリレーしてメッセージをやり取りできる、分散型の掲示板みたいなものです。当時高校生だった僕からすると、結構怖い人がいっぱいいて容易に質問できる状況にはなく、半年ROMる大切さはここで覚えた気がします。

PDCAを自然と知り始める

そうこうしているうちに、PerlでCGIアプリケーションを少しずつ書けるようになり、WindowsアプリケーションはVisual C++も使うようにして低レベルAPIも叩きながら開発することができるようになってきました。その際、メモリのヒープ一覧やブレークポイントを使えるVisual Studioって素晴らしい、ということでした。今だとWebアプリケーション開発でも使えるようになって、良い時代になったなと思います。

英語を覚えたのは、Visual C++で開発する際に、MSDNのAPIドキュメントが当時英語で書かれていたため、それを読破するためでした。高校の英語の勉強はさっぱりしなかったのに、英語の開発ドキュメントは読むのかと親から呆れられた覚えがあります。とはいえ、今になって英語のドキュメントに抵抗がないのはこれのおかげだと思っています。

また、インターネット上にソフトウェアを公開すると、利用者からメールで、質問やバグレポートが届くことがよくありました。ここで、世の中にはカスタマーサポートってのがある、ということを知りました。しばらくすると徐々に同じ質問が来るようになるので、FAQのページを作って問い合わせ量をコントロールするようになりました。

そして、利用者の声を反映してソフトウェアを改善していくプロセスも、ここで自然と取り組み始めるようになります。この時はPDCAサイクルという言葉は知らず、知ったのは20代にスタートアップに転職した時ですが、自然と取り組み始めていたようでした。

ただ、後で知ったことですが、東京の進学校に通っている人には、学校にコンピュータ部があり、部活内で教えあったりする文化があったとのことです。僕は当時、福岡市内にある普通の私立高校に通っていて、プログラミングに関する人の交流は全くありませんでした。こういう機会があれば、もっとプログラミングのスキルを伸ばせたのかもしれません。

就職に至るまで

ソフトウェアエンジニアとしていい感じにやられていたんじゃない?そう思われるかもしれません。いやいや。プログラミングをやりすぎて、学校の成績は絶望的な状況にまで落ちていまして、赤点すれすれの低空飛行を続けていたのでした。数学の解析と、物理の電気関係以外。

当然、大学受験には失敗します。一度浪人して再チャレンジしようとしましたが、これも失敗。父親に泣いて詫びて、就職します、と話したのが2000年です。割とその時は絶望していました。

その後、運良く大手総合電機メーカーの子会社に契約社員としてソフトウェアエンジニアの道に本格的に踏み入れることになります。この話以降は、以前に書いた「私のキャリアキーノート 2017年版」に続いていきます。

今、昔の自分に何を伝えるか

ちゃんと勉強して、ストレートに大学院に進んで、選択肢を持って就職して欲しいと伝えます。しかし、こういうのって多くの人は親から言われてきた言葉で、また多くの人はちゃんと勉強していたはずです。僕は高校生時代にプログラミングにハマってしまい、勉強の理由を見つけることができなかったのがよくなかったと思っています。こういうの、ちゃんと理解が進むように誰かに壁打ち相手になってもらい、話し合って理解しておく必要があったのかもしれません。

僕の場合、運良くソフトウェアエンジニアの仕事を見つけることができて、今も運良く仕事をすることができています。

僕の知る限り、現代において、ソフトウェアエンジニアになるには、大学院で計算機科学やソフトウェア工学を十分に学んでおく必要があり、僕のようなぽっと出の人がソフトウェアエンジニアとして活躍できるような時代ではないという実感があります。
それとも、尖った技術を使ったソフトウェアをOSSとしてGitHubなどでコードを公開し、社会に価値と提供しつつ存在感を出すことで、自らの道を切り拓いていくこともあり得るかもしれません。
または、ソフトウェアエンジニアリングとは違う部分で地に足のついた知識と経験がある人が、ソフトウェアエンジニアリングを学んで新たな価値を生み出すかの、いずれかだと思います。例えば、経理や法律に詳しい人が、ソフトウェアエンジニアリングを学ぶケースが当てはまります。

なので、この方法を真似することは一切お勧めしないし、参考にもしないで欲しいと思っています。この記事は僕が書きたくて書いた昔話で、僕のことに興味がある人が読んでくだされば良さそう、というものです。

あえて書く学びがあったとすれば、コンピュータソフトウェアの技術は、僕が価値を提供しつつ社会につながれる、素晴らしい技術であることを10代の頃に知ることができたことでしょうか。

4年あまりの思い出

この4年あまりの仕事を振り返ります。記憶が薄れないうちに、だらだらと起きたことを書いています。

3月の上旬、在宅勤務令が出ている中、所用でマネジャーの許可をとって久しぶりに会社に出勤した時に撮りました。平日の8pm前なのに、コロナウイルス騒ぎの影響で人が少ないです。

TL;DR

メルカリ(以下、現職、会社)を退職します。大変お世話になりました。ありがとうございました。この4年3ヶ月の間、何事にも代えがたい、貴重な経験ができました。

2015年 年末

あるカフェで、現職に勤めている人から、一度話を聞いてみませんかと勧められ、カジュアル面談に足を運びました。現職は、当時バックエンドにPHPを使っていたのですが、僕はPHPをほとんど書いたことがありませんでした。それをsotarokさんに伝えると、「他の言語は書けますよね?ならPHPも覚えられますよ。」と言われて、そういうものかと納得。この判断が、この後大変なことになるともつゆ知らず。

カジュアル面談後、あれよあれよと面接を勧められ、あれよあれよと面接のステージを進み、いつの間にか進太郎さんとの最終面接へ。気づいた時には内定が出ていました。

2016年 上半期

2016年1月にバックエンドエンジニアとして現職に入社しました。社員番号は百数十番目でした。初めての六本木ヒルズでの勤務、きれいなところだなー、とおのぼりさん気分でオフィスの扉を開けました。当時は六本木には数十人しかおらず、フロアの何割かしか使っていない状況でした。

PHPの開発を始めたのですが、いかんせんボロボロ。日本のPHP界を支えたエース級のソフトウェアエンジニア、そしてITインフラを支える腕利きのSREの人たちに囲まれ、僕が書いた現職の品質に耐えないコードに、プルリクエストのコメントが入りっぱなしでした。あの熱意に感動しつつも、その物量に圧倒され参っていたのもまた事実でした。試用期間の3ヶ月の間、帰宅すると相方から「葬式から帰ってきたみたい」と心配されるくらいです。

それからは、必死に毎日出社すると、昨日更新されたすべてのプルリクエストを読んで、PHPのコードの書き方と、業務をとにかく覚える日々でした。なんとか戦力になることに必死でした。夏ごろになると、ようやくなんとか一人でやっていけるほどになりました。なんとか見放さずに居させてもらえていて、これからは価値を提供せねばとという思いが強まってきました。

当初より、US版の開発に配属されたのですが、当時はコードベースが日本版とかなりの部分が共通でした。そんな中、出品のグロースを担当する部署で、アジリティここにありというスピード感満点の開発とリリースが繰り返されました。

2016年 下半期

ようやく現職に慣れて来た頃。US版の出品のグロースの担当は変わらずに取り組んでいた矢先、隣のチームで後に「招待爆発」と呼ばれるイベントが発生しました(詳細は「一晩でインストール数10倍、米AppStore3位に メルカリ「招待爆発」の裏側 | ログミー Biz」をどうぞ)。社内は大いに盛り上がっていました。

それから、所属するチームでKYCを始めとした本人確認の仕組みの開発が始まります。はじめはサービスのグロースと違う開発だったので戸惑いがあったのですが、過去にSIerに勤めていた経験もあり、業務知識最高やな!と気持ちを切り替えて乗り切ることができました。そして、これは後々活きてくることになります。

同時に、秋に初めて仕事で海外出張をすることができました。サンフランシスコのオフィスです。海外出張、ただそれだけで感慨深いものでした。

2017年 上半期

現職のサービスが、日本で誰もが知る状況なったのが、この頃でした。自分が担当するサービスが、mixiのように山手線内でみんなが当たり前のように使ってもらえたらいいなと願って約10年。本当にそういう時代が来たんだなと感慨深い日々でした。

僕は春から3ヶ月ほど、サンフランシスコに長期出張となりました(その頃の話は「サンフランシスコ出張を終えるにあたって」をどうぞ)。出張1週間前に指示されたできごとでしたが、会社のおかげで、本当に良い思いをさせてもらえました。こんなことは、なかなかできるものではありません。感謝にたえません。

2017年 下半期

日本に戻って、担当も日本版となりました。引き続きサービスのグロースのための開発に取り組んでいました。担当分野は変わるものの、昨年一緒に仕事をした同僚ともまた一緒になったため、割とやりやすい環境にありました。その中で、決済や出金といった割とコアな部分の担当もこなすことが増えてきました。これも、来年以降活きてくることになります。

また、急成長するサービスの前に、SREのメンバーとともにリアルISUCONに取り組みました。モニタリングツールで確認できる負荷の数値が減ると、グッとガッツポーズが出ます。また、この規模ですと結構な台数にインパクトが出るので、インフラコストに対してもポジティブに働きやすいのも、やりがいを感じやすい要因の一つになりました(詳細は「たのしいリアルISUCON – Mercari Engineering Blog」をどうぞ)。

会社もみるみる急成長。人の採用もどんどん進んで、フロアはますます広くなり、当初は空席ばかりで「本当にこんなに人を雇うの?」と感じていたのが杞憂だったどころか、「これ、今度どこに座ってもらうのだろう?」という状況になるのにはあまり時間はかかりませんでした。

2018年 上半期

1月より、この月から本格的に立ち上がる電子決済サービスの子会社であるメルペイに出向することになりました。昨年末に公募があり、応募したところ通りました。

この頃も、引き続き会社にたくさんの人が入社し続けました。特に、日本人ではない、外国籍の人がかなり増えてきたのが印象的で、社内公用語も自然と英語にシフトしていくのでした。サンフランシスコにいてなんとか英語を話していたものの、日本にいるとどうしても日本語を使ってしまうので、積極的に英語で話すよう努力するところから始めるのでした。

メルペイの立ち上げにあたって、まずはアーキテクチャを考えるところでかなり大変だったのを覚えています。その頃の話は「mercari tech conf 2018 で決済のマイクロサービス化についてお話してきました」にまとめていますので、どうぞ。同時に、Microservices化が進むようになり、会社内で使用するプログラミング言語もPHPからGoに急速に変わっていきました。状況の変化に追いつくので必死で、人の顔もわからなくなりつつあって、大変になってきたのを覚えています。

そして忘れてはいけないのは、6月19日の株式上場でした。このときの正直な気持ちをいうと、会社って上場できるんだ!ということでした。今まで勤めていた会社の中で「会社を上場させる」という話を聞いたことがあっても、実現できたのは今回が初めてでして、感慨もひとしおでした。上場日、会社の広場でワールドカップのグループステージを観戦しながら、日本のゴールのときに小泉さんとハイタッチしつつ、みんなで喜んでいたのをよく覚えています。

2018年 下半期

10月にPayPayがサービスインし、本格的な電子決済サービスの時代が幕を開けました。僕らも急ピッチで準備を進めている最中でした。

同時に取り組んだこととして、中学生・高校生向けのプログラミングコンテストである、情報オリンピックの世界大会の協賛に関わる取り組みを行なっていました(その模様は「第30回 国際情報オリンピックに協賛しました #ioi2018 – Mercari Engineering Blog」へ)。協賛を通じて、これからソフトウェアエンジニアになるかもしれない世界中の若人を応援できればという想いからでした。これ以降、次年度の日本国内大会の支援も継続しています。

現職は、人もますます増えていき、担当が細分化されていきました。僕は2017年の経験をベースに、出金部分に集中することになります。この時期は、まさに産みの苦しみに直面する時期でした。

そんな中、僕は初冬に体調を崩してしまい、年内は週休3日にする許可をもらってなんとか開発を続けました。今振り返ると、ほかのチームと、よくリリーススケジュールの足並みをそろえて開発しきれたなと思っています。スタートアップを何社も経験してきていますが、サービス立ち上げの追い込みのときほど苦しいものはありません。なぜこの苦しみをいつも味わってしまうのか、本当に反省が全くありません。

2019年

2月13日、とうとうメルペイがリリースできました。ただ、その後も運用がこなれるまでは様々な対応をする必要があり、まだまだがんばる必要がありました。とはいえ、リリースを迎え、社内は熱気に包まれていました。リリース後も、時々、組織が立ち上がってからリリースまでに撮影した写真やビデオを見返すのですが、その度に初心に返ることができます。会社のGoogle Driveに写真とビデオを、そのまとめはWikiに保存してありますので、社員の方はよければどうぞ。

その後、徐々に落ち着いていくと、運用を固めていく段階に入っていきます。SREばかりではなく、ソフトウェアエンジニアが運用・監視に責任を持つ、Microservicesならではの体制が浸透していきます(詳細は「How do we share troubleshooting skills – Mercari Engineering Blog」をどうぞ)。このエコシステムを運用できるようになっていく状況は、前職でインフラエンジニアをやっていた僕にとって、大変興味深いものでした。

同時に、セキュリティの知見を自分で深めるために、同僚と共にHardening Projectの予選・本戦に出場しました。レポートは「セキュリティの「衛り」の全国大会 Hardening II SU に出場してきたよ – Mercari Engineering Blog」にまとめてあります。また、Software Designへの寄稿の話ももらいました(「Software Design 短期連載「Webサービスを裏で支える!! バッチ処理設計の勘所」を終えて」をどうぞ)。

とはいえ、僕の主たる業務は決済・出金基盤の運用に注力するあまり、これといって「数字」に影響を与えられる開発に関与できていませんでした。むしろ、そうですね、もっと別の貢献の仕方があったのかもしれないと、今になって考えます。Alertチャネル(障害が起きた時の第一報を伝える全社向けSlackチャネル)を通じて一部の人に名を知られる状況になってしまったのも、何かあるとインパクトのある出金業務でお客様への影響は最小限だったとはいえ、大変不名誉なことでした。

また、ソフトウェアエンジニアリングを高等教育機関でしっかり学んできた若手が力をつけているところも、同時に見てきました。このことは、僕が自分のキャリアに対して危機感を持たせるには十二分な状況でした。

そして年末、退職することを決断しました。

2020年

3月末までに、今の業務をチームメンバーに引き継ぐ、このことだけにすべての力を注ぐことになりました。会社のバリューをしっかり実践する同僚のみんなに協力をもらい、出金に関わる複雑な業務、ステークホルダー、そしてソフトウェアの構造を引き継いでいきました。

その中で、リリース後は企画・開発・運用をほぼ一人でやってきた弊害として、資料化・可視化・再現性のある取り組みが足らないことを実感し、なんとしてでもそこを補強して組織で取り組むことができるようにすることが、僕の最後の使命でした。

この時期、みなさまの記憶にも新しいことですが、コロナウイルス騒動の影が徐々に濃くなりました。2月下旬、とうとう現職でも在宅勤務令が発令され、一人一人が自宅で業務を続行することになりました(「在宅勤務を半月以上取り組んで…会社で仕事するのがやっぱりいい」をどうぞ)。それは、僕が退職する3月末まで続いています。間に作った出社日に、何名かの方にごあいさつをすることができ、送別会もボスの取り計らいでオンラインで開催してもらうことができました。一時は誰にも挨拶できないのではと心配しましたが、なんとかなったことにはホッとしています。

今後について

4月1日より、新しい会社で働くことになります。2011年に飛び級して大学院に入学した時を思い出します。僕が新しいことに取り組むときは、いつも大変な波乱の中での始まりであると。

現職の社内で、キャリア形成に対して「韮」という考え方があります(韮については「メルペイからメルカリグループ全体のコーポレート統括へ。横田淳の決意 | mercan (メルカン)」をどうぞ)。僕はこの韮という言葉に大変感銘を受けて、これからはソフトウェアエンジニアとしてのこれまでのキャリアを韮の1本目として、もう1本をこれから作っていくよう取り組んで行こうとしています。どうなるかわかりませんが、新しい挑戦を通じてまた新たな価値を生み出して、世の中に貢献していく所存です。

おわりに

エキサイティングな職場で、エキサイトせずに冷静に物事を進めるプロフェッショナルの集団、それが現職でした。

ただ、僕は特に歴史に名を刻むどころか、バリュー賞をはじめとした目立った賞を取ることもなく、ただただその時々に必要な仕事に取り組んだ一社員に過ぎませんでした。

とはいえ、その歴史の渦中に身を置けたことは、何事にも代えがたい貴重な経験でした。そのことには、本当に感謝にたえません。そして、僕も他のお客様と同様、メルカリが生活の一部となりました。もう一度同じ経験ができるとは、正直思い難いほどです。

とても長くなりました。

4年3ヶ月いた現職を去ることにはなりますが、引き続き「インターネット株式会社」には所属しています。本来ならば、現職の皆様には直接ごあいさつをしたいところなのですが、このコロナウイルスに伴う在宅勤務が続く状況でそれも叶わず、残念です。またどこかでお会いすることがありましたら、どうぞよろしくお願いします。

そして、関わっていただいたすべての皆様に、深く、深く感謝をいたします。どうもありがとうございました。

在宅勤務を半月以上取り組んで…会社で仕事するのがやっぱりいい

2020年2月19日から、勤務先で在宅勤務令が出ました。理由は、もちろんみなさまご存知の通り、新型コロナウイルスの感染拡大防止が目的です。それ以来、今週(3/13)にかけても在宅勤務は続き、この状況はしばらくは続くと想像します。

テレビはどこのニュースもコロナウイルスの話です。日本のチャネルばかりでなく、CNNやBBCなどの外国のニュースまでもこの話一色です。状況のあまりの酷さに気が滅入ります。

さて、ソフトウェアエンジニアなら一度は憧れるであろう、完全在宅勤務。実際にこの状況を半月以上体験して見ての感想をまとめてみます。いろいろな考え方があると思うので、あくまでも僕の私見としてご覧ください。

TL;DR

仕事は原則会社でやりたいです。同僚とリアルに顔を合わせられることがこれほど尊いとは思いませんでした。とはいえ、在宅勤務は事情に応じて自由に選択できるのが良いとも考えます。

どんな環境で在宅勤務をしているか?

感想をお話しする前に、前提となる在宅勤務の状況について、簡単にお話しします。僕は、バックエンドソフトウェアエンジニアです。そのため、ひょっとしたら同じ会社でもロールによって状況は違うかもしれません。現在、勤務先では以下の業務のサービスを利用しています。

  • G Suite (Gmail, Google Calendar, Google Meet, Google Drive, etc…)
  • Slack
  • GitHub
  • 出退勤管理はbotがいる
  • Google Cloud Platform: 特に開発環境
  • その他, Wiki, Atlassian Jira, SmartHRなど

これらのサービスはすべてSaaSでして、その多くは多要素認証(MFA)を元にシングルサインオン(SSO)で利用できます。もちろんVPNはあるのですが、特殊な業務ではないかぎりVPNは使用しません。なので、VPNが重くて仕事にならない、ということはまずありません。

これらのサービスを使えば、通常のコミュニケーションはSlackで伝え、会議はGoogle Meetを通じて行い、作業はJiraで管理し、ソースコード管理はGitHubでできるため、ほぼ会社にいる時と同じ状況で仕事が可能です。そして、これらのサービスを普段から利用しているため、使い方についてのトラブルは特に聞いたことがありません。これは、社外のいろいろな人の話を総合すると、割と恵まれた方なのかもしれません。この環境を維持してくれているIT担当の方々へ感謝しています。

また、自宅にはNURO光とマンション内LAN(バックアップで残した)があり、会社ほどではありませんが高速なインターネット環境を確保しています。家庭用複合機もあるので、手書きの資料を電子化して共有する時のためにスキャナーを使うこともできます。

孤独は辛い

「なんだ、こえむさんの家、十分環境が整っているじゃない。」
おっしゃる通りです。だからこそ言わせてください。

孤独は辛いです

いかに、自分が会社に出社して、多くの同僚に囲まれて、時にはふとした雑談も織り交ぜながら仕事に取り組んでいたのか、身に染みてわかりました。家で仕事をしていると、打ち合わせ以外は誰とも話すこともありません(みんな効率よく仕事をこなすので議題が済むと即解散です 素晴らしいことではあります)。また、日中は相方は時差出勤中、息子は保育園にいます。オンライン雑談タイムを作っている人も目にはするのですが、あまり知る人ではないのもさることながら、オンライン会議で複数人で雑談するのは話の間合いを捉えるテクニックが必要で、ちょっと負担を感じました。

また、ほとんど体を動かさなくなります。オフィス内を動くことはもちろんなくなり、通勤もなくなり、移動距離がグッと少なくなります。首・肩・腰に違和感を感じる同僚もいるようです。僕も腰が痛いです。運動をしたいところなのですが、この状況で週2回以上通っていたジムに行くこともできなくなりました。できて、感染のリスクが少ない、休日にロードバイクに乗るとか、家族で車に乗って登山に行くくらいです。

あと、iOS, Androidのクライアントアプリを開発している同僚は、会社で使っている馬力のあるコンピュータ(iMac Pro)が使えないのも、大変だと話していました。特にバイナリのビルドに時間がかかるみたいです。他のロールの人で、僕が知らない困ったことを持っている人もいるかもしれません。

その他、家の電気代があがるとか、宅急便が来ると作業が止まって案外対応が大変(配達員の方ごめんなさい)だとか、やってみて知る問題もありました。言い出したらキリがなさそうなので、この辺にしておきます。

かろうじて、時間の感覚だけは残っています。息子を保育園に送り迎えする時間が時報がわりです。中には、時間の感覚を失いつつある同僚も目にします。おそらく、自宅ですと時間帯による周囲の環境の変化が極端に減るからだと思われます。

この状況で、とても孤独を感じ、体もだんだん重くなる感覚が抜けません。

久しぶりに出社した

実は、月曜日・火曜日に、マネジャーの許可をもらって久しぶりにチームメンバーほぼ全員が出社しました。もちろん、時差出勤で。この日は集中ワークショップ日にしたのですが、コミュニケーションはやはり膝を突き合わせたほうがスムーズでした。また、昼はおいしいピザをみんなで頬張りながら、久しぶりにどうでもいい話をしました。

また、業務上の理由で出社している別の部署の同僚がほんの少しいたのですが、たまたま古くから顔馴染みだったこともあり、久しぶりにのんびり話すことができました。こうすることで、自分は一人じゃないんだなと確認できます。

僕の中では、やはり会社で仕事をすることが、自分には合っているんだなと確認できた日になりました。また、自分にとって、家は仕事をする場ではなくて、Offになるための場所であることも、同時に理解を深めることになりました。

良いことももちろんある

在宅勤務になって、全てが悪くなったわけではありません。良いこともありました。

  • 保育園の送り迎えがすぐできる オンコールがあっても対応しやすい
  • 家で過ごす時間が長くなる
  • 通勤ラッシュから解放される

最も効果を感じるのは、保育園の送り迎えです。非常に楽です。保育園からのオンコールも1回あったのですが、すぐに迎えに行けて助かっています。もちろん、通勤時間がなくなり、家で過ごす時間も長くなります。そのため、家事や息子と遊ぶ時間も長めに取ることができます。通勤ラッシュから解放されることも、良いことです。

僕の在宅勤務の捉え方について

僕には、完全在宅勤務は向きませんでした。主に、精神的な理由で。コロナウイルス騒ぎが、それを加速させていることもまた事実です。

少なくとも、在宅勤務をする時には、あらかじめリアルで顔を合わせている同士で人となりが分かっていることが大切であること。そして、会社で仕事をするときとは違い、体を動かしたり1日の時間をよりしっかり管理するなど、意識的に動かないといけないことが増えるようです。

ただ、一時的な在宅勤務ができる仕組みはあったほうが良いと考えます。というのも、家庭の事情や、台風をはじめとした交通障害の理由で、出社が満足にできない状況が起こりうるからです。その時に、無理に出社せず、家で仕事を続行することができれば、柔軟な働き方ができます。幸い、勤務先ではこの仕組みで運用されています。

もちろん、完全に在宅勤務に移行したら仕事をしやすいと感じる、という人もいるかもしれません。これはこれで、その人にとって新しい発見だったのではと思います。あくまで、僕は完全在宅勤務は精神的に持たない、そう感じただけです。

まずは乗り切っていきましょう

所属するチームをはじめ、在宅勤務でもうまく気晴らしができる仕組みを、そしてチームの士気を保てる方法を考えて実践する動きが出てきました。オンライン飲み会をやっているチームもあると聞きます。ただ単に、みんなで同じことをしているだけなのかもしれませんが、それを通じて一人ではないということを知られるだけでも大変有意義な時間であると、僕は理解しています。一人で乗り切るには、あまりに大変な状況です。

コロナウイルス騒ぎが早く落ち着いて、全てが普段通りに戻ることを、今はただただ祈るばかりです。しかし、状況はますます悪化し、世界的な広がりを見せています。また、僕らのような在宅勤務の選択が取れるIT企業はまだマシで、外食や観光産業は悲劇的な打撃を受けているという報道もたびたび耳にします。

今は、知恵を出しつつ、とにかくこの状況を乗り切る。これに尽きます。

Software Design 短期連載「Webサービスを裏で支える!! バッチ処理設計の勘所」を終えて #gihyosd

縁ありまして、ソフトウェアエンジニア向け技術雑誌「Software Design」で、2019年12月号から2020年3月号までの4回にわたり、「Webサービスを裏で支える!! バッチ処理設計の勘所」を連載しました。

今月が最後の回で、連載も終わりましたので、後日談として記録を残します。「きっかけ」「執筆の状況」そして「執筆を終えて」の3部に分けて書きます。

きっかけ

当初、この話は2019年のbuildersconのプロポーザルに「安心・安全なバッチプログラムを書くコツと運用のツボ」として書いた内容でした。ただ、落選してしまって、それならどこかの同人誌即売会に向けて同人誌として書き直そうと方針を転換しようとしていました。

その矢先、TwitterのDMで、技術評論社の吉岡さんから、プロポーザルとそれのもとになった会社のブログ(「Mercari Engineering Blog – バッチ処理の採用と設計を考えてみよう」のこと)を読んでみました、よかったらSoftware Designで書いてみませんか、というお話をいただきました。これはいい話だなと思い、会社内にいる執筆に慣れた同僚からちょっと意見をもらいつつ、連載として進めることになりました。

モティベーションとして、バッチ処理を書く機会はそれなりにあるはずなのに、ミドルウェアとかアーキテクチャの話に比べてあまり語られることのない話で、かつ割とノウハウが必要なところもあるので、それをどうにかまとめてみたいというのがありました。

問題はターゲットでした。玄人向けにジョブネットワークとかクラウド環境向けの話を書くこともできたのですが、これはやめました。ガチガチの業務システムで使われている商用の基盤についても、今回は触れるのをやめました。読者層などを鑑みて、Web系IT企業に勤める、これからバッチ処理を書こうとする人、または書いているけどノウハウを得る機会にあまり恵まれずに困っている人向けとして設定しました。また、大学やプログラミング教室でプログラミングの講義をきちんと受けたけれど、バッチ処理を書く講義はさすがに受けたことがないだろう、という想定もありました。

執筆の状況

流れはこんな感じです。

  1. 原稿を書く。
  2. 吉岡さんと、同僚のレビューをもらう。
  3. レビュー結果を反映する。
  4. ここまで、発売1ヶ月以上前の〆切に間に合わせる。
  5. 吉岡さんが編集して、組版してみる。
  6. 著者校正する。
  7. 編集部でも校正が入る。
  8. 刷られる。

執筆にあたっては、Google Docsを使いました。レビュワーの人たちにすぐに展開できること、レビュー時にコメントを入れやすい、そして吉岡さんからも推奨されたという理由がありました。Google Docsは普段の業務でも使用しているので、誰も何も困らずに使うことができました。問題は図面だったのですが、これは鉛筆で書いて、スキャナーでスキャンして渡しました。

目次案は8月のお盆前に作成して、当初は3回シリーズで行こうと決めました。ただ、第2回を書いているときに、1回あたり8ページ(1万文字くらい)だったはずが、あっという間に原稿が溢れてしまい、1回分おかわりすることになりました。

執筆は8月のお盆明けから始めました。当初は余裕のペースで進められていたのですが、最終回の第4回になると割とギリギリでした。まあ、それでも第1の〆切(?)には間に合っていたので、吉岡さんには迷惑はかけなかったはずです!第4回は正月休みを挟んでいたため、正月休みに書けるだろうとタカを括っていたのですが、これが裏目に出ました。正月休みは、家庭のことなどで、執筆にほとんど手が回りませんでした。休みに原稿が仕上がるというのは虚構ですw

なお、普段の原稿の執筆は、家の近所のドトールコーヒーでやっていました。電源があったことと、向かいにあるdocomoショップからdocomo Wi-Fiの電波が出ていて、窓際席だとそれを捕まえることができて便利だったからです。家だと、息子から遊んで欲しいとか言われたりするものですから、ちょっと難しかったです。

レビュワーですが、会社の同僚にお願いしました。第1回〜第3回はバッチの設計・開発にフォーカスしたため、Data Platformチーム(データ分析基盤を構築・運用するチーム ジョブネットをめっちゃ作っている人たち)にいる @syu_cream さん、第4回は運用の話題が多めのため、SREチームの @tjun さんにお願いしました。お二人とも、社内で技術の前線で業務にあたる、僕の信頼している同僚です。彼らのおかげで、より良い原稿に仕上げることができました。

執筆を終えて

おかげさまで、多くの方から高い評価をいただけていると、吉岡さんからお話を伺いました。大変嬉しく思います。ありがとうございます。

また、個人的に聞いた話ですが、当初想定していた読者層に加え、Data Platformの開発・運用担当者の人にも評判が良くて、ありがたいなと思いました。彼らもまた、各基盤からデータを集めて処理するために、たくさんのバッチ処理を書いて、ジョブネットワークを組んで、運用をしています。そこに響いたんだなと想定しています。奇遇にも、レビュワーの一人はData Platform開発・運用担当の @syu_cream さんだったのも、よかったです。

バッチ処理については、他にも書けることがあるので、また機会を見つけて書こうかと思っています。

ご意見、ご感想がありましたら、他の方の記事も含め、読者アンケートを通じてフィードバックをいただけたら幸いです。編集部の皆様、そして執筆者の僕らの励みになります。

謝辞

今回は、このような執筆の機会をいただきました、技術評論社の吉岡さん、レビューを買って出てくれた @syu_cream さん、 @tjun さん、そして執筆の時間を作ってくれたうちの相方に感謝します。どうもありがとうございました。