超高速開発について考える

超高速開発について概要から、特長、課題までを7つの章に分けて解説します

1. システム開発にイノベーションを― 超高速開発とは

ビジネスのグローバル化やスピード化によって、企業をとりまくビジネス環境の変化に対して、よりタイムリーで、柔軟で、迅速な対応が求められる時代になってきています。

そんな企業のニーズに応え、経営判断や企業競争力を支える情報システムをよりビジネス成果に直結させるものとして、超高速開発が注目を集めています。

ここでは、その超高速開発とはどんなものか、従来の開発手法との違いやメリットなどについてご紹介します。

 

超高速開発とは

 

超高速開発とは、業務アプリケーションの開発工数を劇的に短縮する開発支援ツールをはじめ、開発手法なども含めて、システム開発により高い生産性をもたらし、従来のシステム開発が抱えている問題解決などに活用していく考え方、開発への取り組みのことを指しています。

 

従来の開発との違い

 

従来の開発では、業務サイドへのヒアリングから始まり、要件定義、仕様決定、基本設計、詳細設計、実装(コーディング)、テスト、リリース、運用、というように工程を追って開発が進んでいきます。

しかし、超高速開発では、コーディングやテストの工程を削減または自動化することで省略することができます。また、なにより大きな違いとして、従来のSIer主体の開発から、ユーザー(もしくは業務)サイドが主体となって開発を進められる(システムの内製化)だけでなく、SIerにとっても従来のような「人月ベース」のビジネスモデルから「ビジネス価値」への転換を推進するためのツールであるという点が挙げられます。

 

超高速開発のメリットとは

 

超高速開発は上記のとおり、開発工程の簡略化や自動化によって、開発期間や工数を短縮できます。それに伴い、わかりやすいところでは、人件費や設備費用など開発にかかるコストを削減できるというメリットがあります。

また、開発期間の短縮によって、ビジネス要件の変化に対応するシステムの更改をよりスピーディかつ柔軟に行うことができることも大きなメリットと言えるでしょう。

 

特に従来の開発においては、SIerなどのエンジニアやマネージャーが中心となって開発を進めることが多く、システム側からの視点でシステムが作られてしまい、業務要件からかけ離れてしまう、ユーザー(もしくは業務)サイド側から当事者意識が薄れ、結果としてシステムに求められる業務情報が伝わっていない、開発工程が終盤に差し掛かってから急な仕様変更が入る、といった業務サイドとシステムサイド間の情報の乖離や認識のずれから発生する問題を多く抱えていました。

ところが、超高速開発においては、開発工程の早い時期から実際に動きを確認できるプロトタイプをユーザー(もしくは業務)サイド確認しながら開発を進めることができるため、情報の乖離や認識のずれなどは起こりにくく、実際に業務に携わる人が開発に深く関わることで、より業務サイドの観点に立ったシステムを構築することができるのです。

 

2. 超高速開発ツールの特徴とは

 

超高速開発に欠かせないものといえば、ソースコード自動生成ツールや業務アプリケーションの実行エンジンを提供しているものなど、開発支援ツールが挙げられます。

最近では、単独の機能だけではなく、設計からテストまで、開発全体の工程を一括で管理できるような多くの機能を備えた超高速開発ツールが作られるようになり、様々な種類の超高速開発ツールが様々なベンダーから提供されています。

今回は超高速開発のキーとなる、超高速開発ツールについて説明していきます。

 

超高速開発ツールでできることとは

 

各種ツールによっても違いがありますが、超高速開発ツールが持っている主な機能としては、以下のようなものが挙げられます。

 

(1)仕様の管理

超高速開発ツールでは、ユーザーインターフェースとしての画面の要求仕様や、扱うデータのデータ仕様とその処理、システム上で行われる業務のフローなどの業務仕様をデータベースやリポジトリに格納し、変更管理・世代管理・履歴管理といった管理を行うことができます。

このような仕様管理機能によって、利用者は常に正しい仕様情報を把握することができ、急な仕様変更にも柔軟に対応することができます。

 

(2)コード自動生成型と、実行エンジン型

