誰もいじれない“秘伝のタレサーバー”をどう克服したのか　8年前にフォルシアが決行した「個からチームへの変革」

技術部長として「webコネクト」開発を統括

田中謙次氏（以下、田中）：フォルシアの技術戦略で、「これまでどんなことをやってきて、これからどうしていきたいか？」という話ですね。

まず自己紹介をします。私は、田中謙次と申します。名も名字も平凡ですが、先に趣味を言うと、旅行がけっこう好きで、今も旅行のシステムを作っています。行ったことのない場所を開拓していくのが好きで、日本はもう全部行って、海外も33ヶ国行きました。左の写真は、アマゾン川で撮ったものです。赤色のところは行ったことがあります。最近子どもが生まれて、パパになったので育児をやっています。

私は、今、第二旅行プラットフォーム部で技術部長をしていますが、経歴は中途入社8年目です。もともと複写機メーカーのR&Dで働いていて、そこから縁があってフォルシアに来ています。

技術組織や技術推進体制の構築、マネジメントを担当しています。特に今は採用やチーム開発にチカラを入れて推進しています。同時に旅行販売プラットフォームの「webコネクト」の開発を統括しています。よろしくお願いします。

今日話そうと思っていることですが、フォルシアがこれまでどんなことをやってきたかという話と、これからの話ですね。これまでやってきた話は少し中期的なスパンで話します。まずフォルシアがこれまでどんなことをやってきたか、事業内容をザッとお話しします。

弊社は、旅行会社や、理化学機器メーカーに「Spook」というプロダクトを導入してもらっている会社です。今はだいたい120人ぐらいの社員がいる会社で、その内の半分ぐらいがエンジニアという会社です。

弊社の強みは、PostgreSQLなどを使って膨大で複雑なデータを検索に特化したデータに変えて、コンパクトにして、速く検索できるようにする独自の技術です。

普通の検索エンジンだと、なにか1個を見つけてそれを深堀りしていくんですが、弊社はデータを俯瞰して見られるところを売りにしています。「この条件を選んだら、ほかの条件を選んだときに何件になるか」とか「これ押したらどうなるか」とかを一歩先回りして検索するみたいなことをやっています。「ユーザーがいい感じに検索できる」ことを心がけています。

「ドキュメントより動く」を重要視して価値を提供

開発の流れですが、今までは基本的には受託開発をメインにしていました。お客さんからデータをもらって、それをお客さんと和気あいあいというか、あーだこーだと議論しながら一緒に作っていって、「ドキュメントよりも動くもの」というところを大事にして、価値を提供しています。また、納品して終わりではなくて、継続的にその事業に関わっていくことができる会社です。ここは今も続いている話です。

フォルシアのエンジニアは基本的に検索を軸にして顧客との仕様調整から実装まで一気通貫でやります。全部やるのは、やっぱりコミュニケーションロスをなくすというのが一番の理由かなと思っています。

伝言ゲームってどこかで失敗すると思っているのもありますし、「なんでこれ作るんだろう？」というところをやっぱり一番大事にしたいなと思っているので、顧客の仕様を決めたり、実装したりというところをきちんと大事にしたいなと思ってやっています。

開発・運用・保守というところで、チームをあえて明確に分けていません。やっぱり継続的な改善と運用がすごく大事だなと思っています。

例えば、運用や保守をあんまり考えずに作っちゃうと、「とりあえずなんとかする」みたいな仕組みになってしまったり、あとの人のことをあんまり考えずに作ったりしてしまうので、あえてそこは明確に分けずに、「自分も保守していくんだな」ときちんと考えてやるという設計を目指してやっています。

あとは少数精鋭でボトムアップですね。高い自律性を売りにしています。今回他のLTで発表されたいろいろやったという話も、別に「やってくれ」と言ったわけではなくて、自発的にやるということをすごく重視しています。

入社当初の会社は実績を重ねていた時期　仕事も課題もいっぱいの日々

だいぶ昔の話にはなるんですが、私がフォルシア入ったのは7～8年くらい前ですね。今がだいたい120人くらいいるので、半分よりちょっと少ないくらいの50人くらいの会社のときがどんな感じだったかという話です。

