報告のやり方を揃える

概要

アジャイル開発・スクラムで開発スケジュールの確認、進捗を測る方法としてはバックログ・バーンダウン(アップ)チャート・ベロシティ・スプリントレビューと様々なやり方が存在する。しかし旧来組織の中で一部チームだけがアジャイル開発に取り組んでいる状況だと、他のチームとの報告のやり方が異なることで懸念を示されたり、内容が理解されなかったりすることがある。

このような場合、無理にアジャイル・スクラムのやり方を押し付けて理解させるのではなく、旧来組織のフォーマットに進捗を変換して報告すると良い。

チームの対外的な窓口としてはスクラムマスターがその役割を担うのが良さそうだが、管理職が行っても、プロダクトオーナーが行っても問題ないと考える。報告対象が状況を把握しやすく情報をまとめられる人が担当すれば良い。

どこから報告のやり方を変えるべきか? アジャイル開発に巻き込む管理職の見分け方は?

報告フォーマットを変えることでアジャイル開発に取り組むことに対する波風を抑えることができるが、少しでも抵抗されたら即フォーマットを変えれば良いというものでもない。

組織の階層を上に辿っていくとある地点で「開発対象が理解できる管理職」から「管理のための管理職」に切り替わる箇所がある。ここがアジャイル開発に巻き込む管理職を見分けるポイントで、「開発対象が理解できる管理職」までを巻き込むようにすれば良い。報告フォーマットを切り替えるタイミングもここになるように組織にアジャイル開発を広めていくことを目標にする。

ネタ元

認定LeSS実践者研修にて

Re: エンジニアリングマネージャーでいるのがつらくなったときは

はじめに

c5meru.hatenablog.jp

自分もチームリーダー→プロジェクトリーダー→プロジェクトマネージャーと役割が変わっていった時に、同じようなことを考えたことがあったなと思い出しました。

私の場合

マネージャーはチーム・組織を開発するのが仕事

海外子会社に出向してある製品開発に携わることになり、ガラッと環境が変わりました。最初はプロジェクト管理として入り、次にソフトウェア部門のマネージャー、プロジェクトリーダーと役割が拡大していきました。実装作業から離れ、協力会社・取引先との打ち合わせ・調整・マネジメントが主業務となり、社内の面談でも自分の成果を伝えることが難しいなと感じるようになりました。

1年ぐらい炎上するプロジェクトと格闘したのち、ある時の上司との面談で「うまくできていたのか、できていなかったのかまったく手応えがない」と打ち明けたところ「協力会社・取引先からプロジェクトに参画してもらって助かっていると感謝の言葉が来ていただろ、あれが全てだ」とコメントをもらいました。

その時から私のマネージメントに対する認識が変わったことを覚えています。 エンジニアの開発対象がコード・ソフトウェアであるように、マネージャーの開発対象はメンバ・チーム・組織・開発プロセスです。メンバが直面している課題を解決し、チーム・組織全体での成果を引き上げることがお仕事です。 マネージメントに対する認識が変わった後では、開発チーム・プロジェクトが「雰囲気良く協力し合い」、「技術的・組織な課題に対処できており」、「スケジュール通り進捗」していればそれを自分の成果として上司に伝えています。何度か上司が変わりましたが、変わらず良い評価をもらえています。

チームの雰囲気を察知する

職場の人間関係に対して常にアンテナを張っていなければいけない気がする不安 ・Slackから目が離せない ・あそこで話している人たち、何を話しているのだろう?

「人を管理する」と捉えると上記の発想になりやすい気がしますが、「チーム・組織を良い状態に引き上げる」と考えると少し違った手が打てます。

例えばこんな感じです。

