齋藤 龍

フィールドエンジニアリングチーム

事故と遅延なく、顧客に迷惑をかけずに作業を終えられること

**フィールドエンジニアリング概要** 自社製品はERPパッケージ製品であり、自社で開発したシステムはお客様にサーバーを用意いただいて、その上で運用します。 弊社におけるフィールドエンジニアには、 弊社製品のアップデートやデータベース移行などを行うために、お客様先に訪問して製品の適用を行うという役割がありました。 **状況** フィールドエンジニアリングの部署はもともと外注していたのですが、それを社内人員で賄おうという理由で異動になりました。 配属され１ヶ月目のほとんど業務を理解していない＋資料も全くない中、チームリーダーとして5名ほどのチームを割り当てられました。 このチームには全チームの中で最も経験が浅く、問題行動の多いメンバーが集められていました。 私に課された責任は、「チーム全体が事故遅延なく作業を完了する」というものでした。 **業務内容** 与えられた業務はメンバーが客先作業にいくのを会社に残ってサポートするだけでしたが、マンパワーに頼ってなんとか部署を回している状況でした。 それを打開するために独自で改善タスクを作って取り組んでいました。 - <span style="color: red; ">チームメンバーに対しての定期的な教育イベント実施</span> 対応したトラブルを自分で止めずにメンバーに共有したり、作業内容やサーバー構成の目的を具体化して理解してもらうための講座など 最大40名ほどの前で講座をおこなった経験もあります。 部長しか知らないツールの構造部分についてなどをまず私がヒアリングしそこから広範囲に展開していくなど、ハブのような役割も果たしました。 - <span style="color: red; ">作業前に対象環境の読み合わせや事前準備確認</span> 人事領域では国内最大規模の業務システムであったため、顧客の数や環境差異、特殊作業手順などが非常に多く、事前の情報共有会やトラブル想定会を独自に開催しました。 - <span style="color: red; ">チームメンバーの作業経験や事故率、遅延率といった成果部分の記録と能力の可視化</span> 部長や課長を含めた部署内のほとんどの人にヒアリングをしてスキルマップを作成し、そこで作業遅延や事故率を記録していままで感覚値で計測されていたパフォーマンスを明確化し、これにより個別面談で改善協力やモチベートを行いました。 - <span style="color: red; ">自分チームメンバー以外とのコミュニケーションや独自で行っていた開発への補助</span> 部署内には作業内容に不満を持つ者もおおく、チーム外からも貪欲に意見を聞き入れ、時にはその解決に取り組んでもらうためのサポートとして問題のヒアリングやカタログレビュー、実装・テストケースレビューなども行っていました。 よいものができれば積極的に上司に掛け合って、現場での使用許可をとっていき、作業の効率化に努めました。 - <span style="color: red; ">自分でメンバーを選定しての開発チームの立ち上げ</span> 作業工数の根本解決のため、開発での問題解決を部長に提案し、メンバー選定から立ち上げ、チケット選定やレビュー、マネジメントを並行して行いました。 自分を入れて３名の開発チームでしたが、ここで立ち上げたプロジェクトは後に社員賞を獲得しました。（私は異動のため表彰対象外） - <span style="color: red; ">作業手順書の環境依存部分などを自動的に埋められ、コマンドを生成する適用手順書ツールの作成</span> 異動直後から資料が陳腐化しており、しかも手順書内容を個人個人が環境依存部分を書き換えて作業を行うという非効率的なものであったため、テンプレート化してコマンドを自動生成するようにしました。 - <span style="color: red; ">相互扶助の環境を整える</span> メンバー同士の軋轢などがひどい状況だったため、工数をやりくりして個人面談やペア作業を実践し、協力体制を整えました。 これにより、私が経由せずに問題を解決できるトラブル対応フローなども出来上がり、よいチームになりました。 - <span style="color: red; ">チームメンバー全員が残業しないで済むようなコントロール</span> 全員の一日の作業から時間ごとの進捗ラインを想定し、主体的に全員と電話でやり取りしながら適宜サポートを行い、問題が起きる前に事前につぶすことを徹底しました。 これにより、遅延が起きる場合なども数時間前には予想できるようになり、コンサルとの関係性も良好に保てました。 - <span style="color: red; ">自分の得た知識を後進に伝えるための総合マニュアル作成</span> とにかく口伝ばかりだったので、異動直後から次の異動まですべての知識を資料化し続け、共有し続けました。 これにより、作業やトラブルだけでなく、正体不明のツールや作業内容についてもいつのまにか解説資料ができており、一切資料が整理されていない状況からとりあえず参照できるデータベースが出来上がりました。 - <span style="color: red; ">メンバーへの作業アサインや企業担当のコンサルとの調整</span> - <span style="color: red; ">メンバーが作業以外に事にも取り組めるように、全体的な効率化による工数確保</span> 作業を繰り返すだけではメンバーのキャリアアップにつながらないので、＋αで成長できるようなタスクを持てるように、作業調整や工数改善によって週１日は無作業の日を作るようにしました。 **結果** チーム全体のパフォーマンスは安全性96%・未遅延率93%と高水準を実現しました。 また、私がSREに異動した後にはなりますが、立ち上げた開発チームで取り組んでいた自動セットアップツールは社員賞を獲得しました。 部下のロイヤリティをあげつつ成果に責任を持つことの大変さと、裁量を持つことで様々なブレイクスルーが可能であるという楽しさを学びました。

小数規模のツール開発チーム

客先での作業を効率化するためのツール開発

**概要** フィールドエンジニアのチームリーダーをしていた時に、平行して作業効率化のための開発チームを立ち上げました。 メンバーの選定やチケットの精査、カタログレビューなどは担当していましたが、コーディングは行っていません。 **状況** 客先にもっていってその場で使える必要があり、大半がwindows環境であったためbatでのツール開発を行いました。 チームメンバーは同期と先輩の２名で、部署内で個別にヒアリングをして開発能力の高いメンバーを選び他作業チームから引きぬいて組織を立ち上げました。 **課題と対応** - <span style="color: red; ">チームを立ち上げるための根回し</span> メンバーを引き抜く以上同列のチームリーダーと会話するのではなく部長課長クラスを説得しなければならず、そのための現状の課題把握や解決イメージの把握・共有が必要でした。 そのため、常にチーム外も含めたヒアリングやトラブルの把握をし続け、資料にまとめていきました。 途中でインシデント対応MTGが導入されたことを利用して、トラブルの根本解決として人間の作業量を減らすことの重要性を説いていきました。 - <span style="color: red; ">自分自身の工数不足</span> 開発チームの仕事をしつつ、フィールドエンジニアチームの仕事を並行しなければならず、開発チームのマネジメントをするために私がいなくても運用が回る体制をフィールドエンジニアチームで構築する必要がありました。 そのため、チーム内の友好度や実力を上げ、相互扶助のトラブル対応フローをつくり、Excelや簡単なbatで実装できるツールを駆使するなどして少しずつ私の工数を開けられるように取り組み続けました。 - <span style="color: red; ">レビュアーとしての技術理解不足</span> 先輩や同期に対して、技術力が低い私がレビューをするというのも苦労しました。 私は保守としてコードを読むことはあってもほとんど機能開発などやってこなかった人間なので、ほとんどコードレビューはできませんでした。 そこでできないことは割り切って、パラメータ管理や運用面など自分のほうが理解している分野のみを対応し、コードレビュー自体はチーム内で回してもらうようにしました。