modest violet

modest violet

開発者としてのあれこれや、日々の雑記など

your future hasn't written yet. no one's has.
by Emmett Lathrop "Doc" Brown

(de:code2016を終えて)エンプラ系技術者の僕がOSS系技術者に劣等感を抱いて変革を試みた4ヶ月の内容

f:id:shin21sk:20160526073132p:plain

先日の記事で書いたのですが、de:code2016に初参加しました。
shin21.hatenablog.com

『de:codeでは最新技術に触れながら、明日現場に戻れば旧態依然の開発現場が待っている・・・。』

セッション「拝啓 『変わらない開発現場』を嘆く皆様へ ~エンプラ系 SI 開発現場の「今」を変えていくために~」でグサッとささる一言でした。
はい、まさにその通り!哀しくなります。

僕自身はずっと業務系開発(いわゆるエンタープライズ系、略してエンプラ系)をやって来ていた為、本当にオープンソースソフトウェア(以下、OSS)には疎いのです。エンプラ系の周りには当然エンプラ系しかいない為、OSS側の知識なんて本当に入ってこない閉鎖的な状況でした。
そんな旧態依然の環境で日々戦っている訳ですので、やれDevOpsだInfrastructure as a Codeだ何だとなった日には、本当に「黒船来襲」くらいのインパクでした。
「どれだけ自分が無知であったか・・・」を、痛切に反省した次第です。

黒船襲来! 世界DevOps トップ企業 x マイクロソフトによるトークバトル セッション
https://www.microsoft.com/ja-jp/events/decode/2016/special.aspx

ちなみにですけど、ここに挙げた両セッションは受けたかったんですが、受講していません!(人が多い&他も魅力的な内容多過ぎ!!)
エンプラ系のセッションは後でTwitterの書き込みを見て、何が何でも受講すれば良かったと本気で後悔しましたけどね・・・。

そもそも今回de:codeに参加したのも、エンプラ系だとかOSS系だとかそういう枠組みは関係なく、僕自身が技術者として停滞している事に強い危機感を抱くようになったからなんですね。
結果から述べると、ここ4ヶ月で少し停滞感は払拭出来たかな?と思っています。実際に実践した内容を3点ほど記載します。

※エンプラ系として括っていますが、もちろん全ての方々がこういう訳ではありません。あくまで僕の主観です。

2日間で考え方がガラッと変わったDevOpsハッカソン

「何かしなくちゃいけない!でも何を?」と今年の始めには、そんな宛ての無い問いに悩んでいたりもしました。そんな中でふと目にとまったのが「DevOpsハッカソンです。

参加するまでは、DockerとかJenkinsですら当然知りませんでした。でも周りのハッカソン参加の方々は普通に話しているんですよね。「あれ?僕は場違いか?浦島太郎なのか??」と。劣等感を抱かずにはいられませんでした。

でも中には同じように「エンプラ系で頑張っていて、同じようにExcel仕様書に苦しんでいる」方達もおり、自分が抱いている悩みは他にも思い悩んでいる人たちはいるんだ!と一種の安堵ではないですが、共感する事が出来ました。
じゃあ、知らないものは仕方が無いので、後は少しずつ覚えていけば良いんだなと思い直すと、少し気負っていたものが楽になった瞬間でもあった訳です。

ただ、そんなOSS系に縁遠い方々でメンバーを組んだ為、1日目は「何をすればいいの???」と右往左往しか出来ません。「初体験の人たちが組んでも仕方ないでしょ!!!」と心の中で呟きまくった訳です。

1日目は軽い絶望を抱いたハッカソンでしたが、2日目は吹っ切れて楽しくやりました。自分がやってみたいと思う事をね、やっちゃおうと。苦しむために来たんじゃ無い、楽しむために来たんだ。そう考え直したわけです。別に失敗したから怒られるわけでもないし、逆に何もしない(何も得ない)で帰る方が勿体ないわけで。

