「【翻訳】外注したら約400万円かかるシステムを、コーディングなしで自前でつくったお話」の裏にあるもの

タイトルを見て、エンジニアに出さずに内製化したのかって早合点していたのだが、読んでみたら、人ってバイアスを掛けて情報をみているのだな、と自分で自分を諌めるなどしている。

エンジニアになって数年した頃、知り合いの知人の建設関連の人で

『こんなのをPCで実現したいんだけどいくらくらい』

と聞かれ、何も話を聞いていないから『100万くらいですかね』と言ったことがあった。要件わからないで規模を言うのもアレだし、それが自分で作れるかもアレなのに、随分と適当だったなと冷や汗ものではある。

あと、世間を知らなすぎな感じはある。今なら話を聞いて、誰でも持っているものでできないか、そもそもいるのか的な方向に持っていくだろう。なぜなら、ITにポンと100万出すほどの規模ではないからと察しがつくためだ。

数ヶ月した後、知り合いからその話があって、結局、知人の方はexcelで自分で作ったと聞いた。引用の記事のタイトルをみて、それを思い出して、引っ張られた。

今の自分は、外に出すよりはエンジニアのチームを抱える指向性を持っているので、そうしたこともバイアスの1つになっていると思われる。自分のことであるが、意思決定は自分の過去の成功体験などの積み重ねで捻じ曲げられるから、思われるとしか言いようがない。

とは言え、何が何でも内製かと言えば、そうでもない。SaaSは使う。もう、全部SaaSでいいとも思っているが、属する組織の実現したいことがSaaSで実現できないものもある。そういったものやSaaSに置き換えられないものは内製化になる。

SaaSを使い始めると、引用記事のように情報が分散する。目的に応じてSaaSを選び、業務を行うから、結果的に情報は業務別のSaaSに収容される。

ここで問題が起きる。SaaSの乱立は手作業を生じさせる。どんな手作業かと言うと、転記やデータを手動で出し入れである。

これはオンプレと言うかシステム間インタフェース（連携）の話だ。

インタフェースを決め、csvファイルをHULFTを使ったり、指定のディレクトリにファイルを置いて、決めたサイクルでファイルを読みに行き、スクリプトで取り込むなどよくやるものだ。

令和になり、2020年にもなろうと言うのに、平成なことを今度はクラウドでやろうとしているのである。

でどう繋ぐか。no codeだZapierなどで業務担当が繋いだり、codeならAPIでエンジニアが繋ぐことになる。

話は脱線するのだが、microserviceの本をサラリと斜め読みして、『あー、大規模システム内のサブシステムの開発をリリースはときどき合わせて、あとはサブシステム毎に業務都合の裁量で開発しているようなものか」と解釈していた。

組織内の業務アプリがSaaSへ移行すると、業務システムのmicroservice化が起きる。もともとSaaSだから勝手に機能もインタフェースも変わる。利用者やエンジニアへの配慮はない。プロダクトの都合で進んでいく。

やっぱり繋ぐ仕組みが必要で、microserviceならAPIなのだがZapierなどで繋ぐのでもいいのではと思うようになった。

なにせ、Zapierを使ったり設定したりするのが業務担当なら、SaaSのバージョンが勝手に上がって、インタフェースのサポートが切れようなものなら、すぐにわかる。直接のユーザだから。

使えなくなったら自分で直せるからエンジニアに頼まなくていい。エンジニアはAPIでゴリゴリ繋ぐ方か内製化の組織内向けのサービスプロダクトに集中すればいい。

そのことを事象として語っているのが、引用の記事なのだと思う。

そしてそれが事業会社のエンジニアリングの進む方向なのだろう。