IM-FormaDesigner / IM-BISでのアプリケーション作成工数は限定条件下でしか低コストにならない。注意。

IM-FormaDesigner公式アピールポイント

intra-martカタログより

これまで多くの工数をかけて開発していた業務システムを、素早く低コストで提供することが可能です。

しかしこの謳い文句はすべてを語っていない

「Forma標準設定で可能な範囲で設定するときのみ」素早く低コストのアプリケーション作成が可能となる
IM-FormaDesigner（以下Formaと省略表記）はクライアントサイドJavaScriptによるカスタマイズを前提としているところがあり、ここでの動作は標準から外れてサポート対象外となる
標準から外れたそのときからFormaの罠が始まる

Formaの特徴

「単純なアプリケーション作成は得意だが、複雑なものは苦手」
簡単なことはスクラッチ開発と比べて工数が半分で済むかも知れない
が、複雑なことは倍以上の工数が掛かってしまう、それがIM-FormaDesignerである
そしてFormaにとっての複雑なことは予想以上に多い ＝ 罠が多い
一般的なWebアプリ開発者がスクラッチ開発で作成すれば容易に実現可能だと思われることが
様々な制約で多くの回り道をするはめになる

スクラッチでアプリ作成をするか否か、ここの切り分けを誤ると地獄を見る
webアプリでhtmlだから苦手でもなんとかなってしまうのが癖者
最悪ajaxでhtml動的に生成するスクリプト埋めてしまえば、いろんなことが出来るが工数が跳ね上がる

安易にForma開発としてはいけない

Formaはあくまで簡易Webアプリ作成ツールで本格的な開発には向かない
要求事項の実現可能性の調査を入念に行ってから導入を決めるべき
ここでの調査は、実際にアプリを作成して想定の動作が出来るか確認する必要がある

Forma開発プロジェクトに必要なこと

Formaの制約事項をあらかじめ顧客に伝え、Forma標準機能から離れない作りを基本とすべし
業務に機能を合わせる方向でアプリを作るならFormaは使用しないほうが無難
Forma機能に業務を合わせてもらう方向が許される場合にFormaを使う

天から降りてくる謎の甘い言葉に気をつけて

甘い言葉の数々

• Formaで作ると開発工数が下がる
  スクラッチと比べて1/4になるという怪情報もある
  試験は省略できないので1/2が良いところ
  Forma標準と離れたことを実現しようとすると、開発工数が大幅に膨らむため、スクラッチよりも工数が膨らんでいるのではないかと思われるケースが散見される。。。
  大体の開発では、Forma標準では出来ないことを要望される。。。

• プログラミングが分からないユーザー企業でもメンテ可能です。内製化を見据えて導入しましょう。
  Forma標準で作られているアプリケーションのメンテナンスはそれなりに容易。
  標準機能外でJavaScriptを駆使して作成されたアプリのメンテナンスは地獄。外注したら大体こうなる

• 無理やり動くようにカバー対応しているので、意図がつかみにくい作りになってしまう

• 処理記述箇所が分散しており全体の見通しが立てにくい

• 変更差分が取れないため、修正後の確認が困難

• 簡単にIM-Workflowと連携可能です
  これは本当。簡単な出張申請、休暇申請ワークフローあたりならFormaで作ると楽で速い。
  IM-BISだともっと楽。

工数が膨らむ現実例 Forma難点

パフォーマンスに難あり（特にIE11）

1画面に配置アイテムが100個程度でIE11では使い物にならないぐらい遅くなる
画面初期表示に10秒以上掛かるようになってしまう
生成されるhtmlサイズもクソでかい。1MB以上のhtmlがバンバン飛んでくる
AWSで動いてたら転送量膨らみまくって課金額どんだけになるのやら・・・

Chromeだと速度は10倍速い。とはいっても1～2秒は掛かる重さ
シングルサインオン対応が要件にあるとブラウザがIE11オンリーになるので
IE11から逃れられない

アイテムいっぱいある画面をデザイナで開くとさらに重い。開発効率ダダ下がりである

見た目のカスタマイズに弱い

見た目のカスタマイズに弱い
事前に見た目のカスタマイズは対応しないと言い含める必要がある
安請け合いすると死ぬ
css変更でカスタマイズしようとしてもIEハックが入りまくりで思ったようにスタイルが適用されない、ツライ
IE10以前の対応が残っている気がする
フォントサイズ、テキストボックスの大きさ、ラベル位置など調整がツライ

デザインを変えようとするとスクラッチで作った方が楽になる
しかし妙に余白の多い見た目を直して欲しいという要望は多い

アイテムの動的な位置変更に弱い

DOMを直接いじると可能だが、画面項目は絶対値指定で配置されており、位置調整を動的にするとなると全コントロールの座標管理することになりツライ
アイテムの表示をONOFFするだけならいいが、表示をOFFにしたら上に詰めてくれとか左に詰めてくれなどと言われたら戦争である
（一応標準機能で詰めてくれる機能があるが、制約が多く使い勝手が悪い）
アイテムのセンタリングしたいなどと言われても聞かなかったことにしたい

動的処理が苦手

出来ることは出来る
標準アイテムがajaxで動いている部分があり、そことバッティングするとツライ
これをやるとformaでやれないことも大体できるようになるが、死ぬほどコードが書きにくい
罠が２，３あって気を使う

• 例：FormaのセレクトボックスにJQueryでイベント付けても動作しないことがある
  • プロパティ指定のセレクトボックスはreadyの時点で生成される
  • データソース指定のセレクトボックスはreadyの時点で生成されない
    readyの時点で生成されてないので、documentに対してイベントを付与すると動く

公式以外の資料が少ない

今時、技術系情報はネット検索で探すものだが、検索しても答えが出ないケースが多い
そのため問題解決に時間が掛かる ＝ 工数が膨らむ

工数が膨らむ現実例

• 簡単に出来ると思った動きをFormaでやってみようとしても、なぜか簡単に出来ない

• 代替案を出してやってみるとその代替案にも罠がある

• ajaxで動的に画面表示なりをすべてやってしまえば、不幸にも対応可能 ＝ スクラッチ以下の生産性

• 色々やった結果、要求は満たすも動作が重くなる。。。

• タブ化したときの体験談をちょっと

  • 画面項目が多すぎて初期表示に30秒以上掛かるのでタブにして分割
  • タブにしたら必須チェックまわりの挙動が問題が多く頑張ってカスタマイズ
    • 入力チェックしたいタブを表示しないと必須チェックが掛からない
      → タブ表示を必須とする機能で対応
      • 登録済データを更新するたびにすべて必須タブを表示しないと更新できない。1項目修正するのにタブ10個開かせるの？
        → タブ表示必須はとりやめ。前処理で登録済データを呼出。登録済データと編集データを混ぜて入力エラープログラムにて入力チェック
      • 画面初期表示処理が終了する前にタブ切り替えが可能で、タブ切り替え時エラーになる
        → 初期表示が終わるまでタブのaタグをクリック無効にする

こんな具合で試行錯誤繰り返していたら工数もかさむ
標準から外れると万事がこんな感じになるときが多い。。。
Forma採用には慎重になってください。。。