開発と運用のギャップ
• 「運用部門はこれから BCP やデータセンター内の電力確保に動かなければ ならないのに、開発部門の人たちは、こちらの事情をお構いなしでテスト を実行し続け、開発サーバの電源も落とさずに帰ってしまった」
• 「昨日は運用部門の人と６－７年ぶりに再会した。 HW/SW の安定性、運 用の継続性は重要と。現場の意見はやっぱり大事だ。その後はサービス企 画部門。こちらは全く違って HW/SW はどうでもいい、必要な機能さえ満 足してくれればと。次はセキュリティ部門だ。また違う意見なんだろうな。 」
• サービス設計導入時の検討漏れや実装が間に合わない部分を「運用でカ バーする」というように、設計側による " その場しのぎ " の影響を直接受 ける。「えー、カバーするの俺たちなの？」という声が運用現場から上が るものの、上から「がんばれ」と言われるとやるしかない、という現場も 多い。
事例① 開発と運用
1/17 （月）午前 8 時 23 分、 JR 東日本の運行管理システ
「 COSMOS （コスモス）」の運用でトラブルが生じ、 J
R 東日本新幹線が全線不通になる事件
『都内にある新幹線運行本部のダイヤ管理用モニター２２台すべてで、各列車の駅への到着予定時刻を 示す線が消え、運行指令はシステムの不具合が起きたと考えて全列車を止めた。ＪＲ東によると、この 日朝、雪で福島県内の東北新幹線のポイントが故障し、２４本の列車ダイヤを変更することになった。 この際、修正必要箇所がシステム上限の６００件を超えて線が一時的に消えたという。システム部門は こうした表示の仕組みや修正上限数を把握していたが、運行指令は知らされていなかった。』
実は運用担当部門がシステムの仕様を知らされていなかったことで、規定の 動作を「障害」と誤判定してしまったことが判明
システムの開発側は要件を定義して構築する側ですから、細部に渡る仕様も熟知しているものですが、 その情報がどこまで運用部門に伝えられるかは、その開発プロジェクトの多忙度合と開発側の献身性 に委ねられているといって過言ではありません。
多くの組織では、開発側よりも運用側の方が立場が弱いのです。
運用側の立場が弱い最大の理由は、開発側の方がハイスキルな人材が揃っており、スキル的にすでに負 けているからです。システム開発ベンダーの単価（平均 100 万円 / 月以上）と運用ベンダーの単価（平均 80万円 / 月以下）を見比べるだけでも明らかですね。スキル的に負けているからこそ、開発側が運用側 に資料を授ける、という構図がこれまで当たり前だったと思います
事例② ユーザと開発
グループ企業がアプリ領域とインフラ領域に別れて別の提案していたとしても、 アプリの制約に引きずられてミドルウェアの仕様が決まってしまうこともあります し、インフラ側でサーバ集約などを提案していくなら、上に乗っているアプリをど のように統合するかがポイントになるわけです。
こういった場面なら、通常はアカウント担当を顧客にアサインし、その人がグルー プ内企業のメンバーと連携して提案するのが一般的かと思いますが、たとえば富士 通はそういった体制が整っていないため、顧客は各グループ会社の営業担当と個 別に話をつけなければなりません。同じことを何度も話すことになり、顧客にと っては工数のムダになります
グループ内の連携不十分で顧客を苛立たせる大手 SI 企 業
東日本大震災から 3 日後の 2011 年 3 月 14 日。この日の午前に最初のトラブルは発 生した。テレビ局が東日本大震災の義援金を番組などで呼びかけたところ、みず ほ銀行東京中央支店のテレビ局の義援金口座（以下、口座 a ）に、振り込みが殺到 した。午前 10 時 16 分、振り込みによって生じた「取引明細」の件数が上限値を 超え、口座 a に対する「預金・取引内容照会」ができなくなった
事例③ 開発と運用
実は夜間バッチでも、一つの口座につき何件まで処理できるかを示す上限値の設 定があった。口座 a は、振り込み処理の前に明細を退避する準備処理で、この上 限値をオーバーした。このとき、現場にいたシステム担当者は、このような上限 値が勘定系システム「 STEPS 」に存在することを知らなかった
みずほ銀は昼間のオンラインと夜間バッチを、同じハードウエア（富士通製メイン フレーム）で交互に実行する。オンラインとバッチの並行処理は想定せず、準備 もしていなかった
夜間バッチを中断した後の自動運用手順を用意していなかった（表 -10 ）こと だ。みずほ銀は「 TARGET 」と呼ぶ夜間バッチの自動運行システムを使っている。 富士通が開発したものだ。 TARGET は一晩に約 3 万件のジョブを自動実行してい る
事例④ 顧客と提供者
経営層の想い
•情報システム部は経営に役立つハズ （たぶん）
•経営層の全社的視点を、情報システム部にも持ってほしい
•他社の情報システム導入事例を見て心が動いたことがある
•わが社のシステムは適切なコストに見合った効果を上げているのだろうか？確 信が持てない
•運用コストを下げようとすると「止まっても責任を取れない」と脅迫される 情報システム部管理職の想い
•全社的に横串を入れたいが、パワーが足りない！予算も人材も足りない！
•どんなシステムであるべきか？トップの想いが伝わってこない
•コストセンターと見られていて、モチベーションが低下している
•現有するシステムの運用ノウハウは貴重な財産！でもこのシステムをずっと使 い続けられるとは思っていない
CIOの悩み 現場の悩み 情報システム運用 コストを下げたい
外に出せないか 現場に翻弄例外処理だらけ 情報システム企画・開
発 どんなトレンドを信用すれば良いか分 からない
現状技術を捨てられな い
勉強する時間が無い CIO と情シス現場の乖離
【 Q4-1 】経営サイドの方：情報システム部門の成果に対して期待するものはなんですか？
自主的な運用
システムの安定稼動
自社のシステムを良くする努力を、顧客のシステム構築支援にも使えるようにして欲しい。
ハード・ソフト上の制約ではなく、実務効率に軸足を置いたシステム構築
ハードウェア、ソフトウェア、サービスにとらわれずシステムの最適化を考え、業務の可用性と完全性を追求したシステ ムを構築すること。
•経営に貢献するマネジメントシステムの運営
•コスト削減を目指すシステムではなく、売り上げに貢献 できるシステム作り。
•コスト（導入・運用）
•業務の継続性維持
•お客様、株主、経営に対して、結果を出すこと。
•コストセンターであるがために、コストを考えた仕事の やり方を考える
•業務のＩＴ化とコストバランス
•業務効率向上
•不明。コンセプトが見えない。
•コミュニケーション
•安定稼動
•情報セキュリティの確立
•セキュリティ
•安定稼働
•業務部門と連動した、 BA に基づく全体最適な企画
•情報統制＆費用対効果
•システムをツールとした業務コンサルティング（売上・ 利益拡大、業務効率化）
•安心・安全・安定
•システムの安定稼働 コスト削減
•ユーザの立場に立ったシステム運用
•経済産業省が提示している「企業のＩＴ化ステージ」の 第三ステージ（グループ内の全体最適化を目指すこと。
•ユーザ業務の効率化（本当にシステム化すべきかどうか を含めて業務全体を考えて提案・実現する）
•資産の有効活用
•情報システムの安定稼動 セキュリティ
•情報システムコスト削減、経営に資する情報システムの 開発•リスク対応
•情報の一元化
•関係会社も含めた基幹システムの再構築
•目的意識ある行動
•インフラの安定的な運用
•生産性の向上
•自身のスキルの向上と経営側・ユーザ側と強い信頼関係 を作ること
•システムの安定稼動
【 Q5-1 】情報システム部門の方：情報システム部門の活動方針として、最も重視しているものは 何ですか？
•短期開発・納期遵守による開発環境の悪化
•サービスインを迎えることが目標となっているため、運用設計や品質保証といったフェーズが優先的に短縮される。そのため、モ ノはそろっているように見えるが、品質に致命的な欠陥を内包したまま無理やり本番稼働させてしまっている。
•サービスイン時の検討漏れや実装が間に合わない部分を「運用でカバーする」というように、開発側による " その場しのぎ "の問 題が発生している。
•「運用でカバーする」ことにした問題が表面化しトラブル対応や保守業務が増加している。しかし、開発と運用を兼任している中 で、新しい開発の納期も迫っており、開発現場は疲弊しつつある。
•運用設計の不在によるサービス品質の低下
•開発での品質検証が不十分であり、かつ運用のことを想定したつくりとなっていないことから、システム投入し本番稼働させるま でに、様々な試練が待ち受けている。
•開発時に短期間で間に合わせるために、運用ドキュメントを場当たり的に作成したのだが、運用スキルが全く考慮されていな い。そのため高度な知識を前提とした複雑な手順となっていたり、判断基準があいまいで手順に一貫性が無かったりする。
•設計が明確でないため障害なのか仕様変更なのか切り分けが全く判断できない。
•開発と運用のコミュニケーション不足によるサービス品質の低下
•設計段階で開発部門がユーザ部門と運用要件について十分に調整せず、開発に着手する。その状態で運用部門に引き渡されてくる ため、運用要件を事後で対応せざるを得ない状況となっている。
•システム上の制限値や有効値に対する回避策や対処方法、開発時に発見され修正されていない問題、開発時に実施されていないテ スト内容、 SLA の取り決めのうち運用で対応するべき項目と開発で実装済みな項目、システム構成情報等、開発から十分な情報の 引き渡しが無いまま本番稼働してしまう。そのため、トラブルが発生しても必要情報が得られず長期化することが多い。
状況
リアクティブな対応 リアクティブな対応
ビジネスニーズの増加
ビジネスニーズの増加 開発環境の悪化開発環境の悪化 サービス品質の低下サービス品質の低下
トラブル多発 トラブル多発 ユーザ・顧客・経営層
ユーザ・顧客・経営層 開発部門開発部門 運用部門運用部門 IT部門
IT部門 ユーザ部門
ユーザ部門
モチベーションの低下 開発能率の低下
運用部門の評価低下
責任の追及
運用手順の複雑化 不明確な復旧手順 保守作業の増加 トラブル対応の増加
IT部門への信頼低下 不透明な投資への不信
コミュニケーション不 足
コミュニケーション不 足
短期開発・納期遵守
短期開発・納期遵守 運用設計の不在運用設計の不在 移行期間増移行期間増コスト増コスト増
運用工数増大要因
サービスライフサイクルの観点で、インシデントを分析する（ ITIL の
活用例１）自社の運用のインシデントを収集し、（セキュリティ的に問題になるなら
、カテゴリだけでも収集）し、分析してみる。
