前回、工程管理ツールは企業で使うと効果的(1) として、企業全体で活用することを想定した工程管理ツールのコンセプトや特徴について明記した。
今回も引き続き、コンセプトや特徴を説明していきたいと思う。

前回は「企業の役割別に集計やセキュリティ管理をするための特徴」と「企業で統一して管理をするための特徴」の2つの特徴をあげて説明したので、今回は企業全体で工程管理ツールを使う時の「スケジュール作成のための特徴」として例をあげていきたい。

プロジェクトのスケジュールを作成する時、何回も作り変えたり作り直したりすることが多いと思う。また、大規模プロジェクトでは各関係者に作成してもらい、それを確認し修正版を再び受け取るなど、スケジュール作成は1回ですぐに完成とはいかないのではないだろうか。

これは工程管理ツールを使っても同じで、会社のサーバーへアップすると他プロジェクトの工数への影響があったり、各関係者からの計画を統合したりすると即座に全体への影響が出てしまうため、未確定版スケジュールをいくつも別プロジェクトやファイルとして作成するような運用でカバーするケースが多くなる。

実は企業全体で活用することを想定した工程管理ツールでは、他プロジェクトへの影響が無いようなシミュレーション用プロジェクトという考え方を持っている。
下図はマスタースケジュールに対し、ABC 3カ所の部隊やベンダーから詳細スケジュールを集めたものである。

詳細Bのスケジュールを見ると、マスタースケジュールのマイルストン日付を越えている状態になっており、

このままスケジュール計算をするとマスタースケジュールへの影響が出るため、事前に何回かシミュレーションを行い確定スケジュールを作成した時点で全体に反映したくなる。
こうしたシミュレーションを実現できるのが工程管理ツールが持っているプロジェクトのミラー化というものである。

下図はプロジェクトをシミュレーション用にミラー化したイメージである。
プロジェクトをミラー化するとシミュレーション用プロジェクトが別途作成される。このシミュレーション用プロジェクトは、全体工数やコストへの集計対象にならない他のプロジェクトにも全く影響が出ないものなので自由に編集・更新ができる。
ミラーは複数作成できるため、いくつかのスケジュールパターンを作成し、納得のいくスケジュールを最終的に反映させる使い方が多いようだ。もちろん必要なくなったミラープロジェクトは削除すれば良いだけである。

では、実際の工程管理ツールの画面例を紹介したいと思う。
今回も企業で活用できる工程管理ツールとして Oracle Primavera P6 の例で説明する。
下図はプロジェクトをミラー化する画面である。
XYZプロジェクトのマスタースケジュールのミラーを作成しようとしている。

「ミラーを作成」をクリックするとマスタースケジュールの下に、マスタースケジュール Reflection というミラーができあがる。これをシミュレーションパターンの数だけ作成していく。シミュレーションはそれぞれのスケジュールでも、パターンごとにまとめたスケジュールでも確認・編集ができるようになっている。

また、ミラーのスケジュールには上図のように「？」マークがついており、これらはシミュレーション用で工数やコストなどが全体（他のプロジェクトなど）に反映されないようになっている。
これにより他に登録されているプロジェクトへの影響もなく、シミュレーションを元に採用したいスケジュール案を計画できるのである。

もちろん「？」マークがついているミラーのスケジュールでも、下図のようにガントチャートが表示され、通常のスケジュール同様のイメージで同様の操作ができるようになっている。

次に編集・更新したミラーのスケジュールを反映させてみたいと思う。
下図は編集・修正したミラーを統合する画面である。対象のスケジュールを選択し「ミラーをソース・プロジェクトに統合」をクリックすると統合画面に移動する。

統合画面では、元となるスケジュール（ソース・プロジェクト）との差異が表示され、それぞれの項目を統合して良いかが確認できる。また、部分的に統合したい場合も対象部分だけチェックを入れれば、部分的に元スケジュールへ更新がかかるようになっている。
下図の例では、元となるスケジュールに更新（差異）があったアクティビティが更新項目・内容と共に確認でき、必要な更新部分をチェックで選択するようになっている。

