今、システム開発の実態はどうなっているのか

2019年11月20日(水)
梅田 弘之(うめだ ひろゆき)

はじめに

本連載では、想定読者を次のような方々としています。

  • これから設計書も書くことになったプログラマー
  • もっと効率的な設計書の書き方を模索したいシステムエンジニア
  • 設計書の標準化を進めて、組織的に設計効率を上げたいリーダー
  • アジャイル開発における設計書のあり方に悩んでいるリーダー
  • 保守・運用コストが肥大化し、保守運用負荷を軽減したいマネージャー

今まで、なんとなく(見よう見まねで)設計書を作成していたという人も多いと思いますが、一度、原点に立ち戻ってシステム設計書を“書く意義”や“書き方”について見つめ直しましょう。そして、令和時代に合った良い設計書の書き方を理解し、自分の仕事に活かしてください。

第1回と第2回では、“設計書の書き方”に入る前に、現在のシステム開発についての全体像を解説します。

プログラミングの割合は3割以下

「システム開発と言えば、やっぱりプログラミングだよね」。はい、テレビドラマなどで超絶スピードでキーボードを叩いているエンジニアを観ている一般人にとっては、そうイメージするのも無理ありません。IT業界を目指す学生にしても「システム開発=プログラミング」と思っている人は少なくないでしょう。でも、実際のシステム開発は、要件定義や設計、テストなど他の工程の比重が大きく、プログラミングが占める割合は全体の1/3に満たないケースが多いのです。

では、残りの2/3はどんな作業があるのでしょうか。これは開発規模や開発手法によっても割合は変わるのですが、例えば64人月くらいの規模の基幹業務システムを、パッケージカスタマイズ&ウォーターフォール手法で開発する場合は、図1のような工数割合になります。

図1:システム開発の工数割合

このグラフを見て、「おや、1/3じゃなくて1/2だよね?」と思ったあなた。ゲームで相手の口(しゃみせん)に惑わされず、ちゃんとカードを読み取れるタイプですね。はい、このグラフだと確かにプログラミング工程は半分近いです。あれ、そもそもこのグラフ、合計が64人月に満たないじゃないですか。

実はこの矛盾は、図1の作業工数だけではシステムを開発できないことから来ています。実際のシステム開発では、要件定義や総合・運用テストという工程や、全体を通したプロジェクト管理の工数も必要になります。また、通常は本番稼働後のフォローにも人手を取られます。

では、これらの作業工数も含めた場合、各作業の割合はどのくらいになるでしょうか。

当社でERPシステム「GRANDIT」を使ってカスタマイズしているチームに工程別の作業工数をヒアリングしてみました。規模によって若干の違いはありますが、64人月くらいの規模ならば、下記のような目安で工数見積を行うそうです。これを加味した工数割合が図2です。自社の工数見積基準と比較してみてください。

開発工数(図1の合計工数)……43人月
要件定義工数:開発工数(図1の合計工数)の20%……8.6人月
総合(運用)テスト:開発工数(図1の合計工数)の10%……4.3人月
稼働後フォロー:総合テスト工数の50%……2.3人月
プロジェクト管理工数:上記全体の10%……5.8人月
上記合計64人月

図2:システム開発の工数割合(全体)

図1、2による設計工程(基本設計+詳細設計)の割合は、プログラミング・単体テストと同程度ですね。「工程が上流なほど重要」という原則を当てはめると、プログラミング・単体テストより比重は重いとも言えます。

JUASの調査でもプログラミングは3割以下

日本情報システム・ユーザー協会(JUAS)が公開している「ソフトウェアメトリックス2018年版(p.7)」にも工程(フェーズ)別工期比の調査データがあるので、比較してみましょう。

このp.7の2016年版合計欄の比率と図2の比率を対比してみると表1のようになります。JUASの調査が「要件定義からユーザー総合テストまでの工期を100%とした工期の割合」としていることを考慮すると、それほど大きく違っていないことが確認できます。

表1:工程別工数割合の比較

当社の見積(ERPカスタマイズ) JUASの調査
プロジェクト管理 9%
要件定義 13% 要件定義 20.1%
基本設計 14% 設計 25.1%
詳細設計 13%
プログラミング・単体テスト 31% 実装 27.8%
結合テスト 9% テスト 26.9%
総合テスト 7%
稼働後フォロー 4%
<<Memo>>プロジェクト管理工数と稼働後フォロー工数

昔のシステム開発では、プロジェクト管理に関わるスタッフの工数を明確に見積もっていないケースが多くありました。実際、プロジェクトリーダーが要件定義や設計作業をしながらプロジェクト管理作業を兼務することが多く、明確に項目を分けずに開発作業の中から捻出するのが普通でした。

