データサイエンティストに転職して1年ちょっとの感想
春なので何かを書いてみたくなった
上記の記事で、転職3ヶ月後の記録を書いてから1年弱の間完全にブログをサボっていました。ただ、4月1日ということもあって、Twitterで新天地で活躍する思いを表明されている話とか、いろんな人のブログとかを見ているうちに何となくこの一年あまりを振り返ってみたくなったので書いてみようと思います。
この一年どんな案件に関わってきたのか?
自然言語処理案件
大量の自然言語公開データを使って、今まで一部のプロフェッショナルがやってきた判断と類似の判断を自動で行うという案件を担当しました。機械学習とルールベースの処理を組み合わせて実現するような案件で、似たような案件を複数件担当しました。
何度かPoCを行って、ある程度有用な示唆を出せるようにはなったのですが、どれもプロフェッショナルを代替するような結果にまでは至らず、プロフェッショナルを一部サポートするツールという位置付けとなりました。
単語分割してベクトル化等を行うWord2Vecなどをベースとする技術から、BERT系の技術まで使って一通り実装してモデルを作ったりしました。単純な文書分類器というわけではなくルールベースを組み合わせたりする必要があったのが大変でした。またプロフェッショナルが判断を行った正解ラベルにかなりバイアスがあり、これも何を正解とすべきかがだんだん分からなくなったりして大変でした。
本当の最先端の技術を使った訳ではないですが、前処理等含めて自然言語処理の基本的な部分や、大変な部分を色々経験できたので良かったと思います。
時系列データ分析案件
とある時系列データの分析モデルを作る案件でした。メインでの担当ではなくサポートです。
精度の良い予測モデルを作ることが目的ではなかったので、SARIMAなどのモデルにその他の説明変数を加えた線形重回帰モデルを構築しました。前処理や、説明変数の選別などを行い、一定以上の精度のモデルができたところで、目的変数の変化を説明する要因を分析していきました。
この案件で、SARIMAというモデルを初めて知りました。単純だけど理論からの先見情報がない時系列変化をモデル化するには便利なモデルだなと思いました。時系列データの分析は前職でも色々やっていたのですが、物理現象など微分方程式で一定の定式化がされているデータを扱うことが多かったので、先見情報となる理論がないのは新鮮でした。
異常検知案件
これも時系列データ分析案件の類似案件ですが、時系列データからの異常検知でした。
SARIMAモデルを応用して、周期変動成分、トレンド成分、ノイズ成分を分離し、本質的な変動が一定閾値を超えるような異常変動を検知する比較的単純なモデルを作りました。ただ、残念ながら元のデータがあまり明確なトレンドを持ったデータではなくノイジーなデータだったため、”異常”をきちんとは検知できませんでした。
FFTやウェーブレット解析などの周波数分析も少しだけ試みましたが、あまり有用な結果は得られませんでした。
統計分析案件
こちらは「とりあえずデータがあるんだけど何かできない?」という典型的な失敗に向かう案件でしたが、やることになりました。
一番つらかったのが、ビジネス観点から分かる仮説をカウンターパートとなるビジネス側の人間が何一つ提示してくれないという状況からスタートしたことでした。さらに非常に短い期間で結果を要求される案件であったため、あまりきちんとビジネス側にヒヤリングをすることも出来ずきつい案件でした。
結局のところ基本的な記述統計量を様々な属性ごとにまとめたり、散布図やヒストグラム、相関ヒートマップなどの可視化等基礎分析を行なった上で、暫定仮説を立てて統計検定を行いました。
この案件の中でパラメトリック、ノンパラメトリックの統計検定やpost-hoc analysisのやり方や、多重検定時の補正、効果量や信頼区間、サンプルサイズなど色々なことを学び直しました。
検定結果から得られた示唆は、ある特定の属性間において仮の仮説に基づいていくつか定めた目的変数間に統計的に有意な差異が見られる、という結果になりましたが、まあ想像した通り「そんなことはもう知ってるよ」という返事がビジネス側から得られました。
ちなみに、仮説のきちんとした検証は継続的にデータを取ったり、そもそもデータを取得する計画をきちんと立てないとならないという話をしましたが、示唆が当たり前のことしか言えなかったため継続した話にはつながりませんでした。
この案件で、HARKing, p-hacking, asterisk-seekingという言葉を恥ずかしながら初めて知りました。これらを学べた点や、数理統計学の実用上の落とし穴を色々学べた(というか必死に勉強し直した)点は良かったように思います。
組み合わせ最適化案件
とあるデータリストと、とあるデータリストの最適な組み合わせを探る案件でした。(この説明では抽象的すぎて、何も説明できていないですがご容赦ください。。。)こちらもメイン担当ではなくサポートでした。
一番難しいモデリング部分は別のデータサイエンティストの方が基本的に終えていたので、組み合わせ最適化問題を解くだけでした。
制約条件が非常に複雑で、多項式時間で最適解を求められるような形にモデリングではなかったので、ソルバを使って混合整数計画問題(MIP)を解くか、ヒューリスティックな手法で解くかのどちらかでした。
結果としてこちらでは遺伝的アルゴリズムを使ったヒューリスティックな方法を採択しました。精度が保証されるやり方ではないので、あくまで解は参考値として最終的には人が判断するという形になりました。
ただ、結果はプロフェッショナルな人間の目から見てそれなりに妥当な結果であったようで、人間が一から組み合わせを考えるよりも、十分使えるという形になりました。
簡単な分析処理を組み込んだアプリ開発
直接のデータ分析案件からは少し離れますが、ソフトウェアエンジニアと一緒に協力しあってクラスタリング処理や、PCAによる次元圧縮などの処理をベースとした分析処理を行うWebアプリを作りました。
フロントはフロントエンドエンジニアに任せていましたが、バックエンド処理はそれなりに作りました。フロント側はVue.jsでした。
AWS上で作ることになり、AWS自体あまり使ったことがなかったので最初はかなり戸惑いました。ただ慣れてくると、軽い処理はAWS lambdaで、重い処理はAWS batch(中身はDockerで作ってECRに保存してデプロイ)で比較的簡単に作れるということがわかりました。
フロントもシンプルなものならS3にデプロイして、lambdaでAPIを作れば比較的簡単にWebアプリは作れるということがわかりました。
今まで、SIerではオンプレのサーバ等でしか開発した経験がなかったのでAWSのインフラ構築とデプロイの簡単さは驚きました。一方でAWSのサービス自体はものすごく多く、使いこなすのは大変だなという思いを抱きました。あと権限周りの設定が非常に多岐にわたっていて難しく、今だにこの辺りは単純な例を除くとよく分かっていません。
その他の案件と直接関係ないお勉強
- 因果推論(効果検証)、因果探索等を勉強し、勉強した内容を発表したりしていました。
つくりながら学ぶ! Pythonによる因果分析 ~因果推論・因果探索の実践入門 (Compass Data Science)
- 作者:小川雄太郎
- 発売日: 2020/06/30
- メディア: 単行本(ソフトカバー)
- 強化学習の勉強も少ししていて、勉強した内容を発表したりしていました。
一年を振り返ってみて
こうして書き出してみると、色々やったなーと思いました。まだまだ、勉強しなきゃならない事はいっぱいありますが、データサイエンティストとして、ある程度のことはできるようになってきたのかなと思っています。
自分自身何か1つの技術に特化したデータサイエンティストではなく、広く知見を伸ばし、ビジネス課題を解決するための適切な手法を選択できるようなデータサイエンティストになりたいと思っているので、可能な限り手を動かし、より広い知識と経験を得ていければなーと思っています。
データサイエンティストに転職して3ヶ月弱経過したので雑感を書いてみる
転職後約3ヶ月経っての雑感
1月31日に前職のSIerを退職して、コンサルティング会社のデータサイエンティストとして転職してから大体3ヶ月弱の月日が経過したので、その雑感を書こうと思います。
退職時の記事は以下にあります。
データサイエンティストの仕事について
下記でツイートしていますが、結論としてはあまり違和感なく仕事ができています。
SIerのSEからデータサイエンティストに転職して3週間が経ったけど、凄い勢いで色んなことを学んでいる。
— たー@in_the_rye (@in_the_rye) February 21, 2020
新しく知ることが多いけど、全く違和感がなくすんなり理解できるので、自分がこれまで学んできた事は無駄じゃなかったんだと思えて素直に嬉しい😆
前職でも特殊な業務ドメインでしたがデータの分析を行う機会は多かったのと、あとは博士課程でのデータ分析のバックグラウンドもかなり生きていると思っています。
データサイエンティストの仕事は一言で言えば「データから何らかのインサイトを導き出す」ことなので、今までやってきた仕事は特殊なドメイン知識を用いた解析ではあったものの本質的には変わらない仕事をやっていたのだと今は思えています。
SIerの経験も生きている
これも、下記でツイートしていますが、やはり何だかんだでSIerの経験は生きています。
SIerでのプロジェクトマネジメントの経験は守りの技術で、博士課程で培った発見的な思考は攻めの技術なんだと、改めて実感している。
— たー@in_the_rye (@in_the_rye) February 21, 2020
両方とも持っているという人は余り居なくて、結構価値を生み出す事に繋がっているのでは無いかと思えて、少しずつ自信に繋がって来ている。
データサイエンティストに転職してみて思うのは、分析スキルは大事だけど、要件定義能力がないとその分析スキルは結局評価されないということ。その意味でSIerの経験はなんだかんだで役に立つ。
— たー@in_the_rye (@in_the_rye) April 16, 2020
まあ、事業会社じゃないからってのも大きいのかもしれないけど。
SIerでのプロジェクトマネジメント経験
リスクをどのくらい積んで見積もりをするのか、そのリスクの管理をどうするのか、経営層やクライアントとそれについてどう交渉するのかなどの点含めて諸々やってきた経験は、そのままデータサイエンスプロジェクトや機械学習エンジニアリングのプロジェクトでも通用すると思いました。
もちろん、見積もり(工数、期間)はデータサイエンスプロジェクト等に特有のプロセスに対しての具体的な作業イメージがないと精度が上がらないので、その点での不確定要素はありますがシステムの納品に比べてプロジェクト期間が短く成果物が比較的軽い(報告書がメイン)、かつPoCなどのフェーズではアウトプットに調整の余地があるという点でむしろリスクコントロールがやり易いように感じています。
SIerでの要件定義経験
これも大きな点ですが、やっぱりデータサイエンスプロジェクトや機械学習エンジニアリングのプロジェクトでも結局は”なんの課題を解決したいのか”と”そのためにどういうソリューションを選ぶのか”という点が大きな点で、SIerでやってきた要件定義の経験がそのまま生きてきます。
どれだけ多くの分析手法や機械学習モデルの構築手法等に長けていても、結局何を解決したいのかのところを詰め切れないと良い手法を選択することはできず、そのための課題分析の能力はデータサイエンティストでも強く必要とされるのだと思いました。
全部うまくいっていて、困ったことはないのか?
これまで、すべての経験が生きていてまるで困ったことがないようなことばかり書いていますが、当然足りない部分もあり色々キャッチアップしないとならない部分も感じています。
基本的な分析手法の知識がすっぽり抜けていることがある
おそらく”データサイエンティスト”の職業にある人は99%が知っているような基本的な知識がたまにすっぽり抜けていたりすることがあって、ジュニアなデータエンジニアとかに「えっ知らないんですか?」的な目で見られてたまに恥ずかしい思いをしたりします。
例を上げると大変恥ずかしいのですが、今まで回帰分析の「決定係数」をちゃんと知りませんでした。。。
ただ、もちろん用語に馴染みがなかっただけで、その定義の数式を見れば何を示しているのかはすぐに理解できたので単純に言葉を知らなかっただけになります。(が、それにしてもかなり恥ずかしいくらいの基本です。。。)
言い訳
一応、言い訳を言うと、今まで取り扱ってきたデータは大体何らかの定式化されたモデルに従うことが前提になっているようなデータで(例えば物理現象であれば大抵何らかの微分方程式で記述できるなど)そもそも、前提となる定式化が存在しないデータに対しての分析というのをやったことがなかったので、回帰分析での決定係数を指標として用いて評価をするということもなく知らなかった、ということになります。
でもキャッチアップはすぐできる
上記のように、基本的な知識は抜け落ちている場合がありますが逆に無駄に詳しく理論を知っていたりする分野もあるので、その辺の知識をベースにすると基本的なことはその知識との類似性とかから結構すぐにキャッチアップできるので、その意味でも今までやってきたことは無駄じゃなかったんだと感じています。
まとめ
総じて、現在の所、直接的な仕事の実感としてはうまく行っているという感触を得ているので、このまま順調に仕事を続けていければなと思っています。
あとは昨今のCOVID-19による影響で、世界経済が停滞してデータサイエンスや機械学習プロジェクトなどへの投資も直近ではシュリンクしてしまっているのは事実なので、そのあたりも含めて何とかうまくビジネスを回しつつこの居場所を確保し続けられればなと思っています。
詳解ディープラーニング(第1版)の読書メモ
ずっと積ん読してた詳解ディープラーニング(第1版)を読みました
詳解 ディープラーニング ~TensorFlow・Kerasによる時系列データ処理~
- 作者:巣籠 悠輔
- 発売日: 2017/05/30
- メディア: 単行本(ソフトカバー)
ずっと積んでるうちに第2版が出てしまっていました。。。
まあ、pytorchに対応したりtensorflowのバージョンが上がったりといった実装としての記述が変わっただけのようなので、時系列データを扱うディープラーニング(RNN系)の理解のためには第1版のままでも良いかなと思い一通り読んでみたので、自分のためのメモをここに残しておこうと思います。
ざっと読んだだけなので、あまり理解出来てなくて間違った解釈をしているところがあるかもしれませんので、詳しい人がこのブログを見ていたら優しく指摘してもらえると大変助かります。
また、以下のメモは自分が理解する為に書いたものなので、書籍に書いてない部分を想像して書いているところや、メモだけでは意味がよくわからない記述や、一部単なる感想を書いているところもありますので記述の統一感の無さ等に関してはご容赦いただければと思います。
以下にメモを書きます。
1〜2章は準備部分でそれほど面白い内容はなかったので、特にメモは無しです。
3章 ニューラルネットワーク
- 単純パーセプトロン
- 複数の入力、1つの出力でかつ活性化関数がステップ関数の1層のニューラルネット。
- 入力が二つだと単純で分かりやすい。
- 2値分類になる。ある入力(x1, x2)が y=0, 1の2値分類する。
- ロジスティック回帰(1出力)
- 単純パーセプトロンの活性化関数をシグモイド関数にしたもの。
- 尤度関数を最大化する最尤法で解いているので、最小二乗法になれた身としてはわかりづらかった。
- 最尤法と最小二乗法で線形最適化問題を解く例は下記を参照。
- https://qiita.com/shngt/items/13151c778956b011dfca
- 最尤関数の-logをとって掛け算を足し算に直したものを損失関数としている。
- 勾配降下法として確率的勾配降下法が説明されている。
- 勾配降下法は損失関数をパラメーターwとbで偏微分して、学習率ηをかけた変化分をくわえながらwやbを更新していく。
- 学習率ηは一般的に0.1などが使われる。
- Δw = wk - w_k-1 の変化が閾値以下になったら収束と見なせる。
- 学習率ηは実際に変化率に対してどれだけ大きく更新するかの更新量に影響する。
- 大きすぎると収束しないし、小さすぎると収束に時間がかかる。
- N個のデータx_n(n = 1〜N)に対して1つのバッチで勾配降下法を使うのが普通の勾配降下法。
- N個のデータからランダムにいくつかのデータを選んでMグループを作ってこれらのグループ毎に勾配降下法を行って、値の平均値を採用するのが確率的勾配効果法。
- 勾配降下法は損失関数をパラメーターwとbで偏微分して、学習率ηをかけた変化分をくわえながらwやbを更新していく。
- 2値分類ではなく確率が出力されるが、線形の分類問題。
- ある入力(x1, x2)が平面にプロットされて、それを分類する直線が存在し、そこから離れるほどその分類の正しさが確率が高い値になるようなイメージ。
- 多クラスロジスティック回帰
- 多層パーセプトロン
4章 ディープニューラルネットワーク
- ディープラーニング(3層以上のディープニューラルネットワークによる学習)
- かつては、隠れ層を増やしたニューラルネットワークは使われていなかった。下記のような課題があったため。
- 勾配消失問題
- シグモイド関数は端っこの微分値がほぼゼロでまた最大でも傾きが0.25なので、隠れ層が多くあると、その微分値を掛け合わせることでどんどん誤差項が小さくなっていく。→勾配の消失。誤差逆伝播での勾配が小すぎるということは、どれだけ学習してもパラメータがほとんど更新されないことになってしまう。
- 解決策としては中間層の活性化関数のみ以下のような活性化関数を採用する。(最終層は、ソフトマックス関数やシグモイド関数など)
- オーバーフィッティング・オーバーラーニング(過適合・過学習)
- 勾配消失問題
- その他の問題
- 局所最適化への対処
- モメンタム
- 学習率を0.1などの固定にせずに、最初は大きく徐々に小さくする。
- 学習率そのものをは変化させずに、モメンタム項という調整項を更新して行き、擬似的に学習率を調整する。
- 物理現象との対応で言えば、落下運動に空気抵抗に相当する項(速度に応じて抵抗が生じる)を加えるようなもの。
- Neserovモメンタム
- 次のステップの更新量近似値がわかるようになり、どの方向にパラメータを更新すべきかをモメンタムの式に織り込んだもの。
- Adagrad(Adaptive gradient algorithm)
- モメンタムは学習率の値自体は一定で、モメンタム項を更新することでパラメタ更新していったが、Adagradでは学習率の値そのものをパラメータとして更新していく。
- 勾配の2乗累積和のルートを取ったもので、学習率を割る。
- 累積和であるため単調増加して行き、学習率はどんどん小さくなる。
- ただし累積の変化については、勾配が大きい時は小さく、勾配が小さくなると大きくなる。
- 累積和であるため単調増加して行き、学習率はどんどん小さくなる。
- モメンタムと比べてハイパーパラメータが少なく、これまでの勾配に基づき自動で学習率ηを修正するのでより扱いやすい手法。
- Adadelta
- Adagradは勾配の累積和で学習率を割るため、学習のステップが進むと学習率が極端に小さくなって、学習が進まない場合がある。
- そのため、ステップ0からの全ての2乗和を累積させるのではなく、定数w分だけ(wステップ分の和)に制限する。
- ただし、定数w分の更新量を全部保持しておいてその都度、計算をするのはメモリを食うので、ステップ数を遡るほどその勾配の寄与を減衰させるような減衰平均の式を用いて計算を行っている。減衰を調整するパラメータはρでこれでどのくらい減衰させるかを調整する。
- 一般的にρ=0.95を用いる。
- RMSprop
- Adadeltaと同じような制約を求めるが、Adadeltaの簡易版。
- Adam(Adaptive moment estimation)
- Adadeltaの減衰平均に加えて、単純な勾配の移動平均の項も加えたもの。
- Adadeltaでやっているのが、勾配の2次モーメント(分散)による調整だが、Adamでは1次モーメント(平均)も加えて調整している。
- Adadeltaの減衰平均に加えて、単純な勾配の移動平均の項も加えたもの。
- モメンタム
- オーバーフィッティングへの対処
- Early Stopping
- 学習率ではなく学習回数(イテレーション回数=Epoch数)に対する調整。
- 処理は単純で前のEpochに比べて、誤差が増大していたらそこで学習を打ち切るだけ。
- Early Stopping
- Batch Normalization
- ミニバッチ毎にデータセットを正規化(白色化)し、重みの初期値を調整して学習をうまく行きやすくする。
- 局所最適化への対処
- かつては、隠れ層を増やしたニューラルネットワークは使われていなかった。下記のような課題があったため。
5章 リカレントニューラルネットワーク(RNN)
- RNN
- RNNは系列データを扱うときに使われる。(音声、文字列など)
- RNNは時刻tにおけるニューラルネットの隠れ層に対して、時刻t-1の隠れ層の入力を追加しただけ。
- この時刻t-1の隠れ層の影響が逐次的に累積していくので系列データを扱うことができる。
- 損失関数は時刻t=0〜Tの全ての出力と正解値との二乗誤差(O-C)2の和で、これを最小にする。
- 誤差逆伝播時の注意
- 時刻t=t1のときの出力値から誤差逆伝播するときには、隠れ層がt=0〜t1まで連なっているので、時刻を遡って逆伝搬する必要がある。
- 全ての時間を遡る必要はなく、τ分遡ってそれを入力とするようなモデルで学習する。
- Τを大きくして長期間遡ろうとすると勾配消失が発生する可能性が高くなる。
- LSTM(long short-term memory)
- RNNで活性化関数をシグモイド関数などにすると、長期間過去に遡ったときに勾配が消失してしまい、過去のデータによる重みを学習できなくなってしまう。
- 上記を防ぐために、いくつかの手法がありそれを取り入れたのがLSTM。
- CEC(constant error carousel)
- 過去の隠れ層の活性化関数をLiner(線形関数)にしたのと基本的には同じと理解。
- 過去の隠れ層の情報をそのまま保持しておく回路を隠れ層に付け加えたもの。
- これによって勾配消失は生じなくなるが、微分値が1で一定なので過去の隠れ層の重みが全て同じになってしまう。
- 過去の隠れ層の活性化関数をLiner(線形関数)にしたのと基本的には同じと理解。
- 入力ゲート・出力ゲート
- 例えば周期性のある時系列データなどはその周期Tに該当する周期だけ遡ったデータの重みが大きくなって活性化されるべきだが、過去の隠れ層の重みが全て同じになってしまうと逆周期のデータも同じ主みで活性してしまうので、重みが打ち消しあってしまう。(入力重み衝突)
- その活性化したニューロンからの出力に関しても同じ。(出力重み衝突)
- 過去の隠れ層の重みが同じになってしまう問題を解決するために、必要になったときだけ逆伝搬するような回路を設けたもの。
- 例えば周期性のある時系列データなどはその周期Tに該当する周期だけ遡ったデータの重みが大きくなって活性化されるべきだが、過去の隠れ層の重みが全て同じになってしまうと逆周期のデータも同じ主みで活性してしまうので、重みが打ち消しあってしまう。(入力重み衝突)
- 忘却ゲート
- 覗き穴結合
- 長期時間依存性を学習できているかを評価するためのtoy problem → Adding Probrem
- 入力x(t)に対してs(t) シグナル、m(t) マスクの二つが出力される。
- s(t)は0〜1の一様乱数に従う値。
- m(t)は0か1をとるが全区間でランダムで選ばれた2点のみが1でそれ以外は0を取る。
- これをRNNで学習すると、誤差関数は全く収束しないが、LSTMだとあるタイミングで誤差関数が一気に収束する。
- 入力x(t)に対してs(t) シグナル、m(t) マスクの二つが出力される。
- RNNで活性化関数をシグモイド関数などにすると、長期間過去に遡ったときに勾配が消失してしまい、過去のデータによる重みを学習できなくなってしまう。
- GRU(gated recurrent unit)
- LSTMは推定パラメータが多いため計算に時間がかかる。パラメータを減らしてもLSTMと同等の性能を得ようとしたモデルがGRU。
- 多分ポイントは、CECのように過去の隠れ層を保持しない点と思われる。
- これによってパラメータを削減している。
- リセットゲートによって、そのtにおいて時刻t-1のデータをどのくらい考慮するのかの重みが調整されるため、これがLSTMで言うところの忘却ゲートのようなものとなっていると思われる。リセットされるとそれまでの過去データからの重みは考慮されなくなる。
- 更新ゲートで時刻t-1のデータをどのくらい考慮するかの重みづけがなされるので、これで更新されていることでそれまでの過去データの重みが積み重なって更新されていく。リセットゲートの重みが高くなるまでは過去の重みによる影響がリカレントに更新されていくと考えられる。
- 多分ポイントは、CECのように過去の隠れ層を保持しない点と思われる。
- LSTMは推定パラメータが多いため計算に時間がかかる。パラメータを減らしてもLSTMと同等の性能を得ようとしたモデルがGRU。
6章 RNNの応用
- Bidirectional RNN (BiRNN)
- 未来を未知として、過去のデータで学習して未来を予測するように過去の隠れそうだけを使うのが通常のRNN。
- ただし、過去も未来も両方のデータがある場合に、その時の現在を予測するのに過去・未来両方の隠れそうが使われるのがBiRNN。
- MNISTの画像を時系列データと見立てて、BiRNNに入れるとよく予測できている。(本来系列データではないので、アプローチの一つとしての参考。普通はCNNを使うのが一般的)
- RNN Encoder-Decoder
- Sin波などの時系列データはt+1の繰り返しでありM、厳密にはシーケンス(系列)ではない。
- 文章など単語データの組み合わせで一連の意味をなすものがシーケンスであり、英語→仏語の翻訳などは入力も出力もシーケンスであるため、これらを扱うようなモデルがsequence-to-sequence modelとなる。
- RNNを利用した sequence-to-sequence model が RNN Encoder-Decoder。
- RNN Encoder-Decoder は エンコーダとデコーダという2つのRNNを組み合わせたモデル。エンコーダが入力を処理し、デコーダが出力を処理する。
- エンコーダは出力がない普通のRNN。
- 隠れ層には単純な活性化関数を使うのでも良いが、LSTMやGRUのような回路を含んだ関数であるのが一般的。
- デコーダは自身の出力を次のステップの入力として受け取っている。
- ここで出力の活性化関数は確率を出力するので、ソフトマックス関数となる。
- 簡単なQ&A → 足し算をエンコーダ・デコーダで解く
- 文字列を扱う時は全て数値化する必要がある。
- one-hotエンコーディング(one hot化)によって、文字列を数値化(1-of-Kベクトル化)する。
- パディング(空白文字も含めて)数値化する。
- 文字列を扱う時は全て数値化する必要がある。
- Attention
- Memory Networks
- LSTMやGRUの問題点として、セルの内部に時系列の情報を保持するため非常に長期の情報を学習するには時間がかかる点や1つのベクトルの中にその情報が集約されるため、情報が適切に記憶できないという問題があった。
- この過去の時間情報を外部記憶に切り出して保存しようとしたものがMemory Network。Memory Networkにはフィードフォーワードの単純なニューラルネットワークを用いる。
- Q&A問題への適用例から理解する。
- 学習データはbAbiタスクデータ(Facebook AI Researchが公開しているQ&Aを中心としたテキスト形式のデータ)
- 最初にストーリーが読み上げられて、それに対するQとAが掲載されている。
- ストーリーをもとに外部記憶を構築して、質問文とその外部記憶を照らし合わせて出力を行うというモデルとする。
- 入力用と出力用の二つの記憶を用意する。
- Word Embeddingによる記憶。
- 単純にone-hotエンコーディングされた単語ベクトルでは、それぞれの単語間に相関がないことになるが意味を考慮して各成分が0, 1以外の浮動小数点数を与えるようなベクトルにする。
- word2vecはWord Embeddingを応用した、単語のベクトルか手法。
- 最も単純なWord Embeddingはonhotエンコーディングされたベクトルに対する重み行列を掛け合わせることであるので、ニューラルネットワークの層で表現できる。このニューラルネットに学習させることで、どのように重み付けしてストーリーを記憶すれば良いかがわかる。
- 学習データはbAbiタスクデータ(Facebook AI Researchが公開しているQ&Aを中心としたテキスト形式のデータ)
約10年勤めた大手SIerを退職しました
いわゆる退職エントリというやつです
この2020年1月31日をもって、約10年勤めた大手SIerを退職(転職)することとなったので、自分考えを整理するために書いてみようと思い立ちました。
自分のバックグランド等
簡単に自分のバックグラウンドとどんな業務に関わってきたかを書きます。
- 博士(理学)
- 物理学系(実験系)
- 新卒で大手SIerへ就職
なぜ会社を辞めようと思ったのか?
会社を辞めようと思った理由はいっぱいありますが、いくつか大きな点を挙げると下記のような理由です。
- 中間管理職(いわゆる課長・部長あたり)のキャリアに魅力が無い
- 優秀な若手がどんどん辞めていくがそれに対する対策をしない
- 経営層の経営判断が遅く物事が進まない
- 自分ができる範囲のボトムアップ活動があまり良い結果にならなかった
- 社外を見ると今の組織の停滞具合がより顕著に実感された
中間管理職のキャリアに魅力がない
中間管理職のキャリアに魅力が無いのは、ジャパニーズトラディショナルカンパニーではもう常識的なことではありますが、以下のような状況でした。
- 雑務に追われて、技術もマネジメントも中途半端
- 課長職は毎月300時間くらい仕事に費やし、昼も夜も無いような生活だけどは一般社員より給与が低い
中間管理職の雑務は稟議や勤怠等の承認処理、金勘定、下請け会会社の人員受け入れ、備品管理、コンプライアンス対策、監査対応、上役への社内報告等々多岐にわたっていて、定時内は雑務を片付けてその後に本業をするというような状態でした。
課長・部長はマネジメント層なのでマネジメント業務がその職務だと思いますが、本業に直結するようなマネジメントに本気で取り組んでいるように見えた人は自分が観測できる範囲では残念ながら一人も居ませんでした。雑務が多すぎるのでそれも仕方がないのかもしれません。
ここで自分の状況を話すと、自分はちょうど一般社員としての一番上のランクに昇級したところでその後は中間管理職になるかどうかのキャリアを選択するというようなフェーズにいました。会社が用意しているキャリアパスとしては、「一般社員で居続ける(基本的に給与は変わらない)」か「管理職になってさらに上を目指す」の2択でした。そのため会社が用意している唯一のキャリアアップの道である中間管理職のあり方は、自分の今後を考える上で大きな課題でしたが、明らかにそのキャリアには魅力がありませんでした。
優秀な若手がどんどん辞めていくがそれに対する対策をしない
これも悲しいことだったのですが、優秀だなと思う若手はすぐに辞めていきました。5年離職率が大体2〜3割くらいであったように思います。まあ昨今の転職市場の盛り上がりからして仕方がないことだったとは思うのですが、その状況をまさに経営層と中間管理職が「仕方がない」という理由だけで片付けてしまっていたのが非常に残念でした。
いや、実際には経営層に近い人はこの状況に危機感をもっていたと思います。少なくとも危機感をもっていると発言はしていました。ただし、発言をするだけで実際に行った行動はほとんど普段顔をあわせることのない新人と経営層が面談をするみたいなことだけでした。危機感をもっているという発言をしていても、本当にその危機感に見合うだけの行動をしている人が管理職の中にいなかったことが残念でなりませんでした。
若手が辞めていく理由は、会社に残った別の若手から間接的に聞いたものばかりなので本当のところは分りませんが、概ね下記の2つが有力なものだったようです。
- やっている業務量に対して年収が見合わない
- 下請け業者のコントロールだけで技術が身につかず今後のキャリアに不安がある
1.を理由とする若手は大体外資系コンサルに転職していき、2.を理由とする人はWeb系のスタートアップとかに転職していきました。現状の業務は面白い点もあるのだけど将来を考えると泣く泣く転職するという人もいたので、この二つの理由を真摯に受け止めて本気で対策を打とうと思えば、「危機感持ってるよ感を出す」だけのおざなりな面談とかよりももっと実効性のある対策を考えることはできたと思います。
また、転職によるキャリアアップはもう時代の流れと受け止めるならば、それを前提として新たな人材をどう獲得するのか、事業部としての裁量でやれることをもっと真剣に考えることもできたと思います。ただし、残念ながらそうした動きが生まれることはありませんでした。
経営層の経営判断が遅く物事が進まない
若手が辞める例だけではないですが、IT業界を取り巻く色々な変化に経営層は一応なりとも危機感を見せていました。一部のトップマネジメント層では、大きく社内を改革しようとするような行動も見えてはいました。ただし、それは一部の変化にとどまり、複数の事業部が個々の利権と社内政治で複雑に絡み合う会社の中ではトップマネジメントの試みがそのまま適用されるわけではなく、自身が所属している事業部には少なくとも自身が観測できる範囲では何の変化もありませんでした。
そういう状況の中で自分自身は何をやっていたのかというと、受託だけでなく自社サービス開発をやってみようといった提案や、あるいはスタートアップ的なコミュニティ活動を事業部の中でやってみようという提案等をやってみました。そしてことごとく上手くいきませんでした。
色々な提案をしていて一番思ったのは、経営判断がものすごく遅いという点です。まあ、これもジャパニーズトラディショナルカンパニーでは分り切ったことなのかもしれませんが、まず経営層(といってもその中にも何階層も階層があってその中の一番下の階層)に対して話をもって行こうとすると、月に一回くらいの頻度でやる提案会議(必ず開催されるとは限らない)に話を持っていかなければなりませんでした。
その会議に話を持っていくためには、その会議に持っていく話を厳選するための別の会議体みたいなものがあって、その別の会議体の中で決められたフォーマットに従った情報を埋めて、そのアイデアが一定レベルのもの(と中間管理職の担当が思ったもの)だけが、その経営層の会議にかけられるみたいな手順を踏むというやり方でした。しかもフォーマットがあらかじめ決められているにも関わらず、そのフォーマットだとよく分からないという理由でなぜか追加資料を作らされるという意味の分からないところもありました。
そして、その経営判断を行う会議に持っていっても結局決めるのは次年度の予算とかになるので、その年の12月くらいまでに経営層の承認を得られないと次年度の計画として取り込まれないというような時間感覚でした。別な会議体でフォーマットに従った資料をブラッシュアップして、さらにフィードバックを受けて別資料を作って、というプロセスが必ず発生するので、提案した内容が実際の計画に落とされるのは最短でも1年後くらいの時間になります。
自社サービス開発とかを本気で考えた場合、上記のような経営判断のスピード感では遅すぎます。さらに受託の開発業務をやりながらその空き時間で上記のような提案を続けるモチベーションを保ち続けるのはかなりきつく、実際そうした理由もあって提案を撤回したことがありました。
自分ができる範囲のボトムアップの努力をしたがあまり良い結果にならなかった
上記の経営層への提案の例でも触れていますが、中間管理職のキャリアに魅力がなくロールモデルとする人が居ないことは新人の頃から分かっていたことではあったので、それを変えるためのボトムアップの活動を色々やってはいたのですが、それがあまり実らなかったという点も退職を決める大きな要因でした。
具体的には、下記のようなことをやっていました。
- 若手から中堅を集めての社内勉強会開催
- 社内限定ブログで自身の考えを忌憚なく発信(経営層のダメ出しもするが、必ず代替案を出す)
- 中間管理職・経営層への提案(業務直結のものから社外コミュニティ活動の提案など)
他にも色々試したいことがあったのですが、上記の活動をやっていこうとしている時に客先への出向することになり活動が途切れてしまったり、出向から戻ってきたら活動の主要メンバーだった人たちが会社を辞めていたりと色々あって、活動自体が中途半端になってしまった点が悔やまれる点でした。
客先出向自体は今振り返ってみればそれはそれで良い経験だったと思うのですが、それによる活動の停滞は自身がこの会社で今後もやっていこうと思うモチベーションを下げる大きな原因でした。社内の改善活動を本格的に実施しようとしている時に上司に客先出向を言いたわされ、社内でやりたいこと押しとどめて出向を受諾したにも関わらず、数年に渡る出向から戻ってみると当時撒いていた改善のタネは刈り取られており、それどころかその当時よりも活動の機運は停滞しているような状態でした。
「転職」という考えが頭に浮かぶことは何度もありましたが、それを実際に行動に移してみようと心に決めたのは、客先出向から戻ってきて社内が全く変化して居なかったところが大きかったです。
社外を見ると今の組織の停滞具合がより顕著に実感された
今まで社内に向けた活動は色々とやっていたのですが、恥ずかしながらエンジニアの社外勉強会などはこれまで全く参加したことがありませんでした。ちょこちょこ参加するようになったのはここ半年くらいになります。そうした場所などで経験した社外の刺激がこの会社を去ろうという考えを後押ししました。
社外勉強会に参加しようと思ったきっかけは、ふとしたことからTech系のポッドキャストを聞くようになって、そこでエンジニアの勉強会の話題が度々登場していたので出てみたいと思ったからでした。
特に影響を受けたポッドキャストは、「しがないラジオ」(SIerのエンジニアからWeb系に転職したんだが楽しくて仕方がないラジオ)でした。
タイトルは色々煽り気味なので敬遠される方もいるかもしれませんが、聞いてみると自分よりも若いパーソナリティの方々(@jumpei_ikegamiさん、@zuckey_17さん)が、しっかりした考えを持って自身のキャリアを考えられていて、大手SIerを辞めたのちに独自のキャリアを築かれているのに新鮮な感動を覚えました。
登場するゲストの方々も独自のキャリアを歩んできた様々な方がいらっしゃって、社内にはいないような考え方を持った人たちが多く、そうした人々の考えを聞くに社内のメンバとのギャップが大きく意識されました。一番違いに思ったのは、自分の周囲をより良くしたいという考えやそのために変化しようとする姿でした。
こうしたポッドキャスト駆動で勉強会に出席するようになっていき、ポットキャストや実際の勉強会で社外の人たちの考えを聞くにつれ、自分が思っている以上に現職の会社の停滞感が強く意識されました。
結局まとめると単純な理由
ここまで書いてきて色々と退職理由をあげていますが、端的にまとめると「社内が嫌になった」+「社外の方がよく見えた」というすごく単純な理由です。この辺は退職エントリの理由としては普遍的な構造なんだと思います。もちろん隣の芝は常に青いので、社外が手放しで楽しい場所だとは考えていません。ただし、自分の周囲をより良くするという点では何らかの変化が必要で、変化を起こすための手段として環境を変えてみるのは有効な手段だと思いました。
それで、会社を辞めて何をするのか?
SIerのSEからデータサイエンティストとして転職をすることになります。業務改善を担うようなコンサルティング業務を主として行なっている会社です。現職の職場で業務改善を試みながらもうまくいかなかったことから、そうした方向性を少し違った視点で追求してみたいという考えと、データ解析を趣味や一部現職の運用業務でも実施していた経験を生かしたいという考えが結びついた結果になります。
実際に業務を初めて見ないとわかりませんが、色々とチャレンジングなことを行なっている組織のようなので、そこで変化を楽しんで行ければと考えています。
政府の情報システム調達の今後についてちょっと調べてみた
政府のシステム調達の一般的な流れ
政府機関のシステム調達はかなりお硬いプロセスに則っています。 基幹系のシステム導入を大きな企業が行う場合と同じなのだけど、以下のような流れです。
その後、契約締結後は仕様変更によって、契約内容が更新されることはあるけれど、基本的にはRFP時の要求とそれに対する提案がベースになって、設計、製造、試験、受け入れとなります。 当然ですが、契約形態は”請負契約”でありシステムの開発はがちがちのウォーターフォール開発になるのが一般的です。
アジャイル開発の導入に向けた政府の取り組み
ただ、昨今のIT業界の情勢を受けて、政府調達にも改革の流れが及んでいるみたいです。 未来投資会合なる会合が平成28年度から開始されていて、そこの構造改革徹底推進会合の中で、IT関連の議論及び政府の調達のあり方に対する議論が行われていました。
構造改革徹底推進会合(H29.9~)第4次産業革命」会合
「第2回 平成30年1月18日 行政からの生産性革命について」の資料によれば、下記のような課題が調達の仕組み上の問題として挙げられています。
○予算・契約上の問題
システム開発経費の変動や各省横断的なシステム開発を各省の予算上吸収しきれない、単年度主義により効率的な開発ができない、予算要求時から開発まで2年弱は要するなど時間を要する、アジャイル開発の調達成果物の設定ルールが明確でない、入札手続き以降は具体的内容を変更調整できない等
これによれば、予算・契約上の問題がアジャイル開発等の導入のネックになっているという問題意識を政府側も意識していたようでした。
デジタル・ガバメント推進標準ガイドライン
上記の議論を継続して行っていった成果なのか、2019年(平成31年)2月25日最終改定のデジタル・ガバメント推進標準ガイドラインには以下のような記述がされていました。
なお、利用者が多岐にわたり、要件定義等の関係者に対して綿密な調整が必要となる等の場合は、開発手法としてアジャイル型を導入することで、利用者の利便性を向上させるよう考慮する。その際、変更管理に基づき、既に作成された設計書や要件定義の内容を見直すことも想定した計画を立案すること。
上記以外にも、アジャイル開発に関する記述が明確に記載されていて、アジャイル開発を政府調達にも導入しようとする動きが見えます。
少し前に話題になっていた、経産省と本気でアジャイル開発をやってみた!制度ナビPJで見えたGovTechのリアルと未来のイベントもこうした流れを受けての企画なのだと思われます。
2019年度の閣議決定
ガイドラインを整備したのち、前述の課題でもあげた予算や調達の課題はどうなったかというと、それらも議論は継続されていて、調達上の対策としては経済財政運営と改革の基本方針 2019 について(令和元年6月 21 日 閣議決定)の中で、下記のような形で盛り込まれていました。
政府情報システムの調達において、機動的かつ効率的、効果的なシステム整備に資するよう、契約締結前に、複数事業者と提案内容について技術的対話を可能とする調達・契約方法を、2020 年度から試行的に開始する。
これらの取組を通じ、運用等経費及び整備経費のうちのシステム改修に係る経費を2025 年度までに 2020 年度比で3割削減することを目指す。
技術的対話を可能とする調達・契約方法とは?
情報システムに係る新たな調達・契約方法に関する試行運用のための骨子によれば、下記のようになるようです。
①は一般競争入札で、価格と技術を総合的に判断し落札者を決定する方式の流れですが、今までと異なるのは、技術提案書と価格から1社の落札業社を決めるのではなくて、技術的対話を通して複数業者を合格として、さらに仕様書確定後にもう一度技術審査をして最終的な業者選定をしている点と思われます。あとは業者決定後に対話プロセスを公表するところでしょうか。
②はいわゆるコンペですが、あまり政府の情報システムの調達で行われているのを見たことはない気がします。②は随意契約(いわゆる随契)が前提で入札ではないようで、こちらも今までとの違いは技術的対話の部分だと思われますが、技術的対話の中で2次審査に合格した複数業者と価格の交渉をどのようにやるのかは疑問が残ります。
この調達方式がアジャイルに向くのか?
①の一般競争(総合評価落札方式)について
まず一般的に一括請負の契約はアジャイル開発には向かないと言われています。
(参考) アジャイル開発に向けたITベンダーとの契約の結び方【第6回】(digital cross)
①の一般競争入札での技術提案では、応札業者が結局、「こんな機能を持ったシステムをこのくらいの期間とこのくらいの金額でできますよ!」って、まだ開発も始まってない段階から提案を出して、金額含めて「よし!」じゃあそちらに決めた!みたいな形で、業者が選ばれます。
結局金額と期間と作る規模が決まっているし、最初の提案価格で審査されるので何としても受注したい場合は業者がどのくらいのリスクを負うのかを判断して、価格を抑えて応札してくることも考えられます。結局この調達方式では”請負契約”になるのが必須なので、”技術的対話期間中”に別契約でも結んで開発を開始でもしない限り、アジャイルな開発を行うことは難しいように思われます。
②の企画競争方式について
②の方がまだ可能性がある気がします。技術的対話の中で、イテレーション(スプリント)毎の開発の議論とスコープ調整がされること、あとは契約形態自体もここで議論ができるのであれば可能性があると思います。
ただし、②の企画競争ってのが何を審査するのかイマイチピンと来ませんでした。結局審査では実態のないプレゼン資料が作られて、上手いプレゼンをやったらOKみたいなイメージなので、開発されるシステムの良し悪しはここでは何も評価できない気がします。
今後の政府調達に期待
ともあれ、アジャイルな開発も見据えた方向に政府の情報システム調達が動き出したというのは、良い傾向ではあるので、ぜひ見せかけだけの取り組みではなくて実際に中身のある施策として本気で取り組んでいってもらいたいなーというのが、1エンジニアとして思うところです。
政府が変われば、大企業もある程度は変わるし、大企業が変われば、世の中のシステム開発ももう少し変わっていくだろうし、普通のSIerのシステム開発でもアジャイルに、本当の価値を生み出すシステムを作れるようになるのであればこんなに嬉しいことはないと思います。