SE 時代（2012～2015年）
いわゆる SE として2次受けで業務アプリを作る会社に入社しました。
リーマンショックの傷跡も癒えない内に東日本大震災がやってきて、景気は悪かった頃です。
エンジニアって本とかネットで知識がオープンになっていて、勉強次第で会社に依存しないキャリアを築けるからいいなと思ったのがきっかけでした。
その頃はプログラマーと SE の区別もついていませんでした。
景気が悪く、「手に職」「未経験からエンジニア」といった文句をよく聞いていたので影響を受けたかもしれません。
入社してからは大手 SIer が作ったパッケージをカスタマイズしながら導入していました。
1年目は Java、JSP、JavaScript、HTML、Visual Basic を触っていました。
2～3年目は、大き目の業務システム刷新プロジェクトにアサインされて C# を主体に触っていました。
最近嫌われがちなウォーターフォールの上から下までを一通り見れたと思います。
設計書を書いたり、仕様調整をしたり、ミドルウェアを触ったり、プログラマーに仕事を依頼したり、1年目と比較してプログラムを書く機会は断然減りました。
この時点で自分はプログラマーではないんだなと思うようになっていました。これが SE（何でも屋）かと。
ミドルウェアは JP1 と iDIVO を触っていました。今風に言えば RPA になるでしょうか。
iDIVO では、全国の関連組織から送られてくる色んな形式（全銀長等）、色んな文字コードの受発注データを同じデータベースに流し込んだり、逆に出荷データを送信したりしていました。
こういう製品って、GUI を操作すれば簡単に構築・運用できると思って導入されることが多いと思いますが、実際はイレギュラーなデータを捌くためにトリッキーな使い方をしなければならず、結局、カスタムフィールドにスクリプト言語っぽい（お客さんは COBOL っぽいねと言っていました）ものを書いていました。
運用を楽にしようと1社で頑張っても、他社システムとのつなぎ（システム連携部分）の部分で複雑性が減らなければ、運用も楽にはならないと学びました。
現場に iDIVO を触れる人がいなかったので、仕様調整は3年目の私がやっていて、運用手順書を書いて引き継ぎもしていました。
なんだかんだありましたが、私も私の実家も利用するサービスだったので、仕事と生活世界がつながった初めての経験でした。
生活世界とつながった話で思い出すのは、2014年に起こったベネッセの個人情報漏洩事件です。
ベネッセ個人情報漏洩事件のすべて｜企業は加害者？それとも被害者？
同じ会社の同期が現場にいて、実家にも500円の図書カードが送られてきたのを覚えています。
この事件の前からですが、情報漏洩を恐れて常駐してほしいクライアントと自社に持ち帰りたいベンダーの攻防がずっとあります。
ベンダーにとっては常駐させると会社への帰属意識が薄れて転職されてしまうので、結構死活問題だったりします。
持ち帰った方が人的リソースを柔軟に入れ替えられて、教育にとってはよかったりします。
iDIVO の現場では、常駐でしたが、文字コード変換等を検証しないといけなかったので、個人情報をそのまま使ってテストしていました。
テスト期間が延びる度に個人情報開示の延長申請を1次受けの部長さんにして、お客さんにハンコをもらっていました。
悪意さえあれば漏洩させることもできたので、他人事とは思えませんでした。
ミドルウェアを隅々まで触って速やかに習得して人に説明する能力は示せたように思いますが、iDIVO にはもう2度と触る機会はないだろうなと思ったときに、この働き方でいいのかなと転職を考えるようになりました。
BtoC の WEB サービス会社でプログラマーをやるか、調整能力に振り切ってコンサルになるかで悩み、まだ何をやっても学びの多い若者だった私は、最終的に友人から誘いのあったコンサルになる道を選びました。
SIer からの転職先として「ネット専業かコンサルか」はよくあるパスなのではないでしょうか。
少しですが、転職前に Salesforce の案件をやりました。言わずと知れた SaaS of SaaS です。
今も勢い衰えずですが、2015年当時もすごくて、SE の4年目で下請けだと単価は月50～60万円くらいだったと思いますが、同じ人が Salesforce をやれば100万円になりました。
型が決まっていて確かに作るのは早いのですが、処理件数に制約があったり、いつの間にか仕様変更があったりで、扱いは結構難しいです。
最近も事件がありましたが、Salesforce にはほとんど負の影響がないのが切ないところです。
Salesforce利用企業、アクセス権限設定ミスで相次ぐ情報流出
お金の話をすればキリがないですが、同期で新日鐵住金の SE になった知り合いの知り合いが月300万円と言っていました。
iDIVO の現場のベテランインフラエンジニア（おそらくフリーランス）でも月300万円でお金持ちだったので、何に担がれるかは大事なんだなと思ったのを覚えています。
「単価＝その人の価値」と思わないで生きるのが心には優しいと思います。
フリーランスと言えば、iDIVO の現場にいた方が40歳くらいで半導体メーカー工場の管理職を辞めて SE になった方で、ほぼ経験年数は変わらない方でした。
半導体業界は Japan as No.1 の象徴ですが、もう限界に来ていたのでしょうか。
SI は懐の深い業界だなと思いましたが、年齢が行ってからの未経験 SE だったので、かなりブラックな現場を経験されたそうです。
日本屈指の炎上案件の卒業生でした。なぜか iDIVO の現場には卒業生が何人もいました。
2012年の特許庁システム開発中止、開発費全額返納のなぜ
キャリアは慎重に選ぼうと思いました。
コンサル時代（2015～2016年）
社会人4年目に外資系コンサル会社に転職しました。コンサルと言っても内部の職階ではコンサルの下のアナリストでした。
高級 SE 的な立ち位置で、官公庁の業務システム更改（官公庁用語でシステム刷新の意味）プロジェクトにPMOとして参画しました。
現場には郵政民営化（2007年～）のときの更改案件の卒業生がいました。先述した特許庁案件の卒業生もいて、狭い世界だなと思いました。
客先常駐でしたが、同じ部屋ではマイナンバーを使った最初の案件もやっていました。
プロジェクト管理のガイドラインを改定してクライアントに説明したり、調達仕様書と提案書を根拠にベンダーの成果物をレビューしたりしていました。
ほとんどの時間、議事録を書いていたと思います。
自社に限らず、コンサルが SIer 化して人員規模が急拡大している時期でした。
最近になって高級派遣と言われるようになった現象と重なっていると思います。
人月商売は単価が高止まりすれば人数を増やして成長を見せる必要があるのだと思います。
と言うと悪く言っているように聞こえますが、そんなことはなく、グローバルに構築された教育システムと過去案件資料のライブラリには小さい会社は叶わないと思いました。
特に教育システムについて、教材の多さとレビューにかける時間の多さは企業体力の成せる技だと思いました。
レッドオーシャンで選ばれる企業になるためには、これほどまでにガチガチの仕組みの中でストイックにやり続けないといけないのかと思いました。
丁度、電通が槍玉に挙げられた頃でした。人員拡大と同時に、働き方改革や女性が活躍できる職場作りも始まりました。
でも実際は、人員拡大による品質低下が進んでいて、昔からいる人の中では、古いコンサルを維持するための新しい職種を作ろうという動きもあり、そういう人達はまだ激務をよいことだとしていました。
私も「古いコンサル」に誘われて、「こっちに来ないと出世できません」と言われました。
健全な生活の方がお金より価値があると思ったので、在籍期間は短かったですが転職を決意しました。
やはり技術から遠ざかりたくないという思いもありました。
長くはいませんでしたが、コンサル時代に言われたことは今も生きています。
日本語の指導をかなりされて、そのとき100%直すことはできていませんでしたが、次の会社に行ってからも意識し続けるだろうし、1人でも改善しようと思って出て行きました。
本庁の会議に出席した先輩が、数日後に議事録を書かないといけないと知り、記憶を頼りに議事録を書き上げていて驚愕しましたが、今では同じことができると思います。
運用エンジニア時代（2016～2018年）
AI バブルの初期の頃だったと思いますが、リーマンショック後に大量解雇になった金融業界のエンジニアがオークション等で培われた技術をマーケティング業界に持ち込んだ後で、日本でもマーケティングツールのベンチャーが沢山ありました。
3社目は、そういうベンチャーの内の1つでした。
マーケティング業界も経験してみたかったですし、マーケティング業界なのでデータ分析もしていて、AI バブルが始まった頃だったこともあり、惹かれるところがありました。
最初はずっと AWS を使った自社製品の運用エンジニアでした。
ログを集めてDWHに蓄積し、レコメンドエンジンでパーソナライズしたおススメ商品を何百万人にメルマガで送っていました。
開発部隊はすでに次の主力製品に振り向けていて撤退戦が始まっている頃で、運用費は稼いでいましたが人数は減り、大変な時期でした。
AWS は S3、EC2（Ubuntu）、RedShift を主に触りました。AWS 以外も Treasuredata、GCP BigQuery を触りました。BI では Tableau も扱いました。コスト管理を含め、クラウドの扱いには慣れたと思います。
クラウドでよくある障害には大体当たりました。障害が起こったときは、その後の対応次第で顧客から逆に信頼されることもあると学びました。
データサイエンティスト時代（2018～2019年）
元々データ分析会社だったこともあり、会社が AI やデータサイエンティストを押し出し始めて、私もデータエンジニアを経てデータサイエンティストと呼ばれるようになりました。
データサイエンティストは、一昔前までは物理学や数学の修士や博士の方がなるイメージでしたが、今は民主化されて、様々なバックグラウンドの方がいます。
実際、データ分析のプロジェクトには、営業やコンサルに始まり、プロジェクトマネージャー、分析基盤を構築したりデータの前処理をするエンジニア、機械学習やディープラーニングを駆使するアナリスト等、多くのプレイヤーがいて、広義のデータサイエンティストにはこのエンジニアとアナリストが含まれます。
私はエンジニアをやりつつ、古典的な手法でマーケティングに特化したデータ分析もやっていました。
モニターの POS データや EC サイトの行動ログを元に、休眠顧客や優良顧客等、5つくらいのグループに分けて、それぞれのグループの行動を比較しつつ、どうしたら最終的に優良顧客を増やせるかを考える、そんな集計に近い分析です。
データサイエンスっぽい手法でいうと、社内の有識者に聞きつつ GBDT も少し使いました。
マーケティング分野のデータ分析について一般論を言うと、分析結果を施策に結び付ける部分が一番難しいです。
実店舗が絡む施策だと実施コストが高く気軽にできません。なので結局、クーポンメールを送るしかないのですが、効果を高めるためにターゲットを絞り過ぎると統計的に有意なサンプルが得られないですし、逆にターゲットを広くすると全配信とさほど変わらなくなってしまいます。
結局、消費者に対する効果的な施策はできず、毎週新しい Tableau を1年間作り続けるプロジェクトもありました。
その Tableau は toC の営業や経営判断に活用されたのですが、具体的にどう活用されているのか不可視な面もありました。
もちろん尖ったサイエンティストが大量に集まることでしかできないこともあるので、支援会社にも意義はありますが、それほど高度ではないデータ分析をやるなら事業会社でやった方が面白いだろうなと思いました。
一番、施策まで含めてうまく行ったプロジェクトでは、AWS Lambda と Google タグマネージャーを使って、パーソナライズしたおススメ商品を EC サイトの色んなページに表示して、Google オプティマイズでベイズ推定しました。
これならコストも低いですし、効果もリアルタイムにわかります。
最近は GDPR 等もあって、世界的にクッキーに対する規制が進んでいて、マーケティングもサードパーティのデータに頼らず、いかに自社 EC サイトや SNS 等でファーストパーティのデータを集められるかという方向に進んでいるようです。
品質管理部時代（2019年～）
年間100人を超える規模で会社が成長する中にあって、プロジェクトの進め方を標準化しようという主旨で品質管理部が立ち上がりました。
ミッションは「品質の底上げ」なので、全社的なことやイレギュラーなことは何でもやります。
私が参画するまでは、プロジェクトガイドラインを作ったり、新しいタスク管理ツールを導入したりしていました。
常時、専任が2名（マネージャー＋私）の体制で、私が参画してからはガイドラインの拡張や SharePoint でのプロジェクト資料の整理をしていました。
QA エンジニアとも違いますし、今でもしっくり来る職種名がないです。
ミッションはありますが、具体的に指示が来ることはほぼなく、社歴が長いせいか、色んな社内の声は聞こえてくるのでそれらを拾って、優先順位だけマネージャーと相談しつつ対応しています。
SharePoint サイトで社内ポータルやコロナ対策サイトを作ったり、SharePoint リストで作った社内掲示板を Power Automate で Slack と連係させたり、リモートワーク下のセキュリティ対策を進めたり、Azure や AWS の利用ルールを決めたり、GitHub 等のツールのマニュアルを作ったり、Azure の分析環境をすぐ立ち上げられる仕組みを Terraform で構築したり、社内勉強会の動画を整理したり。
何をやるにしても、マネージャー陣にレビューしてもらって、協力企業の方も含めた全スタッフに説明するところまでで1セットなので、社内の全員がクライアントみたいな状況です。
最近はクラウドのセキュリティ対策強化、分析モデルのシステム実装支援、知財管理の強化（他社の権利を侵害しない＆自社の権利を守る）等の課題に取り組んでいます。
こういうニュースがあると仕事が増えます。
Anaconda パッケージリポジトリが「大規模な」商用利用では有償になっていた
GitHubは悪者か？ SMBCのソースコード流出から学ぶ、情報漏えいのリスク
結局何をやっているのか
この9年間、ずっと広義のエンジニアのつもりで今でもそうですが、エンジニアにしては色々やり過ぎている感もあります。
ただ、前例のないことを淡々と進める能力は身に付いたように思います。
とは言え私自身は何でもできるわけではなく、社内の有識者に教えを乞うてそれを見える形にして広める作業を延々やっています。
名付けるなら「コラボレーションエンジニア」になるのかなと考えたりします。
データサイエンティストみたいなエッジの立ったスペシャリストの中でやれているなら、どんなスペシャリストの中でもやれるんじゃないかと展望しつつ。
以上