運用設計の難しさと起こりうる話

柚人

　こんばんは。
　Twitterでこんなツイートを見かけたのですが、当人へのリプだけじゃなく他の方への参考にも記事化しておこうと思い、noteに書きます。
　あと文字数(ry
　なお、述べる内容は自分も要件定義から機能設計から運用設計まで行なってきたからの経験則であり、なんらかの論文や書物から引用したものでも、体系化されたものでもないことを念頭において読んでいただければと思います。
　また、自分がやってきたのは、人事システム内に作ったワークフローとマスタ情報への反映、そしてマスタ情報の配信という部分です。

開発時に運用設計をしていないケースが散見される

　これはよくある話だと思います。
　システム開発において、必ず発注者という人がいます。そして、その人は大体実務者ではありません。また、実務者であったとしても、自分の前身、後続で何が起きているかまで把握している人は言うほど多くないのが現実です。
　つまり、多くのヒアリングから見えてくるものは点の処理です。
　システムが乱立する、機能が乱立すると、点がどんどん増えていき、それらがどう繋がっているのか、どこと繋がっているのか、が見えなくなります。

機能設計時に重要なこと

　機能設計をするときに重要なのは、点をつないだ線にしたとき、最初のトリガーから最後のトリガーまで確認することであり、最初と最後、がシステム処理で行える一つの動作ではなく、どこまでいけば、会社における業務がひと段落するか、で見る事です。
　つまり、一つの動作の中に、1時間や1日など時間的継続性がないものや、ワークフローの承認など操作者が切り替わる場合は、そこで一旦処理を区切り一つのオブジェクトとして作りますが、機能としては終わりではありません。
　ですが、先ほども述べたように1人の人から聞ける細かい話は、このオブジェクトレベルの話であることが殆どで、SIerの方が発注者から不満を言われるのは、このオブジェクトレベルで機能を作り実装してしまうことで、総じて「電子化」は出来たものの「省力化」には繋がらない為だと思われます。

運用設計時に重要なこと

　運用設計といっても2パターンの考え方が存在します。
　その2パターンの特性を理解し、必要物を切り分け準備することが重要です。

　一つはシステムの運用設計です。CI/CDと言われるものやDevOpsというのが昨今話題に上がりますが、プログラムを改修した時に環境構築などの作業を自動化したり、環境内に検証ソフトを入れることで、コンフリクトやスタックを検出する、品質管理を目的とした運用設計。
　これらには自動化した部分の動作監視という意味も踏まえ、ジョブ監視の動作も含みます。

　もう一つは、操作者の運用設計です。
　こちらが漏れているケースが非常に多く、その理由は仕様の決定者が実際にオペレーションを行う人間でない場合や、納期など時間的猶予の関係から「現場でのテストをスキップする」ことで、運用に入ってから現場から文句を言われたり、現場が想定外の動きをする事で、バグや不具合、現場のマニュアルや業務標準などとの齟齬が発生する、というものです。
　現場たたき上げで、システムを理解し運用マネジメントを行なってきたPMやPLがプロジェクトに入っていることは非常に稀で、特に企業が大きくなればなるほど、年数が長ければ長いほどこういったことは起きやすいです。

どうやって運用設計すればいいのか

　まず、自分は前者のシステムの運用設計(自動構築、ジョブ監視)には関わっていないので、そちらは割愛させていただきます。
　そのあたりは、CircleCIやAnsibleやJenkinsを入れた方に聞いていただければと思います。

　操作者の運用設計は以下の点に気をつけて行うことが重要です。
　・操作マニュアル作成は部門別/システム別で作る
　・業務標準の記載項目テンプレートを作成し、同じフォーマットで業務標準をつくり、操作マニュアルに記載する内容とは重複させない
　・業務標準は、部門別で作成するがシステム＋人で部門として負う責任範囲を示す
　・全体フロー、ドキュメント管理台帳、チケッティングシステムはセットで保管される(構成管理、インシデント管理、変更点管理は導入・運用において共通する仕組み)

全体フローの書き方
【前提】
　最初は、入力内容が決まる時(例:新入社員が入社する)
　最後は、他の社員同様全ての手続きが終了し、社内でやることがなくなる(例:社会保険の加入、給与項目の入力、各種雇用届の作成&提出など)
【気をつけるべきポイント】
　1.横軸に、操作権限別で人を表す
　2.縦軸に、操作フローと帳票、対象システムを記述する
　3.人による判断、システムによる処理、吐き出されるデータを明確に記載する(項目は描かなくて良いが、ファイル名や機能など詳細を調べるヒントを埋める)
　4.ヒアリングした各実務者に、自分の行う業務で入出力が合っているか確認するついでに全体フローを教える
　5.(完了まで時間的制約がある場合)時間軸も縦軸に添える

操作者の運用設計の成果物

　操作者の運用設計の成果物としては、上記のことから以下のものがあると良いと思います。
【各システム別】
　1.操作マニュアル(責任部門・作成者記載)
　2.業務標準(業務の概要、関係部署、入出力データのファイル名など)
　3.ドキュメント管理番号と来歴管理
【各機能別】
　1.全体フロー
　2.全体ドキュメント管理台帳
　3.各システム別チケット設定(インシデント管理のカテゴリ分け)

IT運用における必要な知識、関係者に広めると良いもの

・システム運用、管理者側向け:ITIL(アイティル)
・ユーザー向け:IT教育(ITパスポートの取得など)、全体フローの公開、責任分界点の記載されたドキュメント

まとめ

　ざらざらっと1時間半で書いたのであまり身のある話になっているか微妙なところですが、これから運用設計する方や、プログラマからSEになる方、体系的マネジメントを意識しだした方には参考になるかと思います。
　意見質問はTwitterにいただければと思います。
　たくさん語り合いたいですw

おしまい

いいなと思ったら応援しよう！