SIerはどう変わるべき？ 「下剋上」も夢じゃない、ユーザー企業のために獲得すべき技術とは：SIerはどこから来て、どこへ行くのか（2/2 ページ）

[室脇慶彦，SCSK株式会社]

「SoRは今のままでいい」？　刷新しなくてもいいシステムは存在するのか

　近年、SoE（System of Engagement）とSoR（System of Record）の二元論でIT施策を語る傾向がある（最近ではSoI《System of Insight》も議論になっているが、今回は割愛する）。「SoEこそが新たな技術適用であり、SoRは今のままでいい」と主張する有識者もいるが、これは正しいのか。

　筆者の理解によると、SoEとは、顧客との絆を作るために個々の顧客に合った商品を提案するためのシステムだ。「顧客ニーズには迅速、柔軟に対応することが必要だ。アジャイルが必要なのだ」という言説には筆者も同意する。

　しかし、顧客ニーズに対応するには、商品のバリエーションも含めて品揃（ぞろ）えを充実させる必要がある。新たな商品を迅速、柔軟に開発するだけでなく、商品管理システムも必要になる。商品管理システムとはSoRそのものだ。

　そもそもSoR全てが必ずしも非競争領域であるわけではない。業界に古くから存在する商品に関するSoRは非競争領域かもしれないが、新たな商品を管理するSoRシステムには柔軟でスピーディな対応が求められる。こういう意味で、新しい商品を管理するSoRシステムは競争領域にあると筆者は考えている。管理対象の商品が業界で成熟してコモディティ化するに従ってSoRも非競争領域になる。

　つまり、SoEもSoRも「車の両輪」で両方に改革が求められる。先ほどのような「SoEこそが新たな技術を適用すべきであり、SoRは今のままでいい」と主張する有識者は、SoRに関する問題を先送りしている。

　「IT負債」化した既存ITシステムを維持するコストがIT予算の8割を占める中で、新しい投資のためにも既存ITシステムを放置することは許されない。

　なぜSoEとSoRの話を出したかと言うと、 AI技術を活用したDXの実現は、IT負債化した既存ITシステムの変革抜きに進められないからだ。技術者の大半が既存ITシステムの変革を担える人材に変わることこそが、SIerに求められる技術変革の中心になる。筆者はこう考えている。

なぜ「アジャイル型開発」は主流にならないのか？

　ITシステム開発に関して近年議論になっているのが「アジャイル」だ。アジャイル型開発が今後、ソフトウェア開発の主流になることは間違いない。SIerがDXを推進するためにもアジャイル型開発は欠かせないものと考えている。しかし、日本のソフトウェア開発は、現状ではアジャイル型になっていない。これはなぜなのか。

　巷（ちまた）では、アジャイル型開発とウォーターフォール型開発が相反するものであるかのように議論されているが、筆者はそうは考えていない。そもそも、アジャイル型開発で一般的な「スクラム」は、一橋大学名誉教授で経済学者の野中 郁次郎氏が提唱したものだ。野中先生は著名な経営学者だが、ITの専門家ではない。スクラムについてもソフトウェア開発の方法論としてではなく、一般的な組織の在り方として提唱されたと認識している。

　つまりアジャイルは行動規範であり、ソフトウェアの開発方法論ではない。

　ウォーターフォール型開発モデルは要件定義から設計、開発、テストまでを順次実施し、工程ごとに成果物と終了基準を定義するソフトウェアの開発方法論だ。一方、アジャイル型の設計開発でも機能単位で要件定義した上で設計、開発、テストを実施する。

　つまり、ソフトウェアの開発方法論はどちらにしてもウォーターフォール型開発モデルなのだ。

　では何が問題なのか。日本では、ウォーターフォール型開発モデルと称して、さまざまな機能の要件定義、設計などを同じタイミングで終了させるようにプロジェクトマネジメントをしていることだ。すなわち問題はウォーターフォール型開発モデルではなく、現状のITシステム構築のプロジェクトマネジメントの手法にある。

　要件を決めなければ設計は不可能であり、設計しなければ開発も不可能だ。つまり日本のソフトウェア開発において、つまりソフトウェア開発において、アジャイルが主流になってもウォーターフォール型開発方法論がなくなることはない。

アジャイル開発が定着しない「最大の障壁」

　従来のプロジェクトマネジメントでは、なぜ要件定義を一斉に終了しなければならないのか。

　例えば、銀行のITシステムを作ろうとしたときに、まずは口座開設を定義する。口座の基本情報が定義されなければ、入金処理や口座情報の変更、口座の閉鎖も定義できない。さらに、入金処理を定義しなければ出金処理や定期預金の作成処理、口座引き落とし処理も定義できない。

　要件定義は、こうしたシステムを構成する各項目の関係を踏まえて順番に定義する必要がある。

　それにも関わらず、「全ての要件定義を同時に同レベルで作成しろ」という“無理な”マネジメントが行われてきたのはなぜか。後工程で起こるかもしれない要件変更を最小限にするために、一斉に仕様を確定させる必要があるからだ。

