コード管理の効果と効用

システム管理におけるコード化の効果について所感を整理しておきたくなったので説明してみる

導入

コード化や仕組み化の効果（メリット）として、一般的にいわれるのは属人化回避という説明が多い。しかし少人数で担当している際は「誰かが頑張れば回ってしまうため今のままでもよい」と判断され、当てはまらないケースもある。

コード化は単に作業者が楽になるという話ではない。適切に分割することでフラストレーションを解消し、組織のケイパビリティを分散・最適化する効果があるのではと考える。

例

権限管理システムを例にとってみよう。

システム化前、やり取りベースの管理とそのプロセス

システム管理者のTさんが権限管理の設定項目の編集、適用を一手に引き受けており、依頼の対応から適用まで行っている場合、依頼プロセスは「やり取りベース（依存型）」になる。

依頼者は設定方法のやり方、設定項目を知ることができない状態なので、曖昧な依頼になりがち。これにより管理者が再度ヒアリングする、判断に迷って作業ミスする、などの手戻りが発生しやすくなる。

図にしてみるとこんな感じだろうか。

システム化後、コードベースの管理とその効果

対して、システム化後。権限管理の設定をツールを使ってコード化し、設定の編集は開発者などに、権限変更の適用は管理者のTさんに与えていた場合を考える。

依頼者はツールの使い方がを知っていれば誰でも変更を編集できる。特に、似たような権限を持つユーザーが居る場合は（類似依頼の踏襲で済むため）、手間なく変更依頼（PRレビューなど）が依頼者側からも可能になる。管理者は変更内容がコードなので、迷うことなく影響範囲も理解でき、設定項目の確認と権限の妥当性のチェックを行うことに集中できる。

これにより各々のケイパビリティのしきい値を下げる、またはシステム化することで互いにコミュニケーションがツールを介して規定され、手戻りやコミュニケーションミスが減る。

図にしてみると

コード化前後の互いにかかる負負担（認知負荷）について書き出してみる。

まずはコード化前の、管理者が変更・適用を一手に担う運用。そこでは以下の負担が生じるパターンを想定する。

• 翻訳（コミュニケーション）コスト
  • 曖昧な依頼を、システム（設定）に落とし込む変換・解釈する頭脳労働。
    • 依頼者と管理者の解釈違いによる設定ミスのリスク。
• マルチタスクコスト
  • 「要件のヒアリング」と「手順の確認」を、他の作業と並行で処理する負荷。
    • スイッチング・コスト増大による、対応遅延や疲弊・イライラの増加。
• 属人性コスト
  • 実際の手順や設定内容の全てをTさん一人に依存している。
    • Tさんの不在時（休暇や病欠）にシステムが停止する、もしくは引き継ぎが不可能になるリスク。

Tさんの業務範囲が、依頼を受けて適用作業をする役割に限定されているのなら、従来のままでもよいだろう。ガバナンスやセキュリティについての責任も負っている場合は、作業ミスや判断ミスと言ったリスクにもつながる。

次に、コード化後。以下の負担について解消される。Tさんは承認（決定）に集中できるので判断ミスのリスクは下がる。

• 翻訳コストの排除: 依頼者がコードを書くことで、翻訳は依頼者側で行われるため、管理者は「翻訳」作業から解放される。
• マルチタスクの分離: 管理者は「実装」と「承認」を同時に行わず、安全性の「判断」というシングルタスクに集中できる。
• 属人性の解消: 変更内容がテキストファイルとして可視化・履歴化され、ステークホルダーの記憶に依存するリスクがなくなる。

「判断」部分については管理者が行うため、依頼者側がシステムの使い方を把握して申請作業を行えるようになれば、変更作業のできる人が増える。権限管理のコード化により、客観的に仕様を眺められるようになる。ブラックボックス化を防ぎ、権限設定の適用状態を容易に確認できるようにもなる。

表でまとめると以下のようになる。

項目	Before（属人化）	After（コード管理）
認知リソース	認知資源が分散し、作業代行に浪費される。	認知資源が集中し、判断に活かされる。
役割の境界	「実装」と「承認」が混ざり、ミスが多発する。	「実装（コード）」と「承認（レビュー）」が分離される。
持続可能性	システムは「管理者のミスのない完璧な作業」に依存する。	システムは「仕組み」に依存し、持続可能になる。

論点。仕組みの分離の効果

次に、この仕組みにおける境界と役割を整理すると、コード管理の効用は、この境界の分離にあるのではないのだろうか。

• 実装の詳細（Why/How）： 申請者（User）がコードとして定義する。結果として意図が明確になる。
• 判断と責任（Decision）： 変更の妥当性の判断（適用の承認）は管理者（Admin）が行う。ガバナンスの担保のみに集中できる。

コード（もしくは権限管理システム）という共通の知識を用いることで、要望の伝達をプロトコル（例でいうと設定ファイル）として用いることができ、管理者は本来の役割である権限管理の妥当性の確認（品質管理）の集中できる。

管理者が個別のファイル管理にエネルギーを割くのではなく、権限管理システムがうまく回るような仕組みの維持・改修についてエネルギーを割くべき。

コード管理は業務プロセスにおけるコミュニケーションを自然言語からコードに変換するとも言える。

まとめ。システムをデザインするということ

コード管理を例に挙げた。システム化（コード化）などを設計する真の目的は、人間に「最高の記憶力と無限の認知負荷」を要求する運用を止めることにある。認知資源を最適配置し、組織全体のパフォーマンスと持続可能性を向上させるのが狙いだ。

単なる 流行っている ツールを使って、仕組みをつくりたい（ドヤりたい）のではなく、業務プロセスのコスト構造やリスク移譲のあり方を変えるために導入していく、というのが本筋ではないだろうか。技術が好き（と勘違いされて）その効用が浸透しないこともある。まだ、流行っていると事例も多く組織に浸透させやすいという側面はあるが、ノリで決めていくのはそのノリが合わない人には苦しい環境にだろうか。総合的にみたときの効用や効果については説明は用意しておくと納得感のあるシステム（や採用技術）につながるのではないだろうか。

システム開発は本来、こうした業務プロセスの仕組みをデザインするために行うものでは、と考える（it業界で一般的に言うengineeringの範疇）。

別な論点。今回はそこまで追求しないけども。

また、管理者に以下の期待（スキルセット）を同時に処理できるかと言うと。少なくとも専門性を持つという時点で希少であるので、さらにマルチタスクの対応適性も求めるのは非現実的であろう。そのためスタッフエンジニアやテックリードという職種が必要になってくる。

• 高度なシステム管理: システム設定の詳細やガバナンスの問題を把握する能力。
• 無限の忍耐力（感情労働）: マルチタスクによるストレスや疲労を抱えながらも、依頼者に対して常に丁寧に対応し、苛立ちを表に出さない対人スキル。

システムの運用と構築の維持において、非現実的な人物に依存するのは組織として無理があるだろう。結局DXとかAIといってもやっていること社員がやっている業務を代替するのみなので、どこで確認取ってインシデント（やネガが発生する）のを避けつつ、どこまで人間のミスを減らせるか（で、空いたリソースで本質的なビジネスをやれるか）の場所、空間をデザインできるかにかかっているのではないだろうか。