このコラムは、株式会社エル・ティー・エスのLTSコラムとして2016年3月に掲載されたものを移設したものです。
ライター
前回「前編：実は「超高速」じゃない超高速開発」では、超高速開発の特徴とメリットを中心にお話しました。今回のコラムは、LTSで行うシステム導入に際して超高速開発とパッケージ開発の両面から調査を行ったことがきっかけです。しかし、このプロジェクトでは結果的に超高速開発ツールの適用は見送りました。これはどのような判断に基づくものだったのでしょうか？今回は、超高速開発の注意点と、パッケージ開発と比較した際の向くシーン/向かないシーンについてお話してみたいと思います。
超高速開発で気を付けること
前回のコラムに記したような超高速開発のメリットを聞くと、すぐにも活用してみたくなりますが、調査する中でいくつか注意点も見えてきました。
活用するツールをしっかり選定すること
「超高速開発ツール」と一言で言ってもその種類は実に多岐に渡ります。その特徴はツールによって千差万別で、出来ることと出来ないことに大きな差があり、ツールの選定は慎重に行う必要があります。
ツール間の最も大きな違いは自動化範囲で、概念設計（基本設計）から詳細設計、プログラミング、テストまでを含むかなり広い範囲を自動化するツールから、テストだけを自動化する範囲の狭いツールまで様々です。最も普及しているのは詳細設計からプログラミング、そして初期的なテストまでを自動化するツールで、画面仕様、画面遷移、業務処理の論理、情報（データ）項目のそれぞれを入力することで、自動的に画面、プログラム、DBを生成してくれるものです。
自動化範囲以外でもツールによって異なる機能は多々あります。一例として画面（GUI）の設計自由度があげられます。ツールによって画面を自由に設計できるものと、一定の条件を指定することで自動的に画面を生成するものに分かれます。ほかにも対応できる業務処理の複雑さ、生成したコードの出力有無、バッチ処理の有無といった点でツール間の違いが見られます。
柔軟性が高いツールが良いかというと必ずしもそうではありません。柔軟性が高ければ高い程、設定しなければいけない項目も増え、設定時に必要とされる技術的なリテラシ（例えばプログラミング言語への知識）も高くなる傾向にあります。そもそも柔軟性を高めれば高めようとするほど、本来のカスタム開発の方式に近くなるので、自動化をして効率化する余地が高いツール程かゆいところに手が届かなくなるのは仕方がないとも言えます。実際の選定ではこのバランスに注意する必要があります。
ツール選定が重要な理由はこのような機能性だけではありません。総じて超高速開発ツールの仕様はそれぞれのツールを開発したメーカーの独自仕様です。よって異なる開発ツール間での設計情報やプログラムの互換性はなく、一度特定の超高速開発ツールで開発を行った場合は、同じツールで開発（保守）を行うことが前提となります。基本的に「オープン性」「互換性」はないと考えた方が良いでしょう。この観点からもツールの選定は長期的視野で慎重に行う必要があります。
システム企画と要件定義の手間は変わらない
先ほどツールの自動化範囲はツールによって差があると書きましたが、ほとんどのツールで詳細設計に近いレベルまでの作業をユーザー自身で実施する必要があります。よっていくらツールを活用してもシステム企画から要件定義、そして設計にかかる負荷はこれまでのカスタム開発における負荷と大差ありません。要求機能が標準機能と大きな差異がなければ、パラメータの設定とデータの移行を行えば導入可能なパッケージソフトウェアと比べて、開発期間及び期間中の人員の拘束コストは高くなるケースが大半です。超高速開発ツールの価格は、大半のパッケージソフトウェアよりもかなり安いですが、このような人件費を考えると必ずしも安いとも言えません。よって、業務への適合率の大きいパッケージソフトウェアが市場に存在する場合のシステム導入の迅速性は、パッケージ開発に分があります。
さらに考えなくてはならないのがシステムの品質です。パッケージソフトウェアは新製品でもない限り、稼働実績があり一定の品質は担保されています。ところが超高速開発の場合は、設計を一から自分達で行うわけですから、設計品質がそのままシステムの品質に反映されます。よって設計の見落としやミスによる、システムのバグや誤作動と言ったリスクは高くなります。
ただしこのパッケージ開発の優位性はパッケージソフトウェアの業務への適合率が高く、カスタマイズやアドオンを行わない前提があればこそです。カスタマイズやアドオンを行えば行うほど、条件は同じか、場合によっては超高速開発の方が優位になるということもあり得ます。
その他の考慮点
「プログラミングの自動化」というキーワードから、SEに必要とされるプログラミング等のITの基本技術スキルを持たなくてもシステム開発が可能なのではないか、という期待を持つ人がいるようです。これについては自動化範囲がツールによって全く違うので一概に言えませんが、一部の簡易なアプリケーションを生成するツールを除いて、過度な期待は禁物です。開発者に一定のプログラミング経験があることが前提となっているツールもありますし、開発にプログラミング知識を必要としないツールでも、ツールが自動生成したプログラムを微修正するケースや、周辺システムのインターフェースを構築する際などに一定の技術スキルが必要になります。全体的に「システムエンジニアが必要なくなるツール」ではなく「システムエンジニアがポイントを絞ってより効果的に関与できるようになるツール」程度に考える方が適切です。
その他の注意点としては、SNSのような近年のウェブサイトで提供される高いユーザビリティを実現するツールは見つかっておらず、生成される画面の使い勝手は過去20年の一般的な業務システムと大差ないこともお伝えしておきます。
パッケージ開発か？超高速開発か？
さて、このような注意点を考えた上で、実際のプロジェクトではどのように開発手法を選定していくべきなのでしょうか？
まず超高速開発ツールが対象としていない超大規模開発や複雑な処理が必要なシステムについては一旦、対象外としておきます。その上で、業務の特殊性が強くパッケージソフトウェアが市場に流通していない、エンドユーザーの要求実現の要望が強くパッケージソフトウェアではカスタマイズが多くなることが見込まれる、業務が頻繁に変わり稼働後の保守（仕様変更）が多発することが見込まれるといったケースであれば超高速開発ツールを検討する余地は十分にあります。
逆に言えば、業務への適合率が十分に高いパッケージソフトウェアやクラウドサービスが市場に流通している、消費者向けのサイトなど高いユーザビリティが必要とされる、最新の技術を利用したいといったケースでは必ずしも超高速開発は適切ではないでしょう。
LTSが今回の調査のきっかけとなったシステム導入で超高速開発ツールを見送った最大の理由は、対象業務領域が顧客との受発注に伴う書類事務や顧客情報の管理など、いわゆる販売管理の領域であり、市場に多くのパッケージソフトウェアやクラウドサービスの選択肢が存在したためです。幸いにして、中には弊社のようなコンサルティングビジネスに適したソフトウェアもありました。
このようなことを考えると、一般的な企業内の業務支援システムの構築におけるソリューションの検討の順番は、まず適合率の高いパッケージソフトウェアの有無を調査し、もし良いパッケージがなければ超高速開発を検討するという流れになるでしょう。業界特有の業務で特殊性が高く、どう考えても適合するパッケージが市場にないようなケースであれば、はじめから超高速開発を検討するのも良いかもしれません。
ここで少し考慮が必要なのが、業務領域としては一般的だが、自社の業務が業界標準と差異が大きい場合や、ユーザーの要望が多様でパッケージだと適合率が低くなる懸念がある場合に超高速開発を適用するかどうかです。基本的にはこのようなケースは超高速開発が向く案件です。
ただし一つ考えて頂きたいことがあります。日本ではシステム要求の決定において現場のユーザーの発言力が大きい傾向があり、開発コストやスケジュールの都合を考えない要求がなされた結果、システム要求全体が肥大化し開発コストや期間が増大することが少なくありません。その一方で、一説では一般的なシステムにおいて全機能のうち20～30%の機能はそのシステムのライフサイクルにおいて全く使われないという調査結果もあるそうです。“全く”ではなく、ほとんど使われない機能も含めれば、一般に日本の業務システムには無駄な機能がある程度含まれているのが標準なようにも思えます。
ですから「ユーザー要望が多様なため超高速開発を適用する」は原則としては正解ですが、そのユーザー要望が本当に応えるべき要望かを、システムの企画の段階でよく精査して頂きたいと思います。要求をしっかり絞り込めば、パッケージソフトウェアでも実現できる可能性もあります。
活用シーンの広がる超高速開発
まとめると現時点では、超高速開発ツールが適するのは以下のようなケースです。
- 特殊性が高く業務に合致するパッケージソフトウェアが市場にない
- エンドユーザーの発言力が強く、パッケージソフトウェアを利用しても多くのカスタマイズやアドオンが見込まれる（パッケージの仕様に合わせるという思想が通用しない）
- 歴史が浅いなどの理由で今後も業務の変更が見込まれ、稼働後もシステムに対する仕様変更が多発することが見込まれる
この他にも超高速開発は設計～開発～テストのトライ＆エラーの繰り返しを迅速に行うことが出来るのでアジャイル開発にも向いています。
上記のようなケースに加えて基幹系の核となる機能はパッケージソフトウェアで実現し、パッケージへのカスタマイズを避ける目的で、パッケージで実現できない要求事項（仕様）を吸収する周辺システムの開発に超高速開発ツールを活用するといったケースもあります。
またツールを、システム開発のツールとして使うのではなく、プログラマが基本となるコードを生成するためのツールとして活用する例もあるようです。この場合、生成されたコードを手直しして活用すれば、プログラマは一からコーディングをするよりもはるかに楽にプログラミングが可能になります。また、BPMSやBRMSについては、全体システムアーキテクチャの一要素としてミドルウェア的な使い方をされる例も多いようです。
超高速開発という手法が加わったことにより、パッケージ開発に偏っていたシステム開発の世界で、よりシステム要求の性格に合わせたソリューションの選択が可能になりました。また超高速開発ツールは進化も著しく、新たなツールがどんどん生まれています。手法の特徴とツールの動向に注意した上で、超高速開発が向くシーンでは是非積極的に活用していきたいものです。
◆関連書籍のご紹介◆
BPO（ビジネスプロセスアウトソーシング）の効果が出なかったり、システム開発がトラブル続きだったりと、ビジネスプロセスマネジメントが上手くいっていないと多くの課題を引き起こします。
2015年7月に刊行した『ビジネスプロセスの教科書―アイデアを「実行力」に転換する方法』では、このような問題を解決するために、ビジネスプロセスとは何か、どのようにマネジメントすれば良いのか等をわかりやすく解説しています。また、著者がこれまでにお客様企業の現場で経験してきたビジネスプロセス変革の事例も多く紹介しています。ユーザー企業側で組織変更、情報システム導入、アウトソーシング活用といったビジネスプロセス変革を行う予定のある方はもちろんシステム開発やアウトソーシングベンダーの担当者の方も必見です。
