現職のコンサルっぽい仕事・インフラアーキなエンジニアな仕事も大好きですが, やっぱデータを見ると興奮するぐらいにデータ好きな人です.
本日（2023/1/19）, ありがたいご縁がありまして, 「機械学習エンジニアが目指すキャリアパスとその実話」というお話をさせていただきました.
参加者の方々, ご清聴ありがとうございました&参加されていない方も気になるポイントあればぜひ御覧ください.
1/19の #stapy で「機械学習エンジニアが目指すキャリアパスとその実話」なるトークをすることになりました, 自画自賛ですが思ったよりいい内容に仕上がった気がします, 機械学習とかデータサイエンティストとかのキャリアでお悩みの方に届くと嬉しいです, 来てねhttps://t.co/KHxAXYY5mr pic.twitter.com/eguUyEnfbN
— Shinichi Nakagawa / 中川 伸一 (@shinyorke) 2023年1月10日
開催前に（宣伝を兼ねて）こんなツイートをさせてもらい,
特にこちらの絵に対する言及や反応が結構多かったので,
- 駆け出し・メンバーの頃やっててよかったこと
- プロジェクトの主力メンバーとしてやっててよかったこと
- マネジメントとしてやっててよかったこと
こちらをちょこっと掘ってこのエントリーに残したいと思います, 言い換えると「発表に入れようと思ったけど入らなかったコンテキスト」集です.
なお本日のラインナップはこんな感じです.
TL;DR
「ドッグフーディング」「プロジェクトマネジメント」「最後までケツを持つ強気なお気持ち」この3つメッチャ重要やで.
機械学習プロジェクトを成功させるには?
本題に入る前に, 目線合わせの意味も込めて, 「そもそも機械学習プロジェクトってどうやったら成功するの?」というのを再確認します.
これはなんと既に「仕事ではじめる機械学習」という本で良い言語化がなされています.
どう書かれているかというと,
機械学習を含めたプロダクトをビジネスとして成功させる上で重要になるのは、どのようなチームでしょうか?私（著者）は以下の4者が重要だと考えます。
- プロダクトに関するドメイン知識を持った人
- 統計や機械学習に明るい人
- データ分析基盤を作れるエンジニアリング能力のある人
- 失敗しても構わないとリスクを取ってくれる責任者
※「仕事ではじめる機械学習」 1.4「機械学習を含めたシステムを成功させるには」より引用
これ以上に無い言語化です, 本当にそのとおりだと確信しています.
- ドメイン知識が無いと良い課題設定・仮説が立たないし, 手法や特徴量で全くもって見当違いの事をしてしまう可能性が高い
- 統計・機械学習は言わずもがな, 手段として無いとお話にならない.
- データの利活用を含めた実業務への連携, ビジネスシーンに合わせたモデルの更新（いわゆるDevOps）などはデータ基盤を作れる・運用できるエンジニアリング能力がないとお話にならない.
- プロジェクトが上手くいくときはもちろん, 「なんだこれ全然使えないじゃん」的な事になった際もリスクを取ってメンバーを守ってやり続ける（もしくは撤退させる）責任者がいないと上手くいくものも上手くいかない
と思っています.
これを「データサイエンティストをやるぞ」「機械学習エンジニアからのマネジメント目指すぞ」的なキャリアプランに当てはめる際の考えはシンプルです.
自分自身が4者の役割の内, どの順番に鍛えて成長していくか?というキャリアプランを考えて実践する.
シニアになればなるほど役割は増えていく感じになります.
やっててよかった3つのこと
というわけで, 「やっててよかった3つのこと」の話です.
ざっくり上げると,
- 「ドッグフーディング」を通じて己の技量向上とドメイン知識習得を頑張る
- 「プロジェクトマネジメント」を学ぶ・やる（逃げない）
- 「最後までケツを持つ強気なお気持ち」を絶やさず育てる, ヤバいと思ったら逃げよ
こんな感じです.
駆け出し・メンバー時代
この時代に関しては,
「ドッグフーディング」を通じて己の技量向上とドメイン知識習得を頑張る
生データを見るだけではなく, 対象サービスを自ら使うドッグフーディングを通じた「ドメイン知識の習得」は徹底してやることを覚え実践しました.
私はこの時代GIS（地理空間情報）系のプロジェクト, もっと雑に言えば地図アプリを作るみたいなプロジェクトをしていたのですが,
- 地図アプリの作り方・データ構造を知るため, Google Maps等の地図アプリをとにかく触ったり, GISの基本的な事を触って覚える.
- 地図コンテンツの対象であった情報を雑誌買って読み漁ったり, ネットで探したモノを読みまくる（余談ですが雑誌は自費購入）.
- 自分でもちょこっと地図アプリを作ってみる*1.
といった事をやっていました, クライアントや周りの人のほうが詳しかったので追いつくのに必死だった時代です.
すぐには結果は出ず, プロジェクトでも迷惑を掛けた機会の方が多かったのですが,
- 生データだけでなく, サービスやアプリを触ることで気がつくことが多いという実体験.
- データおよび周辺情報のどこを読めばいいか?という土地勘
- そして何よりも, データや資料を読んで理解する所業が苦しいと思わなくなった（必要な体力と気力, 速読術が習得）.
のが大きかったです.
手を動かすことで統計・機械学習のスキルだけでなく, ドメイン知識やエンジニアリング能力を鍛える, という意味でドッグフーディング大事です&これはマネジメントまでやるようになってもある程度はついてまわる*2基礎トレーニングみたいなもの, と今は解釈・実践しています.
プロジェクトの主力メンバー時代
駆け出し&下っ端メンバー時代から, 「中川さん機械学習とかやってるから出来るでしょ」的な任され方をされてからのやっててよかったことは,
「プロジェクトマネジメント」を学ぶ・やる（逃げない）
これに限ります.
私の場合, この辺の時代はベンチャー・スタートアップの社員として, 学生バイトやインターンとプロダクトを開発する機会が非常に多かったです, データ系の案件もそれ以外*3も.
ここで何が発生するか?というと, （エンジニアな仕事が好きな人が嫌いでおなじみ）「マネジメント」ってやつです.
- プロダクトオーナーの
思いつきお気持ちのこもった企画を要件・基本設計化. - デリバリーする日を決めて作りきって出す. なおプロジェクトマネジメントはスクラムだったりXPだったりウォーターフォールだったり色々.
- エンジニアとしての自分のリソースを計算しつつ, 他の若手メンバーや学生さんのリソースを計算してはめる, 「この日はシフト入れないからだめよ」みたいなのも計算に入れて.
私が今働いているコンサルの会社やSIを生業にする会社だと「そんなの当たり前じゃん」なのですが, そうじゃない会社さんだとこれ, 意外とみんなやりたがらないんです, 「コード書きたいから」とか「育てるの無理」とか色々な理由で.
私の場合は幸いにも「若い人を育てながら何かをやる」のが好きだったのと*4, 機械学習やデータサイエンスをちゃんとやれる人材はただでさえ少ない&現実的な解決策として社員に関係なく（必要な報酬とバリューを提供した上で）学生さんや若い人たちにやってもらうようにしないと回らん！っていう事情があったのでプロジェクトマネジメントを兼任しながらやりきりました.
私のエンジニアリングスキル的には「ガチンコのアルゴリズム・数学屋」ではなく, 「何かモデルとPoC出来るやつあればシステムとしていい感じにまとめまっせ」という, 「データ基盤エンジニア」としてのスキルが強めだったので,
- アルゴリズムやらモデル作りやらは得意な若者に任せる. といいつつ, ドメインを知らないと出来ない事は私がしっかりレビュー.
- システムへの組み込み, PoCに必要なプロダクト作りは私の担当. コア部分を設計・実装し, 端っこの部分を学生さんや若い人にやってもらう（ISSUE化した上で）.
- これらを締め切りなど意識しつついい感じにプロジェクト&プロダクトをマネジメント.
これでなんとか乗り切りました.
ちなみにですが, マネジメントの教本となったのはこの辺です.
スクラムでスプリント作ってやるのには食い合わせが悪そうだった（それなりのスクラム経験者としての土地勘）のと, 「私と2, 3人のチームなのでコミュニケーションの濃度を濃くする感じが良かろう」という判断*5でエクストリーム・プログラミングな方式でやりました.
あ, もし他にいいマネジメント方法あれば教えて下さい（緩募）
マネジメントを初めた今
前職のワクチン的なプロダクトでいい感じになった辺りです, つい最近の話でもあります（といいつつ2年近く経過しているが）.
「最後までケツを持つ強気なお気持ち」を絶やさず育てる, ヤバいと思ったら逃げよ
責務と比例して権限が増え, プロジェクトの成功を託されるような感じになるともう割り切りしかないなってなりました.
深く悩んでも自分のためにならないのと,
- やること見えて筋道ついてきたらもうデリバリーするまでやりきるのに集中.
- 成功するかどうかは出たとこ勝負かつ, 当時やってたプロジェクトはモデルの更新も込みの話だったので後で巻き返せるのでは?という思いもあった.
- 成功したらチームで喜び, しくじったら学び・経験として捉えよう. 実はこれが一番大事（個々人のスタンスとしては）.
それがにじみ出ているのがこのスライドで,
こちらは実話で本当にこの気持ちでやりました,
「プロジェクトに携わってる皆さんが自慢できる・次のキャリアにつながる仕事をしよう, 自分も含めて.」
チームメンバーには言葉を変えながらこれずっと言ってた気がします, メンバーにだけじゃなくて自己暗示をかける的な意味もあったのですが, 正直に言うと.
これは結構効果あって, 結果としてチームもまとまり必要なアウトプットもアウトカムも獲得できました.
今思うとこれって,
失敗しても構わないとリスクを取ってくれる責任者
これそのものでした, 小さいチームだったとはいえ.
事業責任者ではなかったですが, プロダクトマネージャーに任じられていたので少なからず「責任者」というロールでは有りましたので結果的に大きな自信にも繋がりました.
ちなみにですが, 「どうしてもヤバいとなったら逃げる」はホントに考えていました.
自分の価値観的には仕事のために死ぬのは避けたいのと, 死ぬのを避けるにしても一生の傷として残るようなダメージを負うのは死に等しいとも思っていたからです.
「しくじったらやり直せばいい」ぐらいの余裕と安全ルートの確保, マジで重要です.
結び
というわけで,
- 駆け出し・メンバーの頃やっててよかったこと
- プロジェクトの主力メンバーとしてやっててよかったこと
- マネジメントとしてやっててよかったこと
を,
- 「ドッグフーディング」を通じて己の技量向上とドメイン知識習得を頑張る
- 「プロジェクトマネジメント」を学ぶ・やる（逃げない）
- 「最後までケツを持つ強気なお気持ち」を絶やさず育てる, ヤバいと思ったら逃げよ
という学びを添えて紹介しました.
基本的には目の前の事に（無理ない範囲かつ, 強いお気持ちを持って）取り組むのがいいかなと思います.
なお, 機械学習・人工知能的なのがメジャーになった今では仕事の取り組み・スタンスに参考になる書籍も増えてきています.
この辺は参考になると思います.
私の発表・このエントリーでちょっと思う所出たらぜひ先人たちの知恵を拝借する意味でも読むといいかもしれません, このブログよりもっといいこと書いてるので.
次はデブサミでお会いしましょう.
最後までお読み頂きありがとうございました.
*1:この辺はRailsとかでやっていた一方, 環境としてAWSを使っていて実はこれが地味にクラウドデビューだったりしました, 今から14年前（2009）ぐらいのお話.
*2:メンバーをやる頃ほど躍起にならないかもしれないですが, 実態把握をしたりレビューしたりマネジメントする上で知らないでやることは出来ない筈なのでという感じです.
*3:普通のWebアプリケーション開発・案件もあれば, E2Eテストを揃えるなどのDevOpsもありました.
*4:余談ですがこれが現職を選んだ理由の一つだったりします, マネージャーとしてもっと多くのメンバーを育てながら戦うというのがやりたかったので.
*5:Slackでのチャット, Zoomミーティング, 経緯はすべてGitHubとかのISSUEに落ちてる, ドキュメントもQiita Teamに書いてる的な状況で周辺環境はアジャイルに進められる感じだったので, あとはプロトタイプを元に議論&プルリクの応酬でどうにかなるだろうという判断でした（これが個人的にも一番好きでやりやすい方式）.