このようにミラー作成、修正・更新、元スケジュールへの統合を行うことにより、スケジュール更新をいくつかのパターンでシミュレーションしながら、スケジュールを計画できるようになる。

さて、今回「工程管理ツールは企業で使うと効果的（2）」というテーマで、企業全体で工程管理ツールを使う時の「スケジュール作成のための特徴」の例としてスケジュールのシミュレーションについて説明してきた。
近年、企業としてのプロジェクト管理の仕組み作りを検討・導入する企業が増えてきている今、プロジェクト情報のサマリー集計やプロジェクト間の要員調整などに正確な情報集計が求められることになる。
工程管理ツールも企業全体で使用できるように進化してきている。ぜひ企業で活用してみてはいかがであろうか。

ITの活用が当たり前になってきている現代、プロジェクトではITを活用したさまざまな管理ツールが使われるようになっている。プロジェクトの工程（スケジュール）管理にも、いくつものITツールが販売されており、活用されている。 しかし、工程管理ツールにはプロジェクトのみに使うツール以外に、企業全体で使うことを想定しているものがあることはご存じだろうか。

これは企業としてプロジェクト管理方法をどう考えるか、企業内やプロジェクト関係者間でどのように情報を可視化していくかなど属人的なプロジェクト管理から脱却し、管理手法やツール（システム）を統一する動きが出ているからである。

では、企業全体で活用することを想定した工程管理ツールとはどのようなコンセプトで作られているのか？
ここでは「企業の役割別に集計やセキュリティ管理をするための特徴」と「企業で統一して管理をするための特徴」の2つの特徴で説明したいと思う。

最初に「企業の役割別に集計やセキュリティ管理をするための特徴」について説明する。
下図は企業で使うことを想定している工程管理ツールのプロジェクト管理構造である。

まず、プロジェクトの上に階層があることに注目してほしい。企業でプロジェクト管理の仕組みを考える場合、事業ドメイン別に（事業ドメイン＝組織の場合もあり）情報を収集する必要も出てくる。
このためプロジェクトの上位に事業ドメイン階層が作られており、関係プロジェクトの情報をサマリーレベルで集計できるようになっている。

もちろん集計値を確認する範囲や権限など、どの部署の誰にどのような役割で管理権限を与えるかはとても重要なものとなってくる。

下図は工程管理ツールが持つ EPS・プロジェクト・WBS・アクティビティに対しアクセス管理や各種コードなど、どのような属性項目が関連するかの相関図である。
この相関図の赤点線枠が管理権限に関する部分となり、OBS（Organization Breakdown Structure）で主管組織と役割を定義し、組織別・役割別に EPS・プロジェクト・WBS まで管理範囲が設定できるようになっている。また、役割別に編集や閲覧などの権限を持たせる設定もある。
これらを活用することにより、企業内それぞれの役割別の視点でプロジェクト・プログラム・ポートフォリオ管理を実現することができるようになる。

では例をあげて説明しよう。例えばアクティビティコードに関しては定義が以下のとおり3つの単位に分かれている。

以上のようにグローバルや EPS 単位にアクティビティコードを持たせることにより、企業標準のアクティビティコードを活用するようになり、企業で統一した視点で工程管理をすることが可能となるのである。

今まで企業で活用するための工程管理ツールの管理構造や特徴について説明してきた。
ここからは、実際の工程管理ツールの画面例を紹介したいと思う。
今回は企業で活用できる工程管理ツールとして Oracle Primavera P6 の例で説明する。

下図は「企業の役割別に集計やセキュリティ管理をするための特徴」で説明した管理構造の EPS とプロジェクトを登録した例である。
ここでは、EPS を全社 - 事業 - 事業拠点（海外or国内）- プログラムで階層化し、その下にプロジェクトが登録されている。