• 定期的に振り返り(KPT)を実施してもらい、問題として上がってくる内容に目を通す。
• チームで解決できない問題を「リーダー・マネージャーに対処してほしい問題」としてあげてもらい、付箋で壁に貼るなどして皆が見える場に置く
• 上がってくる課題に対して「何らかの施策」を「早急に打つ」。根本原因に迫れれば良いが、効果はやってみないとわからないので小さな一歩でもとりあえず試してみる。課題をあげても対応されないと士気が下がるので早くに対応する。
• 問題はいつ、どのようなものが上がってくるかわからないので自分の時間は空けておく。むしろ暇なぐらいが良い。
• 時間ができたらまめに職場を歩き回り、メンバと会話する。「さんぽ」と自称して、話しかけてもらうハードルを下げる。色々な問題がカジュアルに出てくるようになる。

要は問題を提起するやり方がメンバに定着し、改善する流れがつくれれば細かく見張る必要は減っていきます。

プレイヤーに未練はないの?

次々新しいものが出てくる実装・技術を身につけてスキルアップしていくことは楽しいですが、マネジメントも同様に学ぶものが多くあります。

私は「仕事をうまく回せるチームを"再現性"を持たせて作れるか」をテーマにして取り組んでいます。 同じメンバ・同じチーム・同じプロダクト・同じ課題に直面することはなく、課題に対する施策も効果があるものもあればそうでないものもあるのがマネジメントだと思っています。

今の自分の自己評価は「30〜40人のソフトウェアエンジニアをまとめて、1つの製品をアジャイルに開発できる」です。これがゴールではなく、この先には「ビジネス・バックオフィスもまとめて全社でアジャイルにやる」、「100〜200人、もしくはそれ以上の人数で大規模アジャイル開発を実現する」といったチャレンジがあると考えています。

スーパーマンリーダー、プレイングマネージャーに対するスタンス

いたらラッキーだけど、いないと回らないチーム・組織になってしまった時点でマネジメントの負けかなと考えています。

• チームの単一ボトルネックに容易になりうる
• メンバの尊敬を集めるかもしれないが、「自分はリーダー・マネージャーになれない」という先入観を与えてしまうかもしれない
• メンバに任せるべきところを任せられず、チームとしての成長を阻害する要因になるかもしれない

おわりに

マネジメントはマネジメントの面白さがあると思います。

あなたのチームのスクラムマスター、「スクラム秘書」になっていませんか?

概要

「私たちは毎スプリント、スクラムマスターをローテーションします(“We rotate the Scrum Master role every Sprint” – Serious Scrum – Medium)」という記事の中にある「スクラム秘書(Scrum Secretary)」という表現が面白かったので、悪いスクラムマスターの例として流行ってほしい。

詳細

スクラム秘書とは

元記事では下記の悩みに対する解決策として毎スプリントのローテーションが実施されたとある。

No-one wants to be the Scrum Master in our team. That is why we decided to rotate. Every Sprint we switch the Scrum Master role.

私たちのチームでは誰もスクラムマスターになりたがりません。だからローテーションすることに決めたんです。毎スプリントでスクラムマスターの役割を変えています。

リーダーシップを取りたがる人がおらず、スクラムに対する理解が浅く、適切なコーチもいないとこのような発想にたどり着くのでしょうか。 スクラム秘書がいるチームはこんな雰囲気なのでしょう。

• スクラムを始めた時に年上、役職者、当初のリーダーがなんとなく役割を引き受ける。
• プロダクトオーナーが上位に置いているバックログアイテムを適当にもらってくる。スプリント内に終わるかどうかはあまり気にしない。
• 毎朝の朝会の司会を淡々とこなす。各自がやってることを報告してすぐに朝会が終わる。
• スプリントが始まるとスクラムマスターとしての帽子を脱ぎ、一開発者として黙々と開発に没頭する。チームの状態はたいして気にしない。
• スプリント終盤になって遅れが出てきても特に何もしない。朝会で「遅れているのでみなさん頑張りましょう」と言うだけ。
• 決まりなのでスプリントレビューを実施する、もしくは誰も来てくれないのでスプリントレビューをスキップする。たいして盛り上がらず時間が過ぎるだけ。
• 振り返りはみんながやっているKPT！ TRYは「次から気をつける」「次スプリントからはXXXを頑張る」といった気合いTRYが決まる。

