Sign in

こんにちは
JDSCのエンジニアだった横山です。
だった?
最近フロントチームへ移籍しました。
フロントというのは、営業やコンサルティングなど、クライアントワークが中心のロールです。

TL;DR
なんでそんなことになったの? ということを今日は書いていきます。
技術的なことはほぼ無いですが、エンジニアのキャリアパスとして、そういうのもあるかも? と思っていただければ幸いです。

※そもそも、TL;DR(Too Long, Didn’t Read笑)といったエンジニアにはお馴染みの書き出しも通じない世界へ飛び込むわけなので、そういった言葉が通じないというのを常に頭の片隅に置いておく必要があります。

そもそもなんでそういうことになったの?

JDSCでは三位一体(バックオフィスを入れると四位一体)をポリシーにしています。
- フロント(FR)
- データサイエンティスト(DS)
- エンジニア(EN)
が一体となって、プロジェクトを進めたりプロダクトを作ったりしてます。
しかし、言うは易く行うは難しで、実際に協働しようとすると様々な問題が出てきます。
その中からいくつかピックアップします。

実は、フロントとエンジニアではプロジェクトそのものの捉え方にズレがあります。
エンジニアでプロジェクトと言えば100%システム開発が伴いますが、フロントではシステム開発が伴わないプロジェクト、例えば戦略策定支援や、業務改善提案等があります。
そのため、単にプロジェクトと言っただけだとそれはビジネスプロジェクトなのかITプロジェクトなのか分からずに進めてしまうので穴に落ちがちです。

それを防ぐためにITプロジェクトかどうかを意識し、プロジェクトマネージャーもITプロマネと呼称し、採用もITプロマネとプロマネを分けて募集しています。

成果物に対する考えも違います。
極論を言えば、フロントの成果物はパワポです。
もちろん、内容に関しては膨大なリサーチや思考の結果なのですが、厳密な検収もなく、クライアントが「いいね!」と言ったら検収OKになったりします。
そのため、クライアントとの関係構築が重要で、怒られながらもドメインナレッジを急速に吸収し、信頼醸成していきます。
これは、動いてナンボのエンジニアの世界とはかなり違った世界と言えるでしょう。

他にもいろいろとギャップがあるのですが、そういった諸々の積み重ねにより「あれ? あれ?」といったディスコミュニケーションが度々発生するようになりました。

というわけで、順序が逆転するのですが、そういったディスコミュニケーションの原因が何かが良く分からなかったので、フロントとエンジニアを越境するポジションをつくって明らかにしていくということになり自分がアサインされた次第です。そして、明らかになったことが上記等のズレの原因になります。

さて、部門間のコミュニケーションギャップをどうやって見つけていくかというと、これはもう地道に1on1を重ねていくしかないというのが現時点での答えです。
もしかしたら、もっといい方法があるのかもしれませんが、同じ会社の社員同士であっても信頼醸成というのはそんなに簡単ではないと思っています。そのため時間がかかっても少しずつ丁寧に相手の声に耳を傾けることが結果的に最短最適なのではと考えます。

そして、そのギャップをどう埋めるかを考えました。
それが上で出たITプロマネの導入です。
どういうことか?


スモークテストのすゝめ

スモークテストとは何か?

IT用語辞典より

> 開発・修正したソフトウェアを実行可能な状態に組み立て、起動するかどうかや基本的な機能が動作するかなどをざっと確認すること。

となっているが、もう少し具体的に定義する。

- 実装者による動作確認

- 単体テストと結合テストの間に位置するもの

実装者をサーバーサイドに仮定すると、

- クライアントや外部サービス向けのAPIの動作確認

- バッチ処理の動作確認

となるが、今回は都合上クライアントの動作確認に限定する。

つまり、サーバーサイドエンジニアが実施するステージング環境でのAPIの動作確認ついて考える。

なぜ、スモークテストが必要か。

単体テストは実施済みという前提で考える。テストファーストて何?という人もまずはそちらから調べてください。

テスト駆動開発自体はだいぶ普及して、実際にカバレッジがある程度ないとレビュー通さないという文化もできてきている。それでもバグは減らない。単体テストをどう完璧にしてもステージングや本番でのバグは減らない。

その理由の一つとして結合テストや総合テストのリソース不足がある。

リリース日が遅らせられない場合は、実装フェーズが遅延するほどテストフェーズにしわ寄せがくる。

予定より少なくなった時間で品質を担保するのは無理で、どうしても項目を少なくしたりするしかない。

そこで、バグが発見されて戻しが発生するとなおさらである。

スモークテストはそういう状況を少しでも減らすのが目的である。

どういうことか?

そもそも単体テストの実施のみでステージングでQA開始になったとたん、いきなりつまづくことがある。

その原因は、例えば

