サービスを止めずに変え続ける。トヨクモのアンチ・ビッグバン開発

トヨクモ技術広報チームです。

現場のリアルな熱量をお伝えする「PLGに生きるエンジニアたち」第4回です。

「作り直したほうが早い」。複雑になったコードを前に、多くのエンジニアが一度は考えることです。
しかしトヨクモの開発本部は、一気に変える「ビッグバン」ではなく、お客様が使い続けているものを止めずに少しずつ変えていく「アンチ・ビッグバン」を選びます。その実践について、江田さんに伺いました。

―江田さんは新卒でトヨクモに入られましたね。入社を決めた理由は何でしたか？

　元々学生時代からトヨクモでアルバイトをしていたので、社風が分かっていて安心できたんです。ここなら成長できると思えました。就職活動の頃、「人の役に立つものを作りたい」と思っていて、まだ漠然としていましたが、トヨクモ製品はユーザーが多く、声を聞いて製品に反映できることが自分の考えと合っていました。

―実際に入社してみて、アルバイト時代と変わったことはありますか？

　入社前までは「これができないから、これをやる」というその場その場の積み上げ式の考え方でした。でも入社後は、先に「理想は何か」を決めて現状とのギャップを見極め、落としどころを作るようにしています。それがエンジニアの仕事だと考えるようになりました。

―コードを書く中で、理想とする実装と既存のコードとの折り合いに悩むことはありますか？

　毎日です（笑）。こうしたいけど思うようにいかない、その中でもまず「どうあるべきか」を決めて落とせない部分を守り、それ以外は諦める。その繰り返しですね。

―２年目でリファクタリングタスクを担当されたそうですね。FormBridgeの共通処理に手を入れることになったとき、「一か所直すと別が壊れる」という状態だったと伺いました。具体的にはどんなコードの状態だったんですか？

　共通処理の層が条件分岐だらけだったんです。FormBridgeの「管理者画面」と「公開フォーム」という性質の違うものが混ざり、さらにそれぞれに共通処理があったため、分岐を重ねて書くしかありませんでした。それで一か所直すと別の場所に影響が出る状態だったんです。リファクタリングの設計は北川さん、実装は自分だったのですが、まず性質が分かれるところを境界として、北川さんが設計を決めていました。

―北川さんの設計から、どんなことを学びましたか？

　設計とは「目的を達成するのに必要十分な手段を取る」ことだ、という点です。その時は、リポジトリもアプリケーションも分けずに、エントリポイント（処理の入口）だけを分けました。

　性質の違うものを分けるなら、マイクロサービスという手段もあります。しかしマイクロサービスにすると、サービス同士の境界を厳密に設計しなければなりません。FormBridgeでいえば、公開フォームもフォーム設定画面もどちらも「フォーム」を扱うので、共通する部分があります。サービスを分けると、その共通部分をどう持たせて、どう連携させるかに時間を取られてしまう。今回の目的は共通処理の条件分岐を減らすことだったので、入口を分けるだけで十分でした。境界を緩めにしておくことで開発スピードを保ちつつ、条件分岐の複雑さは解消できたんです。「何を目的にしていて、そのためにどんな手段をとるか」を考える、というのを学びました。

―作り直すのではなく、今あるコードを分けていく進め方を選んだのはなぜですか？

　複雑に絡み合った挙動で成り立っていたので、ゼロから作り直すと、挙動が大きく変わってしまいそうだったんです。全部作り直すとなると、動作確認もテストも追いつかず、ユーザーに影響が及んでしまいます。まず既存の挙動を明らかにして、それをどう単純化するか、という進め方のほうが安全だと判断しました。

―進める上で、気をつけていたことはありますか？

　セキュリティまわりなどセンシティブな部分を触るので、怖さはありました。なので着手する前に、テストが足りていないところにはテストを書き足し、そのあとでリファクタリングに入るようにしていました。想定外のことが起きないように、ですね。

