「作る」から「使う」への転換〜「アプリを作らない」ノンコーディング開発基盤Nintex

吉田健一(Kenichi Yoshida) 2010-02-14 13:53:04

■アプリを「作る」ことは価値を生まない

日本の生産性は悪化の一途をたどりOECD加盟30カ国中第20位まで落ち込んだ。その原因の一つはナレッジワーカーの業務非効率にある。優秀な社員が手間をかけて素晴らしい業務をしているが、それは本来手間をかけるべきではない非戦略領域である事が多い。ITの面でそれが如実に現れているのが乱立するアプリケーションである。

例えば、ある大手企業A社の例を見てみよう。

大手企業A社は10年前からNotesを利用し始めた。現場のニーズに合わせたアプリを容易に作ることができるためEUCが進展、現場発で次々とアプリが作られ、最終的にDB数が2,000DB近くまで達した。

10年間でIT化は大きく進んだが、その反面DB数の多さがメンテ・サポートコストに跳ね返ってきた。また、バージョンアップや移行をしようとしても、DB数が多すぎて身動きがとれなくなった。ユーザーからみてもインターフェーズがバラバラなDBが乱立することで使い勝手が低下していた。

しかし、この2,000DBをよく分析してみると、実は部署毎に似たようなアプリをたくさん作っているだけで、機能としてはほとんど同じアプリが多かった。例えば、議事録を作成し承認を得た上でメール配信するDBが個々に15種類も作られていたが、1種類のDBに標準化・共用化できるものであった。結果2,000DBは20種類の標準的アプリで済むことが分かった。

A社では技術力のある優秀な現場社員はアプリを「作る」ことが仕事だと思い、その能力をアプリの機能追加やユーザーインターフェース改善に費やしていた。しかし、そうした個々の努力は個別最適を生み、結果として全体からみた非効率を生みだしてしまっていたのである。

クラウド化の進展により、「作る」よりも「使う」ことが重要である、というトレンドが生まれつつある。しかし、クラウドだからこの問題が解決するというわけではない。圧倒的な短い開発期間により導入が進んでいるforce.comでも、開発が容易だからといって「作る」ことを続けていると、数年後には上述のA社のようにアプリの乱立で身動きが取れなくなってしまう。

■ノンコーディング開発基盤Nintex

こうした状況への解決策としてこの度、リアルコムではノンコーディング開発基盤Nintexの国内販売を開始した。「作らない」ためには、開発=コーディングを行わないで、設定によりアプリを作る必要がある。Nitexはこうしたノンコーディング開発を実現する基盤としてUSで高いシェアを誇っており、お客さまからこうしたツールの要望が多かったため、国内販売・サポートを開始するに至った。

Nintexは世界シェアNo.1の情報共有基盤SharePoint上で動くワークフローアドオンソリューションである。SharePointのワークフローというと稟議・決裁をイメージされるかもしれないが、SharePoint用語でのワークフローとは条件判断、条件分岐、アクションといった「ビジネスロジック=仕事の流れ」の事であり、ナレッジワーカーが行う様々な業務をノンコーディングでアプリ化することができる。

Nintexの最も大きな特徴は、ノンコーディングによる簡単なアプリ作成である。

設定画面上のドラッグ&ドロップで「アクティビティ」と呼ばれる処理内容を組み合わせることで簡単にアプリを作ることができる。例えばこれまで、上長にメールで議事録を送って確認を取り、その後関係者に公開するという業務であれば、Nintex上で

 1:議事録を承認する
 2:承認後、アクセス権を公開する
 3:関係者にメールを送付する

という3つのアクティビティを設定すれば、簡単に議事録アプリを作ることができる。

 

アクティビティにはやデータ内容による条件分岐や、WebサービスやXMLクエリ、SQL実行等の外部システムと連携することも可能である。

Nintexで開発したアプリはノンコーディングのため、サポート・メンテコストの増大やバージョンアップ時のコスト増も発生しない。こうしたメリットを受けて、NotesユーザーがNotesで作りこんだアプリの移行先として活用するケースが増えている。

■断固として「作る」から「使う」への転換を

Nintexは「作る」から「使う」へのシフトを加速させる1つのツールにすぎない。真に「作る」から「使う」へのシフトを実現するのは、IT部門に断固としたリーダーシップが求められる。

