オープンアーキテクチャ，オープンソースソフトウェア時代の標準化フレームワークを使用したプロジェクトマネジメント...
TRANSCRIPT
オープンアーキテクチャ，オープンソースソフトウェア時代の標準化フレームワークを使用したプロジェクトマネジメント
OSSコンソーシアム.NET 開発基盤部会 リーダー 西野 大介
１．はじめに
２．現状の問題点
３．Open棟梁による解決方法
1
Contents
４．OSSエコシステム形成と企業間の連携強化
６．おわりに
５．施策の効果
2
１．はじめに
多くの要員が必要になるエンタープライズ領域のSIプロジェクトでは，種々の「標準化作業が必要不可欠」である．
- - - > 標準化を行わない場合，図のような問題が多発する．
3
１-１ 標準化されていないSIプロジェクトの問題
そのため，多数のSIプロジェクトで，設計・実装ガイドラインをもとに“テンプレート” や “アプリケーション フレームワーク”が作成されてきた．
4
２．現状の問題点
5
２-１ 独自の標準化フレームワークの問題
技術の発達により，必要な“標準化フレームワーク”の開発が容易になったが，個別の投資で，プロジェクトごとに開発された独自の標準化フレームワークには，以下のような問題点がある．
• ユーザビリティ等に関する品質は低かった．
• 当該プロジェクトに特化した仕様・設計となっていた．
- - - > 必要性は十分に認識されているものの，種々の要件やアーキテクチャの異なるプロジェクトを跨いだ展開が困難なまま，解決されていなかった．
プロジェクトＡの要件・アーキテクチャ
プロジェクトＢの要件・アーキテクチャ
既存の資産を流用したくても…
プロジェクトＡの要件・アーキテクチャに従って作られた独自標準化フレームワーク
個別の要件やアーキテクチャに特化した作りになっているため，他プロジェクトへの流用が困難
6
２-２ “要素技術”の多様化に伴うSI事業の問題
また近年，Web技術，スマートフォン，クラウドなどの登場により開発から運用までの様々な“要素技術”が急速に多様化している．
このため… しかし一方で…
- - - > 生き残りをかけた抜本的な経営の見直しが求められている．
• 大規模化や，単価の高いプロパー比率の低減 (規模の経済，図中(１))• 単価や利益率の高いソリューションの企画 (連結の経済，図中(２))• サービスの運用・メンテナンス (範囲の経済，図中(３))
多様化した要素技術を扱う難易度の向上
個々の作業への更なるコストダウンの要求
7
３．Open棟梁による解決方法
Open棟梁は，.NET 3.5 以上，多様な処理方式に対応できるアプリケーションの全レイヤをカバーするフルスタックなアプリケーション・フレームワークである．
また，共通部品や開発支援機能を提供することで生産性を向上し，重厚な標準化を施すことで，高品質なアプリケーション開発を可能にする，QCDF*を向上させるための標準化フレームワークである．
8
３-１ Open棟梁とは
Access Trace Log
B（F）層
ベースクラス１
サブクラス
ベースクラス２
P層
ベースクラス１
サブクラス
ベースクラス２
D層
ベースクラス１
UI
サブシステム
ベースクラス２
サブクラス
Operation Trace Log SQL Trace Log
• アクセス制御• 表示・非表示• 活性・不活性
• 閉塞処理• コネクション制御• トランザクション制御• 例外処理
アクセス制御
Database
SQLインジェクション防止
LDAP
認証
2014年4月にOSSとして公開
< License >• Program :
Apache License, Version 2.0
• Document :Creative Commons - CC BY 2.1 JP
-----*QCDFとは，QCD(「Quality（品質）」「Cost（費用）」「Delivery（納期）」)に，「Flexibility（柔軟性）」のFを加えたもの．
< 呼び出し規則を強制する共通化 >
9
３-２ “制御の反転”の導入
< “カスタマイズ可能レイヤ（ベースクラス２）”の分割 >
- - - > 共通化が容易になった．
制御の反転を導入した
モジュール構造
- - - > 横展開を容易に行うことができるようになった．
“制御の反転” では，個別の目的に実装されたコード(ベースクラス２・サブクラス)が，再利用可能なライブラリ(ベースクラス１)によるフロー制御を受ける．
この“制御の反転”の導入により，モジュール化が促進され，拡張性が向上した．
10
３-３ プロジェクト テンプレートの活用
また，“プロジェクト テンプレート”として，図のようなスタック構成で一式をテンプレート化した．
対象PJにフィッティングさせる• プロジェクト・テンプレート• カスタマイズ可能レイヤ
標準化フレームワークとして開発された部位
マイクロソフトが提供するデファクト スタンダードなランタイム フレームワーク
- - - > これにより，迅速な導入が可能になり，開発者はすぐに開発に着手できるようになった．さらに，開発工数の少ない小規模プロジェクトへの導入も可能になった．
11
３-４ プロジェクト テンプレートの追加の効果
< 開発ノウハウの蓄積 >
< 導入プロセスの進化 >
スタック間の重複を最小化，DRY原則*を遵守した形で開発ノウハウを蓄積．
- - - > オフショア一括外注プロジェクトでも，高い生産性・品質を確保できる．
一式の利用ガイド，チュートリアルを整備して利用方法の習得を迅速化．標準化ノウハウを，「セルフ・サポートで」・「手軽に」適用可能になった．
-----*DRY（Don‘t Repeat Yourself）原則 ： プログラム コード以外のもろもろの重複を避ける．
必要に応じて
12
４．OSSエコシステム形成と企業間の連携強化
13
４-１ 企業間の連携強化の背景
従来のメーカー系SI事業者のビジネスモデルは垂直統合型であったが，オープンアーキテクチャの隆盛により，このモデルが大きく崩れ始めている．
SI事業には多種多様な要素技術が必要とされるが，これらの要素技術を扱う高レベルの技術者は，垂直統合の狭いマーケットでは採算が合わなくなっている．
- - - > このため，購買代理業者側に位置するSI事業者では，このような，高レベルの技術者を，新たに外部から調達する必要がでてきている．
統合メーカー
顧客
販売代理理業者（メーカー系SI事業者）
凡例： ・ 情報の流れ
要素技術提供者Microsoft，Google，Apple，
OSS
顧客
パッケージャ（専門業者）
購買代理業者（SI事業者）
要素技術の多様化
更なるコストダウンの要求
14
４-２ OSS化とOSSエコシステムの形成
今後，オープンアーキテクチャの下で更なる要素技術の登場が予想される．
• このような状況下では，新技術の導入と，その標準化は重要だが，それを遂行する人材が （購買代理業者側である）SI事業者内で維持できない．
• このため，不特定多数の（パッケージャ側である） SES事業者に情報を公開，OSSエコシステムを形成し，人材の調達を可能にする必要がある．
- - - > 2014年4月のOSS化以降，インターネット上でサポート技術情報の拡充を図っている．
- - - > これにより，導入プロセスを更に進化させることができると考えた．
15
５．施策の効果
16
５-１ 定性的効果
< 開発手順・実装方法の標準化による効果 >
• 標準化や部品再利用，自動生成により，バラつきの無い手順で開発可能．これにより，品質・信頼性・生産性の向上と，ぜい弱性の排除が可能．
• オフショア一括外注プロジェクトでも，プロジェクトの統制を取って，高い生産性と品質を確保，プロジェクトを成功に導くことができる．
• 開発時から保守・運用時までのデバッグやトラブルシュート手順が確立されている．
< フレームワークの特性による効果 >
• カスタマイズ可能レイヤ（ベースクラス２）により，横展開を容易に行うことができるようになった．
• プロジェクト テンプレートにより素早い導入が可能で，開発工数の少ない小規模プロジェクトへの導入も可能になった．
• 最新技術にOpen棟梁のプロジェクト テンプレートを追従させることで，様々なアーキテクチャへの対応や，最新技術のサポートが可能になった．
17
５-２ 定量的効果
< 前提 >• ソフトウェア開発の工程別工数比率
設計 : プログラミング : テスト = 3 : 4 : 3
• Open棟梁の効果を分析する際の前提
< 計算式 >
[削減工数]人月 = 2.0人月 + ([適用前のソフト開発の全工数]人月 * (0.4 + 0.3) * 0.1)
工程 削減工数
設計工程 最小 2 人月
プログラミング工程 最低 10 %
テスト工程 最低 10 %
40人月のプロジェクトを例に取った場合，Open棟梁を適用することで，
の工数が最小でも削減可能．
2人月+ ( 40人月* 0.7 * 0.1 ) ≒ 約 5 人月 (約 12.5 %)
18
５-３ 新技術導入時のリスクヘッジの具体事例
Microsoft Azureを使用した案件において，PaaS対応テンプレートを作成して提供．これにより，セキュリティ対策で処理方式の変更が必要になったが，業務処理のサブクラス実装はそのままに，処理方式を迅速に変更できた．
ゲートキーパーデザインパターンの採用
セキュリティ対策による処理方式の変更
新技術の導入時は，このような処理方式変更が発生するリスクがあるが，Open棟梁を導入しておくことにより，迅速に対応できる．
19
５-４ OSSエコシステムの形成による企業間連携の強化
オープンな開発のコミュニティを中心にOSSエコシステムを形成したことにより，SI事業者とSES事業者と連携を強化できるようになった．
- - - > このエコシステムの中で，プロジェクトに必要な技術者を育成し，必要に応じて供給・調達することが可能になった．
SES事業者は習得した技術を別の商流に対しても利用できるようになる．
SI事業者は必要な技術者を外部から調達可能になる．
これをビジネス上のメリットと考えるSES事業者とSI事業者は，コミュニティを中心に連携を強化することで，このWin-WinのOSSエコシステムを形成することができる．
20
６．おわりに
21
６-１ OSSエコシステム形成とコントリビュートの推進
本発表では，技術カットから，ビジネスモデルの変化を分析・予測し，SI事業者と， SES事業者と連携を強化することで可能となる，プロジェクト調達マネジメントに関する新しい問題解決方法を提案した．
• オープンソースやサポート技術情報をインターネット上に公開，OSSエコシステムを形成し，このOSSエコシステムの中で，プロジェクトに必要な技術者を育成し，必要に応じて供給＆調達することが可能になった．
今後，ビジネスモデルの変化と，企業の全体最適を考慮したプロジェクトマネジメントを行うためには，OSSエコシステムを横断した，より高度な施策の策定が必要になっていくものと考える．
• 現在， コミュニティへコントリビュート（プログラムや技術情報を開示）を促進させるため，プロジェクトに関わるベンダ間の契約を，プログラムや技術情報の留保が可能になるよう，契約の見直しを行うようにしている．
• 今後，OSSエコシステムの中でフレームワークがエンハンスされていくようにWin – Win のOSSエコシステムの形成の方法を継続的に検討していく必要がある．
22
６-２ トランスフォーメーション（企業変革）の推進
現在，OSSコミュニティのSaaS開発ワーキング・グループで3社協創のSaaS開発プロジェクトの運営・開発に携わっており，このプロジェクトで開発されたSaaS開発基盤をOSSとしてリリース予定である．
Open棟梁では，システム開発力を強化する機能が一通り揃ったと認識している (図中(１))．今後は，業界トレンドや顧客ニーズに合わせて，SaaS開発基盤 (図中(2)，(3)) へとサポート範囲を拡大していく予定である．
23
オープンアーキテクチャ，オープンソースソフトウェア時代の標準化フレームワークを使用したプロジェクトマネジメント
END
※ Windows、.NET Framework、Azureは、Microsoft Corporationの米国およびその他の国における商標もしくは登録商標です。※ Javaは、Oracle Corporationおよびその子会社、関連会社の米国およびその他の国における登録商標です。※ その他記載の会社名、製品名は、それぞれの会社の商標もしくは登録商標です。
0
1
はじめに．
2
（１-１ 標準化されていないSIプロジェクトの問題）
多くのSIプロジェクトで，標準化は必須です．この理由は，SIプロジェクトでは多くの要員を投入するためです．
図のように，標準化を行わないプロジェクトでは，
• （原因として ）：「実装が開発者ごとにばらばらになる」
• その結果として：「品質・性能が出ない，対策でデグレード多発，問題の分析ができない」
などの初歩的な問題が多発します．
このため，多数のSIプロジェクトでは，設計・実装のガイドラインとともに，“テンプレート”や“アプリケーション フレームワーク”と言ったものが，プロジェクト毎に“重複して”作成されてきました．
3
次の章では「現状の問題点」を説明します．
4
（２-１ 独自の標準化フレームワークの問題）
Java / .NETなどのオブジェクト指向言語など，開発技術の発達により，優れたフレームワークの開発が可能になり，デファクト スタンダードなASP.NET
などのランタイム フレームワークがコモディティとして提供されています．しかし，SIerが開発・利用する “標準化フレームワーク”は，“オレオレ フレームワーク”等と呼ばれているように，なかなか進歩が見られませんでした．
これは，
• 基本的に当該プロジェクトの範囲内でしか共有されないため，
• ユーザビリティに関する設計品質は低く，利用方法の習得などに問題があったこと．
• また，図にあるように，プロジェクト独自の仕様・設計であったため，狭い範囲にしか横展開できなかったこと．
• これにより，重複投資となってしまい，夫々で予算確保やマネタイズなどが難しくなったこと．
などが原因であったと考えています．
5
（２-２ “要素技術”の多様化に伴うSI事業の問題）
SI事業が人月商売であるが故，技術的なナレッジ蓄積が進まない中，
• （図）取扱う必要のある要素技術は増え，難易度が向上し続ける一方で，
• （図）個々の作業への更なるコストダウンが要求されており，
SI崩壊やSI淘汰，SI終焉などと叫ばれる状況に陥っています．
このため，生き残りをかけた抜本的な経営の見直しが求められています．例えば，この図（SI事業者のスマイルカーブ*）では，システム開発の差別化（図中（１）），若しくは，脱却（図中（２）（３））が必要になっていることを表しています．
*スマイルカーブとは，製造業において，縦軸に収益性（付加価値）を，横軸に事業プロセス（価値連鎖）をとった場合，両端の“R&Dと販売・アフター”の収益性（付加価値）が最も高く，中間の“製造と組立”の収益性（付加価値）が最も低いU字型の線になる状況を説明する図になります．
6
そこで我々は標準化フレームワークである，
Open棟梁を使用して，これらの問題の解決を試みています．
7
（３-１ Open棟梁とは）
Open棟梁とは，2014年4月にOSS化された.NET用のフルスタックのアプリケーション フレームワークであり，システム開発のQCDFを向上させる標準化フレームワークです．
本章では，Open棟梁による問題の解決方法について説明します．
8
（３-２ “制御の反転”の導入）
まず，Open棟梁で“制御の反転”と呼ばれる設計のモジュール構造を導入しています．このようなモジュール構造を導入したことにより，
• 呼び出し規則が強制され，共通化が容易になった．
• （図のように）“カスタマイズ可能レイヤ（ベースクラス２）”の分割により横展開が容易になった．
という改善を図ることができるようになり，更に・・・，
9
（３-３ プロジェクト テンプレートの活用）
“プロジェクト テンプレート”として，図のようなスタック構成で主要なアーキテクチャ毎の一式をテンプレート化したことで，クラスライブラリやAPIの組み合わせ作業を各プロジェクトで“個別に”遂行する必要が無くなり，更なる導入の効率化を図ることができるようになりました．
“プロジェクト テンプレート”のスタック構成は下位から，
• （下位）：マイクロソフトが提供するコモディティのレイヤとして，
• ランタイム（.NET CLR）
• ASP.NETなどのランタイム フレームワークこれはJavaで言う，Struts，Spring等のFxのレイヤに位置します．
• （中間）：標準化フレームワークとして開発された，
• 共通部品
• 標準化フレーム
• （上位）：プロジェクト要件に合わせてフィッティングさせるレイヤとして，
• 共通処理をカスタマイズするカスタマイズ可能レイヤ （ベースクラス２
• アーキテクチャに合わせカスタマイズするプロジェクト・テンプレート
となっています．
10
（３-４ プロジェクト テンプレートの追加の効果）
“プロジェクト テンプレート”化には，更に以下の追加の効果がありました．
1. 一番目は，テンプレートへの開発ノウハウの蓄積を実現したことです．これは，スタック間の重複を最小化することで，DRY原則を遵守した（＝重複を削除して，二度手間を繰り返すことが無くなるような）テンプレートへの開発ノウハウの蓄積を実現しました．
2. 二番目は，導入プロセスの進化です．“プロジェクト テンプレート”一式の利用ガイド，チュートリアルを整備して，当該プロジェクトに所属するリードエンジニアが利用方法を習得する期間を短縮しました．これにより，図のようにノウハウの蓄積された標準化をリードエンジニアのセルフサポートでプロジェクトへ導入することができるようになりました．
これにより，１人のリード エンジニアでも，統制の難しいオフショア一括外注プロジェクトなどで，高い生産性と品質を確保することができるようになりました．
11
また，OSS化によって
「OSSエコシステムを形成できるようになった．」
という効果もあります．
次の章では，
「OSSエコシステムの形成によって可能となった企業間の連携強化」
について説明します．
12
（４-１ 企業間の連携強化の背景）
先ず，企業間の連携強化の背景ですが，オープンアーキテクチャによるビジネスモデルの変化は，今までの垂直統合のビジネスモデルを破壊し，
その構造を，
• 統合メーカー－販売代理業者のモデルから
• 要素技術－パッケージャ－購買代理業者のモデルに
分割しました．
これにより，オープンアーキテクチャのビジネスモデルでは，どこから何をどのように調達するか・供給するかということを考えることが必要になりました．
これをSI事業に当てはめて考えた場合，SI事業者は購買代理業者に相当するため，「要素技術・パッケージャに相当する技術・技術者を“自社の商流内で”ペイラインに乗せる事が難しくなってきています．」
そのため，「これらの技術・技術者をどこから調達するか？ということが重要になってきている．」ということかと思います．
13
（４-２ OSS化とOSSエコシステムの形成）
このような状況の下，
• 新技術の導入と，その標準化は“相変わらず”重要ですが，「それを遂行する人材が （購買代理業者側である）SI事業者内で維持できない．」ということが次第に明らかになってきました．
• このため，Open棟梁プロジェクトでは，不特定多数の（パッケージャ側である） SES事業者に技術情報を公開し，エコシステムを形成，人材の育成と調達を可能にするため，
2014年4月のOSS化以降，インターネット上でサポート技術情報の拡充を図ってきました．これにより，導入プロセスを進化させることができると考えました．
14
次の章ではこれまで説明した施策の効果について説明します．
15
（５-１ 定性的効果）
定性的効果については，
• 先ずXとして，X1，X2，X3等が挙げられます．
• 続きまして，Yとして，Y1，Y2，Y3等が挙げられます．
16
（５-２ 定量的効果）
次に，定量的効果については，Xです．
これは，以下が前提条件になっており，
以下の計算式から算出することができます．
17
（５-３ 新技術導入時のリスクヘッジの具体事例）
また，新技術の導入時は，処理方式変更が発生しがちでありますが，Open棟梁の“プロジェクト テンプレート”を導入して開発をすることによる，共通化や，業務処理の切出し・局所化により，処理方式変更に迅速に対応できるようになりました．
図はその実例になります．この事例は，Azure PaaSを使用する案件で，Open棟梁のPaaS対応テンプレートを作成・適用をしました．
これにより，後のセキュリティ対策で必要となった“ゲートキーパーデザインパターン”（ストレージキー・ストレージアクセスをWebロールからバックエンドのWorkerロールへ移動する）への処理方式変更を，テンプレート側のコードを修正するだけで，サブクラスの業務処理の実装はそのままに，迅速に変更することが可能でした．
18
（５-４ SI事業者とSES事業者との連携）
そして，（このようなWin-Winの）OSSエコシステムの形成により，SI事業者とSES事業者との連携を強化することで，人材の育成と調達を可能にし，導入プロセスを更に進化させました．
具体的には，
• SES事業者のリードエンジニアは，セルフサポートでの導入が可能になり，
• SES事業者から有償サポートの提供を可能にすることで，セルフサポートでの導入で問題が発生した場合の問題解決を有償サポートに依頼することが可能になりました．
19
おわりに，
20
（６-１ 部門横断の施策策定の推進）
本発表では“このような”施策の適用とその効果について説明しました．
今後は， Open棟梁を使用して，以下の様な施策を進めていく予定です．
1. コミュニティへのコントリビュートの促進（プログラムや技術情報を開示）するため，プロジェクトに関わるベンダ間の契約を，プログラムや技術情報の留保が可能になるよう，契約の見直しを行うようにしている．
2. 今後，OSSエコシステムの中でフレームワークがエンハンスされていくようにWin－Win のOSSエコシステムの形成の方法を継続的に検討する．
21
（６-２ トランスフォーメーション（企業変革）の推進）
Open棟梁はシステム開発のQCDF向上というシステム開発力の強化についての貢献をこれまで行ってきました．しかし，今後はシステム開発力の強化ではなく，（図のような）トランスフォーメーション（企業変革）が求められてくると考えています．
このため，現在，Open棟梁の開発を遂行しているOSSコミュニティのサブワーキングであるSaaS開発ワーキングでは， 3社協創のSaaS開発を遂行しており，そのSaaSの基盤部分をSaaS開発基盤として今後，OSS化する予定です．このSaaS開発基盤は，今後のトランスフォーメーション（企業変革）の起爆剤として提案していこうと考えています．
22
23