トラストバンク本社オフィスへの最短入館ルート

どうも。パブリテック事業部のたけだです。

株式会社トラストバンクは 2024 年 1 月に本社を移転し、目黒オフィスをオープンしました。 www.trustbank.co.jp

JR東急目黒ビル 7 階全体がトラストバンクオフィスフロアになっています。 このブログでは、テックな話ゼロで超ウルトラスーパー方向音痴の私がトラストバンク本社への最短ルートでの行き方をご案内いたします。

オフィスの場所

〒141-0021 東京都品川区上大崎三丁目1番1号 JR東急目黒ビル 7階 www.trustbank.co.jp

JR東急目黒ビル

駅からトラストバンクオフィスまでの経路

私たちのオフィスであるJR東急目黒ビルは、目黒駅直結のビルになってるので、改札からビルまで徒歩1分程度で着きます。

  • JR目黒駅から徒歩1分
  • メトロ目黒駅から徒歩1分

maps.google.com

電車を降りてから改札まで

JRでお越しの場合、内回り・外回りどちらの電車に乗る場合も10号車に乗るのが最短になります。

10号車から電車を降りると、東急改札連絡口に下りるエスカレーターが目の前にありますのでここから下ります。

東急改札連絡口の改札を出ます。

地下鉄でお越しの場合、以下が最短になります。

  • 8両編成なら 2号車 3番ドア
  • 6両編成なら 1号車 3番ドア

電車を降りると、改札に上がるエスカレーターが目の前にありますのでここから上がります。

改札を出ます。

改札からビルまで

改札を出たら奥に階段が見えますので、階段の方向に向かって進みます。

エスカレーターを上がります。

地上に出ますので、すぐ右にあるアトレ2の正面玄関から入ります。

アトレに入ったらすぐ目の前のエスカレーターを上がり2階に上がります。

オフィスビル入館からオフィスまで

2階に上がったら、右側に見える自動ドアからオフィスエリアに入ります。

※平日は開いてますが、土日祝日だとこの自動ドアが閉まっておりますので、土日祝日にイベントや勉強会などで来られる方はこの付近に運営スタッフがいるか、社員を呼び出していただく必要があります。

エレベーターホールはこちら。エレベーターで7階まで上がってください。

オフィスエントランス

7階に上がりましたら目の前がエントランスになります。

受付方法

アポイントのある方は社員呼び出しのためのQRコードが届いているかと思いますのでここの端末からQRコードをかざしてチェックインをお願いいたします。

エントランスには白地図があり、自治体職員さんがいらっしゃった際には一言記入してもらっています。これからドンドン埋まっていくんだろうな~~
楽しみ!

プロダクトを共創するProductOperationの取り組み

この記事は、トラストバンク Advent Calendar 2023 25日目の記事となります。

こんにちは。11月にトラストバンクにJOINした @feat2kjです。

Advent Calendar 2023. 最終日は現在取り組みを進めているプロダクト開発を効率的に行うためのProductOperationについて書いていこうと思います。

ProductOperationの概念については 【プロダクトマネジメント】 で知りました。当初は重要性を認識できていませんでしたが、チーム構成・運用プロセスを整理していると有効な概念だと思うようになり取り組むようにしました。 【Product-led Growth】 ではプロダクトOpsと定義されています。

ProductOperationとは

ProductOperationに関する記事はいろいろありますが、pendoでの定義がわかりやすかったので引用させていただきます。

プロダクトオペレーションを設立する主な理由は、プロダクトマネージャーからオペレーション(そして時間のかかる)タスクを取り除き、顧客を喜ばせるプロダクト作りに集中できるようにすることです。これにより、コミュニケーションと効率も向上します。これは、プロダクトオペレーションが、全社のチームにプロダクトの専門知識を提供するリソースとして機能するためです。 jp.pendo.io

ScrumにおけるScrumマスターの役割が少し似ているかもしれませんね。

ProductOperationの役割

オペレーションを担って効率化を行うという観点から担当する範囲はとても幅広くなります。 また企業によって定義されている役割・ニュアンスが微妙に異なるところもあるので、自分なりにまとめてみました。

  • 情報の可視化

    • プロダクト戦略・意思決定に必要なデータにアクセスできるような基盤整備
    • ビジネス、カスタマーサクセス、カスタマーサポート、PdM、エンジニアが必要なタイミングで情報を知る事ができる仕組構築
    • 戦略上必要なレポート管理
  • ケイデンスとコミュニケーション

    • プロダクト開発・運用におけるコミュニケーションパスの整備 (関係者の把握)
    • アウトカムに対する進捗の定期的な確認(意識づけ)
    • 会議体の整備
    • 各関係者から上がってくる運営に関するフィードバック管理 (※初めはここが重要)
  • プロダクト開発の効率化

    • プロダクトフローを分析し、効率的に動けるように計測・改善を行う
    • プロダクト開発・運営におけるトイルの撲滅
    • 効果的な運用ツール (issue管理) の提案・運用
    • 開発プロセスに関するコーチン
  • プロダクト運用・品質向上

    • 品質・運用など主語でかい問題の整理
    • プロダクト状態を定期的にチェックできる仕組み作り
    • ドキュメン管理の方針策定