多分ですけど、この考え方が当たりだったと今になって思えます。
結果、ハッカソンは本当に参加して良かったと思っています。

ユニットテストを書くように意識した

ハッカソンでDevOpsの基礎の"キ"を学んだ訳ですが、現実に戻るとレガシーなシステムがお待ちになっておりました。ひとまず、ユニットテストを書けそうな所から少しずつテストを書くように試みていきました。ただ、今までユニットテストが無いという事は周囲も「それで正解!」と判断出来る人がいない訳です。

ハッカソン中でも話題になったんですが、単体テストの認識が少し違うんですよね。今思えばエンプラ系とOSS系では完全に捉え方が違っていますね。
shin21.hatenablog.com

また、管理者の方々は安定志向な人が多いです。当然と言えば当然何ですけど・・・。あとユニットテストが無いという事は、テストを書く工数も無いという事になります。
多分、この辺りがエンプラ系でテスト駆動開発が成立しにくい理由の1つなんでしょう。de:codeで牛尾さんが「意思決定者を巻き込んで話を進めれば大抵すんなり通る」と話されていましたが、それはその通りだと思います。ただ、そこに持って行くまでに心が折れてしまう開発者も多いんじゃ無いかなと僕は思うわけです。
「そこまで苦労して方法を変えたくないよ」とか思ってしまう人たちも多いはず。マイクロソフトエバンジェリストの発言と自社の一介のプログラマーの発言とだと重みが違いますもんね。それなりの「覚悟」を持って事に当たる必要があります。別に首をかけろとかそういう意味での「覚悟」ではありません。
「このままのやり方ではいずれ通用しないから変えるなら今だ!変えるのは自分だ!!」という自分への覚悟です。

そんな覚悟を抱きながら、少しずつですがテストを書くようにしています。
余談ですが、Visual Studio 2015のコードカバレッジテストを覚えてからは、テストを書くのが楽しくなってきました。テストケースがどこを走ったのか、明確に可視化されるとすんなり受け入れてくれます。

そして、Azure

DockerとかJenkins、はたまたその他の技術・・・。
OSS系の技術って千差万別で何を選択して良いのか、本当に分からないんですよね。素敵なコーチでもいれば話は違うんでしょうが、そう簡単に見つかるものでもないですし。

もちろん、一つ一つ覚える為に勉強するのが一番理想なんでしょうが、そんな事をしていたらさすがに日常が回らなくなります。

幸い、マイクロソフトには「Azure」があるじゃ無いですか。de:codeでもAzureづくしでした。という事はAzureは将来の強みになる要素がいっぱいあるわけです。
まだまだ小さい企業ではAzureというかクラウドに対して無条件で抵抗感を示すケースが多いです。これって逆にチャンスですよね。

自分の覚える事を最小限にして、最大限の効果を得る。これまた牛尾さんが言っていた「Be Lazy」の考え方に繋がるなと。
simplearchitect.hatenablog.com

結局何が言いたいかというと

エンプラ系やOSS系といろいろなケースはあると思いますが、組織の中でふと気付くと自身が停滞していた場合、その殻を破れるのは自分自身なんだという事。
知らない事は恥ずかしくない。だって知らなかったんだから。「知らなかったから、じゃあどうしたいの?」を考える。考えた末に覚えるなり不要と判断するなりの取捨選択が大事。

とまぁ、偉そうに書いていますが、まだまだ駄目駄目なんです。de:codeに参加して「もっともっと頑張らないと!でも最小限の労力で」と闘志に火が付きました。

「終わりのないのが終わり」とでも言いましょうか。
先日、桂歌丸師匠が笑点の司会を勇退されましたが、生涯現役を貫く姿勢には感動しました。
開発者35歳定年説とか有りましたけど、なんとなく年老いて亡くなる前にも新しい技術とか追求してる姿を思い浮かべると素敵かもと思うようになってきました。
色んな意味で考え方が変わってきました。本当に参加出来て良かったです。

併せて書籍学習も続けてます

shin21.hatenablog.com