翔泳社主催によるITカンファレンス「Developers Summit 2006」が、2月9日、東京・目黒雅叙園で開幕した。今年の同カンファレンスのテーマは「Developers 2.0」。主催者によれば、「Develpers 1.0」とは、アプリケーションを書ける、プロジェクトの中での自分の役割を理解している、自分の仕事を人に説明する能力がある開発者を指し、対する「2.0」は、より高い志と、より広い視野を持ち、より深い洞察で未来を見据えることのできる人々のことだという。
今回用意された70の無料セッションは、ユーザー企業の視点から話される「カスタマーズオピニオン」や、ITアーキテクチャの構築技術に関する「アーキテクト」のほか、「開発テクノロジー」「ファシリテーション」「プロジェクトマネジメント」「組込みソフトウェア」といった6つのテーマに分けられており、会場は初日から大勢の開発者でにぎわった。
「天使のSE」に必要な知恵とは？
9日に行われた「天使のSEと呼ばれる知恵 −現場ユーザーにもわかる業務フローはこれだ！」と題するセッションは、サントリー情報システム事業部システム開発部課長の片山隆氏によるもの。グループ会社の業務内容変更に伴って、自ら輸入仕入業務の設計を行う必要に迫られた片山氏は、業務フローの作成に当たって、自ら開発した「DWF」と呼ばれるモデリング手法を利用したという。このセッションでは、実際の事例と照らし合わせながら、DWFの概要や利用した場合のメリットなどが紹介された。
片山氏が業務フローを作成するに当たっては、UMLなどの利用も検討したものの、「独自の様式でも、より万人に分かりやすい表現方法」を使う必要性を強く感じ、それがDWF開発の動機付けになったという。
DWFは、業務の全体像を把握するための「業務フレームワーク」、個々の業務の流れを表す「タグフロー」、各業務の内部での情報の流れを表す「業務フロー」の3種類の図から成る。それぞれの図は、作業内容や判断処理などを表す10個程度のアイコンを基本に構成され、チャート化しづらい内容については自然言語による「コメント」もふんだんに利用することによって、システム部門の担当者や開発者のみならず、現場ユーザーにとっても理解しやすい業務フロー図の作成を目指すものだ。
片山氏は、業務フローの用途として「業務設計」「システムの要求定義」「あらゆる関係者の業務理解」の3つを挙げた。DWFの方法論を使って作成された業務フローは、開発者の業務理解や、担当役員向けのプレゼンテーション、業務の引き継ぎなどのあらゆる面で利用できるとした。また、DWFで作成した業務フロー図を、UMLで定義されたユースケース図やクラス図などへ落とし込むことも容易であり、実際の開発工程への展開のしやすさもメリットのひとつであるという。
片山氏は、若い技術者へのメッセージとして「業務設計に携わる機会は多くないかもしれないが、業務フローにすべき題材は身近にたくさんある。身近な題材をモチーフとして訓練を積み、分かりやすい業務フローを書くスキルを身につけることで、現場ユーザーにも信頼される“天使のSE”になってほしい」と述べて、セッションを締めくくった。
SOAにまつわる10の疑問に答える
- 日本BEAシステムズ、プロフェッショナルサービス本部プリンシパルコンサルタントの岡嵜禎氏
日本BEAシステムズ、プロフェッショナルサービス本部プリンシパルコンサルタントの岡嵜禎氏による「現場コンサルタントが語るSOA10の疑問」と題されたセッションは、ベンダーコンサルタントの立場で、ユーザーから寄せられるSOAに関するFAQに答える内容だ。
「そもそもSOAって何？」という問いに対し、岡嵜氏は「現在、SOAという言葉はベンダーが製品を売る際のキャッチーなキーワードとなっている」とした上で、狭義には「これまで“ソフトウェア部品の再利用”と呼ばれていたものとほぼ同義」、広義には「今後、企業システムを作っていく上で選択肢となるアーキテクチャのひとつ」と述べ、「SOAの導入に当たっては、全社最適の考え方に立ち、実現したい効果を明確にすることが重要」とした。
また、「SOAはどこから始めるべきか？」という問いについては、膨大な業務処理を分析して共通のサービスを抽出するトップダウンのアプローチと、ビジネスエンティティを抽出して随時サービス化するボトムアップのアプローチがあることに言及。ただし、トップダウンの場合には、規模が大きくなると作業負荷が増大して進行が滞りがちになる、ボトムアップの場合には、部分的な対応から始まるので全体での変化が分かりづらいといったデメリットがあるとし、実際にはそれらの複合的なアプローチが、最も進めやすく、効果も分かりやすいとした。複合アプローチでは、全体の業務処理の中からキーとなるビジネスプロセスを抽出し、サービス化によるプロセスの再構築を行っていく。その際に、標準的な手法やルールをしっかりと定義することが重要であるという。
「最も多く寄せられる質問」として挙げられたのは、「サービスの粒度はどう決めればよいか」に関するものだ。岡嵜氏は「（サービスの粒度を決めるに当たっては）絶対的な方程式はない」としつつ、サービスの定義を決め、それぞれの業務システムの中で使われている機能を用途別に分析することによって、最適な粒度を割り出すことは可能だとした。
SOAを実現する際にエンジニアに求められるスキルとしては「最新の技術力」に加え「業務モデリングのノウハウ」「プロジェクト間の調整力」「コンサルティング能力」などを列挙した。「非常に高いスキルが要求されるが、SOAに関わることは技術者がステップアップするためのチャンスである」（岡嵜氏）とし、より多くの技術者が自らのキャリアプランの一環として、積極的にSOAプロジェクトに取り組むよう促した。
