システム導入が爆速に？ 「超高速開発」の出番ってどこですか？：本当はうさんくさくない、超高速開発のリアル（3/4 ページ）

[高橋一成，ITmedia]

超高速開発の代表的な製品について

　私の観測範囲における、代表的な製品について簡単に俯瞰しておきましょう。ただし、各製品のコメントはあくまで筆者個人の見解であることをご容赦ください。

製品名	典型的な案件規模	特徴
				メリット	デメリット
Salesforce（セールスフォース）	中〜大	超高速開発の技術ではないが、そういう見方もできる。大規模基幹システム向け。	カスタマイズの開発工数は重め。
Kintone（サイボウズ）	極小〜小	「サイボウズデヂエ」の後継。ちょっとした業務ツールをDIY的に作成する用途に特化。	ドラッグ＆ドロップでできる範囲を超えて利用しようとすると、かなりのJavaScriptを書く必要がある。
Microsoft Access（Microsoft）、FileMaker（ファイルメーカー）	極小〜小	歴史と伝統のあるDIY製品。	個人利用ツールの性格が強く、複数人同時利用は困難を伴うことがある。
Wagby（ジャスミンソフト）	小〜中	ノンプログラミングで対応できる範囲とカスタマイズ許容度のバランス志向。	スマホのネイティブアプリなど、非Web環境には対応していない。
FastAPP（SCSK）	中〜大	ノンプログラミングを中心にスクラッチとのハイブリッドな開発が可能。SIer向け。	大量データ処理、リアルタイムな高速処理には向いていない。
MOD99（ルート42）	小〜中	少ない設計情報からリッチな業務システムを生成できる。業務ロジックは手書き。	性能要求がシビアな用途には向いていない。

　それぞれ向き不向きがあることがお分かりいただけたでしょうか。優劣の問題ではなく、目的に応じて最適なものを選ぶことが大切なのです。

　なお、最後の3製品は、今回の連載の執筆陣が関与する製品です。一見すると特徴が類似しているように思えるかもしれません。それは、三者が活動してきた領域において似たような課題が多く、「アプローチは違えども、結果としては同じ山の頂にたどり着いた」ということだと私は考えています。

超高速開発の適用事例

　詳しいケーススタディーは連載の第2回へと譲りますが、ここで1つ、事例を紹介します。

　当社の直近の事例として、国内大手データセンターの在庫管理システムの実装を担当しました。規模は次の通りです。

画面数	500	画面仕様書、業務ロジック仕様書として提示されたPowerPoint資料とWord資料の合計は最終的に500ページ以上。
テーブル数	300	データセンター内には膨大な設備があるが、在庫管理の粒度はメモリ1枚の単位であり、マスターの構造が複雑。
帳票	80	CSVおよびPDF帳票。QRコード出力あり。
コードの行数	およそ100万行（※6）、そのうち手書き部分は4万行程度	コード行数がシステム規模を正しく反映するわけではないが、参考情報として提示。

　この案件の予算は通常のスクラッチ開発の1/2から1/3程度でした。また、開発の着手時点で基本設計は6割程度しか完了していませんでした。このような条件下でしたが、弊社は6カ月で開発（※7）を終えました。

　もちろん良い点だけではなく、割り切ってもらった点も多数あります。例えば次のような点です。

• 本来は1つの画面で完結すべき処理が、2つ以上の画面にまたがってしまうことがある
• 細かい使い勝手の要望は受け入れない（ボタンを画面のどこに配置するかというレベルの話）
• アプリケーションのパフォーマンスは、まあ妥協できるという程度（※8）

　フルスクラッチ開発だったならばシンドい案件になったはずですが、「今回のシステム実装で重視すべきこと」に優先順位を付け、それに基づいて妥協を織り込むことで、このような結果を出すことができたのです。

---

※6：　単体テストおよびコメント行を含む。

※7：　設計期間およびUAT期間を除く。

※8：　遅い箇所を手書きコードでオーバーライドすれば改善できますが、せっかくのコストメリットが損なわれます。