DX時代の開発案件の受付方

DX時代に開発を進めるにあたり、情報システム部がとか事業部がとか、SORとかSOEとか色々な切り口で会話をされているように思う。この不毛な議論を収束させたいと考え、1つのフレームワークを作った。ポイントは、新規 or 既存、Needs or Seedsです。この2軸で役割分担を行い、その間をお互い埋めて、開発の優先順位付けをしていくことが重要である。

枠組みのイメージ図

既存 × Needs

既存システム×Needs、それらのUpdateやRebornは、ドメインスキルが重要であるため、いわゆる情報システム部がリードするとうまく進む。複雑になっている既存システムを「改善」するには彼らの力が必要。情シス内の部課長が担当している場合が多い。

既存システムのSeeds系

情報システム部の本当のエンジニア、または、既にDigitalサービスを行っている人、場合によっては外部のSIer等、技術Orientedで出来る事をベースに進めるとうまく進む。最新の技術を知っている人が今のシステムを「改革」するような場合は、このアプローチが効く。ベテランエンジニアが担当をしている場合が多い。

新規 × Needs

これはカスタマーサクセスチームを立ち上げて、そこに情報を一元化するのが望ましい。何故ならこれから作る新しいDXの仕組みの情報を一元化して、新しいビジネス×ITアーキテクチャを作るためには、彼らがクッション役になるしかない。かなり根性のいる仕事のはず。Presalesやコンサル的人材がココを担当している場合が多い。

新規× Seeds

これは最も難易度が高いやつ。私の会社でいうとSmartCity研究所。Seedsが自社の持つノウハウや人、コンテンツ、その他資産と組み合わせて、他社と比べて優位性が継続する確率が高いと思えるSeedsを見つけるのは難しい。AIやBigdataあたりでこのような会話が盛り上がるが、なかなか成功しない。凄腕アーキテクトがここを担当している場合が多い。

これらを俯瞰すると、人材は適材適所であることがわかる。ベテランを活かして、営業マインドを持った人材を前面に出し、技術に深い知見を持った内外の人材を最大限活用する、これがDX時代の開発案件の受け方である。