そごうソフトウェア研究所

SOA、開発プロセス、ITアーキテクチャなどについて書いています。Twitterやってます@rsogo

トップ > 企業のIT

Mule 3.5のセットアップとサンプルの実行

簡単 SOA 企業のIT ESB

会社の方で公式ドキュメントして書くのだけど、ひとまずこちらに書いてみます。

目標は、取りあえずインストールして、実行してみるところまで。

インストール

使用可能な環境はここでチェック。OSはMuleがサポートしているJDKがサポートしていればOKっぽい。

http://www.mulesoft.org/documentation/display/current/Hardware+and+Software+Requirements

どんな構成にするか

デプロイモードを選択する。

http://www.mulesoft.org/documentation/display/current/Deployment+Scenarios

ここでいうデプロイメントとは、Mule自体の配置のこと。Mule上で動作するモジュールのデプロイメントではない。

MuleはAPサーバー上でも動かすことができるけど、基本はスタンドアローンでOK。

Mule Management Consoleって使うの？

http://www.mulesoft.org/documentation/display/current/Mule+Management+Console

いろいろな管理機能が提供される。Enterprise Editionが必要。

インストールの手順はこれの「Mule Community Runtime」のタブに従ってやればOK。基本、スタンドアローン構成ならZipを解凍するだけ。

http://www.mulesoft.org/documentation/display/current/Downloading+and+Launching+Mule+ESB+-+hid

  1. Javaセットアップ Javaをセットアップして、JAVA_HOME設定

export JAVA_HOME=/usr/java/jdk1.7.0_60/

  1. Muleセットアップ 解凍するだけ。まじ簡単。

bin/muleを実行で起動。終了するときはCtlr＋C。

起動停止

$MULE_HOME\bin\mule.bat start|stop

起動オプションなんかは下記にまとまっている。

http://www.mulesoft.org/documentation/display/current/Starting+and+Stopping+Mule+ESB

自分で作ったモジュールを動かしてみよう

Anypont Studioを入れるとSampleが一緒に付いてくるから、それを実行してみましょう。

f:id:begirama:20140627084110p:plain

スタートページのOpen Sampleでサンプルの一覧が見られる。

f:id:begirama:20140627084119p:plain

まあ、最初はHelloWorldだろうと。

f:id:begirama:20140627084123p:plain

フロー定義の見た目はこんな感じ。 HTTPでリッスンして、文字列を返すだけのフロー。

取りあえず試すだけなら、Anypont Studioの中に埋め込みMuleが入っているのでプロジェクトを右クリックして、「Run AS-> Mule Application」でOK。

サーバー上のMuleへのデプロイは上記のURLの「Deploy on a Mule Enterprise Server」の通りにやればOK。

Anypont StudioでExportする

f:id:begirama:20140627084441p:plain

f:id:begirama:20140627084448p:plain

f:id:begirama:20140627084455p:plain

Muleへのデプロイ

Mule HOMEのappsフォルダにzipを置くだけ。 Muleがポーリングをしていて、しばらくするとzipが解凍されます。

[sogo@localhost mule-standalone-3.5.0]$ cd apps/
[sogo@localhost apps]$ ls
default  default-anchor.txt

appsフォルダにエクスポートしたhello-world.zipを置くと・・・・

[sogo@localhost apps]$ cp ~/hello-world.zip .
[sogo@localhost apps]$ ls
default  default-anchor.txt  hello-world.zip

しばらくするとzipが展開されてデプロイされている。

[sogo@localhost apps]$ ls
default  default-anchor.txt  hello-world  hello-world-anchor.txt

Muleのデプロイログ

同じタイミングでMule側のログには、サンプルアプリが置かれたことを検知して、インストールして起動した旨のログがでます。

INFO  2014-06-26 21:26:12,950 [Mule.app.deployer.monitor.1.thread.1] org.mule.module.launcher.ArtifactArchiveInstaller: Exploding a Mule artifact archive: file:/home/sogo/mule/mule-standalone-3.5.0/apps/hello-world.zip
INFO  2014-06-26 21:26:13,008 [Mule.app.deployer.monitor.1.thread.1] org.mule.module.launcher.application.DefaultMuleApplication: 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ New app 'hello-world'                                    +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
INFO  2014-06-26 21:26:13,009 [Mule.app.deployer.monitor.1.thread.1] org.mule.module.launcher.log4j.ArtifactAwareRepositorySelector: Found logging config for application 'hello-world' at 'file:/home/sogo/mule/mule-standalone-3.5.0/conf/log4j.properties'
INFO  2014-06-26 21:26:15,796 [Mule.app.deployer.monitor.1.thread.1] org.mule.module.launcher.MuleDeploymentService: 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Started app 'hello-world'                                +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