プロジェクト管理の重要性が年々認識されるようになり、近年はプロジェクト管理担当を専任とするケースが増えました。それにつれ、工数見積でも明確にプロジェクト管理に関する作業と工数をきちんと提示するようになったのです。

これは稼働後フォロー工数も同様です。昔はカットオーバーまでの作業工数しか見積らなかったのですが、実際に“かかるものはかかる”ので、最近ではきちんと想定工数を見積って提示することが多くなっています。

新規システム開発の割合は3割以下

もう1つ、昔と今で変わったのがシステム投資の内訳です。新規システム開発の割合が6~7割以上あると思っている人もいますが、それははるか昔の話。近年は、保守・運用の負担が非常に重くなり、今では新規開発に回る割合は3割に満たない状態になっているのです。

いくつかのデータで確認してみましょう。日経XTECHが公開している2012年度の運用実態調査(IT関連コストの75%は稼働後に発生する)の図1を見ると、IT関連コストのうち新規開発に回せているのは24.3%しかなく、運用管理44.9%、保守開発30.8%よりも少ないことがわかります。

最近のデータでも、投資コストを保守・運用に取られている傾向は変わりません。ITRの「国内IT投資動向調査報告2017」を元にしたDIAMOND onlineの記事「デジタル時代のIT投資効果をどう見極めるか」の図2を見ると、新規投資は31%に過ぎません。また、ビジネス成長のための投資はその32%にしか過ぎず、業務効率化37%と業務継続31%の合計が68%を占めています。

新規開発に投資が回っていない状況は、ここ数年ほとんど変わりません。JUASの「企業IT動向調査」をIT Leadersがまとめた「「『IT予算の8割がシステム維持管理』が依然続き、沈みゆく日本のITユーザー/IT業界」図1のグラフからも、国内企業のIT投資が既存システムの維持管理に8割弱、新規開発2割強という傾向にほとんど変化がない様子が伺えます。

<<麻里ちゃんの設計奮闘記>>運用と保守って何が違うの?
  • 麻里あのぅ、さっきのIT関連コストで運用管理44.9%、保守開発30.8となっていますが、そもそも運用と保守ってどう分類するんですか。
  • 先輩:おお、それは良い質問だね。確かにこの2つは運用保守とか保守運用とか一緒にされることが多いものね。
  • 麻里はい、同じようなものって漠然と認識していたのに、いきなり違うってデータを示されて戸惑っています。
  • 先輩:どれどれ。うん、Weblio辞書によると『保守運用とは、主にITの分野においてコンピュータシステムやネットワークシステムの正常な稼働を維持するために行われる諸種の管理作業を総称する言い方である』となっているね。
  • 麻里ほら、ここでもやっぱり保守と運用を一緒にしているよね。
  • 先輩:でも、続いて、『保守運用は「保守」と「運用」を総合した言い方であり、保守と運用は基本的には区別される。システムの保守は、システムの変更・改良・更新・チューニング、あるいは不具合の修正といった、何らかの変更に伴う不測の事態を発生を抑止する取り組みを指す。
  • システムの運用は、定時に行うシステムの起動・停止・再起動やネットワークの監視、異状発生時の迅速な対処といった、正常な稼働を維持する取り組みを指す。「運用」が含む取り組みは幅広く、保守も運用に含まれる概念と捉えることもできる。』という記述もあるよ。
  • 麻里なるほど、やっぱり基本的には区別されるんだ。でも、まだちょっとピンと来ないなぁ。
  • 先輩:企業によっても定義が異なることがあるからね。じゃあ、問題。麻里ちゃんの彼氏が、週末に一緒に食事をしたり、週に1回は麻里ちゃんに電話したりするのはどっち?
  • 麻里え、なに、そのおやじっぽい例えは。え~と、うん、これはたぶん運用!
  • 先輩:ふんふん。じゃあ、麻里ちゃんがテンパったときとか、別れたいって言ったときに、すっ飛んで来て話しを聞いてくれるのは?
  • 麻里う~ん、じゃあ、こっちは保守。
  • 先輩:正解。正常に稼働しているかを確認してトラブルが起こらないようにするのが運用で、トラブル発生時に適切な対応をするのが保守って感じかな。
  • 麻里トラブルって何よ! 失礼しちゃうわ。
  • 先輩:麻里ちゃんが寂しくないか気に掛ける(システムの監視)は運用、維持のためにプレゼント(システムのアップデート)するのは保守。
  • 麻里ちょっとぉ、、、もう、その例え、やめてください。っていうか、かえって分かりにくいです。変な例えをした埋め合わせで、先輩も私に保守してくださいよ。
  • 先輩:おっと、そう来たか(にやにや)。じゃあ、今度、イタ飯でも食べに行こうか。
  • 麻里イタ飯なんて言う時点で、もう情けないほどおやじ入っているよね、先輩!

運用費と保守費の内訳

