皆様こんにちは、伊藤です。

先回は、「障害対応から障害低減への脱皮」につきまして述べましたが、今回はその活動の中で進められた、システムの開発体制の改革について述べようと思います。

目次

障害低減活動を通じた、システム開発部署の変化

システム開発の自工程完結と障害低減活動

次回予告

障害低減活動を通じた、システム開発部署の変化

システム運用部署だけでは、障害対応から障害低減へ脱皮することはできません。それは、ユーザー部門や、システム開発部署との連携の成果であることは、先回申し上げました。

今回は、このシステム開発部署との連携の過程で、システム開発部署で成し遂げられた開発体制の改善についてもう少し具体的にご説明したいと思います。

システム開発と申しましても、最近はアジャイル開発とか様々な手法が適用されておりますが、弊社メインフレーム系の開発におきましては従来からのウォーターフォール方式を採用しております。ただ、今回の改善の中身につきましては、基本的にどのような開発方式を採用しても採用可能な方法だと考えております。

ところで、我々の企業グループには「自工程完結」という考え方がございます。元々はものづくりの現場での活動から始まったものです。

具体的には、品質、納期を守って製品を作り続けるため、自分の担当する工程＝自工程で、その工程で要求されている品質や、納期を守るため、作業要領書を中心にして、自分の作業内容や、使用する工具のコンディション、組み付ける部品の状態などといった、工程の環境与件＝良品条件　と　自分の工程でのものづくり品質や納期が、要求に応えているかどうかを判断するものさし＝良品状態　を決め、良品条件、良品状態を自分で確認しつつ作業を行う＝完結させる　ことです。

弊社では、この「自工程完結」活動を、ものづくりの現場から会社全体へと拡大展開しております。情報システム部においては、開発、運用、マネジメントなどの部署でそれぞれの業務を個別工程に細分化し、工程ごとの要領、良品条件、良品状態を作成しております。

そういった中で、運用部署での、障害対応から障害低減へといった活動の変化がはじまりました。まさしく、システム障害が発生した　ということは、システムが「良品状態」になっていない　ということになるわけです。

障害低減活動でのシステム開発部署の役割は、起こった障害への対処に留まらず、障害の再発防止活動として、システム開発過程のどこの要素作業で問題があって障害となったのか、その何が問題であったのか、その問題を起こさないようにするためにはどうすればよいか。ということを障害ごとに実施するわけです。これは大きな障害の場合だけではありません。 

このことから障害低減活動をシステム開発の自工程完結と結びつける活動が始まったのです。

システム開発の自工程完結と障害低減活動

読者の皆様はご承知かと存じますが、システム開発にはいくつかのステップがございます。会社により呼び方は多少異なっているかと思いますが大きく区分すると、企画、仕様決定、外部設計、内部設計、プログラム作成、個別テスト、総合テスト、本番移行準備、教育、本番切替えという流れです。

我々はシステム開発作業の自工程完結を進めるにあたり、各ステップの中の作業手順をさらに要素作業として細分化し、それぞれの要素作業ごとに良品条件、良品状態を明確化いたしました。

具体的には、内部設計の作業を、サブシステム構造化設計、システム性能・資源の検証・・・という作業手順に分解し、さらにそれらの作業手順を、たとえば、サブシステム構造化設計では、外部設計書理解、サブシステム細分化、機能構成図・機能関連図の作成　といった要素作業に細分化して、それぞれの要素作業毎に、必要な情報、良品条件、良品状態（その要素作業が正しく行われたかどうかを担当者自身で判断できる客観的な状態）を文書化したわけです。

これまで使っていました要領書やチェックシートなどは、要素作業のツールや、良品条件の確認表として織り込んでおります。この自工程完結活動を行う中で、作業要素に細分化した結果、標準がなく、個人ごとに個別判断している部分があったり、良品条件が明確になっていなかったりと、様々なことも判ってまいりました。これら不足している内容は、自工程完結活動の中で追加してまいりました。

これらの成果物は、自工程完結テンプレートとして、個別のシステム開発ごとにコピーし、システム開発者が実際に使ってまいります。そのまま、システム開発のドキュメントの一部になるわけです。個別の成果物や、チェックシートなどは、この表にハイパーリンクで紐付けてあり、常に参照できます。

このようにシステム開発業務を自工程完結活動で再定義したことにより、障害低減にも大変役立つものになりました。

障害低減に向けた障害再発防止がどのようにして、これらの自工程完結テンプレートに展開されるかを具体的に申し上げますと、例えば障害の原因が、「システム変更時の運用マニュアルの記載モレ」であった場合、「運用マニュアルの作成、改訂」という要素作業のなかで、どのようなミスがあったのか、ミスをなくすようにするには何をすればよいか、なぜミスに気付かず次の作業に進んでしまったか　といったことを、「運用マニュアル作成、改訂」という要素作業の良品条件、良品状態に追加すればよいのです。それをテンプレートに即時に反映することで、同様の作業を行う他のシステム開発者による同じようなミスをなくすことができます。また、これらの変更については、障害報告書が結び付けられており、テンプレートの使用者はなぜこのような作業をしなければならないかを、原点にさかのぼって確認できます。このようにして、システム開発者への展開が確実に行えます。先回の障害低減の活動の説明の中で、「再発防止活動」と申しております部分がこの内容になります。

このようにして、システム開発者の全員の努力により、新規開発、変更時の全プロセスに、障害対策や、そのほかの気付きにより常にメインテナンスされるテンプレートが用意できました。

大規模なシステム開発の際には、チェックの目も入り、品質管理も行われますが、システムの改善のような小規模のプロジェクトでは、残念ながら開発者まかせになってしまうことも多々ございます。このようなケースでも、開発工程の必要な部分を上司と確認しあい、該当する要素作業をテンプレートから抽出して仕事を進めるようにしております。このようにして、類似障害の低減に大きく寄与することができ、障害を起こしにくいシステム開発体制を構築することができました。

今回は運用設計そのものではありませんが、障害を減らすという意味では運用と大変関係の深い内容だと考え紹介させていただきました。
読者の皆様のご参考になれば幸いです。

次回予告

次回は、「システムオーナーと運用の関係について」お話をしたいと思います。