［2019/09/30開催「IIJ Technical NIGHT vol.8」の講演資料です］ Barryの開発にあたっては、対応の迅速化はもちろん利用するエンジニアの利便性も重視し、仕様の検討段階からいくつかの工夫を行ってきました。 ここでは、開発プロセスや機能面でこだわったところ、さらに、利用者のモチベーションを維持するための面白い取り組みについて具体例を交えながら紹介します。 ▼講演者 基盤エンジニアリング本部 運用技術部 運用システム開発課 浅野 貴大

1. 浅野 貴大
基盤エンジニアリング本部 運用技術部
開発へのこだわり

2. 「楽しくやる」
開発者
も楽しく
利用者
も楽しく
開発へのこだわり

3. 「楽しくやる」には
業務にマッチした
使えるものを作る
…その上で
アラート・障害対応の
モチベーションを上げるための
工夫がある

4. 目次
1. プロジェクトの始まり
2. 使えるものを作る
3. モチベを上げる機能
まず、きちんと使える
システムにするために
• 実証実験とモックで機能の検証・洗い出し
• 開発者が楽しみながら開発し、提案した機能

5. 1. プロジェクトの始まり
初期の雰囲気、開発規模、
メンバーの初期スキルなど

6. Barry プロジェクトの始まり
何か自分たちの手がとどく範囲の技術で
業務改善できそうなことってないだろうか
なんか未経験の
技術を触りたい
なんとなく身近に
改善できそうな業務がある
気がする…
「スマホでエスカ対応」をテーマに
やりたいことをやって、それで改善できたらいいな
というユルいプロジェクトとしてスタート
「できたらいいな」というプロジェクトなので楽しくないと続かない
ふわ
ふわ
もや
もや

7. この規模の
アプリは
初めて
よゆう
いける
ウェブアプリ
1人
サーバサイド
1人
モバイル
初めて
モバイル
初めて
モバイルアプリ
1人→2人
サーバサイド以外はほぼ経験者がいない状態
…というメンバーで、初めは主務ではなく
「趣味と息抜きと業務改善」を兼ねた
スキマ時間のプロジェクト
メンバー

8. 2. 使えるものを作る
開発期間・開発のステップ。
使ってもらえる
システムにするために。
こだわり、その１

9. 実証実験
(参加者60人)
チーム内
デモ アルファ版
開発要素技術
の検証
• OS (iOS/Android)
• 開発環境 (Swift/Kotlin)
• 外部サービス
(AmazonSNS,FireBase)
• ルール通りの呼び出し機能のみ
• サーバ/API実装 (GraphQL)
• ウェブ/モバイルアプリ実装
(React/ReactNative)
開発のステップ
モバイルのアプリ開発や
呼び出しってどうやるの？
まだベータ版
なんです
ベータ版
開発
(試用者300人)

10. アルファ版: 実証実験の結果
• テキストで呼び出し内容が確認できる
• 機器名などの伝え間違いのリスクが減らせそう
• アラート通知システムとの連携・チャット機能
• アラートの取りまとめができると人を挟まず呼び出せる
好評だった点
次のバージョンで期待された機能
アラート・インシデント機能を追加することに
監視システム
呼び出し
アラート
メール
アラートの取りまとめも
やっていた

11. システムの見直しで何をやったか
ここからは… Adobe XD で
「アプリケーションのモック」を作って
UX設計・ヒアリング・要件の再整理
実装しながらUIを組んだせい
この時点での課題
• 仕様追加: アラート・インシデントという要素が増える
• アルファ版の反省: アプリ全体のUXが悪い(画面遷移とか)
アルファ版 → ベータ版に向けて…

12. アプリケーションのモック
「操作時の画面遷移を作り込める紙芝居」

13. モックを作るメリット
• 実装は置いといて夢を膨らませられる
• 「欲しいもの」が出来上がる
直接的なメリット
そして割と楽しい
• チーム内でアイディアを議論しやすい
• チーム外でのヒアリングもしやすい
「機能を順次追加した結果全体としての使い心地が悪くなった」
ということを避けられる = 全体を通して使いやすいUI
• 3部署 × 2回ずつ、見せて得られた意見を即モックに反映
• イメージが誤解なく伝わる、ヒアリングの質が向上
• 画面遷移・画面数が一覧できる

