社内システム開発からパブリッククラウドの会社へジョインします

執筆日:

更新日:

本日、2016年7月29日をもって、新卒から3年4ヶ月働いてきた部署が最後となり、8月1日から異動(出向)する。
社内転職制度を使って、自らの希望でパブリッククラウド事業の会社へジョインすることになった。
(新規事業を行う部署へ異動となり、そこから別会社へ出向という扱い)
グループ内の異動ではあるが、違う会社・事業で、職種も変わるので、今の部署でやってきたことをまとめて残しておこうと思う。

私は通信会社のネットワーク運用部隊に所属している(いた)。
ネットワーク運用部隊なのだが、私の部署はネットワーク運用を自動化したり運用を楽にするためのシステム開発を担うところで、下記のような仕事をしてきた。

1. ベンダーコントロールという仕事

システム開発にはうちでは外注物も内製物(後述)もある。
業務の都合上、システムの種類によってはSIベンダーへ発注をして作ることがあった。
ベンダーコントロールなんて言ったりするが、発注でのシステム開発の業務では下記のようなことをしてきた。

  • 要求仕様の検討
  • 見積もり依頼と価格交渉
  • 発注、スケジュール調整
  • 社内での業務調整
  • 受入試験、検収
  • 運用

仕事のほとんどは、社内外の人との調整(コミュニケーション)だ。
エンジニアとしては一見つまらなそうな仕事にみえるかもしれない。
しかし、この仕事から様々なコミュニケーションを学び、それはいろんな場面で役に立っている。
例えばだが、以下の様なコミュニケーションがあったりした。

  • 要求を他者にしっかり、わかりやすく伝える
  • 仕様や価格についての折衝をする
  • システムの利用部門との業務調整をする
  • 作業の手順について精査し指摘する
  • ミスなど良くないことが起きた際には、今後の対策はどうするか相手側に考えさせるよう導く
  • 場合によっては厳しく叱ることもする(感情的に怒るわけではない)

特に価格の折衝などは、SIerや購買部と激しく激突することもあり今でもとても印象に残っている。
こういった業務はビジネスマンとしてとても大事なことを学んだと思うし、内製での開発業務でもとても活きてきている。

外注はいいけど・・・

社内リソースが少なくても同時並行でいろんなシステムの開発ができるし外注はいい。
一方で外注開発について、もどかしさや非効率さなどもたくさん経験してきた。

まず、なにをやるにもお金と時間がかかることだ。
一度納品されてしまったものについて、なんらかの改修をしたい場合、
その改修規模を問わず、見積もり→発注→開発・改修→納品のプロセスを通さなければならない。
if文を1行追加するだけだろ…って思うようなものでも数百万で数週間かかることだってあった。

そして、プロセスの効率化が難しいことだ。
ベンダーが開発したシステムをリリースするには、発注側の会社に度々きてリリース作業を行う。
勝手に発注側のシステムをアップデートすることはありえないので、必ずリリース作業には社員が立ち会わなければいけない。
そのとき、リリース作業が自動化されていないことも多く(発注時の要求によってもちろん異なる)、
何時間もかけて数十台のサーバにデプロイしたりしなければいけなかったりするので大変だ。

これは当たり前だがとても効率が悪いし時間の無駄だ。
だがこれを改善しようと思うとまたお金がかかるわけである。
扱っているシステムが、業務システムなのでアップデートの頻度がおおくないこともあるので、
はじめからデプロイの自動化などを要件にいれることは少ないのである。

これらはSIの開発をディスっているわけではない。(要求も悪いのはわかる。)
これは仕方ないこととして、そのメリット・デメリットをきちんと理解した上で選択、要求をしなれけばいけないということだ。

2. 内製開発の仕事

外注開発とは別にシステムの内製での開発業務も多くおこなってきた。
社内的には外注開発から内製開発に徐々に切り替えの最中であった。
ちなみに開発言語はRubyRailsやPadrino)やPHPFuelPHP)なんか使っていた。

業務システムの他にもメールサーバやリバースプロキシサーバなど基盤システムも構築してきた。
2015年の振り返りブログに雑だが少し書いていた。

2015年振り返り - Goldstine研究所

開発組織の改善活動

また、開発組織を改善するための活動をおおく行ってきた。
どこの組織でもある問題だと思うが、うちもまた「属人化」「秘伝のタレ」などといった類の悩みをたくさん抱えていた。

うちはソフトウェア企業ではないし、システムを外注で作る部署も多い。
そのため、新卒や異動してくる人などがソフトウェアエンジニア思考の人ばかりではない。というかむしろ少数派。
だからこそ、よりいっそう「属人化」「秘伝のタレ」が弊害となる。
わかりやすいところでいうと下記のようなことをやったりして開発組織の改善をしてきた。

  • gitlabを使ったgithub-flowの導入。レビュー必須化
  • Ansibleを使ったインフラ環境のコード化、構築自動化
  • またそういったツールの導入だけでなく講師としてワークショップの実施やサポート活動
  • 部署内の開発ルールの策定
  • 最低限身につけてほしいスキルや知識を習得できる環境や研修の準備

