taso0505

［概要］商用Webシステム定型業務担当チームマネジメントと安定運用 ［規模］22名（自社4名、協力会社18名、530人月） ［役職］チームリーダー ［担当］チーム方針設定とモニタリング、安定運用に向けた業務改善推進 ［環境］自社 ［課題］ 　1.20名超えの体制だが、チームの業務量と必要工数がブラックボックスで、 　　適正化できていない。 　2.業務で必要なドキュメントが存在せず、業務の内容や品質・納期が 　　属人化している。 　3.上記状況であるにもかかわらず、業務改善が全くされず、 　　凝り固まった業務になっている。 ［成果］ 　1.confluenceとJIRAを用いて、インフラチームで対応している業務と作業量を 　　定量的に可視化し、月ごとの業務量と必要工数のシミュレーションを可能にした。 　　その結果、20名超えの体制から-6名で同じ量の業務を行うことが出来た。 　　（年間6,000万円のコスト削減） 　2.有識者で業務内容の棚卸しとウォークスルーを行い、confluenceに業務フローと 　　手順を整備していくことで、属人的でない業務を実現する事に成功した。 　　また、slackをコミュニケーションツールとして導入する事で、オープンな議論を 　　可能にし、困っている事やトラブルをプロアクティブに吸い上げる事で、 　　より高い生産性を実現する事ができた。 　　また、納期短縮/コスト短縮をするためにansibleを導入し、事業側ともKPIを 　　再定義を合意して、定常作業の自動化を実現した。 　　自分で手を動かしてエンジニア作業を実施し、そこからの気づきをメンバーへフィードバック 　　することで納得感のある業務改善のサイクルを回せるように注力した。 　3.私を中心に現状の業務を「課題→原因→解決策→効果」というフレームワークで 　　棚卸しを行い、まずは課題・改善ポイントを可視化した。 　　進めて行く経緯をconfluenceに残す事で、業務改善のベストプラクティスとして 　　他のメンバが何か改善のアプローチをしようとする時のサンプルとした。 　　PDCAサイクルを回すための業務改善プロジェクトを立ち上げ、定期的に 　　改善ポイントの抽出と対応計画の立案を行うスキームを装着した。 ［工夫した点］ 　・業務改善を経験したことない若手メンバがたくさんおり、「なぜ変える必要があるか？」 　　「変えた先に何をしたいか？」を摺合せする事で、中長期的にKPIをハイレベルで達成して 　　いきたいというマインドを醸造した。 　・ITILの資格を取得していた為、メンバに対して勉強会を開催し、サービスマネジメントの 　　あり方や考え方、スキル・ナレッジをトランスファーした。 　・実務におけるヒヤリハットを共有することで、メンバの意識向上を促し、伴走することで 　　知識の習得を効率化した。

［概要］SUMMOに対するSRE活動 ［規模］25名（自社5名、協力会社20名、40人月） ［役職］担当リーダー ［担当］SRE活動の下地作りとチーム運営PMO ［環境］自社 ［課題］ 　1.インフラの業務内容が不透明（業務一覧、役割分担、責任分界点、など）で 　　何かインシデントが起きたときのアクションが遅くなってしまう。 　2.インフラの業務状況が不透明（インシデント件数、申請対応数、など）で 　　KPIもなく、今が良いのか悪いのかすら把握できない。 　3.業務フローや手順書が整備されておらず、運用がブラックボックス。 　　特定メンバが不在の場合、業務が滞ることもあった。 ［成果］ 　1.confluenceを用いて、インフラチームで対応している業務を整理し、 　　カテゴライズした業務一覧を作成。 　　関係各所と認識合わせを行い、インフラの役割分担と責任分界点を合意した。 　2.業務をモニタリングする基盤をJIRAで構築し、JIRAを活用した業務フローを整備し、 　　インシデント件数や依頼業務の対応状況、メンバのスキル偏りを可視化し、 　　リアルタイムに確認できるようになった。 　　システムのモニタリング情報はslackヘ連携する事で、システマチックに解決した。 　3.有識者から業務をヒアリングし、confluenceを用いて業務フローを可視化。 　　他のメンバでも対応可能にした。 　　また、各自で作っていたツールをGithubに集約し、共有のサーバで稼働させることに成功した。 　　共有のサーバはRHEL＋Dokerで構築し、コンテナ上で稼働させた。 　　また、業務はansibleのplaybookに落とし込み、インフラメンバなら誰でも作業できる状態を 　　作り込んだ。 ［工夫した点］ 　・今までの運用で苦労していないメンバもおり、やり方を変えることに対してハレーションが 　　起きないように「なぜこの活動をするか？」「この活動をすることで何が得られるか？」を 　　メンバに腹落ちするまで説明し、協業して進めるようにした。 　・インフラといっても範囲が広いので、通常運用を担当するメンバと課題解決を担当するメンバに 　　役割を分けて、チーム内で責任分界点を明確にすることで、当事者意識を醸造し、 　　生産性を上げるようにした。 　・自分のPCにvagrant+virtualboxで環境を作り、その中でansibleやDockerを稼働させることで 　　実際にサーバを構築する前に上位層へデモを行なった。

