仕事の進め方：PDCAサイクルとは
月刊「Windows Server World」の連載コラム「IT嫌いはまだ早い」の編集前原稿です。もし、このコラムを読んで面白いと思ったら、ぜひバックナンバー（2009年８月号）をお求めください。もっと面白いはずです。
■□■
IT業界にはいろいろな仕事があるが、大きく分けるとシステム開発とシステム運用に分かれる。いずれも重要な仕事だがその性質には違いがある。今回は両者の違いを紹介しよう。
●システム開発とシステム運用
IT業界の仕事は大きく「システム開発」と「システム運用」の2種類に分類される。
システム開発は、新しいプログラムの作成や、既存のプログラムを修正する作業だ。システム開発では、利用者に必要な機能を見極め、コンピュータでどのようにして実現するかを考え、実際にプログラムとして完成させる。
システム開発では、開発開始日と開発完了日が明確に決まっている。完了日が遅れることはあるが、とにかく完了日ははっきりしている。今までにない独自の製品やサービスを、有限の期間で作成する業務を「プロジェクト」と呼ぶ。SE（システムエンジニア）やプログラマなど、IT業界でよく知られた職種はたいていプロジェクトに関わる人たちである。
一方、システム運用は完成したプログラムを円滑に利用するための環境を整える作業だ。たとえば、必要なコンピュータやネットワークが正しく動作しているかどうかを監視し、故障があれば修復を行う。システム運用の仕事には始まりはあっても終わりがない。
開発と運用はどちらが重要ということはない。鉄道に例えてみよう。新しい鉄道路線を開通させるのは開発の仕事だ。そしてその鉄道が安全に運行できるように車両や線路の点検をするのが運用の仕事だ。開発者がいなければサービスは始まらないが、運用する人がいなければ事故が起きるかもしれない。どちらも同じように大切だ。
●派手なシステム開発と地味なシステム運用
一般に、システム開発の方が派手な仕事であることは確かだ。システム開発プロジェクトの成功は、しばしばニュースやドキュメンタリ番組になる。また、時代の先駆けとなったシステムは歴史に残る。たとえばJRグループの座席予約システム「マルス」は世界でも最初期のオンライン座席予約システムであり、その後継システムが現在でも使われている（*1）。日本のコンピュータの歴史を語る上では欠かせないシステムなので情報処理学会により「情報処理技術遺産」として認定された。
ところがシステム運用の成功がニュースになることは少ない。日本が世界に誇る新幹線は、自動列車制御装置（ATC）に代表される高度な技術だけで安全性と正確性が維持できているわけではない。そこには車両点検や線路の保守など日々の運行に関わる人々の努力が欠かせない。しかし保守点検作業が注目されることは極めて少ない。実に理不尽である。
成功ではなく、システム運用の失敗がニュースになることはしばしばある。運用担当者がバックアップ手順を間違えて本来のデータを消去してしまったとか、コマンドの入力ミスでネットワークが停止したとか、さまざまなミスの結果大きな被害を出してしまうこともある。うまくいって当たり前、失敗したら非難されるのがシステム運用の宿命だ。
実際のところ、システム開発とシステム運用は車の両輪である。開発させたシステムは運用しなければ役に立たないし、開発されていないシステムを運用することはできない。先進的な機能を搭載していても、バックアップが面倒だったり、トラブルシューティング手順が複雑だったりすると、運用担当者から敬遠され、別の手段で代用できないか検討されてしまうかもしれない。
●システム運用の仕事：PDCA
システム開発の仕事は「プロジェクト」としてよく知られている。NHKの人気シリーズ「プロジェクトX」のようなことはだいたい起きると思って良い。それに対して、システム運用の仕事はあまり知られていない。いい機会なので、システム運用の仕事のスタイルを紹介しよう。
システム運用の基本はPDCAサイクルだ。これは以下の4段階の頭文字をつなげたものである。
- Plan （計画）…業務計画を作成する
- Do（実行）…計画に沿って実施する
- Check（評価）…実施が計画に沿っているかどうかを確認する
- Action（処置）…実施が計画に沿っていない部分を調べて処置をする
最後のActionは、思いついたものをすぐに実行するのではなく、次のPDCAの起点となる。つまり、PDC（A=PDC（A=PDC……））と無限に続く。ちょうどらせん階段を上るように改善が進むので「サイクル（繰り返し）」と呼ぶ。
計画と評価には数値目標を設定すべきだとされている。「システム停止時間何分以内」「トラブル報告から初期対応まで何時間以内」という具合だ。
また、計画はもちろん、実行したことや評価項目まで逐一記録すべきだとされている。たいていのトラブルは何かを行ったあとで発生する。急に動かなくなったコンピュータの持ち主に「何かしましたか?」と尋ねるとたいてい「何もしていません」と言う。しかし、ほとんどの場合は何かしているはずだ。自分でも気付いていない「何か」を明らかにするため、あらゆる管理作業を記録する。
PDCAサイクルは品質管理工程として提案されたが、終了時期が決まっていないすべての仕事に対して有効である。プロジェクトのように終わりがある場合は改善にかけられる時間に制限がある。そのため、問題に優先順位を付け、軽微な問題についてはあえて対策を取らないこともあり得る。しかし、一般業務では優先順位は付けても対策をしないことはあり得ない。締め切りがないからだ。ちなみに、あえて対策を取らない問題点のことを「運用で対処（する問題点）」と呼ぶ。
PDCAサイクルの考え方は、ほとんどの日常業務に対して非常に有益なので、新人研修のカリキュラムにもよく取り入れられる。しかし、実際の業務で適用するにはどうすればよいかまで理解できているだろうか。筆者はよく理解できなかった。言っていることは分かるのだが、具体的な行動に結びつけられなかった。
後に筆者が解釈したPDCAのあり方はこうだ。
- Plan（計画）は「頭で考える」
- Do（実施）は「身体を動かす」
- Check（評価）は「他人に見てもらう」
- Action（処置）は次のPlanの始まり
評価するための数値目標があれば他人に見てもらう必要はなく、自分で判断できる。
以前「IT技能を習得するには」で知識と経験のバランスについて書いた。しかしそこには足りないものがある。それは何か。知識は頭で理解する「Plan」、経験は身体を動かす「Do」と考えれば「Check」が必要なことが分かるだろう。
スポーツなら試合に勝つ、プログラマならプログラムの作成速度やバグの量を評価することで初めて次のステップに進むことができる。
●予実管理
ビジネスで大事なことは、利益を上げることよりも、予定通りにことが進むことである。そこで、予算を立て、ビジネスを行い、決算をして、翌年度の計画を立てる。これもPDCAの一種である。
個人の仕事でも計画を立ててから行い、あとで確認することが望ましい。IT業界の人は常に忙しい。計画を立てないと日々の仕事に流されてしまい、自分の成長に時間を割けない。自分が成長したければ、今年は、今月は、あるいは今週は何をするという計画を立て、その計画が実行できたかをその都度確認しよう。実行できなければそれはなぜかを考えて次の計画に生かせばよい。PDCAを意識することで、日々の作業に追われるのではなく、主体的に仕事に取り組めるだろう。
もちろん計画通りに進まないことは多い。計画通りに進む方が少ないくらいだ。それでも、計画を立ててから実践し確認する手順は有益なはずだ。フランスの細菌学者ルイ・パスツールはこう言った。
偶然は準備のできていない人を助けない
（*1）MARSは、アメリカン航空とIBMが共同開発中だったシステムSABREを参考にしたと言われている。SABREの契約は1957年で最初の稼働は1960年である。マルスの稼働は1960年1月だから稼働はほぼ同時期と考えて良い。
■□■Web版のためのあとがき■□■
以前、マイクロソフトの技術カンファレンス「TechEd」の基調講演で、開発者と運用管理者と利用者が悪口を言い合う寸劇が披露されたことがある。
開発者は「自分たちの作ったシステムが正しく使われないのは運用が悪いからだ」と言い、運用管理者は「システムが悪いから使えない」と言い、利用者は「こんな使いにくいシステムはだめだ」とぼやいていた。
関係が近いほど、相手を悪くいうのは一般的な習慣のようだ。
友人の建築設計士によると、大工と左官は仲が悪いらしい。中国日本韓国（CJK）も基本的にはお互いに良い感情を持っていないし、イギリス人とフランス人、フランス人とドイツ人も決して仲良くはないらしい。
他人と献花するよりも、家族内での口論の方が多いのも同じことかもしれない。
しかし、お互いに悪口を言うだけでは、気分は晴れるかもしれないが問題は解決しない。共通の目的のために和解するのが「大人」というものだろう。