---
title: Chatwork Android版アプリ 障害対応の舞台裏
tags: 
author: [okuzawats](https://convert.docswell.com/user/okuzawats)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/G75R45RQE4.jpg?width=480
description: Chatwork Android版アプリ 障害対応の舞台裏 by okuzawats
published: March 11, 25
canonical: https://convert.docswell.com/s/okuzawats/K22EM6-incident-management
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/G75R45RQE4.jpg)

「Chatwork」Android版アプリ
障害対応の舞台裏
奥澤 俊樹 @ 挑戦の軌跡をたどるAndroid開発の舞台裏
2025年3月11日


# Page. 2

![Page Image](https://bcdn.docswell.com/page/9J2DVNDWJR.jpg)

自己紹介
奥澤 俊樹（@okuzawats）
株式会社kubell所属
コミュニケーションプラットフォームディビジョン プロダ
クト開発ユニット Androidアプリ開発グループ
ビジネスチャット「Chatwork」 Android版アプリを作っ
ています。
今年は前厄だと思って油断してたら本厄でした。


# Page. 3

![Page Image](https://bcdn.docswell.com/page/DEY23P29EM.jpg)

事業概要
● 国内最大級のビジネスチャット「Chatwork」を展開。
業界のパイオニアであり国内利用者数No.1*1、導入社数は62.0万社*2を突破
● 圧倒的な顧客基盤とプラットフォームを背景に、DXされた業務プロセスそのものを提供する
クラウドサービス、BPaaSを展開
ビジネスチャット「Chatwork」
BPaaS (Business Process as a Service)
お客様
*1 Nielsen NetView 及びNielsen Mobile NetView Customized Report 2024年4月度調べ月次利用者（MAU:Monthly Active User）調査。
調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む41サービスを株式会社kubellにて選定。
*2 2024年12月末時点。
オペレーター


# Page. 4

![Page Image](https://bcdn.docswell.com/page/VJN8V58D78.jpg)

「Chatwork」Android版アプリ
障害対応の舞台裏


# Page. 5

![Page Image](https://bcdn.docswell.com/page/YE9K6YK8E3.jpg)

障害対応とは
障害 = システムにおいてユーザーの業務を妨げるもの※1
「Chatwork」で言えば、チャット等の機能を用いたコミュニケーション、またはそれを通
じた業務の遂行を妨げるもの※2
自分たちに直接の責任がないことが原因であったとしても、それは障害である。
例えば外部サービスの不調。
※1 本スライドにおける説明のための定義。「Chatwork」及び株式会社kubellの公式見解ではありません。
※2 本スライドにおける説明のための解釈。「Chatwork」及び株式会社kubellの公式見解ではありません。


# Page. 6

![Page Image](https://bcdn.docswell.com/page/GE8RZ6RZJD.jpg)

障害対応とは
障害対応 ≠ 不具合を修正すること
障害対応 = 業務を遂行できる状態に復旧させること※1
不具合の修正は目的ではなく、手段の一つ。
「運用でカバーする」など、他の手段もあり得る。
ユーザーの業務が妨げられている状態から早期に復旧させることが重要。
※1 本スライドにおける説明のための定義。「Chatwork」及び株式会社kubellの公式見解ではありません。


# Page. 7

![Page Image](https://bcdn.docswell.com/page/LELKD9K1JR.jpg)

障害対応の流れの要点
障害検知
・ユーザー問い合わせ
・エラーログ
・Velocity Alert
・etc…
障害対応
・リリース停止
・関係者招集
・対応方針策定
・復旧作業実施
・ストア申請
・障害収束判定
ふりかえり
（ポストモーテム）
・場作り
・事実関係の整理
・根本原因の抽出
・改善アクションの策定
・改善アクションの実施
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/4JM2PZ25JW.jpg)

障害検知の流れ
ユーザー様か
らの問い合わ
せ
障害ではない
社内からの問
い合わせ
インシデント
障害
判定
エラーログ
Velocity
Alert
ユーザーの業務は遂行できるか？
ユーザーの業務にどの程度影響があるのか？
・機能の重要度
・機能の利用者数
・回避方法の有無
・etc…
障害


# Page. 9

![Page Image](https://bcdn.docswell.com/page/PJRM16MZE9.jpg)

障害対応時の役割分担
障害対応はエンジニア中心に実施する。エンジニアの役割を2つに分担する。
-
-
インシデントコマンダー
- 障害発生・収束の宣言、対応方針決定等、障害対応に関する意思決定
- 作業担当者への指示、作業の優先順位付け
- 関係者の招集・意見取りまとめ・連絡
- 情報整理
作業担当者
- 原因調査・影響範囲調査・対応方針策定
- 原因調査と影響範囲調査は2人以上で分担できることが望ましい
- 技術領域に詳しい者
- インシデントコマンダーへの報告
- リリース関連作業
木村 (2024), 「改訂新版 システム障害対応の教科書」を元に、現状の我々のグループの状況を整理。用語も木村による。


# Page. 10

![Page Image](https://bcdn.docswell.com/page/PEXVYMV17X.jpg)

障害対応の流れ
作業担当者
影響箇所・範囲の
調査
当該バージョンの
リリースを停止
原因調査
hotfix
（修復・切り戻し）
修復方針策定
ストア申請
指示・報告
障害発生
宣言
情報整理
対応方針決定
インシデント
コマンダー
関係者の招集
（チャット、ビデオ通話）
取りまとめ
エラーロ
グ
障害収束宣言
広報連携
ユーザー様への周知


# Page. 11

![Page Image](https://bcdn.docswell.com/page/3EKQ3GQMED.jpg)

障害対応
インシデントコマンダーが不在・役割が不明確だと何が起こるか？
-
障害検知から障害対応への移行に時間がかかってしまう。
- 障害発生の宣言の欠如
障害対応に入った後、方針や責任が曖昧なまま、復元時間が伸びていく。
- 指揮命令系統の混乱
- 情報伝達の不備
- 意思決定者と作業者の境界不在
障害対応は緊急性を伴うため、平時と比較して現場のマネジメントの重要性が高い。
インシデントコマンダーを立て、指揮命令系統を確立することにより、最短で復元する。


# Page. 12

![Page Image](https://bcdn.docswell.com/page/L73PGNP2E5.jpg)

※ サービス復元時間の推移
約40%の短縮
当初、障害発生時の役割分担が曖昧で、
サービス復元時間が伸びがちであった。
インシデントコマンダーとして振る舞うことで、
サービス復元時間を短縮することができた。
ただし、インシデントコマンダーを設置して関
係者を巻き込んだ対応が必要になるような障
害対応は、Androidアプリに関しては年に1回
か2回程度。
画像出典： https://creators-note.chatwork.com/entry/2024/12/18/175518


# Page. 13

![Page Image](https://bcdn.docswell.com/page/87DL1WL6EG.jpg)

ふりかえり（ポストモーテム）
障害対応をふりかえり、再発防止のための改善アクションを抽出する。
-
-
-
ポジティブな雰囲気となる場作り
- 非難なし（no blame）ルール
- 責任追及の場になってしまうと、問題を隠してしまう
時系列で事実関係を整理
- 障害対応中に考えたこと、判断に迷ったことの言語化も大切
根本原因の抽出
- なぜなぜ分析等の手法
改善アクションの策定
- KPT等の手法
- 精神論はダメ
- プロセス・ツールの改善
改善アクションの実施
- 二度と同じ障害を出さないという断固たる決意でやり切る


# Page. 14

![Page Image](https://bcdn.docswell.com/page/VJP2Q94ZJ8.jpg)

ふりかえり（ポストモーテム）
時系列で事実関係を整理
改善アクションの策定
根本原因の抽出


# Page. 15

![Page Image](https://bcdn.docswell.com/page/2EVD5MXMEQ.jpg)

現状の課題
-
インシデントコマンダーが属人化している。
-
障害はひとつひとつ異なるため、教育が難しい。
-
-
自分も誰かに教わったわけではない。
-
障害は計画できないため、意図して経験を積むことができない。
-
障害対応訓練を行うこともできるが、実施コストが高い。
モバイルアプリの場合、手作業による修復作業、アプリの申請・承認、ユーザーによる
アプリのアップデート、というようにユーザーが障害から回復するまでのタイムラグが
長い。
-
動的にフィーチャーをトグルすることで、このタイムラグを短縮することが可能な
ケースも多いと考えている。
-
疎結合アーキテクチャやインフラの整備等、前提条件が多く、途上。


# Page. 16

![Page Image](https://bcdn.docswell.com/page/57GY6GVX7L.jpg)

まとめ
-
障害は、システムにおいてユーザーの業務を妨げるものである。
-
障害対応は、ユーザーが業務を遂行できる状態に復旧することである。
-
障害対応は、以下の流れで行う。
-
-
障害検知
-
障害対応
-
ふりかえり（ポストモーテム）
障害発生時、インシデントコマンダーと作業担当者の役割を分担し、意思決定者・指揮
命令系統を明確にした上で、インシデントコマンダーが障害対応現場のマネジメントを
行うことで、サービス復元時間の短縮につながる。
-
インシデントコマンダーの育成は課題である。
-
動的にフィーチャーをトグルすることで、ユーザーが障害から回復するまでの時間を短
縮できる可能性がある。


# Page. 17

![Page Image](https://bcdn.docswell.com/page/4EQM4X65JP.jpg)

参考文献
-
-
木村誠明, (2024), 「改訂新版 システム障害対応の教科書」, 技術評論社
ふりかえりカタログ / Retrospective Catalog, retrieved from
https://speakerdeck.com/viva_tweet_x/retrospective-catalog-59bd3a29-314c45dd-911b-f8e5f1308333 （最終アクセス日：2025年3月11日）
Androidアプリ開発部の「four keys」大公開！赤裸々な1年を振り返る, retrieved
from https://creators-note.chatwork.com/entry/2024/12/18/175518 （最終アク
セス日：2025年3月11日）


# Page. 18

![Page Image](https://bcdn.docswell.com/page/KJ4VQ64VE1.jpg)

働くをもっと楽しく、創造的に
18


