3年間勤めたNTTコミュニケーションズを退職します

表題の通り、3/31を持ちまして、新卒より3年間勤めましたNTTのコミュニケーションズ(以下、NTTコム)を退職します。

TL;DR

いわゆる退職エントリです。一時期NTTの退職エントリなるものが流行りましたが、NTTコムの退職エントリはあんまりなかったと思うので書き留めて置こうと思った次第です。 おそらくすでに出ている複数のエントリと同じようなことしか書いておらず、完全にチラ裏なので見たい人だけ見てくださればと思います。

また、本記事の全ては個人の見解に基づくもので、所属する組織、団体の公式見解ではありません。

NTTコムについて(の感想含む)

いわずと知れた大企業であり、代表的なサービスとしてOCN*1があります。 私はR&D系の部に属しており、残念ながら多岐に渡る部やサービスのすべてを把握できていないので、書かせていただくのは主に所属していた部署についてとなります。

私の仕事

自社向けの社内システムやR&D周りのwebアプリやコントローラなどを書くSoftware Engineer(以下、SWE)として働いていました。 その他にも社内検証網の開発運用なども担当し、実務を通したネットワークや物理環境の経験なども積ませていただきました。

とにかく働きやすい

服装がほぼ自由、フレックス(そのうえ時間休を組み合わせられる!)、理由の問わないリモートワーク、取り放題の年休と、最高の環境でした。 新入社員のころから社会を舐めたような(個人の感想です)服装をしていても、特になにも言われることなく過ごすことができましたし、1年目からかなり多くの年休と夏休みが付与されます。

いい人が多い&すごすぎる人がいる

関係する人が非常にいい人ばかりで、不快な思いをすることや日本語が通じないことがほとんどありません。 また、主に日本のネットワークやインターネットを切り拓いてきた人が多数在籍しており、めちゃめちゃすごい人がめちゃめちゃすごいです(語彙)。

ネットワークについて

部署によると思いますが、ネットワークの基礎的なところはいつの間にか身につきます。 今でも勉強中ではありますが、他の分野でも頻繁に必要になるような 基礎的なネットワーク知識については研修や普段のいたるところの業務から身につける事ができます。 SWE職についているとインフラ周りのスキルが伸びづらい環境の人も多いと思うので、非常にためになりました。 また、インターネットの歴史や外に出せないような話なども聞けて、元から好きだったインターネットがもっと好きになりました。

退職事由

大きな不満はありませんでしたが、それでも退職する決断をいたしました。 端的に言えば「今、NTTコムにいる理由が薄い」と感じたためです。詳細を3点ほどに分けて説明します。

エンジニアとして一番成長できる場所か

webアプリを書くのがメインの仕事でしたが、アプリケーションについてはすでにチームで一番わかる、という状態になっていました。 完全に私個人の悪癖なのですが、自分よりできる人がいてその人を追いかけるくらいの気持ちでいないとすぐにサボり始めます。 当然まだまだエンジニアとして未熟な私としては、指導できる人(いわゆる強い人)と働きたく思っていました。 20代後半という時期を投資したいと思える場所を探そうと、転職活動をしていました。

キャリアパス

まず、エンジニアとして働き続ける(=スペシャリストとして給与を上げる)キャリアパスがほとんどありません。 私自身はマネージメントも興味がありますが、多様性のあるキャリアパスのある会社(や環境)で働きたいと思っていますし、エンジニアである間も給与をあげる制度があるといいなと思っていました。

style.nikkei.com

最近こちらの記事が話題になりましたね。記事になっている通り様々な営みが行われており、実際すこしずつ形になってきています。 私自身もエンジニアが楽しく働ける環境を目指して、及ばずながら様々な(e.g. NTT Tech Conference - connpass)活動もしていました。ただ、理想に近づけようとする最高の仲間たちがいる一方で、なかなかうまいように進んでいない実感もありました。