ProductOperationの必要性

実はProductOperation(それに該当するもの) に似たことは自然と組織内で対応できている場合が多いです、そのため必要性をそこまで感じにくいかもしれません。自分もそうでした。その場合は以下の内容に心当たりがないかを振り返ってみて下さい。

  • 運営に関する課題が有志の活動によって解決されている
  • Mgrに課題がフィードバックされ、解決ができている
  • PdMが必要性を感じて対応している

課題として解決されていればわざわざ [運用チームを作る] という考えに至らないかもしれません。もう一歩深く考えてみましょう。

運用関係を引き取ってくれている人は自分のミッションに集中しきれているか

個人に頼ってしまっている運用を、[冗長化できていない] という問題として対応してしまうことが多いですが、リソースの話などに発展してしまいそうなので、ここではパフォーマンスにフォーカスしたいと思います。

有志による活動

有志の活動は組織としてとても貴重です。何か新しい事、改善したいと思った時に、次の成長に繋げる原動力になってくれる事が多いからです。ただモチベーションに甘えて運用・管理などを任せてしまい知らない間に個人に責務を負わせてしまう事も少なくないと思います。個人のモチベーションでの活動が業務化してしまいモチベーションの低下・本質的な自分の役割(エンジニアであれば開発に割く時間)に向き合えなくなるリスクは、組織としては致命的なパワーダウンです。

Mgrによる課題解決

このパターンは非常に多いかなと思います。部署横断でいろいろな判断ができるという役割上、適任のように見えます。課題点としては、このポジションの人は方針の策定・判断をする立場であり細かい作業を行う時間がないという事です。課題全体把握・優先度をつける事はできるかもしれませんが、分析やツールの検証などをしている時間はありません。その影響で全体判断が遅れたり、課題リストが積み上がり消化されない状態になる事があります。細かい作業より組織全体に関する判断などに時間を使ってもらった方が良いです。

PdMが対応している

PdM(ProductManager)の責務多い問題については、 The Product Management Triangle – Product Logic など、多くの書籍や記事により解像度が上がっているように思えます。それだけ重要な役割ということがわかります。

Figure 3. Examples of the roles that fill each region of white space.

ProductManagerの責務について整理した中にもオペレーションに対する事項はありますが、あくまでも基盤を使ってオペレーションを行うというように理解できます。PdMはデータ分析基盤・開発フローの整備など内面よりも、それを利用してプロダクトに向き合う作業・時間を増やすようにするべきです。

ProductOperationチームのValue

ProductOperation がいろいろルールを整備して、運用していく監視役のようなイメージを持ってしまうかもしれません。実際に運用を始めた際に、[このツール使いましょう][こういうふうにやりましょう]というコミュニケーションをプロダクトチームと取ることが増えてきます。そのため、Operationチームのスタンスをしっかり明示しておくことが大事です。

ルール通りに運用してもらう視点になり、アウトプット思考にならないこと!

アウトカム思考の運営

運用策定したものが上手く回っていない時にコーチングをかけにいくより、何故上手く行かないのか?を分析・ヒアリングしましょう。運営チームはサポートを通して、プロダクト価値をユーザーに届けることがMissionとなります。コーチングだけに固執すると適切な運用方法でないものを守ってもらう行動をとってしまい本来の目的から大きく外れてしまいます。また悪い運用から逃れるため、各チーム・部署で余計なハックが始まり全体でバラバラな運用が行われてしまい状態が悪化する可能性すらあります。運用状態がbadな時にアウトプット思考のルートでなく、アウトカム思考のルートに進んでいきましょう。運用は整備して終わりでなく、常に計測・改善を意識するマインドを持ちましょう。この辺はプロダクト開発と同じ思考になると思います。

ProductOperationが必要なタイミング

どのタイミングでOperationチームが必要かどうかは、組織の規模・状況により異なると思います。プロダクト開発・運用を行う上で運用チームが必要かという観点で判断する必要があります。自分も問題を整理した上で重要性に気づいたこともあるので導入基準は明確にはわかっていません。ただ関係者が本来のミッションに向き合えていない兆候が多くなったと思ったら検討を始めてみるのはアリだと思います。

ProductOperationのインストール

本記事を読んでいただいてProductOperationの必要性を感じてもらえたのであれば、ぜひ導入を検討してみてください。導入についてはこちらの記事がステップ毎に整理されているので、とても参考になります。 https://productzine.jp/article/detail/715?p=3

自分もまだまだ手探り状態ですが、導入時に意識していくことをまとめてみます。

チームとして定義する
  • 仮に1人だとしてもチームの枠組みで始めることで役割を明確にする
  • Mission・目標を他チームと同じように設定できる
  • 個人活動で開始すると 個人目標になりがち。チームにすると他のチームと同様の扱いとなり、組織的にサポートしやすい
  • 他のチームに対して相談窓口を明確にできる
    • ⚪︎⚪︎さんに相談するではなく、Operationチームに相談という状態を作る。担当が変更・チームが拡張された場合でも窓口の名称は変わらない
課題の整理から始める
  • 課題リストを整理する
    • 現状上がっている課題を整理する。フィードバックを受けるつつ優先度を決める
情報の可視化
  • 課題解決するためにわかっていない情報を可視化する
  • 例えば開発効率が悪いと言われても、どの箇所がどれくらい悪いのかは定性的になりがち
取り組みやすい課題から進める
  • 本質とはずれてしまいますが、運用改善効果を他チームに実感してもらい信頼を得るために結果を素早く出す
  • 実施する側も手探りな状態が出てくると思うので、なるべく取り組むやすい課題解決を行い振り返りながらOperation方法を改善していく
相談しやすい状態を作る
  • どこ宛に課題を起票すれば良いかを関係者に伝える

プロダクトを共創する組織へ

ProductOperationの導入により、各チームのケイパビリティを最大限生かし、全員でプロダクトを共創する(共に創っていく) 状態ができるようにサポートしていきたいと思います。 ※ユーザーフィードバックはプロダクトに多くの気づきを与えてくれるため、図の中にあえて表現しました。

We are hiring!!

今回の記事の取り組み以外でも、プロダクト開発・技術的課題解決などやりたいことがたくさんあります。 カジュアル面談歓迎です!少しでも興味を持っていただけたら是非ご連絡ください!

www.wantedly.com www.wantedly.com

新米プロダクトオーナーの6ヶ月間の振り返り

この記事はトラストバンク Advent Calendar 2023 の21日目の記事です。

パブリテック事業部プロダクトチームの近藤です。

12月といえば、プレミアリーグの過密日程ということで、大事な試合を欠場したり出場停止にならないように、気をつけなくてはいけないところです。
とはいえ全力を出さないのはもちろん違うということで、勇気を持って戦っていく必要があるし、またチーム力が問われる期間だなと思います。(マダーズ早く返ってきて…クティは節度を持って頼むよ…)

さてさて私は、自治体専用デジタル化総合プラットフォームである「LoGoフォーム」というサービスのプロダクトオーナーを担当しております。

昨日のたけださんの記事にもありましたが、 LoGoフォームのプロダクト開発では、2023年の6月からLeSS(大規模スクラム)に基づいたスクラム開発を開始しました。
プロダクトオーナーになって半年を過ぎまして、その振り返りをしていきます。
スクラム開発のイベントや、アジャイルラクティスなどには触れず、文化やマインドを中心にお話していきます。

スクラム開発開始までの経緯

スクラム開発を開始する以前は、品質面、スピード面など多岐に課題がある状態でした。
私自身は開発チームの中ではなく、PdM 兼 PM 兼 QA といった主に外から見る立場で、数ヶ月活動をしてきました。

そんな中、パブリテック事業部では2023年1月から Odd-e Japanさんのアジャイルコーチの方に参画いただきました。 スクラム開発をする前提ではなく、プロダクト開発全般のご支援という形で参画いただきました。
アジャイルコーチの方々は、開発業務などを観察することで課題を抽出し改善提案をいただき、 私自身は開発チームの中に入って、実際に開発業務を行うなどで現状の把握に努めていきました。

責務に対する考え方や、チーム間でのコミュニケーションに課題を感じた結果、 スクラム開発に切り替えることで、自分ごとで考える、自己管理したチームにしていきたいと考えました。

当初は混乱もありましたが、皆が良くしていきたい!という気持ちのもと、アジャイルコーチのアドバイスを素直に受け入れていった結果、現在は、開発も改善も責任感を持って一歩づつ進めはじめ、先週より今週と進化を続けていくチームになってきました。
(コーチはすごい。日々感謝。)
(このあたりは長くなるので、また別の機会でお話できれば)

気をつけていること

ここからは半年間プロダクトオーナーを勤めてきて、気をつけていることを3つあげます。

チームの能力を見極める

「これは開発者の責務だから〜」と言ってもすぐにできるものばかりではありません。 プロダクトオーナーと開発者間での責務は少しずつ変化させていっています。
開発者側に委譲したものも沢山ありますし、委譲しようと思ったけど取りやめたものもあります。 時にチャレンジングな委譲もしていきますが、スクラムチーム全体としてROIを高めるための見極めが大切だなと感じています。

とある日のオーバーオールレトロスペクティブでは、リリースの頻度やスピードを向上させるために、今のチームでできることと、他者に依存しているものを整理してチームで巻き取ったほうがいいもの、委譲したほうがいいものなどを整理したり…

とある日のオーバーオールレトロスペクティブ

種をまき続ける

プロダクトオーナーとしてというよりも、プロダクトチームのメンバーとしての色が強いですが、 学習のきっかけを作ることや、フィードバックを沢山実施することは大切にしています。
スクラムのこと、顧客目線で考えること、価値を考えることなどもありますし、設計や開発の進め方などエンジニアリングのこともありますが、 すぐに実践や結果に繋がらなくても、数カ月後にふと思い出して行動に繋げてくれることが多々ありました。
私自身もスクラムマスターに言われたことを1ヶ月後くらいに実践することが何度もあり、納得感を持って進めることができています。

最初は10個くらいだった完成の定義のDONEアイテムもどんどん増えていきました(技術品質に関するルール)

完成の定義

能力を上げる

スクラムを実践していると、日々課題がどんどん見つかっていきます。 レトロスペクティブでネクストアクションを考えて改善は進めていきますが、 何よりもシンプルにスキル不足に起因することも多々あり、能力を上げていく必要性を痛感します。

プロダクトオーナーはROIを最大化するため、
開発者が能力を発揮しやすいように、また能力を向上させられるように、戦略的にプロダクトバックログを作成していく必要があるなと感じています。 開発者には、勉強会の実施や、1on1やレトロスペクティブを通じて、個人として・プロダクトとしての課題に向き合ってもらえるように取り組んでいます。 (たぶん社会人になって1番インプットもアウトプットもしている気がする…

まとめ

アジャイルコーチの方から、スクラム開発をすると現状が可視化されるだけで、それだけで良くはならないと言われてきました。 実際にスクラム開発を実践すると、本当に沢山の課題が見つかり、道は長いなと思わされます。
課題に直面したとき、1つずつ向き合ってチームで解決していっていることが成果に繋がってると思っています。
開発者からは「楽しい」や「成長を実感する」といったポジティブなフィードバックをたくさんもらえて感謝です。
もちろん私自身も成長を実感しつつも、沢山の失敗をし、未熟なところ・甘いところが見つかり、もっとこうすれば良くできるのでは、もっと学んで実践しなくてはという日々です。

私は「守破離」という言葉が好きですが、基本は大切で、基本を理解しないと本質を見失うなと感じています。
スクラムガイドを読んでもわからないことをアジャイルコーチの方に埋めていただき実践し、実践後にスクラムガイドを見ると気づきがあるというサイクルが定期的に訪れています。
特に経験主義のスクラムの3本柱と5つの価値基準と自分(たち)の行動を照らし合わせて、ちゃんとできているかな、もっと良くできないかなと行動することが大切だと感じてます。
プロダクトオーナーという立場から偉そうな口を利くこともあるのですが、開発者と対等な関係として、チーム力・競争力をどんどん高めていきたいです。

TO DARE IS TO DO

エンジニア募集

トラストバンクでは、一緒に働く仲間を募集中です。
パブリテック事業部のプロダクトチームでは、開発者やスクラムマスター、サポートエンジニアなど様々な役割を募集しております。
エンジニアとして成長の機会は沢山ある職場です!
少しでも興味を持っていただけたら、お気軽にご連絡ください!

https://www.wantedly.com/companies/trustbank/projects

2023年のパブリテックを振り返る: スクラム、カイゼン、そしてAI

パブリテック事業部プロダクトチームの所属のたけだです!
この記事はトラストバンクAdobent Calender 2023の記事です。

何を話すか

トラストバンクにジョインと同時にパブリテック事業部立ち上げた2019年1月からいつの間にか5年経とうとしています。もう昨日の記憶すらなく(おい)一瞬で1年が終わろうとしてますが、、、今年1年を振り返り、パブリテックのプロダクトチームで挑戦したことや成果を書こうと思います。

パブリテック事業部と私

パブリテック事業部では、全国の地方自治体向けのSaaSを提供しており、私はこれらサービスのプロダクトチーム全体のマネジメントをしてます。

  • 自治体専用ビジネスチャット「Logoチャット
  • 行政手続きデジタル化総合プラットフォーム「Logoフォーム
  • スケジュールや掲示板サービス「LoGoチャットPlus」
  • 各業務シナリオに合わせて利用する「LoGoチャットボット」
  • LoGoチャットでChatGPTを利用できる「LoGoAIアシスタントbot版

「マネジメント」って玉虫色な所があるし、事業フェーズやプロダクト、チームによっても要求されることが異なるんですが、今日の私が思う私の役割は「事業成長に貢献するプロダクト組織をワークさせ、チームの隙間を埋める安定剤となる」だと思ってます。
(あ。LoGoAIアシスタントに関してはリソース不足の中で急ぎでリリースした新サービスということもあり、プロダクトオーナーも兼務してるのでこのサービスだけは開発の現場のこともしてます。)

挑戦したことや成果

その① スクラム開発導入

アジャイルソフトウェア開発宣言
※出典:アジャイルソフトウェア開発宣言

昨年までは、緩いウォーターフォール開発だったのですが、以下の考えから、アジャイル開発がパブリテックに向いているのでは?という考えを漠然と持ちました。

  • 新規事業であるため要件が途中で変わることもあり柔軟に変化に対応する必要がある
  • SaaSであり、計画的に進むことよりも品質や運用を優先したい
  • 「ユーザに近い所で仕事がしたい」「プロダクト全体を俯瞰して自分が何に取り組んでいるのかを把握したい」など、軸となる共通の価値観を持ちコミュニケーションを大事にするメンバーが多い

何人かに聞いてみたら興味ある!という反応のメンバーが多かったので、まずは正しいアジャイルスクラムフレームワークの知識とルールを理解しよう!ってことで、 Odd-e Japanさんのアジャイル入門研修をプロダクトチーム全員で受講しました。ワークショップ参加型の研修で、ディスカッションしながら理解を深めることができたと思います。
各プロダクトの開発チーム内が全員で2カ月以上話し合って「スクラム開発導入したい!」とチーム単位で全員一致で決断してくれたので「よしやろうぜ!」ってことで導入することにしました。 人数規模からスクラムを拡張したLarge-Scale Scrum (LeSS) フレームワークでスタートすることにしたということもあり、有識者の支援と客観的な評価が欲しかったので、研修して頂いたOdd-e japanさんのアジャイルコーチングを受け、悩みや課題を相談しながら皆で定義やルールづくりがスムーズにできたと思います。

成果はたくさんあって書ききれないですしそのうちスクラムチーム内のメンバーがテックブログ書いてくれる気もするので雑に書くと。こんな印象を持ってます。

  • 品質が上がった
  • メンバー1人1人の成長スピードや意欲が上がった
  • 自分の役割に対しての責任感が上がった
  • もっとプロダクトよくしようという意思をもってユーザに価値を届けるための主体的な行動が増えた
  • とにかく楽しそうに仕事をするようになった

まだまだ課題はたくさんありますし常に振り返って改善を繰り返している道半ばですが。これからが楽しみです。

その② DX Criteriaアセスメントシートによるチーム力とシステム力の可視化

今年は安定稼働と品質強化の面で変革と改善を優先的に行ったことから、一緒に事業を進める中で内部事情が見えにくいビジネスチームメンバーやプロダクトチームのステークホルダーにも伝わるような評価の指標として日本CTO協会さんが出されているDX CriteriaのDX Criteriaアセスメントシートを使って定期的に評価を行う運用を導入しました。 プロダクトチーム全体や社員ごとの年間目標にも達成基準として含めて設定し、毎月の1on1などで進捗確認や必要に応じて目標の軌道修正を行いました。 CICD導入やテストコード実装など、時間のかかる項目もある中で、それぞれのプロダクトごとに着実に評価が上がりました涙

例えば1つのプロダクトを代表で一部推移をチラ見せすると... ↓

2023年2月時点(スクラム導入前)
2023年6月時点:スクラム開発導入直後
2023年8月時点
2023年11月時点
※このシートの活用は、あくまで活発に改善と対話を促進して組織が持つ文化やケイパビリティに注目するものなので過度に数字を気にするものでも、できていないことで誰かを責めたりするものでもありません。

皆めちゃめちゃ頑張った!!!!プロダクトチームの1人1人皆、すごいぞマジで! もし興味ある方は一度自己評価チェックしてみてください。最初、"自信持ってTRUEとは言えないな、、" みたいな項目ばかりで改善しなきゃ!っていう気持ちになるはず。

その③ 新サービス「LoGoAIアシスタント」のリリース

7月にリリースしたLoGoAIアシスタント、(すでに記憶にはないですが記録を辿ると)構想から提供開始まで3カ月程度のフルスピードでリリースしました。
ここまでのスピードが出せたのはAWSのサーバレスやマネージド機能の活用と過去4つのプロダクトリリース経験、そして何よりもパブリテック全員の協力体制にあるかなと思っています。 もちろん開発や構築も頑張ったのですが、それ以上に、ドキュメント準備、規約類作成、商標登録、運用やサポート体制整備、リスク管理などなど「使われるサービスとして完成させる」って本当に大変です。。

なお、このプロダクト特有で記憶にあるのは。

  • GPT-4のWaitlist申請から登録までなかなか連絡が来ずドギマギ...
  • 生成AIから返ってくる返答が変動的なので何をもって正解と言えるのか判断難しくAI相手にずっとグチりながらテストする日々(笑)
  • 毎日のようにアップデートされる生成系AIの最新技術情報のキャッチアップ大変(これは今でも...)  

その④ 正社員の採用と内製化

これは...頑張ったけど成果としてはまだまだなんですが。。スカウト活動、カジュアル面談、採用面接などの採用活動に優先して時間をかけました。 今年になってパブリテックプロダクトチーム所属の社員が10名ジョインしてくれました。 最初2人から始めた事業部も今や社員49名。社員以外の皆も含めると90名近く、、感慨深い。

その⑤ プロダクトチームのスキルアップ

採用するだけでなく既存メンバーの技術スキルを上げる活動も取り組みました。(というか自分自身のスキルアップもしたいからということもあるのですが。)

AWSJさんによるAWS CDK,EKSハンズオン勉強会

CloudflareさんによるCloudflare Images勉強会

  • AWSJさんからのハンズオン勉強会
  • Cloudflareさんからのハンズオン勉強会
  • 社内週次のLT会やもくもく会継続開催
  • 社外のユーザーコミュニティ勉強会などへの参加
  • Odd-e Japanさんの認定スクラムプロダクトオーナー(CSPO)トレーニング →認定資格2名取得
  • Odd-e Japanさんの認定スクラムデベロッパー(CSD)トレーニング →認定資格3名取得

などなど。
CSD取得した若手社員は「人生が変わりました!」と目をキラキラして報告してくれて日々の業務に活かして成果上げてくれたり、まわりのメンバーもよい刺激を受けているように思います。

ってことで何がいいたいかっていうと。

パブリテック、これからも面白いことしていくよ!! 一緒に働きませんかーーー??!!!

www.trustbank.co.jp

さくらのクラウド シンプル監視はいいぞ

この記事は、トラストバンク Advent Calendar 2023の18日目です。

今年はIT健保メシとトスラブ箱根をコンプし、IT健保ジムにも通いはじめ、IT健保を満喫しているSREのbutadoraです。

私の観測範囲だとあまり採用事例を見かけない、さくらのクラウドのサービスである「シンプル監視」を推したいと思います。

死活監視に求めるもの

マネージドサービスで運用できる

  • 自前でスクリプトを作ったり、監視ソフトウェアを用意しない
  • 小規模な組織だとそのスクリプトやソフトウェアの管理コストの方が高くなるため

別プラットフォーム

  • 死活監視はあくまでアプリケーションが稼働するプラットフォーム自体を含めて稼働しているか確認できるような構成にする
  • 想定されるパターンとして、AWS上で稼働しているアプリケーションをAWS上で構築された監視サービスを利用していると、AWS全体で障害が起きたときに即座に気づくことができない可能性がある*1
  • とはいえ弊社のシステムは主にさくらのクラウドで動いているのでこのポリシーは満たせていないものの、NewRelicのSynthetics Monitoringを併用してクリアとしている現状

さくらのクラウド シンプル監視とは

  • その名のとおりさくらのクラウドで提供されているシンプルな監視サービスです

    manual.sakura.ad.jp

  • シナリオ監視のようなリッチなことはできないものの、1エンドポイントあたり月額22円とリーズナブルに利用できます

  • ただし、IPv6やAAAAレコードなFQDNはサポートしていません
  • 通知先はメールの他、SlackやDiscordといったWebhookでも通知ができます
  • 弊社では専らHTTPSなエンドポイントのFQDN監視してSlackで通知を受けています

おすすめポイント

AWS以外のプラットフォームから監視できる👍

  • 当たり前ですが、さくらのクラウドのサービスなので別プラットフォームからのマネージドな監視を実現できます
  • さくらのクラウドは東京と石狩にリージョンがあるため、日本の地理的にも分散していると信じたい

再試行時間と回数が設定できる👍

  • 他サービスだと単位時間ごとにチェックして、三振したらみたいな設定が多い記憶なので素早いダウン検知が可能です
  • 例えばチェック間隔60秒で設定、fail時に10秒おきに再試行して3回失敗したらダウン検知とするみたいなことができます

まとめ

死活監視をマネージドサービスで監視をすると、意外と高くついたり、 誤検知を減らすために再試行回数を増やして検知が遅れるなどあります。

弊社のサービス監視では以前から利用しているさくらのクラウドのシンプル監視ですが、 実際に利用していると痒いところに手が届く良いサービスだなと感じています。 現在AWSへの移行*2を計画していますが、シンプル監視は継続して利用していく方針です。

主観混じりの内容にはなりましたが、みなさんのイチ押しソリューションがあればぜひ教えてください!🙋

最後に

弊社ではSREを絶賛募集中です。

興味がある方はぜひ一度お話ししましょう!

www.wantedly.com

*1:とはいえAWS全体で障害が起きればSNSがザワザワするので気づけなくはないのかも

*2:https://tech.trustbank.co.jp/entry/2023/12/14/083008

New RelicのNerdGraphを用いて1分ごとにアクセス数を集計しCSV出力する

はじめに

この記事は、トラストバンク Advent Calendar 2023の15日目の記事となります!

こんにちは、4日目の記事も書かせていただいておりました、トラストバンクの@h0r4kです。

今回試したこと

今回の記事では、NewRelicのNerdGraphAPI)を用いて、1ヶ月以内の特定のエンドポイントへのアクセス数を1分間隔で集計し、CSVファイルに出力するプログラムを作成します。

今回取得目的は特にありませんが、NewRelicのNerdGraphを使用することでNRQLと組み合わせながら条件を指定しつつ、目的のデータをループ処理で取得することを目指します。

事前準備

まずは事前準備としてAPIキーを発行します。

NewRelic画面左下のアイコンをクリックし[API Keys]をクリックします。

画面遷移後、[Create a key]をクリックし、必要な項目を入力してAPIキーを発行します。※Accountを間違えないようご注意ください

APIキーが一覧に追加されたら[…]をクリック、[Copy key]をクリックしAPIキーをコピーします。

これにて準備は完了です。

NRQLを組み立ててみる

では、実際にプログラムを記述する前に、まずはデータ取得に必要なNRQLを組み立ててみましょう。

今回は下記のように絞り込み条件を含めながら、TIMESERIESを1分として設定し、1分ごとでアクセス数を集計していきます。

SELECT count(*) FROM Log WHERE 絞り込み条件 TIMESERIES 1 minute LIMIT MAX

なお、実際の取得時には、SINCEUNTILを指定しますが、こちらの期間はTIMESERIESを1分で設定するため、6時間間隔として設定いたします。(現在のNewRelicの仕様上TIMESERIESが1分の場合は6時間以上のデータ取得ができません)

コードに書き起こしてみる

では実際にコードに起こしてみましょう。

今回のコードでは、NewRelicの制約のもとに6時間毎でSINCE,UNTILを区切りながら、ループでデータを取得していきました。 (対象期間は$start_str = "2023-01-01"$end_str = "2023-01-02"として指定しています)

<?php

date_default_timezone_set('Asia/Tokyo');

$url = 'https://api.newrelic.com/graphql';
$api_key = APIキー;
$account_id = アカウントID;
$start_str = "2023-01-01";
$end_str = "2023-01-02";
$start = new DateTimeImmutable($start_str);
$end =  new DateTimeImmutable($end_str);
$day_span = ($end->getTimestamp() - $start->getTimestamp()) / 86400 + 1;

$fp = fopen("access_per_minutes_{$start_str}_{$end_str}.csv", 'a');
fputs($fp, 'タイムスタンプ,呼び出し回数' . PHP_EOL);

for ($day = 0; $day < $day_span; $day++) {
    for ($quarter = 0; $quarter < 4; $quarter++) {
        $hour1 = $day * 24 + $quarter * 6;
        $hour2 = $day * 24 + $quarter * 6 + 6;
        $since = $start->modify("+$hour1 hour")->format('Y-m-d H:i:sP');
        $until = $start->modify("+$hour2 hour")->format('Y-m-d H:i:sP');
        echo 'since: ' . $since . "\n";
        echo 'until: ' . $until . "\n\n";
        $nrql = "SELECT count(*) FROM Log WHERE 条件 TIMESERIES 1 minute SINCE '$since' UNTIL '$until' LIMIT MAX";

        $ch = curl_init();
        curl_setopt($ch, CURLOPT_URL, $url);
        curl_setopt($ch, CURLOPT_POST, 1);
        curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode(['query' => "{actor{account(id:$account_id){nrql(query:\"$nrql\"){results}}}}"]));
        curl_setopt($ch, CURLOPT_HTTPHEADER, [
            'Content-Type: application/json',
            'API-Key: ' . $api_key,
        ]);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
        $result = json_decode(curl_exec($ch), true);
        curl_close($ch);
        foreach($result['data']['actor']['account']['nrql']['results'] as $record) {
            $row = $record['beginTimeSeconds'] . ',' . $record['count'] . PHP_EOL;
            fputs($fp, $row);
        }
    }
}

fclose($fp);

実行します。

$ php newrelic_api.php
since: 2023-01-01 00:00:00+09:00
until: 2023-01-01 06:00:00+09:00
...
since: 2023-01-02 18:00:00+09:00
until: 2023-01-03 00:00:00+09:00

CSVにも無事結果が出力されました🙆🏻‍♂️ (期間も48時間分取得できました)

タイムスタンプ,呼び出し回数
1672498800,370
1672498860,173
...
1672671360,122
1672671420,114

成功です!

終わりに

今回の記事では、New RelicのNerdGraphを用いて1分ごとのアクセス数集計を行いました。

ただし今回の実装では、NRQLを利用する前提でNewRelicのNerdGraphを脳筋コールしただけなので、今後はもう少しNerdGraph本来の力を引き出せるような使用方法をご紹介できればなと思います。

最後までご覧いただきありがとうございました!

エンジニア募集

弊社では絶賛エンジニア募集中ですので、気になった方は是非ご連絡ください!

www.wantedly.com

SREにジョインして1年の振り返りとか

この記事は、トラストバンク Advent Calendar 2023の14日目の記事です。

今年からSREにジョインしているyoshiroooooです。

早いもので、入社エントリーから半年以上が経過し、入社1年が経過しようとしています。

tech.trustbank.co.jp

ということで、この1年を振り返って、やってきたこや来期に向けた取り組みを書いてきます。

今年やってきた改善

アラート調査の継続とアラートノイズの低減

アラート調査については入社エントリにも書きましたが、こちらは引き続きの対応です。

入社した頃と比べるとだいぶノイズは減ったと思います。

(もちろん自分一人対応だけではなく、周りのメンバーの協力もあってです)

DB周りのアラートは、MySQLスローログやバイナリログを泥臭く解析して、原因調査もすることで、バッチの構成やどんなクエリが流れているのかなど把握できました。

調査はもう少しスマートにできたらと思うところはありますが、今後、改善したいと思います。

ログサーバーのアクセス制限

ログ集約しているサーバーがあり、そこへ開発メンバーがログインしてgrepなどで調査し、負荷上昇やディスク容量のアラートを検知する状況でした。

また、一部のログについては、開発メンバーなら誰でもアクセスできてしまうことは、セキュリティリスクがありました。

そこで、弊社はNewRelicを導入しているのですが、今後のログ調査はNewRelicで行ってもらうようにし、サーバーへのアクセスを制限しました。

アクセス制限だけであればすぐに対応できますが、ログサーバーにログインする必要がある現状をヒアリングして、NewRelicの運用に寄せても問題ないか、開発メンバーと調整しています。

SREに限らずだと思いますが、物事をスムーズに進めるには、こうした事前の調整が必要で、運用改善するときにも大事なことだと思っています。

その後は、開発メンバーのアクセスはなくなり、アラートもなくなりました。

コスト(お金)削減