私が入社したときどんな会社だったかというと、とにかく圧倒的な実装能力・調整能力を持ったエンジニアがもうバッサバサと案件をこなしていくみたいな会社でした。今と変わらず、とにかく少数精鋭でより多くのアウトプットを出すことを重視していました。JTBさんやANAさんなど、日本の旅行業を牽引する旅行会社を皮切りに、どんどん実績を重ねていく時期でした。

とにかく仕事がいっぱいあって、毎日毎日大変な時期で伸びていたときではあったのですが、課題もありました。

具体的には、「ドキュメントよりも動くもの」を重視した結果、「ソースコードを読めばわかる」仕様になっていたり、少数精鋭の少数もいいところで、プロジェクトが1人メンバーという「ぼっちプロジェクト」と呼ばれるプロジェクトもあったりしました。

ほかにも、ひどいサーバーを運用したことがある人はわかるかもしれないんですが、設定もそれぞれ勝手にやったりしていて、「誰が何をどうしていて」とか「どのサーバーにどんな設定をしているか」とか、もはや誰もよくわからない状態を「秘伝のタレ」と言っているんですが、そんなサーバーがあったり、とにかくいっぱいやっていたので、その障害対応に追われる日々でした。

8年前に起こった「個からチームへの変革」

そこからどういうふうに変わっていったかですが、今から8年前ぐらいから変わってきました。「個からチームへの変革」があったのかなと思っています。

その個からチームへというところでどう変わっていったかですが、まず開発カルチャーの変革です。

これは「えっ？」っていう感じかもしれませんが、実はコードレビューって昔はぜんぜんやっていなかったりするんですね。それを最近は当たり前のようにできるようになってきました。

あとはやっぱりコミュニケーションって大事だなというところとかで、朝会をするようになりました。ほかにもテストを書くようになったり、新卒1年目からいろいろとやったりですね。そういうカルチャーがだいぶできてきました。あとは、1人でプロジェクトを回すことはなくなってきたかなと思います。

あと、意外と大事だなというところで、日常的に気軽にドキュメンテーションする文化ができてきました。重たい仕様書を書くよりか、「ちょっと困ったな」と思ったときや「これ誰かが困りそうだな」って思ったときに、esaなどを使って、本当にちょっとした文章を書くということができてきたと思っていて。何か困ったら書いたり、GitLabを使ったり、変わってきたなと思います。

ほかにも、プロダクト開発と運用の変革というところで、プロダクト軸とは別に個別課題を解決する横串組織を作りました。

なんで動いているかわからないサーバーがなくなったというところです。これは前回「FORCIA Meetup」で、DevOpsがテーマのイベントをやったんですが、そのときも、Ansibleなどを使ってとにかくサーバーの設定をきちんとコード化して管理するという話をしています。「新しくサーバーを入れるときには、Ansibleで絶対やろうね」と強い意思をもってやってきました。

あと、レガシーコード改善もここ数年けっこう力を入れてきました。レガシーコードって、けっこう古臭い感じで「あんまり触りたくねぇな」みたいな気持ちになるのがあって、どうしても臭いものにはフタをしよう、みたいなところがあったんですが、やっぱりこのレガシーコードに向き合っていかないといけないなと思っていて。

こういうコードを改善するのってかっこいいって普通に思うんですね。それをみんなの共通認識にできたということが、このレガシーコード改善の1つのポイントだったと思っています。もちろん気持ちだけじゃなくて、TypeScriptに変えたり、このイベントでも東川から発表がありましたが、ああいう改善したりって普通に考えてかっこいいと思うので、そういう文化を作っていきました。

あとは障害アラートです。メチャクチャいっぱいアラートがあったんですが、これも「いっぱいだなぁ」だとぜんぜん変わらなくて、「このくらいが今あって、このくらいを減らそう」みたいな指標をを作っていったり。単純に可視化すれば「今こういう状況になっていて、前よりだいぶ減ったぞ」みたいなのがあったりしたら「よし、もうちょっと減らそう！」となるので、このように障害を見えるようにするということですね。自分たちがこの障害に対してどれだけの時間を使っているかとか、そういうところをきちんと見えるようにしてきました。

ほかにも、自社で管理できる一部のサービスは、Kubernetesにどんどん移しています。

横串横断組織を作って、まだまだ課題は山積なんですが、個別の課題をけっこうクリアしてきました。

（後半へつづく）