※EPS にプロジェクト名が入っている部分もあるが、大規模プロジェクトをサブプロジェクトに分け管理することを想定し、EPS にプロジェクト名を入れ複数のサブプロジェクト管理をするケースもある。

これらを登録することにより、プロジェクトだけでなく事業単位、事業拠点単位、プログラム単位でも進捗・工数・コスト状況を分析できるようになり、組織視点で事業の意思決定材料を集めることができるようになる。

下図は実際にプロジェクトの進捗・工数・コスト管理状況が各 EPS にボトムアップ集計されている分析画面である。
赤枠部分の「石油化学プラント事業」を見ると、配下のプロジェクト情報が集計され、事業当初計画の予算（BAC）
約172億円に対し、完成時予想コスト（EAC）が約176億円となっている。
また、SPI が0.91（<1）であることからこの事業は予定より若干進みが遅いこともわかる。
このように工程管理ツールから事業状況までもが分析できるのである。

次に「企業で統一して管理をするための特徴」の1つであるアクティビティコードの定義画面を紹介したいと思う。

下図は Oracle Primavera P6 のアクティビティコード定義画面である。赤枠内を見るとグローバル・EPS・プロジェクトと3つ選択できるようになっており、それぞれグローバル（企業単位）の標準アクティビティコード、EPS（事業単位）の標準アクティビティコード、プロジェクト独自のアクティビティコードが登録できる（それぞれに登録できるコード数は無制限）。
これらをうまく活用することにより、企業で統一してプロジェクト管理を行う仕組みの1つが実現できるようになるのである。

ここまで、工程管理ツールの具体的なイメージを紹介してきたが、企業全体で工程管理ツールを活用するためには、企業として管理構造・体系をどうするかなどを決めていく必要があることを忘れてはならない。

自社内で管理構造・体系を検討するのも良いが、ツールの構造に詳しい人間も必要となるため、各社のワークショップサービスを活用するケースも多いようだ。

弊社でも Oracle Primavera P6 といったツールの構造を説明しながら、お客様と管理構造・体系を決めていくワークショップサービス（EPM ソリューションサービス）を提供している。

さて今回、「工程管理ツールは企業で使うと効果的（1）」という題で企業全体で活用することを想定した工程管理ツールの特徴を説明してきた。
属人的なプロジェクト管理から脱却し、企業としてのプロジェクト管理の仕組み作りを検討・実施する企業が増えている今、工程管理ツールも時代の背景に合わせて進化している。みなさんも企業全体での工程管理ツールを活用を検討してみてはいかがであろうか。

前回、製造業におけるプロジェクト管理の仕組み作りとして個別受注生産について述べたが、今回は量産の話をしたいと思う。

量産というとプロジェクトという言葉から遠い感じがするが、近年では鉄道車両や航空機など中型（車などより大きく、船などより小さい）の生産にプロジェクト管理の要素を取り入れる傾向が出てきている。

それは鉄道車両や航空機など中型の生産は組立工程がそれなりに長いため、見込生産から計画生産に変更するところが増えてきているからだ。

たしかに計画生産にすると、仕掛の削減や全体のリードタイム短縮が期待できる。しかし、計画が正しくないと必要部品未入荷により組立作業員の待ちが続いたり、組立時の要員不足で作業の進みが悪くなったりする。

このようなことから、大日程・中日程に関して製造型番をプロジェクトとして捉え、全型番の工程とリソースを踏まえて計画・調整していくプログラム（プロジェクト）管理の考え方が取り入れられてきている。

では、どのように実現性のある最適な大日程・中日程を計画していくか述べていきたいと思う。

下図は大日程と中日程において工程計画で主に考慮しなくてはいけない項目をあげている。