［概要］インターネット広告配信システムのDevOps ［規模］3名（自社3名） ［役職］リーダー ［担当］DevOpsの推進と既存業務のリファクタリング ［環境］自社 ［課題］ 　1.過去のインシデントに対するアプローチや対策が人の頭の中に存在していることで、 　　ナレッジが継承されて行かず、運用の再現性がない。 　2.ansibleで構築/運用をしているが、ドキュメントがなく、他のメンバが利用できない状況。 　3.上場企業の内部/外部監査に耐えうるセキュリティになっていない。 ［成果］ 　1.過去の作業をRedmine、slack、JIRAから抽出し、インシデント対応の手順を 　　リバースエンジニアリングした。（自動化できるものはplaybook化した） 　　ドキュメントはエンジニアが読みやすいようにMarkdownで作成。 　　今後の作業をJIRAで管理し、JIRAで作業管理、インシデント管理、課題管理など 　　プロジェクトを回すうえで必要な統合管理基盤をITIL、スクラムマスターの知見を 　　活用しつつ、構築した。 　　また、対応したタスクや手順はナレッジDBとして、Githubに蓄積し、チームメンバ以外からも 　　参照可能にすることで、自チーム以外でも利活用できるようにした。 　　（フィードバックをもらうことで、より良いものへブラッシュアップしていく） 　2.ansibleはコマンドだけ知っていれば実行できてしまうリスクもあるので、実行前に参照すべき 　　ドキュメントを新たに制定した。 　　また、手作業で行なっているものを随時ansibleへ移行することで生産性の向上と再現性の担保を 　　可能にした。 　　ansibleへ移行する際に検証環境をデータセンターのラッキングから全ての設定を自前で行い、 　　作成ー廃棄ー再構築を実施する中でナレッジの蓄積も合わせて行った。 　　最終的にはJenkinsから操作を行うようにすることで、オペミスの確率を低減し、 　　リスク対策を実現する予定である。 　3.まずは「当社のセキュリティ要件」の整備から着手、ベストプラクティスを参考に 　　「何を脅威」とし、「どのように防ぐか？」を中心に検討を行なった。 　　外部よりも内部への対応が薄いと分析し、アクセスログの収集や確認の業務フローを立案。 　　特権に特化したセキュリティ対策を設計することで監査での指摘事項を減少させることに成功した。 ［工夫した点］ 　・参画直後からサイロ化している状況であったので、現状調査と分析に時間をかけ、 　　「今がどういう状況なのか？」をQDCを軸に明らかにしていった。 　　今を見れば問題はないが、再現性のない運用をしていることが一番のリスクと捉えて、 　　再現性の高い運用を実現すべく、実績のある手順を抽出して可視化することで、 　　今後起こりうるインシデントへの対策をプロアクティブに講じた。 　・「業務の可視化」が出来ておらず、属人的になっている業務を1つ1つひも解き、 　　生産性を可視化するところから着手する事で、改善の効果も見える化した。 　・セキュリティはあまり考慮されていない状況であったので、ITILやIPAが提示する内容を 　　ベースに守るべきセキュリティ要件を明確化し、優先順位をつけて実装を行なっている。