　実は、要件変更には簡単なものと、対応が難しく工数のかかるものがある。工数がかかるものは、主要なデータベースに影響するデータ項目の追加を伴う。主要データベースは多くの処理で参照され、更新される。主要データベースが修正されれば多くの処理に影響し、対応する範囲は広範囲に及ぶ。

　そのため、データベースのデータ項目を確定させてデータベースのスキーマを決定する必要がある。この後の工程でデータ項目に絡む変更が行われることを避けるためにも、要件定義を一斉に終了させなければならない。そうしないと、プロジェクト運営がままならなくなるのだ。

　つまり、現状のアプリケーションは、データベースを中心として各処理が密に結合した「モノリスシステム」になっている。この「モノリスシステム」こそが、アジャイルが日本に定着しない最大の障壁だと筆者は考える。

「ピザ2枚で満足する人数」で取り組む理由は？

　アジャイル型開発のスクラムでは、朝会・夕会を毎日実施するといった行動規範を求められる。約10人でチームが構成されている場合、1人当たりの報告にかかる時間を3分とすると約30分間で実施できる。日に換算すると約1時間の負荷になる。

　Amazon Web Services（AWS）には「ピザ2枚ルール」がある。ピザ2枚が行き渡る人数がアジャイル型開発のチームを構成する適正な人数だというものだ。これ以上の人数になるとチームが分割される。重要なのは、チームだけでなく担当するITシステムも疎結合に分割されることだ。つまり、「モノリスシステム」構造でないことがアジャイル型開発の必須条件なのである。

　日本の場合、小規模なITシステムはアジャイルで開発できるが、大規模システムをアジャイルで開発しようとすると、失敗するケースが多い。モノリスシステムは密結合であるため分割できない。大手SIerは「大規模アジャイル開発に取り組む」としているが、モノリスシステムの取り扱いが主であるSIerにおいて大規模アジャイル開発がうまくいった話を筆者は聞いたことがない。

　大規模アジャイル開発に取り組むチームの構成人数が30人であれば、朝会や夕会は1回当たり90分、1日当たり180分、つまり3時間かかることになる。これでは仕事にならない。モノリスシステムから抜け出さない限り、アジャイル型開発は失敗に終わる。これが、日本においてアジャイルが主流にならない最大の理由だと筆者は考えている。

　他にもアジャイルに対する誤解がはびこっている。「アジャイルでは、ドキュメントの整備よりも動作するソフトウェアの作成を重視する」がそれだろう。

　確かに、従来とは異なる開発方法を実践する17人のソフトウェア開発者が2001年に公開した「アジャイルソフトウェア開発宣言」には、「包括的なドキュメントよりも、動作するソフトウェアを」という文言がある。ただし、同宣言には「左記のことがら（包括的なドキュメント）に価値があることを認めながらも、私たちは右記のことがら（動くソフトウェア）により価値をおく」という注意書きがある。つまり、同宣言は「包括的なドキュメントには価値がない」とは言っていない。

　そもそもソフトウェアは「動いてなんぼ」の世界であり、優先順位が高いのは当たり前だ。開発の内容を複数人で共有するためにドキュメントの整備は必須だ。特にさまざまな人々に引き継ぎながら保守する場合は、ドキュメントの整備は極めて重要になる。

　情報系などスクラップ・アンド・ビルドが繰り返されるシステムでは、そもそもドキュメント化の必要性が低い。「包括的なドキュメントには価値がない」という言説が生まれたのは、初期のアジャイルの対象に情報系システムが比較的多かったことが影響したのかもしれない。

　いずれにしても、基幹系にアジャイルを適用する場合は、設計情報を標準化し、維持するのは当然だ。ただし、設計情報はドキュメント化というよりもリポジトリ化が必要だろう。設計情報が維持されないとITシステム開発の属人化が進むことになる。基幹系における属人化はまさにブラックボックス化であり、担当者の突然の退職などによって基幹業務の継続が危ぶまれる事態が起こり得る状況となるため、許されることではない。実際、米国でもアジャイル開発によってブラックボックス化、属人化が発生しているケースを目にする。

　ただし、事業や業務、ITの人材が自主的に一体となり、提供するサービスのレベルを継続的に向上させるためにアジャイルは必須の行動規範となる。同時に、ITシステムに求められ信頼性や可用性、拡張性といった特性に応じて、必要な情報の維持と「見える化」が求められる。「アジャイルソフトウェア開発宣言」を正しく理解して、アジャイルを実践することが求められる。

　次回は、SIerがITシステムの変革を進めるために必要な技術を取り上げる。特に重要な部分にフォーカスして深掘りしたいと考えている。

著者紹介：室脇慶彦（SCSK顧問）

むろわき　よしひこ：大阪大学基礎工学部卒。野村コンピュータシステム（現野村総合研究所）執行役員金融システム事業本部副本部長等を経て常務執行役員品質・生産革新本部長、理事。独立行政法人　情報処理推進機構　参与。2019年より現職。専門はITプロジェクトマネジメント、IT生産技術、年金制度など。総務省・経産省・内閣府の各種委員等、情報サービス産業協会理事等歴任。著書に『SIer企業の進む道』『プロフェッショナルPMの神髄』など。