また、(resumeを書いたり転職活動して気づいたことだが)エンジニア職の原初風景がインフラにあるのも影響してか、 キャリアパスとしては「インフラを担当するソフトウェアエンジニア」になりたいと現時点では*2思っております。 ただ、NTTコムにはそういったポジションはあまりなさそうだと感じ、興味が外に向かっていきました。

給与制度

定年まで考えたときに決して低くはない給与をいただけます。ただ、学部卒の私は、最初の昇格まで5年を要します。(昇格しなくても一応ゆるゆると給与は上がっていきます) 順調に出世(昇格)を続け、30代半ばころになれば十分な給与を貰えるのですが、そこにたどり着くまでに10年近くあり、平たく言えば待てなかったです。

謝辞

今まで業務で関わったすべての方、及び身勝手な理由により退職を決めた僕を円満に送り出してくださった上長、チームメイト、同期の皆様に最大限の感謝の意を表します。

f:id:renjikari:20190331200757j:plain
親愛なる同期が洒落で作ってくれた卒業証書

最後に

なんだかんだ書いてますが私はNTTコム好きです。なんならいつか戻りたい。 NTTコムが労働者にとってより働きやすく魅力的な会社になることを願っています。

*1:たくさんのサービスがありますが詳細は省きます

*2:明日には変わってるかも

TDDの権化、t_wadaさんによるTDDワークショップに参加しました

t_wadaさんによるTDDの1dayワークショップに参加しました

2018/2/27(火)にTDDのスタンドの使い手 id: t-wada さんによる、1日ワークショップに参加してきました。 一ヶ月以上もブログ書くのが遅れてしまった…

ワークショップアジェンダ

ワークショップは以下のような流れですすみました。

  • TDDについての講演
    • 講義とライブコーディング
  • ペアプロ
    • 全員参加のコードレビュー大会

TDDについての講演

テスト駆動開発とは何かというところから始まり、TDDがうまくいかない(主に技術的でないもの)原因を学び、TDDを実際に行うためのサイクルをライブコーディングを交えつつ披露していただきました。

こちらの詳細な内容については、 以下で非常によくまとめていただいていたので詳しい内容は割愛して僕の感想だけ書こうと思います。(講義時のメモをまとめたら全く同じ内容の記事ができてしまったため)

developer.ntt.com

予測可能性について

講義の中で、今はまだソフトウェアが工学(Engineering)になりきれておらず、予測可能性が低いという話をされていました。

まさに目からウロコといった表現で、実体験としてこういうことを感じており非常に心に響きました。言い方をかえると「書いてみないとわからないことが多い」という当たり前のようなことですが、設計してるときはついつい忘れがちになります。 わりと緻密に設計をしたつもりでも、いざコードを書いてみると全く想定していないところで動かないことは頻繁にあり、今までは単に「辛い」と女子高生のような語彙力の低さを撒き散らしていたので、これからは「予測可能性が低いから(キリッ)」と言おうと思います。

どうやって「動作するきれいなコード」へいくか

ソフトウェア工学の世界では予測可能性が低いので「動かない汚い -> 動く汚い -> 動くきれい」(動かない汚いって単体で見るとすごい表現だな)というステップを踏もうとします。 そのために取れる手法のうちの一つがTDDというわけです。 しかし、このステップを進もうとするときにどす黒い感情が我々の前に立ちはだかります。

  • 堕落
    • 動いてればいいじゃん
  • 焦り
    • 動いているから、もっとほかのところ、次のところをやるべきではないか
    • 内発的な焦りと外発的なプレッシャー
  • 恐れ
    • 動くコードをきれいにしていく過程で動かなくなったら意味ないじゃん
    • しかし、ソフトウェアの世界が日進月歩なので動いているものを手をいれて変えないと、いつか動かなくなる

これらはそれぞれ誰にでも経験があるだろうことで、もっと言えばみんな上司とか偉い人から言われたことあるよね????(ぼくはあるよ)。