超高速開発ツールには、大きく分けて2つのタイプがあります。1つは、業務仕様情報に基づきシステムの設計からソースコードを自動で生成するコード自動生成型です。

もう1つは、リポジトリに定義されたアプリケーションのメタデータ情報をツール独自の実行エンジンで動作させる実行エンジン型です。

 

(3)テストの設計、自動実行

超高速開発ツールの中には、コーディングだけでなく、テストの設計や実施、結果の精査なども自動で行うことができるテスト自動化ツールもあります。

特にテストは、従来型の開発ではその工数の多くを占め、コストや納期を圧迫する大きな要素となっており、テスト自動化ツールによって生産性を向上する大きな要素となっています。

 

(4)ドキュメントの作成

従来型の開発においては、要件定義書、仕様書、設計書、テスト仕様書といった工程ごとの成果物として、また情報管理や開発の根拠となるものとして、各種のドキュメントを作成します。

しかし、超高速開発ツールによる開発では、それらの情報を全てデータベースやリポジトリで管理しているため、ドキュメントの作成のための工数を削減できます。

情報の可視化として、それらの情報をドキュメントのような形で出力できるものもあり、必要に応じてドキュメントを自動生成することもできるのです。

 

超高速開発ツールの特徴

 

超高速開発ツールの特徴として特に象徴的なものは、要求される業務仕様などの必要最小限の情報の入力を起点として、その後の情報や進捗の管理を全て一括で一元管理できることです。

それによって常に情報の整合性が保たれ、いつでも正しい情報が把握できるため、業務変更などによる仕様の変更などにも柔軟に対応できるのです。

 

3. 従来の開発における問題点

 

超高速開発ツールは、開発コストの増加やプロジェクトの長期化、開発・保守に携わる人材不足、情報管理の困難さやその後の運用や変更管理の難しさなど、従来型の開発が抱える多くの問題点が解消されることを期待されて生まれてきました。

それでは従来型の開発はどのような問題点を含んでいるのでしょうか。

従来型開発における問題点について考えていきましょう。

 

構築スピードの遅さ

 

従来型の開発方法では、システム構築に時間がかかってしまう多くの要因を抱えていました。

 

たとえば各工程での成果物などはドキュメントベースでプロジェクト内の情報共有や認識合わせを行うため、単純にドキュメントの作成や整備、その後の管理などに手間や時間がかかり、また、プロジェクト内での認識をそろえるために頻繁な打ち合わせや会議が必要となり、プロジェクトの遅れを招く原因となります。

 

また、開発において最も多くの期間を占めるテスト工程は、長い期間をとられるだけでなく、多くの工数=人件費=コストがかかることになります。

ほかにも、実際に出来上がるシステムのイメージをユーザーが把握できるのが、かなり後半の工程になってしまうため、開発終盤での大幅な仕様変更なども発生しやすく、さらに仕様変更にあたっては、設計工程までさかのぼって手戻りが発生し、ドキュメントやソースコード、テストといった各工程をやり直すこととなるため、大幅な工程遅れを引き起こすことになります。また、SIerはこのようなリスクをあらかじめ見込んで見積ります。これが多重下請け構造では、下請け開発会社がそれぞれリスクを多重に上乗せするためコストが膨れ上がるという現象も起きています。

 

このような成果物(ドキュメント)ベースの開発方法は、単に工程の遅延やコストの増加を引き起こすだけでなく、情報管理を困難にし、情報の整合性を保てなくなったり、ドキュメントが陳腐化して、実際の情報が失われてしまったり、といった弊害を引き起こす場合があります。

こういった情報管理に起因するリスクは、開発期間のみならず、その後の運用や改修時の変更管理などにも悪影響を与える可能性もあるのです。

 

バージョンアップへの対応

 

一時的にしか利用しないシステムでない限り、ハードウェアやOS、ミドルウェアのバージョンアップに伴って、システム自体も対応するよう継続的にバージョンアップを行っていく必要が発生します。

従来型の開発では、OSなどのバージョンアップや、新しいデバイス・システムへの対応も独自に行わなければならないため、新しい技術への対応やそれに応じたバージョンアップが遅れるといったリスクが考えられます。

