#はじめに
自動車業界の1企業にて、SREチームのマネージャ兼アーキテクトとして活動しています。2018年の秋にメンバーと共にチームを立ち上げて約3年が経ちました。この3年間で複数のプロジェクトに参画し、様々な経験をしました。まだ発展途上にある組織ではありますが、この機会に一度振り返りたいと思います。
生々しいことはここに書けませんが、機会があれば別で共有しましょう。
#私たちのSREチームの社内における位置づけ
私たちの会社には複数の事業グループがあります。我々は一つの事業グループに属していますが、事業グループの枠を超えて社内外のプロダクト開発に参画するミッションを持っています。
#参画プロジェクト
この3年間で、市場にリリースしたプロダクト、試行稼働中のプロダクト、開発中のプロジェクトを含めて、複数のプロジェクトに参加しました。グループ企業やお客様が主管するプロジェクトにも参加しました。自動車業界はCASE,MaaSといった新しいプロダクト開発に取り組み始めている段なので、いずれも会社にとってチャレンジングなプロジェクトです。
#私たちのチーム
私たちのチームには、ITアーキテクト、プログラミングスペシャリスト、データサイエンティスト、ネットワークスペシャリスト、QAスペシャリストなど様々な経験やスキルを持ったメンバーがいます。
#私たちのSREチームのミッション
SREはGoogle社が最初に提唱したもので、Google社で実践しているシステム管理とサービス運用の方法論であり役割です。Engineering能力を身に着けた運用チームがこの役割につくことで、DevOpsを推進する一役を担います。一方で、SREという言葉の定義は各社各様であるのが実状と認識しています。
私たちのSREチームは、組織名称にもSREという言葉を入れていますが、その活動は運用に限定せず企画・開発の段から運用・保守の段まで参画します。私たちはプロダクトの非機能要件定義、クラウドインフラ構築、運用機能構築、システムテストなどにも焦点を当てます。こういった活動はプロダクトの後段に回されることもありますが、それは絶対に避けるべきであると考えています。こういった活動をリードする我々が企画の段から参画することによって早期のコスト見積とプロダクト品質の作りこみ、リスク評価の一役を担い、そのプロダクトでの継続した収益の確保に貢献します。
プロダクトでの継続した収益の確保に貢献するために、我々が常に心掛けていることが、Shift LeftとShift Rightです。Shift Leftとはプロジェクトに大きな影響を与える要件やリスクを早期に明確にし、対処することです。Shift Rightはその逆でプロジェクトに与える影響が小さいものに対して安易にコストをかけないようにすることです。
#私たちのSREチームのオペレーション
私たちが参画するプロジェクトの多くにおいて、スクラムチームが開発と運用の主体です。私たちのSREのメンバーは、そのチームのメンバーの一員としてプロジェクト体制の中に入ります。プロジェクトを適切に支援するために、私たちは機能部として外部からプロジェクトを支援するのではなく、プロジェクトの一員と参加して様々な制約を理解したうえでプロジェクトのメンバーと一緒に作業する必要があると考えています。
私たちにとって、プロジェクトは学びの場であり、他のメンバーに対するスキトラの場でもあります。なぜなら、現場でしか得られない知見やスキル、文書からは読み取れない知見やスキルがあるからです。文書化された経験や知見を自身の活動に活用する際に、自身の経験や経験から知見が役立つことも多々あります。それは私たちと一緒に活動してくれる他のメンバーにとっても同様です。共同作業を通じて私たちの経験、知見を共有させていただき、私たちがいなくても私たち以上の成果をだしてくれることが私たちの目指す姿と考えています。そうなったら、私たちは別の新しいことにチャレンジします。会社にとっても、私たちの現場での成功と失敗の繰り返しが競争力の源泉であると考えています。
ただし、個々人で経験できる数は限られているため、SRE間のつながりを意識的に持つようにしています。SREメンバーは、担当するプロジェクトを跨いで密にコミュニケーションを取り合います。モブプログラミングを実施することも多々あります。ツールとしてはSlackやzoomを活用し、常に連絡を取り合える環境に身を置いています。加えて、私たちが得た経験と知見を広く共有する活動として、情報共有サイトの運営、作成物の標準化、共通化といった活動に取り組んでいます。
#####経験、知見の共有
グループ会社内組織横断で経験・知見を共有する場としてDocBaseというソフトウェアを活用したWebサイトを運用しています。Webサイトを立ち上げた当初は私たちのチームから情報発信が主でしたが、今では様々な組織から発信いただいています。文書だけでは共有できない経験や知見を共有する、組織を跨いだ社員間でのコミュニケーションや協業を促進することを目的にするオンライン情報共有&勉強会も実施しています。
様々な組織、様々なプロジェクト、様々な立場で得た経験や知見を相互共有することよって、作業効率を高めたり、プロジェクトのリスクを早いタイミングで低減することに役立たせたいと考えています。
作成物の共通化
監視やインシデント管理といった運用機能など、1つのプロジェクトではROIが出ずらい機能や課題があります。このようなものは、共通化することによって効率を高めて、その分だけサービス機能開発に対してより多くの工数をかけることができるようにしたいと考えています。
観点や作業手順の標準化
高可用性設計パターンやセキュリティ設計パターンなど実績あるアーキテクチャ設計やソリューションを横展開することで、システム品質の底上げと作業効率化を図ろうとしています。ただし、これはボトムアップの活動です。横展開されたもの採否や活用方法は現場にゆだねるものと考えています。現場がその判断を適切に行えるように支えることもこの活動に含みます。可用性、性能・拡張性、セキュリティといった非機能要件や国・地域固有の環境制約や法規制などCASE,MaaS特有のものが数多くあります。
#私たちSREチームの立上げからの3年間を振り返る
2018年に組織を立ち上げてからの活動を時系列でふりかえると、以下3つのステップで整理できます。
Step1.プロジェクトでの共同作業を通じて、チームメンバー間の相互理解を深める
チームとして最初に参画したプロジェクトに対しては、当時のチームメンバーのうちほぼ全員で参加しました。同じプロジェクトでの共同活動を通じて、スキルや人間性を含めてメンバー間の相互理解を深めました。また、共通のプロジェクト参画経験を持つことで、プロジェクトの進め方に関する共通理解を持ちました。もちろん、私もメンバーの1人としてこのプロジェクトに参加しました。この時に得た相互理解と共通理解は、今のチーム活動に活かされています。
Step2.プロジェクト支援を通じて、私たちのチームに対する社内の認知度を高める
組織として活動を広げるために、少人数に分かれて複数プロジェクトに参画しました。これは今も継続しています。ただし、プロジェクトの企画段階から参画できることは稀で、プロジェクト途中で課題解決を支援する役割として参加するケースが多かったです。私の苗字に栗という漢字がはいっていることもあり、チームのメンバーはこのようなプロジェクト参画ケースを「栗拾い」と呼んでいます。このような形でプロジェクトに参加する際には、私たちのチームメンバーにとってもプレッシャーがかかることが常ですが、いくつかの観点で支援すべき、そして課題解決の一役を担えると判断できる際には積極的に参加してきました。プレッシャーがかかる中でも、メンバー間で支え合い、多少なりとも課題解決に貢献してこれたと自負しています。他の組織からも我々の貢献を認めていただき、企画の段から相談いただくケースが増えてきました。
Step3.更に活動の幅を広げるために、これまでの経験をプロダクトに昇華させる。仲間を増やす
いま、ここに着手し始めたところです。
私たちの人数は限られていますが、より多くのプロジェクトに貢献したい、サービスビジネスを会社の事業の柱にする一役を担いたい、そして日々新しいことにチャレンジしたいと考えています。これを実現するための施策の一つとして、我々がこれまで経験したこと、作成したことをプロダクトという形にして、必要としてくれるプロジェクトに提供する企画を進めています。加えて、組織の枠を超えて私たちのチームの活動に参加いただき、そこでの共同作業を通じて経験、知見、そして想いを共有することで、一緒に活動する仲間を増やす活動を進めています。この2つの活動については、また別の機会で皆様と共有できればと思います。
活動を継続するために、私が実施してきたこと
この3年を通じて、私が意識して、あるいはなんとなく実施してきたいことを、以下のように振り返りました。
・業務に必要な研修は積極的に受講してもらいました。スキルアップにはOJTが効果的なことは周知のとおりですが、ベースの知識があるほうが効率が良いことも周知のとおりです。特にIT企業以外の職場に身を置くエンジニアは、得られる教育機会が少ないことが問題のひとつだと考えています。
・私が持ちえた情報は極力オープンにしてきました。一般的に、情報を抱え込んでしまう人も少なくありませんが、機密性の制約があるもの以外は雑談の場などで気軽に伝えることで、情報共有しやすい雰囲気を作ることに努めてきました。
・メンバーからの提案や企画は、積極的に応援するよう心掛けてきました。業務をこなしているなかで、さらに提案、企画をしてくれるほどの想いを持ってくれることはとてもうれしいことですし、会社にとってプラスになることはあってもマイナスになることはありません。さらにありがたいことに、メンバーが提案、企画してくれた活動の多くは、今でも会社にとってもチームにとっても、そして本人にとっても有益なものになっていると思います。
・メンバーが主体的に実施してくれている活動に対しては、メンバーに任せるようにしてきました。メンバーが熱い想いで活動しているところに外から冷や水を指すことはしたくないし、外から口を出してもチームにとって良いことはあまりないと思っています。ただし、SlackやDocbaseなどでチームが公開している情報をのぞいたり、1on1や雑談の場で活動内容を聞いたりすることで、活動内容や状況を理解し、必要があればいつでもサポートできるようには心掛けています。
・メンバーのスキルアップのために私たちのチームは積極的にプロジェクトに参加してきました。Cloudを活用した本番サービス開発プロジェクトに対して私たちのチームが一番多くの経験をしている自認しています。その際、可能な限り複数名で参加するようにしました。プロジェクトに参加した際にはプレッシャーがかかるものですが、その際に悩みや問題を一人で抱え込ませない、無理をさせないようにするためには、物理的に1人にさせないことが有効です。特にプレッシャーが大きいプロジェクトは、私もメンバーとして参画するようにしています。
・プロジェクトや活動において、成功することだけにこだわらず、多少失敗してもよいなという想いで見てきました。そのためのリスク管理が私の役割の一つだと考えています。
・メンバーが1つのプロジェクト、一つの業務だけに追われないように、メンバーのワークロードバランスに配慮してきました。私たちエンジニアを取り巻く環境は常に変化するため、その変化に対応するための余力が必要です。この機会を損なわないように注意してきたつもりです。
#今後に向けて
この3年間は、個人的には総じて楽しんでこれたと考えています。今は、多くを書きません。ただ、今後も周りのみなさんが楽しんで活動できる機会をできるだけ作っていきたいと思っています。
あと、いつか、空飛ぶ車の管制センターを作りたいな。