こいつらを乗り越えないと「動かない汚い -> 動く汚い -> 動くきれい」といった順番に乗れず、予測可能性が低い方法(しつこい)を取らざるを得なくなったり、動くけど汚いコードのまま過ごすはめになるわけです。

TDDではこの中でも特に「恐れ」に対抗する手段としてとれる手法とおっしゃっていました。

TDDのサイクル

- 次の目標を考える
- その目標を示すテストを書く
- そのテストを実行して(予想どおり)失敗させる(Red)
- 目的のコードを書く
- テストを成功させる(Green)
- テストが通るままでリファクタリングを行う(Refactor)

TDDのサイクルを載せました。TDDではこの中でもrefactoringが一番折れやすく、ないがしろになりやすい(「堕落/焦り」ですね)のでここは普段のプログラミングや日課に紛れ込ませてやるのがいいとおっしゃっていました。

(例えば、テストと目的のコードをたくさん書いたあと、次のスプリントはまるまるリファクタリングさせて下さい! よりも日々の中にリファクタリングを積んでしまったほうが良い。スプリントまるまるリファクタリングに費やすと新規機能が0なのでSMやPOからしても指示や承諾がしづらい)

ペアプロとコードレビュー大会

さて、午後からはペアプロの時間でした。お題は Semantic Versioning(参考: Semantic Versioning 2.0.0 | Semantic Versioning)です。

1時間半程度のペアプロをしてその後全員参加のレビュー大会をする、という流れを二回繰り返しました。

載せて良いのかわかりませんがその時のペアプロしたものと、あとからいろいろと変更を加えたものをおいておきます。

github.com

私はpython3 + unittestを利用して課題に取り組みました。 行った感想としては

  • ペアと一緒に要件を書き出していって、書き出した順に実装していたのですが、もう少し順番を考えたほうが良かった。
    • 今回はスピード勝負ではないので問題ないといえば問題ないんですが、一番複雑なところから手を付けてしまった。
  • 要件の洗い出しについては「近いところを詳しく、遠いところはざっくりと」ということをt_wadaさんがおっしゃっていて、非常に重要な感覚だなぁと思いました。色々な要件を実装する際に最初からすべて考えようとすると、前提条件の実装が動いていないので非常にコストがかかる感じがしました。そろそろ実装するぞ(=近い所)というところだとすぐ実装を決められます。最初から全ての要件を綺麗にしようとすると予測可能性があれということをこの時間のうちに体感できました。
  • python的な書き方に少々つまずき、綺麗でない実装になってしまった
    • ちゃんとgitに上がっているやつは直しています。commitログをみるとすごい複雑なif文が表れますw

全体的な感想

  • Testを書くこと自体もそれほど得意ではなく(やったことはあるが体系的に学んだことがない)、TDDに関しては完全にノータッチだったのでイチから学ぶ機会を頂いて非常に良かった。
  • 単純にペアプロしてレビューするのが楽しかった。
  • 企画してくれた先輩にとっても感謝します。

マイグレーションコンペティション 2018で優勝してきました

マイグレーションコンペティション 2018に参加して優勝しました!!!!!!!!!111

マイグレーションコンペティション 2018 winter

詳細は以下のURLより御覧ください

日本MSP協会のコンペティション担当による、運用技術を競うコンペティションです。次代を担う若手運用技術者同士の交流・競争を通して日本のMSP事業者における運用技術の向上を目的としています。

とのこと。

今回は EC2の1インスタンスにいるWebAppDBサーバその他もろもろをAzure上に移行する、というお題でした。

優勝のご様子 f:id:renjikari:20180129000822j:plain

メンバー

