事例で解説する、超高速開発に向く案件と向かない案件：本当はうさんくさくない、超高速開発のリアル（3/4 ページ）

[堀井大砂，ITmedia]

ケーススタディー3：　画面開発の柔軟性と生産性のバランスをとる

　次に、超高速開発ツールを正しく適用するためのヒントとなる事例を紹介しましょう。超高速開発ツールでは、画面の作り込みが難しいと思われがちですが、ほとんどの画面はカスタマイズが可能です。ただし、超高速開発ツールが生成した定型画面をベースにカスタマイズを行うため、スクラッチ開発に比べると手順が複雑になり、生産性も保守性も悪くなります。

・事例：　一般利用者向けECサイト再構築事例

　ここではECサイト再構築案件で、画面デザインに関する問題が起きたケースを紹介します。

　この案件でクライアントは、「PCに慣れていない人でも使いやすいECサイトの再構築」を目指しており、ユーザビリティやデザインを重視していました。デザイン会社に定型画面のカスタマイズで対応できる範囲を説明し、ある程度まで画面デザインを割り切ることでクライアントと合意して要件定義を進めました。

　しかし、カスタマイズで実現した画面デザインが競合他社と差別化するには不十分であり、想定以上にカスタマイズが複雑になって開発予算が膨らんでしまうことも分かり、要件定義の最終段階で案件が凍結することになったのです。FastAPPリリース初期の案件で機能も経験も足りない中で起こったことであり、現在であれば対応方法もいろいろと考えられるケースですが、繰り返してはならない教訓となっています。

　使用頻度の多い画面であれば当然、ユーザビリティが重視され、定型画面や既存の部品だけでは実現できないこともありますから、ある程度のカスタマイズが必要になります。その際に、「生産性の向上」と「画面開発の柔軟性」のバランスをどう取るかが、案件の成否を左右することになるのです。

　先のECサイトの事例のように、画面デザインの重要度が高く、柔軟なデザインが求められる画面が多い場合には、超高速開発を選択するか否かも含めて判断する必要があります。

ケーススタディー4：　パフォーマンスを意識した設計を行う

　多くの超高速開発ツールはノンプログラミングを実現しています。ツールは短期間で習得が可能なため、業務アプリを容易に開発できるようになりますが、誰もが適切な品質のアプリケーションを作れるわけではありません。設計技術があり、特性を理解した人が作らないと、パフォーマンスが悪く保守性の低いものになってしまいます。

・事例：　営業活動履歴のExcel管理台帳のWeb化事例

　ここで紹介するのは、営業スタッフが顧客との営業内容を記録し、共有するために使っていたExcelファイルをWebシステム化する案件です。

　このマクロで作り込んだExcelのワークシートは、年々データ量が増えて入力に支障が出ており、集計作業に時間がかかっていました。加えて担当者が3カ月後に退職することになり、代わりにExcelマクロを保守できる人もいないことから、Webシステム化を行うことになったのです。

　期間は短いものの、利用者の日々の操作を大きく変えたくないということで、現行に近いインタフェースを実現したいという要望でした。

　提案段階では、画面をカスタマイズすることでExcelに近いインタフェースを実現できることを確認していたのですが、実際に開発を進めていくと、項目が想定以上に多く、1つの画面の中に全てを表示すると見づらい上、期待する表示性能が出ないという問題が起きました。そこで、画面表示項目を内部的に列分割し、画面の中で切り替えて表示する形に変更して対応しました。

　データの行表示は当初、「1画面内に収まる行数まで」という設計でしたが、「ある程度の行数までを1画面で見たい」という現場の声があったため、スクロールして表示行数を増やすことになりました。実装した結果、性能テストでピーク時のメモリ使用量が想定していた容量を超えることが分かり、データ検索方式を「一括検索取得」から「順次検索取得」へと変更しました。

　用意していたデータベース検索部品を使うことで、機能上は問題なかったのですが、データ件数への考慮が不足していて、性能テストで性能要件を満たせない問題が発生しました。

　データベース検索部品が発行するSQLでは、インデックスを作成しても性能要件を満たすことが難しいため、ストアドプロシージャを使って複雑なSQLでデータベース検索を行う方式に変更することで対応しました。

　適切なシステム性能を実現するには、データベース設計で正規化し、性能要件に合わせて画面表示する項目数や表示形式を工夫するといった設計が必要です。機能によっては、ノンプログラミングをやめて、プログラミングを行う判断も必要です。

　スクラッチ開発では、画面や機能ごとに最適化されたプログラミングを行いますが、超高速開発ツールが生成するシステムは、汎用化された部品（またはソースコード）で構成されるため、スクラッチ開発に比べてオーバーヘッドが発生します。また、サーバ仮想化が進んでいる今、柔軟にサーバのサイジングを変更することで解決し、設計にかける労力を減らすという割り切り方もありますが、それにも限度があります。

　このように「求める機能」によってノンプログラミング開発が合理的な場合もあれば、そうでない場合もあります。つまり「速い・簡単」といった側面ばかりが注目されがちな超高速開発においても、以上のような合理的判断ができるような“一定レベル以上の設計技術”が求められるのです。