DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ゴールデンウイーク明けのブログは、長い休暇で煮詰まった頭を空っぽにしたところで初心に戻り、ITアーキテクチャの必要性について再考してみたい。過去を振り返ること２０年余り、１９９０年代前半までの企業システムには手付かずのフロンティア領域が多く存在していた。この頃、社内システム部門に所属していた私は、PM支援とデータアーキテクト（当時はそんな呼び名もない）の二足のわらじを履いていた。ちなみにPMはユーザ部門代表の１名が通例。私の仕事の比率は圧倒的にアーキテクトが大きかった。プロジェクトの完成は当たり前であり、如何に“いけてる“プロダクト（社内システム）を創るか？に全身全霊を傾けていたように思う。

かわって２０年後の今、システム開発は周辺システムを除き、基幹系のフロンティア領域は減り、再構築（基本的ビジネス要件は変わらないがITは刷新）が主流となった。１０数年のメンテ期間を経て肥大化したシステムはブラックボックス化を招き、再構築に適用する新たなITはその専門性において外部ベンダーに頼らざるを得なくなった。専門性の分化、適用技術の多様化、既存システムの複雑化などを背景に、プロジェクト成功の難易度は格段に高まり、そこでのプロジェクトマネジメント技術が必須となる。もはや片手間でPMが出来るなんぞはあり得ない。それどころかPMを管理するPMOまで登場してきた。にもかかわらず、企業システムはROIを得られないまま、カオスへと向かっている。

さて、このような様相を呈している今日、システム開発のどこが問題なのであろうか？私にはどうも、プロジェクトの成功を重視するあまり、プロダクトの成功が軽視されているように思えてならない。それは本来のモノづくりの楽しさも削ぎ落としかねない勢いである。ここでプロダクトとは出来上がるシステムそのものを指し、その成功とは、どこかの品質管理の教科書にある“バグのないシステム”のことではなく、ビジネス活動に良い影響をもたらす“魅力的なシステム”のことを言っている。そして、プロダクトの成功にはライフサイクル全体のROIや他システムとの調和が前提条件で、１プロジェクトの成功とは次元が異なるものだ。

このような状況に陥った原因は、アウトソーシング領域の誤り、ガバナンス機構の不在、ユーザ企業側の手配師化、SIベンダーの逞しさ（笑）などいろいろ上げられるが、最たるものがアーキテクチャ（設計思想）の不在である。それは「どんな企業システムの構造にしたいか？」をひたすら考える“社内アーキテクト”が不在なことに起因する。理想的には社内でITアーキテクトを育成することである。以前も書いたが、企業システムはコモディティではなく、企業独自のビジネスモデルに即した世界でオンリーワンの注文生産品である。言ってみれば建築の世界での”作品”に相当する。それにはベンダーSEより自社ビジネスを熟知している社内SEが適していることは言うまでもない。譲りに譲って、社内アーキテクトの育成が困難な場合は、その重要性を理解した者が、ユーザ企業側の立場に立った専属アーキテクトをプロジェクトに依存せずに雇うことでも代替可能であろう。

今後のシステム開発におけるアウトソース形態は、かつての丸投げ請負での炎上の反省から、準委任契約にシフトしてゆくことが予期され、そうなればなおさらプロダクトの質に注視しなければならなくなるであろう。なぜなら、ベンダー側はプロジェクトを納期通り完了することを優先して、体よくプロジェクトをまとめることに奔走することが予見されるからだ。「プロジェクトが炎上せずに完了すれば”失敗”と言わない」ことが通例となってきたことが既にその予兆と捉えて良い。

２１世紀の企業システム及び情報システム部門が、ビジネス遂行部門にとって信頼できる強力なパートナーであり続けるためには、プロジェクトの成功も（投資をドブに捨てない為には）大事だが、それ以上にプロダクトの質（＝出来映え）にこだわらなければならない。また、このことはベンダー側のSIサービスのあり方についても、従来の人海戦術によるマスプロダクションから、少数精鋭型の質の高いソフトウエア開発にシフトすることが求められる。極端に言えば、”やらされ感”のもとで”やっつけ仕事”をするアーキテクトに設計を任せたくないと誰もが思うだろう。世界に１つしかない作品をこしらえるシステム開発は、楽しく創造的でなければならない。そして、”管理”はモノ作りが面白すぎて暴走しない為に機能させたいものだ。