運用エンジニアから開発エンジニアになるためにやったこと

Web の会社でエンジニアを始めて 4 年、ずっと運用エンジニアをやってました。運用とは端的に言うと、社内外の他人が作ったソフトウェアを期待通りに動作させるためのエンジニアリングだと思ってます。アプリケーションはもちろん開発者が作ったものですし、MySQL や Apache や Linux も全部他人が作り上げたソフトウェアであり、それらの設定を変更したりパッチを当てたり運用ツールを駆使することで、協調動作させることに磨きをかけてきました。

ただ、いつまでたっても他人の作ったものの面倒を見てることには変わりないし、運用ツールを開発したところでそれはあくまで誰かが生み出す価値のサポートにすぎないのが自分的には満足できなくて、ずっとアプリケーション(ビジネスロジック)が作りたいと思ってました。

で、今年の始めからたまたまタイミングよく新規開発の部署に入ることになって、いきなり開発者をやることになりました。ビジネスアプリケーション開発経験ゼロの自分が今では開発を普通にやっているわけですが、それができたのは自分がある程度準備してきたからだと思ってます。

今運用エンジニアをやっている人の中には、自分と同じようにいつか開発をしたいと思っている人もいるのかなと思うので、自分が何を準備してきたのかを書いておこうと思います。以下に挙げる様なことをこの 1 年くらい自分の時間も費やして準備を続けてきました。やったこととアドバイスがごちゃ混ぜになってますが、メモ書きなのでご容赦下さい。

僕の好きな言葉に「いつ来るか分からない 15 分のために常に準備をしているのがプロ」というのがあって、僕はずっとこれを信じてやってます。

アプリケーションをゼロから作ってみる

仕事ではアプリケーションを書く機会はありません。でも、それではいきなり明日から開発やってねと言われた時に手が動きません。アプリケーションが作ってみたいのなら、自分で作ってみることに勝る準備はありません。自分がウェブアプリを作りたいと思ってるならウェブアプリを、スマホのネイティブアプリを作りたいと思っているならそれを、ともかく時間を見つけて自分が作りたいと思うものを必死に作ってみた経験が今に生きています。

別に、ちゃんとしたサイトやアプリに仕立てて公開して、とかまでやらなくていいです。というかぶっちゃけ完成しなくていい。運用やってる人なら公開した時にどうなるかとかは知ってるはず。それよりも、何もないところから、何を作りたいかを考えて、どうやって作るかを考えて、実際に動くものを作る、というプロセスを踏むことがとても重要な経験でした。

大事なのは、解説本やチュートリアルをなぞるのではなく、自分で何を作るかを考えて作るところです。実際のアプリケーション開発は、作るべきものが完全に決っていることなんてありません。開発するということは作るものを考えるというステップも含まれるので、何を作りたいのかを自分で決められるということが大事です。

ソースコード管理手法を身につける

最近なら git+github 的なものになると思いますが、これらの使い方をマスターしていることは開発を始めるのに必須です。特にチームで開発するのであれば複数人で 1 つのリソースを並列で更新するわけで、管理もなしに開発することはできません。

僕は今回開発を始めるまではもちろんチームで開発なんかしたことありませんでした。でもチーム開発に向けて自分一人のプロジェクトでも必ず branch を切って pull request してから merge するという作業を踏んでいました。また、github 上の他の人のレポジトリに PR を出したり、逆に PR をもらったりすることで、擬似的ではありますがチーム開発の準備もできました。

準備段階であっても常にそれが本番に反映される姿を想像しておくことで、git flow とか github flow とか全くやったことがなくても、自然と自分の頭で管理フローを考えることができました。

複数言語・フレームワークで開発する

ビジネスアプリケーション開発をしている人と違って、個人のお勉強でやっている場合には 1 つの言語・フレームワークを使い倒すところまで至るのは難しいと思います。どうしても表面的な言語仕様やフレームワークの使い方を学ぶところで止まってしまったり、1 つの言語仕様でしか理解ができなかったりして、実際にアプリケーション開発する時には幅も深さも足りません。

いつか来るチャンスはどの言語・フレームワークでやってくるかはわかりません。だから僕はなるべく多くの言語・フレームワークに手を出しました。perl, ruby, python, node, go, java, scala, assembly, objective-c などなど。ちょっと触っただけのものから、アプリケーションを試しに作ってみたものまで様々ですが、いろんなものに触れることでアプリケーションとはこういうものなんだというのが少しずつ見えてきました。

特に、web アプリケーションとネイティブアプリケーションとか、動的型付けと静的型付けとか、vim と IDE とかを触ったのは大きくて、それぞれ実は大きな違いはないんだなぁとかが分かって、そこで得たアナロジーが実際の開発にすごく役立っています。

CS を勉強したこともなかったので、コンピュータにより詳しくなるという意味でもいろんなものを触ってみるというのは大事な経験でした。

小さいライブラリを作ってみる

アプリケーションは非常に大きく複雑になりがちですが、その途中で共通処理をライブラリに切り出すということはよくあります。そういうのをしたいと思ったときにクイックにやれることは大変重要です。なので、僕は各言語でライブラリ開発もしました。実際は便利ツールをいろんな言語で書いてみた、というのが多くてアプリケーションで使うライブラリとまではいかなかったですが、Authoring の方法やバージョン管理の方法なんかを一通り学べて大変役に立っています。

