目次
はじめに
1.参画当初に直面した課題
2.キャッチアップと試行錯誤
3.全体像が見えたことで変わった自分の視点
4.把握した現場全体像と改善案
5.技術的な学び
6.非技術的な学び
7.今後の課題
8.「期待を超える」ことの難しさと面白さ
おまけ：参画前のもがき
はじめに
「来週からMLOps案件に入ってください。単価は90万円です。一人で全部やってもらいます」
AIエンジニアを目指して転職活動を行った結果、ようやく決まった案件でした。
しかも、以前から携わりたいと考えていた機械学習関連の業務です。
一方で、この話を聞いたときに真っ先に頭に浮かんだのは、喜びよりも現実的な不安でした。
単価90万円ということは、即戦力として相応の成果と再現性が求められるということです。
未経験である自分が、その期待に応えられるのか。
正直なところ、「単価下げるか先輩社員も入れてくれ...」と内心ビビっていました。
それでも、現場で求められていることを一つずつ理解し、自分なりに課題を整理しながら取り組んできた結果、現在は「期待を超えられる可能性が見えてきた」と感じています。
本記事では、1年の振り返りとして、このMLOps案件で学んだことや、直面した課題、それに対してどのように考え、行動してきたか、
そして今後どのような価値提供を目指していくかを整理します。
1.参画当初に直面した課題
案件に参画した直後の最も大きな課題は、「なにもかも分からないのに、それをどう解決していいかわからない状態」にあったことでした。
わからないことの具体例は下記のようなものがありました。
- このプロジェクトが何を目的としているのか
- MLOpsとしてどこまで自分が担当するのか
- 自分に対して何が期待されているのか
- プロジェクト全体がどのように進行しているのか
- 誰に、何を、どこまで聞いてよいのか
特に「誰に、何を、どこまで聞いてよいのか」が一番ストレスでした。
本プロジェクトは、エンドクライアント、その業務を受託する子会社、そこにパートナーとして参画する私、という構造になっています。
私は業務を受託している子会社の一員として扱われる以上、エンドクライアントに聞くのが一番早い内容だったとしても、安易に「分からないので教えてください」と聞くことで、評価や信頼に影響が出る可能性を考慮する必要がありました。
また、プロジェクト全体では複数名が所属企業から参画していましたが、私が担当する領域については実質的に単独対応となっていました。
これは同じ会社先輩がいない、という意味ではなく、その担当領域に入っている人間の総数が私一人であり、設計・実装・運用の実質的な責任が私にあるという状況でした。
以上の状況から、責任者である私が分からないと言ってよい内容なのか、自分で調べるべき内容なのかの線引きが難しく、また答えを持っている方が誰なのかが分からないためそもそも誰に聞けばいいのか判断が難しかったと感じています。
これらの課題は、私が懸念していた技術力云々以前に「前提である状況を正しく把握できていないこと」から生じていました。
まず全体像を把握し、属人的な情報を集めながら、自分の役割と期待値を明確にすることが最優先の課題だったと振り返っています。
2.キャッチアップと試行錯誤
上記のような課題を解決するために、どのように業務が回っているかへの理解を最優先にしながら、自分ができる最大限の価値提供を行えるよう、下記のような取り組みを行いました。
2.1. 朝会を通じた進め方の把握
当時、私が定常的に接点を持てていたのはPMと他プロジェクトメンバーとの朝会のみでした。
PMは複数プロジェクトを取りまとめる役を担っており、その複数プロジェクトのうち性質が近いもののメンバーを集め、毎朝30分の進捗報告と相談をする時間が朝会です。
何を分からなかった私は、PMと他メンバーの朝会でのやり取りを注意深く観察し、
- タスクがどの粒度で切られているのか
- 進捗報告で何が求められているのか
- どの程度まで自分の判断で進めてよいのか
といった点を把握していきました。
特に、単にタスク完了の報告をするよりも、「具体的に何をして完了させたのか」「次に着手するタスクを自主的に作る、もしくは選ぶ」という動きをしたほうがプロジェクトとして前に進みやすい、という点は、朝会を通じて学んで、今でも役に立っていることの一つです。
2.2. Slackのやり取りから見えた「踏み込んでよいライン」
また、Slack上での他めんだー同士のやり取りを読むことで、現場におけるコミュニケーションの雰囲気をつかんでいきました。
当初は「どこまで聞いてよいのか」が分からず、質問を控えがちでしたが、実際はあいまいなままタスクを進めたり、調査に時間をかけすぎるよりも、分からない点を早めに相談したほうが喜ばれる現場であることに気づきました。
一方で、エンドクライアントは完ぺきな仕事を好んでおり、曖昧さや調査不足に厳しいということもわかりました。
1度、PMとコミュニケーションをとる感覚で質問した際に厳しい返答をいただいてしまったこともあり、
- 分からない点は背景や仮説を添えてクローズドクエスチョンで相談すること
- 深堀をされた際に素早くこたえられるよう、事前に整理して説明できる状況を作ること
の重要性を強く意識するようになりました。
2.3. 担当領域の理解を深めるための取り組み
自分が担当する領域について、PMは全体像を把握しているものの、細部まですべてを把握しているわけではありませんでした。
そのため、担当領域についてはプロジェクト内で誰よりも詳しくなり、自分が責任をもって判断できる状況を作る必要があると考えました。
具体的には、
- ソースコードを読み解き、処理の流れを把握する
- 仕様が明文化されていない部分は仮説を立てながら理解し、不明点を言語化し理解できるまで深ぼる
- コードからは追えない環境や運用面については、朝会などで話題に出たタイミングで質問をする
といった形で、信頼を損ねないように、かつ分からないまま放置しないように、少しずつ理解を積み上げていきました。
2.4. プラスアルファの視点を載せる意識
タスクの進め方として、単に依頼された作業をこなすだけでなく、必ず自分なりの意見や改善策を添えて提案することも意識しました。
具体的には、
- 新規のモデル評価指標を取り入れ、過学習を検知できるように提案
- 処理速度を向上させるためリファクタリングを提案
- コスト削減のため既存処理のフロー変更を提案
なお、コスト削減の一環として提案した内容については、最終的には大きな成功には至りませんでしたが、検討過程や判断理由も含めて自身の学びにつながりました。
詳細は以下の記事にまとめています。
https://zenn.dev/zenn_mita/articles/da8d84d0369869
このような姿勢を意識するようになった背景は、SESという働き方に対する課題意識があります。
SESの現場では、「依頼された作業を遂行すること」が中心になりやすく、受け身のままプロジェクトに関わってしまうケースも少なくありません。
その結果、技術的な理解が部分的になり、成長が早期に頭打ちになってしまうこともあると感じています。
また、「なぜその判断をしたのか」という説明責任が求められるテックリードのような立場に移行する際、主体的に考えてきた経験が不足していると成功しにくくなるリスクがあると考えています。
近年の市場環境を踏まえると、単に作業をこなすだけの役割は今後さらに価値が相対的に下がる可能性があり、自分自身の市場価値を高めるためにも、プロジェクト全体の成功に貢献する姿勢が重要だと考えています。
そのため、自分が関わるプロジェクトでは、作業の完了を目的とするのではなく、プロジェクトを成功させること、ひいては自分が向き合っている顧客の利益最大化に貢献することを常に意識して取り組んでいます。
未経験である以上、最初から「期待を超える」ことは難しいですが、「期待を超えようと考え続けること」自体が、顧客への提供価値と自身の成長を最大化し、結果として期待を超えるための土台になると考えています。
3.全体像が見えたことで変わった自分の視点
上記のような試行錯誤を重ねるうえで、徐々にプロジェクト全体の構造や処理の流れが見えるようになってきました。
参画当初は、自分の知識不足や経験不足といった「自分自身の課題」に意識が向いていましたが、コードや運用の理解が深まるにつれて、「現場の課題」に意識が向けられるようになったと感じます。
具体的には、「自分がタスク完了できそうか」ではなく、「このプロジェクトは安全に、正しく、継続的に運用できる状態か」という観点で見るようになりました。
結果として、設計や運用の前提とずれがないか、長期運用を前提としたときにリスクになり得る点はないか、といった点に自然と目が向くようになっています。
これらは誰かから求められたものではありませんが、期待に応えるだけでなく、「期待を超える」ために何が必要か、を考え続けた結果だと考えています。
こうした視点の変化によって、自分の役割も、単なる作業者から、プロジェクト全体の健全性を意識する立場へと少しずつ変わってきたと感じています。
4.把握した現場全体像と改善案
前章の取り組みを進めていく中で、現行のアーキテクチャを整理し、設計・運用の前提と実装の乖離や、運用面でのリスクが徐々に明確になってきました。
4.1. 現行アーキテクチャの全体像
下記が現行のアーキテクチャになります。
「△」がついている箇所は手動実行処理となります。
現在はAWS上の実行基盤において学習・推論処理を行い、分析・評価についてはSnowflakeを中心とした分析基盤で実施する構成となっています。
また、テスト環境と本番環境が分離されており、データ前処理や学習対象の選定から、推論・格納までの一連の処理がバッチ処理として実行される設計となっています。
実行基盤から分析基盤へのデータ移行は別のバッチ処理が担っており、バッチ処理の制御はAirflowを用いて実行しているため、推論結果格納の自動化に成功しています。
4.2. 全体像を把握して認識した課題
現行構成を把握した時点では、主に以下のような課題が存在していました。
- 格納ロジックの設計と実装に乖離があり、意図しないデータが長期間格納されていた
- バックアップ処理が存在せず、過去データの修正や検証が困難な状態だった
- 一部手動実行に依存しており、ヒューマンエラーリスクが残っていた
- モデル設計およびデータ取り扱いに起因するリスクがあり、推論結果の信頼性に課題があった
- データ量の増加に伴い、既存ロジックでは処理効率やコスト面で最適とは言えない箇所が存在していた
これらの課題に対して、運用上の影響が大きいものから優先順位をつけて対応を進めました。
判断基準として最も重視したのは、「現行処理を止めずに是正できるか」という点です。
理想的には、モデル設計やデータ取り扱いに起因するリスクについても早期に対応したいところでしたが、まずは日々の業務や意思決定に直接影響を与えるデータの整合性と再現性を担保することが最優先だと判断しました。
特に、格納ロジックの不整合により、意図しないデータが蓄積されていた点については、社内でも影響が大きく、このままではビジネス的損害に繋がる可能性がありました。
そのため、まずはデータの正当性と復旧可能性を確保することを第一とし、格納ロジックの是正及びバックアップ処理の追加を提案・実装し、すでに運用に反映されています。
(上記アーキテクチャにおいて濃青で表されているフローが追加した処理となります)
この一連の対応を通じて、技術的な正しさだけで優先順位を決めるのではなく、「顧客やビジネスに与える影響の大きさ」を軸に判断することの重要性を改めて実感しました。
MLOpsにおいては、理想的な改善を追い求めること以上に、現行運用を止めずにリスクを低減し続ける判断が求められる場面も多く、今回の対応はその典型的な例だったと感じています。
4.3. 今後の改善方針
一方で、依然として手動実行や人の判断に依存している箇所が残っており、運用面でのリスクは完全には解消されていません。
そのため、今後は「通常時は全自動運用・異常時のみ手動介入」という運用を前提とした改善を進めていく方針です。
下記が改善後のアーキテクチャイメージです。
具体的な改善として、
- 正常性確認及び成否判定の自動化
- エラー発生時に人が介入できる仕組みの整備
を進めることで、ヒューマンエラーリスクの低減と、安定した長期運用を目指します。
また、基盤面の安定化を完了したうえで、今後はモデル精度の改善や評価手法の見直しにも段階的に取り組む予定です。
具体的には、
- 特徴量生成およびデータ分割設計の見直し
- 学習・評価に使用するデータ取得条件の再整理
- 正常性確認時と学習時に参照するデータ母集団の整合性確保
といった観点から、推論結果の信頼性向上を目指しています。
5.技術的な学び
本案件を通じて、以下のような技術的なキャッチアップを行いました。
- Python/AWS/Snowflakeを用いた開発
- MLモデルが現場でどのように運用されているかの理解
- アーキテクチャ全体を把握する力
- 要件定義から運用までの一連の開発フロー
- 大規模データを扱う際の制約や注意点
特に後半の2点については、今後のキャリアにおいても大きな意味を持つ経験になったと感じています。
本案件では、未経験ながらもプロジェクトを前に進める役割を担い、PMやエンドクライアントと認識をすり合わせながら、顧客の利益最大化を意識したデリバリーに取り組みました。
その結果、単に実装を行うだけでなく、仕様や制約について説明し、合意を得ながら進める経験を積めたと考えています。
また、数十億レコード規模のデータを扱う環境では、安易な実装がパフォーマンス低下やコスト増大に直結するため、処理特性を踏まえた設計が不可欠であることを実感しています。
具体的には、パーティションカラムの追加や、データを分割して格納する設計を取り入れることで、性能とコストのバランスを考慮した対応を行いました。
これにより、大規模データ環境においても、現実的な制約下でシステムを成立させる感覚を身に着けることができたと考えています。
6.非技術的な学び
また、技術的なスキルに加え、ビジネス価値を最大化するための非技術的な能力についても多くの学びがありました。
以下の点は本案件を通じて特に強く意識するようになったポイントです。
- 前提をそろえてから本題に入る説明力
- 利益最大化を軸とした説得と判断
- 「分からない」を仮説として提示する姿勢
- 自走して違和感を検知する力
これらに共通しているのは、単に実装するだけでなく、顧客やプロジェクトにとっての価値を起点に考え、それを技術で実現するという姿勢です。
ときには、相手にとって手間や負担が増える提案であっても、中長期的に見て利益最大化につながると判断した場合には、背景や理由を整理したうえで説明し、合意形成を図る必要がありました。
ビジネス上の目的や制約を理解し、関係者と認識をそろえながら技術的な解に落とし込む、という橋渡しを担うことができる点は、本案件を通じて自分の強みになったと感じています。
7.今後の課題
本案件を通じて、既存のアーキテクチャや実装を理解し、運用上のリスクや改善点を発見・是正する経験を積むことができました。
一方で、「なぜこの設計になっているのか」「そもそも別の選択肢はなかったのか」といった設計思想の部分まで踏み込んだ検討については、まだ十分にできていないと感じています。
既存構成を前提に改善を行うだけでなく、要求整理の段階から関わり、最適な構成を一から設計できるレベルにはまだ到達していないというのが正直なところです。
特に大きな課題として感じているのが、MLモデルおよびMLOpsパイプラインのゼロイチ構築経験が不足している点です。
本案件では、既存モデルや既存パイプラインを理解し、改善・自動化・安定化を進める役割が中心でした。
そのため、モデル選定や特徴量設計、学習・評価・デプロイまでを一気通貫で設計する経験は限定的でした。
今後MLOpsとして専門性を身に着けていくためには、要件定義の段階から「どのようなモデル構成・パイプラインが適切か」を設計し、実装・運用まで落とし込める力を身につける必要があると考えています。
そのためにも、今後は
- 既存処理の設計意図推定
- デザインパターンやCSといった設計判断の引き出しを増やすための学習
- Kaggle・個人開発や別案件での実践
を通じて、「分かっている」から「選べる」状態へのステップアップを目指していきたいと考えています。
8.「期待を超える」ことの難しさと面白さ
本案件に取り組む中で、強く意識するようになったのが「期待を超えること」の難しさと、その面白さです。
正直に言えば、初めから「お客様のために価値を出したい」といった高尚な動機を持っていたわけではありません。
取り組みの動機は、評価を獲得するためでした。
SESという働き方においては、社内評価の指標として単価向上が重視されるケースが多くあります。
自社もその傾向が強く、加えて本案件では初期単価が90万と高水準であったため、言われた業務をこなすだけでは評価に繋がらないのではないか、という課題意識がありました。
そのため、与えられたタスクをこなすだけでなく、課題を見つけ自ら解決に動く、つまり「期待を超えること」が必要だと考えるようになりました。
このような、いわば不純な動機から始まった取り組みでしたが、結果として技術的な理解が深まり、自分の強みや立ち位置が明確になっただけでなく、仕事を「こなす」のではなく、仕事を「創り出す」面白さを実感しています。
もちろん、期待を超えることは簡単ではありません。
技術的な深い理解が前提となり、自分一人で完結しないため、他者を説得し行動を変えてもらう必要もあります。
思い通りに進まないことも多く、時間をかけた取り組みが結果に繋がらないことも多々あります。
それでも、期待を超えようと試行錯誤を重ねる中で、顧客の利益に実際に繋がる成果が生まれ、同時に自分自身の技術力や思考力が積みあがっている感覚があります。
この積み重ねこそが、環境や役割に左右されない力につながり、次の選択肢やチャンスにつながると考えています。
今後も期待に応えるだけにとどまらず、期待を超えるためにもがき続けながら、価値を提供できるエンジニアであり続けたいと考えています。
おまけ：参画前のもがき
本編を振り返り、「内容がきれいすぎるな?」と感じたので、おまけとして案件参画までのもがきも書くことにしました。
テーマは下記4つです。
- 転職活動でAI開発系企業150社以上落ちた
- ようやく入った今の会社では営業経験を買われ営業系の案件ばかり振られる
- 粘りに粘ってようやくAIエージェント開発案件の話が来たと思ったらMLOps案件への補充要員として参画が確定してしまう
- 技術面を見てくれていたメンターが転職して成長方針を見失う
それぞれに対するもがきが下記のようになります。
- 資格取得やKaggleで実績を積みながら内定が出るまで続ける
- ポートフォリオ作成や資格取得で実績を積みながら「やりたいことはAI開発なんです」と営業に営業し続ける
- 「現場で経験が積めないのなら自分でやればいいじゃない」と個人開発で論文検索AIエージェントを完成させる
- メンターがPC返却をする直前に「大事なお話」という1on1を入れて個人的な連絡先を聞く
...と、裏ではこんな感じでまあまあ必死こいてもがいていました。
本編だけ読むとそれっぽいですが、実際は試行錯誤と失敗の連続で、正直しんどい時期のほうが長かったと思います。
それでも今こうして振り返ると、もがいていた時間は無駄じゃなかったなと思います。
このおまけが「あきらめたらそこで試合終了ですよ...?」という一例になれば幸いです。