さらには、一から独自に作り上げたシステムの場合、バージョンアップするたびに、開発したシステムの全ての機能を検証しなくてはならないため、検証の工数や期間が長くなってしまうこともリスクとなりえます。

また、従来型の開発手法では、SIerなどのエンジニアが主体となって開発を進めるため、開発を行ったエンジニアが異動や退職などでいなくなる際に十分な引き継ぎを行っていないと、システムがブラックボックス化してしまうという問題を抱えてしまうことにもなりかねません。

 

4. 超高速開発で変わる開発環境とは

 

超高速開発を取り入れることによって、開発環境にも変化が生じます。ここでは、超高速開発によって開発環境や開発工程がどのように変わっていくのかを考えていきましょう。

 

品質管理が容易になる

 

従来型の開発方法において、品質を管理するために行われてきたこととは、大量のドキュメントの作成とそれに対して行われる「レビュー→ドキュメント修正」の繰り返しでした。

ドキュメントを中心に進められる従来型の開発方法では、品質を維持するためには、多くのドキュメントを作成し、繰り返されるレビューとその指摘事項を反映することでドキュメントの精度を高めていく必要がありました。

 

大きな間接工数をかけてレビューを繰り返し、レビューの評価結果をまたドキュメントとしてまとめることで品質管理を行う、といういわゆる「管理のための管理」が必要となってしまっていたのです。

しかし超高速開発においては、リポジトリなどによって一定レベルの品質が担保されることになるため、繰り返し行われるレビューや大量のドキュメントは最小限におさえられます。

リポジトリに登録されている情報をチェックすることで簡単に品質管理することが可能になるのです。

 

テスト工程が一部自動化できる

 

従来型の開発におけるテスト工程では、開発したソフトウェアの実行や、ソースコードの検証を行い、システムが期待した通りに動作するかを確認します。

テストはバグの検出等、システムの品質を担保する上で非常に重要な工程です。高い品質を維持するためには、膨大なテストケースを想定し、単調で地道な繰り返し作業が必要となります。

そのため、テスト工程は開発全体の中でも非常に多くの作業工数を占める事になります。

特に品質を求めれば求めるほどテストケースは膨大になり、より多くのコストが必要となります。

 

さらには、開発の過程で仕様変更が生じた場合、テスト仕様の見直しや場合によってはテストのやり直しなどを余儀なくされることもあります。

しかしテスト自動化ツールを活用することで単体テストや、システム全体の動作を確認する統合テストでは、テストケースの設計やテストの実施まで自動で行うことが出来ます。

仕様の変更に対しても、テストケースの整合性やテストの再実行をツールが行ってくれるため、大きな手戻りやコストの増加を招くことはありません。

そして、テストの設計からテスト結果の統計までをリポジトリ上で管理できるため、テストの実施状況や結果などの情報を把握しやすくなります。

 

下流工程の作業負担が軽減できる

 

超高速開発では、扱うデータや機能の定義といった業務要件や、利用者に提供するインターフェースデザインのような実装要件など、基本設計情報をリポジトリに登録するだけで、業務用のアプリケーションやシステムを開発出来ることを最大の特徴としています。

それにより、「基本設計/詳細設計」・「プログラミングなどの実装」・「単体テスト/結合テスト」など、開発における下流工程の作業負担を大幅に軽減できる、という大きなメリットを持っています。

 

しかし、単に下流工程の作業負担を大幅に軽減できる、というだけでなく、それによって本来十分な時間を割くべきであった業務分析結果などの仕様情報をリポジトリに登録したり変更したりする作業が中心になってくるということです。

さらには、短期・低コストで開発を進められるため、最初の開発に要求事項の全てを盛り込む必要がなくなり、運用フェーズで改善していくことを前提に開発工程を組むことも可能になるのです。

 

5. 超高速開発で変わるシステム開発のプロジェクトマネジメントとは

 

超高速開発を取り入れることによって、システム開発の工程や進め方が変われば、それに合わせてプロジェクトマネジメントの方法も変わってきます。

