見出し画像

地図を片手に不確実性に挑む!

こんにちは。long(@kametaro)です。1週間で自分がつぶやいたことを1つピックアップして妄想を膨らませる試み。今週はこちら。

お恥ずかしい話なんですが、ぼくはずっとエンジニアしか経験したことがなくて、気づけば今年で22年間もぼーっと過ごしてきてしまいました。最初はメインフレームのSEとして、COBOLで業務用のちっちゃなツールなんかを作ったりしていたんですが、まあドデカい基幹システムでしたので、一体自分が何に貢献しているのか、正直なところよく分かっていませんでした。

地図を描け

そんな感じで半年間ほど過ごしました。そんなんでよく半年も過ごせたなと思われるかもしれませんが、毒にも薬にもならない目の前のタスクだけは死ぬほどありましたので、なにも分からないままとにかく先輩のやってるオペレーションをひたすら覚える日々を過ごしていました。そんなある日のこと、おっかない上司に呼び出されましてこう聞かれました。

「おい、お前はこのシステムがどんな仕組みで動いているのか知ってるか?」

この問に対して、ぼくは、覚えたてのオペレーションの中から付け焼き刃、にわか仕込みで、なんとか色々答えを引っ張り出してみたものの、そんなので上司の満足のいくはずもなく、案の定、めちゃめちゃに怒鳴りつけられたのでした。

それから、上司はおもむろに自分のカバンから、でかい模造紙を取り出すとそれを机に広げました。それはシステム全体のめちゃめちゃ細かい製図みたな構成図でした。ぼくは当時、下請け会社の孫請け会社みたいな会社に所属している底辺の底辺的存在で、上司は一番上のプロパーの方でしたので、そんな重要なもんを自分みたいなのによく見せてくれたなと思います。しかも、それはシステム設計時に作成されたものではなくて、上司がこのシステムに携わった当初に、数週間かけて自分で作ったものと聞かされてさらにビビりました。この人、暇なんかな・・・?

「お前もこれを描け、自分で」

そう言われ、ぼくは上司を二度見しました。嘘でしょ、そもそもこんなの作れっこないし、すでにあなたが作っているのに同じものを作って何の意味がある・・・の?上司はぼくの疑念を感じ取ったのか、諭すような口調でこう答えてくれました。

画像1

「お前がやっていることは、全体の一部にすぎない。これからたくさんのことをお前は覚えていかないといけないんだから、闇雲に目の前の仕事をしていては覚えるにしても効率が悪い。オレは新しいプロジェクトや、新たなシステムに携わるときには、いつでもこの構成図を描くために、最初の2週間は仕事をしないと周囲に宣言している。これを描く過程で分からないことがあれば、一番詳しい人に聞きに行くからその人と懇意になれるし、自分が分かっていること、分からないことが明確になるんだ。オレはこの工程なしでいい仕事はできないと思っている。これは全体が見渡せる地図のようなものだ。これがあるから、いまやっている仕事が全てじゃなくて、全体の一部なんだと改めて理解できる。」

今考えると本当にありがたいお話なんですよね。あのとき、上司の立場からすれば、ぼくなんかほんとだたの使い捨てのコマみたいな存在で、ある意味目の前のオペレーションだけ淡々とこなしてさえいればよかったわけですから。こんな話をなんでわざわざ呼んでまでしてくれたのか・・。

と、まあ、なんにせよ、ありがたいことでして、ぼくもそれ以来、新しいプロジェクト、システムに携わるときには、既存のものがあろうがなかろうが自分用の構成図を描くようにしてきました。それが正解だったかどうかは正直わかりませんが、でも、やっぱり上司があのとき教えてくれたように、分からないことを直接詳しい人に聞くことで、その人と繋がることができますし、そういったコールドコールに対して臆することなくできるようになったのは、そうしてきたおかげだと思っています。

また、分からないことと、分かっていることが明確になるので、分からないことにのみ理解を注力できますし、一方、分かっていることについては、さらに余白を埋めることで深い理解につなげることができます。マクロな視点とミクロな視点の両面においてこの地図の制作は有用だと感じています。めでたし、めでたし。

データエンジニアという職種

さて、時が経ち、若かりしCOBOLのエンジニアだったぼくは、あの頃の上司と同世代のおじさんとなり、今ではデータエンジニアになりました。データエンジニアという職種はまだまだ日本では市民権を得られてない気もしますが、海外ではデータサイエンティストよりも企業からチヤホヤされているという実はかなりイケてる職種なんだそうです。しかし、まあ、やってることはかなり地味ですから、いわゆるビッグなデータをあっちにやったりこっちにやったり、状況に応じてちゃんと確実に入れたり(ACID)、雑に素早く入れたり(CQRS)と、要するに、その名の通りデータを扱うのが得意なエンジニアということになります。

