さった8月22日に東京・神田で開催されたセミナーに参加してきました。7社の事例発表をまとめてみます。
ユニケージ開発手法「スピードが全てを駆逐する」
有限会社ユニバーサル・シェル・プログラミング研究所の當仲所長による発表。
OSSでもソースコードが何十万行もあれば読めないので、実質的にはブラックボックス化してしまうことを踏まえ、ユニケージ手法は「シンプルで短いコード」を求める。開発期間は従来方法に比較して半分から1/5になっている。COBOLバッチ処理、SQL置き換え、BI、ビッグデータ解析などが主な開発テーマ。大学との共同研究も進んでおり、国内だけでなく海外（MIT）との協力体制を敷いている。
ポイントは「データ中心主義」「7割主義」「完全分散」。データを整理せずにアプリケーションをつくらない。業務の骨格は全体の7割。あとは実際に使って手直しを行いながら完成度を高める。プログラムやデータの依存関係をなくすとは、プログラムからプログラムを呼ばないようにすること。またRDBではないので、データの関連は定義しない。
これまでの経験から、自分の業務を知り、こういうデータならいいよねという発想を持てる人が内製に向いている。
Excel開発ツール「StiLL」を使ったERPカスタマイズの事例
日本ユニシス株式会社ビジネスサービス事業部の亀山様による発表。
StiLLはExcelを使うツール。Excelの上にボタンが配置される。見た目がフローチャート、動作させればプログラム、印刷すればプログラム設計書になる。
発表事例は「パッケージ+カスタマイズ」という構成を「パッケージ+StiLL+残ったカスタマイズ」にしたもの。日本ユニシス社のERP「Hybrish」のカスタマイズにStiLLを組み合わせて提供している。WebベースのERPから、あるメニューを選択するとExcelが開き、StiLLで開発した機能が使えるようになる。UIがExcelベースというのが嬉しいという方には向いている。SIer視点での最大のメリットは、お客様自身に開発をお願いできるということ。ただしDB更新は避けてもらい、検索系のみ。お客様が自分でつくるので開発コストを下げられる。
Wagbyを使ったAS400システム再構築の事例
株式会社パルシスの阿部様による発表。老朽化したAS400システムのリプレースにパッケージソフトを検討したが、1年ほど要件定義を行ったところカスタマイズの量が膨大になり、パッケージベンダーが降りてしまった。当初、パルシスはフルスクラッチの開発を提案したが予算が合わず、Wagbyによるコストダウンを提案した。
Wagby採用を決定した理由は「豊富な非機能要件、特に権限管理」「画面表示の充実」「Javaカスタマイズが可能なためユーザー要件を満たしやすい」こと。
Wagbyによって、当初スクラッチ開発で見積もった分から32%の工数を削減できた。コードの品質も担保できる。カスタマイズはJavaに詳しいエンジニアが必要だが、少人数で済むため要員の管理コストは削減できた。
ドイツ製のワークフローツール Metasonic Suite
パワードプロセスコンサルティング株式会社の岡田様による発表。前提として既存のBPMNは複雑すぎる（記号だけでも100以上あり、専門家が必要）というのが出発点。Metasonicは5つの記号に絞込んで業務フローが書ける。ここでいう業務フローとは、いわゆるワークフロー。海外事例が多い中、国内ではNECにおける採用事例がある。SAP導入時に対象から漏れた部分を Metasonic でカバーしたというもの。動的ルート設定や、複数の承認ルールの扱いなどができたというのがアピールポイントになっている。
ODIP（オーディップ）によるバッチ処理
株式会社インテリジェント・モデルの小林様による発表。プログラムは生成せず、リポジトリ情報を元に動作するエンジンとなっている。事例発表として金融機関で7,8行の導入実績の説明があった。700から1000人月の大規模開発を行っているという。
Magic xpa の代表的な大規模システム事例
マジックソフトウェア・ジャパン株式会社の渡辺様による発表。9つの導入事例発表があった。うち4つを列挙する。
事例その1。全国に累計10,000クライアントを導入、初期導入から10年以上経過。Web,C/S混在。その途中、Javaで作り直す事も検討したが、結局Magicに戻った。
事例その2。あるメーカのパッケージソフトはMagicで作られている。対象人数50,000人、Webサーバ10台、DBサーバ10台という構成。要件定義に時間がかかったがMagicによって製造工程を短期間で済ませた。ピーク時100人体制で製造した。Magicサーバをマルチインスタンス化することができる。WebサーバからMRB(Magicリクエストブローカ）をとおして最も負荷の少ないMagicサーバと接続するため、負荷分散によるレスポンス向上を実現している。
事例その3。20年以上、Magicを利用している。最初は個人レベルで7年ほどつくりつづける。UNIXパッケージソフトから移行のチャンスがあり、Magicで大規模開発を実証。現在、ホストの生産系基幹システムをMagicベースに移行している。同社はMagic開発者50名、ユーザー数は3000名。
事例その4。10年前のシステム（プログラム5000本）を6ヶ月で移行。システム開発自体はパートナー会社による。SIerによる見積1億円相当だったが、その数分の1で実現。
GeneXusを利用した大規模基幹システム開発
株式会社市進ホールディングスの今林様による発表。自社システム更改に際して7社コンペを行った。6つのシステム（汎用機、Web、C/S）を統合。開発期間は18ヶ月。既存システムはCOBOLによるスクラッチ開発だった。新システムの開発費は、その前にかけた開発費の1/4から1/5で済んだ。
採用したGeneXusはプログラム、データベース、画面を自動生成する。できるだけGeneXusに合わせるように心がけた。自動生成画面が99%。ツールで難しい部分はあっさり別システム化。開発時間のかかる帳票はBIツールを使った。
自動生成画面のため、UIに対する現場ユーザの満足度はそこまで高くないかも知れないが、変更要求には素早く応えている。そこに価値があると考えている。
プロジェクト成功の鍵は「提示されたままの画面を受け入れる」「課題は3日で決める」「安易な機能追加を認めない」というプロジェクト憲章を用意したこと。
ユーザー目線での成果は次のとおり。開発時は（ユーザー側、ベンダー側ともに）徹夜なし。予定通りのサービスインで、システムの並行稼働なし。全データを一括移行したところ、すべての機能が動作したので問題なかった。ただし当日、仕様が間違っていたということに気付いたことがあったが、すぐに修正できたので問題なし。過去にはカットオーバー当日、ボタンを押すと異常終了したという経験があった。自動生成ではそのようなトラブルがない。稼働後のバグが少なく、仕様違いの方が多い。
ユーザからのフィードバック要求はほぼ、画面に集中した。しかし3ヶ月我慢してもらったら、馴れていただけた。数画面のみ、カスタマイズで開発した。
まとめ
いずれの事例も、ツールが人間の能力を補助することで、本当に必要な箇所に人的パワーを集中し、プロジェクトを成功に導くような仕掛けを持っていることがわかりました。
最後の発表者である今林さんのコメントを転載して、まとめとします。
変化はコントロールできない。できることは、その先頭に立つことだけである。（ピーター・ドラッカー）
1社20分という短い時間での発表でしたが、各社ともポイントを押さえており、聴講する側は多くの知見を得られたのではないかと思います。発表者の皆様、ありがとうございました。