運営が当日ランダムでチームを組むのですが、チームメンバーはid:kani_bさんと大阪からいらっしゃっていたokazakiさんでした。 主にid:kani_bさんがDB周りの移行とチームマネジメント(リーダー)、okazakiさんがWebAppの移行、私がメール周りの移行を担当しました。 メール周りなんて大学生ぶりにさわるのでまじで怖かった

お題詳細

今回のお題はEC2サイトの移行ということで、移行元サーバには以下のような物が稼働していました。

最終的な方針

私達のチームでは最終的に以下の方針で移行を進めていきました。

  • ミニマムなところから移行し、お題の必須項目を完璧にやる
    • これができたら+αをやっていく
  • 具体的な方針
    • サーバ切替時にはメンテナンスを入れる
    • バージョンアップは無理せず, CentOS7.4のデフォルトパッケージでyumインストールされるものを利用する

覚えている感じのタイムスケジュール

今回は競技時間が10:30 ~ 17:00でした。

11:30 頃まで

自己紹介と移行元サーバの把握をしていました。また、リーダーの提案でgithubリポジトリを作成し、issueで進捗管理をすることに。(これとても良かった) また、予算がいくらくらいあるのかを担当者に確認し、現行の+-20%程度にしてくれという回答をもらいました。 この時点でAzureを使うと冗長化できなさそうかな〜みたいな話をしていました。

13:00 頃まで

途中ご飯を食べながら方針を決め始め、それぞれの役割分担を決定。このときはまだ、無停止でサーバ切り替えできないか模索していました。確か、MySQLを旧新サーバでレプリケーションしてデータ移行させれば無停止でいけるんじゃ?みたいな議論をしていたと思います。

担当者にはDNSTTLを60秒にしてもらうことと、サイトでなんらかの作業がある場合は14時までに実施してもらうよう連絡していました。(商品追加の作業があると言っていた気がする)

14:30 頃まで

チームとしてはそれぞれの移行をやっていましたが、MySQLのrootが取れないことが判明。root取れないとレプリケーションが組めないし、root取るためにはMySQLの再起動が必要なのでここで無停止を諦め、メンテナンスを入れてrootを乗っ取ることに(14:00頃)

私はメールサーバの移行をしていまして、saslを触ったことがなかったので、そこを一旦無視してPostfixDovecotの移行をやっていました。たぶんここらへんで/etc/postfixと/etc/Dovecotをごっそり移し替えて起動するくらいまではできていたような気がする。

15:30 頃まで

この頃にEC-CUBE及びメールサーバがほぼほぼ移行完了し、そろそろ切り替えれるんじゃないかみたいな話になっていました。

私はというとsaslをググったらそんなに大変そうじゃなかったので移行元サーバをまるぱくり、間違いがないかpostconf -nやdovecot -nを読んでいたのですが、virtual mailboxの設定をしていないことに気づき、/var/spool/vmail(だったような)の移行を開始。 ディレクトリ自体はそのままrsyncしたんですが、移行元サーバに/var/spool/vmail/をホームディレクトリとするvmailユーザがいたのでやり方に不安を覚えつつ/etc/passwdと/etc/shadow, /etc/groupを移行して、vmailユーザを作成しておきました。(これどうすればよかったのかな…)

16:30 頃まで

担当者に連絡し、16:00からサーバ切り替え作業とDNS切り替え作業を実施。移行が完了

17:00 まで

残りの時間で、id:kani_bさんがAzureのバックアップを作り、okazakiさんを中心に引き継ぎ&実施した内容のドキュメントを作成(Google Docsで作った)、私はドキュメントを手伝いつつlinuxユーザの整備などをしていました。

全体的な感想

ながながと書きましたが、だいたいこんな感じで進めていて、優勝をいただくことができました。 率直に言って最高だった(勝ったから)。 一番良かったのは、必須項目以外はやらない、位の勢いでもろもろを切り捨てる方針で進められたことだと思います。 あとid:kani_bさんのエンジニア視点のマネジメントが最高だった。 ぜひ来年も遊びに行きたいと思います。