私が Workflow Foundation に魅せられたわけ

スキル

» 2011/10/31

　今までに何度か、私が趣味で調べている技術として .NET の Workflow Foundation がある、ということを書きました。.NET 3.0 のリリースと共に提供され始めたこの技術ですが、日本においては残念ながらあまり利用されていません。Microsoft の Sharepoint Server や Team Foundation Server 関係にて利用されている部分がせいぜいです。このような状況となった背景として、ワークフローという言葉が持つ意味合いがあるのではないかと考えています。

　皆さんがワークフローと言われてイメージするのは、恐らく「社内で書類を回覧する」際の仕組みではないでしょうか。書類の提出を行った際に流れる経路、そしてその途中途中で行われる独自のアクション（提出者への通知など）を行う物＝ワークフロー、というイメージが大半なのではないかと思います。

　しかし、本来のワークフローとはさらに広義な意味を持ち、「組織的・企業的な活動を反復的な行動として表すためのもの」、と書かれるように非常に広範囲です。上記の書類提出というのはワークフローにて定義・表現するのに非常に適していたため、狭義のイメージが浸透してしまったのではないかと思われます。

　このようにイメージが先行していたことがあるのと、実際にどのように利用するのが適しているかが掴みにくい事からも Workflow Foundation はなかなか利用する機会がありませんでした。私も .NET 3.0 リリース時にはかなりの期待を持ちつついろいろと調査を行い、実際に利用してみたりもしたのですが業務にて利用する事はありませんでした。その流れもあり、.NET 4 が登場しかなり機能が強化された WF4 が登場したタイミングでは、なかなか食指が動かなかったりもしました。

　そのようなこともあり、私の記憶の中から WF という存在が忘れ去られようとしていた時、唐突に思い出すことがありました。

　私は業務で時々、スクリプトを作成します。簡単なバックアップを行うものであったり、ソースがコミットされた際にビルドを走らせたり、小さいアプリの環境設定などいろいろな種類のスクリプトを作りしました。

　もともと、これらのようなスクリプトを作成する理由として「作業の定型化」があるかと思います。ところがそのように定型化するためのスクリプトを作成しているうちに、「全体が大きくなりすぎて追いかけにくいなぁ」とか「あのスクリプトのここだけ欲しいけど別スクリプトにしてコールするのもなぁ」、「他の人にスクリプト作成頼みたいけど教えるほど時間がないんだよな」という感じに、面倒を感じることが増えてきたのです。「ある程度仕様を考えている時のチャート、をそのままはき出してくれれば楽なのに」、都合の良い考えですが同じように思われる方は多いのではないでしょうか。

　そのような時に思い出したのが、 WF でした。WF はコードでも記述可能ですが、デザイナにより見た目に分かりやすい形での利用が可能です。ましてや WF4 で新たに登場したフローチャート型ワークフローは、スクリプトを作成中に感じた面倒を解消する理想形に近い物でした。私はどちらかと言わなくても古いタイプの考え方ですので、よく頭の中で処理フローをイメージすることがあります。WF を利用すればそれをそのまま実行形式に落とし込むことも可能なのです。

　残念ながら、状態遷移型ワークフローは .NET 4 標準では提供されませんでしたが、後々のアップデートにて利用が可能になっていますし、.NET 4 のみだとしても Codeplex にてその前身が提供されています。これで WF3 時代にできていたことは一通りできる形になりました。

　一通りのことができると分かり、実際にスクリプトを WF に移植してみました。その際に数人に見てもらったのですが、Visual Studio がなくともデザイナーを利用することができる点や、Visual Studio があればもっと多くのことができる点などは、一緒に働いている面々にもなかなか好評でした。

　なにより、スクリプトで作成している場合は行数が多くなりがちで、なかなか全体を通してイメージを掴むことが難しいこともあるけれど、 WF であればかなりイメージを掴みやすいのが好評の理由だったと思います。また細かいロジックはアクティビティというコンポーネントにより隠蔽されるのも、全体を掴みやすくするのに一役買っていたのではないかと思います。

　そうこうすることで、WF の適した利用場面というのもある程度、思いつくようにはなりました。今回のケースのようにスクリプトを置き換えるというのも1つですし、既存ワークフロー製品で利用するというのも一つです（この場合は状態遷移型が適していると思います）。またイントラネットで Web サービスを急いで構築するようなケースにも向いていると思います。このような事を考えているうちに、どんどんと WF というものに魅入られてしまったのだと思います。おかげで「アクティビティ化すると気にならないから実際のロジックは（ある程度）どうでもいい」と、プログラマらしくない考え方に最近は染まってしまっています。このあたりはコンポーネント指向の良いところと悪いところなのかもしれません。

　また、もう1つ私の中でメリットと感じている点が「1つのアクティビティを作るのが非常に楽」ということです。

　実際に1つのアプリケーションを作成しようとした場合、結構な量のコードが必要になると思います。ですが、アクティビティはあくまでも1つのコンポーネントであるので、アプリケーションと比較するとものすごく少量のコードで済みます。大きいアプリケーションは作ることもテストすることも大変ですが、小さいアクティビティであれば、作ることもテストすることも、比較的容易です。小さなアクティビティを組み合わせ大きなアプリケーションを作成する、これはモジュール化やクラス化などで行おうとしていることとまったく同じなのです。同じことなのですが、明確に独立しているアクティビティはモジュールやクラスライブラリ作成と比較しても、やはり作りやすくなる面があるのだと感じています。

　まだまだ日本語の情報量が少なく試してみるだけでも苦労する状態ですが、少しずつ改善されていくことと思います。Visual Studio Express Edition しか持っていなくとも WF が利用できることを見てもらえるように簡単なツールを Codeplex にて公開しています。興味のある方は是非、触ってみてください。コラムも同じですが、何かしらの反応があるととても嬉しいものだったりしますので。

Flowchart
※WF4 でのフローチャート型ワークフローのサンプルイメージ