当然のことながら、スクラムマスターは誰でも簡単にすぐできる役割ではなく、「メンバ全員スクラムマスター経験者」とかで無い限り、スクラムマスターのローテーションはできません。

望ましいスクラムマスターの振る舞い

スクラムガイドにある責務は下記の通りです。

“The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

スクラムマスターはスクラムガイドに定義されたスクラムを推進し、助けることに責任を持つ。スクラムマスターは皆がスクラムの理論・練習・ルール・価値を理解することを助けることでこれを実現する。

先に挙げた問題に対し、望ましいスクラムマスターはこう振る舞います。

• スクラムを理解している人、チームのために働く人をスクラムマスターとして任命する。任命してうまくいかなければ途中で交代する。
• プロダクトオーナーが上位に置いているバックログアイテムをもらってくる。価値が理解できないもの、着手条件を満たしてないもの、スプリント内に終わらないものは引き受けず、プロダクトオーナーと対応を協議する。
• 毎朝のデイリーミーティングで「チームが昨日やったこと、チームが今日やること、チームとしての課題」を確認する。朝会とは限らず、チームにとって最も良い時間にやる。
• スクラムマスターは自分の時間をチームが最大の成果を引き出せるように自分の時間を使う。メンバを助け、チームの問題や障害を取り除き、時に対外的な盾となってチームを守る。
• 計画に対して順調に推移しているか、バーンダウンチャートなどを使って確認する。遅れている場合は対応策を、スプリント内に作業が終わらない場合はその時点でプロダクトオーナーと相談する。
• スプリントレビューを実施し、顧客の反応を観察し、プロダクトをより良くするための開発項目・アイデアを引き出す。
• 振り返りはみんながやっているKPT！ だが、全ての課題を改善することはできないため、最も重要な課題1〜2個に絞り、具体的なアクションにTRYを落とし込む。

下記は少しオーバーな表現で示されていますが、チームを守るためになんでもするのがスクラムマスターです。

www.youtube.com

ネタ元

medium.com

バックログアイテムを4象限に分類する

解説

プロダクトオーナーはプロダクトバックログアイテムに優先順位を定める時、様々な事項を考慮する必要がある。 新機能の追加、技術負債の解消、アーキテクチャ・技術基盤の見直しなど。 無意識のうちに特定の領域を優先してしまうことがないよう、「過去-将来」と「ビジネス-技術」の2軸でプロダクトバックログアイテムを分類し、どの領域にどれだけのリソースを費やすのかあらかじめ決めておく。

過去 & ビジネス

バグフィックス、顧客サポート、ちょっとした改善など。 既存顧客のためにリソースを使うことになる。

将来 & ビジネス

新機能の追加。新しく顧客を引き込むためにリソースを使うことになる。

過去 & 技術

技術負債の解消。遺産のために生じるコストや、将来の開発効率を改善させるためにリソースを使うことになる。

将来 & 技術

新技術の導入。将来のコストダウンや、開発効率の改善、差別化のためにリソースを使うことになる。

効果

どの領域にどれだけ注力しているからが簡単にわかることになる。 スプリントレビューで成果を見せる際にどの領域の作業かを示すことで、誰向けの作業かビジネス側の人にわかりやすくなる。

ネタ元

medium.com

www.growingagile.co.za

Re: FOLIO を支えるエンジニアリング組織の七転八倒記: 2018年冬

はじめに

国内のLeSS事例をまとめている際に見つけた大規模スクラムにおけるプロダクトの定義 - TechとPoemeの間の筆者さんがFOLIOのアドベントカレンダーで、会社の開発体制・組織構造の変遷について下記の記事を公開されていました。