大日程計画ではリソースキャパシティを考慮して実現性のある工程計画をする。
中日程ではリソースの制約の他に、組立設備の制約が入ってくる。組立作業は同じ作業を複数の製造番号で順に行っていくため、場所が空いていないと次の番号の組立を始めることができない。よって設備を考慮した工程計画・計画更新を以下に早く正しくできるかが組立中日程の工程計画のポイントになってくる。

次に組立中日程の組立設備の制約とリソース制約について図で説明していきたいと思う。

下図は組立中日程の例である。型A001を製造番号ごとに組立対象となる設備番号ごとに示している。下には組立員種類の負荷状況とキャパシティを示している。工程は同じ設備が同時期に重ならないよう、また組立員の状況を確認しながら計画や更新をする必要がある。

例えば、製造番号30815 の Z001 の組立日程が変更もしくは遅れた場合、下図のとおり 30816 は Z001 の組立ができなくなる。そのため 30816 と 30817 の工程をすぐに変更しなくてはいけない。また工程を変更することによりリソース（組立要員）のローディングも変わるので、要員調整などのため一緒に確認する必要も出てくる。

これらの考え方はシステムを活用しないと相当な手間がかかる。
ここからはプロジェクト管理システム（工程管理）を使った例を紹介したいと思う。

今回はプロジェクト工程管理システムの Oracle Primavera P6 の例で紹介する。
下図は製造番号30015工程 の Z001 の終了日が変更（遅く）なった例である。変更後の状況を確認後、スケジュールボタンを押すとすべての製造番号に対し設備を考慮して工程が自動調整される。あわせて工程更新後の要員ローディングも確認できる（ローディング負荷による工程調整もできる）。
このようにプロジェクト管理システムを使うことで即座に設備とリソースに配慮した工程作成が可能になる。

ここまで組立中日程の組立設備の制約とリソース制約を考慮した工程作成について話をしてきた。大日程もリソース制約も中日程のリソース制約同様にシステムで工程作成できる。これにより組立中日程までの工程計画・更新の仕組みができあがる。

ここからは、部品と組立中日程の日程調整について説明していく。

組立中日程がきちんと計画できても、各設備で組み立てるための部品が完了していないと組立が始められなくなってしまう。よって、部品中日程と組立中日程の日程のずれを確認できる仕組みを作り、日程調整する。

下図は組立中日程の作業開始に対し、部品がいつ完了予定かを表現している。Z002 の組立開始よりも2日後に部品が揃うことになり、調整が必要となることがわかる。
このように、どの組立作業に部品完了予定とのずれが生じているかをシステムを使ってすぐに確認する必要がある。
そのためには、部品中日程のシステムと組立中日程のシステムをつなぎ、いつでもそれぞれの日程を確認できるシステム構築を行う。

では、システムの例を紹介したいと思う。
下図は部品中日程でよく適用される MRP システムとプロジェクト工程管理システム Oracle Primavera P6 をつないだ例である。組立中日程側から部品完了予定が分かるようになっており、組立開始と部品完了予定までにどのくらいのずれがあるかが分かるようになっている。これによりすぐに調整に入ることができ、部品工程・組立工程・設備・要員すべてが加味された実現性のある中日程計画がいつでも可能となる。

さて、中型製造の計画生産におけるプロジェクト管理を取り入れた大・中日程の仕組み作りについて紹介してきた。
実際にはこの他にも下図のように小日程システム（MES や生産スケジューラーなど）との連携や BOM、手配システムとの連携、経営／組織／現場それぞれにおける BI を活用した KPI 分析なども仕組み作りの中には含まれる。

さらに、現在では全工場のマスタープランを1つにして、製造実現性と最適化を最大限考えた「プロジェクト・マニュファクチャリング」という考えが普及し始めている。

以上、今回は製造業におけるプロジェクト管理の仕組み作り（2）として、中型製造の計画生産におけるプロジェクト管理を取り入れた大・中日程の仕組み作りについて紹介してきた。最後に明記したプロジェクト・マニュファクチャリングも含め、世界的に製造業の工程計画・リソース計画を連携し統合していく動きが広まってきている。