従来型のシステム開発方法においては、プロジェクト内の情報共有などの情報管理や、スケジュール管理などの進捗管理、成果物の精査などによる品質管理などが重要視されてきました。

超高速開発では、実際にどのようなマネジメント要素が必要になってくるのでしょうか。

超高速開発で変わるシステム開発のプロジェクトマネジメントについて考えてみましょう。

 

品質管理

 

設計情報がリポジトリで管理されているため、その時点で設計情報の整合性が担保され、一定レベル以上の品質を維持することが可能となります。

プロジェクトの進捗やシステムの品質がリポジトリによって簡単に確認できるため、従来のようなレビュワーや有識者によるレビューの繰り返しによる品質管理ではなく、担当者自身がリポジトリを通して品質を確認することが出来ます。

ドキュメント中心の作成とコミットの繰り返しによる品質管理がなくなり、定期的なレビュー会などは不要になり、常にリアルタイムな品質確認・品質管理が可能になり、高い品質の維持が容易になります。

作業担当者自身が、品質管理責任者となることが可能となるのです。

 

組織体制

 

従来型のシステム開発では、システムの規模によっては大量の人員を投じ、労働集約的に各工程の作業を進める必要がありました。

そのため、各工程ごとにチームが分かれ、それぞれのチームを統括するリーダーが必要となります。

こうして作られた組織は、複雑な構造になり、管理・把握が難しいとともに、横の連携が弱く、情報や意識の共有・統一が非常に困難な体制であると言えるでしょう。

超高速開発では、従来型の開発手法に比べて組織は小規模でかつ相互の連携が発達したマトリックス型の組織体制とマネジメントが可能になります。

 

コミュニケーション

 

従来型のシステム開発では、プロジェクトの各工程において担当者がいて、それぞれの役割分担がはっきり分かれていました。そのため、ドキュメントを中心に、各個人の力を集約することでシステム開発を進めることになっていたのです。

しかし超高速開発においては、情報システム開発の技術的なハードルが下がり、業務担当者でも開発プロジェクトに関わることが出来るようになります。そのため、個人の技術や能力の集約ではなく、チームワークとしての作業が求められるようになるでしょう。

従来型の開発よりもさらに、プロジェクト内のコミュニケーションが重要になってくるのです。

また、小規模でかつ相互の連携が発達したマトリックス型の組織体制が必要になるため、横の連携が強く、活発にコミュニケーションを取り合うことのできる組織作りが必要となります。

 

6. 超高速開発で必要なスキル

 

超高速開発では、従来型の開発とは違い、設計やプログラミングといった知識やテクニカルスキルの必要性は一般的な開発言語に比べると低いとされています。

しかし、超高速開発でこそ活かされる能力や経験、スキルというものが存在します。それでは超高速開発に求められるスキルとはどのようなものなのでしょうか。超高速開発で必要となるスキルについて考えてみましょう。

 

業務分析のスキル

 

超高速開発では、実装(コーディング)、テストなどの下流工程はある程度削減され、業務情報を仕様としてリポジトリに登録する作業が中心となるため、プログラミングや設計手法などのスキルよりも、正確な業務知識や業務分析などのスキルが重要となってきます。

特にユーザーサイドに立った経営やビジネスについての知識や、ユーザー企業の抱える経営上の課題や方針についての分析力や考察力が必要とされるのです。

豊富な業務経験や、ユーザー企業のビジネス、経営方針などを正しく理解し、システムに反映させる能力が重要になります。

 

データ中心発想のスキル

 

従来型のシステム開発においては、システムの観点からのデータ取り扱いや処理という発想になりがちでしたが、超高速開発では、豊富な業務経験があり、そこからこのようなデータが望ましい、といったデータ中心の発想ができる人材が求められるようになります。

従来型のシステム開発では、業務要件がシステム要件になるだけでなく、システム上の都合が業務に影響を与えることも少なくなかったため、業務プロセスとビジネスルールを切り離すことができませんでした。

しかし、業務プロセスとビジネスルールを分離して管理することが、超高速開発においての重要な考え方となっているため、業務プロセス設計やビジネスルール設計といった、企業のビジネスの根幹となる知識やスキルが必要となるのです。

 