t-and-p.hatenablog.com

「英語のLeSS本を読むくらいなら、開発体制もLeSSにしちゃえば挙げられている課題は解決しそうなのに」と思ったのですが、はてブのコメントでは書ききれない分量なのでここにまとめます。

LeSS (Large Scale Scrum)とは

日本語だと下記の記事が素晴らしくまとまっています。

qiita.com

このブログでも下記に情報をまとめています。

tune.hatenadiary.jp

FOLIOさんの開発体制・状況はこんな感じなのかな…?

記事を読んでの想像です。違っていたらごめんなさい、すぐ訂正します。

• 証券会社という性質上か「抑えるべきところは抑え、固く進める必要がある」雰囲気がありそう。アジリティ・スピード感を持たせた開発を対外的に言いにくいのかもしれない。
• スクラムで規定されているイベントはやっていないか、部分的に取り入れていそう。元記事の筆者さんが入社したのが2018年2月らしいのでアジャイル開発の知見を持つ人がそこから入ったのかもしれない。
• ウォーターフォールではないのだろうが、アジャイル開発とも対外的に言えない開発プロセスになっている。
• 技術力の高いメンバの底力でベンチャー企業のスピード感に追いついてきたが、人が増え・やることが増えたことで組織づくりが急務になっている。

LeSSを導入したら解決するはずの点

プロジェクトではなくプロダクトを作る

アジャイル開発は顧客にとって価値がある成果を短期間で提供していくことが目的です。元ブログの 今，個人的に重視しているエンジニアリング組織のためのセオリーをまとめる - TechとPoemeの間でも「フロー効率」として挙げられている点です。 有期のプロジェクトだと終了時にメンバが入れ替えになることでチーム開発力が低下したり、文化が失われてしまいます。また締め切りが常に頭に貼り付いているような状態だと「そもそもどんな課題を解決することが目的だったのか」が後回しになってしまいます。 あくまで利用者・顧客にとっての価値を第一に置いておけば自然とプロダクト開発に皆の意識が揃っていきます。

プロダクトの定義は大きく設定する

LeSSで推奨されている考え方です。「そもそもどんな課題を解決することが目的だったのか」が正しくチーム・メンバに理解されてないとその場しのぎの解決策に負けてしまいます。

LeSS実践者研修の講師 Bas Vodde氏がNokiaを例に挙げたのが下記の考え方です。

1. 通信モジュール/ライブラリ
2. 通信チップ/基盤
3. 通信機器
4. 通信基地局/通信キャリア

Nokiaの製品は通信基地局向けの機器(3)ですが、末端のエンジニアが主に取り組むのは通信モジュール/ライブラリの開発(1)でしょう。とはいえ単に決まっている仕様をコードに落とし込む作業と、通信機器としてどう有るべきかを頭に描いた状態でやる作業の結果は大きく異なるでしょう。とはいえNokiaは通信キャリアではないので大きければ良いとは言っても自社でコントロールできない基地局運用や通信キャリアのビジネスモデル(4)まで考えた開発はできないでしょう。ということでNokiaの開発者にとってもっとも大きいプロダクトの定義は通信機器(3)でしょう。

FOLIOさんだとこんな感じでしょうか?

1. 投資運用アルゴリズム
2. マイクロサービス
3. PORT/FOLIOサービス
4. 投資プラットフォーム
5. ワクワクする投資文化(?)

元記事のプロジェクトのスコープは2と3の間に見えますが、実際は4あたりなのかな。

「バックエンドエンジニアのサブグループ化」ではなく「クロスファンクショナルのフィーチャーチーム」を作る

顧客に価値が提供できるのは「3.PORT/FOLIOサービス」か「4.投資プラットフォーム」として世に出せたタイミングになるので、企画からリリースまでのタイミングを短くするのがもっとも望ましい開発体制となります。そのためには1つのチームが企画からリリースまで単独で遂行できる必要があり、「バックエンド/フロントエンドなどの職能チーム」ではなく「上から下までチーム内で取り扱えるクロスファンクショナルのフィーチャーチーム」を構成しなくてはなりません。

