.NETによる大規模システム開発で失敗しないために

マイクロソフト株式会社コンサルティング本部
赤間信幸

マイクロソフト株式会社 コンサルティング本部 赤間信幸氏

　大学院卒業後、最初に独立系大手システム・インテグレータに就職し、主に業務分析・設計、J2EEシステムの開発などに2年半ほど携わりました。

　その後、いまから4年ぐらい前になりますが、マイクロソフトコンサルティング本部へと転職しました。この業界に入ってから転職した時期が早かったということもあって、私自身、正直なところテクノロジのことをあまりよく分かっていない状態でした。幸いにも、弊社のコンサルティング本部は勉強できる環境やリソースが整っているうえに非常に優秀な先輩方も多く、最新テクノロジについて、仕事を進めながら勉強できました。また、さまざまなお客さまと接することで、IT導入現場の多種多様なニーズを知ることもできました。

　現在の担当は、主にアプリケーション開発のご支援です。Webアプリケーション開発には限らないのですが、特にアプリケーション・アーキテクチャについて、例えばレビューや提案などを中心にコンサルティングさせていただいています。

　製造系、公共系、金融系など多岐に渡っています。業種という点ではばらばらですが、テクノロジという意味でいうと、主にアプリケーション・アーキテクチャにフォーカスしています。もっと身近な言葉では「開発標準」といった方がいいかもしれません。

　システム開発の初期フェイズには、「業務設計」と並列して行われる「方式設計」と呼ばれる作業があります。私が主に担当しているのは、この部分になります。つまり、ビジネス・ニーズを満たすシステムを、各種のマイクロソフト製品群をどのように活用すればベストな形で作り上げていくことができるのかを考える、という部分についてご協力させていただいています。

　例えば、わたしが携わったものの1つにNECさんの「GAUSS」という基幹系システムがあります。これはプロジェクトの初期フェイズから入らせていただいた例です。このシステムは、日本国内の大規模.NET事例の1つであるだけでなく、SCMプラットフォームとしてもユニークで非常に興味深いものであるため、弊社の事例サイトでも詳細に紹介しています。大規模開発の考え方やコンサルティングサービスの関わり方を知るためのよい参考事例になるかと思います。

1. NECのノウハウと.NET Frameworkとの融合で実現された「変化に強い基幹システム」

2. 業務と組織の変化に強い基幹の SCM プラットフォームを実現 〜Microsoft .NET Framework で構築された新発想のシステム「GAUSS」を追う

　このような大規模プロジェクトで設計のレビューをさせていただいたり、あるいは一緒に考えてほしいという依頼を受けてプロジェクトに入らせていただいたりします。もちろんプロジェクトの途中から入るケースもあります。

　私が行っているようなアプリケーション・アーキテクチャ・コンサルティングのほかにも、弊社ではさまざまなコンサルティングを行っています。

　例えば、ネットワーク基盤のコンサルティングを担当しているコンサルタント、あるいはシステムの効率的な運用にフォーカスしているコンサルタントもおります。また、情報システム部門の方々といっしょになって、戦略的な情報システムの中長期計画を立案するようなコンサルティング・サービスも提供しています。

　お客さまのニーズによりさまざまなケースがあります。既存のシステム環境と融合することも多く、他社のデータベース製品が入っているケース、あるいはメインフレームと連携するケースなども多々あります。現実には、疎結合による連携の話を抜きにしても、既存のインフラや既存のシステムを切り離してシステム・インテグレーションを考えることはできません。

　私たちマイクロソフトのコンサルタントは、お客さまのシステム開発プロジェクトを成功させること、お客さまにご満足いただくことを第一に考えています。そのため、既存の他社データベース製品と連携するケースもありますし、既存のCOBOL資産を活用できるような形でシステムを設計していく、といったケースも多々あります。その辺りは、お客さまの環境、実情に応じて対応させていただいています。

　開発標準というと、コーディング標準のようなものを思い浮かべる方が非常に多いと思いますが、実際にはそれだけではありません。

　業務アプリケーションは、それが論理的にすっきりした形で作られていて、誰が見ても同じような構造を持つように一定の形で作られ、保守性があり、なおかつスムーズにバージョン管理やリリース管理ができるようになっている必要があります。

