トラブル削減のための原則拾七ヶ条とは？【まとめ】

立て札のタイトルをクリックすると各記事にジャンプ

はじめに

　私は30年以上システム開発に携わっていて、幸いなことに、他業界でおこった耐震強度偽装のような類の、悪意、犯罪が原因となったシステムトラブルに出会ったことがありません。私の知っているシステムエンジニアは、誠心誠意システム開発に取り組み、少しでもシステムの品質、システム開発の品質を高めようと努力している人たちでした。

　一方、多くのシステムエンジニアが日々努力しているにも拘わらず、システムトラブルは日常的に発生し、新聞紙上を賑わすようになっています。

　技術が進んだ21世紀になっても、システム開発は人が考え（例えばビジネス構想）、人が決め（例えば業務要件）、人が設計し（例えば仕様）、人が作り（例えばプログラミング）、人が稼動させる（例えば移行、本番展開）という、最初から最後まで人手に頼った仕事です。全ての工程において、人が普通に、いやどんなに熟慮、検討した場合にでもおこる、一般的なミス、誤りと無縁ではないのです。扱う対象が大きくなればなるほど、複雑になればなるほど、見えない部分が出てきますし、組み立てどおり、思い通りにならないことがたくさん発生します。決め事、はかりごとは規模に比例して、いやそれ以上に不安定になりますので、よほど慎重に神経を使って進めなくてはうまくいきません。

　システムトラブルの原因を押さえ込むことができたら、少しでも多くの誤り、ミスを事前に発見できたら、おこってしまった時でも、被害が広がらないようにして、損害を最小限にすることができたら、そんな願いを現実のものとするために、様々な取り組みが行われています。

トラブル削減のための原則拾七ヶ条

　さて、今回ご紹介するシステム開発担当者のための「トラブル削減のための原則拾七ヶ条」は、私が損害保険会社のシステム開発品質管理担当になった2001年に作成した基本動作の原則集です。開発担当者として自分が仕事をする時の基本にしていたことをまとめたものです。

　基本とすべきことはもちろん、他にもたくさんあります。私の経験の中でこれだけは意識してやった方がいいなと思うものを選びだしました。他にも、一般的な、根回しはタイミングよく、とか、キーパーソンを押さえろ、とか、連絡は受け手が読んで自分に期待されていること（やらなければいけないアクション）が理由とともにわかるように書く、とか、運用設計は開発の初めにおこなえ…とか、たくさんあったのですが、トラブル削減という視点から17個を決めました。

　ということで、損害保険という分野のシステム開発の事情を色濃く反映していることと思いますが、そこはお許しいただきたく、しかしお読みいただければわかっていただける通り、かなりな程度一般的に通用する内容と思います。

ルールは手段

　ところで、原則とか、ルールというものは、はさみと同じで、使いようで効果も、逆効果も出ます。若い方には既に遠い過去の出来事だろうと思いますが、JRが国鉄時代であった時の順法闘争などは、ルールどおり運用することを逆手に取ると、何がおこるかを象徴的に教えてくれます。ルールどおりに運転し、電車を運行出来なくすることが出来たわけです。

　原則やルールには、必ず目的がありますから、その目的を踏まえて使いこなさなくてはいけません。ルールの変更、適用についての例外設定も、ルールを作った目的の実現を踏まえて臨機応変に行わなければなりません。原則もルールもそれ自体が目的ではなく、手段です。いわば戦術兵器であるからです。

　今回、「トラブル削減のための原則拾七ヶ条」をご紹介するにあたって、なんでこういった原則を掲げなければいけないのか、説明を作りました。お読みいただき、活用していただければ幸いですし、自分のところではむしろこうだな、こうしよう…ということになっていただければさらにうれしくおもいます。