データエンジニア にとって不確実性

画像2

これは、不確実性コーンという有名な図ですね。ソフトウェア作り始めた当初は不確実性が大きく、完了間際には不確実性がほとんどなくなるという、そんなことを表した図です。ところで、この最初の不確実性要素についてその構成を考えてみると、大きくは未来への予期できないという要素と、現状の不理解による要素が占めているのではないでしょうか。さらに、この二つの要素というのは、互いに独立した要素というよりは、現状に対して未来は従属する関係にあり、つまり、現状の不理解に起因している不確実性要素を可能な限り潰しておけば、未来の予期できない要素も連動して潰すことができるのではないかと思うんですよね。

具体例

たとえば、オンプレで長年使用してきたシステムをいよいよクラウド化したいという、たっての要望が前提にあって、新任の担当者はその要望を満たすために構成を検討したとしましょう。その際、彼は一般的なクラウド・パターンのテンプレートを参考に、まあいわゆるありきたりな構成を考えてみました。

この場合、この新任担当者が地図を描かなかった場合どうでしょう?きっと、クラウドへのデータ移行はスムーズにいかないでしょうね。なぜなら、彼は、どのようなデータがどのデータリソースに保存されているかも理解していないし、どういった頻度でそのデータが保存・更新されるのかも分かっていないですので、データが保存されるタイミングやリソースサイズなどで最適化することは難しくなるでしょう。

また、過去のデータの保存経過の勾配から回帰的に未来のデータ増加量を予測することもできないので、適当に選択したデータリソースが十分なストアコストを維持するためには、料金コストはどの程度かかるかなど判然としません。つまり、現状から回帰することで潰せたはずの未来の不確実性までそっくりそのまま未来の負債として繰り越されてしまったわけです。もし仮に、彼が地図を仔細に描き、詳しい担当者と密なコミュニケーションをとっていたら、回帰曲線上にシステムをクラウド移行することができたかもしれません。負債はこうやって未来に受け継がれていくんですかね・・。

しかも、データエンジニアリングに関していえば、プロダクト制作にはない不確実性もたくさん存在するんですよね。ぼく自身がもっとも顕著だと思うものを2点あげてみます。

1点目はデータ量そのものが非決定的であるという点です。これはたとえば、プロダクト開発においては、とある関数の返す出力値は入力に対して一意に定まりますが、このことを決定的といいます。ところが、データに関しては、ある日のデータ量は多く、またある日のデータ量がその半分にも達しないということもよくある話で、さらに機械学習を使う場合では推論結果が入力に対して一意という保証はありません。これが非決定的な世界です。非決定的とはすなわち不確実なわけですので、データエンジニアは日常的に不確実と向き合わなければならないということになります。

次に2点目は、仮説に対する効果検証についてです。仮説が常に採択されるならそれは決定的でよいのですが、仮説は棄却されるものですし、それは効果検証が終わるまでわかりません。で、結果に対してデータは都度変更されますので、仮にデータを事前に構造化したスキーマとして確定させてしまっていたとしたら、過去のスキーマと変更後のスキーマとで整合性を維持できず、結局また別のスキーマを新たに作らざるを得ないという状況も起こり、一意性のあるデータを持続することがとても困難になります。

このように、データエンジニアリングにおける不確実性要素は、ソフトウェア制作のそれと比較してもさらに大きいと言えるんですね。その困難な課題に挑むためには、データエンジニア はさらに念入り、かつ、広範囲な地図を描かなくてはいけませんね。

まとめ

今週は昔話から、いまの思いの丈をだらだらと書きました。データエンジニアがいかにイケてる職種かということを、もし共感してくれる人がいたとしたらとても嬉しいです。事業会社ですと、正直なところ、データエンジニアリングってやってることが経営サイドからとても見えづらいんです。なんで、データエンジニアを専任で一人雇う判断ってなかなか難しいとおもうんですよね。そんなわけで、データ基盤も作れば、分析もするし、機械学習のモデルも作るし、デプロイも自分で、みたいな兼業になりがちで、ただ、それが全部できる地図を持っていることこそがデータエンジニアの強みだし、面白さでもあると思うんです。そんなデータエンジニア が日本でも早く市民権を獲得して、イケてる職種だと認識してもらえる日がくるといいな。

この記事が気に入ったらサポートをしてみませんか?