いやー簡単ですね。

ITmediaのセミナーでの成田空港さんの事例

UX Design 企業のIT モバイル

ITmediaさんのセミナーで、企業でのモバイルアプリの取り組みの事例などをお話しさせてもらいました。

そちらの内容は、別途、公開しますが、今日は同じセミナーで成田空港さんが事例を紹介されていましたので、Twitterの内容からまとめます。

元々はカウンターではNotesを使ってご案内ができていたが、後述の巡回案内ではNotesにアクセスできないという情報の差が課題だったそうです。Notesをモバイルで持ち出すというのは面白いですね。需要ありそう。

これは、いつもモバイルならではの使い易いUIにしましょうと、提案することが多いので、そうなんだ！と思いました。

これ、理想。

これは自分のセミナーでも同じメッセージです。 小さく、素早く始めて、利用状況を見ながら、改善していく。

iBeacon面白そうですね！

セミナーで話すよ！「実践的アジャイル開発入門　～SI、大規模システムにおけるリアルな導入事例～」

企業のIT 開発プロセス Agile

WebCatStudioさんとNCDCが共同開催するセミナー「実践的アジャイル開発入門　～SI、大規模システムにおけるリアルな導入事例～」で、これまでやってきたプロジェクトの中からいくつかピックアップして事例として紹介します。


僕は基幹システムのリプレイスプロジェクトと、オフショアプロジェクトの２つか、どちらかを話す予定です。他にも受託開発で比較的規模の大きなプロダクト開発の事例も同僚が話しますので、こちらも面白いと思います。


なるべく、プロジェクトで実際に起こった課題や、悩んだことなんかも話せたらいいなぁ。
お申し込みはATNDからお願いします。
http://atnd.org/events/38459


【追記】
夜遅い時間帯でしたが、多くの方に参加いただきました。ありがとうございます。
会社のブログの方に資料を公開しました。
http://nextconceptdc.com/practical_agile_case_study/

作るシステムの特性と、開発プロセスの相性

企業のIT 開発プロセス Agile

こちらのブログを読みまして、面白いテーマだと思いました。
アジャイルがダメだと思う7つの理由
"アジャイル"開発の長短みたいなのか。


よく「内製か・外注」か、「請負か・業務委託か」というのでアジャイルが向いているかどうかという議論があります。
他の要因として、作るシステムがどんなものかと、と開発プロセスには相性があるのではないでしょうか。

必要な機能が予想できるか

コンシューマ向けのシステムでは、どんな機能が使われるのか完全に予想するのは難しい。

企業内で使われるシステムであっても、業界内でも先進的なアプリケーションではれば、どんな機能が自社に必要なのか予想するのは難しいでしょう。
この場合、優先度の高い最小限の機能をすばやく実装し、ユーザテストをする手法が有効です。

一方、企業内のシステムの基本的な機能であれば、機能は予測し易い

受注、発注、会計のような基本機能はもう企業内に既存のシステムがあるでしょうし、ベストプラクティスを実装したといわれているパッケージソフトもあります。この領域のアプリケーションであれば、事前に調査することで機能を定義することはできそうです。
（その企業が例えば出荷の仕組みを独自にこれから新しい仕組みを作っていくんだという場合は、この限りではありません。）

また、企業システムの基本的なシステムであれば、一部は新しいシステムに実装されていて、残りは古いシステムに残っている状態で、ユーザの二重入力や、システム間のデータ同期はやりたくないので、リリースの単位も大きくなる傾向があります。
その為、リリースのロードマップとしては、A機能やってから半年後にB機能という機能単位ではなく、全てメインの機能をA事業部にパイロット導入し、次にB事業部といった導入になろうかと思います。

この場合、アジャイル的なプロセスのメリットのいくつかは関係ないでしょう。
パッケージを使ったプロトタイピング型の導入方法や、その他の条件でウォータフォールやアジャイルを選択することになるのではないでしょうか。


下記でやっているプロジェクトでは、２つめのパターンに近いので変化への対応という観点ではアジャイルのメリットは小さかったのですが、内製で細く長くシステム開発を続けるために、チームの学習という効果に着目してアジャイルを取り入れた開発プロセスを採用しました。

アジャイル開発プロセスへの様々な関係者からの期待値とプロジェクトスタート
改善した開発プロセスを評価する。定量評価だけではなく、情報システム部門の戦略にあっているか？

アジャイル開発プロセスへの様々な関係者からの期待値とプロジェクトスタート

企業のIT 開発プロセス Agile

半年ほど前に改善した開発プロセスを評価する。定量評価だけではなく、情報システム部門の戦略にあっているか？と題したエントリーを書きました。

とあるプロジェクトでどのような開発プロセスを採用するかを、このころ検討していました。

