きっかけ

ここ数年、JTC的な事業会社の中のヒトとして、いわゆる「DX」や「データ活用」と呼ばれているものの導入の旗振り役をやっている。
このネタが旬なのもあと数年だろうと思い記事化してみている次第。

前回の続きで、社内でDXを進めるために大事だと思ったこと、その3
最後は組織関連の話。

DX推進組織のスキル定義

事業会社内のDX推進組織として、もしくはその社員として保有すべきスキルの範囲や程度を定義しておく、ということである。

• 内製でアルゴリズムを開発して学会発表できるようなサイエンティスト集団を目指すのか？

• データ関連の「手に職」は社員には持たせず、外注管理と社内調整に徹する総合職集団として乗り切るのか？

まー、この2つは両極端な話で、分析自動化などの技術進化の状況や、自社がDX要員採用に与えることのできる給与水準等に鑑みながら、間のほどよいビジネスアナリスト集団としての定義を決めていくのが現実的なのではないか。

PDCAの高速化や、自社のビジネスドメインを理解した上でのアナリティクス設計が重要だと考えるなら、ほどよい程度のアナリスト集団は内部に形成する必要があると思っている。

ただ、業界業種によっては、特殊な技術集団を内製化することが、大きなDXの成果につながるような気もする。

コンサルやデータ分析会社の使い所の定義

上の話の裏返しで、内製・社員でカバーすべき範囲が決まれば、外注にどこまで頼るのか？という話である。

すぐには無理でも将来的に社員で対応していくことが想定される場合は、アルゴリズムやソースコードの著作権や改変の権利を放棄させるような契約が必要。
機械学習モデルをサブスク型で契約する等ははもってのほかである。。。

ただ、その場合は、値切らない方が良いと思う。
自分も受注側にいたので気持ちがわかるが、値切られるとやる気なくなる。

社内異動の人員要件の定義

DX推進組織のスキル定義にもよるが、ある程度アナリスト集団を目指すなら、社内から異動者の採用は、少なくとも大学以降に数学を勉強している人材が望ましいと思う。

∑や微分、ベクトルがわからない状態から実務に登場するアルゴリズムを理解するのは難しい。

自分でコーディングするような場面がなくても、例えば「次元圧縮」みたいな機構を理解する必要があるとき、上記知識がないと感覚的にやっていることを理解することはできないのではないかと思う。

以上。
連休中に一旦まとめられてよかった。

私でお役に立てることがあれば個別ご連絡ください。