ベンダーからすると「作る」から「使う」へのシフトは大きな脅威であり、極力「作る」ことを提案してくる。また、ユーザーからしても、自分のニーズをそのまま実現してくれる「作る」アプローチの方が心地よい。そうしたベンダーとユーザーのはざまに立ちながら、企業としてあるべき開発戦略を考え、断固として「作る」から「使う」へのシフトをリードしていくことが、IT部門には求められている。

「作る」から「使う」へのシフトにより、 優秀な日本のナレッジワーカーが価値の高い業務に従事し、生産性向上に寄与することを願ってやまない。

 

吉田健一@リアルコム  お問い合わせはこちら

(■twitter始めました。よろしければフォローお願いします。)

※このエントリはZDNetブロガーにより投稿されたものです。朝日インタラクティブ および ZDNet編集部の見解・意向を示すものではありません。

3件のコメント
  • ななし

    cocoatomoさんのコメントについて

    弊社ではNintexで作ったアプリが乱立している状況にあります。
    Nintexではサイズに関する制限はありませんので、いくらでも複雑なアプリを作ることは可能になります。使えるアクティビティが制限されているので、同じことするために、より複雑な処理を行うことになり、かえってメンテナンス性が悪くなっていると思います。

    この記事で、コーディング・ノンコーディングという単語をどういう意味で使われているのかわかりませんが、なんか勘違いだと思います。

    2012年07月08日

  • 吉田健一

    cocoatomoさん、コメントありがとうございます。ご指摘の部分、説明が足りず申し訳ありませんでした。

    >1. それって Nintex で解決するの?

    おっしゃる通り、事例の会社ではNintexを活用しただけではなく、アプリを標準化・共用化するためのプロセス・体制や、標準化・共用化したアプリの利用を強制する権限を含めて「作る」か
    ら「使う」へのシフトを実現しました。ですのでNintexはあくまでツールに過ぎません。

    ただツールとして、

    ・Nintex上の設定変更はほとんどコストがかからない上に、他者が作ったアプリの構造も簡単にわかるのでたメンテ・サポートコストが大幅に低下した
    ・Nintex上で作られたアプリはSharePointのバージョンアップ時にテスト・移行コストが不要のためコストと柔軟性が大幅に改善した
    ・Nintex上で作られたアプリは構造が見える化されており標準化・共用化しやすくなった

    というメリットがありました。

    >2. それってノンコーディング?

    こちらは説明不足でしたが、Nintexは「開発ツール」ではなく「設定画面」だという位置づけというところが肥大化を防いでいると思っています。
    Nintexでは「アクティビティ」と呼ばれる処理を組み合わせてアプリの設定をしますが、この「アクティビティ」はもともと提供されている70しかなく、新しいものを追加することはできません。
    ですので限られた範囲内でしかアプリが作れません。ユーザー部門にはニーズを多くをあきらめてもらい、標準の「アクティビティ」の範囲で要件を満たしてもらうことになります。
    設定できないものはあきらめるという割り切りがアプリの肥大化を食い止めるきっかけになっていると思います。

    ご指摘をいただいて、新しい発想が出てまいりましたので大変感謝しています。
    またご指摘等ありましたらよろしくお願いします。

    2010年02月15日

  • cocoatomo

    1. それって Nintex で解決するの?

    そもそも最初の問題って「部署ごとに似たようなアプリケーションが乱立する」ことだったわけで, その原因というのは社内のアプリケーションに対する要望を吸い上げる, もしくは先取りして提供する仕組みが社内に無かったことだと思います.

    しかし Nintex を導入することでこれがどう解決するのかが, この記事からは分かりません. 結局, Nintex で作ったアプリが乱立するだけになると思います. Nintex にはそれを防ぐ仕組みなどがあるのでしょうか?

    2. それってノンコーディング?

    記事中の図を見る限り, フローチャートを組んでアプリを作ることを「ノンコーディング」だと仰っているように見えますが, そのチャートが肥大化したときには結局メンテナンスコストも肥大化するのではないでしょうか? それとも Nintex ではフローチャートが肥大化しないための仕組みなどがあるのでしょうか?
    (私はメンテナンスコストの増大は, 適切なコンポーネント化が行なわれていないことが原因だと思います. これは「コーディングをする/しない」という実装手段の話ではなく, 「物事を整理して考えられるかどうか」という設計の話です.)

    また, 外部連携などと言い出したら, それこそコーディングとほとんど変わらないと思いますが如何でしょうか?


    以上の 2 点についての回答を, 記事に追記するなどしていただけないでしょうか?

    2010年02月15日

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]