「フロントエンドより」「バックエンドより」はあっても良いですが、「バックエンドしか触れない」チームはNGです。

こうなると

1. チーム間で調整・すり合わせのためのミーティング(XXX定例)や調整役(XXXプロジェクトリーダー)が必要になる
2. 会社・組織として最優先で取り組まなければならない開発項目があっても、バックエンドに関する項目がないとチームが遊ぶことになる。またはバックエンドチームが全く価値のない開発作業を時間を埋めるために始めることになる。

フィーチャーチームは下記に詳しく書かれています。

• フィーチャーチーム

「マイクロサービスのオーナーシップの不明瞭さ」はコンポーネントメンターを置く

フィーチャーチームを構成すると全チーム(全員)が全てのコードを触れることになりますが、好き勝手に作っていては設計方針がずれてしまいます。また技術負債や問題があってもオーナーシップが薄れ、返済・解消が遅れがちになります。

これを解決するLeSSのプラクティスがコンポーネントコミュニティー & コンポーネントメンターです。

私ならこんな順序でLeSS導入をするかな

1. バックログを作り、開発優先順位を見える化し、共通のものとする

進行中のプロジェクトが扱っている開発中の仕様のドキュメントや,プロジェクトのスコープや課題の一覧をまとめるpj-doc と呼ばれるプラクティスが社内で確立したり

内容的にスクラムでバックログと呼ばれる項目に思えます。全社で唯一の開発優先順位を決めたバックログをまず作ります。そして唯一のプロダクトオーナーを決めましょう。プロダクトオーナーが複数人いると方針がぶれるので、優先順位を決めるまでの議論は喧々諤々やった方が良いですが、最後の意思決定者だけは1人に決めます。

2. フィーチャーチームを構成する

職能別のチームを解体し、複数のレイヤに携われるフィーチャーチームに作り直します。

チーム構成を考える上で、バランスのとれたスキル配分となるよう、スキルマップを作って参考にします。

またチームを下から支えるリーダー、スクラムマスターを決めます。職能チームのリーダーが引き継ぐことも一案ですが、専門技術をリードする能力と、チームをまとめる能力は異なるので、できそうな人をピックアップしてリーダーに任命しても良いかもしれません。

先にリーダーを決め、リーダーにチームとしてありたい姿を語ってもらい、メンバにどのリーダーについていくか決めさせるやり方もあります。私はやったことはありませんが、面白い取り組みだと思います。

tech.nikkeibp.co.jp

3. DONEの定義の拡張ワークショップを実施する

2で作ったフィーチャーチームは社内の全機能を開発できることはなく、PORTのみ・FOLIOのみ・またはそのうちの一部だけに知見があるという状態だと思います。またPORT/FOLIOは扱えるが、テスト・マニュアル・法規制確認など「リリースまでにやらなくてはいけないが、各チームがスプリント内で扱えないもの」があるはずです。一朝一夕に扱える領域は増やせませんが、増やす順番・目標・時期を決めるために「DONEの定義の拡張ワークショップ」をやると良いです。

独立した記事でまだまとめていませんが、下記で少し触れています。

Re: スクラムを大人数で運用したところ💩な結果になった。 - tuneの日記

4. コンポーネントメンターを任命し、コンポーネントコミュニティの運営を依頼する

マイクロサービスに詳しい人にメンターとなることを依頼し、コミュニティを作ることを依頼します。まずは社内のSlackチャネルにマイクロサービス固有の議論をするチャネルを作り、アナウンスして興味がある人に参加をお願いします。あとは好きに議論するなり、定期的にメンバを集めて打ち合わせを持つなりすれば良いと思います。