―一度では終わらない作業だったと思います。途中で止まらずにやりきれた理由は何でしたか？

　北川さんの設計が、「分離した部分は他に影響しない」と確信を持てるものになっていたのが大きいです。もともとは腫れ物に触るような状態で、触った分だけ広い範囲の動作確認が必要でしたから。

　実は当時の自分は、そこを課題だと思えていなかったんです。北川さんが課題として捉えていたからこそ、思わぬところに影響が広がるのを防げました。こうした課題設定力は常に求められていることで、今もまだ完璧にはできませんが、頑張っているところです。

―お客様にとっては、どんな変化がありましたか？

　お客さんはこの件を知らないと思います。リファクタリングは、お客さんにとって「何も起きない」ことが成功なので、それでいいんです。もし手を入れずにいたら、直すたびに別のところに影響が出て、障害の多いサービスになっていたかもしれません。逆にマイクロサービスで大きく分けていたら、今回の目的に対しては過剰で、境界を気にしながらの作業になり、開発スピードの遅いサービスになっていた可能性もあると思います。

―監査ログ（※）をkintone連携サービス全体に入れる、という仕事を任された時、どう思いましたか？

※監査ログ：ユーザーの操作履歴を記録する機能。セキュリティ要件として導入の条件にする企業も多い。

　正直嬉しかったです。これまで着実に取り組んできたことが認められて、任せてもらえたのかなと。今回作るものの性質上、インフラのアーキテクチャから考える必要があったので、そこも楽しそうだと思いました。

―監査ログは複数のkintone製品にまたがる機能です。どのように進めたのでしょうか？

　ポイントは、実装に入る前に、複数のサービスから1か所にログを集めるデータの流れと、複数サービスの認可に基づく表示の仕組みを設計しておいたことです。その上で、1サービスずつ導入していきました。

　こうすると、ログを書き出す部分で難しさがあった時、最初に進めた製品と他の製品で技術スタックが共通しているところは横展開できるので、作業スピードを上げられます。また、複数サービスで一気にやるとデータ量が多くなり、それ自体が不確定要素になります。1サービスずつなら少しずつ増えていくので、変化や影響範囲が見やすいんです。

―リリース前に、本番環境で先行して動かしていたそうですね。

　はい。データ量を見たかったのと、疎通の確認ができるので、ユーザーには見せない状態で事前に動かしていました。その時に溜まった中途半端なログはリリース直前に消しきって、ユーザーから見ればリリース時点で何事もなかった状態にしました。

―もし、それをやっていなかったとしたら、どうなっていたと思いますか？

　リリースした直後の数日間は「ちゃんと動いているかな」という不安に駆られていたと思います。事前に動かして、動いている実績があったので、リリース後も動くだろうという安心感がありました。

　ユーザーが機能を有効化した後の使われ方は本番環境でしか見られませんが、それでも「何かあった時にどうやって元に戻すか」といったシミュレーションはできた状態にしておけます。

　この動き方は、「ユーザーの見えないところで先に仕込んでいっていい」という会社の方針でもあります。もちろん機能によっては切り替えのタイミングが危険なリリースもあるので、裏側で仕込むタイミングは見極める必要がありますし、一部の人だけが気づいて得をするようなことがあってはいけません。そこをチェックした上で、「見えないリリース」をやっています。

　インフラの設定次第で起きる問題は、どうしても検証環境では見つけられないことがありますからね。環境に起因する要素は、先に本番環境で動かしておけば分かる。「わからない」ことの数を減らした状態でリリースできるのがメリットです。

―監査ログは、会社にとっても重要な機能だと伺いました。

　「監査ログがあることでトヨクモの製品を導入できる」というお客様も多いので、やりがいがありました。また、閲覧期間や保持期間がコースによって異なる複雑な仕様なのですが、特定のプランだけ長期間保存できることがコースアップの理由になる。ビジネスとしてアップセルを狙えるので、エンジニアにとっては大変でも、しっかり作るべきところだと考えていました。