その後のプロジェクト運営と、周りの評価を何回かに分けて書いていきたいと思います。

http://cdn.morguefile.com/imageData/public/files/h/hotblack/preview/fldr_2008_11_02/file0001710806888.jpg


事前の関係者の開発プロセスへの期待値


  • プロジェクト全体のコストを抑えたい

  • 短期間での大きなキャッシュアウトを避けたい

  • 外部に丸投げではなく、自社グループの社員を主体（少なくともPM層と技術リーダ層）とした体制

  • 保守局面で必要な情報はドキュメントとして整備されてなくてはならない


これらのいくつかは業務や既存の運用を理解している自社グループの社員＋技術スペシャリストから構成される比較的小さなチームの元、繰り返し型の開発プロセスを採用することで達成できるのではないかという方向に決まりました。

プロジェクトのスタート

そして、１ヶ月を１つの単位とするイテレーションを最小し、プロジェクトをスタートさせました。
１ヶ月の根拠は、チームはウォーターフォール型のプロジェクトしか経験がなく、２週を単位とすることで混乱が起こるのを避けたかったというのが大きいです。
結果としてこの１ヶ月という期間の設定は、このチームでは成功だった思います。ちょうど良く設計、実装、テスト、振り返りがまわりました。


かなり大きなシステムだったので、１ヶ月単位でもかなりの回数の反復が行われ、チームの知識や、技術の学習効果も期待できました。


別のプロジェクトでは１週間ごとの顧客レビューを目標にイテレーションしています。この別のプロジェクトでは設計書はかなり軽量で、チケットや、打ち合わせで仕様を都度詰めながら、テスト後に修正しながら進めていましたので、作るシステム、チームの文化に強く依存するなぁと感じています。

改善した開発プロセスを評価する。定量評価だけではなく、情報システム部門の戦略にあっているか？

企業のIT 開発プロセス

今、基幹システムのリプレイスプロジェクトのパイロットとして、開発プロセスをこれまでのウォータフォールから、短期間でイテレーションを繰り返すアジャイル的な要素を組み入れた開発プロセスに変更してみて、内製化ができるか、工数がどう変わるのか、どのようなリスクが増えて、減るのかを検証しています。


今日議論になったのが、これまでの開発プロセスと、今考えている開発プロセスと比較して、どこかでどちらで行くのかを判断しないといけないと言うことでした。


で、新旧開発プロセスの比較評価が難しいね、と。
今のパイロットプロジェクトの要件では、新しい開発プロセスでしかシステム開発をやっていないので、実績としては新開発プロセスのものしか取れません。
逆にプロジェクト開始当初にウォータフォール式で行った見積もりは存在しています。ただ、その時点では新開発プロセスは初挑戦で見積もり根拠が無かったので、プロジェクト当初の見積もりはありません。存在していたとしても精度がかなり低いでしょう。


ウォータフォール式の見積もりと、新開発プロセスの実績を比較するのでいいの？
開発が終わったときに、要件やリスクがすでに分かっている状態で新開発プロセスで再見積するのは、プロジェクト当初にリスクをいっぱい積んだ見積もりと比較できるの？
という議論になりました。


個人的には、工数のような定量的な比較も重要ですが、内製化の方針をとるならどちらが向いているのか、PMのリスクの感じ方、本番の基幹リプレイスで人数が増えたらどうなるの？といった定性的な評価もして選択すれば良いと思います。
結果として、新開発プロセスが今の会社の方針に合っているということが言えれば、工数の様な定量比較は厳密な比較は不要で、目標の工数内に収まるのならそれで良いじゃないかと割り切ることもできると思います。

ITシステムは変わっていく前提、連携していく前提

企業のIT

お客さんと企業内のITシステムの課題についてディスカッションを行いました。

情報システム部門としては次の相反した要求に応えていく必要があります

  • ユーザ部門からは新しい機能のリクエストがでてくる
  • 情報システム部門としてはコストを下げる必要がある


単純に新しいことをやるために必要なお金（新規機能分の費用）以外に、今持っているITシステムのしがらみのために使うお金の割合が結構大きくなってしまうのも上で書いているやりたいことをじゃまする原因になっているなぁと感じます。

例えば、新しい機能で使うデータを別のITシステムから取ってくる必要があるけれど、そんなつもりで元々作って無いから、データを出力するための準備がすごく大変、とか。

数十年前に導入したITシステムを新しいものに代えたい。
でも他のシステムになるべく改修費用をかけないために、せっかく新しいものを入れるのに、これまで通りのお作法でやらないといけない、とか。


これを変えるには、少なくともこれから作るITシステムは、どんどん変更が行われる前提、他のITシステムや企業外のITシステムともつながる前提とした設計で作っていかないといけない、ということを改めて感じました。