14. 「現場の声から生まれた」
実証実験・ヒアリング
モック作成
… その結果として Session 2 で紹介した
メインの機能を実装した
= 現場の声をすくい上げ、反映させながら開発した
アルファ版
開発
ベータ版
開発
呼び出し (順番・並列・通知のみ)
アラート対応 インシデント管理

15. 3. モチベを上げる機能
より使用感を上げる機能を
利用者も開発者も楽しく実装
メインの機能を
サポートした上で…
こだわり、その２

16. • 対応量が評価に結びつかない
• プレッシャー、スキルや経験不足、孤独感
• 原因・影響範囲の特定、迅速な状況判断・対応
• プライベートな時間・睡眠中の緊急呼び出し
休日・夜間を問わず対応
高度な対応スキル
精神的な負担
誰も評価してくれない
運用担当者のつらさ
組織運営・システムの両面でカバーすべき
システムから
サポートできそう

17. 紹介する機能
1. 統計情報・ビジュアライザ
2. タイムライン
3. リアクション
4. アバター
対応の役に立つ?
モチベ上がる?
実装して楽しい?
どれもオリジナル機能では
ありませんが…

18. 1. 統計機能・ビジュアライザ
アラート・対応時間などの統計情報を可視化

19. • とにかく実装が楽しい
• CSS/イベント処理楽しい
• 見た目が華やかで楽しい
• パフォーマンスチューニング
楽しい
• 事象の概要が一目でわかる
• 時間の範囲指定が簡単
• メンバーの対応量を把握できる
人知れず対応が埋もれる、
というのが一番モチベにならない…
両方
しあわせ
利用者
にとって
開発者
にとって
1. 統計機能・ビジュアライザ
どうモチベに繋がるか

20. 2. タイムライン
全体・グループ内のイベントを時系列で一覧する

21. • いろんな種類のデータを
時系列で同列に並べる実装は
やりごたえがある
• データ取得を効率化
• デザイン的にも面白い課題
• 直近の動きが見れて便利
• むしろ無いと不便
• メンバーの働きを見逃さない
利用者
にとって
開発者
にとって
• 朝起きて、寝てる間何かなかったか
• 通知が鳴っていたけど何かあったのか
2. タイムライン
両方
しあわせ
どうモチベに繋がるか

22. 3. リアクション
コメントに対して絵文字で反応を返せる

23. • 細かいUIに手をかける楽しさ
• 手の込んだUIを組めている感じ
• 労いやすい (省スペース)
• 誰かに(同僚・上長)が見てる
というモチベ・安心感
利用者
にとって
開発者
にとって
3. リアクション
両方
しあわせ
どうモチベに繋がるか

24. 4. アバター
グループ・ユーザ名の横に表示される画像を登録

25. たまたまメンバーが開発していた
簡易ファイルサーバが使えそうだった
https://github.com/yosisa/restfs
• メディアを扱うAPIを実装
できて楽しい
• 見た目が華やかで楽しい
• ユーザ・グループが判別しや
すい・視認速度があがる
• 呼び出し先のミスが減る
• 自己表現できて楽しい
• 「誰が」を強調する
利用者
にとって
開発者
にとって
4. アバター
どうモチベに繋がるか
両方
しあわせ

26. モチベを上げる機能: まとめ
アバター コメント
統計 ビジュアライザ
タイムライン
リアクション
可視化機能やいろんな粒度の
コミュニケーションが
対応のモチベを上げるかも
試行錯誤しながら実装
できて楽しい
使用感を向上する機能の他、
今まで見えずらかったもの、やりずらかったことを
サポートする機能を実装

27. まとめ
モチベ高い障害対応のために
アプリ作ってみた
IIJ Technical Night Vol. 8

28. • 初めに運用上の課題があり、その解決のために開発
• 実証実験やヒアリングを繰り返して開発した
• 業務に合わせて柔軟な呼び出しをサポートする
• 対応の寂しさ・不安さ・報われなさをやわらげる機能
• 統計機能・様々な粒度のコミュニケーションをサポート
アラート・障害対応のモチベーションを上げるシステム
1. Barryは弊社体制に則した呼び出しシステム
2. 対応の共有・見える化をサポートする