小さいライブラリは github でも公開しやすくて、PR やコメントをもらいやすいので、思い立ったらどんどん書いてみて公開するといいと思います。ゴミをいくらアップしたところで困る人は誰もいません。自分のコードを晒すことで逆にチャンスを増やせるはずなので、開発するチャンスが欲しいと思う人は積極的に公開していくといいと思います。

チャンスがあれば開発する

運用をやっているとスクリプトを書く機会はあると思います。最初は shell script しか書けない人が大抵だと思います。本気で開発をやりたいのであれば、いつまでも shell script のコピペばっかりやっていてはダメです。ここがチャンスと思って、スクリプトをアプリケーション風にしましょう。

運用をやっている人は得てして 1 枚のファイルに処理が全て書かれていて、上から読めば理解できる形をとりがちです。別に悪くはないんですが、ぐっとこらえて CLI の部分と実際の処理をクラス等に切り分けてみましょう。必然的に自分のコードの中で、CLI と処理クラス間のインタフェースを設計したりすることになります。そうしていくことで、実はスクリプトと呼んでいるものも、アプリケーションとして捉え直すことができてきます。

僕が開発を始めた一番のとっかかりはこの辺で、コピペで量産されるスクリプトを如何にすれば綺麗にできるのかというモチベーションからでした。コピペをすればその場は一瞬で片付くかもしれませんが、あとになって大量の負債に悩まされることになるかも知れない。そのトレードオフを見極めて、チャンスだと思ったら開発してしまいましょう。ビジネスアプリケーションではないかもですが、とても良い開発経験になります。

テストを書く

運用スクリプトとかは得てしてテストコードが全く無いです。それはテスト自体が難しいものもあるからではありますが、少なくとも単体テストを書かない開発はいまどきありえません。上で書いたアプリケーション作ってみるとかライブラリ書いてみるとかするときには、必ずテストを書きましょう。テストコードを書くことも経験を積まないと、何をテストで書いたらいいのかが見えてきません。

また、その時には出来る限り標準的な手法でテストを書きましょう。それぞれの言語でみんながやっている書き方やみんなが使っているライブラリがあると思います。それになるべくどっぷり浸かっておく方が、無駄なことをしなくて済むので良いです。覚えることが多くて嫌になるかも知れませんが、オレオレで書いたテストコードはメンテできないしレビューできないので、結果的に効率が悪いです。

基礎的な知識をつける

特にセキュリティまわりの知識は、実際にアプリケーション書いたことがないと全然身につかないので、アプリケーションをゼロから作りながら、一般的なセキュリティ対策の手法も合わせて勉強しておきましょう。CSRF とか XSS とか暗号化とか色々あって大変なんですが、この辺の基礎がないと開発者として全く役に立たないので習得は必須です。別に 100%できなくていいんです。ただし、そもそもそこに気を払わなければいけない、ということにすら到達していないと、悪意なく脆弱性を埋め込んでしまいます。

また、セキュリティ以外にもライブラリ管理の手法であったり HTTP の仕様、ジョブキュー、メール、ネイティブアプリならフレームワークの基本的な知識などなどアプリケーション開発で必要になるものは当然事前に準備しておかなければいけません。

他人のコードをひたすら読む

ここまでは攻めの準備を書き並べて来ました。しかし、最も大事な準備は守りでもある読むことです。実際の開発では他人の書いたコードをレビューします。その時に何を基準にレビューすればいいのかという判断基準は、どれだけたくさんのコードを読んできたかで築きあげられるものだと思います。そして、その基準はそっくりそのまま自分が書くときにも役立ちます。なので、大量に読むことが重要でした。

自分の場合は、動かなくて悩んで奥底まで読み込んだり、どうしても追加したい機能があってどこに足すのが綺麗なのかを探って読んだり、というモチベーションが無いとダメだったんですが、人によっては Linux kernel 読むぞ、っていって読みまくるとかでもいいと思います。ともかく量をこなせば読んでスッと入ってくるコードとそうじゃないコードってのがだんだん見えてきます。短いコードやファイルが分かれてないコードが読みやすいわけではないということに気付かされます。

読み込んだ結果として別に何か PR が出せたりブログ記事が書けたりとかアウトプットにならなくて全然問題ないです。読んだその経験がそのまま自分の力になるのだから、ためらわず読みましょう。

運用エンジニアとしてのスキルを磨く

上に見た様に、既に開発をやっている人と比べて完全にビハインドなので、全部準備できてやっとスタートラインです。その時点で価値を出すためにはやはり自分の得意分野と組み合わせるしかありませんでした。なので、運用エンジニアとしても常に最新の動向を追いかけ、誰に言われるでもなくいろんな検証を行って手球を増やしておくことも重要でした。運用の現場を知っている開発者は実は少ないので、ここを狙うしかありませんでした。

今やってる自分の仕事を切り捨てて開発のための準備だけをしても、それは大きなアドバンテージにはなりません。

おわりに

改めて書いてみると結構色々やってたなと思い出しました。〇〇をやらせてくれればすぐキャッチアップしますよ、というのは新卒ならいいでしょうがプロとしてはアウトで、やらせてもらえる時には既にプロでありたいと思ってきました。足りないのは経験だけ、という状態を作りたかった。実際やってみるとこれでも足りないことは多々ありましたが、一応すぐにスタートすることはできたので準備はギリギリ足りたかなという感じでした。

本気でチャンスを掴みたいと思っているのであれば、プロとしての準備をしておきましょう。その覚悟があれば必ずチャンスはやってきてつかむことができるはずです。

  • hisa 14-06-04 (水) 21:39

    頑張って下さい。