コンポーネントメンターにPull Requestのレビューを依頼することをやりそうですが、開発のボトルネックにならないように注意しましょう。メンターはコンポーネントの相談に乗り、時に方針を出すことに注力するべきで、コードレビューやテストの責任はあくまでチーム内で完結できるように育てていく方が良いです。

LeSS実践者研修オススメ

上記の内容を3日間で学べるLeSS実践者研修オススメです。次回は2018年3月12〜14日です。

training.odd-e.jp

スクラム開発を取り入れるためにパイロットプロジェクトを作るべきか

概要

結論から言うと「無い」。

開発・組織・社内全体をアジャイル開発・スクラム開発に切り替えるためであっても、複数のプロダクトを、複数のチームで別個に開発する限りは一気に取り入れた方が良い。

詳細

パイロットプロジェクトの目的

weblioの説明が短くまとまっていました。

実際的ではあるが限定された運用条件のもとで,情報処理システムの暫定版を試験するように計画されるプロジェクトであって,後にそのシステムの最終版を試験するために使用されるもの.

少数のチームで実験的な取り組みを行い、学んだことを踏まえて次のプロジェクトに活かしたり、組織内に横展開を図るための進め方です。

なぜスクラム開発はパイロットプロジェクト方式と相入れないのか

スクラム開発は不透明な課題に対して、チームとして協力し合い、チームの自律性を促し、メンバの成長を実現させ生産性を高める人にフォーカスしたフレームワークです。チームが取り組むプロダクトが違えば、チームメンバの性格や能力も異なり、各チームが直面する困難も異なります。

スクラム開発を学ぶために外部からアジャイルコーチを招き、小さくスタートする形がよく見られますが、チームが得た学びはチームのものであり、別のチームでも活用可能な一般的な知見が得られるかは保証できません。むしろ一斉に導入した方がアジャイルコーチが全員を集めて知識を集中的に教えることができ、レベル差が小さいスクラムマスター同士で困ったことを相談でき、組織へのアジャイル開発導入も短時間で完了します。

1つのプロダクトを大人数・複数チームで開発する場合はどうするか

たくさんのアジャイル開発チームを作るのであれば一気に導入した方が良いですが、1つのプロダクトを手がける大規模チームを作る場合はプロセス変革・組織変革を伴うため一気に導入してはなりません。

小さな単位で初め、少しずつ拡大していきます。

ネタ元

LeSS実践者研修で講師だったBas Vodde氏の話より。

機械学習を含む開発をアジャイルに取り組む

機械学習のイメージ

概要

機械学習・ディープラーニングなどアルゴリズム検討を含めてうまくアジャイル開発を回すやり方を考えたい。

Spotifyで機械学習に取り組むDavid Murgatroyd氏がSlideshareに公開している資料をベースとしている。

Agile Deep Learning from David Murgatroyd

www.slideshare.net

詳細

機械学習の検討がアジャイル開発でうまく回せない要因

アプリケーション・システムの開発と比較してアルゴリズム開発は予測しづらい事項が多い。また手番も長くかかるため、製品全体を固定期間のスプリントで区切り、アジャイルに開発しようとするとアルゴリズム周りでうまくいかないことが多い。近年だと機械学習やディープラーニングが関係する箇所が特にそうなりやすいのではないか。

機械学習の検討の流れ

David Murgatroyd氏の資料では下記のように整理されている。楽曲の推薦アルゴリズムを業務で開発していると思われるが、検出や認識など他のアルゴリズムでも大枠は外してないと思われる。

1. 問題を明らかにする (Identify Problem) : 解決すべき課題を明確にする。
2. メトリクスを明らかにする (Identify Metrics) : 課題が解決できたか確認できる指標を明確にする。
3. データを明らかにする (Identify Data) : 扱うデータセットの用意・整備
4. モデルを明らかにする (Identify Model(s)) : どのようなアプローチで問題に取り組むか。ディープラーニングのネットワーク検討など。
5. 探索・実験 (Explore & Experiment) : データセットをもとに学習を施行する。
6. 分析 (Analyze) : モデルがうまく動作しているか、仮定に見落としが無いかを確認する。
7. 優先順位づけ (Prioritize) : 課題の対処法を検討する。
8. 製品投入 (Productize) : 完成したモデル・アルゴリズム・モジュールを製品に組み込む。

