■日常処理として約20,000のジョブが起動。非常に高度なバッチ構成（起動時間帯は8:00～29:00）。

ほぼ1日中バッチが起動する為、システムとしてのクリティカルパスについては即時対応が要求される。

■生産手配、会計のホストシステム及びEDI、SFA（営業支援）、物流のオープンシステムとのシステム間連携が多数あり。

■ＩＴＩＬにおけるサービスサポート（日常運用保守）

・サービスデスク（ヘルプデスク）

・インシデント管理

・問題管理

・構成管理

・変更管理

・リリース管理

■バッチ稼働監視及びトラブル対応。

■アプリ開発支援

・バッチ登録申請，プリンタ登録申請。

・バッチパラメータ登録。

・バッチ構成設計。

・標準化作業。

■運用設計・提案（非機能要件）。

■拠点統廃合・分割を含む組織変更対応。

■顧客との調整。

対象業務が多く、サブシステム間インターフェースをバッチプログラム起動で調整する仕組み。

サブシステム間を横断するデータ・拠点間を統合するデータにおけるデータの不整合を

運用でカバーするなど運用支援工数が大量に発生している。

それでも、拠点間データ統一の難易度が高く、作業担当者個人判断に任せられないようなケースに

対するカバーの運用のしくみつくりなどの難度高い業務が中心。

その理由は、ジョブの前後関係を意識しなければ運用できないが、数千ものネット（ジョブの塊）が

くもの巣状態に存在している上、中にはホスト時代の構成が引き継がれているものもあり、

判断が難しい状態となっているため。

また、PRJ規模が大き過ぎると感覚的なものが全体的に鈍る感があり、経験の浅い若い人にとっては

極度のモチベーションの低下が感じられた。末端のメンバーは、簡単に本稼動が延期できるという

錯覚から、納期遅延に関する危機感・責任感が感じられず、疲弊感だけが蔓延する状況が見受けられた。

重なった時期にインフルエンザ感染者が現れ、結局は本番延期という顧客判断となってしまった。

プロジェクト管理（メンバーのモチベーションの維持管理）の仕方。

メンバーの大半が外部協力会社社員であるプロジェクトでは責任感・結束力が弱く徒に疲弊感、マンネリ感が漂っていた。

精神的に病むメンバーが出現したりと、大規模プロジェクトにおけるリーダーのリーダーシップの

ありかたやプロジェクト管理手法について多くのことを学んだ。