企業としてのプロジェクト管理の仕組み作り同様に、製造業においても企業として情報の可視化や統合、リソース全体最適化が注目されている。
みなさんも製造業における企業としてのプロジェクト管理の仕組み作りを検討してみてはいかがであろうか。

今回は製造業のプロジェクト管理について話をしたいと思う。

製造業では余剰在庫をできるだけ減らすため、受注してから設計を始める個別受注生産に事業を変更して行う企業がよくある。
たしかに個別受注生産であれば余剰在庫を減らすことは考えられるが、設計・調達・組立まで一気通貫で工程管理、リソース管理をしていかないと、納期遅延やリソース不足、コスト増加を引き起こす。
つまり、生産管理以外にプロジェクト管理の考え方が必要になってくる。

では、個別受注生産におけるプロジェクト管理について述べていきたいと思う。

海外企業との競争など製造業も納期要望の短期化が進んでいるなか、多数の短納期案件を受注する製造業が増えている。経営陣や組織マネージャ、営業は、現案件がいつ完了して次の案件を始められるのか、人の都合はつくのかを、常に設計部門長・調達部門長・組立部門長に状況を確認し、お客様と話を行っていく。しかし、案件が増えてくると全案件の状況を把握することが困難になってくる。

このようななか、企業の全案件状況を確認していくため PMO（プロジェクト・マネジメント・オフィス）を一つの組織として設置する企業も出ている。
PMO は企業のプロジェクト管理を横断的に支援する立場として、各案件の進捗状況やリソース状況（もちろんその他もあるが）をモニタリングし、経営陣や組織マネージャへの報告、また対応が必要なプロジェクトに必要な支援を行っていく。
これにより企業として全案件の状況を分かるようにする考えであるが、PMO が全案件をモニタリングするための全社で統一した仕組みとシステムが必要だ。

上図は全社で統一した仕組みとシステムがない状態で起こるケースである。上図では、設計部門で個別に対象製番（案件）の管理をしており、調達部門や組立部門にはいつ図面があがってくるかがよく分からない。また調達部門や組立部門もそれぞれのシステムで個別に管理しており、設計部門からするといつまでにどの図面を作れば良いかが分かりづらい。さらに PMO は定期会議報告で受けた情報しかなく、最新の製番進捗状況が把握できない状態が起きている。

このような状態の時、企業は以下が可能となるシステムを検討することが多い。

• ・設計、調達、組立の進捗状況を一気通貫で確認できる（大日程、中日程レベル）
• ・必要スキルのリソース負荷状況を確認し要員調整が行える
• ・全製番をまとめて管理することができる
• ・全社が同一の仕組みで使える（海外拠点がある場合は多言語対応）

上図は全社で統一したシステムを考えたケースの例である。
この例では、BOM 構成を利用して大日程、中日程の構成を作り、小日程（生産スケジューラなど）と統合させて設計、調達、組立を一気通貫で確認できるようにした仕組みである。
製番の下を設計、調達、組立のフェーズにし、その下を BOM 構成にして遅れをトレースする考え方だ。これにより PMO はいつでもどの製番の、どのフェーズで、どの部品が遅れているのかをトレースできるようになる。

では、システム作りの例をあげていこう。今回は Oracle Primavera P6 と BOM システム、生産スケジューラの連携をベースにしたシステムの例である。
下図は Oracle Primavera P6 に全製番を登録し、WBS を BOM 構成として BOM システムから取り込み、アクティビティ（作業レベルのタスク）を生産スケジュールの小日程の日付から取り込んでいる。またアクティビティにはどのフェーズの作業か属性をつけておく。

