Extremely Rapid Application Development Community (xRAD)

超高速開発シンポジウム2014

  • HOME »
  • 超高速開発シンポジウム2014

■ 超高速開発シンポジウム2014

“超高速開発ツールの話をたびたび耳にするようになったが、導入にあたって問題はないのだろうか。”

“自社にはこのような課題があるので超高速開発ツールを活用したいが、他の企業はどのようにしているのだろうか。”

“導入を検討しているが社内の技術者は対応できるだろうか。”

今回の超高速開発シンポジウムでは、実際に、導入に関わられた企業様の生の声をお届けいたします。
抱える課題の本質は何なのか、どのように解決していったのか。導入後に起こり得るであろう不安点を含め、経験者の体験談を直接聞ける、コミュニティならではの企画です。

超高速開発シンポジウム「超高速開発の導入を迷っている最後の理由 – 開発ツールの期待と課題」

日 時 2014年11月26日(水)
13:00 – 15:00 (受付開始12:30)
15:30 – 17:30 (交流会)
会 場 スクワール麹町(JR四ツ谷駅 麹町口から徒歩30秒)
(http://www.square.or.jp/access/)
定 員 200名
対 象 コミュニティ会員及びご興味のあるユーザー企業、ITベンダー企業
内 容 (1) 問題課題の整理 (10分)

事前にいただいたご意見(下記参照)を整理して、どういいた懸念があがっているのかを簡単に紹介します。

(2) 識者、経験者によるパネルディスカッション (90分)

パネリスト   木内 里美 氏(NPO法人システムイニシアティブ協会理事長)
藤原 孝幸 氏(伊藤忠テクノソリューションズ株式会社 情報システム部
アプリケーションシステム第1課)
米窪 英人 氏(松本商工会議所理事 情報事業部長)
袖嶋 嘉哉 氏(株式会社ジェーエムエーシステムズ
企画営業部 マネージャー)
コーディネータ 今林 豊 氏(株式会社市進ホールディングス 情報管理部
IT戦略推進室 室長)

(3) まとめ (10分)

参加費 シンポウジウム参加費無料(コミュニティ非会員も無料です)。
交流会参加費4,000円。
スポンサー 株式会社アトリス
マジックソフトウェア・ジャパン株式会社
株式会社BlueMeme
株式会社アイエルアイ総合研究所
株式会社コアネクスト
株式会社コラボスタイル
サピエンス・ジャパン株式会社
株式会社ジェナ
株式会社HOIPOI
申 込 本シンポジウムは終了しました。

お申込み者からいただいた、課題リストは次のとおりでした。

  • 仮に開発プロジェクトが炎上した場合、人海戦術しか打つ手がないとなると、オープン技術とはいえない高速開発ツールを利用していると技術者の確保が難しい。
  • SIerである以上、技術力は当社のコアコンピタンスであるべき。高速開発ツールの全社的な導入に舵を切った場合、当社の将来を担う若手エンジニアから技術力の低下を招きかねない。
  • COBOLのように、数十年利用できるのか疑問?(一時的な流行で採用したくない!)
  • ツールの将来性が不安。基幹システム等、長く使うシステムを開発する際、ベンダーサポートや製品サポートが継続されるのか不安。
  • 中長期で利用しようとすると、バージョンアップ時の互換性等が気になります。
  • ツール開発ベンダの存続基盤が脆弱で、導入後に発生するかも知れないリスクの評価が困難であること。
  • 長期に使い続けるために、その会社が存続しうるか?
  • リポジトリ型のツールの場合、ツールにロックインされてしまう。また、ツールベンダーがツールの提供をやめた時にソースコードがあれば継続利用/保守が可能だが、リポジトリ型の場合、どうなるか不安がある。
  • 採用したツールにロックインされて競争原理が働かなくなり、長期的に見ればむしろ費用が割高になるのではないか。
  • 導入障壁は「ツールロックイン」と思います。
  • ツールロックインから逃れることは可能か?
  • ツールロックインへの不安。
  • レガシ―環境でアプリを組んでいたSEにとって、超高速開発ツールはSQLを駆使したデータ処理に不安を抱えている。
  • 基幹系で登録しているユーザ権限を如何に活用できるかも不安に思っている。
  • ユーザインタフェースに関しても、従来エンドユーザの我儘を取り入れてきたため、制限があることに不安を抱えている。
  • 採用したツールによって機能面・性能面での制約を受け、必ずしもあらゆる業務要件を満たせないのではないか。
  • どの程度の規模まで対応可能かわからない。
  • 既存システムとの連携についてどこまで対応できるのか。
  • 品質はどうなの。
  • ソースコードの自動生成の信頼性に不安を感じる。
  • ソースが読めないことに不安を感じる。
  • 自前で、保守を含めて対応できるか?(ベンダー依存したくない)
  • (自分たちの技術レベルが低いので)ツールを使いこなせるのか不安。
  • ツール比較・選定が難しい。リポジトリやBPMN2.0準拠等に共通性があれば失敗しても切り替えできるが、現状では困難なので最初にしっかり吟味する時間がとられる。
  • プロセスから入りたいのだが、結局DOAだと言われると開発的要素が強く感じられユーザー部門に近い部門からの提案がし辛くなる。
  • 大規模なシステム開発や改修時に多数の技術者を集めることが難しいこと。(広く普及すれば無くなる問題ですが。)
  • ツールで出来ないことがあった際に、どう対応すれば良いのかわからない。対応方法が分かったとしても、自分たちだけで解決することは難しい。
  • 親身になってサポートしてくれるベンダーが、近くにいないこれまで付き合いがあるベンダーが担いでくれると良いが、なかなかそういう話は無い。
  • 工数削減につながるか疑問。開発工数を現状より何%削減できるのか?効果が得られるか確信がもてない。
  • 費用対効果が得られるかが疑問。良いツールでも、いつごろ減価償却できるかイメージができない。
  • この手法を活用することによる、ユーザにとってのメリットが見えない。
  • 導入費用が高い。ツール自体も高い。数百万円する。SIerの場合、社運を賭けた導入となる。
  • 導入障壁は「価格」と思います。
  • 中小企業に決断させるには初期費用が高い。
  • Windows信者(クラサバ信者)をどのように説得したか?
  • ツールを利用する案件がない。良いツールでも、ターゲットとなる業務が明確にならず、上申しづらい。
  • ビジネスプロセスToBe描ききりが必要では?
  • 既存システムの機能改修で活用できるのか。
  • ユーザとして開発手法まで関与する必要があるのか不明。
  • 官庁特有の課題:開発手法なので、はじめから仕様書に規定できない。

当日の進行議事録を掲載しました。

■ 開発者・提供者の章
 ツールの提供元の信頼性、将来性。
  xRADツールを25年使っている。職員10名全員で使う。
  大規模システム立ち上げ時のベンダーサポート。
  ツールの研修(新人)もベンダーに依頼している。
  同一ツールについて、4種類のバージョンを混在して使っている状況。
   混在しても特に問題はない。
 地方でのツール・機種選定
  機種選定には固有の事情がある。(他の地方も?)
  どの機種でも動作するというのがツール選定の根拠。
 現在は…
  スマホアプリを作るというニーズもある。ツールが支える。
  Web、クラサバ、RIA、…
   違いを知らなくても使うことができている。
 価格はどうか?
  ぱっと見て、安くはない、という印象がある。
  スクラッチ開発に馴れているお客様にはライセンス費がかかることを説明しないといけない。
  しかし従来の開発人件費とトータルで考える、という説明は可能。
  すべてのツールとは言わないが、高い。ちょっと試しにやってみたい、では敷居が高い。
  開発ツールの価格と、実行ライセンスの価格がある。

■ SIerの章
 SIerが超高速開発を選定する理由
  オフショア開発などの登場 => 競争力低下
  クラウド、モバイルには同意しても、超高速開発ツールは社内で賛否があった。ゆくゆくは自分たちのクビを締めるのでは?
  それよりも「新しい価値」を提供する方がいいのではないかという案で押し切った。

 制約
  自動化率が高いほど、(画面の)画一感が高い。
  スクラッチに馴れた技術者ほど、もやもやとする。
   そこで手を入れてしまって、ツールの良さを活かせなくなる。
  導入手法はスクラッチ型ではなく、パッケージ型へ。
  パッケージのカスタマイズという感覚。カスタマイズするかどうかをお客様といっしょに決めていく。
  画一化と独自性の、よいバランスを見つけようとしている。(5年間の経験から、見えてきた)

 SIer視点での、導入のメリット
  ツールを使った、特色のある提案を仕掛けられるようになった。

 お客様の声
  今のシステムと比べて、操作性が… という突っ込みはある。しかし意外と馴れていただける。馴れによる解決。
  それでも満足しないというお客様への、さらなる対応方法は次のとおり。
   ツールが許容する範囲でのカスタマイズを行う。(生産性は低下するが、ツールの範囲内にとどめる)
   ツールを超えるUIの要求は、手組みをする。生成したDBに接続できるので、つなげることは可能。
  ツールで実現したデータ構造については、指摘は(ほとんど)ない。

■ ユーザの章
 効果
  
  高速ツール使用して最初のプロジェクトですので効果がまだわからない。
  
  当初は、簡単に開発できると感じていたが、言語を覚えるたため 2~3ヶ月、ベンダーの 導入支援が必要だった。
  
覚えてしまうと、簡単な画面は確かに素早く作成できる。大規模システムにそのまま適用できるかは、まだわからない。

 ロックイン
  
  ベンダー視点では「Javaコードがある(生成される)ので大丈夫」と説明。

  他のツールに置き換えられるか?は、疑問。

 ユーザ視点からの導入の目的

  開発期間、開発費用の短縮、ということ。

 実際には
  導入「後」の方が効果が高い、を実感している。
  DB変更も一日あれば実現。今までにないスピード。

 敷居の高さ
  はじめてのプロジェクトは馴れていないので、最初は効果がわからない。
  ロックインは避けられないが、ツールが手元にあれば今でも使えるという環境ではある。

 ツールロックイン vs ベンダーロックイン
  両者に、そんなに違いはないのでは?
  将来性を見越して、採用側が判断することになる。
  どのみち(ユーザー企業にとっては)モデリングは必要。モデリングなしでシステム開発はできない。
  結婚もロックイン?

 公共調達とロックイン
  入札制度のため、ロックインはできるだけ排除しなければならない。
  期待:要求仕様を定めれば、ツールは何でもいい、という世界。
  導入費用は?入札なので、最低価格を目指す。

■ 会場の意見

□ ツールを導入すると何が変わるのか?
 保守性が抜群、という視点
  COBOL時代、レイアウトを変えることは不安だった。

□ ビジネスのためにどう使うか、という視点で議論してほしい
 どうやってビジネスに活かし、運用していくか。
 社内だと、トップが変われば業務ルールも変わる。
 いかに早く、環境変化に合わせるか。
 ツールありきではない。=> ビジネスを早く回すためにツールが良い、というストーリーは成立するのか?
 xRADツールは、あくまでも選択肢の一つ。

□ 要件定義の視点
 将来をみすえた業務フロー作成が入り口。
 ツールは要件定義フェーズと相性がいいのではないか。
  今は書面でつくっている。
  ツールを使えばドキュメント作成は減らせる?
  そういうノウハウはある?
 従来開発でいうところの、Excelで書き始めるところから、ツールの出番では。ドキュメントの代替 => 動くものができる。要求と違うところを赤入れする。
 ツールを使うと要件定義の時間は短縮される。
 あとでひっくり返される、というような場面は減っている。
 コスト・期間の面で「ここは諦める」というところが早めに認識できる。

□ ツールは「どうつくるか」だが、「何をつくるか」の議論は?
 上流の前段階 => グランドデザイン
 プロセスモデリングとデータモデリングを固めて、はじめて準備ができる。今はそうやって進めているか?
 細部は決まらない。やりながら決まっていく。
 手戻りは起こる。
 ツールは、仕様を決めることを支援できる。
 ただし、つくる側(ユーザ)が主体性をもたないと活かせない。

 7割の仕様が決まったところでツールを使う => あれも足りない、ということがわかってくる。動いているものをみて、はじめて気付く。これは上流の不足を補う、ということができたということ。

 上流工程の成果を「リポジトリ(設計情報)」としてきちんと管理するようにすれば、下流工程とつなげることができる。製造、テストフェーズでも設計情報は利用できる。

□ コンシューマ向けのサービス開発でのツールの活用
 デザインと、パフォーマンスが気になる。
  画面部分は手組みになる。ツールは(画面とDBの)つなぎ、として使える。ツールの組み合わせ => SI

□ 技術者の育てかた
 ツールを理解すれば力になるが、理解力をもった技術者だったら、という前提があるのではないか。新人がいきなり使うと、ツールのすごさもわからないまま使うのでは。
 新人向けの説明は…
  稼働しているさまざまな業務システムを見てもらう。

□ ツールを使うと内製化に進む?
 ユーザにとって扱えるツールなら => 内製化への動機付け。
 SIerにとってはビジネスチャンスになる?内製化が進んでも、社内開発体制の整備には限界があるはず。大きな開発になったところでSIに声をかけてもらえればいい。周辺のビジネスチャンスもひろがるはず。

□ ユーザー視点の内製化
 どんなツールでも、学習しないといけない。
 ユーザも学習し、かつベンダーがそれを支援するという関係がベスト。
 保守というのは開発行為であり、運用ではない。保守をユーザーが行えるのは良い。
 すべてを内製化しようとは思わない。コア部分=内製でも、周辺部は外注でかまわない。そういうユーザがこれから登場する。

□ 情報システム部はニーズがわからない?
 ニーズをもっているのは、お客様の先にいらっしゃる方。
 ニーズをいかにシステム化するか、が専門職という位置づけ。

□ 働きかた
 IT業界に限らず、世の中の仕事が変わっていく。ここは気にするところではないのではないか。

Copyright © 超高速開発コミュニティ事務局 All Rights Reserved.
Powered by WordPress & BizVektor Theme by Vektor,Inc. technology.