プログラマとインフラどっちが良いの？代表に聞いてみた
どうもこんにちは！アウルキャンプのコーホーちゃんです。
今回は「プログラマか？インフラか？」というテーマで、当社代表にインタビューしてみました。
インタビューのきっかけは、当社に応募される方のほとんどがプログラマ志望であるが、本当にこだわりがあってその選択をしているのか？という疑問。
よくよくお話を聞いてみると、絶対に開発者になりたい！という強い思いがあるわけではないことも多く、スキルを身に付けるためにWebエンジニアになりたい…という方が多い感じもするのです。（実際はインフラ/プログラマのこだわりはあまりないのかも？）
未経験の方からすると両者の機能・役割はイメージしづらい部分もあるかもしれません。そこで、エンジニアの先輩でもある代表永野さんにアドバイスをいただこうと思います！
プログラマとインフラどっちが良い？
ー ズバリ、プログラマとインフラはどちらが良いでしょうか？
どちらでも良い（投げやり？）と思いますが、お互いの役割や業務内容を理解することは重要です。
ー その理由はなぜですか？
CTO（チーフテクニカルオフィサー）という役割がプチブレイクした時がありましたが、インフラを理解しているアプリ開発者がCTOになるケースが比較的多いように思います。何かしらのサービスを展開する場合、開発プロセスやプロジェクトルールなどアプリ開発で培ってきた経験と、サービスの可用性やセキュリティを守る知識、どちらも必要になります。なので、キャリアアップにおいてはお互いの領域のことを知ることが重要だと思います。
代表のキャリアについて
ー 永野社長のキャリアは、インフラからのスタートですよね！
私は「インフラ」と言われる汎用機（メインフレーム）の運用保守からスタートしました。汎用機なんて今はもうレガシーで知らない方がほとんどですが、今でいうサーバーですね。
そもそも皆さんは「インフラ」にどんなイメージを持っているでしょうか？アプリ開発は仕事内容を想像しやすく、プログラミング言語でアプリを開発するのが「アプリ開発」とわかりやすいです。そして「インフラ」は「それ以外」と捉えらているように思います。
「アプリ」は「インフラ」の上で動いており、インフラはただサーバーを準備しているだけという理解が多いように感じます。一言で括ると低レイヤーの仕事だと思われているのかなと。でも、実際の「インフラ」は下記のようなことを含みます。
設計
非機能要件（可用性、拡張性、運用保守性、移行性、システム環境）を決める。
要件に基づいた基本的な設計（基本設計）を決める。
基本的な設計から具体的な設計（詳細設計）を決める。
構築
OSのインストール・設定
アプリケーション実行環境の導入・設定（exデータベース、アプリケーションサーバー等）
エラー発生時監視ツールの導入・設定
障害発生しても継続してサービスが稼働できるようなミドルウェア導入設定
データバックアップ、ミドルウェア制御スクリプト等のインフラプログラミング開発
サーバーなどインフラを作成するプログラミング開発（クラウドの場合）
ネットワーク機器の負荷分散設定やファイアウォールのルール作成等
運用・保守
設計に忠実に運用・保守を行う。
言葉にすると小難しいですが、最近ではAWSを筆頭にパブリッククラウドが主流となっていて、インフラでもプログラミング言語を使う機会が多くなってきています。もともとデータバックアップやミドルウェアの制御（起動・停止など）はシェルスクリプトで製造していたりと、意外とプログラミングする機会もあるんです。
ー 現在はプログラミングの仕事もされていると思います。どんなきっかけでプログラミングを勉強されたんですか？
プログラミングであろうがインフラであろうが、本質的なことは同じだと考えています。この言葉による区分けが「アプリ開発」と「インフラ」の対立を生み出してきたのでしょうね。同じITの仕事なのだから、お互いの仕事を尊敬し、信頼しましょうってことです。
その考え方によって、DevOpsの定義（高い品質を確保しつつ、システムへの変更をコミットしてから通常の運用に移るまでの時間を短縮することを目的とした一連のプラクティス）が組織に根付くと思っています。
結果として「アプリ開発」と「インフラ」が相互協力することで、お客さまに良い価値を提供できるのかなと。片方だけが優秀でも品質高いサービスの提供は難しいので、両方を知ることはとても重要だと思います。
ー 逆にインフラとしてキャリアを極める道は選ばなかったのですか？
私の中では「CTOになる」というのがインフラとしてのキャリアの極みだと思っています。私はアプリ開発の現場でチーム開発をしてきたわけではないので、それは実現しませんでした。ただSESでインフラの要件定義、上流設計から構築、コード開発、運用設計、そして保守含めて全てのフェーズに携わってきたので、やりきった感はありますね。
ITエンジニアの最近の傾向
ー フルスタックを目指すべきだ！という意見をよく聞きますがどう思いますか？
当初から「フルスタック」の定義は曖昧で、「LAMP環境が構築出来て、その環境でMVCアーキテクトなアプリ開発まで出来る人」みたいな感じでした。でもこれってすごく当たり前で、ITが好きだったら枠を決めないで学ぶのは普通のことだと思います。ITエンジニアを言い換えると「ITを使った職人」だと考えているので、拘りを持って目の前のものを作ってほしい。それにはいろんな道具の特性やツールの使い方を知っている方が強いですよね。そういうことです。
ー プログラマとインフラで適正はあったりしますか？
若干はあると思います。まず両者に共通することは、怠惰であることです。怠惰っておかしいと思いますが、そもそもプログラムやITは、生産性を上げることを目的にしたものです。たとえば丸一日かかる作業を、プログラムにすることで5分にする。それが目的です。その気持ちよさを知って、皆さんはIT業界に興味を持ったと思います。
ITエンジニアは、上記でいう"5分にする"ための開発をする職種で、そのためだけに1週間かける情熱があります。それはプログラマもインフラも共通するところじゃないでしょうか。あとは知的好奇心が旺盛なこと、ロジックで考えられることが重要です。正解のロジックを見つけプログラミングにして解決する。考え方によっては簡単だし、スッキリするお仕事だと思います。
応募される方に向けて..
ー プログラマとインフラで悩んでいる方がいたら、永野さんならどのようにアドバイスしますか？
つまり、どっちでもいいと思います。自分の行きたい方向は、やっていくうちにいずれ見つかります。
ー スクールで学ぶのはプログラミングがほとんどなので、インフラの実務イメージを持ちづらい方も多いと思います。永野さんのオススメ勉強法はありますか？
やったことは自分の知識になるので、理解に時間を費やすこと。そうすると応用が来ても全てが思考の中で繋がって、未知のことでも予測して解決できるようになっていきます。
あとは、私の好きな考え方に「守破離」があります。まずは 「守」で師や流派の教え・型・技を忠実に守り、確実に身につける。 「破」は他の師や流派の教えについても考え、良いものを取り入れて心技を発展させる段階。 「離」で一つの流派から離れ、独自の新しいものを生み出し確立させる。
ITエンジニアは職人だと話しましたが、まずは基本の型を身につけ、自分の経験や流行りの技術の情報を入手し、良いことを取り入れてスキルを発展させ、それらを組み合わせて自分が目指すべきエンジニアになっていくのだと思います。
ー 永野さん、ありがとうございました！
インタビューを経て・・・・・・・
結果として「アプリ開発」と「インフラ」が相互協力することで、お客さまに良い価値を提供できるのかなと。片方だけが優秀でも品質高いサービスの提供は難しいので、両方を知ることはとても重要だと思います。
プログラマか？インフラか？という区分けに捉われることなく、技術者としてITで社会貢献できるための技術をしっかりと身に付けていくことが大事だと感じたインタビューでした。特に永野さんが大切にされているのは「守破離」の3段階の考えです。
基本の型というのはコーディングだけでなく、ツールの使い方であったり、テストであったり、それがインフラであったりITの領域はとても広く様々な分野があります。当社に入社された方はぜひ一緒に技術者として成長していきましょう！
興味を持ってくださった方、まずは話だけでも聞いてみたい方は、<< こちらのフォーム >>からお気軽にご連絡ください🦉🙌
この記事が気に入ったらサポートをしてみませんか？