―要件を決める過程で、エンジニアとして意見を出すこともあるのでしょうか？

　要件の多くはPM（プロダクトマネージャー）が決めていますが、PMやデザイナーが出してくる理想像に対して、エンジニアとして実態を踏まえて「ここは妥協できないか」と相談することは日々あります。ユーザーの体験として落とせる部分なのか、といったことを話します。

　監査ログでいうと、閲覧も保存も2週間までというコースがありますが、2週間でデータを消すのは、複数製品のプラン状況を把握して大量のデータを消す、という複雑なロジックになります。なので「消さずに見せないだけでいいのでは」と相談しました。でも、ログが残っていると契約と違ってしまうし、あとでプランアップすれば見えてしまうので、ビジネス上は認められないという結論になりました。結局、削除する形で実装しました。

　必ずしも技術的な合理性が優先されるわけではありませんが、エンジニアが提案すること自体は歓迎されます。トップが技術を深く分かっているので、話がしやすいです。

―ビジネス上の狙いを聞ける環境があることは、開発にどう影響していますか？

　理由が分かったうえで作業できるのはメリットですね。何のためか分からないまま複雑なものを作る、というのは耐えられないので（笑）。

―自分が作った機能が使われている実感はありますか？

　売上への影響まで細かくキャッチアップするのは難しいのですが、機能の有効化率は見られるので、自分が出した機能が有効化されていると嬉しいです。「使われているな」「ちゃんと動いているな」というのが実感できます。自分の役割を果たして、ちゃんと使われるものを作っていきたいです。

―開発本部では「不確定要素の多いところから先に着手する」という方針があると伺いました。実際にはどういう作業になるのでしょうか？

　「どうなるか分からない不確定なところ」から意識的に着手します。自社サービスなので、そこまでスケジュール調整が必要なわけではありませんが、早めにリリース日を確定させて、セールス担当部署が最大限売れるようにしたいんです。リリース直前になって不確定なものに着手して「ズレます」となると困るので、読めないものを先に潰して、直前は小さめの作業だけが残るようにしています。

―不確定要素は、どうやって割り出しているのですか？

　自分にとって解像度が低いところです。自分も周りの人もあまりやったことがない部分や、今は「こうできる」と思っているけど、いざやってみたらできない、ということになりそうなところですね。頭の中でコードレベルで浮かぶところは後回しでいい。今パッと書けないところが、不確定なところです。

―最近の案件で、具体的な例はありますか？

　FormBridgeのAIチャットパネルです。フォームに特化した知識を答えてくれるAIを入れられる機能で、ユーザーがkintoneに登録しておいた知識をLLMに検索させます。こういう検索にはRAGやAgentic Searchといった方法があって、今回はAgentic Searchを採用しているのですが、それで実用に足る検索ができるのかが一番の不確定要素でした。なので、まずAIにPoCを作ってもらって、十分に動くことを確かめました。

　次に着手したのは非同期処理です。公開フォームに入れると一定のアクセスがあり、AIの応答には時間がかかるので、単純な同期リクエストでは耐えられません。なので非同期の形にして、それがちゃんと動くかを確かめるところに着手しました。どちらも今までやってきていない形だったので。そのあとのUIの作り込みや設定画面は、工数はかかりますが、進めていけば必ずできる作業です。

―こうして不確定要素をあぶり出すのは自然にできることですか？

　僕は意識的にやっています。あまり計画性のある人間ではないので（笑）、どこをリリースギリギリにやったら危ないかを考えて、そういう「計画段階」を意図的に工数に入れています。不確定要素だけでなく、「それをやらないと他の実装が進まないもの」も洗い出して、先にやるように計画します。同じチームのメンバーもこのやり方をしています。

―トヨクモではなるべく早くリリース日を決めていきますよね。しかし不確定要素を100%潰しきれていない中でリリース日を決めるのは、他社のエンジニアからするとリスクを強く感じそうです。

　リリース日にはまず「予定」の段階があり、リリースの数週間前に「確定」します。この時、バッファはそこまで持たせずにリリース予定日を決めて、ずれてしまったらずらす。「確定」させるタイミングでは、もう不確定要素がなくなっているので、改めてリリース日が決まります。

　こうした決め方の根底にあるのは、「リリース日を早く決めること」そのものではなく、「有用な製品を早くユーザーに届けること」です。「早くリリースする」「早くリリース日を決めてセールス担当が売りやすくする」ことを重要視しているので、バッファを多めに、という考えではやっていないです。

―まずお客様にとにかく価値を届けることを最優先とするということですね。

　そうですね。また、届いたあとにも変化しうるものなので、その時々の完成形を出しつつ、触ってもらった上でさらに具体的な改善点が出てきたら改訂していく、というのが大事だと思っています。

―監査ログでは、ログが重複して保存される不具合があったと伺いました。振り返って、何が起きていたのでしょうか？

　ログを保存するまでの経路の途中で重複が発生することを考慮できておらず、稀に同じログが重複して保存される事象が起きていました。大量にデータが流れてくる仕組みには、「最低1回は必ず届ける」、つまり重複して届くことを許容する「at-least-once」というメッセージングの方式があって、そこの考慮が抜けていたんです。SQS標準キュー（※）が重複配信することがあるのは知っていて、そこの重複排除は考慮していました。でも、SQSに限らず、「大量にデータを送るサービスなら、重複を許容するパターンをとっている可能性がある」と考えるべきでした。受け取る側それぞれで重複排除する必要があったんです。基礎知識があれば気づけたことだと思っています。

※SQS標準キュー：AWSのメッセージキューサービス「SQS」の標準的なキュー。大量のデータを高速に受け渡せる一方、同じデータが重複して届くことがある。 

―同じ見落としを防ぐために、今はどうしていますか？

　最初は、レビューしてもらう人を増やして、気づきの起点を増やすことを考えました。でも、人数を増やしても気づけないものは気づけないので、個人のレベルを上げていくしかない。年次を重ねる中で、自分も指摘する側にならないといけません。今まで携わってきた業務についてはレビューできますが、体系的な知識をつければもっと違和感に気づけるようになると思うので、コンピュータサイエンスやアプリケーション開発の基礎知識から学び直したいと思っています。

―基礎を学び直そうと思ったのは、この件がきっかけですか？

　監査ログの件の前から、感じてはいたんです。AIの成果物が上がってきて判断するときに、基礎知識がある人とない人では違うと思います。基礎知識がある人の方が、広い領域で意味のあるレビューができていますからね。この数年で自分で書く経験は積めましたが、時間をかけて経験を積んでいける時代ではなくなってきています。一度体系的に学ぶことを、このタイミングで入れるのがいいと思っています。

************************************

【最後に】

トヨクモ技術広報から
自分の限界を決めずに挑戦したい方へ

今回は、アンチ・ビッグバン開発についてお届けしました。

不確定要素を先に潰し、小さく分けて、早く届ける。江田さんの話から見えてきたのは、アンチ・ビッグバンがこうした判断の積み重ねで成り立っているということです。そして、どこに不確定要素が潜んでいるかに気づくのも、AIの成果物を見極めてスピードにつなげるのも、それを支えるのは基礎知識。江田さんの学び直しは、アンチ・ビッグバンを続けていくための次の一手でもあります。

オープンな組織と確かな技術をベースに「自らプロダクトの価値を作る！」
それが私たちの目指すエンジニアリングです。

次回は、新卒入社後、早くも2年目でプロフェッショナルに昇格したエンジニアへバトンを繋ぎます

どうぞお楽しみに！
************************************

「すべての人を非効率な仕事から解放する」という弊社のミッションに共感し、ともに挑戦していただける方からのご応募を心よりお待ちしております。

▶応募はこちらから

▶開発本部全体の情報はこちら

引き続きトヨクモをよろしくお願いいたします！