コミュニケーションのスキル

 

従来の労働集約型なシステム開発においては、ITスキルが高く、ドキュメントとの間で自己完結的に仕事を進めるタイプのエンジニアでも十分に役割を果たすことが出来ました。

しかし、超高速開発においては、チームワークで仕事を進められることが必要となってきます。

また、変更や改善を当然のこととして受け入れられることが必要になってきます。

従来型のシステム開発では、変更や改善は工数を増加させ、大きな負担となるものでした。

そのため、プロジェクトの置かれた状況によっては、変更や改善を受け入れることがプロジェクトの破綻を招くことになりかねませんでした。

一方、超高速開発では、変更や改善は必然としてとらえ、間違いの指摘や、変更要求を喜んで受け入れられる心や態度が重要なスキルとなってきます。また、相互の情報連携が活発なマトリックス型の組織体制が必要となります。

よりスピーディに情報を連携し、変化に対応していくためには、相手に共感する力や逆に共感を引き出すようなコミュニケーション能力が求められます。

従来型のシステム開発においても、コミュニケーション能力は必要とされてはいますが、超高速開発においては、違う観点からより重要な役割を果たすことになるのです。

 

7. 超高速開発における課題

 

超高速開発ツールは、コストの増大や開発期間の長期化、システムよりの発想による弊害など、従来型の開発が抱える多くの問題点を解消するために生まれてきました。しかし、超高速開発にも課題がないわけではありません。

それでは、超高速開発の抱える課題にはどのようなものがあるのでしょうか。ツールや人材、体制といった観点から、超高速開発が抱える課題について考えていきましょう。

 

ツールという限界

 

超高速開発では、設計や実装(コーディング)などの工程をツールに任せることになります。

そのため、ツールの想定を超える要求には対応できない、という課題をはらんでいます。

ツールに実装されていない機能は当然対応できませんし、そもそもあまりにもイレギュラーな要求まで想定するとなるとキリがなくなってしまいます。

汎用性や、利用する可能性の低い機能を実装したところで、本来超高速開発の強みである効率性には繋がりません。

開発する業務システムに合わせたツール選びや、超高速開発可能な業務プロセス設計などによる対策が重要となるかもしれません。

 

新しい人材育成のしくみ

 

超高速開発でも、設計や開発といったシステム開発の知識やスキルが不要になるわけではありません。

しかし、業務分析や業務プロセス設計、ビジネスルール設計といった、業務に沿った、経営よりの知識や経験がより重要となります。

特に業務経験などについては、各企業ごとに事情が異なり、ユーザー企業側で企業独自の人材育成が必要となります。

 

従来型のシステム開発のように、プログラミングや設計・構築のスキルをもった人材を育てる仕組みは確立されているため、比較的簡単に人材を育成することができますが、業務分析や業務プロセス設計、ビジネスルール設計といったスキルの教育方法はまだ確立されていないといっても過言ではありません。

そのためには、これまでになかった新しい人材育成のしくみが必要となるでしょう。

 

体制、意識の改革が必要

 

システム開発は大規模な体制を組んで、大量の人員を投入し、定められた期間内に完了させるプロジェクトタイプの仕事、という考え方が常識として浸透している現在において、小さくつくって大きく育てる、日常の運用業務の一環として改善していく、といった概念を理解し、実践していくには、根本的な意識改革が必要となります。

また、いままでSIer主体で進めてきたシステム開発をユーザー企業が主体となって進めるには、ITベンダーのみならず、ユーザー企業の意識改革が必要となります。

開発主体がユーザーサイドに変わるとともに、責任分解点も変わり、ITベンダーとユーザー企業間の契約モデルの見直しが必要となります。

 

しかし、工程ごとの多段階契約が主流であり、人月契約・多重下請け構造が当たり前となっている現在では、このような契約の見直しは大きな障壁となりかねません。

超高速開発を各企業が活用できる社会を実現するためには、IT業界のみならず、日本の社会全体を巻き込むような大きな意識改革が必要になるのかもしれません。