- ファイルのデプロイ漏れ

- 設定が漏れている

- デプロイが失敗しているのに気づかない

- DBのテーブルが作成されていない

- テストデータが用意されていない

などなどである。

そのため、QAから「なんかエラーで動かないんですけど」と聞かれて調べてみると上記のような凡ミスが多い。

その時間(再デプロイを含む)だけでも、数十分から長いと数時間になる。

そして、QA側のストレスも貯まり、こういった状況が続くとお互いの信頼関係にも影響がある。

また、結合テスト本来の目的であるサービス間のテストやデータの整合性のテストの時間も食いつぶしてしまう。

スモークテストはそういったQA側の負担を減らすために実装者が実施するテストである。

上記に対応してみると

- マージするプルリクエストに対象コードが全て含まれているか

- 各種設定ファイルは開発環境だけでなくステージング環境も追記・更新済みか

- デプロイは正常終了しているか

- マイグレーションは正しく反映されているか

- テストデータなどは自動または手動で生成されているか

などを確認した上で、さらに実際に動作確認する。

APIの確認はポストマンが必須と思っていい。

https://www.getpostman.com/

ポストマンが便利なところは、

- headerやbodyをエンドポイントごとに保存が可能

- content-typeの設定が簡単

- jsonの記述が簡単

などである。

そして、ステージングのエンドポイントを叩いてみる。想定した結果が返ってくればOK。ただそれだけである。

このスモークテストを実施することにより、QA側は最初からスムーズに結合テストに入れる。数分の手間で無駄な数時間をうまなくてすむ。また、スモークテスト中に実装バグに気づくこともあり、そこで修正できればさらに以降のリソースも浪費しなくてすむ。

スモークテストという名前の由来は、昔、配管工が工事を終了したときに煙を流してみてどこからも漏れていないかチェックした事からという説がある。

私たちも、ものづくりの一端を担うものとして最低限のQA(=品質保証)を担保するようにしたい。


こんにちはJDSCエンジニアの横山です。
アルカモとは、有事の際に必要なものの在庫状況を皆で共有するサービスです。
地図の描画にはGoogleマップを利用しています。
コロナウィルスの拡がりに対して、JDSCとして何か社会貢献活動をできないかという思いが発端になっています。

アーキテクチャ


以前の記事で書いたエンドツーエンド機械学習のアーキテクチャの前処理部分をどうするかについて。
結論を先に書いておくと現時点ではBashOperatorがベターな選択ぽい。

前処理は基本的にBigQueryのデータセットで進めたいので、それを操作できるオペレータは何があるかあげてみる。

  • BigQueryOperator
  • DataflowOperator
  • PythonOperator
  • BashOperator

それぞれのオペレータについて特徴は以下の通り。

BigQueryOperator

Clout Composer->BigQueryOperator->BigQueryと一番素直なパターン。しかし、最大の欠点としてUSリージョン以外ではBigQueryOperatorの処理結果を取得できない(マジかよ…という感じ)。なので、実際に成功してても常に失敗となるのでCloud Composerを使う意味がなくなってしまう。

DataflowOperator

Clout Composer->DataflowOperator->Dataflowというパターン。BigQueryの操作hはDataflowのパイプラインで実行する。Group Byで集計したレコードを並列処理するなど強力な機能もあって大量データのバッチに向いているが、これもUSリージョン以外では処理結果を取得できない(マジなんなの…)。
このBigQueryOperatorとDataflowOperatorで、処理結果を取得できないバグはAirflow本体では修正済みとなっているが、まだCloud ComposerのAirflowには取り込まれていないもよう。

PythonOperator

Clout Composer->PythonOperatorというパターン。BigQueryの操作はPythonOperatorからgoogle-cloud-bigqueryパッケージを利用する。実際の前処理は、SQLやDataframeなど選択の自由度がある分責務が分散する可能性がある。また、クエリの結果が大量に返ってくる場合にプロセスごと落ちる可能性もある。

BashOperator

Clout Composer->BashOperator->bqコマンドというパターン。実際の操作は外部ファイル等に記述し、bqコマンドはその内容を実行するだけ。SQLをそのまま実行するのでBigQueryの機能をフルで使用できる。
サンプルコード:

もし、Cloud ComposerとBigQueryをUSリージョンで稼働させられるならばそれがベスト。できないならば、BigQueryOperatorとDataflowOperatorは対象外となる。
PythonOperatorかBashOperatorかは、前処理の内容による。
前処理がSQLですべて完結するならば、外部ファイル化してBashOperatorから起動するのがシンプルで良い。
SQLだけで完結できない場合、例えば条件判定を含む複雑な集計や、外部パラメータの読込が必要だったりする時はDataframeを使って加工するのが良いかもしれない。

