障害が多発するサービス開発の現場。
アプリケーションは新機能をリリースするたびに不具合が流出し、インフラのメンテナンスにおいても作業ミスや考慮漏れが多く障害が頻発する状況。
当時私自身は主にソフトウェア開発を役割とする開発部門のマネージャーに就任した直後であり、主にアプリケーションの品質改善と業務プロセスの改善に関与した。
アプリケーションリリース後の致命的な不具合（※）をゼロにする。
（※）改善活動の過程で定義した分類で、ユーザの業務に支障が出る不具合や回避策がない機能不全を指す
月並みですが、観察→課題抽出→施策立案→実行→評価といった流れで進めました。
- 現状の業務プロセスを把握するため関係者へのヒアリングを経てフロー図を作成
- 開発項目の決定からリリースまでの流れに着目すると以下の課題が浮かび上がった
- (1) コミュニケーション（要望発出～受取の経路が複数ある）
- 製品に関わる多様な立場の人から多様な方法で開発部門に要望が流れてくる
- 可視性の高いものから低いものまで。極端な例としていわゆる「タバコ部屋」で交わされるやり取りで決まった開発項目も存在した
- 要望を受ける側も複数人いる状況。また、優先度や切迫度合いが不透明で選定基準も不明確で「安請け合い」で開発項目が増加していた
- 開発者の業務量が過剰な状態が続き恒常的に開発スケジュールを圧迫していた
- 要望された機能開発をこなすだけで精一杯でリファクタリングやテストコードの充実など内部品質の向上につながる活動はほぼゼロという状況に陥っていた
- インフラ部門も同様の状況であった（サーバーの設定変更や構成変更の依頼が複数の部門、メンバーからあらゆる経路で飛んでくる）
- (2) 構成管理（イレギュラーな実行環境が存在する）
- 個別のユーザ向けにカスタマイズされた実行環境が複数存在するが全容が不明
- ここで言うカスタマイズは SaaS として妥当と思われる動作切替の仕組み（アプリケーションの設定項目として実装する等）を逸脱し、ユーザによって OS/MW の構成が異なったりアプリケーションのバージョンが異なるといったレベルのもの
- どのユーザ向けにどのレイヤーでどのようなカスタマイズがされているのか、開発・インフラの特定のメンバーしか知らない状態
- アプリケーション改修やメンテナンスの影響範囲分析の際に考慮漏れして障害につながるケースが多発していた
- (3) 悪循環
- (1)、(2) の帰結としてサービスの内部品質が悪化
- 障害対応に追われて改善活動が進まないまま疲弊し新たな障害を呼び込む、という悪循環に陥っていた
- 課題に対する打ち手を検討し実行
- (1-a) 要望の一元管理化
- まずは全ての要望を一か所で一覧できるようにする必要があると考えた
- そこを見れば「いつ、誰が、なぜその要望を上げたのか」が分かる状態にする
- 要望管理は Redmine で運用することとし、チケットのテンプレートとして上記のような基本的項目と優先度の判定に必要な項目（対応しなかった場合のビジネスインパクト等）を設けた
- (1-b) 要望の評価方法の策定
- 一元化された要望一覧に対して優先度を判定しリリース計画に取り込むか否か判断するルールを策定
- 評価観点を抽出し、それぞれについて具体的な評価方法を作成。スコアリングによって開発項目を決定するようにした
- 観点としては、要望元のユーザとその分類、社内各部門の業務負荷軽減への寄与度合い、マーケティング上のインパクト、ビジネスモデル/戦略との合致具合など
- スコアリングは ICE など一般的なフレームワークを参考に設計
- (2) 構成管理簿の作成・運用
- 本来的にはそもそもカスタマイズを行わない・やめるのが望ましいが、すでに稼働している環境に変更を加えるのは（当時の状況としては）困難と判断
- まずは悪循環を断ち切ることを優先したかったので、現実的な範囲で実現可能なことを優先することにした
- 地道に調査を行ってカスタマイズの全容を把握し台帳化した
- (3) 改善活動のための余力確保
- 対応窓口の設定
- 開発・インフラ部門ともに要望を受け付ける専任担当者を設置
- 受け取った要望の優先度を判定し適切なメンバーに割り当てる
- メンバーの割り込みタスクを減らし効率的・集中的に業務を遂行できるようにするため
- 業務の縮退、新規開発の停止
- 改善傾向が確認できるまでの間、重要度の低い業務を停止
- 改善活動にあてる時間を確保
公平のために記すと、これらの施策の全てを私一人で着想したり独力で行ったものではありません。
マネージャーという立場で中心的に携わりましたが、いずれの工程も必要に応じて上司や同僚の助言助力を得ながら行ったものです。
また、記載内容は私が主担当として携わった部分に限定しています。同時期にこの他にも私の裁量の範囲を越える改善活動も進められていました（品質管理部門の新設など）
それらの総合的な取り組みの結果、施策開始の翌年（業務縮退期間終了後）に当初の目標を達成することができました。