2015-05-13スマートフォン用の表示で見るジャスミンソフト日記2015-05-13Wagby分科会の歴史と、第14回・15回Wagby分科会のご報告はじめに、これまでのWagby分科会をリストアップしてみました。今回は、第14回と第15回の報告です。(第16回目は今月25日に大阪で開催予定です。浩一様に基調講演をお願いしました。日経SYSTEMS誌で国内トップアーキテクトの一人として紹介された方で、同社代表として、産総研で培った製造・流通企業の基盤となる「包括フレームワーク」の展開を図っていらっしゃいます。林様のこれまでのご経験から、現在、発注側(ユーザー企業)は丸投げでも内製でもリスクを回避できないという悩みを抱えているが、Wagbyを知ったとき、このようなアプローチは「何を、どこまで」解決するかに興味を抱いたということでした。そこで、フルスクラッチの開発案件について、並行して同じものをWagbyでもつくってみた結果を考察されました。WagbyDesignerというツールへの依存性は生じるが、開発効率向上とトレーサビリティ維持の効果は大きい。開発経験のある技術者であれば実用上問題ないコードが生成されたことを確認。ソースコードが修正できるためロックインは限定的。Wagbyが生成できる範囲に収まるように要件を調整するスキルが必須。要件調整できないもののみをカスタマイズで対応することになる。(今回の案件では「複数データベースをまたぐ更新処理」をカスタマイズ)開発工程のコスト削減効果は確かにある。カスタマイズ量が増えると、効果を帳消しにしてしまうことにつながる。フルスクラッチの方がよかったという状態になってしまう懸念がある。Wagbyは少数の開発者で理解でき、開発・運用する場合には極めて有用。利用者視点を超えたシステム全体の最適化を俯瞰的に考える場合、アーキテクト的な役割が欠かせない。これらの知見をもとに「丸投げでも、内製でもない、第三の道」をご提案されました。発注側で開発の進め方と技術を統制し、PMOとアーキテクトを据えることが基本となる、ということです。その基本の上に、Wagbyのような超高速開発ツールを取り込むことで、効果が発揮されるというお話でした。向けのメッセージとして、今は「次期(基幹系)システムの枠組みをつくる重要なとき」であり、クラウドや超高速開発、オープンなミドルウェアといった技術を取捨選択しておくことの重要性を説かれました。自分なりのシステムのあるべき姿を語れる人材は希少なので、争奪戦になる。早めに方向性を打ち出すこと、というお話は、多くの参加者が納得されていました。和志様から「3年の運用を通してわかったWagbyの使いどころ」というタイトルでご発表いただきました。同社は興和株式会社の100%子会社となります。風邪薬のコルゲンやバンテリンといった名称で一般に知られています。それがWagbyを使って同社のコアとなる「店舗巡回(営業)報告ツール」「SPイベント管理システム」を開発・運用されています。店舗巡回では、巡回担当者がスマートフォンを使って現地の情報を本社にアップしていきます。2011年7月にWagbyを知り、二ヶ月ほどトライアルキットで感覚をつかんだところで開発に着手、最初のシステムリリースは1ヶ月で完了させています。月次業務報告やタイムシート、経費明細などのレポート機能も備えられました。運用開始後すぐに現場から「店舗報告の画像だけを一括閲覧したい」「メール送信したい」「販促物要望を管理したい」「予実管理したい」といった改善要望が上がってきますが、すべてWagbyで対応。このような、現場と一体感をもった開発と運用プロセスが実際に可能としているのは、たった一人の「データモデラー」の存在である、ということが明らかになりました。同社ではその後、イベント管理システムの早急な立ち上げの必要性が生じますが、4000現場以上の管理を行うシステムを一週間で構築されました。ユーザ自身が開発と修正を繰り返すことができ、プログラム知識がなくてもアプリケーションが手に入るという、Wagbyが実現したいテーマをまさに体現されていました。ここのキモは「業務に熟知した設計者の存在」に他なりません。さらなるWagbyへの要望として「UI改良のためのテンプレートの充実」「リファレンスモデル」「サードパーティによる業務部品の販売」「ユーザー視点でのマニュアル(現在のマニュアルはまだSIer視点で難しいところがある)」などがあげられました。様より行っていただきました。当初はパッケージの導入を検討されますが、自社業務とのフィット&ギャップで多数のカスタマイズが発生することがわかり、2012年からWagbyによる開発を着手しています。2013年から運用開始され、これまで細かい修正は続いていますが、大規模障害もなく、日々運用できているというお話でした。現在は少人数かつ完全な内製で保守体制を構築されています。当初は外部のJavaエンジニアを巻き込んで、複雑な業務ロジックのカスタマイズを行っていましたが、途中から「サーバサイドJavaScript」で可能なものはできるだけこの技術を使うようにし、Javaカスタマイズは限定する方針に。その結果、Wagby本体のバージョンアップ時に、保守すべき対象を削減できるようになりました。それでも数十本のプログラムは残っていますが、大半はデータ更新時の業務ロジックで、これは必要なものです。Wagbyのワークフローを使いこなしており、5階層から7階層のフローを複数、設定されています。ワークフロー状態を記録するテーブルはすでに数十万件のレコードに達しています。ワークフローが進むタイミングで業務ロジックを呼び出すといったカスタマイズも行っています。データ量や、モデル定義の規模のいずれも基幹系クラスということで、参加者からは「Wagbyで簡単にシステムをつくるというイメージをもっていたが、やろうと思うとこの規模まで定義できるというのは、改めて驚いた」という感想が相次ぎました。数百項目を一画面に表示していますが、レイアウトを丁寧に作り込んでおり、好感度のもたれる画面です。フォームを意識した画面になっているということでした。今後の要望として、同一ブラウザでタブを使った運用や、利用者が誤って「戻る」ボタンを押せないような仕掛けなど、現場担当者ならではの改善要望もいただきました。様には改めて感謝申し上げます。日々の業務が忙しい中、分科会のために一肌ぬいでいただけたご恩は、製品の改善と、いただいたご要望を満たすことで必ず、お返しできるようにします。第14回の分科会会場をご提供いただいたジェーエムエーシステムズ様と、第15回の分科会会場をご提供いただいたエフ・エフ・ソル様にもお礼を申し上げます。エフ・エフ・ソルの古宮様には司会によるまとめとして「Wagbyをさらに良くしていくために、ユーザやSIerが一緒になって知見を公開しあい、メーカーを巻き込むというこの流れを加速させたい」とおっしゃっていましたが、私もそのとおりと考えています。誰かが得をするではなく、関係者すべてにメリットがあるという仕組みがビジネスの基本です。Wagbyはツールとしても、またビジネスモデルとしても、なんらかの形を残せるよう、引き続き取り組んでまいります。次回は5月25日に大阪で開催します。こちらも基幹システムの適用事例となります。お申し込みはこちらです。操作するデモを行ったところ、非常に好評でした。このアプローチは受けそうです。使った例も技術者から喜ばれました。Streamはなれるまで時間がかかるかも知れませんが、Wagbyの繰り返しコンテナや外部キー子モデルの一括操作で効果を発揮します。整理して、ドキュメント化したいと思います。その思考は、未来設計から。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。