コスト削減は、シビアな状況になってからだと、張り詰めた気持ちで、超頑張らないといけません。。

幸い、今のところは差し迫ってコスト削減を進める必要はなく、この状況下であれば、心に余裕を持つことができますので、今のうちにということで、削減を進めることにしました。

コスト分析した結果、削減対象としては、インフラに絞りました。

他にも業務で使っているGitHubのライセンスなどもありますが、あまりインパクトのある削減コストではなく、仮に削減しようとしても諸々の調整する工数がありますので、削減対象から外しました。

下記に書いていますが、現状のインフラはさくらのクラウドが主要で、新しいサービスの立ち上げなどでは、AWSを使っています。

tech.trustbank.co.jp

※ この後にも少し書きますが、来年からは、さくらのクラウドからAWSへの移行に向けて動き出します!

まず、AWSについては、いろいろな要件で新規環境を構築したものの、その後、不要になったリソースを削除しました。

(Terraformで管理しているので、対象のコードをごっそり消して、リソースを削除していく)

あとは、リザーブインスタンス(RI)やSavings Plans(SP)の恩恵も受けられそうなので、適用しようと思いましたが、ふるさと納税の制度改正によるアクセス数増加に向けた対応が入り、いろいろ対応することが出てきたので、一旦、お見送りに。

tech.trustbank.co.jp

AWS移行が進んできたら、また適用を検討します。

さくらについては、AWSと同様に不要なリソースがけっこう出てきましたので、それらは削除しましたが、ディスクなどのバックアップも多くありました。

歴史的な経緯だと思いますが、サーバを入れ替えるタイミングなどで取得しておいたと思われるバックアップが溜まっている状況でした。

何かのために取得しておく必要はあると思いますが、もう数年以上経過しているバックアップは、さすがに使わないだろうと。

バックアップ要否を確認し、バックアップを削除しましたが、さくらのコスト削減が最もインパクトがありました(なんと、数十万/月)

来年の取り組み

AWS移行

今年は新規環境構築などもしましたが、既存システムでのつらさもいろいろと経験してきました。

そんな中、ようやくAWS移行が再始動しますが、まず移行するのは、昨年の記事にも書いてある地域通貨事業のchiicaです。

tech.trustbank.co.jp

もともと、chiicaを含めて、他のシステムも良い感じに移行に向けて進み始めていたものの、他の案件との兼ね合いもあり、空いた時間で進める、というベストエフォートでの対応となっていたため、本番環境の移行まで進まず。。

そこで、まずはchiicaの移行をプロジェクト化して、しっかりリソースを確保する流れにしました。

(ちょうど、会社としても移行を進めていこうという話が再び上がってきたのも良い流れでした)

「移行やるよ」宣言をして、他の案件があっても、これで堂々と突き進むことができるはずです!

移行計画を整理し直したり、移行に関わるメンバーのリソース確保だったりとPM的な動きも必要ですが、突き進むためには、今はこの進め方が最善かと考えていますので、しっかりやり切りたいと思います。

chiicaを先に移行することには大きな意味があります。

現状、ふるさとチョイスとchiicaは同じサーバに共存しており(一部は分離済み)、この状態では、双方のサービスに注意しながら作業を進めたり、移行中に双方のサービスに影響が出るリスクがあります。

そのため、先にchiicaだけ引き剥がしておくことで、チョイスを移行するときには、チョイスに専念して移行できるようにします。

1年通して感じたこと

やっぱりやること多いけど・・・

AWS移行だけではなく、他にもいろんなイベントがこの先に控えており、その中でも運用改善、サービスの信頼性向上、開発者体験の向上などやることがあります。

人的リソースも限られている中でどう進めるか、これを常に考える必要があります。

ですが、開発組織をリードする方もジョインしてきているので、来年以降、一緒にああだこうだ言いながら、組織面でもシステム面でも前進できたらと思っています!

フルリモートは最高

フルリモート歴が1年となりましたが、今の生活リズムが心地よくて、毎日通勤という生活には戻れなくなったかもしれません。。

職住隣接という言葉がありますが、文字通り、職場に近い場所に住む、ということで、通勤時間を短縮し、ワークライフバランスが取れたりというメリットがあります。

私も以前は電車通勤で、通勤時間は本でも読めば時間を有効に使えると思っていました。

ですが、リモートでは、朝型の自分の場合、朝は犬の散歩・朝食・家事をしても、8時くらいからは仕事を始められる状態にあり、調べごとをする時間に割り当てたりできます。

(家事も手伝うようになって、奥さんからの信頼を貯める。まさにトラストバンク。外で飲むには信頼残高を増やすことが大事。)

夜は、仕事を終えてそのままPCの前で本を読んだり、技術的な調べこともPCですぐにできますので、時間を有効に使えているのかなと感じています。

コロナ禍が落ち着き、出社となる方が多くなっていると思いますが、フルリモートが続けられずに悔しい思いをしているなら、弊社に転職してみては?、と下記の記事に続けて、煽っておきます。

tech.trustbank.co.jp

エンジニア募集

弊社ではSREを絶賛募集中です。

興味がある方はぜひ一度お話ししましょう!

https://www.wantedly.com/projects/854879