About ytnobody

Spread the love

人物の歴史

出生から学生時代

あずま さとし(東 聡志)。都内在住。ネット上ではytnobodyと表記。オフでは「わいとん」などと呼ばれる。

1980年、北海道函館市に生まれる。幼少期は紙工作とボードゲーム、水泳にのめり込み、中高時代はバドミントンとバンド活動、M;tG(トレーディングカードゲーム)に夢中になった。

地元の工業高校(電気科)を卒業するも、不器用が祟り、これといって資格を取ることができなかった。そのため、発電・送電・電気工事の分野への進路をあきらめ、POSレジ修理のエンジニアとなる。この時、18歳で上京した。

POSレジ修理エンジニア時代

当時は社員一人ひとりへのPC割り当てという状況ではなく、部署ごとにPCを共用していた。やがて顧客や上長などからのメールが増えるにつれ、社員一人ひとりへのPC割り当てが急務となるものの、予算の都合で私には専用PCが割り当てられなかった。

顧客から指名を受けることがまずまず多かった私としては、業務上、POSレジが内実PCと同じものであることを知っていたので、夜間待機業務の合間を縫って、社内で余った廃棄部材を寄せ集め、1台のPCを自作した。別部署のヲタク気質の先輩に唆され、OSにHolon Linuxをインストールし、これを業務PCとして利用した(当時の情報システム部の担当からは大変嫌な顔をされたものである)。なお、このPCは別の夜間待機時間中に蚊がCPU付近に留まり、そのままショートしてしまい、破損。

その後、20歳のころ(つまり2000年)に残業代が出なくなることに耐え切れずハローワークで転職活動を行い、ソフトベンチャーへと転職する。

派遣社員時代

当時は派遣社員の身分だったが、これがIT業界への初めての本格的な参加となる。

しかし、初配属となった派遣先(建設関連)で情報システムの利用ガイドラインに抵触してしまい(プログラム習得のためネット上を調べていたところ、「2ch」のリンクを踏んでしまった)、およそ半年で契約解除となる。

次の派遣先(金融関連)では、セキュリティとネットワークに関する脆弱性の検証と対策について担当した。しかし、当時の実力では満足にこれをこなせたとは言えず、代わりの業務としてアクセスログ集計の自動化を任された。当時私が唯一書くことができたPHP4で開発し、一定の成果を上げたが、契約期間満了のため現場を離れる。

その後、3か月ほど仕事がなく(派遣元から仕事がこなかった)、毎日が困窮していた。にもかかわらず自宅サーバを立て、Webサーバ、ファイアウォール、メールサーバ、ハニーポットなどの仕組みと運用を独習(Windows2000上で、だが)。

開発ベンチャー時代

2002年の春、派遣元の開発室に配属となる。基本的には三次孫請け開発のような立ち位置の部署であり、この頃の流行はガラケー向けの着うた配信だったらしく、その運用に携わることになった。

その後、業務系システムの開発、動画配信システムの構築、エンタテイメント機器と連携したシステムの開発、懸賞サイトのインフラ構築・運用、DRM対応ガラケーアプリ配信サイト開発、某有名厨師公式サイトのインフラ構築・運用、某怪〇〇ワイヤルより1年登場が早かったwebベースソシャゲーの開発、ソシャゲ開発、ソシャゲ開発、メルマガ配信システム構築&運用、ソシャゲ開発、ソシャゲ開発・・・という経験を積む。

毎日新しい知見が蓄積され、開発は楽しいものであったが、タスクとしては過酷であり、土も日もなく、毎日徹夜のような生活が続いた。時には部下が過労で倒れたり、上長が脳梗塞で倒れたりすることもあった。私自身も執務室で雪が舞い降りるのを目にしている。明らかなオーバーワークであった。

2011年3月11日、東日本大震災でデータセンタが停電してしまい、担当サービスが停止。当時中国にいたボスに連絡するも「自転車漕いででもサーバを動かせ」という言葉を聞き、「散々残業させておいてこの物言い、もはやこの男への義もない」と判断、その週のうちに転職活動を始め、4月には退職。