これらの取り込みにより小日程から中日程（BOM 構成）、大日程（フェーズ）、製番へと工程計画・進捗、リソース工数の予実が集計される。これで PMO は全製番の進捗状況とリソース状況がわかるようになり、設計、調達、組立では一気通貫の管理が実現され、図面はいつ出来あがるか、いつまでに作れば良いかがそれぞれ分かるようになる。
もちろん、システムを使う前に、事業戦略案件、案件規模、案件難易度など常にモニタリングが必要な製番の洗い出しや、アラートの対象となる遅延日数、リソース投入可能数、超過工数の設定などをあらかじめ決めておく必要がある。

では、PMO がこのシステムでどのように全製番の状況をチェックするか記述していこう。
下図は製番一覧である。ここでは計画より10日以上遅れている製番に対しマークをつけ、対象製番だけを絞りこんで確認している。下図では 5 製番が10日以上遅れている状態であり、PMO は毎日遅れている製番だけを確認できるようになっている。
ただし前述したように、遅れ以外にも戦略的に優先して確認したい製番や規模や予算など企業にインパクトが大きいものは、システムで確認できるようにしておく。
今回は遅れ製番に焦点をおいて、どのようにトレースしていくかを明記したいと思う。

上図により遅れ製番が確認できたので、次にこれらの製番のどのフェーズが遅れているかを見ていく。

下図は 5 製番をフェーズ別に切り替えた画面である。たとえば製番P00400では、調達と組立に遅れが生じていることが分かる。

さらに、P00400の調達について部品構成を表示すると部品P-1、P-2、P-2-1に遅れが生じており、P-1とP-2-1については終了列に納品フラグの A（Actual）が無いことから、手配したが、未納ということが分かる。

また組立の遅れに対してリソース負荷状況を確認してみると、組立上級スキル（リーダーレベル）の負荷が高くなっており、調整が必要な状態になっていることも確認できる。

これで、PMO は全製番に対する進捗状況とリソース状況の確認や問題の抽出が
できるようになり必要な対策をどこに打てば良いかが明確になる。

今までは PMO の視点から話をしてきた。しかし、全社的に統一したシステムを使うとなると現業側からも見たい情報が見られるようにしたいものだ。今回はその一例をあげたいと思う。例えば、調達や組立では部品の入荷状況を一目で確認したいものである。調達と組立用の画面レイアウトを切り替えると、部品の発注数、入荷数、入荷率が各日程とともに分かるようになっている。これにより各部品の入荷状況がいつでも分かる。

また設計では、設計メンバーの稼働状況が気になる。設計メンバーの稼働状況画面に切り替えると、どのメンバーがどの製番でどのくらい稼働予定かが分かる。これによりリソース調整が可能となる。

以上のように PMO だけではなく、現業側の欲しい情報も用意することにより企業全体のシステムや仕組みの導入、運用がスムーズにできるようになる。

今回は製造業のプロジェクト管理をテーマに個別受注生産の全案件の工程、リソース管理の仕組み作りを説明してきた。

今回のように単体のプロジェクトではなく、複数プロジェクトをまとめて管理することを「プログラム管理」、経営戦略などによる優先度や規模、難易度などを入れて全プロジェクトを分析することを「プロジェクト・ポートフォリオ管理」という。

短納期で多数案件を管理する今回のような製造業では、全案件をモニタリングする組織やシステムを検討する企業が増えてきている。プログラム管理、プロジェクト・ポートフォリオ管理の考え方やシステムをいかに取り入れ、見える化できる仕組みを作っていくかが今後の鍵になっていくだろう。

※本文中のARES PRISMはブランド名を「Contruent Enterprisse」に変更いたしました

みなさんはプロジェクト用アプリケーションにクラウドを活用しているだろうか。
クラウドというと IaaS（Infrastructure as a Service）[イァース]、PaaS（Platform as a Service）[パース]、SaaS（Software as a Service）[サース]の3つの考え方が定番となっている。この3つの定義について調べてみると、IaaSはハードウエアまで、PaaS は OS や実行環境を伴うプラットフォームまで、SaaSはアプリケーションまでとよく書かれている。
しかし、SaaS はアプリケーションベンダーがその会社のアプリケーションのみ提供しているものであり、実際には PaaSのプラットフォームに自社でアプリケーションのインストールや設定を行うか、メインベンダーのアプリケーションに絞って SaaS にするかのどちらかになり、複数ベンダーのアプリケーションが自由に選べるわけではない。

