6.1 運用面まで考慮したドキュメントの整備
Webのシステム開発のドキュメント体系としては、下記のようなドキュメント一式を納品物としておさめるというプロセスが一般的なイメージとしてあるのではないかと思います。
ある開発「案件」としてのドキュメント体系としては上記のようなものが一般的かと思いますが、運用されているシステムとして、整備されるべきドキュメント体系としてはすこし異なり、機能追加の各開発案件のためのドキュメントとともに、保守/運用という観点で求められるドキュメントが必要となってきます。
a. システム最新状態の要件定義書やシステム設計書
まずは、すでに実運用されているシステムに機能追加する開発案件の場合には、既存の仕組みをベースに機能追加や改修を行うことになりますので、開発「案件」のドキュメントとしての要件定義書は、既存のシステムをどのように改修するか・機能を追加するかという観点での要件の規定となります。また、システム設計書は改修する機能については設計内容の修正箇所がわかるように色をつけて修正版としたりしますが、既存機能の中でも改修を行わない部分については当該案件の納品ドキュメントには含めないのが普通ではないかと思います (改修しない部分も含めないほうが、改修範囲が明確になる面もあります)。
一方で、保守/運用という観点で必要となるのは、対象システムの現状/最新の要件・設計などを規定したドキュメントとなります。初期のシステム構築があり、その後に何回かの機能追加/改修の開発が行われたシステムの場合、各開発案件のドキュメントとは別にシステム全体についての最新状態を示すドキュメント一式の管理は運用/保守観点では必須となります。
また、継続的に運用していくことを考えると認識する必要があるのが、運用を開始した後にメンバとして加わってもらう、途中参加メンバが全体の仕組みを理解するための情報源としてのドキュメントです。全体像や仕組みを理解するためにはシステム設計書では細部までの記述がされ過ぎている面があり、その観点からもシステム全体の最新状態の要件定義書は必要となります。
さらに、システム規模がある程度以上に大きくなると、システム全体について要件レベルでも設計レベルでも一度に頭に入れて把握することが困難になってきます。特に業務フローとして複雑な面がある場合には、業務フロー図のようなそのシステムが使用される用途や状況が把握できるドキュメントが整備/更新される必要がありますし、ある程度以上の規模のシステムに対しては、大規模なシステムを部分的に把握/確認していくことを可能とするために、要件定義書とシステム設計書という２段階での全体説明資料のほかに、処理シーケンス図や状態遷移図などのような、特定の観点での仕組みを説明するドキュメントや、要件定義書とシステム設計書の中間レベルでの処理の流れを説明するドキュメントなども必要となります。
一方で、規模が大きくなればなるほど全体像を細部まで把握している人間がいることは期待できなくなりますので、ドキュメント体系としても重複した内容が含まれるドキュメントを用意してドキュメント内容のチェックがきく面も意識する必要があります。システム設計書についても外部設計書だけでなく、プログラム実装レベルでの設計内容を規定した内部設計書まで用意することが多くなると思います。プログラム実装レベルとはそのプログラム言語で実装を行うときの各関数/メソッドとしてどのような関数/メソッドを作り、それぞれの関数/メソッドではどのような機能をもたせ、リクエスト/レスポンスの項目は何とするのかまで規定するものです。なお、ドキュメントはより詳細まで記述した多数のドキュメントを用意できると好ましい面がありますが、ドキュメントの更新の負担も重くなっていく面もあるので、見積もり/スケジュール策定/人員アサインなどのおいても注意すべき点のひとつです。
b. 運用作業のためのドキュメント(仕組み)
Webシステムのドキュメントとしては、運用観点/保守観点のドキュメントも必要となってきますが、運用や保守を担当する人間が当該システムを理解するために、その仕組みや要件・仕様などが記載されたドキュメントおよび、日々の問い合わせなどに対応して調査を行う際の具体的な手順などをまとめてあるドキュメントの大きく２種類のドキュメントを用意できるとよい面があります。
仕組みなどを説明するドキュメントはシステムの規模が小さい場合には、開発時に作成する資料で十分である場合もありますが、システム規模が大きくなってくると、開発観点で作成している資料では運用/保守担当には必要ない部分も多くなり、マッチしない面が強くなってくることが多いので、別途、運用/保守用に必要となる情報のみをピックアップしたドキュメントを作成することが多くなります。
そのようなドキュメントに含まれる内容としては、システム全体のシステムアーキテクチャのような内容から、セキュリティ方針やその方針に従った各セキュリティ対策の設定などに関する資料、各種マスタデータの内容・どのようにシステムで利用されるかに関する説明資料、あるいは問い合わせ対応の調査などを行うときにまず確認することの多いサーバの各種ログに関する資料などがあります。
c. 運用作業のためのドキュメント (手順)
運用/保守の業務として重要なもののひとつとしては、ユーザ/クライアントからの問い合わせに対応した調査や、監視システムからのアラートに対応した調査、不具合事象に対する原因調査などのさまざまなシステムの調査業務があります。同一システムに対する問い合わせや不具合などに起因する調査業務は、同じあるいは類似のものが繰り返し発生する面があります。
したがって、新しい保守/運用担当がアサインされた場合に、それらの新メンバが早期に問い合わせや不具合調査に対応できるようにするために役に立つ情報として、どのような問い合わせ/不具合事象があった場合には、まずDBやサーバログなど、どの情報を確認して、その確認結果がどのような内容の場合には、次にどこを調べるとよいかという、事象タイプごとの調査手順を一式記載してあるドキュメントが整備されているとよいです。また、そのようなドキュメントは、新たな不具合事象が発生して対応した場合や、新たに増えてきた問い合わせが出てきた場合には、随時、手順を追記してドキュメント更新をしていくと、安定したシステム運用にもつながります。
Webディレクタとして次のステップをさがしている方たちへ
これからのWeb構築・Webディレクションとして、業務にまで踏み込んでディレクション/プロデュースすること、それが近年のバズワードであるDXにもつながること、そしてWebの進化とともにWeb構築の各種ツール/サービスやSaaSが広がってきていることにしたがって、業務とシステムの両面からWeb構築・運用していく人間が求められていくこと、そのためにどのような知識や能力を身に着けていくとよいかについて解説している「マガジン」です。