日本電気株式会社 様
Xupper と各種ツール連携で自動化促進知識集約型開発への転換を目指す オフショア開発がますます進展する中で、従来のような労働集約型の開発スタイルのままでは価格競争に陥り、海外の安価な労働力に太刀打ちできない。こうした状況を見極め、日本電気では知識集約型開発への転換を図るべく、新たな開発手法の確立に取り組んでいる。 |
 |
NECが目指す「TCO削減指向AP開発手法」とは？
昨今のアプリケーション開発では、以前に比べて全体の開発期間や開発費が縮小傾向にある一方で、基本設計や機能設計といった上流工程に関しては、より多くの時間・コストが必要とされるようになっている。
また、開発コストに対するユーザの要求も変わりつつあり、従来のように新規開発時だけでなく、追加開発も含めたシステムのライフサイクル全体を通じてのコスト低減が強く求められるようになった。
もう1つ、最近の傾向として挙げられるのが、開発リソースの問題だ。いまやSE は「新3K」と呼ばれるほど人気が低迷しており、優秀なSE の確保が非常に難しい。加えて離職率も比較的高いことから、熟練者の育成も困難な状況となっている。
こうした環境の中で、より早く、コストを抑えながら、品質の高いアプリケーションを開発していくために、日本電気（以下NEC）では開発スタイルの変革に着手。その狙いは、従来の労働集約型から知識集約型開発への転換だ。
具体的なポイントとしては、開発要員の労力を上流工程の設計や評価試験の設計に注力させること。そして、ツールを活用した自動化によって中下流工程を効率化すること。
維持フェーズにおける効率化のためには、設計情報を一元管理することでメンテナンス性を向上し、デグレードを抑止することも重要となる。
この知識集約型開発への転換に向けて、NEC では上流設計工程、中流・下流工程、開発リソースのそれぞれにおける課題に対して「あるべき姿」である目標を設定。
それらを実現するために、さまざまなアプリケーション開発技術や開発手法、さらにはプロジェクトマネジメントの要素を連携した「TCO 削減指向AP 開発手法」の確立に取り組んでいる。
Xupperを用いたアドバンスドDOA上流設計
上流設計工程では、仕様のゆらぎを防ぎ、もし仕様変更が発生しても容易に追加変更できることが目標となる。その実現手段として、TCO 削減指向AP 開発手法では、アドバンスドDOA 上流設計、業務モデル化、リポジトリ一元管理、イテレーション開発といった要素を採り入れた。
アドバンスドDOA とは、IF ?THEN 形式のルールで問題解決をするプログラミング技法である「ルールベース」の考え方と、従来のDOA（Data Oriented Approach）を組み合わせたアプローチだ。
アドバンスドDOA では、まずユーザの視点に立ち、ユーザの理解しやすい業務フローを主体に、業務知識（ビジネスルール）をルールベース化。それらをXupperのリポジトリで一元管理する。
同時にデータ分析を行い、従来のDOA と同様にビジネスルールとエンティティの関係を分析して、アプリケーション構造を確定していく。
プログラムの自動生成は、MDFrame/X のアクションダイヤグラムから行うが、将来的にはルールベースシステムとして、ロジックを解析できるものについてはルールエンジンによりプログラムを自動生成することを目指している。
業務モデル化では、業務フローによって業務をモデル化することで、人や組織、IO、データ項目などの管理対象を明確化し、業務モデルからフレームワークと部品化すべきモデルの独立性を重視しながら抽出。データ分析からオブジェクト候補を洗い出す。
こうしてフレームワークや部品を効率的に活用していくことで、作り込む部分を減らしたり、作る場合でも均質なものができるようになる。
こうした上流設計工程を支える基盤となるのが、Xupperによる設計情報の一元管理（リポジトリ化）だ。業務フロー図を中心に、さまざまな情報を関連づけて管理できるので、仕様のゆらぎや追加が発生した際も、リポジトリ情報からIO やデータ項目などの影響ポイントを抽出し、影響のあるビジネスルールやエンティティを検索できる。
また、基本設計の確定後にイテレーション開発によって業務要件の成熟度を段階的に上げ、業務フローの要件やアプリケーション構造の確定を実施することで、仕様要件のゆらぎを抑えることが可能となる。
各種ツールの活用でプログラム作成やテストも自動化
中流から下流工程の目標は、上流設計終了後のプログラム開発の効率化と開発期間短縮だ。ここでは、各種ツールの活用による開発の自動化が鍵となる。
画面設計に関しては、コンポーネントエディタやAdobe のFlex Builder 2 を利用する。Flex Builder 2は、実際に動く画面( モックアップ）を生成して、仕様を確認することができるツールだが、そのUI 定義をMXML 化しておけば、モックアップの画面設計情報をそのままXupperのリポジトリへ取り込むことができる。
データベースのアクセス部品（SQL）は、MDFrame/X の機能によって自動生成。プログラムについても基本的に、業務ロジックをMDFrame/X でアクションダイヤグラムとして登録し、Java のプログラムを自動生成する。これにより、中流工程以降の開発の効率化および期間短縮が期待できる。
このアクションダイヤグラムからの自動生成に加え、今後、ルールエンジンによるプログラム自動生成が実現すれば、さらに生産性が向上するはずだ。
また、TCO 削減指向AP 開発手法には、テストケースの自動生成も含まれている。たとえば、試験漏れ防止のためにXupperのリポジトリからテストすべきケースを自動抽出したり、業務フロー図を分析してすべての業務の流れをテストケースとして抽出することが可能だ。
テストケース（詳細）として、テストで使用する画面やテーブルなどのデータと確認すべき情報をリポジトリ上で連携し、試験仕様書を容易に作成することもできる。
今後はテスト工程の効率化をさらに推進すべく、テスト管理ツールのHP QualityCenter や自動テスト実行ツールのHP QuickTest Professional などと連携させ、テストケースの作成から実行、管理まで自動化するための検証を進めているという。
|
|
 |
スモールチーム開発で知識の集約化を図る
開発リソースの課題に対しては、スペシャリスト集団による知識集約型開発という目標が掲げられた。TCO 削減指向AP 開発手法においては、これを実現するためにスモールチーム開発やディレクタ組織といったプロジェクト体制が組まれる。
知識の集約化を図るには、少数精鋭のスモールチームのほうが望ましい。また、優秀なSE を育成するには、できるだけ多くの場数を踏ませる必要があるが、その点でもスモールチーム開発は有効だ。
大規模開発においても開発部隊を10～30 人までのスモールチームに分け、すべてのローテーションをチーム単位で行うことで、チームメンバーの連携が強固になり、結果的に生産性を向上させることができるという。
なお、スモールチーム開発を有効に機能させるためには、各チームのリーダーと仕様管理者から構成されるディレクタ組織というものも必要だ。TCP 削減指向AP 開発手法では、このディレクタ組織が仕様管理を一元的に実施し、業務間相互レビューによって仕様齟齬などを防止する役割を担うことになる。
NEC のTCO 削減指向AP 開発手法は完成形ではなく、まだ進化の途上にある。今後、日本のソフトウェア開発のあり方を変革する新たな指標となることを、大いに期待したい。
日本電気株式会社様の事例PDFは下記よりダウンロードできます
キリンビジネスシステム株式会社 様
キリングループの情報システム開発における標準ツールとしてXupperを導入キリングループの情報システム開発を担うキリンビジネスシステムでは、品質を維持しつつ開発生産性を向上させることを目的に、新たなツールの導入を検討。ツール自体の評価や自社開発標準のカスタマイズといったプロセスを経て、標準ツールとしてXupperを正式適用した。MDFrame/Xについても段階的にパイロット適用を行っており、間もなく正式適用となる見込みだ。 |
 |
DOAをベースに開発標準を確立、そしてXupper導入へ
キリングループは2007 年7 月にホールディングス制に移行。これに伴い、キリンビールの子会社であったキリンビジネスシステムは、新たにグループ内の機能分担会社として位置付けられた。
現在、キリンビールやキリンビバレッジをはじめとする各事業会社は社内に情報システム部門を持たないため、キリンビジネスシhowcase/pamphlet-ent/ステムはグループ唯一の情報システム会社として、グループの情報戦略を実行し、システムインテグレーションやユーザサポート、e- ビジネスなどのサービスを各事業会社に提供している。
同社では、古くからDOA（Data OrientedApproach）を開発に適用してきた。1989 ～1992 年には、キリンビールシステム開発部において、ウォーターフォール型開発を対象に開発工程を標準化するとともに、DOA をベースとした上流工程での分析方法を標準化。これが、「キリン開発標準」および「キリン情報要求分析標準」である。
|
1998 年には、スパイラル型のRAD（RapidApplication Development）開発と従来のDOA の考え方を融合した新たな方法論である「DOA-RAD」をデータ総研と共同で開発。 |
 |
現在、開発ではXupperとMDFrame/X、そして運用ではSQETというツールが標準として採用されているが、これらの標準ツールもすべてこのW モデルをベースに適用されている。
品質を維持しながら開発生産性を向上するために
キリンビジネスシステムがXupperおよびMDFrame/X の導入プロジェクトを開始したのは、2007 年1月。その背景には、サービスを提供するユーザ企業（事業会社）の増加、ユーザ企業の施策スピードに合わせたさらなる短納期化への対応などがある。また、手組み開発における生産性向上も課題とされていた。
そこで同社では、品質を維持しつつ開発生産性を向上させることを目的に、ツール導入を検討。具体的な目標としては、開発効率の向上、保守効率の向上、資産の管理といった定性目標とともに、開発工期2/3（＝トータル開発生産性1.5 倍）という定量的な目標も掲げた。
|
2007 年3 月までの間に、同社では生産性向上のための仮説を設定。「上流から下流までを一貫して管理することで手戻りを排除する」、「自動化できる部分を極力機械化することで手作業を排除する」、「リポジトリで一括管理することで保守工程の負荷を軽減する」という3つの仮説のもと、2007 年4 月よりXupperとMDFrame/X の評価を開始した。 |
 |
標準ツールとして定着させるための仕組みづくり
続いて、2007年11月から2008年3月にかけては標準化を実施。このフェーズでは、キリンビジネスシステムの推進メンバーのほか、ケン・システムコンサルディングとデータ総研の2 社が参画した。
両社の協力のもと、キリン開発標準をカスタマイズして標準ルールを設定。さらに、XupperによるTH モデル表記法を制定し、「DOA-RAD for Xupper」という新しい開発方法論を生み出した。
標準化のフェーズを終え、Xupperが正式適用されたのは2008 年4 月。ただし、MDFrame/X はパイロット適用という位置付けだ。
なお、XupperとMDFrame/X を利用できるのは、キリン社内ネットワークに接続可能な環境のみ。社外からの接続はネットワークセキュリティ規定上の条件をクリアした場合に可能となるが、現時点では不可となっている。
また、利用対象者は開発担当者および運用担当者に制限。Xupperで設計した各種ドキュメントはHTML やExcel に出力できるので、ユーザである事業会社の担当者にはそれらを見せることで利用対象外とした。
ツールの適用基準としては、特に金額や規模での限定はせず、手組みの新規開発すべてを対象としている。ただし部分改修は除き、サブシステム単位で再構築となるような案件以上が対象だ。Xupperは標準ツールとしての正式適用なので、対象案件については特別な理由がない限り適用することが義務付けられる。
MDFrame/X については2008 年を準備期間として位置付け、各部で選定した案件のみを対象に適用。パイロット適用での課題を踏まえて第2 フェーズの標準化を行い、2009 年からの正式適用を目指しているという。
設計情報の整合性をXupperにて保持できるように、改修時はすべてXupperから再設計するというルールも徹底している。Xupper以外で作成するすべてのドキュメントも、Xupperのツールナビゲータで管理。
また、C# の直接コーディングは基本的に不可とし、マクロ類も手作りするのではなく、共通部品としてケン・システムコンサルティングに開発依頼することにしている。つまり、人がプログラムに手を入れる部分を最小限に抑え、開発はすべてツールで管理するのが原則だ。
キリンビジネスシステムでは今後の課題として、全体の管理者や標準部品のメンテナンス担当者、開発現場での推進キーパーソンなどを含む社内体制の構築を挙げている。また、開発協力会社にキリン開発標準を十分理解してもらうことも不可欠としている。
これらはいずれも「人」に大きく関わる要素といえる。今回導入したXupperなどの「ツール」やキリン開発標準のような「方法論」に加えて、それらを適切に使うことのできる「人」が三位一体となることで、さらなる開発生産性の向上が実現できるだろう。
キリンビジネスシステム株式会社様の事例PDFは下記よりダウンロードできます