大企業を中心に高まりつつあるAD自動化ツールへの関心

　アプリケーション開発ツールは、JUAS（日本情報システム・ユーザー協会）ソフトウェアメトリックス調査2015によると、機能別に（1）設計・コード生成型、（2）設計・実効エンジン型、（3）業務モデル作成支援、（4）テスト自動実行、（5）EAI（Enterprise Application Integration）、（6）UI生成・実行に分けられる（※1つのツールで複数の特徴を持つ場合もある）。


　ではAD自動化ツールへの関心度は、日本において実際のところどれくらい高まっているのだろうか。2016年5月にガートナーが調査した結果では、従業員数2,000名以上の大企業で特に強いことがわかっている。

　この理由の1つには、大きな企業ではさまざまな開発プロジェクトがあるため、中には「自動化ツールを導入してみるか」といった動きも出てきやすいこと。

　もう1つには、大規模なシステムが多いため、案件が複雑化・巨大化しており、従来のスクラッチ開発やウォーターフォール開発だけでは課題が解決できないといった事情がうかがわれる。

　一般には、新しい技術に敏感なイノベーターやアーリーアダプターと呼ばれる層が15～16％に達すると、その後が継続的に伸びると言われている。

　もちろん、企業全体で見るとまだ不十分だが、大企業セグメントの中でも新技術導入に前向きな35％の企業が、採用予定も含め何らかのアプローチを行っているという事実は、今後のAD自動化ツールの伸びを十分に期待させるものだ。

AD自動化ツール導入による、3つの代表的なメリットと課題

　次に、企業が抱えるアプリケーション開発の最重要課題を見ていこう。こちらもガートナーの2016年調査によれば、エンタープライズ・アプリケーション開発で今後もっとも重視される項目は、「品質：31.2％／コスト：26.8％／納期：4.0％」の割合になっている。スピードも大事だが、どれか一つ選ぶとなると、やはり品質とコストが優先されるのだ。

　ところがここで注目すべきは、上の3項目以外に、単独で「アプリケーションの特性による」という回答が38％に上っていることだ。要するに、アプリケーションの特性によって、重視する項目も変わってくるというのである。実はこれが、エンタープライズ・アプリケーションの開発プロジェクトを実施する際に、「ツールかスクラッチか？」を判断する重要な基準になる。

　そもそもアプリケーションの特性によって選択するには、前もってスクラッチ開発とAD自動化ツール双方の違いを明確に比較し、理解しておく必要がある。ここではAD自動化ツール導入のメリットと課題から、代表的な3つを紹介する。

1.「伝言ゲーム」による話の食い違いが解消

　スクラッチの場合、担当者各人が自分の“用語”で話しているうちに、だんだん要点や意図がずれてくる。あいまいな言葉によるコミュニケーションが、アプリケーションの品質に影響を与えてしまうのである。

　AD自動化ツールを使うと、プロジェクトチーム全員が、共通の言葉でコミュニケーションできるようになる。この結果、要件定義が明確になり、その後の開発プロセスにおいても齟齬が生じにくくなるため、当初の要件と最終的成果物がぶれにくい。

　ただし留意しておくことは、「自動化ツールを使ったからといって設計が不要になるわけではない」ということ。ここを勘違いすると、プロジェクトが迷走することになる。

2.要件変更への柔軟な対応が可能になる

　スクラッチの抱える問題点の1つは、システムの変更作業が大変なことだ。その点AD自動化ツールならば、要件定義からアプリケーション開発、システム構築、そして本番稼働後の改修まで、繰り返しの要件変更を文字通り自動化できるため、スケジュールに大きな影響を与えず、ビジネスの要件に対応したアプリケーションが実現できる。

3.属人性を排して高品質と生産性を両立

　スクラッチのコードは、「書いた人自身でないとわからない」ことがしばしばだ。これを避けようとコーディング規約を作っても、「全員が守らない」、「守らせるのが大変」と、プロジェクトマネージャーや開発リーダーの苦労ばかりが増えて実効が少ない。AD自動化ツールは内部にコーディング規約などを実装できるため、開発工程の標準化が実現される。

スクラッチ開発とAD自動化ツールはどう選択すればよいのか

　ここからは、「アプリケーションの特性によってスクラッチ開発とAD自動化ツールをどう選択するのか？」を具体的に紹介していく。

　まず「アプリケーションの特性によって選択する」場合、何を基準に考えるのか。図の上の「革新－差別化－記録」のスケールに注目して欲しい。これは開発するアプリケーションの特性を分類したものだ。


　「革新」は、文字通り自社のビジネスをイノベートするアプリケーションである。いわば自社の業務のコアとなる、またはマーケットに対する訴求や差別化を担うもっとも重要なアプリケーションだ。

　ここでは、柔軟性を最優先してスクラッチ開発を選択する。つまりビジネスに必要な機能を完璧にカスタマイズするため、スクラッチ開発とそれを支えていく仕組みが必要なのだ。

　一方の「記録」は、売上や在庫、経理・財務などの数値データであり、処理のスピード（効率性）と省コスト性が重視される。ここには、パッケージやSaaSなどを採用していくのが賢い選択だ。「差別化」は、革新と記録の中間に位置するものであり、その業務の内容や特性によって適宜判断する。

　以上のように、開発手法の選択にあたっては「業務におけるアプリケーションの位置付け」と、「開発上の自由度＆制約」の2つのスケールが有効だ。これらを用いて「こだわってカスタマイズする価値があるか」、「スピーディーにデリバリーすればよいのか」を判断していくことが、開発リソースの配分バランスの最適化につながるのである。

　ただし、単純にスクラッチかAD自動化ツールかを分けるのが正解ではない。あくまでAD自動化ツールによる「QCD:品質／コスト／納期」の改善を基本スタンスとして、その上でツール標準機能では難しい機能を、あえてスクラッチ開発すべきかどうかを判断する。

　さらに、ツールでも実現可能だが、そのままではユーザーの使い勝手がよくないので別途作り込むといった「非機能要件」が必要な場合も、スクラッチを選択する理由となる。この非機能要件の吟味を入念に行うことが、使いやすいアプリケーションを作る上では見逃せない。

【次ページ】AD自動化ツール導入事例に見られる「失敗しやすい」4つのポイント