麻里ちゃんと先輩の掛け合いでイマイチよくわからなかった人のために、具体的に運用と保守の違いを見ていきましょう。ちょっと古いですが、JEITA(電子情報技術産業協会)が公開している「ソリューションサービスに関する調査報告書Ⅰ」の図2-4を見てみましょう。これによると、2008年度のIT投資の比率は新規システム投資が28.6%、既存システム保守運用が71.4%と、ここでも上記と同様の割合になっています。

この報告書では、保守運用の内訳として運用費が38.2%、保守費が33.2%となっています。抱えている要員の人件費を運用と保守に区分けした上で、償却費は運用、保守料金は保守に分類されています。

【運用費】38.2%
―ソフトウェア/ハードウェア償却費 20.1%
 ソフトウェア償却費(10.7%)
 ハードウェア償却費(9.4%)
―運用人件費 11.7%
 内部要員人件費の運用(7.2%)
 運用外部委託費(4.5%)
―その他 6.4%

【保守費】33.2%
―ソフトウェア/ハードウェア保守費 24.1%
 ソフトウェア保守費(12.0%)
 ハードウェア保守費(12.1%)
―保守人件費 9.1%

運用費と保守費の具体的項目

日経XTECHが公開している「コスト削減の標的は保守サポート費とライセンス料」の図1のグラフで運用管理コスト44.9%の内訳が示されています。これを表2のように整理してみると、前述のJEITAの記事で運用費としている費目がどのような内容なのか具体的に理解できると思います。

表2:運用コストの内訳表

費用 内訳(運用) 内訳(全体)
人件費 22.3 10.0
保守サポート費 17.0 7.6
リース料 11.5 5.2
減価償却費 11.2 5.0
業務委託費/外注費(データセンター/クラウド) 9.5 4.3
ライセンス料 8.3 3.7
業務委託費/外注費(常駐SE費用) 7.3 3.3
オフィス/施設費/電気料金/通信費 7.2 3.2
固定資産税 2.7 1.2
その他 3.0 1.3
合計(%) 100 44.9

保守業務の方も、具体的な作業内容を見てみましょう。先ほども紹介したJUASの調査「ソフトウェアメトリックス2018年版」のp.28にある「保守作業割合の分布表」によると、工数の多い順に、ユーザーからの問い合わせ対応、改良保守、是正保守(バグ修正)、適用保守、基盤整備、予防保守、完全化保守などが主な保守業務となっています。

とは言っても、「何を保守として取り扱っているか」は各社まちまちのようです(p.30)。ちなみに、当社の定義は「対応案件の内容に基づき判断しており、対応工数・対応要員数に依存しない」です。

開発費と保守費の割合を年間投資コスト単位ではなく案件単位でも見てみましょう。JUASが調査した投資案件の新規開発費用と5年間累計保守費用を比較したデータです。p.36の図表7-72によると、新規開発費(初期費用)と5年間費用は、ほぼ1対1となっています。これを複数年度でならしてゆくと、前述した日経XTECHの2012年度の運用実態調査のように新規開発と保守開発が近い値になるわけです。

おわりに

第1回の今回は、いくつかの統計データをベースに、システム開発における設計や他の工程の比重を理解するとともに、新規開発よりも運用・保守の方にコストがかけられている実態を紹介しました。次回も引き続き本題に入る前の予備知識として、システム開発におけるドキュメント体系や令和時代のシステム開発の状況について解説します。

著者
梅田 弘之(うめだ ひろゆき)
株式会社システムインテグレータ

東芝、SCSKを経て1995年に株式会社システムインテグレータを設立し、現在、代表取締役会長。2006年東証マザーズ、2014年東証第一部、2019年東証スタンダード上場。

前職で日本最初のERP「ProActive」を作った後に独立し、日本初のECパッケージ「SI Web Shopping」や開発支援ツール「SI Object Browser」を開発。日本初のWebベースのERP「GRANDIT」をコンソーシアム方式で開発し、統合型プロジェクト管理システム「SI Object Browser PM」など、独創的なアイデアの製品を次々とリリース。

主な著書に「Oracle8入門」シリーズや「SQL Server7.0徹底入門」、「実践SQL」などのRDBMS系、「グラス片手にデータベース設計入門」シリーズや「パッケージから学ぶ4大分野の業務知識」などの業務知識系、「実践!プロジェクト管理入門」シリーズ、「統合型プロジェクト管理のススメ」などのプロジェクト管理系、最近ではThink ITの連載をまとめた「これからのSIerの話をしよう」「エンジニアなら知っておきたいAIのキホン」「エンジニアなら知っておきたい システム設計とドキュメント」「徹底攻略 JSTQB」を刊行。

「日本のITの近代化」と「日本のITを世界に」の2つのテーマをライフワークに掲げている。

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています