こんにちは。SRE の roki です。暑い日はまだあるものの、朝はすっかり秋を感じるようになり子どもたちが登校しやすくなってホッとしている今日このごろです。 この記事では、テックタッチという会社・サービスに触れつつ、SRE チームの働く環境や課題感を共有しながらチームの紹介をしていきます。興味を持っていただけたらぜひお声がけください。カジュアルに話し合う場を設けさせてもらっており、採用情報ページにて受け付けています。 テックタッチでは、社名と同じ「テックタッチ」という名前のサービスを運営しています。どのようなサービスかというと、対象とする Web システム上に、そのシステムを修正せずにノーコードで操作ガイドを設置することで、エンドユーザーに対象システムの活用を促すというサービスです。 プロダクトの概要については、サービスサイトをご覧ください。また、先日プレスリリースをうたせてもらったとおり MAU で 300 万人をこえる規模まで成長してきています。エンドユーザーからみるとシステムの一部として見える、そしていろいろなシステムでご利用いただいているため、高い可用性が求められます。 そんなテックタッチを開発・運用する社内の雰囲気を表す 1 つの側面として、最近社内で使われる「Co-Developers」という考え方がとても象徴的です。開発者だけでなく、営業やカスタマーサクセスなどのビジネスチーム、コーポレートチームのメンバーを含めた全員を指しており、全社一丸となってテックタッチの展開に取り組んでいる状況をよく表している言葉だと思っています。 テックタッチの SRE チームは、テックタッチにおけるソフトウェア開発・サービス運用における信頼性・生産性の向上と改善に努めています。ここでいう「ソフトウェア開発・サービス運用における信頼性・生産性」を分解すると、 の周辺を指していて、SRE チームはこれらを向上させるために必要なことに日々取り組んでいます。たとえば、 などを通して体現しています。また、DevEx に関連する具体的な話は DNX Ventures 主催の採用イベントでも紹介させてもらいました。 SRE といってしまうと、いわゆる「Google の SRE」を想起されると思います。しかし、テックタッチは Google のような巨大なインフラを抱えているわけではないので、「Google の SRE」とまったく同じではありません。テックタッチの SRE は、ソフトウェア開発・サービス運用における信頼性・生産性向上のために状況を見直したり、ソフトウェア開発を行ったりすることがメインです。SRE というと、まずインフラエンジニアを想像する方が少なくないと思います。クラウドインフラ要素は多分にありますが、上述の理由からサーバーサイドエンジニアとして Web アプリケーション含めたソフトウェア開発にあたっている方のほうが活躍の幅は広いと認識しています。 導入事例で紹介させてもらっている通り、テックタッチは社内向け、自社プロダクト向け、中央省庁や自治体のシステム向けの領域でご活用いただいています。テックタッチは、顧客システムのエンドユーザー数とテックタッチへのリクエストの数が比例する構造になっているので、エンドユーザー数は多くなります。 そしてエンドユーザーからすると対象システムの一部とも見えるため、「テックタッチが停止する = 顧客システムの一部が見えなくなる」ように見えます。導入事例（たとえば、「デジタル庁の「調達ポータル」にシステム活用支援サービス 「テックタッチ」を利用」 のナビゲーション）をご覧いただくと理解していただけるのではと思います。このような状態が数多くのシステムにわたり起こり得るため、エンドユーザーに見える機能が停止するようなメンテナンスを行うのは簡単ではありません。このような状況に耐えるアーキテクチャが必要で、そこに向かっていけるように改善を行っています。 大きなサイクルとして、毎年、全社で掲げるビジネス目標と現在のギャップと各種リソースの利用状況（リクエスト数や DB レコード数など）から、将来どれくらいまで利用リソースが拡大するかを予測します。それに基づき何をしなければならないか考えたり、負荷テストなどを行いボトルネックを探りにいきます。 小さなサイクルとして、日常業務における基本サイクルは、「先 3 週間のプランニング → デイリーミーティング → ふりかえり」の形をとっています。チケットの管理はカンバン方式で行っています。プランニングでは大まかにどの部分を見ていくかというレベルで方針を決め、デイリーで日々の進捗を確認しつつ状況を見ておかわりしてく方針でタスクに取り組みます。サービス運用をしているかたわら、一定の割り込みは許容しているところからこのような方針をとっています。ふりかえりでは KPT + Concern（Problem ではないけど気になること）方式で、共有・改善を図っています。3 人の小さなチームですがふりかえりスパンが長いこともあり、1 時間では収まらないくらいの話し合いになることはままあります。その他、検討・決めなければいけないことがあればチーム内外問わず適宜ミーティングを開催しています。SRE として他チームに働きかけることは多いです。 テックタッチの開発・運用を行っている組織はフルリモートで業務にあたっています。このため、基本的にコミュニケーションは、Slack, Tandem, Google Meet あたりをメインで使っています。文章化したほうが良かったり非同期で十分な場合は Slack を使いますが、ちょっとした相談なんだけどテキストではコストが高いことでは音声チャットも多用しています。オフィスでちょっと話しかける雰囲気をリモートでも失わないようにしたいという思いから来ています。 インフラとして AWS を全面的に利用しています。サービスとしては Amazon ECS Fargate, Amazon Aurora, Amazon CloudFront などを中心にマネージドサービスを積極的に採用しています。インフラの管理は AWS CDK や Amazon CloudFormation を用いています。主要アプリケーションはコンテナで管理されておりその管理もおなっています。監視基盤として Datadog を導入・運用しています。CI/CD 環境として AWS 関連以外では CircleCI, GitHub Actions を利用しています。必要に応じてアプリケーションに手を入れることもありプログラミング言語については既存スタックの影響で Go を使うことが多いです。また、周辺スタックをさわる際に TypeScript/JavaScript, Python など適宜使い分けています。 SRE チームの様子や取り組み、テックタッチの雰囲気などまとめさせてもらいました。テックタッチの雰囲気についてはこちらにバリュー・行動指針がまとまっています。気になる方や、中の人と話してみたいかもと思った方はぜひご一読ください。バリューの中にある「いつでもごきげん」については、セキュリティインシデント疑似体験調査ワークショップに参加すべき３つの理由 を見ていただくと、さらに雰囲気を理解していただけると思います（SRE も参加しています！）。
テックタッチという会社・サービス
テックタッチの SRE チーム
何をやっているの
インフラエンジニアというよりもソフトウェアエンジニア
課題感
SREチームの活動 - 大きなサイクル・小さなサイクル
コミュニケーション
技術スタック・ツール
終わりに
テックタッチにおけるSREの役割・課題感を紹介します
テックタッチのガイドを再生している様子
