皆様こんにちは、株式会社コアブリッジの柳です。
デジタル庁発足、システム障害の続発で業務改善命令、など、ITに関する大きな話題が連日報道されています。
知るや知らざるや日常のありとあらゆるものが”システム”化されて生活の基盤になっており、それを基に生活している以上は、システムというものの特性(特に短所や難しさ)や、それをどうやって作り上げていくのかという最低限の知識と無縁ではいられません。今回は「システム開発」について述べてみます。

システムとは

システム(System)とは”体系”のことで、複数の要素が一つに集まって機能しているものを指します。太陽系(Solar system)が一例です。
今日ではコンピュータを使ったシステム(computer system)の意味で使われることも多いですが、実際にはコンピュータだけで完結することはなく、何らかの形で必ず”人”が介在します。
システムを使っているのが人である以上、そして、例えばそれが企業の情報システムの場合に、複数の社員が共同して業務にあたっている場合、人による入力、選択、判断などが入ります。
システムを作る段においては、「システムに何をやらせたいか」(※これをシステム要件(System requirements)と言います)を決めるのは人間で、これを明確に決めない限りはシステム開発はできません。
よしんば、なんとか出来上がったとしても期待通りに動くものではありません。システム構築の発端である「システム要件を決めること」、これが何にもまして重要（そして難しい！）なのです。
以前、あるシステム会社の部長さんのお話で
「システム化により、自分の業務がリスクや変化なしに全て楽になると思い込んでいる人がなんと多いことか…そんな魔法はないという現実をシステム屋は啓蒙していかなければならない」
とありました。全くもって同感です。
こと要件定義、すなわち、「システムに何をやらせたいのか」の決定はシステムの利用者（発注者）が何をしたいのかに極めて大きく依存し、開発者だけでは決められません。ここが大事なところです。
あくまで説明上の例ですが、企業の合併により新システムを構築する際に、複数社の業務のやり方自体を整理しそれをシステム化する、あるいはどこか一社の業務方法とシステムに統一する、という戦略とその実行が必要不可欠で、システム(開発者)だけでどうにかなるなどというのはとんでもない妄想です。
その事実だけでも、システムを作る前と出来上がった後にもやることが山ほどあるというのは想像に易いでしょう。

システム開発＝プログラミングではない

前回は”プログラミング”について述べました。システム開発＝プログラムを作ること、と思う方も多いかもしれません。最終的にはプログラム化するので間違いではないのですが、その前後に実施すべきことがごまんとあります。
システムの開発手法は色々とあり、方法論によって差異はあるのですが、一般には複数の工程（開発工程と呼びます）を踏んで進めていきます。モノを作るのは、何だってそうですね。
工程の呼び方や区切り方、何をするのかは開発組織でまちまち(宗教戦争があるくらいです…)ですが、ここでは引用する統計データ(後述)に合わせて、「要件定義」「基本設計」「詳細設計」「製作」「結合テスト」「総合テスト」の六工程で話を進めます。
各工程の概要は以下の通りです。

　要件定義：システムに何をやらせるのかを決める
　基本設計：要件実現のためにどのようなシステム構成や方式にするのかを決める
　詳細設計：システムを小さな部品に分解し部品の役割を決定する
　製作　　：プログラム作成＋小さな部品単位での動作確認(＝単体テスト)
　結合テスト：小さな部品を結合した状態で動作確認を行う
　総合テスト：完成品としての動作確認を行う

上述のように、プログラミングは『製作』に含まれます。
では、ここでクイズです。プログラミング(製作)が全開発工程に占める期間の割合はどれくらいだと思いますか？
答えは、およそ『20%』です。思っていたよりもだいぶ少ないのではないでしょうか？
厳密にいうと、この統計データの『製作』は「プログラミング＋単体テスト」と解釈され、「単体テスト」を除くと、実際の数字はさらに小さいです。
この数字は「期間」比率ですが、工数（マンパワー）比率にするともう少し大きくはなります。
各工程に割り当てる人の数は均一ではなく、上流工程は少人数で実施し、製作近辺の工程は人数を増やす（外部委託を多く使う）ことが多いので、工数比率にするとおよそ『30%』くらいになります。それでも想像よりも小さいのではないでしょうか。
では、他の工程がどれくらいか、統計データから算出したざっくりとした数字（※当方で複数のデータから算出した値です）を載せておくと、以下の通りです（※数値を５％単位に丸めています）。

　◆期間の割合
　　・要件定義　：15%
　　・基本設計　：20%
　　・詳細設計　：15%
　　・製作　　　：20%　※単体テスト込み
　　・結合テスト：15%
　　・総合テスト：15%
　
　◆工数の割合
　　・要件定義　：10%
　　・基本設計　：15%
　　・詳細設計　：15%
　　・製作　　　：30%　※単体テスト込み
　　・結合テスト：20%
　　・総合テスト：15%

実際には、上記の「総合テスト」の後に、利用者(顧客)側が実施する「総合テスト2（受入れテストとか運用テストとか呼ばれます）」も実施するのが常のため、さらに期間や工数がかかります。

※上記の数値は、独立行政法人情報処理推進機構「ソフトウェア開発データ白書2018-2019」https://www.ipa.go.jp/ikc/our_activities/rs_04.htmlP.178-183の「新規開発」「改良開発」「再開発」各データの”中央値”を基に、要件定義工程も含めた比率として算出し、それらの平均をざっくりと求めたものです

デジタル化からDX(Digital Transformation)へ

“DX”という言葉も毎日のように見聞きします。DXの説明は別の回にするとして、システムに何をやらせるか、を考える時に、日々の業務やサービス、あるいは事業と無関係なはずがありません。システムも業務も、変革や最適化していく必要があります。
これを行うのが”DX”で、旧来のデジタル化(＝システム化)から、ビジネス観点に重点が移ってきたのです。もはやITは技術者だけにとどまらず、業務視点、事業視点でも不可欠となり、IT人材の獲得・育成・確保が声高に叫ばれているのは時代の趨勢なのです。

今号は以上です。
では、また次回お会いしましょう。

※本文中の情報、状況、数値等は執筆時点のものです