Leverages Advent Calendar 2019 - Qiita 最終日を担当します。ITインフラの研究職からSREを経て、現職ではいつの間にかVPoEのようなことをやっています久松です。キャリアを拗らせて唸っているうちにこういうキャリアになった、と説明しています。
今回はHRE（Human Resource Engineering）と題しましてエンジニア組織のカタチとマネージメントについてお話させていただきます。昨今のエンジニア組織マネージメントの難しさに悩む方々は多いかと思います。組織図や開発関係者一覧、タスク量計算をしていて「何だこれは」と思っている方々も多いのではないでしょうか。私自身、VPoE的な業務に取り組むにつれ、ふとインフラエンジニアだったあの頃と似通った着想に至りました。組織図をCDPっぽく描くというのが今回の主テーマです。何故EMやVPoEといったソフトなスキルを持ったポジションが求められるのか、エンジニア組織運営の難しさを理解する一助になれば幸いです。
従来型の会社組織
データセンター（会社）の中で全てが収まっています。室温から空調まできちんと整えられています。オンプレミス環境のオペレーションに関わったことのある方は思い当たると思いますが、物理サーバのホスト名に拘ったりして可愛がりますね。落ちると悲しいし、涙します。
増設（採用）は好ましいことですが、ラック（会社の物理空間）に限界もあります。計画はしっかりとデータセンター管理会社（バックオフィス）と連携しておく必要があります。
サーバやプロセスの監視も必要です。異常発生時はその現場に駆けつけましょう。ハードウェア（フィジカル）・ソフトウェア（メンタル）・ネットワーク（人間関係）など様々な課題が有りえますので、それらを吸い上げる仕組みや関係性づくり（1on1等）が必要です。
遠隔開発拠点
都内でのエンジニア採用が難しいと感じた場合、遠隔地で採用をかけるケースも多く見られます。海外でオフショアだったり、国内でニアショア、もしくは地方支店の一角を開発拠点にするケースもあります。その場合、意識すべきは意思疎通です。遠隔地に居る分、伝送遅延はありますので何往復も意思疎通するとその分ロスが発生します。何の機能を本社に残し、何を機能を外に出すのかが重要になります。社内組織として設ける場合は「外注感」「下請け感」が出ないようにしなければならず、機能ごと任せてしまうというのは一つの解法だと考えています。
SES
正社員でまかなえない業務が発生した場合、SESが登場します。フリーランスだったり所属会社の正社員だったりします。契約単位は時間のケースが多いですね。さながらパブリッククラウド的な形。同じドメイン（社内）で稼働をお願いするためにDirect Connect利用のケースもあるでしょう。ALB（タスク分配）やCloudWatch（勤怠管理）も必要です。
請負、コンサル
機能を部分的に他社に依頼するケースもあります。アプリケーション開発を受託開発に出すケースもあれば、チューニングといったスポット依頼のケース、AI開発や分析のような専門性の高いケースもあります。
AWSで言うところのManaged Service利用のようなセットアップと運用を丸々委託するパターンもあれば、Facebook APIやTwitter APIなどをインターネット経由利用するように基盤に乗っかるパターンもあります。
重要なこととして障害・仕様変更・サービス終了などにより依頼先が（一時的にでも恒久的にでも）応答しなくなった場合、極力本番環境に影響しない形での実装と運用が必要です。私も前職ではFacebookベースのサービスのインフラを担当していましたが、先方都合の部分はいかんともし難いものでした。「他人の褌で相撲を取っている」という感覚を忘れてしまうと大事になりがちです。
社内副業
俄に流行の兆しですね。新卒採用イベントにて他社さんの会社説明などを聞いていると「実は取り組んでいます」という会社さんがちらほら居られます。これはつまり外注という選択を取る前に社内の余剰リソースでタスクを消化させようという動きです。余剰リソースを有効活用という意味合いでは仮想化のようなものですね。
加えて弊社調査でも言及させて頂きましたが、若手エンジニアには限られた時間でできるだけ複数の経験を積みたい（複業）というタイムパフォーマンス志向が見られます。
余剰リソースの有効利用や、複業に応える解答としては肯定できる社内複業制度ですが、労務や制度的な難易度が高いです。実務的な観点で問題となるのは「タスクの切り分けとマネージメント」が挙げられます。
クラウドソーシング
タスクを細切れにして外部に依頼します。特にインフラを構築せずともリクエストを投げるとリザルトが返ってくる様はさながらLambdaです。ただしプロセスの信頼性は低く、タイムアウトする可能性もありますのでプロセス管理が重要となります。
（エンジニア）組織のミライノカタチ
経営層の視点で「働き方改革は誰のためにあるのか？」と問われると「メンバー層」を対象にしたものではないかと答えています。特に能動的な行動を好むメンバー層への働き方改革の影響は大きく、所謂自社メディアと呼ばれる企業、それも他社との比較がしやすいITベンチャー密集区ではその直撃を免れていないように思います。
あるスタートアップ事業さんでは正社員は数名のみが在籍し、タスク分解を徹底し、残りは全てフリーランスで事業展開をされています。出勤日は固定ではなく、カレンダーに稼働時間を登録して貰った上で消化していくというスタイルを取られていたりもします。稼働可能な時間（スキマ時間）に稼働するスタイルはスポットインスタンスと言えます。
経営目線で考えると会社とは何か（少なくとも社員数は重要ではなくなる）、正社員には何を期待し何を残すのかを考えなければならない時代に来ています。オンプレミスとパブリッククラウドのハイブリッド構成だとデータベースをオンプレミスに残すケースが多いですが、会社組織であれば事業イメージをカタチにする企画職や、開発管理をするPM業務が該当するかと思われます。こうした人達をどこから連れてくるのか、育てるかというのも課題となってきます。事業コンセプトだけが会社に残るケースもあるのではないでしょうか。
一方、メンバー視点で考えると働き方改革を前に「ええじゃないか」と踊るのではなく、前回記事の指名される理由が必要になってきます。自分の自己責任が叫ばれる時代の中、どの立ち位置で、時間・成果のいずれの報酬体系で、どう渡り歩いていくのかを意識しなければなりません。また、弊社レバテック事業においてもこうした流動性の高い不確実な時代の流れを捉えつつ、日本一の相談相手として歩まなければならないと考えています。
最後に
働き方の多様化が進み、自社のみでの開発組織の完結が難しくなってきた現在、人的マネージメントは困難を極めています。だからこそEMやVPoEといったソフト面の職種が登場したのだと考えています。
こうしたデザインパターンに載せて考察していくとHRとSREで共通点が見つかったり、マネージメント上の課題が発見できたりするというのが今回提唱したHREです。インフラエンジニアの基本であるトポロジ図やCDPに倣って、自社の組織図を書いてみるのも一興ではないでしょうか。
今回は書くと棘のあることはあえて伏せているのでいつの日かあるかも知れない書籍化に取っておきます（DRとかオートスケーリングとかマルチクラウドとかクラウド移行とかリプレイスとか）。
