てんさんインタビュー
@tenn_25さん
某Webサービスの運営会社で働いています。
3年目までは社内システムの保守開発をしてたのですが、
集計システムだったのでSQLしか書かず、一般的なプログラミングは一切しませんでした。
(ここで周りと差がついてしまってプログラミングコンプレックスがあります)
4~5年目は運用側に移って、クラウド/オンプレ問わずやってます。
今はクラウド→別クラウド移行の案件で、アーキ設計と、DevOpsやSREに適した運用設計をしています。ちなみに、社会に出てからまだ一社目です。
――学生の頃はどんなこと勉強してたんですか？
学生時代はいちおう情報工学部だったので、プログラミングとか数学とかやってましたね・・。
研究室は画像の特徴量検出の研究でした。
とはいえあまり勉強ちゃんとやらなかったので、いずれも中途半端なまま卒業しました。
――大学ではプログラミングもできてたわけですか。
そうですね。
C,C++,Javaは必修で半年ずつやってました。あとアセンブリ言語の授業もありました。内容としては座学と課題の繰り返しです。
「こういうプロパティとメソッドを持った◯◯クラスを定義して、引数に△△を与えたら□□と表示されるプログラムを作りなさい！」みたいなイメージです。
成果物として目に見えるアプリケーションを作るようなものはなかったです。
C言語なんかはもっと低レイヤーな内容だったので、面白いと思わせるものではなかったですね。
なので、クラスとかインスタンスとかそれらの継承とか、Cのポインタとか、概念的なことは学びました。
ただ、その上でフレームワークを使ってWebアプリケーションを作ろうってなると壁があります
ただ、半年なんて入門書の半分も行かないくらいなので、それだけでは何も作れるようにはならなかったです。
結局はその先の自己学習が必須でしたけど、ほとんどやらずじまいでしたね。
――記述法とかを覚えていく感じのやつなんですね。概念を知ることも、わからない人にとっては壁の一つなので大事なことだと思うんですよね
経歴にもあるDevOpsやSRE（共に開発とインフラを一体化して考える概念や文化）にも役に立つ素養だと思うんです。
そうですね。そういう意味では本当にプログラミング未経験の方と比べれば多少イメージが湧くところはあると思います。
ただ、仕事で使えるスキルではないのでコード書けないエンジニアに含まれるかなぁと思ってます。コードの設計というか、書く前に考えるフェーズがあると思うのですが、そこが微塵もわかりません。
――今は開発と近い距離で仕事してると思ってるんですが、読めなくても差し支えはない感じですか。Azureでインフラと開発を一体化して管理してるんじゃないかって思ってたんですよ。ビルドして試験してみたいなこともインフラでやるのかなぁって思ってたんです。
確かにアプリもインフラも同じようにGitで管理されてデプロイフローも同じになりましたが、インフラのテスト自動化まではできてないので、他環境にデプロイして動作確認してます。
インフラのコードはjsonとかyamlとか設定ファイルみたいなもんなので、開発の人がインフラコードを書くのは増えるかもしれません。
ただ、やっぱり非プログラマー(私だと運用部)がアプリケーションまで見るのはかなりハードルが高いです。
私のとこだと、運用部主導でSREの考えを取り入れていこうとしてるんですが、役割超えてアプリケーションのプログラムまで見ろとは思わないです。会社って役割分担してなんぼなので。
マイクロソフトの真壁さんって方がよく言っている「べきではなく武器」って言葉がすきです。
×プログラミングできるべき
◯プログラミングできたら武器
SREの考えを取り入れて変わろうとしているところなんですが、運用部としてできる範囲で
・インフラのコード化
・自動化(かんたんなスクリプト程度)
あたりは、プログラミングできたら武器！って感じでやっていきたいな、とは思います。
――それはいいですね。私はやっぱり見れる人が不足してて、本当はちょっとはできるのが良いんです。結局それができてないせいで、バグとか出してて品質に影響出しちゃってるので。
なるほど、私のところは、部署自体が開発・運用で分かれてるのでコードレビューまでは求められないですね。。
DevOpsはそれはそれで難しいですね。役割分担が曖昧になるので、いつの間にか「〇〇ができる人が誰もいない！」みたいなことが起こりそう。
――今のままだと、コーディングしなくてもちゃんとステップアップできそうな環境だと思います。そのままクラウドインフラ周りをこれからも伸ばしていく感じですか？
割と何をやってても面白さを見出せるタイプですが、今の自分のモチベーションが、「自分がモノ作りをする人として成長しているかどうか」なんです。最初3年はレガシー技術をやっていたのですが、データベースとかSQLの本質的なところの面白さに気づけるきっかけにはなりました。
今後については、「今のところ」クラウド中心ですね。
もともとWebサービスを作りたくて今の会社入ったんですが、当時は自分でプログラムを書いたりサーバ構築したりする「エンジニアリング」しかないと思ってたんです。最近は、システムアーキテクチャとか運用設計に限らずWebサービスを動かすための設計「デザイン」に興味が向いてます。技術そのものよりは、「既にある技術をどう組み合わせたら作りたいものが作れるか」を考えるのが好きです。
今はクラウドサービス(特にAzure)でそれを実現するのが目標です。
その先どう進むかはわかりませんが、もう少し広い意味でWebサービスのデザインもやりたいです。いっそ転向してUI/UXデザインとかもやってみたいです。
――新しいものやいろんなことに興味を持てる人ってエンジニアにすごく向いてると思うんですね。
データベースに関しては技術にも興味湧きましたが、あれもデータの整合性と処理スピードをどう両立するかって課題を考え抜いた上で作られた叡智の結晶なんです。
私がやりたいのはデザインによる課題解決なのかもなともおもいます。
――具体的にはどんなことですか。
システム設計みたいにエンジニアリングに重点が置かれるものはアーキテクトって訳し方が正しい気もしますが、
もう少しユーザ目線で考えたり、全体を俯瞰したサービス設計という意味で「デザイン」と表現しました。
技術一辺倒じゃなくて、柔軟に適切なアプローチができるようになりたいです。
技術やツールは色々ありすぎて飽和してるので、何をどう使うか見極めて選択できる人が求められてる気がします。
ITサービスである以上、エンジニアリングとデザインが分業ってことはないと思うので両輪で伸ばしたいですね。
――アーキ設計やデザイン設計って導入以前の企画・要件から設計、運用と全部やるって異メージでしょうか。
今はシステムリニューアルのプロジェクトに運用の立場で参加していて、最初の要求出しの段階から混ざってます。
通常の開発案件とかも、企画から開発に降りてくる段階で一緒に話聞きますね。なかなかそこで意見言うって難しいですけど・・
でもお陰で事業全体が見れるし、全体が最適化されるように意見出して方向修正していけるので前より確実に良くなってる実感があります。
――以前は違ったということですね。
運用部に配属になった2年前、まじかよ最悪だ…って思ってたんです。
ただ、運用設計もデザインだと思うようになると結構楽しいです。
・定常作業を確実にこなしながら随時改善していける仕組み作り
・障害時に迅速に動くための連絡/対応フローの取り決め
・リリースなど変更起因の障害を減らすための工夫
など挙げたらキリがないですが、人/ルール/ツールがうまく繋がって回っていくように業務設計するのもデザインなんじゃないかと思います。
ここでも「プログラミングできたら武器」、なんです。ただ僕はプログラミングができない。
簡単なスクリプト書くので精一杯・・宜しいならばデザインだ。って感じです。
――なるほど。全体のデザインはするけれど、プログラミングできなくても目指しているというのは非常に参考になります。同じAzure使いとして個人的にも注目しています。今日はありがとうございました。