前置き
現在進行形の話なので書けないこともたくさんあるけど、自分があの時こんなことをやっていたと後日ふり返るために書き残しておく。
状況説明
チームメンバ
６名（うち１名は管理職、5名が実務担当）
業務内容
- とある業務システム（オンプレミス）の運用管理
- サーバー（物理・仮想）やネットワーク装置のログ管理・リソース監視
- セキュリティパッチの確認・適用
- 業務用のマスターデータの更新
- 他システムとの連携機能の保守開発
- その他、さまざまな依頼対応
技術要素
使っている技術は以下の通り。物理インフラからDB、webアプリケーションまで幅広く取り扱っている。
- IAサーバ、ストレージ装置、IPS、SRX
- VMware ESX, vCenter Server
- RHEL, CentOS (pacemaker, corosync, DRBD)
- Windows Server 2012 R2 (Active Directory, Remote Desktop Service)
- Hinemos, zabbix, kibana
- Oracle 11g/12c, Oracle APEX
- Python, HTML5, JavaScript, Excel VBA
- その他いろいろ
こうやって書き出してみると本当にいっぱいある。もうちょっと整理して減らしたい。。。
スクラム導入の目的
【建前】
属人化の問題
今までは各担当者が守備範囲を決めて個別に作業していたため、業務知識や技術スキルが属人化してしまっていた。 担当者以外は何がどうなっているのか分からない。休みが取りづらい、人事異動が難しい。
→チームで作業する習慣が浸透すれば、属人化が解消できるのでは。
業務の増加
セキュリティ強化や既存システムの機能追加・新規システムの開発など、顧客の要望が質・量ともに年々増加している。 技術者不足や予算の制限もあり増員することが難しい。
→もっと効率的に業務を遂行できる体制・仕組みをつくりたい。
【本音】
単に自分がスクラムをやってみたかった。
会社としても今年度の取り組み事項として目玉になるネタが欲しかった。
→両者の利害が一致！
やったこと（時系列）
情報収集
POStudy勉強会 vol.1 に参加（2017年5月）
https://postudy.doorkeeper.jp/events/60455
新規事業創出のための事業企画、仮説検討、プロダクトバックログの作成を学ぶワークショップ。内容が濃すぎて理解が追い付かなかった。。。
運用保守の世界とは全く違うけれど、顧客のニーズを汲み取って改善提案をしていく流れという点では非常に参考になった。
社内アジャイル研修の開催（2017年11月）
外部からプロのアジャイルコーチを招き、社員（事業部内の管理職・技術職・営業職）を対象にアジャイル・スクラムの研修を開催した。
また、その前に予習として勉強会を数回開催し、アジャイル・スクラムの用語、原理原則、考え方を知識として理解してもらう活動を行なった。
※新しいことを始めるにあたって、前もって上層部に理解を得ておくのは大事。地道に根気よくプッシュし続けた。
POStudy勉強会 vol.2 に参加（2018年2月）
https://postudy.doorkeeper.jp/events/69880
2017年5月のものとほぼ同じ内容。
前回は消化不良だったので再度受講したけど、やっぱり分かるようで理解しきれなかった。
頭で分かったつもりでも実際に手を動かすとあれれ・・・となる。やっぱり実践あるのみか。
開始手続き
稟議書の起案～決裁（2018年2月～4月）
アジャイル（スクラム）の実施を承認してもらうため、稟議書を起案。
- 年間計画
- インセプションデッキの作成 ○月～○月
- スプリントの実施 ○月～○月
- 結果報告 ○月
- 成果指標、目標値
実施体制図
- 責任者
- 管理者
- スクラムマスター、プロダクトオーナー、開発チーム
- 顧客との関係、業務フロー
こんな感じの資料を作成して、直属の上司～社長に至るまで片手に余る数のハンコを押してもらい、決裁をいただいた。
こういう手続きは本当に非アジャイル的だけど、会社のルールはルール。 伝統的日本企業ではこの辺りでうんざりして諦める人も多いと思うけど、自分のやりたいことをやるには折れない気持ちで一歩ずつ前へ。
顧客説明（2018年3月）
- 顧客と運用保守チームとのやりとり（インタフェース）は変更なし
- 今までよりも生産性が上がる＝同じ費用でより多くの仕事がこなせる
という説明をしたので、好意的に受け止めてもらえた。
スクラムの実践
チーム結成（2018年4月～）
それまでは客先常駐と自社内に分かれて作業していたのを、全員一ヵ所に集合させた。
インセプションデッキ作成（2018年4月～6月）
チームの全体像や進むべき方向を明確にしてメンバの意識を合わせるため、インセプションデッキを作成した。
1. 我われはなぜここにいるのか 2. エレベーターピッチを作る 3. パッケージデザインを作る 4. やらないことリストを作る 5. 「ご近所さん」を探せ 6. 解決案を描く 7. 夜も眠れなくなるような問題は何だろう 8. 期間を見極める 9. 何を諦めるのかをはっきりさせる 10. 何がどれだけ必要なのか
一気に全部作るのは無理だったので、毎週1時間ミーティングを行ない、１～2項目ずつ作成していった。 インセプションデッキを作り上げる過程でチームメンバが対話を積み重ねることにより、業務に対する認識が深まったこと、チームメンバ同士がお互いを理解し合えたことが非常に大きな収穫だった。
プロジェクト管理ツール（JIRA）構築（2018年5月）
無償のツールもいくつか試したけど、使い勝手が良さそうなのでJIRAを購入。 初心者こそ、多少お金をかけても良い道具を使うべき。
JIRAサーバー（オンプレミス版）買い切り価格 10ユーザー$10 https://ja.atlassian.com/software/jira/pricing?tab=self-hosted
Scrum.inc 研修受講（2018年6月）
東京で開催されたスクラム研修に、運用保守チームから３名が参加。
- スクラムマスター研修 1名
- プロダクトオーナー研修 2名
Scrum Inc.認定スクラムプロダクトオーナー（LSPO）研修を受けてきた話 https://qiita.com/takusamar/items/97c8b734a065312bb310
プロダクトオーナー研修で学んだことを一言でいうと「Courage! 」
プロダクトオーナーは顧客とチームを結ぶ存在。50%を顧客と共に過ごし、残り50%はチームと共に過ごす。
→スクラムを成功させるためにはコミュニケーションが非常に重要となる。
コミュニケーションを取ることを恐れない。スクラムを前進させる勇気が一番大事。
スプリントの実施（2018年5月～）
最初は２週間スプリントでやろうとしたが、
- 週単位での作業、週単位での報告が多い。
- 割り込みの依頼が頻繁にあり、2週間だと作業計画の変更がしづらい。
といった現場業務の特性を踏まえて、スプリント期間は1週間に決定。
また、週の始めと終わり（月、金）はいろいろと立て込むので、スプリントは「水曜～火曜」と決めた。
- スプリント計画ミーティング（水曜AM） 1時間
- デイリースクラム（毎朝） 5～10分
- スプリントレビュー（火曜PM） 1時間
- スプリントレトロスペクティブ（火曜PM） 1時間
だいたいこのような感じでミーティングを行なっている。
5月中旬から始めて、ここまで15回のスプリントを実施した感想。
- 各作業をスプリント内（１週間以内）で終わるボリュームに分割して、計画を立てられるようになってきた。
- 優先順位（重要度や納期）を意識して、順番の入れ替えや担当者の変更、作業負荷の平準化ができるようになってきた。
- 相対見積もり（ストーリーポイント）の判断が難しい。 結局、時間換算（1ポイント＝1.0～1.5H 程度）になっている。
- 運用保守という業務の特性上、どうしても緊急の割り込み作業は発生する。 割り込みの発生確率を予想して、キャパシティ最大まで詰め込まず余裕を持たせるようにした。
今後の予定
インセプションデッキの定期更新 １回作ってみたけど、考えが抜けている点や周囲の状況が変わった点もあるので、再度作り直す。
できれば、定期的に見直す機会を設けて、常に最新の状態を保つようにしたい。
引き続き、スプリントの実施
まだまだ上手く回っているとは言えない。 特に、現在開発中の新機能がそろそろ総合試験（ウォーターフォールで開発している他社システムとの連携試験）なので、そこをどう乗り越えるかが大きな山場。
スプリントレビューの改善
気がつくと、レビューではなく進捗報告になってしまっている。 顧客にも入ってもらって成果物のデモができるようなスプリントレビューにしたい。