例えば、あるユーザーがプロジェクトでCADアプリケーションと工程管理アプリケーションを使う必要が出たとき、CADベンダーと SaaS 契約したうえで、更に工程管理アプリケーションのベンダーと SaaS 契約する必要がある。
また、ユーザーはバージョンの指定が困難であったり、それぞれのアプリケーションベンダーへテクニカルな問い合わせや教育依頼をしなくてはいけないなどの課題が出てしまう。

そこで今回話題にあげたいのが、PaaS でも SaaS でもない必要なアプリケーション層までを提供する次世代クラウドである。
ソフトウエア（アプリケーション）とプラットフォーム両方を提供するということで、ここではあえて SPaaS（Software and Platform as a Service）[エスパース]と呼びたいと思う。
SPaaS はプラットフォームに加え、アプリケーション層を提供する。つまり必要なアプリケーションと数量を伝えるだけで、必要なアプリケーションが必要な数量だけ、いつでもどこでもブラウザから利用できるようになる。
これによりインストールなどの設定作業や認証化、ユーザー設定などが一切不要になる。

上図は SPaaS サービスのイメージであるが、プラットフォーム上にアプリケーション層があり、そのなかに必要なアプリケーションが必要な数量用意される。
サービス利用者はサービス提供ベンダーへ使いたいアプリケーション名、数量、ユーザー情報を伝える（ここでは、ユーザー1がアプリケーションAとB、ユーザー2がアプリケーションBとCとD）。するとユーザー1のブラウザからアプリケーションAとBが、ユーザー2のブラウザからBとCとDが使えるようになる。
ユーザーはいつでもどこでも必要なアプリケーションが利用できるようになるのだ。もちろんプラットフォームに自社システムを乗せることも、システム間連携開発を行うことも可能だ。

SPaaS サービスのメリットは運用が開始されてからさらに発揮される。
下図は一般的にアプリケーションの導入と運用に必要な業務である。
環境構築とシステム運用保守（ユーザー管理や障害対応など）、教育、ユーザーサポート（ヘルプデスク）などアプリケーション導入後はやるべきことが山のようにある。

しかし SPaaS サービスは、使用するすべてのアプリケーションに対してこれらを1つのユーザー専用ポータルから提供しているのだ。
もちろん、管理者専用ポータルではシステム管理者が気になるアプリケーションライセンス使用状況（ライセンスが足りているか、多過ぎないかなど）や利用場所履歴（なりすまし対応など）をいつでも確認できるようになっている。

もう1つ運用時に大きな問題になるのが、アプリケーションのバージョンアップである。アプリケーションベンダーが提供する SaaS はアプリケーションのバージョンアップがあった場合、プロジェクトの途中であっても強制的にバージョンアップされてしまう。この場合、プロジェクトのレポーティング（発注者側にする報告）やシステムパフォーマンス、連携しているシステムへの影響が懸念される。このような懸念に対し SaaS ではなくオンプレミスや IaaS、PaaS にしてアプリケーション製品管理は自社でという結論になる企業も多いようだ。

実は SPaaS サービスは、このようなケースにもっとも強い。
1つのアプリケーションに対し、複数のバージョンを持ち、ユーザーごとにバージョンを変えることが可能だ。
よってプロジェクトの途中で強制的にバージョンアップされることもなく、自社で対応する必要もないのである。
まさに IaaS でもない、PaaS でもない SaaS でもない SPaaS は第四の次世代クラウドの考え方である。

では SPaaS サービスの例を紹介したいと思う。
今回は弊社のプロジェクト用 SPaaS サービス「PROJECT CLOUD™」の例で紹介する。