with DAG(
"pre_processing",
schedule_interval=None,
default_args={'start_date': datetime.datetime(2018, 1, 1),}) as dag:

query = bash_operator.BashOperator(
task_id='query',
bash_command='bq query --use_legacy_sql=false < /home/airflow/gcs/data/std.sql')

query

考察

もし、Cloud ComposerとBigQueryをUSリージョンで稼働させられるならばそれがベスト。できないならば、BigQueryOperatorとDataflowOperatorは対象外となる。
PythonOperatorかBashOperatorかは、前処理の内容による。
前処理がSQLですべて完結するならば、外部ファイル化してBashOperatorから起動するのがシンプルで良い。
SQLだけで完結できない場合、例えば条件判定を含む複雑な集計や、外部パラメータの読込が必要だったりする時はDataframeを使って加工するのが良いかもしれない。


CloudComposerでBiqQueryOperatorを使ってデータ処理をしようとすると

ERROR - ('BigQuery job status check failed. Final error was: %s', 404)
Traceback (most recent call last)
File "/usr/local/lib/airflow/airflow/contrib/hooks/bigquery_hook.py", line 1132, in run_with_configuratio
jobId=self.running_job_id).execute(
File "/opt/python3.6/lib/python3.6/site-packages/googleapiclient/_helpers.py", line 130, in positional_wrappe
return wrapped(*args, **kwargs
File "/opt/python3.6/lib/python3.6/site-packages/googleapiclient/http.py", line 851, in execut
raise HttpError(resp, content, uri=self.uri
googleapiclient.errors.HttpError: <HttpError 404 when requesting https://www.googleapis.com/bigquery/v2/projects/xxxxxx/jobs/job_xxxxxxxxx?alt=json returned "Not found: Job xxx:job_xxxx-xxxxB"

というエラーが発生する。これはBigQueryの結果を取得する時にUSリージョン固定になっているのが原因のもよう。
参考:
https://stackoverflow.com/questions/55300785/google-cloud-composer-bigquery-operator-get-jobs-api-httperror-404
Airflowをここ3ヶ月触ってみた

この問題に対応したプルリクエストはマージ済みぽいので、ComposerのAirflowのバージョンアップ待ち状態。


なんと5年ぶり。つまりMediumは5年間生き残ってきたということ。


某学会誌の表紙が炎上していて、それについて考えた時にモテ/非モテの文脈を使ったのでもうちょっと掘り下げようかと。

非モテという状態は怨嗟や呪詛がどんどん積もっていって、やがてその重さで全てがクラッシュすることが予想されると思っている。

若い時はモテる要素の種類が少ないけど、年を重ねるにつれその種類も増えて、非モテから脱出するのがベタールートと考えているけど、これはどういうことかというと…

例えば小学生の時て、カッコイイとかスポーツ万能とかがモテ要素で、その要素を持っていない人間はなかなかモテることはない。

それが中学生や高校生になるにつれて、頭がいいとか、楽器が上手い、話が面白い、など要素が増えていって、大人になったら経済力があるとか、家柄が良い、優しいなどより多様になっていく。

そのため、小さいころモテなくても、やがて相思相愛の仲になるような人も現れてめでたしめでたしというルートが王道なんだけど、やはりいつの時代もいつの世界もルートに乗れない人間はいるもので、そういう人はずっとモテない状態が続く。

そうなると、モテるための努力(そもそもそれが誤り)も空回りし、努力が報われないことに対して鬱憤が溜まっていく。やがて、それは周りに発散されることにもあり、また自分の内面をも崩していく。

もちろん、非モテでも人生を楽しく生きることは可能だと思うし、そう生きている人もいると思うけど、50歳や60歳になっても友人や異性の話し相手が一人もいない状態というのは相当つらいんじゃないかなと思う。

ルートから外れたら人たちはどうしたら良いのかは難しい問題で、どうやったら少しでも良くなるのやら。


読むドラッグという表現がこれほど当てはまる本も珍しいかも。
菊地成孔の文章は意識して避けていたけれど(話すとちょっと長くなる)やはり正解だった。
もし中高生でこんな文章読んでしまったらあっという間に持っていかれたと思うし、戻ってくるのにものすごい年月と体力を使いそうだ。
今では、用法用量を守って正しく読める精神になったのは嬉しいことなのか悲しいことなのかは分からない。


医療の現場や製薬業界てデータジャーナリズムと相性いいんじゃないかな?
治験やPMSのデータも整備が進んでいるし、テーラーメイド医療やゲノムの話にしても、大量のデータからなにか特徴を抽出するというのは結構需要がありそう。


てすてす

これはてすとです

yoko8ma

ソフトウェアエンジニア/サーバーサイド/グロース/AI/酒部/焼肉部/カレー部。2020年3月から某データサイエンスカンパニーにJoined

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store