開発フロー案

別チームとして扱い、アジャイル開発のサイクルに取り込まない。定期的に成果物をリリースしてもらう。

機械学習の検討を行うチームとアジャイル開発を行うチームを完全に分ける。機械学習検討チームはアジャイル開発を行わず、彼らの都合の良いタイミングで不定期にリリース物を出してもらう。そしてタイミングを見てアジャイル開発チームが成果物を製品に統合する。。全体としてアジャイル開発は実現できていないが、とりあえず機能する。

デリバリーまでに時間がかかること、顧客からのフィードバックが届きにくいこと、フィードバックを踏まえた開発項目の優先順位見直しがやりにくいことが課題である。

機械学習の検討ステージによってスプリント内で扱う開発項目を絞る。

よくあるスクラムを用いたアジャイル開発は固定期間のスプリント内(1週間〜1ヶ月)で要求分析・設計・実装・テストまでを行う。先の機械学習の流れで言うと1から8まで1週間〜1ヶ月で終わらせるイメージとなる。これでは検討時間が十分に確保できず、スプリント内で不足の自体が起きると成果なしとなってしまう。

そこで機械学習の検討ステージによってスプリント内で検討する項目を限定し、開発期間の短縮を図る。具体的には次のようにする。

1. 課題の明確化・基本方針の決定→1〜4を扱う : 課題・指標がうまくつかめるまで試行錯誤を行う段階。基本方針となりうる候補をいくつか見つける。
2. モデルの選定・改善→4〜7を扱う : モデル・データ・アプローチを変えながら改善を試みる。最終製品で用いるモデル・アルゴリズムを決定する。
3. 製品投入前の仕上げ→ 5〜8を扱う : パラメータの調整を行い、製品品質に精度を高める。

チーム構成案

クロスファンクショナルチームを構成する

各チームに機会学習に長けた人材を配置し、アプリケーション・システム開発を行うメンバと協調して開発を進める。 アジャイル開発としてはもっとも望ましい状態。 各チームに機械学習エンジニアが大勢いることはないので、機械学習アルゴリズムの深掘りがしにくい課題がある。 製品にたくさんのモデル・アルゴリズムがあり、それぞれが比較的シンプルな場合に有効。

専門チーム

機械学習に長けた人材をチームに集め、成果を別チームに提供する。 機械学習アルゴリズムの深掘りはやりやすくなる。 システム・アプリケーションを開発する別チーム間と開発スピード・サイクルを揃える必要が出てくる。 製品に少数で複雑なモデル・アルゴリズムがある場合に有効。

機械学習エンジニアの分類と役割

ひとくちに機械学習エンジニアといっても本人の特性・資質によって役割が異なる。

「機械学習の適用」を行うエンジニア

ツール・ライブラリ・既知のモデルを元に、製品で活用できる機械学習技術を開発するエンジニア。 ArXivに投稿される最新論文や、分野ごとの技術動向をウォッチし、自社の製品に活用できるものを見定めて取り込むことを行う。 求められる素養としては「アルゴリズムもわかるエンジニア」。

「機械学習に必要なツール」を開発するエンジニア

最新の論文、分野ごとの技術動向をウォッチし、背景の理論を理解し、技術の検討・開発に必要なツールを開発するエンジニア。 求められる素養としては「理論がわかり、実装にも強い研究者・またはエンジニア」。

「機会学習の理論」を開発する研究者

機械学習の新アルゴリズムを考案する研究者。

みんなどうしているんだろう?

事例を集めてもっと良いやり方を見つけたい。