ツールの導入や普及、組織改善活動について次の2つがとても重要だったと思う。

  1. キーパーソンを見方につける。
  2. ハンズオンを行う。サポートを手厚くする。

どんなにいい試みをやっても、独断で行ってしまうと「勝手にやったことだよね?」ってやっぱり思われてしまう。
また、その試みを広めるのに苦労する。
試みに対して理解してくれる上の人、キーパーソンを見方につけて働くことがとても有効的だった。

そして、ツール類はとくにそうだが、紹介したりするだけじゃなくて、
ハンズオン会をやったりサポートをし「軌道にのせる」ところまでやったのがとてもよかった。
サポートがないと、気が付くと昔のやりかたにもどってしまっていた、なんてこともあった。

3. データセンター、ネットワークの仕事

データセンター系

サーバ環境はオンプレだった。
また、専任のサーバ・インフラ管理者がいるわけではなかったので、
データセンターへのサーバラックの立架工事やサーバラッキング、配線などそういったことも業務の1つだった。
データセンタ系業務とそれで身につけたことなどは下記。

  • データセンターへのサーバラックの立架工事やサーバラッキング、配線をやった
    • ラックの立架工事や電源工事は当たり前だが外注
    • 工事の監督はさんざんやった
    • サーバのラッキングやLANケーブルの敷設は自前でもたくさんやった
    • LANケーブル作るのはだいぶこなれた
    • でもやっぱりプロの配線は神
  • 安全に工事するための知恵をたくさん身につけた
  • 電源工事などに備え、電気的な知識を身につけた
  • openstack(プライベートクラウド)の検証などもした

ネットワーク系

バックボーンのネットワークは範囲外ではあるが、
システム内のネットワーク設計・構築・運用は自分たちの仕事だった。

そういう組織体系が業務的によかったかどうかはわからないけど、
現代では特に触れる機会が少ないネットワークについて理解を深められたのはとてもプラスになっている。
下記あたりは自前でやってきた。

  • システム内のネットワークの設計
  • L2スイッチ、L3スイッチの設定
    • VLANとかNAT、ACLとか
  • NW機器が故障した際の交換とか設定投入

ネットワークは専門ではないけれど、オンプレでやっているとネットワーク系の仕事をやることや、
他部署とネットワークの話をしなければいけないことが多い。
ネットワークの知識は仮想サーバを構築するときなどにも役に立つし、ソフトウェア開発でも何かと役に立っている。
ちょうど最近、システムが調子悪い原因が光ファイバーの不良ということを発見できてとてもスッキリした。

4. その他

その他にあったことを雑にまとめる

  • たくさん出張にいった
    • 大阪、北陸、名古屋、広島、四国など
  • 社内での業務改善コンテストで賞をとった
  • 新卒の面倒をみたりした
  • インターン生も毎年きて面倒をみた
  • 採用リクルータをやって就活生とたくさん出会った
  • マリオカート大会企画した
  • 勤務地が変更になったりした

最後に

ほんとうに多岐にわたる仕事をさせてもらい、視野が広がった3年間だった。
アプリケーション開発しか知らなかった学生時代を振り返ると驚くほどの成長をしたと思う。

部署や上司、メンバーへ、本当に感謝です(^人^)

次は、パブリッククラウドの会社に行く。
パブリッククラウドを構築し運用するところなので、AWSGCPが敵…)

会社ではオンプレを使っていたし、またプライベートクラウドの構築の検証にも携わった。
規模感や組織構造によるのはわかっているが、どうもシステムを維持することにばかり時間を費やし、本来やるべきシステム開発による問題解決になかなかいたらなかった感じはあった。
一方、趣味開発ではAWSやHerokuなどのクラウドを使っていたので、本来やるべき問題解決に集中できることの価値を感じていた。
そういった経験から、パブリッククラウドをもっと多くの人が活用してシステム開発の本質により注力できるように、と思うようになった。

最後に…
この3年間で社内の仕事の質がかわった瞬間を目の当たりにした。
外注も内製もやってきたと書いたが、はじめは外注が多かったが徐々に内製開発の比率が増えてきた。
それに伴って、社員が行う仕事の質や求められるスキルが変化していったのを感じた。
きっと、次の3年間もなんらかで変化が起こるはずで、振り落とされないよう頑張りたい。

※次のところ英語話さなきゃいけなくてほんとにヤバイ・・・

とてもながめのいいオフィスでした。

記事の内容に関連した相談、仕事依頼したい New

記事の内容やクラウドネイティブ技術に関する相談、仕事依頼を開始しました。
仕事依頼、相談をしてみる

フィードバック

本記事に対して、フィードバックあればこちらのフォームからご記入ください。
記事の内容にフィードバックしてみる

このエントリーをはてなブックマークに追加