下図はブラウザからユーザが PROJECT CLOUD™ にログインして工程管理アプリケーション Oracle Primavera P6 とコスト管理アプリケーション ARES PRISM を使用している例である。弊社への手続きはアプリケーション名と使用したいバージョンを申請するだけである（注：ライセンス自体は取り扱っていないアプリケーションもあるので要確認）。

アプリケーションにもよるが、申請後一週間もあれば各ユーザーのブラウザから申請したアプリケーションの（指定したバージョンの）アイコンが画面左に表示される。アイコンをクリックするとアプリケーションが立ち上がり、すぐに使用できる。

PROJECT CLOUD™ はプロジェクトで使用する以下の5カテゴリに対するアプリケーションを、200種類以上用意している。

 ● アセット管理＆トラッキング
 ● CAD/BIM
 ● コスト管理/見積
 ● GEO 地理空間情報
 ● プロジェクト管理/契約管理

例えば、有名なアプリケーションとして AutoCAD、ARES PRISM、Oracle Primavera、Microsoft 関連のアプリケーションを PROJECT CLOUD™ に申し込んだ場合、一週間程度で各ユーザーのブラウザにアイコンが表示され使用できるようになる。

また、上図のとおりサポートページも用意されており、申し込んだすべてのアプリケーションに対してサポートが受けられるようになっている。問い合わせ先が一元化されているので、ユーザーはアプリケーションごとに違うベンダーへ問い合わせする必要がなくなる。
企業によっては、社内システムサポート部門を用意しているところもあるが、プロジェクトに特化した専門スキルが必要なアプリケーションのサポートは難しいため、これらのサポートが1ヶ所から提供されることは、とても効果的である。

さらに、PROJECT CLOUD™ ではユーザーは画面でトレーニングをしながらアプリケーションの操作を覚えることができる（動画コンテンツ作成は別サービス）。
下図は、工程管理のアプリケーション Oracle Primavera P6 の操作トレーニング動画を使用している例である。
ユーザーは Oracle Primavera P6 を使って工程作成する手順、進捗更新する手順などがわかるようになっている。

ここまでは、ユーザー側のイメージで紹介してきたが SPaaS サービスである PROJECT CLOUD™ はシステム管理者にもメリットがある。
下図はシステム管理者専用ページである。使用されているアプリケーションの使用状況を表示している。これにより、ライセンスが不足していないか、また過剰にライセンス契約していないかを確認でき、ライセンス違反対策や適正ライセンス数の検討ができるようになる。

また、下図は利用場所履歴となっており、なりすまし対策等どこでアプリケーションが利用されているかが確認できるようになっている。

そのほか、アプリケーション別利用者状況やストレージ、サポート・ステータス（重要度別平均解決時間など）などシステム管理者が確認したいレポートが揃っている。

このように SPaaS サービスである PROJECT CLOUD™ は、いつでもどこでも必要なプロジェクト用アプリケーションが使用でき、システム管理者も管理用ポータル画面でいつでも必要な情報が揃い、アプリケーションの導入・管理時間や労力を大幅に縮小することができるサービスとなっている。

以上、今回は日々進化する通信環境において、新しいかたちのシステム提供（プロジェクト用）について話をしてきた。
企業では下図のように社内標準システムだけでなく、プロジェクトや業務でよく使用されるアプリケーションも企業としてまとめて運用・管理したいという動きがでてきている。併せて検討されるのが必要なときに必要な分の環境利用料だけ発生するクラウド環境の活用である。
今回紹介した IaaS、PaaS、SaaS でもない第四の次世代クラウドはそんな時代の流れにあったニーズにより考えられたものである。

企業として本当に必要なシステム環境が何か、いつでもどこでも利用できる状態にするにはどうしたらよいか。
進化する通信環境をうまく活用しシステム構築・運用・管理をしていくことが、経営やプロジェクトの意思決定を迅速化し、企業の力をあげていくに違いない。