第 8 号
第 8 号
30 31 32 33第 8 号
アプリケーション基盤の
標準化に向けた取り組み
Approach to Standardization of Application Architecture
末森 智也 増田 浩士
SUEMORI Tomoya MASUDA Hiroshi
1. 開発領域の変化
2. アプリケーション構築に必要な３要素
参考文献 [1] 谷川英和、河本欣司：特許工学入門、中央経済社、(2003) [2] 谷川英和、田中克己：3種類の特許部品データベースに基づく 特許明細書生成エンジンの構築、情報処理学会論文誌 データ ベース(TOD)、Vol.30号、 (2006) [3] 特願2006-124598、「クレーム従属関係図生成装置等」 [4] 新森昭宏、奥村学、丸川雄三、岩山真：手がかり句を用いた 特許請求項の構造解析、情報処理学会論文誌、Vol.45、No.3、 pp.891-905、(2004) [5] 特許第3908261 号、「修辞構造解析システム」 [6] 谷川英和、新森昭宏、大屋由香里： 言語処理に基づく特許 価値評価支援システムと特許読解支援システム、第４回日本 知財学会学術研究発表会、(2006) [7] 新森昭宏、大屋由香里、谷川英和：特許請求項における多重 多数項引用の検出と書換、情報処理学会第69回全国大会、 (2007)特集
IT基盤の最適化
参考文献 [1] 南波幸雄：企業インフラの構成とアーキテクトが押さえる べきポイント, ＩＴアーキテクト, Vol.10, pp.32-37, ＩＤＧ ジャパン, (2007) [2] 仮想化, IT Keywords 2008, pp.6-7, 日経ＢＰ, (2007.12) [3] 2006年上半期のブレードサーバー出荷台数 前年同期比 46.3%増の1万6534台, ＩＴマーケットデータ年鑑2008, p.44, 日経ＢＰ, (2008) [4] ストレージの市場規模は2011年には7264億円に, ＩＴマー ケットデータ年鑑2008, p.66, 日経ＢＰ, (2008) 開発領域の「差異」を正しく認識していない場合、例えば 開発後半で性能要件を満たすために広範囲に渡って見直しが 必要になるなど、大きな手戻りが発生する可能性がある。 このような結果にならないためにも、通常、一斉開発を行 う場合は品質や納期が保てるよう、プロジェクトの初期段階 でプロジェクト特性に合わせ、図２に示す３つの要素を準備 する必要がある。概要
標準化とは「質、形状、大きさ、方法などに基準を設け、それに統一することにより、同じような結果を得られるよ
うになること」を指す。標準化の動きは今に始まったことではないが、ここ最近の業界的な「標準化」の流れの中、
当社としても標準化への取り組みを続けている。以前から開発プロセスの標準化と改善活動を進めてきたが、今
回はその中で「アプリケーション基盤」に着目し、組織的な改編も含めて、その取り組みを推し進めてきた。本稿で
は当社におけるアプリケーション基盤の標準化に向けた取り組みを具体的に紹介するとともに、その重要性を示す。
近年急速にニーズの拡大したオープンシステムは、メイン フレーム等の従来型システムとは開発領域が大きく異なって いることを正しく認識しなければならない (図1)。 従来型システムではハードウェアからミドルウェアまでが ベンダーからセットで提供されていた。したがって、お客さ まにとっての最適なソリューションを提供するために、これ らの組み合わせを検証する必要がなかった。このため、開発 領域は業務アプリケーション部分のみに絞られ、業務的な専 門知識と特定のメインフレームの知識さえ持っていれば、お 客さまの要件を満たすことができた。 一方、オープンシステムではハードウェア、OS、ミドルウェア、 フレームワークなどが多種多様となり、これらを無数の組み合 わせの中から選べるようになった。選択肢が広がり、お客さま にとっての最適な組み合わせを選択できるようになった反面、 選択した組み合わせを検証し、品質を保証するためには、特に ミドルウェアやフレームワークに関する高度な専門知識が必要 不可欠となっている。つまり、オープンシステムの開発領域は 業務アプリケーションのみならず、これらの基盤となるミドル ウェアやフレームワークも含まれるようになったと言える。 オープンシステムの開発プロジェクトではこのような開発領 域の変化を十分に認識しつつ、計画に盛り込んでおかなければ ならない。 図１ 従来型システムとオープンシステムの開発領域の差異 図２ アプリケーション構築に必要な３要素 (１) フレームワーク 「フレームワーク」とは、開発者があらかじめ定められ たアーキテクチャに則って開発していけるよう、アプリ ケーションに共通する機能を汎用的な形で提供するプロ グラムのことを指す。開発者は固有の機能をフレームワー クに当てはめて開発できるため、例えばデータベース接続 などの共通部分を開発する必要が無くなり、意識せずに高 品質で統一感のあるプログラムを作成することができるよ うになる。 (２) 実装ガイドライン 「実装ガイドライン」とは、プログラミングを行う上で の決まり事をドキュメント化したものを指す。プログラム のロジックは色々な書き方ができるため、ある程度決まり 事が無ければ、その書き方は開発者によって千差万別と なってしまう。このためプログラミングをする上での決 まり事をガイドとして明文化し、開発者間で共通認識とし て持たせる必要がある。またフレームワークはその中身を 理解しなくても使えるところに価値があるため、開発者が ソースコードを見なければ使いこなせないフレームワーク では意味がない。したがって、フレームワークを使ったプログ ラミング方法のガイド、すなわち実装ガイドラインが必要となる。 (３) リリースできる品質のサンプルプログラム 「リリースできる品質のサンプルプログラム」とは、 フレームワーク上で実際に動作するプログラムのサンプル を指す。 実際にフレームワーク上で動作するサンプルを作成する ことにより、フレームワーク及びフレームワークを使った プログラムの動作検証を同時に行えるというメリットもあ る。理論的には実装ガイドラインさえあればフレームワーク を使った開発は可能であるが、実際には活字だけでは伝わ らない部分も多い。このため実装ガイドラインの他に、実 際にフレームワーク上でどのように実装したら良いかを示 す見本が必要である。開発者にとってサンプルプログラム は単なる参考例ではなく、本番アプリケーションをプログ ラミングする上での原型となる。サンプルプログラムに誤 りがあれば、それを原型としたプログラムには全て誤りが あるということになり、修正する手戻りも大きい。した がって、サンプルプログラムは単なる例として捉えるの ではなく、全てのプログラムの原型となることを意識して、 リリースできる品質のものだけを開発者に提供すべきであ る。そのためには、レスポンスやセキュリティなど非機能 的な観点からも検証が必要である。例えば、サンプルプロ グラムが組みあがった段階で負荷テストを実施し、フレー ムワーク及びフレームワークを使ったプログラムにボトル ネックが無いことを展開前に保証しておかなければならない。 以上の３点を準備することは、いわばアプリケーション“開発” 基盤の構築であり、「一斉開発をスムーズに進めるためのレール 作り」ともいえる。開発者全員がこのレールに沿って開発するこ とで、統一感があり保守性にも優れたプログラムが出来上がり、 品質も保証される。もちろん開発者が多ければ多いほどその 効果は高くなり、アプリケーション開発基盤の重要性は増していく。 当社では、特に大規模なプロジェクトにおいて、アプリケー ション基盤構築の重要性を認識し、様々な取り組みを行って きた。次章ではこれらの具体例を挙げ、その内容を紹介する。3. アプリケーション基盤構築に関する活動
当社ではアプリケーション基盤を効率良く構築し、効率良く 普及させるために、試行錯誤しながら様々な取り組みを行って きた。今回はその中で特に注意が必要な以下の３点を取り上げる。 ● アプリケーション基盤構築タスクの整理 ● 設計書の標準化 ● ノウハウの蓄積と展開3.1 アプリケーション基盤構築タスクの整理
プロジェクトの中でアプリケーション基盤を構築する際に、 最初に行わなければならないのは作業項目の洗い出し、すな わちタスクの整理である。当社で作成したアプリケーション 基盤構築タスクは表１のとおりである。 見てのとおりアプリケーション基盤構築の主たる作業は、 第１章で述べたようにフレームワークの作成、実装ガイドラ インを含む開発標準の作成、及びサンプルプログラムの作成 の３点、すなわちアプリケーション開発基盤の構築であるが、 その他にも非機能要件の検証や開発環境、構成管理の検討な ど作業項目は多岐に及ぶ。 ここで注意しなければならない点は、アプリケーション基 盤構築作業の大部分が要件定義フェーズで行うべき作業であ るということである。この理由は２つある。 １つ目の理由はアプリケーション基盤の変更は莫大な修正コ ストを要するということである。アプリケーション基盤構築 作業で作成した成果物は全てのプログラムの根源となるため、 一旦開発がスタートしてからこれを変更するとなると、影響度 を入念に調査し、場合によっては基本設計段階にまで遡り、全 てのプログラムの見直しを迫られることになる。このようなこ とにならないためにも、アプリケーション基盤はプロジェクト 初期段階で、且つ慎重に決定する必要がある。 ２つ目の理由はアプリケーション基盤の決定が開発コストを 大きく左右するということである。開発に関わる人数やスキル、 コストやスケジュール、品質など、求められる特性は通常プロ ジェクト毎に異なり、フレームワークやサンプルプログラムは、 それらの特性を踏まえた上で課題を解決できる構成としておく 必要がある。このため、プロジェクトの早期段階で要件の実現 可能性の検証を行っておかなければ、結果として開発コストに 大きな影響を与えてしまうことになる。また、アプリケーション 基盤の構成はインフラ基盤の構成にも多大なる影響を及ぼすた め、可能な限り早期段階で決定しておくべきである。 表１ アプリケーション基盤構築タスク 図３ 設計書の標準化とブラッシュアップ3.3 ノウハウの蓄積と展開
各プロジェクトにおいてアプリケーション基盤を毎回個別に 構築するのは非効率的である。また、それらが個々のプロジェ クトに点在していては、別のプロジェクトから情報を収集する 際にも時間や手間がかかってしまう。一度構築したアプリケー ション基盤は、少なからずプロジェクト特性に合わせてカスタ マイズする必要があるが、各プロジェクトでテンプレートとし て再利用することが可能である。したがって、こうした成果物 はプロジェクト毎に分散させずに、一箇所に集中させ、ノウハ ウとして蓄積し、そして全社展開していくべきである。 当社ではこの取り組みの第一歩として、社内にノウハウの蓄 積と展開の役割を担う部門を発足させ、グループウェアを活用 しながらその活動に努めている。具体的にはプロジェクト完了 時にアプリケーション基盤となる成果物を全て収集し、その中 からノウハウとして展開すべき有益な成果物だけを取捨選択す る。これらの成果物にはプロジェクトの固有要件も含まれてい ることがあるが、サンプルとして様々なパターンを用意してお くことは有用であるため、成果物から固有要件を取り除くこと はない。但し、ノウハウは知的財産であるためアクセスコント ロールが可能なグループウェアで管理を行うなど、これを参照 しても良い者だけがアクセスできるように、細心の注意を払う 必要がある。3.2 設計書の標準化
ここ最近、当社においてもオフショア開発を行う案件が増え てきている。オフショア開発を行う上で最も重要なポイントと なるのが、設計書を使っていかに仕様を伝えるかということで ある。もちろんオフショア開発だけではなく、国内においても 開発を委託するケースが増えており、設計書の書き方がプロジェ クトの成否を分けることも少なくない。全てのプロジェクト を成功に導くためにも、開発を行う上で必要となる情報が全て 設計書に記述されていることが重要である。しかしながら、 アーキテクチャによって開発に必要な情報は異なる。ゆえに全 てのプロジェクトで全く同じ設計書を適用するのは不可能であ るが、少なくとも同じアーキテクチャであれば設計書の記述内 容を合わせるべきである。当社ではこうした考えの元、設計書 の標準化を進めている。 設計書標準を作成する際に苦労したのは、設計書の記述レベ ルを開発委託先によって変える必要があったということである。 特にオフショア開発の場合、例えばデータの抽出仕様は文章で 伝えるのではなく、SQLを書いた方が誤解を生まず結果とし て効率的である、など注意すべき点は多い。また新技術を取り 入れたアーキテクチャの設計書標準を作成する際には、何を設 計書に書けば開発がスムーズに進むのかを意識する必要があっ た。そのために新しい実装技術の検証を行い、設計書作成とそ の設計書を使って実際にプログラミングをする作業を何度も繰 り返し、設計書がより汎用的に利用できるようブラッシュアップ を行った。 こうした苦労は最初こそ負担になるが、中長期的に見れば非 常に効果的な取り組みである。しかも設計書標準を実プロジェ クトに適用し、フィードバックを得ることで、より洗練された 設計書標準となる。プロジェクトの成功率を上げるためにも、 このような取り組みは長期的に続けていく必要がある。4. 今後の課題
以上のように、今後プロジェクトを成功に導くためにはア プリケーション基盤構築が不可欠であり、これを効率良く社 内に普及させることが今後の課題である。アプリケーション 基盤構築はドキュメントを読むだけで誰もがすぐに行えるも のではない。アーキテクチャや新しい実装技術に関して常に 興味を持ち、積極的に学習し、自らの手で実装経験を積むこ とで、徐々にスキルを身につけてゆくことができる。効率良 くこの知識を得るには、経験者の下でアプリケーション基盤 構築作業を行い、成功経験を積むこと、すなわちメンタリン グが一番の近道である。それゆえ経験者は１つのプロジェク トに留まらず、経験者のいないプロジェクトに積極的に入り 込んでいった方が良い。こうすることで二次曲線的に経験者 が増え、実践ノウハウを横方向へ展開するスピードが大幅に 上がる。また、経験者は様々なプロジェクトを渡り歩き、多 種多様な業務を学ぶことでビジネス的観点から各お客さまの 要件に最適なアーキテクチャを見定める力をつけていく。常 に新技術を視野に入れながらこの過程を繰り返すことで、自 らの視野を縦方向へ広げて行くことができる。 このような方式を取ることで、アーキテクチャや新技術に 関するノウハウは実践経験として自らの中に蓄積される。 これにより時代と共に変化するお客さまのハイレベルな要求を “どうやって実現するか”を検討する際、多くの技術的裏付け を基に、即座に実現の可否を判断し、状況によっては代替案を 出すことができるようになる。 このように、アプリケーション基盤構築のスペシャリストは 最終的には要件定義より上流のシステム化計画段階からプロ ジェクトに参画し、ビジネスに対する技術的最適解を提案できる 人材、すなわち「 ITアーキテクト」を目指す。今後重要と なってくる「 ITアーキテクト」のキャリアパスとして、アプ リケーション基盤構築経験は重要な役割を果たす。したがって、 アプリケーション基盤構築の経験者を増やすことが、お客さま と当社双方のビジネス成功の鍵と考えている。特
集
特
集
特
集
SUEMORI Tomoya末森 智也
セキュリティ要件検討 各種セキュリティ対策 性能要件検証 開発環境構成検討 アプリケーション分割指針決定 構成管理の検討 タスク 作業項目 成果物 実施フェーズ 要件定義 基本設計 フレームワークの作成 アプリケーション特性の把握と整理 ○ フレームワーク関連タスクの抽出 フレームワーク選定 フレームワーク設計 フレームワーク製造・テスト アーキテクチャドキュメント フレームワークソースコード 開発標準の作成 設計書サンプルの作成 ＨＴＭＬ標準規約の作成 画面標準の作成 コーディング規約の作成 ネーミング規約の作成 ＨＴＭＬ標準規約 画面標準 コーディング規約 ネーミング規約 基本設計書サンプル、 詳細設計書サンプル アーキテクチャドキュメントの作成 アーキテクチャドキュメント 実装ガイドラインの作成 実装ガイドライン サンプルプログラムの 作成 対象業務の選択 サンプルプログラム作成対象の検討結果 サンプルプログラム作成レベル検討 サンプルプログラム設計 サンプルプログラム設計書 （基本設計書、詳細設計書） サンプルプログラム製造・テスト サンプルプログラムソースコード アーキテクチャドキュメント 負荷テスト結果 開発環境構築ガイドライン 実装ガイドライン 実装ガイドライン 非機能要件の検証 開発環境・構成管理 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ 従来型システム オープンシステム 業 務 ア プ リ ケ ー シ ョ ン 業 務 ア プ リ ケ ー シ ョ ン 業 務 ア プ リ ケ ー シ ョ ン 業 務 ア プ リ ケ ー シ ョ ン 業 務 ア プ リ ケ ー シ ョ ン 業 務 ア プ リ ケ ー シ ョ ン 業 務 ア プ リ ケ ー シ ョ ン 業 務 ア プ リ ケ ー シ ョ ン ミドルウェア OS ハードウェア アプリケーション ワークフレーム ミドルウェア OS ハードウェア システム 基盤 アプリケーション基盤 インフラ基盤開
発
領
域
開
発
領
域
従来型システム オープンシステム ᰑɕɬĘɠɯĘȯ ᰒޒছȬȤɉ ýɩȤɳ ᰓɪɪĘȹǴǚȘౠޑǻ ýȵɳɗɫɗɭȰɩɠ アプリケーション開発基盤 Ħž͔ऎЭ௧ȟȹɠĘȺǸࢴȎȘǬȎǻIJレールijħ適用技術やアーキテクチャ
各設計標準
プロジェクト毎の標準
JSF用設計標準Struts & Seasar2用 設計標準
Windows Forms用 設計標準
ASP.NET & AJAX用 設計標準 オフショア開発利用等、 プロジェクト特性を反映させた 設計標準 標準化 標準化 標準化 標準化 JSF
Java
Struts&Seasar2 Windows Forms.NET Framework
ASP.NET & AJAX テーラリング フィードバック テーラリング フィードバック テーラリング フィードバック テーラリング フィードバック メンタリング 投入 プロジェクトＢ プロジェクトＣ視
野
経験者を投入 プロジェクトＡ プロジェクトA 製造業 投入第 8 号
第 8 号
30 31 32 33第 8 号
アプリケーション基盤の
標準化に向けた取り組み
Approach to Standardization of Application Architecture
末森 智也 増田 浩士
SUEMORI Tomoya MASUDA Hiroshi
1. 開発領域の変化
2. アプリケーション構築に必要な３要素
参考文献 [1] 谷川英和、河本欣司：特許工学入門、中央経済社、(2003) [2] 谷川英和、田中克己：3種類の特許部品データベースに基づく 特許明細書生成エンジンの構築、情報処理学会論文誌 データ ベース(TOD)、Vol.30号、 (2006) [3] 特願2006-124598、「クレーム従属関係図生成装置等」 [4] 新森昭宏、奥村学、丸川雄三、岩山真：手がかり句を用いた 特許請求項の構造解析、情報処理学会論文誌、Vol.45、No.3、 pp.891-905、(2004) [5] 特許第3908261 号、「修辞構造解析システム」 [6] 谷川英和、新森昭宏、大屋由香里： 言語処理に基づく特許 価値評価支援システムと特許読解支援システム、第４回日本 知財学会学術研究発表会、(2006) [7] 新森昭宏、大屋由香里、谷川英和：特許請求項における多重 多数項引用の検出と書換、情報処理学会第69回全国大会、 (2007)特集
IT基盤の最適化
参考文献 [1] 南波幸雄：企業インフラの構成とアーキテクトが押さえる べきポイント, ＩＴアーキテクト, Vol.10, pp.32-37, ＩＤＧ ジャパン, (2007) [2] 仮想化, IT Keywords 2008, pp.6-7, 日経ＢＰ, (2007.12) [3] 2006年上半期のブレードサーバー出荷台数 前年同期比 46.3%増の1万6534台, ＩＴマーケットデータ年鑑2008, p.44, 日経ＢＰ, (2008) [4] ストレージの市場規模は2011年には7264億円に, ＩＴマー ケットデータ年鑑2008, p.66, 日経ＢＰ, (2008) 開発領域の「差異」を正しく認識していない場合、例えば 開発後半で性能要件を満たすために広範囲に渡って見直しが 必要になるなど、大きな手戻りが発生する可能性がある。 このような結果にならないためにも、通常、一斉開発を行 う場合は品質や納期が保てるよう、プロジェクトの初期段階 でプロジェクト特性に合わせ、図２に示す３つの要素を準備 する必要がある。概要
標準化とは「質、形状、大きさ、方法などに基準を設け、それに統一することにより、同じような結果を得られるよ
うになること」を指す。標準化の動きは今に始まったことではないが、ここ最近の業界的な「標準化」の流れの中、
当社としても標準化への取り組みを続けている。以前から開発プロセスの標準化と改善活動を進めてきたが、今
回はその中で「アプリケーション基盤」に着目し、組織的な改編も含めて、その取り組みを推し進めてきた。本稿で
は当社におけるアプリケーション基盤の標準化に向けた取り組みを具体的に紹介するとともに、その重要性を示す。
近年急速にニーズの拡大したオープンシステムは、メイン フレーム等の従来型システムとは開発領域が大きく異なって いることを正しく認識しなければならない (図1)。 従来型システムではハードウェアからミドルウェアまでが ベンダーからセットで提供されていた。したがって、お客さ まにとっての最適なソリューションを提供するために、これ らの組み合わせを検証する必要がなかった。このため、開発 領域は業務アプリケーション部分のみに絞られ、業務的な専 門知識と特定のメインフレームの知識さえ持っていれば、お 客さまの要件を満たすことができた。 一方、オープンシステムではハードウェア、OS、ミドルウェア、 フレームワークなどが多種多様となり、これらを無数の組み合 わせの中から選べるようになった。選択肢が広がり、お客さま にとっての最適な組み合わせを選択できるようになった反面、 選択した組み合わせを検証し、品質を保証するためには、特に ミドルウェアやフレームワークに関する高度な専門知識が必要 不可欠となっている。つまり、オープンシステムの開発領域は 業務アプリケーションのみならず、これらの基盤となるミドル ウェアやフレームワークも含まれるようになったと言える。 オープンシステムの開発プロジェクトではこのような開発領 域の変化を十分に認識しつつ、計画に盛り込んでおかなければ ならない。 図１ 従来型システムとオープンシステムの開発領域の差異 図２ アプリケーション構築に必要な３要素 (１) フレームワーク 「フレームワーク」とは、開発者があらかじめ定められ たアーキテクチャに則って開発していけるよう、アプリ ケーションに共通する機能を汎用的な形で提供するプロ グラムのことを指す。開発者は固有の機能をフレームワー クに当てはめて開発できるため、例えばデータベース接続 などの共通部分を開発する必要が無くなり、意識せずに高 品質で統一感のあるプログラムを作成することができるよ うになる。 (２) 実装ガイドライン 「実装ガイドライン」とは、プログラミングを行う上で の決まり事をドキュメント化したものを指す。プログラム のロジックは色々な書き方ができるため、ある程度決まり 事が無ければ、その書き方は開発者によって千差万別と なってしまう。このためプログラミングをする上での決 まり事をガイドとして明文化し、開発者間で共通認識とし て持たせる必要がある。またフレームワークはその中身を 理解しなくても使えるところに価値があるため、開発者が ソースコードを見なければ使いこなせないフレームワーク では意味がない。したがって、フレームワークを使ったプログ ラミング方法のガイド、すなわち実装ガイドラインが必要となる。 (３) リリースできる品質のサンプルプログラム 「リリースできる品質のサンプルプログラム」とは、 フレームワーク上で実際に動作するプログラムのサンプル を指す。 実際にフレームワーク上で動作するサンプルを作成する ことにより、フレームワーク及びフレームワークを使った プログラムの動作検証を同時に行えるというメリットもあ る。理論的には実装ガイドラインさえあればフレームワーク を使った開発は可能であるが、実際には活字だけでは伝わ らない部分も多い。このため実装ガイドラインの他に、実 際にフレームワーク上でどのように実装したら良いかを示 す見本が必要である。開発者にとってサンプルプログラム は単なる参考例ではなく、本番アプリケーションをプログ ラミングする上での原型となる。サンプルプログラムに誤 りがあれば、それを原型としたプログラムには全て誤りが あるということになり、修正する手戻りも大きい。した がって、サンプルプログラムは単なる例として捉えるの ではなく、全てのプログラムの原型となることを意識して、 リリースできる品質のものだけを開発者に提供すべきであ る。そのためには、レスポンスやセキュリティなど非機能 的な観点からも検証が必要である。例えば、サンプルプロ グラムが組みあがった段階で負荷テストを実施し、フレー ムワーク及びフレームワークを使ったプログラムにボトル ネックが無いことを展開前に保証しておかなければならない。 以上の３点を準備することは、いわばアプリケーション“開発” 基盤の構築であり、「一斉開発をスムーズに進めるためのレール 作り」ともいえる。開発者全員がこのレールに沿って開発するこ とで、統一感があり保守性にも優れたプログラムが出来上がり、 品質も保証される。もちろん開発者が多ければ多いほどその 効果は高くなり、アプリケーション開発基盤の重要性は増していく。 当社では、特に大規模なプロジェクトにおいて、アプリケー ション基盤構築の重要性を認識し、様々な取り組みを行って きた。次章ではこれらの具体例を挙げ、その内容を紹介する。3. アプリケーション基盤構築に関する活動
当社ではアプリケーション基盤を効率良く構築し、効率良く 普及させるために、試行錯誤しながら様々な取り組みを行って きた。今回はその中で特に注意が必要な以下の３点を取り上げる。 ● アプリケーション基盤構築タスクの整理 ● 設計書の標準化 ● ノウハウの蓄積と展開3.1 アプリケーション基盤構築タスクの整理
プロジェクトの中でアプリケーション基盤を構築する際に、 最初に行わなければならないのは作業項目の洗い出し、すな わちタスクの整理である。当社で作成したアプリケーション 基盤構築タスクは表１のとおりである。 見てのとおりアプリケーション基盤構築の主たる作業は、 第１章で述べたようにフレームワークの作成、実装ガイドラ インを含む開発標準の作成、及びサンプルプログラムの作成 の３点、すなわちアプリケーション開発基盤の構築であるが、 その他にも非機能要件の検証や開発環境、構成管理の検討な ど作業項目は多岐に及ぶ。 ここで注意しなければならない点は、アプリケーション基 盤構築作業の大部分が要件定義フェーズで行うべき作業であ るということである。この理由は２つある。 １つ目の理由はアプリケーション基盤の変更は莫大な修正コ ストを要するということである。アプリケーション基盤構築 作業で作成した成果物は全てのプログラムの根源となるため、 一旦開発がスタートしてからこれを変更するとなると、影響度 を入念に調査し、場合によっては基本設計段階にまで遡り、全 てのプログラムの見直しを迫られることになる。このようなこ とにならないためにも、アプリケーション基盤はプロジェクト 初期段階で、且つ慎重に決定する必要がある。 ２つ目の理由はアプリケーション基盤の決定が開発コストを 大きく左右するということである。開発に関わる人数やスキル、 コストやスケジュール、品質など、求められる特性は通常プロ ジェクト毎に異なり、フレームワークやサンプルプログラムは、 それらの特性を踏まえた上で課題を解決できる構成としておく 必要がある。このため、プロジェクトの早期段階で要件の実現 可能性の検証を行っておかなければ、結果として開発コストに 大きな影響を与えてしまうことになる。また、アプリケーション 基盤の構成はインフラ基盤の構成にも多大なる影響を及ぼすた め、可能な限り早期段階で決定しておくべきである。 表１ アプリケーション基盤構築タスク 図３ 設計書の標準化とブラッシュアップ3.3 ノウハウの蓄積と展開
各プロジェクトにおいてアプリケーション基盤を毎回個別に 構築するのは非効率的である。また、それらが個々のプロジェ クトに点在していては、別のプロジェクトから情報を収集する 際にも時間や手間がかかってしまう。一度構築したアプリケー ション基盤は、少なからずプロジェクト特性に合わせてカスタ マイズする必要があるが、各プロジェクトでテンプレートとし て再利用することが可能である。したがって、こうした成果物 はプロジェクト毎に分散させずに、一箇所に集中させ、ノウハ ウとして蓄積し、そして全社展開していくべきである。 当社ではこの取り組みの第一歩として、社内にノウハウの蓄 積と展開の役割を担う部門を発足させ、グループウェアを活用 しながらその活動に努めている。具体的にはプロジェクト完了 時にアプリケーション基盤となる成果物を全て収集し、その中 からノウハウとして展開すべき有益な成果物だけを取捨選択す る。これらの成果物にはプロジェクトの固有要件も含まれてい ることがあるが、サンプルとして様々なパターンを用意してお くことは有用であるため、成果物から固有要件を取り除くこと はない。但し、ノウハウは知的財産であるためアクセスコント ロールが可能なグループウェアで管理を行うなど、これを参照 しても良い者だけがアクセスできるように、細心の注意を払う 必要がある。3.2 設計書の標準化
ここ最近、当社においてもオフショア開発を行う案件が増え てきている。オフショア開発を行う上で最も重要なポイントと なるのが、設計書を使っていかに仕様を伝えるかということで ある。もちろんオフショア開発だけではなく、国内においても 開発を委託するケースが増えており、設計書の書き方がプロジェ クトの成否を分けることも少なくない。全てのプロジェクト を成功に導くためにも、開発を行う上で必要となる情報が全て 設計書に記述されていることが重要である。しかしながら、 アーキテクチャによって開発に必要な情報は異なる。ゆえに全 てのプロジェクトで全く同じ設計書を適用するのは不可能であ るが、少なくとも同じアーキテクチャであれば設計書の記述内 容を合わせるべきである。当社ではこうした考えの元、設計書 の標準化を進めている。 設計書標準を作成する際に苦労したのは、設計書の記述レベ ルを開発委託先によって変える必要があったということである。 特にオフショア開発の場合、例えばデータの抽出仕様は文章で 伝えるのではなく、SQLを書いた方が誤解を生まず結果とし て効率的である、など注意すべき点は多い。また新技術を取り 入れたアーキテクチャの設計書標準を作成する際には、何を設 計書に書けば開発がスムーズに進むのかを意識する必要があっ た。そのために新しい実装技術の検証を行い、設計書作成とそ の設計書を使って実際にプログラミングをする作業を何度も繰 り返し、設計書がより汎用的に利用できるようブラッシュアップ を行った。 こうした苦労は最初こそ負担になるが、中長期的に見れば非 常に効果的な取り組みである。しかも設計書標準を実プロジェ クトに適用し、フィードバックを得ることで、より洗練された 設計書標準となる。プロジェクトの成功率を上げるためにも、 このような取り組みは長期的に続けていく必要がある。4. 今後の課題
図４ 実践ノウハウの展開と視野の拡大 以上のように、今後プロジェクトを成功に導くためにはア プリケーション基盤構築が不可欠であり、これを効率良く社 内に普及させることが今後の課題である。アプリケーション 基盤構築はドキュメントを読むだけで誰もがすぐに行えるも のではない。アーキテクチャや新しい実装技術に関して常に 興味を持ち、積極的に学習し、自らの手で実装経験を積むこ とで、徐々にスキルを身につけてゆくことができる。効率良 くこの知識を得るには、経験者の下でアプリケーション基盤 構築作業を行い、成功経験を積むこと、すなわちメンタリン グが一番の近道である。それゆえ経験者は１つのプロジェク トに留まらず、経験者のいないプロジェクトに積極的に入り 込んでいった方が良い。こうすることで二次曲線的に経験者 が増え、実践ノウハウを横方向へ展開するスピードが大幅に 上がる。また、経験者は様々なプロジェクトを渡り歩き、多 種多様な業務を学ぶことでビジネス的観点から各お客さまの 要件に最適なアーキテクチャを見定める力をつけていく。常 に新技術を視野に入れながらこの過程を繰り返すことで、自 らの視野を縦方向へ広げて行くことができる。 このような方式を取ることで、アーキテクチャや新技術に 関するノウハウは実践経験として自らの中に蓄積される。 これにより時代と共に変化するお客さまのハイレベルな要求を “どうやって実現するか”を検討する際、多くの技術的裏付け を基に、即座に実現の可否を判断し、状況によっては代替案を 出すことができるようになる。 このように、アプリケーション基盤構築のスペシャリストは 最終的には要件定義より上流のシステム化計画段階からプロ ジェクトに参画し、ビジネスに対する技術的最適解を提案できる 人材、すなわち「 ITアーキテクト」を目指す。今後重要と なってくる「 ITアーキテクト」のキャリアパスとして、アプ リケーション基盤構築経験は重要な役割を果たす。したがって、 アプリケーション基盤構築の経験者を増やすことが、お客さま と当社双方のビジネス成功の鍵と考えている。特
集
特
集
特
集
MASUDA Hiroshi増田 浩士
● SI事業本部 システムアーキテクト部 アプリケーションアーキテクトチーム SUEMORI Tomoya末森 智也
● SI事業本部 システムアーキテクト部 ITアーキテクト／アプリケーションアーキテクチャ ● アプリケーション基盤構築に従事 セキュリティ要件検討 各種セキュリティ対策 性能要件検証 開発環境構成検討 アプリケーション分割指針決定 構成管理の検討 タスク 作業項目 成果物 実施フェーズ 要件定義 基本設計 フレームワークの作成 アプリケーション特性の把握と整理 ○ フレームワーク関連タスクの抽出 フレームワーク選定 フレームワーク設計 フレームワーク製造・テスト アーキテクチャドキュメント フレームワークソースコード 開発標準の作成 設計書サンプルの作成 ＨＴＭＬ標準規約の作成 画面標準の作成 コーディング規約の作成 ネーミング規約の作成 ＨＴＭＬ標準規約 画面標準 コーディング規約 ネーミング規約 基本設計書サンプル、 詳細設計書サンプル アーキテクチャドキュメントの作成 アーキテクチャドキュメント 実装ガイドラインの作成 実装ガイドライン サンプルプログラムの 作成 対象業務の選択 サンプルプログラム作成対象の検討結果 サンプルプログラム作成レベル検討 サンプルプログラム設計 サンプルプログラム設計書 （基本設計書、詳細設計書） サンプルプログラム製造・テスト サンプルプログラムソースコード アーキテクチャドキュメント 負荷テスト結果 開発環境構築ガイドライン 実装ガイドライン 実装ガイドライン 非機能要件の検証 開発環境・構成管理 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ 従来型システム オープンシステム 業 務 ア プ リ ケ ー シ ョ ン 業 務 ア プ リ ケ ー シ ョ ン 業 務 ア プ リ ケ ー シ ョ ン 業 務 ア プ リ ケ ー シ ョ ン 業 務 ア プ リ ケ ー シ ョ ン 業 務 ア プ リ ケ ー シ ョ ン 業 務 ア プ リ ケ ー シ ョ ン 業 務 ア プ リ ケ ー シ ョ ン ミドルウェア OS ハードウェア アプリケーション ワークフレーム ミドルウェア OS ハードウェア システム 基盤 アプリケーション基盤 インフラ基盤開
発
領
域
開
発
領
域
従来型システム オープンシステム ᰑɕɬĘɠɯĘȯ ᰒޒছȬȤɉ ýɩȤɳ ᰓɪɪĘȹǴǚȘౠޑǻ ýȵɳɗɫɗɭȰɩɠ アプリケーション開発基盤 Ħž͔ऎЭ௧ȟȹɠĘȺǸࢴȎȘǬȎǻIJレールijħ適用技術やアーキテクチャ
各設計標準
プロジェクト毎の標準
JSF用設計標準Struts & Seasar2用 設計標準
Windows Forms用 設計標準
ASP.NET & AJAX用 設計標準 オフショア開発利用等、 プロジェクト特性を反映させた 設計標準 標準化 標準化 標準化 標準化 JSF
Java
Struts&Seasar2 Windows Forms.NET Framework
ASP.NET & AJAX テーラリング フィードバック テーラリング フィードバック テーラリング フィードバック テーラリング フィードバック実践ノウハウの横方向への展開
メンタリング メンタリング メンタリング メンタリング メンタリング メンタリング メンタリング 投入 プロジェクトＢ プロジェクトＣ プロジェクトＤ プロジェクトＥ プロジェクトＦ プロジェクトＧ視
野
を
縦
方
向
へ
拡
大
経験者を投入 プロジェクトＡ プロジェクトA 製造業 プロジェクトB 流通業 プロジェクトD サービス業 投入 投入 投入 投入 投入2008
第 8 号
I N T E C T E C H N I C A L J O U R N A L3.1 アプリケーション基盤構築タスクの整理
プロジェクトの中でアプリケーション基盤を構築する際に、 最初に行わなければならないのは作業項目の洗い出し、すな わちタスクの整理である。当社で作成したアプリケーション 基盤構築タスクは表１のとおりである。 見てのとおりアプリケーション基盤構築の主たる作業は、 第１章で述べたようにフレームワークの作成、実装ガイドラ インを含む開発標準の作成、及びサンプルプログラムの作成 の３点、すなわちアプリケーション開発基盤の構築であるが、 その他にも非機能要件の検証や開発環境、構成管理の検討な ど作業項目は多岐に及ぶ。 ここで注意しなければならない点は、アプリケーション基 盤構築作業の大部分が要件定義フェーズで行うべき作業であ るということである。この理由は２つある。 １つ目の理由はアプリケーション基盤の変更は莫大な修正コ ストを要するということである。アプリケーション基盤構築 作業で作成した成果物は全てのプログラムの根源となるため、 一旦開発がスタートしてからこれを変更するとなると、影響度 を入念に調査し、場合によっては基本設計段階にまで遡り、全 てのプログラムの見直しを迫られることになる。このようなこ とにならないためにも、アプリケーション基盤はプロジェクト 初期段階で、且つ慎重に決定する必要がある。 ２つ目の理由はアプリケーション基盤の決定が開発コストを 大きく左右するということである。開発に関わる人数やスキル、 コストやスケジュール、品質など、求められる特性は通常プロ ジェクト毎に異なり、フレームワークやサンプルプログラムは、 それらの特性を踏まえた上で課題を解決できる構成としておく 必要がある。このため、プロジェクトの早期段階で要件の実現 可能性の検証を行っておかなければ、結果として開発コストに 大きな影響を与えてしまうことになる。また、アプリケーション 基盤の構成はインフラ基盤の構成にも多大なる影響を及ぼすた め、可能な限り早期段階で決定しておくべきである。 表１ アプリケーション基盤構築タスク3.2 設計書の標準化
ここ最近、当社においてもオフショア開発を行う案件が増え てきている。オフショア開発を行う上で最も重要なポイントと なるのが、設計書を使っていかに仕様を伝えるかということで ある。もちろんオフショア開発だけではなく、国内においても 開発を委託するケースが増えており、設計書の書き方がプロジェ クトの成否を分けることも少なくない。全てのプロジェクト を成功に導くためにも、開発を行う上で必要となる情報が全て 設計書に記述されていることが重要である。しかしながら、 アーキテクチャによって開発に必要な情報は異なる。ゆえに全 てのプロジェクトで全く同じ設計書を適用するのは不可能であ るが、少なくとも同じアーキテクチャであれば設計書の記述内 容を合わせるべきである。当社ではこうした考えの元、設計書 の標準化を進めている。 設計書標準を作成する際に苦労したのは、設計書の記述レベ ルを開発委託先によって変える必要があったということである。 特にオフショア開発の場合、例えばデータの抽出仕様は文章で 伝えるのではなく、SQLを書いた方が誤解を生まず結果とし て効率的である、など注意すべき点は多い。また新技術を取り 入れたアーキテクチャの設計書標準を作成する際には、何を設 計書に書けば開発がスムーズに進むのかを意識する必要があっ た。そのために新しい実装技術の検証を行い、設計書作成とそ の設計書を使って実際にプログラミングをする作業を何度も繰 り返し、設計書がより汎用的に利用できるようブラッシュアップ を行った。 こうした苦労は最初こそ負担になるが、中長期的に見れば非 常に効果的な取り組みである。しかも設計書標準を実プロジェ クトに適用し、フィードバックを得ることで、より洗練された 設計書標準となる。プロジェクトの成功率を上げるためにも、 このような取り組みは長期的に続けていく必要がある。特
集
タスク 作業項目 成果物 要件定義 基本設計 実施フェーズ フレームワークの作成 アプリケーション特性の把握と整理 ○ フレームワーク関連タスクの抽出 フレームワーク選定 フレームワーク設計 フレームワーク製造・テスト アーキテクチャドキュメント フレームワークソースコード 開発標準の作成 設計書サンプルの作成 ＨＴＭＬ標準規約の作成 画面標準の作成 コーディング規約の作成 ネーミング規約の作成 ＨＴＭＬ標準規約 画面標準 コーディング規約 ネーミング規約 基本設計書サンプル、 詳細設計書サンプル アーキテクチャドキュメントの作成 アーキテクチャドキュメント 実装ガイドラインの作成 実装ガイドライン ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○適用技術やアーキテクチャ
各設計標準
プロジェクト毎の標準
JSF用設計標準Struts & Seasar2用 設計標準
標準化
標準化 JSF
Java
Struts & Seasar2
テーラリング
フィードバック
テーラリング
