問題がいつまでも解決しない――
同じ過ちを繰り返す――
仕事がマンネリ化している――
身の回りにも思い当たる節があるかもしれない。担当者の能力や責任に負わせるのは簡単だが，一方で担当者がよく動き，改善していく開発・運用現場もたくさんある。その差はどこから来るのか。それは，担当者が自発的に動くような仕組みがあるかどうかによって決まる。
システム開発・運用の担当者が自ら動かざるを得ない状況を作り上げる「動く力」。これが第4の力である。
継続的にチェックする
ソニー生命保険は度重なるシステム障害に苦慮していた。サービス停止によるエンドユーザーからの不満はもちろん，深夜に及ぶ作業による担当者の疲労も悩みの種だった。発生した問題はノーツDBに障害対応報告として記録。毎月，リスク管理部門を交えた対策会議も実施していたが，目立った効果は見られなかった。
「何とかしなければ」と考えた河村芳樹氏は，障害対策検討会のやり方を大きく変えた。その結果，担当者が障害撲滅に向けて自らアクションを起こすようになり，4年間で障害件数を半減させることに成功した。
検討会では障害に対して後ろ向きになりがちだった議論をやめ，CPU使用率やディスク使用率，チャネル使用率などを盛り込んだ稼働月報から導き出されるトレンドや将来に向けた改善事項，ヘルプデスクへの問い合わせ内容を主に議論する。その上で，繰り返し発生している障害などを「重点対策」と指定。毎月の検討会で解決するまでフォローし続ける（図7）。
 |
| 図7●4年間でシステム障害件数を半数以下に減らした，ソニー生命保険の「障害対策検討会」 4年前に障害対策検討会のやり方を抜本的に変更した。使用するレポートの内容を障害に直結する項目に変更し，重点対策は解決するまでしつこく進捗を追跡することで，劇的な効果を上げた [画像のクリックで拡大表示] |
「担当者は自分の仕事が重点対策に取り上げられることを嫌うから，障害が起きないように普段から注意するようになる。いったん重点項目に取り上げられると次の検討会で必ず進捗報告を求められるから，1カ月の間に何らかのアクションを起こさざるを得なくなる」（河村氏）。
重点対策からは，いろいろな具体策が生まれている。例えば，以前はインフラの変更管理が十分でなく，障害発生時にどのような対策を施したかすら把握できていなかった。重点対策で取り上げた結果，作業手順や稼働検証方法，リスクなどを「作業計画書」として文書化し，承認を得なければ作業できないルールを決めた。
他システムの教訓を伝える
自分が担当するシステムに障害やミスがなくても担当者が動く仕組みを作ったのが，ヤフーのリスティング事業部である。リスティング事業部は「検索サービス」「情報掲載サービス」「地域サービス」という社外向けの三つのシステム群を担当している。
三つのシステム群のうち，どれかに障害やミスが発生したら，それぞれの担当者がまずそれを解決する。問題が解決した後で，トラブルの内容を部内トラブル対策事務局に報告する。事務局には三つのシステム群からそれぞれ担当者が参加しており，トラブルの経緯や原因，対策などの情報をここで共有する。
トラブル対策事務局では，たとえ自分が担当するシステムに同じ障害やミスが起きていなくても，同じ事象が起きる可能性があると判断されれば，他のシステムが適用した再発防止策をあらかじめ適用することを求められる。これにより将来起こっていたかもしれない障害やミスを，未然に防ぐことができるようになった。
そうした例として，次のようなものがあった。「あるシステムで，誰かがやっているだろうとメンバーが互いに思っていて，完成間近になったところで作業の不足が判明し，作業が遅延してしまったことがあった。再発防止策として，作業アイテムの洗い出しやアイテムごとの担当者アサインを徹底するようにし，リスティング事業部全体に適用した」（リスティング事業部 開発部長 小林睦氏）。結果，リスティング事業部全体として，同じような作業漏れを減らすことに成功した。