29. 障害の検知
現状 Barry導入後
監視システム 監視システム
1次対応者への通知 メール Barry
2次対応者への呼び出し 電話 Barry
対応時の情報共有 IRC/チャット
電話
Barry
インシデント管理
メール
Wiki
チケットシステム
Barry
Barryで運用はどう変わるか
これらに加えて統計・コミュニケーション機能を
ひとつのアプリ上でサポートする

30. メリット
デメリット
その他・感想
• モバイルアプリも作りやすい時代になりました
• 会社の業務体制に合わせたツールが作れる
• 開発メンバーのモチベーションが上がる
• 技術習得のきっかけになる
• 開発・運用・保守コスト
運用ツールを自社開発すること
開発チームからのメッセージとして
Adobe Xdとか
Flutterとか

31. チ
ラ
ッ チ
ラ
ッ

32. ちょこちょこ出てきた
この子

33. 「バリーくん」と言います
元々は定型的な対応を
簡便に入力するための
機能にスタンプを実装
でも社内での
盛り上がりを受けて
リクエストに応じて
追加していったら…

34. 200種類以上に
なりました
200種類以上に
なりました

35. エンジニアのためのスタンプ
これで対応もちょっとは楽しく…なる…?

36. LINEスタンプになりました
アラート対応用のスタンプを探している方はぜひ

37. IIJはちょっとした思いつきが
ピックアップされることもある
風通しのいい社風です(PR

38. NEW!
3. バリーくんLINEスタンプ発売中です
• アラート対応用のスタンプを取り揃えております
__EOS__
1. Barryは要望を吸い上げながら開発された
• 初めに運用上の課題があり、その解決のために開発
• 実証実験やヒアリングを繰り返して開発した
• モチベを上げる機能をひとつのアプリ上でサポート
2. モバイルアプリは作ろうと思えば作れる
• Flutterや外部サービスなど環境は揃っている
• 会社ごとの業務体制に合わせられるメリットがある

39. __EOS__

40. 開発期間
2017
2 4 5 8 9
2018 2019
実証実験
gRPC, Flutter, React
実装
技術検証・アルファ版開発
ベータ版のシステム開発
UX見直し機能追加と
アルファ版からの
反省も踏まえて…
呼び出せるだけじゃなくて
アラートも扱えると
業務効率を良くできそう

41. (尺の都合上詳しくは触れません、ぜひ懇親会でお話ししたいです)
ご大層なモックだけど
このアプリ本当に作れるの？
結果論: Flutter/Reactで実装できました
夢物語でも「こういう機能あったら素敵だよね」
は実装のネタとして
モックに残しておく価値がある

42. 1. 最初のモック
アラート・インシデントを
仕様に追加する前の話で…
「アラートを扱うって
具体的にどんな感じ？」
をチームメンバーに
伝えるものとして作成
これでもやりたいことは
十分伝わって
「じゃぁ作ろうか」となった。

43. 2. ブラッシュアップ
ワイヤーフレーム用の
素材を利用して
ブラッシュアップ
アプリらしいUIの
お作法に乗っ取った
見た目・挙動にする
完成版のイメージに近づけて
それをチーム内で共有するために

44. • 伝わりやすい
• なので意見も出やすい
• ショートカット
• 一括処理
• その他メニュー
3. ヒアリングをしながら機能を足し引き
利用者へのヒアリング
にもモックは活躍
得られた意見は全て
画面として残した
※ただし優先順位をメモとして残しながら。
3部署 × 2回ずつくらい, 必要な機能をモックとして取り込んでいく

45. • 使ってもらえる
• 技術的な挑戦ができる
• いろんな機能を試しながら
より便利に使えるように
アイデアを形に
• 業務にマッチしている
• きちんと使えるツールである
• 障害対応のモチベを上げる
その上で…
「楽しくやる」には
開発者
にとって楽しいこと
利用者
にとって楽しいこと
両方が
満足できると
しあわせ