誰にも気づかれない品質を守る。 エンジニアの「“愛車”精神」とは?
高橋
Takahashi
■語り手プロフィール■ 【略歴】SIer、フリーランス等を経て2019年入社。kBackupの開発・運用を担当。
目次
トヨクモ技術広報チームです。 現場のリアルな熱量をお伝えする「PLGに生きるエンジニアたち」第7回です。
今回お話を伺ったのは、現在kBackup(新しいタブで開きます)の開発を担当する高橋さんです。SIerやフリーランス、自社サービス開発を経て2019年に入社し、以来この製品を担ってきました。
うまく動いている限り、お客様に意識されることのない製品。その品質を、エンジニアはどう決め、どう守り続けているのかをお伝えします。
1.泥臭い仕事が好きな自分と、kBackupの出会い
―まずは、これまでの経歴を教えてください。
最初に入ったのは、官公庁や銀行のシステムを開発するSIerでした。いわゆる下請けで、立場としては元請けの会社が「お客様」。仕様はその会社と相談しながら決めていました。残業が月100時間になることもありましたが、若かったので、それなりに楽しかったですね。泥臭い仕事がもともと好きなんです。
その後は不動産系サイトの開発に関わり、30代からはフリーランスとしてコンサルやシステム開発を手がけました。知人とプロジェクト管理ツールを立ち上げた時期もあります。前職はクラウドソーシング事業の会社で、社外向けプロダクト2つと、受発注などの社内システムを開発・運用していました。
いろいろな環境を転々としてきましたが、コンサルを経て自社サービスに関わるようになったあたりで、やっぱり自分は「ものづくり」が好きなんだとわかった気がします。
―kBackupは、どのような製品なのでしょうか?
kintoneのデータを毎日バックアップして、誤ってデータを消してしまった時など、いざという時に戻せるようにする製品です。
お客様にとっては「安心を買う」ものなので、2、3年ログインしない方もいます。使っていることさえ忘れられてしまうのは、裏を返せば、ちゃんと動いている証拠です。毎日確実にバックアップが取れていて、戻したい時に確実に戻せる。お客様が日々安心して使い続けられることが、この製品の価値です。
2.まずはメイン機能から。毎日の積み重ねで立て直す
―入社した当時、バグや問い合わせが多かったと聞いています。その中で、何から手をつけたのですか?
優先したのは、メイン機能に関わるところです。PrintCreator(新しいタブで開きます)(トヨクモの帳票出力サービス) なら印刷できなければいけないし、kBackupならバックアップが取れていなければいけない。影響の大きいものから順に対応していきました。
当時のkBackupでは「リストアできない」という問い合わせが頻繁にあり、毎日のバックアップが終わらないこともありました。そこでまずログを整えて、システムの状態やバックアップにかかる時間、システムコストを見えるようにしました。その上で性能改善を重ねていったんです。
―大変な時期だったと思います。どのくらい続きましたか?
落ち着くまでに2、3年かかりましたね。毎日少しずつ改善を続けるうちに、データ処理が速くなっていきました。ある変更で急に速くなることもありましたが、それも日々の積み重ねで下地ができていたからこそです。気づけばバックアップが毎日正常に終わるようになり、リストアの失敗も問い合わせも大きく減り、システムコストも大幅に下がっていました。
―前職と比べて、仕事の進め方はどう違っていましたか?
前職のクラウドソーシングの会社では、開発部にディレクターがいて、他部署との調整や進捗管理をしてくれていました。トヨクモでは、開発内容も優先順位も進め方も、ほぼすべて自分で判断します。CTOの木下さんに相談するのは、お客様への影響が大きい変更をする時や、工数がかさみそうな時くらいです。
いちいち承認を取っていたら、改善が追いつかないと思います。お客様の数もデータ量も増え続けていて、毎日のバックアップにかかる時間もどんどん伸びていく。かといって一気に並列度を上げれば負荷がかかり、コストも上がる。そのバランスを見ながら、チューニングをずっと続けています。
自由ではありますが、決して楽ではありません。裁量が大きい分、責任も大きい。でも、責任が大きいからこそ、やりがいもある。そんな感覚です。
3.100TB・2億ファイルを、止めずに直す
―扱うデータ量は、どのくらいあるのですか?
入社当初は数TBでしたが、kintoneで動画なども扱えるようになり、今は100TB弱です。添付ファイルは約2億個あります。
―添付ファイルの容量の集計方法を見直したそうですね。
きっかけは、お客様からの「レコードを消しても容量が減らない」という問い合わせでした。kBackupは30日分のバックアップを保持するので、kintone上で削除されたファイルも一定期間は残す必要があります。ただ従来の方式では、もう不要になったファイルまで容量に数えていたんです。
そこで、添付ファイルごとにどのバックアップから参照されているかをデータベースで管理し、最後に参照された日を記録して、不要なファイルを判定できるようにしました。言葉にすると単純ですが、全件をチェックするとそれだけで数日かかります。毎日回せるように、数十本のバッチを並列で流すなど、処理の仕方を工夫しました。
―どのように進めていったのですか?
少しずつリリースして動かしてみると、想定通りになっていないデータが出てくる。その繰り返しでした。古いファイルは今と情報の持ち方が違ったりして、テストでは出ない稀なケースが本番で出るんです。そのたびに処理のログやエラーを調べて、原因を突き止めるのに1、2日。直したら、正しく集計できているかを全件チェックするのに1週間以上かかります。
本番と同じ規模のテスト環境は用意できないので、社内アカウントで先行して検証し、本番では新旧の方式を並行して動かして結果を照合しました。いきなりファイルを消すのではなく、まず「消す予定」のログだけを出して、対象が合っているか、消しすぎていないかを確かめる。確実に大丈夫だとわかってから、本当に消すようにしました。
もちろん、すべてがうまくいったわけではありません。データベースの負荷が上がってバックアップが遅れたこともあります。その時はお客様にお詫びして、データベースのサイズを上げたり、処理を分けたりしながら調整しました。結局、切り替えまでに半年ほどかかりました。
―全面的に作り直して、一気に切り替える選択肢はなかったのでしょうか?
現実的ではなかったですね。一気にやるなら、正解となる状態がはっきりしている必要があります。でも毎日バックアップを取っているので、集計結果も毎日変わる。少しずつ変えては確かめないと、どこで間違えたのかがわからないんです。
それに、データは一度変えてしまうと戻せません。バックアップのデータを失ったら、取り返しがつかない。サービスも、1時間たりとも止めたくありません。だから、動かしながら少しずつ直すしかないんです。毎日乗る車を、長く修理に出すわけにはいきませんよね。今日はタイヤ、明日はオイルと、走れる状態を保ちながら整備していくイメージです。
最新の仕組みで全部作り直した方が楽、という考え方もあると思います。でもこの製品では、お客様のデータを守ることが何より優先です。丁寧に、確実に進めることを選んでいます。
4.お客様の安心を軸に、かける工数を決める
―「リストアできない」という問い合わせには、どう対応していますか?
まずログを確認し、必要ならログを追加で仕込みます。お客様の了承をいただいて、実データの一部で検証することもあります。最優先は、お客様がリストアできる状態に戻すこと。必要なら暫定対応をして、その後に根本原因の解決と再発防止、ログやアラートの整備を進めます。
―最近はどのような改善が多いですか?
ここ数年は、大きなデータを持つお客様のリストアへの対応が中心です。以前は長くても数十分で終わっていたリストアが、数時間、場合によっては12時間ほどかかるようになりました。
ある時、調査依頼を受けてログを見ると、同じお客様が何度もリストアをやり直していたんです。システムはちゃんと処理しているのに、画面上は何も変わらない。1時間待っても動きがないから、止まったと思ってもう一度リクエストする。そこで、リストア前のチェックがどこまで進んだか、何件リストアできたかを表示するようにしました。進捗を記録するカラムを追加し、更新のタイミングも見直して、1、2か月かけて形にしました。
―対応するかどうかは、何を基準に決めていますか?
根っこにあるのは費用対効果です。自分が動く時間もコスト。それに見合うメリットをお客様に届けられるかを常に考えています。
具体的には、2、3日でできるのか、1週間以上かかるのか。お客様にどのくらいお待ちいただけるか。別の方法で解決できるならそちらをご案内しますし、めったに起きないケースなら暫定対応にすることもあります。逆に、他のお客様にも同じパターンがありそうなら、きちんと作り込みます。
どうしても時間がかかる時は、CSと相談して「これだけかかりますが、どうしますか」とお客様に確認してもらいます。大きな変更になるなら、木下さんに経営判断を仰ぎます。
―新機能のアイデアもあると伺いました。
他サービスとの連携や、バックアップ済みの添付ファイルの検索など、アイデアはあります。ただ、検索は「戻す」ための機能ではないので見送っています。「1つのことは1つのプロダクトで」という会社の方針もあり、機能を増やすより、今ある機能を磨き込むことに力を使っています。kBackupの価値は、バックアップできて、戻せること。そこはブレないようにしています。
5.製品への向き合い方は「愛車を大切にする感覚」
―ここ1年くらいでAIを使うようになったと伺いました。仕事はどう変わりましたか?
自分でコードを書くことはなくなりました。設計、実装、テスト、調査、コードと設計書の整合性チェックまでAIに任せています。複数の開発タスクをAIに並行して進めさせ、その間に自分は方針の判断や確認に時間を使っています。
ニュースで気になる技術を見つけたら、「kBackupでやるなら?」とAIに調べさせて、設計や工数の見積もりまで出させる。大きな開発も含めて、複数のタスクを並行して動かしています。感覚としては、完全に自分の部下ですね。生産性は大きく上がり、バグも以前より減りました。優先度が低くて後回しにしていた要望にも、対応できることが増えています。
ただ、楽になるかと思いきや、仕事の密度はむしろ上がりました(笑)。作業中心から判断中心の仕事に変わったので、頭はかなり疲れます。
―AIに任せても、ご自身で担い続けているのはどこですか?
開発の方針と優先順位を決めること。設計書を細かく確認すること。そして、動作やデータを自分の目で確かめることです。本番に出す前には、必ずステージング環境でテストします。AIが書いたコードが良さそうに見えても、重要な変更はリストアを最後まで実行し、データがどうなったかまで自分で確かめます。
若い頃は、作ることそのものに情熱を注いでいました。今は作るのはAIに任せて、プロダクトマネージャーの目線で製品全体を考えています。その分、業務は時間内に収まっていて、残業は月に10時間もありません。
―AIがコードを書くようになり、エンジニアとして何を磨けばいいのか迷う人もいます。
自分はサービスを作りたいし、お客様に喜んでもらいたい。そのために、自分でプログラムを書く必要は必ずしもないと思っています。コンサルをやっていた頃も、既存のツールを組み合わせて価値を出せるなら、それでよかった。プログラムを書くことそのものが、サービスを良くするわけではないんですよね。
「もっと良くしたい」という要望や欲求は、人間にしかありません。それを自分の中ではっきりさせられれば、心配することはないと思います。
―仕事の外でも、技術に触れているそうですね。
週末に個人でAWSを契約して、AIにコードを書かせて何かを動かしています。自分にとっては、ちょっと高級なおもちゃのような感覚です。会社で「これどう作ったらいいんだろう」と思ったものを、家で試してみることもあります。そこで「こっちの方がいいかも」と気づいて、仕事に活きることもあります。
これは強制するようなことではなくて、技術が好きでやっているだけです。ただ、AIが作ってくれる時代だからこそ、「中ではどうなっているんだろう」と興味を持つことは大事だと思います。作ってみると、「思っていたのと違う」という場面が必ず出てきますから。
―ご自身の判断で進める中で、責任を感じるのはどんなところですか?
サービスの信頼性を守ることです。毎日確実にバックアップが取れ、必要な時に確実にリストアできること。問題が起きた時に、誠実に対応すること。開発内容も優先順位も自分で決めているので、自分の判断がそのまま信頼性に直結します。
その意味では、CSや他のチームからの信頼も大事にしています。kBackupの開発は、お客様と直接やり取りする機会が少ないので、CSとの関係がそのままお客様への対応の質になります。不明なことは正直に伝え、難しい時も代わりの方法を考える。そうやって信頼関係ができていると、「お客様に少し待っていただけますか」「ここはこちらの誤りだったので、お客様にそうお伝えいただけますか」と、お互いに頼みやすくなるんです。
―担当する製品を「自分のもの」と思えることが大事だと、インタビュー前におっしゃっていましたね。
愛車を大切にする感覚に近いです。傷があればすぐ直したいし、傷つけないよう丁寧に扱う。定期的にオイルも交換する。kBackupでいえば、不具合の修正、古いコードの整理、ライブラリの更新、性能改善、ログや管理画面の整備です。問題が起きてから対応するだけでは不十分で、普段から良い状態を保ちたい。誰かに言われなくても、自然と手をかけたくなるんです。
とはいえ、最初から今ほどの愛着があったわけではありません。向き合い続けているうちに、自然と湧いてきたものです。
―最後に、トヨクモに興味を持っているエンジニアの方へメッセージをお願いします。
担当する製品を大切にできて、もっと良くしたいと思える人と働きたいです。今の技術力よりも、そちらを大事にしています。製品を大切にできる人は、必要な技術を自分から学びます。自分もkBackupのためにAWSやフロントエンド、AI活用のスキルを身につけてきました。
うちはお客様の使い方が比較的見える会社です。「こうしたらもっと使いやすいんじゃないか」と考えられる人には、きっとやりがいがあります。愛情を持って育てられた製品は、お客様にも愛着を持ってもらいやすい。そういう製品を、一緒に育てていける人を待っています。
************************************
【最後に】
今回は、kBackupの開発・運用を担い、普段は意識されない製品の品質を守り続けてきた高橋さんに、「誰にも気づかれない品質をどう決め、どう守っているのか」について伺いました。
細かく管理されないのは、放任だからではありません。製品を「自分のもの」として、お客様の安心のために必要なことを自らやり切る。その責任を一人ひとりが引き受けているからこそ、エンジニアが自ら品質の水準を決められるのです。
オープンな組織と確かな技術をベースに「自らプロダクトの価値を作る!」
それが私たちの目指すエンジニアリングです。
次回は、前職とは勝手の違う環境で、自分なりの追いつき方を見つけて入社半年で周囲の評価を変えたエンジニアへバトンを繋ぎます。
どうぞお楽しみに!
************************************
「すべての人を非効率な仕事から解放する」という弊社のミッションに共感し、ともに挑戦していただける方からのご応募を心よりお待ちしております。
▶応募はこちらから(新しいタブで開きます)
引き続きトヨクモをよろしくお願いいたします!