　大規模なアプリケーション開発ではこうしたことは極めて重要ですが、これらを実現するために用意されるものが開発標準ということになります。ここまでの話からもご想像いただけるように、これらはとてもコーディング標準だけで実現できるものではありません。

　開発標準の中核となるのはアプリケーション・アーキテクチャですが、これについてもう少し詳細にお話しすると、いくつかのキートピックがあります。

　例えば、業務設計の中には、時間とともに変化する部分と、時間がたっても変わらない部分があります。アプリケーション・アーキテクチャの策定では、このうち変化しない部分、つまりコア業務、コア・サービスになっているものが何かを識別することが第一歩となります。

　また、大規模なアプリケーションは、サブシステムや業務単位に分けて開発作業を進めることになります。分割をしないと分散開発や分担開発ができません。このためには、アプリケーションを正しく構造化しなければなりません。

　あるいは、コンポーネントの分割ルールを決定する必要もあります。アプリケーションを個々のサブシステムに分けたところまではよくても、それらの各サブシステムの内部がまったく違う形で作られているのでは保守を行っていく際に困ります。こうした問題を避けるため、コンポーネントの作り方を標準化します。具体的には、コンポーネントの分割指針や役割分担、トランザクションの制御方針を定めたりします。

　さらに、要求されるパフォーマンスやセキュリティ、信頼性といった非機能要件を踏まえて、論理的に分割されたコンポーネントをいかに展開するか、つまり論理設計と物理配置のマッピングを考える必要もあります。この他にも、共通基盤部品として、あるいはフレームワークとして何をそろえておくかといったことも挙げられます。

　お客さまによって、変わるものと変わらないものがあります。例えば最近、フレームワークという言葉を頻繁に耳にしますが、フレームワークといっても業務依存のものと非依存のものとに分かれます。

　業務非依存の部分については、確かにお客さまによらずほとんど変わらない部分があります。例えばアプリケーションのトレースをどう取得するのか、あるいは例外をどう扱うのかなどです。これらは変わりません。

　しかし、これらが業務の話になると、例えばサプライチェーンをどのように取り扱うのが最適な処理モデルとなるのかとなれば、これはビジネス・ドメイン領域の話になり、お客さま個別の話になります。

つまり、お客さまによって変わらない部分と変わる部分を適宜組み合わせつつ、最適なアプリケーション・アーキテクチャを提案していく、ということになります。

　いえ、両者はイコールではありません。開発標準というのは、設計思想たるアプリケーション・アーキテクチャによってそのアプリケーション全体の設計を均質化するという意味で、非常に重要な位置を占めます。しかしアプリケーション・アーキテクチャや、それを元に定めた設計ルールを守れるかどうかは、プロセスの問題などもあって、それほど簡単な問題ではありません。ですから、実際にアプリケーション・アーキテクチャを定めるだけでは、開発標準としては不十分です。

　例えば、開発段階から運用段階へといかにスムーズにつなげるかという開発プロセスの規定や、日々の作業をしやすい開発環境の構築、あるいは大規模開発に携わる複数の開発者間でどうやってスキル・トランスファーしていくかも検討しなければなりません。そのためには、教育カリキュラムの作成、ドキュメント整備、品質チェック・ツールの作成なども必要になるでしょう。あるいは、作成したアプリケーション・アーキテクチャが「絵に描いた餅」にならないようにするためにも、どうやって開発チームの方々に展開し、活用していただくのかについても併せて考えなければなりません。そうした部分までカバーして、初めて開発標準といえます。

　また、ここまでお話ししてきませんでしたが、アプリケーション・アーキテクチャの分野には「複雑で見栄えのよいもの」が良しとされる風潮や傾向がありますが、個人的には異を唱えたい部分です。アプリケーション・アーキテクチャの目指すところは設計品質の均質化なのですから、開発者の方々が理解できなくなるほどに複雑なものになってしまっては本末転倒です。また、そのアプリケーション・アーキテクチャが一方的な押し付けにならないよう、開発チームから適切なフィードバックを受けることも大切だと思います。ですから、アプリケーション・アーキテクチャは「Simple is the best」を心がけて常に最適化を図り、そのうえで開発標準に発展させて開発チームに展開し、そのフィードバックを受けて成長させていくのが望ましいと考えています。