読者です 読者をやめる 読者になる 読者になる

NTTデータの本気度に注目しています

私はかねてよりNTTデータの動向に注目しています。国内トップクラスのエンタープライズアプリケーション開発実績を持つ同社ですが、大規模開発につきものの「多重下請け構造」問題をいかにして解決するかというテーマに対して、自動化の推進を標榜しているためです。その同社について、注目すべきニュースがありました。

「NTTデータが開発環境をクラウドで義務付け」
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/021500827/

タイトルにはクラウドという言葉が含まれていますが、そこは重要ではないと考えています。

2019年3月をめどに新規のプロジェクトで、100%の利用率を目指す。原則として統合開発クラウドを利用させる、いわゆる「義務付け」となる格好だ。

とあり、ニュースの本質は、TERASOLUNA の利用義務付けです。ちなみに TERASOLUNA というのは Spring ベースのフレームワークで、適用領域はエンタープライズアプリケーション分野です。

TERASOLUNAの適用先は、情報の記録が主なSoR(システム・オブ・レコード)と呼ばれる領域。ERP(統合基幹業務システム)やCRM(顧客情報管理)といった基幹系システムのプロジェクト向けだ。

さて、この記事には、開発者にとって突っ込みたくなる一文があります。

開発の生産性は、人月当たりにどれだけのプログラムステップ数を作成できるかを指標としている。

「今時ステップ数とは(笑)」と揶揄したくなる気持ちはわかります。しかし私は違う観点でとらえました。なぜ、これを指標としているのか。実はこの記事には触れられていませんが、同社が TERASOLUNA をベースとした自動生成技術を持っていることは公然の事実です。私にとってこのニュースは、今後、新規のプロジェクトは自動生成技術の適用を前提とするという宣言であると受け止めました。そしてステップ数指標とは、過去数十年のプロジェクト経験から割り出された「人間による」開発生産性の数値を土台に、自動生成技術がその何倍の生産性を出すかを*社内に*アピールするためではないか、と解釈しています。

今、大規模エンタープライズアプリケーション開発では、以前のように大量の開発者を抱えることが難しくなっています。デスマーチという負のイメージによって優秀な技術者は大規模開発を敬遠します。さらに少子化が拍車をかけ、開発者の絶対数が不足することも明白です。オフショア開発にしても、今後は日本向けの特殊な受託開発ではなく、自国向けの開発やネットサービスに比重が移ることでしょう。そのような状況で大規模開発を行い、かつ、数十年という期間、保守を行うためには「少人数で、大規模開発」をいかにして実現するか、が鍵となります。開発工程の自動化技術は、そのコンセプトを支える基盤技術です。

同業他社への影響

さて業界最大手である同社の取り組みの意義は大きく、多くの同業他社にとって刺激となります。このニュースの行間にあるポイントを、私なりに洗い出してみました。

適用できる分野を増やす = 適用できない業務は受注しない

「100% の利用率」とは、適用できない(新規)業務は受注しないということを意味します。つまり「何でもやります」ではなく、得意な開発領域を絞り込み、受注プロジェクトを選別します。これはゆくゆくは、お客様を選ぶということになります。現場の営業からは当然、反対の声があがるでしょう。それでもこの方針でいく、となったとき、社内文化が大きく変わるのではないかと思います。

SoR と SoE で開発方法が異なっても、一つのシステムとして捉える

このニュースにあるように、SoR 分野と SoE 分野で開発ツールが異なっています。今後の SI ビジネスは、一社で両分野を抱える場合でも開発方法は異なることがはっきりとわかります。規模の違いはあっても、同業他社も同じようにそれぞれの分野における「武器 (=開発方法)」を持つようになるでしょう。しかし両者は開発方法は別でも、お客様からみたときは「一つ(のシステム)」です。よって開発側としては「SoR と SoE をどうつなげるか」も意識しながら取り組んでいくことになります。

具体的には、SoR 分野での「開発の自動化」と、SoE 分野での「アジャイル開発」をつなげる全体的な枠組みを考える、ということになるでしょう。難しい挑戦ですが、やりがいはあります。

2020年には、勝敗はついている

時期も重要です。同社は少なくとも「2019年3月をめどに新規のプロジェクトで、100%の利用率」を掲げました。これは同業他社にとって締め切りを提示された形です。2019年までに我が社の方針を定めておこう、では間に合いません。 一つの目安は2017年中に (1) SoR と SoE の両分野についての受注計画と体制を固める。(2) SoR については開発の自動化を念頭におく。(3) SoR と SoE の連携を行う枠組みを整える、ことです。できれば2017から2018年に試験プロジェクトを経て先行するチームを育成し、2019年には複数プロジェクトで社内展開、そして2020年は新しい枠組みでの受注を本格化させていることが経営者の観点になるでしょう。2020年には、勝敗はついている、ということです。


このように俯瞰すると、長らく問題視されてきた大規模エンタープライズアプリケーション開発の多重下請け構造も、あとわずかではないかと思います。もちろん既存システムの保守という観点からは延命しますが、それも10年はもたないでしょうし、市場規模は先細りです。そして SoE 分野ではアジャイル型が主流であり、多重下請け構造は最初からマッチしません。この構造改革を経て、SoR 分野からデスマーチという概念が過去のものとなり、変わって新しい魅力が備わることを願っています。

Wagby開発スタッフ募集中です!