大手インターネット企業時代

2011年5月には、「聞けば大抵の人が知っているようなインターネット企業」に就職した。

最初は開発支援ツールの開発を目的としたチームへ参画し、バグトラッカーの開発を担当した。しかし、当時の私にはバグトラッカーがどのような存在なのか皆目知見がなく(ベンチャーでも利用したことがなかった)、また仕様も「わかっていることが前提」だったため、質問が出てこない上に何を作ればよいのか深く理解できず、結果的に良いものを作り上げることができなかった。他のエンジニアからすれば「何やってるかわからない人」であったことだろう。

その後、インフラ運用の補助ツール開発やSQLクエリチューニングの補助などをさせていただいたが、これらは超人級のインフラエンジニアが私よりも速く正確に仕事をこなしていった。結果、私は大した仕事を残すことができなかった。

そんな私を見かねた上長が、webコンテンツの開発・運用に配属転換をしてくれた。この配属先では担当エンジニアが退職して不在となり困っていたところだった上に、誰もソースコードの内訳を知らない状況だった。私が少しずつ状況を把握していると、後からプロジェクトごと配属が変わり、エース級エンジニアがバリバリとブルドーザーのように課題を片付けていった。一部残された箇所についてはどうにかこなしたものの、ここでもあまり役には立てなかった。

そうこうしていると、会社の事情が変化し、コアとなる事業が変わってしまった。私もコア事業のO2O部門を担当することとなり、巷でよく目にされる物を自動生成する仕組みを開発した。大手インターネット企業で、ようやくそこそこ役に立つものを作ったという実感が得られた。

ところが、それまでに得た知見から、私は「技術だけで誰かの役に立つことは難しく、サービスの成長に直結した取り組みと組み合わせなければいけない」と考えた。人事部と上長に「エンジニアと企画職の兼任か中間のロールをやりたい。それかUnity」と伝えたところ、「そんなロールは用意できない」という旨の回答を受けたため、転職を決意。

Unityは当時ものすごくのめり込んでいたというのもあるが、未来性があり、技術と利用者が直接対峙する機会が多いと踏んでいたため、次に転職するならUnityをやりたい、と思っていた。

現在 – 都心の小さめなインターネット企業

新しい職場のふたを開けてみると、Unityを使うことはほぼなかった。仕方がない。

代わりに、これまで触ってきたテクノロジスタックを完全にそのまま使える状況だったため、初日からコミットメントを残すことができた。テクノロジスタックが見知ったものであれば、あとはサービス成長のためのアクションを取ればよい。結果、技術人事のような立ち位置を取りつつ、溜まりに溜まった技術負債の返済計画を立て、チーミングの強化を行った。部門間の冷え切った関係のアイスブレイクをしていき、悩みを聞き、事業成長のために何が必要かを説いた。

そのような状況の中、徐々にエンジニアが集まり、それまでなかったエンジニアのチーム(iOS/Android/Web/インフラ/QA/分析)ができた。

今では私は新規事業のPaaS担当兼iOS担当エンジニアとしてコミットしている。

もう一つの顔 – ソリューション・エンジニア ytnobody

昨年よりダブルワークとして、ソリューション・エンジニアのようなことをしている。つまり、各種課題に対してクラウドなどを使った解決案を提案し、一部実装を手伝ったりしている。適宜、より実装が得意なエンジニアとの橋渡しをすることもある。

私自身、専門はサーバサイドアプリケーション(Perl)だが、オンプレインフラ、Microsoft Azure、bash、PHP7、node.js、swift、unityなどにも対応する。

現職でも問題に対するソリューション(解決策)を考え、経営との兼ね合いを鑑みながら実現へ向けてアクションを起こすということをやってきたが、ダブルワークとしても引き合いがある。有難いことである。

関連リンク