内製開発組織つくるには
キーボードと脳が直結しているせいで色々やらかすことが多く、内省してばかりのﾘｱﾙﾏｶｰです。
タイトルは某有名 YouTube チャンネルのオマージュですね。
ジョブホッパーな私ですが FFG に在籍して4年半が過ぎまして、なにげに自分の最長在籍記録を更新することになりました。
これまでのキャリアではシステム開発会社やスタートアップ、テック企業みたいなところに在籍していたので、
事業会社での開発組織が立ち上がっていくところに参画するのはこれが初めての経験になります。
最長記録更新を記念して、これまで見てきたものを「事業会社が開発組織をもってシステムを内製するために支払ったモノ」を軸に振り返ってみたいと思います。
実際に導入している個別のソリューション名は挙げませんが、単に出して良いのかを確認をとるのが面倒だっただけです。
「やれDX」だ「やれ内製」と叫ばれる昨今、とは言うものの結構コストが掛かるもんだよね？と常々思っておりまして。
開発組織の立ち上げを考えている方や、すでに踏み出している方などの参考になれば幸いです。
機材
一般的に Web でもネイティブアプリでも、開発業務にはそこそこマシンパワーのある PC が必要です。
それを使うエンジニアの業務効率にも割と直結しますし。
iOS アプリを作る必要がある場合は macOS がほぼ必須ですが、そうでなくても最近 Mac を好む開発者は増えてきました。かくいう私も入社してすぐに「Mac 使えないと辞める」とゴネたクチです。
おそらく普通に事業会社で事務作業に導入するマシンは Windows でしょうから、新しく Mac を導入ことになると以下のような対応が必要になってきます。
端末の調達
利用中の MDM 製品が対応していなければ、対応を検討
利用中のセキュリティ製品が対応していなければ、対応を検討
コーポレート IT 部門での開発端末へのサポート体制
どこまで頑張るかは程度問題だと思うので、この辺はスモールスタートも可能かなと思います。
なお、開発用の端末のサポート体制は元々あった IT 部門では対応してもらえておらず、結局開発組織内で諸々やっています。
開発マシンではあまりないと思いますが、もし BYOD する場合でも何かしらの協議なりルール作りなり必要になると思います。
通信まわり
がっつりエンタープライズな環境であれば、インターネットアクセス用の Proxy サーバを設けて何かしらの制限を掛けていることだろうと思います。
そういう状況で異質な使い方をされる開発端末が入ってくる場合、おそらく既存のルールのままでは開発業務に支障がでるかもしれません。
あるタイミングから我々の端末もほぼほぼアクセスフリーだったところから許可リスト方式の制御に変わることになりましたが、変更タイミングで数百件のアクセス許可ルールを追加しました。
いまではカテゴリブロックだけになりましたが。それでも数ヶ月に一度は誰かの端末がブロック対象の URL にアクセスしてアラートが鳴り、事情聴取されることがあります。
ある程度ガバナンスが求められる環境であれば、開発業務由来の通信が増えることで何かとこういった運用が増えることが予想されます。
また在宅勤務を許可する場合はインターネットアクセスに各家庭の Wi-Fi を利用するケースがほとんどだと思います。
そうなると業務用の開発端末がセキュリティレベルの異なる私物デバイスと同一ネットワークにおかれることを気にする必要も出てくるかもしれません。
オフィスでも開発端末が接続するネットワークは出島状態だったため、それ用の固定 IP の回線を契約して使っています。この辺は銀行ならではかもですね。
開発環境
最近はもうパブリッククラウド全盛なので、初期投資といった形で開発環境にどーんと投資をする必要はなく、各クラウド事業者への明朗会計で安上がり！
そんなふうに考えていた時期が私にもありました。
便利な反面ちょっとしたミスが情報漏洩に直結しがちなのがパブリッククラウドで、FFG でも導入当初はスモールスタートで使い始めましたが今では以下の様なものが用意されています。
クラウド警察という愛称で親しまれている CCoE という組織
パブリッククラウドを安全に使うためのガイドラインと、そのチェックのフロー
3rd party 製の設定チェックサービスとその運用
これが最終形というわけではなく、クラウドサービスや技術トレンドなどの変化に対応しながら都度アップデートする必要があるため、今後も継続的に経費として掛かってくる感じですね。
品質保証
広義の品質に関しては FFG でも手探り状態にありますが、ことセキュリティに関しては元々あったルールに乗った上、内製開発組織が利用するものに合わせたものも導入しています。
どういうものが必要か・どうやって安全を担保するかの議論にも散々時間を費やし、当然今後新しいことをやる場合には都度議論が必要ですが、今は以下のようなものでセキュリティを担保しています。
有償のコンテナイメージのスキャンツール
社外の第三者によるアプリケーション脆弱性診断
社外の第三者によるプラットフォーム診断(インフラ・ミドルウェア)
セキュリティエンジニアの採用
この周辺は「技術が分からない人にどうやってそのアプリケーションの公開を認めてもらうか」あたりが、それ自体必要かどうかも組織によって事情が異なってくると思います。
人事周り
事業会社という視点からみると、エンジニアというのはだいぶ異質な存在かなぁと思います。
新たに開発組織を作るにあたり新卒採用だけでやるのはどう見ても無理、となると中途で即戦力のエンジニアを雇い入れる〜というのは自然な流れですが、
そういう事業会社にとってこれまでの採用の延長では難しいかもしれません。
FFG のエンジニア採用では、あくまで私から見える範囲ですが、以下のようなものを導入・実施しています。
採用基準の策定と都度の見直し
採用試験の準備(コーディング試験やらなくなりましたけど)
エンジニアに強い求人チャネルの導入
採用イベント実施
リファラル採用制度の新設
自社求人サイト内にエンジニア向けのコンテンツを追加
採用ブランディング
メディア運用(このnoteとか)
パートナー企業との関係づくり(全員直接雇用というのも難しいので)
また、特に評価や待遇に関してはそもそも銀行員向けのモデルとは異なるものにすべきという判断から、会社として制度を新設したりしています。
専門職という人事制度
専門職向けの評価制度
この辺は人事部でのことなので自分から見えていないところでもっと色々な苦労があったかもしれません。制定までに時間がかかっていましたし。
おわりに
細かいところをあげるとキリがないため上記でも何かと抜け漏れがあるかとは思いますが、エンタープライズな環境でシステム内製を目指した開発組織を作ろうとすると何かしらリソースが掛かるというのは伝わったかと思います。
「DX するためにはこれらを払う必要があるのか？」となるかもしれませんが、考えなしにこれらの投資をする必要はないと思います。
技術の手の内化 という言葉がありますが、テクノロジーという手段とちゃんと向き合って考えながら進んでいくというのが要かなと。
いきなり大きく始めるよりは、とりあえず技術ができる人をいれて自走してもらうような、以下の講演(外部サイト)で話されているようなアプローチも有効なのではと感じました。
DX担当としてクラスメソッドからアナログ事業会社に転職し一年間必死に戦った中で見えたこと