はじめに こんにちは！新卒1年目エンジニアの宮本唯です。 私はフォルシア入社前にプログラミングの経験はほぼなく、大学では数学科に所属していました。数学の中でも比較的コンピューターサイエンスに近い分野で、主に正規表現が研究対象でした。残念ながら私には研究者としての資質が無かったためエンジニアに転向したのですが、いざエンジニアになってみるとプログラミングで正規表現を扱う機会が非常に多いことが分かります。 フォルシアでは新人研修でPostgreSQLを使って簡単な名簿アプリを作るのですが、ここでもSQL文に正規表現を使う必要がありました。 「正規表現はワイの専門や！ほかの同期を出し抜いてブ

こんにちは、エンジニアの澤田です。 普段の業務で、XMLなどから値を取り出して扱う際、データを処理しやすいように一度DBに格納して、DB上でデータを処理することがあるのですが、 XMLなどは階層構造になっているため、取り出したデータも階層構造になることが多く、そのままではDBに格納することが難しくなっています。 (FORCIAでよく使っているPostgresでは配列や階層化された配列を格納できますが、階層化された配列の場合、同一階層の配列は長さが同じでなければならない等の制約があります) 今回は、最近少しずつ勉強しているHaskellを使って、階層化された配列をDBに格納しやすい形に変換

この記事は GitLab Advent Calendar 2022 の 12 日目の記事です。 フォルシア株式会社エンジニアの籏野です。 先日、社内にホスティングしている GitLab 上のプロジェクトのライブラリ更新を目的にrenovateを導入しました。 複数のプロジェクトで手軽に導入できるように工夫をしたので紹介します。 renovate とは 詳細は検索すればかなり出てくるので省略しますが、プロジェクトが利用するライブラリの更新を自動化するためのツールになります。 GitHub であれば GitHub App によって renovate を利用できるため、かなり気軽に導入で

こんにちは。エンジニアの宮本唯です。先日、TypeScriptのLT会Shinjuku.ts#1を開催しました。 これまでフォルシアでは、rustのLTイベントShinjuku.rsを20回にわたって開催してきました。Shinjuku.rsでは多くの方にご登壇いただきrust好き同士の交流の場となってきましたが、この度新しく typeScript好きの方々に対しての活動を広げるべく Shinjuku.tsを開催する運びとなりました。 今回は記念すべき第一回、良いスタートダッシュを切るべく   ～TypeScriptたのしい！私の好きな言語です！～   というテーマを設定し登壇者を募集しました。その甲斐があってかはわかりませんが、イベント当日は登壇者のTypeScript好きが伝わってくる講演が目白押し。この記事では各講演の内容を、運営者目線でレポートします。 LTの様子 フォルシアのフレームワークとTypescript   | Taku Hatano さん 1人目は、フォルシア5年目エンジニアのTaku Hatanoさんです。 フォルシアでは独自のWebフレームワークを取り入れていますが、現在最も新しいフレームワークは第3世代です。世の中に便利な技術スタックが出てくるたび、それらを取り入れながらアップデートを続けてきました。開発言語にTypeScriptが取り入れられたのは今の第3世代からです。 開発言語を変更すると、エンジニアの勉強すべきことが一気に増えてしまいます。第2世代から第3世代に移行するにあたっても、社内では学習コストに対する懸念がありました。しかしながら、いざTypeScriptを導入してみるとその恩恵は大きく、今や型のない生活には戻れなくなっています。 とくに今回は リクエストパラメーターに型をつけられること インターフェースを使って実装を分離できること の2点についてどのようなメリットがあったかを説明してくださいました。 籏野さんの講演を聞いてから改めて自分の開発しているソースコードを見ると、TSの恩恵をうまく生かしながらフォルシアのアプリが作られていることがわかりました。 登壇者 HatanoさんのFORCIA CUBEの記事はコチラ。 Keycloak on Kubernetes Reduxのreselectを改めて理解する その他の記事は   コチラ 一か月半かけて、TypeScript本を写経した話   | ツノ さん 2人目は、connpassページから外部LT枠で応募していただいたツノさんです。 写経とは仏教において経典を書写する修行のこと、IT業界でもストイックなエンジニアは写経に励んでいます。ただしエンジニアが写経するのは多くの場合経典ではなく、プログラムのソースコードです。今回ツノさんには、『 プロを目指す人のためのTypeScript入門 』を一か月半かけて写経したときのお話をしていただきました。 写経のコツは1日たりとも休まないこと、毎朝7時に起きて速攻でコーディングしてから出社していたツノさんのGitHubには見事な芝が生えていました。教科書をただ読むだけではなく一字一句写経することで、これまで苦手意識のあった技術をちゃんと理解したり、便利な機能を新しく知ることができたようです。 私はとても体たらくな人間なので写経から逃げていましたが、社内でも写経を推す声があり、ぜひ明日か明後日くらいから取り組んでみようと思います。 TypeScript(WebGL)+React+Viteで、さくっと Geodesic Polyhedron を描画してみた   | tsuji さん 3人目はフォルシア新人エンジニアのtsujiさんです。 「頂点がおおよそ均等に分布する球ってどうやって構成するんだろう...？」ある休日ふと疑問に思ったtsuji青年、多面体から構成された Geodesic Polyhedron が答えとなることに気づき、TypeScriptなどを使って描画することにしました。 実装には複数のフレームワークが使われています。 Vite ... 開発環境の構築 React ... canvas とボタンの生成 WebGL ... 画面に描画する部分 とくにWebGLで画面に描画する部分では、色づかいやアニメーションなど見た目にもこだわって実装したそうです。 tsujiさんは私と同じ新人エンジニアですが非常に高い技術を持っており、先輩社員から「とても新人とは思えない！」という声をよく聞きます。同期で語り合ったブログではこの講演の内容についても触れているので、よろしければご覧ください！ 2022年新卒新入社員で語り合ってみた　座談会part１ ～今年の新入社員～ Type Level Chording | ytaka さん 4人目はフォルシアOBのytakaさんです。 LTのタイトルは "Type Level   Chording "、TypeScriptの型をつかって音楽を奏でようという斬新な企画です。今回の目標は、コード名からコードの音を型推論することです。たとえば、 C   からは   [C, E, G] 、   Cm7   からは   [C, D#, G, A#]   を推論させます。 推論の際カギになるのは音を数字に置き換えるとコードの構成音が文字式で表せること、たとえばmajorコードは   [n, n+4, n+7] 、minorコードは   [n, n+3, n+7]   と表すことができます。この性質を糸口として、TypeScriptの機能でやりたいことをどんどん実現していきます。 数値同士の足し算 ...   Indexed Access Types ,   Variadic Tuple Types ,   Recursive Conditional Types 数値型から文字列型への変換 ...   Template Literal Types 文字列型から数値型への返還 ...   Improved Inference 剰余を取る ...   Type Inference in Conditional Types ほか ytakaさんはフォルシアで活躍されていた元社員です。Shinjuku.tsを開催するにあたっても、ytakaさんにぜひ登壇してほしいと運営から声を掛け快諾をいただきました。内容自体が面白かったのはもちろん、スライドの構成や話し方にも工夫があり、自分が発表するうえでも学ぶところが大きかったです。 Red Coder が TypeScript で競技プログラミングに挑戦して挫折した話   | てんぷらさん 最後はフォルシア3年目エンジニアのてんぷらさんです。 課題に対してプログラミングを使って答えを作成する競技プログラミングは、フォルシアエンジニアにとって国技的存在です。競技プログラミングで使用される言語はC++やPythonが一般的ですが、 TypeScriptで競技プログラミングはできるのでしょうか ？フォルシア最強競技プログラマーのてんぷらさんがTypeScriptでのAC(正解)に挑みます。 TypeScriptで競技プログラミングをやろうとする時に壁となるのは、 MAX_SAFE_INTEGER   と実行時間制限です。競技プログラミングの問題の途中式には   2^63   程度の大きさの値まで出てきますが、TypeScriptでは使用可能な整数は   2^53 未満に制限されているため、オーバーフローしてしまいます。 また、掛け算にBigIntを使用した場合は、処理が遅く問題の実行時間制限に引っかかります。 しかしここで諦めないのがレッドコーダー   tempura0224 、大きな整数同士の掛け算を行う高速なプログラムを自作しACを獲得しました。 現在は競技プログラミングから離れてしまったてんぷらさんですが、業務プログラミングの世界では次々と成果を出しています。今後の活躍にも目が離せませんね。 てんぷらさんのブログ記事はこちら TypeScriptの型レベルプログラミングで数独を解く 余談～運営について～ 今回はTypeScriptをテーマとした初のイベントでしたが、運営も新人エンジニアが中心となって行いました。 運営の1人である私が担当したのは、 参加者募集ページの作成 社内登壇者の募集 当日のスポンサートーク などです。 普段の業務の中で時間を作り準備をするのは大変でしたが、開催後のアンケートではたくさんのありがたいお言葉をいただき、疲れが飛ぶ思いでした。今後も、運営の知見を蓄えつつ、TypeScriptに限らない様々なイベントを開催予定です。皆様のご参加ご登壇をぜひお待ちしております。

はじめに 旅行プラットフォーム部の武田です。 最近、AWS Amplifyを利用してNext.jsのアプリケーションをホスティングする機会があり、実際にアプリケーションを作りながら開発の流れについて紹介します。 Amplifyで楽をしつつ一部のAPIはNext.jsのAPI Routesを利用する、というやり方が比較的シンプルで良いと感じました。 AmplifyでAPIを構築する場合、Next.jsのAPI Routesを利用することも有力な選択肢になりそうです。 今回作るアプリケーションはCognitoユーザープールのユーザーをAWSの管理コンソール経由ではなく、Next.jsのア

こんにちは。経営企画室の伊藤です。 先日の 『 「webコネクトって何ですか？」 ～（前編）フォルシアだからこそ実現できた旅行業界向けSaaSプロダクト～』 に引き続き、今回は後編、webコネクトは今後どのような世界観を目指しているのか伺いました。 webコネクトについて教えてくれた社員プロフィール 旅行プラットフォーム部　開発部長　田中 謙次（たなか・けんじ） 2013年　キャリア入社 OA機器メーカーにてwebシステムの研究開発職に従事。事業化を経験し、技術とビジネスの両方がわかるエンジニアを目指し2013年にフォルシアへ入社。フルスタックエンジニアとして旅行会社や福利厚生旅行会社のシステム開発を担当。 ※所属は2022年11月現在のものとなります 前編に引き続き、開発部長にインタビュー。それではさっそく聞いていきます！ webコネクトの完成形のイメージとは...？ ―― webコネクトは、お客様が必要な機能を選択しながらバージョンアップさせることができるプロダクトであると理解できましたが、今後どのように機能を追加していくのでしょうか？ それぞれのお客様の実現したいことに耳を傾け、導入できる機能を増やしていくことを考えています。個別の要望に最適化するのではなく、なるべく汎用的な仕組みとして提供したいと思います。また、要望に応えるだけでなく、ニーズを先読みし機能を先行して開発し、提案できるような流れにもしていきたいと考えています。 非旅行業界でも低コスト・短期間で旅行業へ参入できる未来へ ―― webコネクトの展開先として、 旅行業以外の業界への展開も視野に入れているのでしょうか？ いわゆる旅行業を生業にされている企業には限りはありますが、これから旅行業界に乗り出そうと考えている企業や、旅行と親和性の高い特色のあるコンテンツを持っている企業は結構あると考えています。webコネクトを活用すれば、そういった今まで旅行商品を扱っていなかったメディアや交通キャリアなどが低コスト、短期間で旅行業へ参入することをお手伝いできるのではないかと考えています。 それだけを単体で売っても価値を発揮させづらい商材に対して、何か色を出して販売できないかと考える企業は多く、ダイナミックパッケージという販売形態も、単純に飛行機の公示運賃のチケットと宿泊施設の料金を足して売っているわけではなく、それらを組み合わせ旅行企画商品として販売することにより、価格的にも内容的にも魅力ある商品としてユーザーに提供できるものです。企画性の高い商品を作成し提供することで、各社が差別化を図ることができます。 宿泊施設は、OTA（ Online Travel Agent：インターネット上だけで取引を行う旅行会社）の台頭やサイトコントローラー（複数の販売先に対して、客室在庫やプランの販売価格、宿泊者の予約情報等をまとめて管理するシステム）の普及により価格は最適化され、仕入れによる差は少なくなってきたのではないかと思います。 一方で、着地型旅行商品と呼ばれているオプショナルツアーやチケットなど、まだまだ平準化が進んでいない旅行コンテンツもあります。自社で保有しているコンテンツだからこそ安く提供できる、在庫を潤沢に持っているなどの特色を活かして商品を造っていくという発想は、旅行会社だけが考えているものではありません。鉄道会社の大どころはすでに旅行会社をグループ会社等で運営していますが、船舶運営会社であったり、同じような発想で集客拡大のために旅行と絡めたサービスの提供を検討している企業はたくさんあります。 例えば、地方のテーマパークに人を呼び込むために、航空券とホテルを組み合わせてセットで売っていくというのもそういった発想ですが、このような売り方をしたいと思っても、セットにしてオンラインで販売していくという実績がないことが多くあります。 眠っている魅力あるコンテンツと、オンライン販売がこなれてきている商材とを組み合わせて魅力づけしていくというのが狙っていきたいことかと思いますが、そこでシステム面がハードルになる。なので、webコネクトの他の業界への展開という点については、まずはその「旅行関連業界」へ向けて、鉄道会社だけ、テーマパーク運営会社だけで、旅行サービスの提供が完結するような仕組みをつくっていくことが活用の場の拡大になっていくと思います。 そのためには、まずは中堅旅行会社や大手旅行会社といった企業にwebコネクトを導入いただき、その次の展開として、魅力的なコンテンツを持っているけれどDX化が進んでいない企業や、集客に課題感を感じていたり、価値を組み合わせることでビジネスを大きくしていきたいと考える企業へのwebコネクト提供ということが考えられるように思います。 webコネクト エンジニアから見た旅行業界の姿 ―― システム面がハードルになりえる点をお話いただきましたが、旅行業界のDX化についてどのような印象でしょうか？ まさに昨今、アナログだった旅行業界が変わろうとしてるフェーズだと感じています。まず、なぜ旅行会社や旅行関連会社がフォルシアに相談してくるのかといったら、基本的には「web販売を強化したいから」です。 店舗の売上はやはり昨今の情勢を鑑み減少傾向だと思います。そういった状況下で、「店舗の売上を上げるため」のシステム投資をしようという方針にはならないものです。店舗の売上が落ちてきているのであれば、なおさら「オンライン上で販売が完結できるように」という方向性でのシステム投資が考えられます。そういう変化のフェーズを迎えていると思います。 ―― それはコロナ禍に関係なくでしょうか？ コロナ以前からそういう動きがあり、withコロナの昨今、さらに加速したという印象です。こういったまさに過渡期であるタイミングでフォルシアをビジネスパートナーとして選んでいただいてるというのは、我々にとってはありがたいですね。 コロナ禍の収束が見えずらい昨今を鑑み、我々としても今まで通り時間とお金をかけて、じっくりサービス（システム）を作るというよりは、旅行業界は特殊な業界ではありつつも、業界内の各社の課題感はある程度共通なものがあるので、その特殊な要素をちゃんと汲み取ってシステムを構築していけば、顧客側としても安く早く使えるというメリットがあると思っています。フォルシアとしても、今までの受託開発というスタイルだけではなく、そういうニーズにも応えていけるよう、戦略立ててwebコネクトを推し進めています。 webコネクトの未来 ―― webコネクトは今後どのように発展していくのでしょうか？ 外部接続できる素材をどんどん増やしていく 導入コストを下げる一方で、webコネクトでできることを増やしていく 旅行会社、そしてゆくゆくは旅行関連会社が自社ならではのサービスを提供していけるように、差別化ができるポイントを増やしていく この３点がこれからwebコネクトが発展していくためにポイントとなって来ると考えています。 さきほども話題に出ましたが、まだまだ世の中には旅行と親和性があるけれどもオンライン上での販売ができていない、「つながっていない」部分はあります。レガシーな業界であっても、簡単にシステム化できるような仕組みを用意して、今まで流通していなかったところを簡単に流通できるようにしていく、「つなげていく」ということがwebコネクトで実現させていきたいことです。 不可能を可能にするフォルシアエンジニア ―― そのために必要なモノ・コトは何でしょうか？ 何も手を打たないと品質の問題で成長が鈍化するというシナリオが見えているので、機能追加と同時に設計の見直し、強い意思を持ってのリファクタリングも進めていく必要があると考えています。 機能追加を行って行くことで、ときには何かしらの矛盾が生じてしまうこともあります。お客様側としては、フォルシアが手を入れたことで不具合が生じるとなったらたまったものではありません。そういったことが起こらないようにするためにも、自分たちの責任でしっかりとした土台を築き、発展させていく。それがSaaSプロダクトをつくるうえでの大切な要素だと思っています。 また、顧客が何を求めているかのニーズを探っていく、それを抽象化し、さらに先読みしてプロダクトとして実装していく。webコネクトの発展のためには、これらが必要になってくると考えています。 最後に、これまでの機能開発においても、JR特有の契約形態の難しさであったり、料金計算の仕方であったり、「本当にこの機能は実現できるのだろうか...」と苦しい場面はありました。それらを実現させてきたのは、フォルシアエンジニアの「最後までやり切る力」や「複雑なロジックをしっかりと実装する力」。これはwebコネクトだから、受託開発だからというわけではなく、フォルシアエンジニアに共通してある強みだと思います。 後編：つなげれば、見える。 「webコネクト」の今後の展望についてのインタビュー後編、いかがでしたでしょうか？ 検索システムの提供（受託開発）が主だったころのフォルシアのキャッチコピーは「見つからなければ、始まらない」、「見つけることから、始めよう」でした。そして、いま、これまでの知見・ノウハウを集結させ、「つなげれば、見える。」という想いでフォルシアはビジネスを紡いでいます。 見つけることができるようになれば、そこから新たな取り組みが始まり、取り組みが動き出せば、ばらばらのように見えたものに一連のつながりが見えてくる―― webコネクトの導入について詳しく話を聞きたい、webコネクトを一緒につくり上げていきたい等、興味関心をお持ちいただけましたら是非 問い合わせフォーム よりご連絡ください。

こんにちは。経営企画室の伊藤です。 10月11日からは、政府が実施する全国を対象とした観光需要喚起策の「全国旅行支援」が開始され、旅行の計画に心躍らせている方々も多いのではないでしょうか。 今日はそんな『旅行』にまつわるフォルシアの自社プロダクト 「webコネクト」 について、どんなプロダクトなのか、プロダクト誕生の背景、今後どんな世界観を目指しているのかといった疑問を開発部長に伺いました！ まずは前編、webコネクトとはどんなプロダクトなのかに迫ります。旅行・観光業のDX化や、SaaSプロダクトの開発に興味があるかたに「webコネクト」のおもしろさが伝わりますと幸いです。 webコネクトについて教えてくれた社員プロフィール 旅行プラットフォーム部　開発部長　田中 謙次（たなか・けんじ） 2013年　キャリア入社 OA機器メーカーにてwebシステムの研究開発職に従事。事業化を経験し、技術とビジネスの両方がわかるエンジニアを目指し2013年にフォルシアへ入社。フルスタックエンジニアとして旅行会社や福利厚生旅行会社のシステム開発を担当。 ※所属は2022年11月現在のものとなります それではさっそく聞いていきます！ 「そもそも、webコネクトってなんですか？」 ―― フォルシアコーポレートサイト の プロダクト紹介ページ では「次世代型 旅行商品販売プラットフォーム」と謳われていますが、いったいどんなプロダクトなのでしょうか？ webコネクトは、旅行会社向けに旅行商品をオンライン上で売るためのシステムを簡単に構築できるプロダクトとして誕生しました。2020年にローンチし、ローンチ当初は、フォルシアの強みである「検索機能」に特化していましたが、現在では旅行商品のプランを作る素材登録システムや、予約・決済システム等まで対応領域を拡大し、近日リリース予定です。 webコネクト　プロダクト概念図 webコネクトを生み出すにあたって、一番最初の発想は、いままでのフォルシアのビジネス（独自の技術基盤を用いた受託開発での「検索システム」の開発・提供）を継承する形で、それをSaaSプロダクトにするというものでした。 もともとwebコネクトは、航空会社の旅行商品用運賃の変動運賃化に伴い、固定金額のパッケージツアーを販売するのが困難になるという予測の元、ダイナミックパッケージという宿泊素材と交通素材を組み合わせて販売できるシステムを簡単に導入できるようにというところから始まっています。その後、料金を変動させつつ予め旅行商品をセットしたパッケージツアーを販売できる「ツアー型」機能や、JRや船舶を販売できる機能をリリースしてきました。ここまではあくまでも「検索システム」の延長でラインナップを拡大させていきました。 そこから、お客様（旅行会社等）がシステム間の連携の調整に手を煩わせなくてもいいように「検索システム」だけでなくその前後の工程までワンストップでプロダクトを提供したいという思いがあり、旅行商品をオンライン上で販売するために必要となる機能を網羅させていくこととなりました。 機能は横にも縦にも広がっていますが、お客様が自社のシステムのなかで必要な機能だけを取捨選択して導入することが可能です。 必要な物を必要なだけ取捨選択 ―― 機能群を総称して「webコネクト」と呼ぶものの、どの機能を実装するかの取捨選択はお客様ができるということなのですね。 結局各社それぞれ現状も何かしらのシステムを使っているので、いま持っているものを活かしながら、webコネクトを導入することができると思います。 例えばすでに商品造成の機能を持っているのであれば、それを作り直すということは手間のかかることですし、精算部分は他のシステムとの連携が強く、変えたくないという意向も強い部分だったりします。リプレイスしないとビジネスに支障が出てしまったり、生き残っていけないという状況になって始めてリプレイスという案が出てくると思いますし、柔軟にお客様にとって必要なものを提供できればと思っています。 ―― いわゆるSaaSプロダクトというと、購入（導入）したらそのまま利用開始できるイメージがあったのですが、webコネクトはそうではないですよね。お客様がwebコネクトを利用できるようになるまでの流れはどういったものでしょうか？ 導入のパターンも色々ありますが、もともと自社でオンライン販売のシステムを持っていて、そのシステムの検索部分をwebコネクトに置き換えるという場合、下記のような流れになります。 受託開発であれば、お客様が用意したサーバー（フォルシアが用意するケースもありますが）にソースコードを置いて納品し運用となりますが、SaaSプロダクトであるwebコネクトの場合、リリースのタイミングや機能拡張の方針はフォルシアが決めます。あくまでも、フォルシアのサービスを提供するというスタイルです。 ただ、webコネクトはSaaSプロダクトですが、各社の現状持っているアセットを活用できる仕組みになっています。固有の要件や精算データの連携など、各社ごとのシステム連携が必要な部分に関してはなるべく柔軟に対応できるようになっています。導入いただいたお客様全員に同じものを提供するのではなく、一顧客一顧客が必要な機能を選択することができます。そのためお客様ごとにコンテナでシステムを隔離する構成を取っています。 ―― それでは、 webコネクトのシステム上の強みや、フォルシアだからこそといった点はどのようなところでしょうか？ フォルシア独自の検索技術基盤「Spook」※１ を用いたシステム開発をしてきた時代から培ってきた、大量のデータを高速に検索するという技術はwebコネクトにも生きています。旅行業特有の複雑な料金計算などのロジックを実装し、速度とトレードオフになりがちなところも犠牲にせずにしっかりとどちらも実装するというところがフォルシアだからこそ実現できた強みです。 また、お客様のビジネスを理解することと、SaaSプロダクトでありながらお客様の要望を聞き出し、実現できる方法を提案していくという点は大事にしています。 ※１　検索技術基盤Spookについてはこちらの記事をご覧ください♪ 「Spookって何ですか？」第一弾：そもそも編 「Spookって何ですか？」第二弾：強み編 「Spookって何ですか？」第三弾：導入先＆未来編 フォルシア初のSaaSプロダクト開発  ―― 冒頭にも話にあがりましたが、フォルシアはもともと検索技術基盤「Spook」を用いての受託開発スタイルでしたが、自社でSaaSプロダクトをつくるに至った背景には何があったのでしょうか？ 今までは一顧客一顧客に対して要件定義・設計・開発・テストと対応してきたので、提供できるスピードや規模に限界がありました。 また、今までもノウハウはかなりのレベルで共有されているのですが、受託開発の場合はアプリが違うので開発コストも運用コストもそれぞれにかかるという状況でした。さらに、長年運用していくとアプリケーションが老朽化していき保守性がどんどん下がっていってしまうのですが、リファクタリングや改善などの対応がどうしても裁量だけでは対応し難いという状況にもあったので、個社ごとに開発をしていくのではなく、汎用性のあるSaaSプロダクトをつくっていくに至りました。 エンジニアの働き方の変化とは？ ―― 受託開発からSaaSプロダクト開発へと開発内容が変わり、エンジニアの方々の働き方は変わりましたか？ トータルで関わる人数が増えシステムも大きくなってきたので、情報共有を意識的にやるようになりました。個別最適化しないようにというのも意識して会議体を設計しています。 ―― SaaSプロダクト開発ならではの面白さとはどのようなところでしょうか？ カスタマイズできるところはありつつ共通化されている点です。カスタマイズと共通化は基本的には相反するものだと思いますが、webコネクトではそれがバランスよく同居しているところにおもしろさがあります。特にデータ連携などの部分に関してはかなり作り込みができるようになっています。 ―― SaaSプロダクトであるwebコネクトのプロダクト開発と、Spookという技術基盤を用いての受託開発では、エンジニアに求められる力は異なるのでしょうか？ 抽象化する力が今まで以上に必要になってきていると感じています。 webコネクトにおいては、今までよりもさらに先を見越して設計・開発するスキルが求められるようになったと思います。複数社展開することを見越して設定を外出ししたり、フックポイントを設けたりといった工夫を凝らしています。 例えば、お客様の複数社でそれぞれ要望が挙がっている部分に関して、それぞれが実現させたいことの本質を見極め、フォルシアとしてはそれぞれの実装を行うのではなく、一回で対応できる方法を考えたり、設定の変更だけで複数分対応できるようにしたりといったことを考えています。あまり考えすぎても進まないし、えいやでやり過ぎるとあとで困るという塩梅が難しいと思いますが、しっかりと仕組みを考え、それがはまってうまく展開できると達成感があります。 前編： フォルシアだからこそ実現できた旅行業界向けSaaSプロダクト 「webコネクト」とはどのようなプロダクトなのかに迫ったインタビュー前編、いかがでしたでしょうか？ これまでも コーポレートサイト や FORCIA CUBE（フォルシアのブログ） のなかで『エンジニアもお客様のビジネスを理解し、それに見合った開発内容を提案していく』ということに触れていますが、まさにwebコネクトはその力を結集し、本質を見極め、抽象化してつくられたプロダクトです。 後編では、「webコネクト」の今後の展望についてお届けします。お楽しみに！

pg_catalog をのぞいてみよう 旅行プラットフォーム部エンジニアの吉田です。 本記事では、弊社でメイン DB として使用している PostgreSQL のシステムカタログに関して紹介しようと思います。 ※記事に記載のリンクは 2022/10/31 現在のものとなります。 システムカタログとは システムカタログとは、リレーショナルデータベース管理システムがテーブルや列の情報などのスキーマメタデータと内部的な情報を格納する場所です。 https://www.PostgreSQL.jp/document/14/html/catalogs.html 一般的には informa

こんにちは。経営企画室の伊藤です。 フォルシアでは通年、積極的にキャリア採用を行っており、大手マスメディアや旅行会社、金融業界の出身者など様々なバックグラウンドをもった社員が活躍しています。 今回は、営業職から転身し、2022年５月にwebエンジニアとしてフォルシアに入社した 瑠東 孝佳（るとう・たかよし）さんに、入社して６か月たったいま、どんなことに取り組んでいるのか、業務を行う上でどんなことを工夫しているかなどを教えていただきました。他社を経験したからこその内容となっておりますので、転職活動をお考えの方々の参考になりますと幸いです。 プロフィール webエンジニア　 瑠東 孝佳（るとう・たかよし） 入社年度： 2022年５月　キャリア入社 所属部署： DXプラットフォーム事業部（2022年11月現在） 前職　　： 大手通信キャリアにて営業職に従事   フォルシアの「エンジニア」 瑠東）2022年５月入社の瑠東です。入社して約６ヵ月が経ちました。 今日はいまどんな業務に携わっているのかをお伝えしたいと思います。 突然ですが皆さんはこちらのテキストを見たことはありますでしょうか？ これはフォルシアのコーポレートサイト、 採用情報（仕事紹介＞エンジニア） に載っているフォルシアのエンジニア像を表したものですが、私は入社前に穴が開くほど見つめて、どんなことをしているのか理解を深めようと努めていました。 『顧客の要望を実現し、価値を創り出す「エンジニア」』 『フルスタックエンジニアとして案件の提案、要件定義から、設計、実装、テスト、運用までを一貫して担当します。』 フォルシアのエンジニアが成し遂げたいこと、なすべきことというのはここにまとまっているように思いますが、実際私がいまどういう業務を担当してるのかというと、赤線で囲っている部分となります。 まずは、主に運用・改善（保守運用）をメインで担当し、最近、開発案件にも携わらせていただいています。 いま私が所属している部署は、 DX プラットフォーム事業部という部署で、福利厚生アウトソーシング業界や専門商社・メーカーなどのユーザーサイトの検索機能の開発や、フォルシアの自社プロダクトである データクレンジングツール「Masstery」 の提供、さまざまな旅行サイトのプランを横並びで比較検討できる宿泊施設の横断検索サービスの提供や、 フォルシア内で前例のない新しいビジネスを見つけ、育てる事業 を担っている部署です。 その部署の中でいま私がメインで担当しているのが、宿泊施設の横断検索サービスの提供で、主に保守・運用に関してフロントに立って顧客企業（サイト運営企業）の担当の方とやり取りさせていただいています。また、最近では並行して別のお客様の開発案件にも少しずつ関わり始めています。 エンジニア以外の方にもイメージがわくようにざっくりとした説明になりますが、どんな対応をしているのかというと、基本的に保守対応というのはお客様から運用・保守費をいただいて、月額の保守料金の範囲内でお客様からの修正依頼に対して調査・確認を行い、実際のユーザーサイトに修正内容を反映するといったものです。 例えば、ユーザーサイトの文言（テキスト）の修正だったり、こういったデータは表示させないようにしてくださいといった裏側のデータロジックの修正、お客様側で用意された 入稿データに不備があり ユーザーサイトの表示が意図しない状態になっている場合等には、急ぎで確認・修正といった緊急対応を行うケースもあります。 一方、開発の部分では、例えばログイン情報でパスワードを打ったときに「パスワードは８文字以上に設定してください」といったチェックロジックとアラート表示といったバリデーション対応など、開発経験者の方からすると比較的軽いと思われるものをから少しずつ開発経験を積ませていただいているところです。 営業職からエンジニアへ、仕事をする上で意識していること 担当顧客からの連絡は可能な限り５分以内に一次返信 営業からの転身でエンジニアとしてのキャリアはまだ浅いため、足りない知識に対して勉強していくというのは当然ですが、その他に仕事をする上で意識していることが２点あります。 まず１つ目は、 『担当顧客からの連絡は可能な限り５分以内に一次返信する』 ということです。 例えば上記の例でいうと、顧客企業の担当者の方から、宿泊施設のプラン表示に、ベッド幅のサイズが小数点以下10桁程表示されてしまっているというような連絡がありました。これはまずいと思うものの、取り急ぎすぐには原因がわからないので、まずは「確認します」ということを２分後くらいに返信しています。 とにかく、まずは一次返信するということを心がけております。 というのも、前職での営業経験から、『５分以内に返信するだけで受注率が５%から10%ぐらいまでアップする』ということがあり、なおかつ受注率だけでなく、サービス継続率にも影響が出ていたため、いまもこうして５分以内に返信するということを心がけています。 Googleアラートを活用し、顧客の情報は常に収集 意識していることの２つ目は、 『顧客の情報は常に収集』 ということです。 営業の方だとWBS（ワールドビジネスサテライト）や日経新聞からお客様の情報を得ることもあるかと思いますが、エンジニアとしても、特にフォルシアのエンジニアはお客様とやり取りすることが多いので、お客様の情報は常に収集するようにしています。 これは私の情報収集方法の紹介になるのですが、私は「Googleアラート」という機能を活用しています。キーワードを設定しておくと、定期的にGoogleがそのキーワードをもとに関連する情報を取得して配信するというもので、その機能とSlack（社内で利用しているチャットツール）を連携させて、SlackにGoogleアラートの通知が常に来るようにすることで、最新情報を取得できるようにしています。こうして得られた情報を活用して、打ち合わせ冒頭のアイスブレイクでの話題に出すなど、お客様とのリレーション構築に役立てています。実際にお客様から「そんなことまで知っていただいてるんですね！」と言っていただいたこともありますので、ぜひ皆さんもご活用いただければと思います。 他社を経験したからこそわかるフォルシアの魅力 他社を経験したからこそわかるフォルシアの魅力について紹介します。 エンジニアがお客様と直接商談 １つ目は、エンジニアがITコンサルといったビジネスサイドのメンバーとともにお客様と直接商談するという点です。やはりエンジニアがお客様と直接商談する機会は他の企業ではあまりないことのように思います。エンジニアが直接会話するからこそ、 スピード感のある仕事ができるというのはもちろんですが、エンジニア自身がお客様の生の声を汲み取り、自分でビジネスを組み立てて仕事を進めることができるというのは、他の会社では得られない魅力だと感じています 。 顧客は大手企業、大規模サイトの担当でエンジニアとして成長 ２つ目に、フォルシアのお客様は業界のリーディングカンパニーといった大手企業様が多く、大規模サイトを担当することができるというのは、エンジニアとしては嬉しいことでもあり、成長する機会になるように感じています。 欲しい情報にたどりつきやすい環境 そして３つ目ですが、開発環境が非常に整っているということです。特に社員が率先してesa（社内で利用している情報共有ツール）に情報を載せたり、Slackを有効活用する文化があり、わからない情報に対してたどり着きやすいと感じています。 こういう部分がフォルシアの文化であり、魅力になっているのだと思います。 自分自身の今後の目標としては、まだまだ私は対応できる範囲が広いとは言えないところがありますので、まずはいち早くフルスタックエンジニアとして成長していきたいと思っています。最終的には、中核となるようなエンジニアとして成長できたらと考えております。 新たな一歩を踏み出そうとしている方、さらなる成長を目指す方へ 私は営業職からの転身ですが、フォルシアのエンジニアは顧客と直接商談する機会が多く、前職の経験を活かして働くことができています。 また、エンジニアとしての経歴が浅い私でも開発案件や顧客提案段階から参加することが多々あり、これから開発を更にやっていきたい、フルスタックエンジニアとして成長していきたいという方にはおすすめの職場です。 さらに、お客様により良いものを提供したいという社員の思いから、新しい技術や若手の意見も積極的に取り入れる文化ができており、自身の知識や経験がそのままサービスに反映されることも多く非常にやりがいを感じられると思います。 ぜひエンジニアとして一緒に働けることを楽しみにしております -------------------------------------------------------------------------------------------------------------------- 入社して半年がたった瑠東さんの仕事に対しての取り組み方や想い、他社を経験しているからこそ見えている景色について、いかがでしたでしょうか？ フォルシアのwebエンジニアの仕事内容や、瑠東さん自身の人柄が伝われば幸いです。 フォルシアでは社員とのカジュアル面談を行っています。少しでも興味を持っていただけましたら、ぜひ下記のリンクからエントリーをお願いします♪

サマーインターンシップ企画チームの吉成です。 普段は Web アプリケーションの開発や自然言語処理を応用した各種案件に携わっています。 フォルシアでは、８月・９月に毎年恒例のサマーインターンシップ「FORCIA Summer Internship 2022」を開催しました。 フォルシア５回目のサマーインターンシップ フォルシアのサマーインターンシップもとうとう５回目。 企画・運営メンバーも代替わりしていく中、今年は下記の６コースを実施しました。 ３タームで合計11名の学生の皆さんにご参加いただきました。 どのコースでも「技術力でビジネス課題を解決する」ということの面白さや難しさを体感していただけたのではないかと思います。 ５回目ともなると、運営にあたっても「例年通りに」というところが出てきます。 それで上手くいく部分もありますが、企画・運営メンバーとしてはまだまだ改善できる点も多いと考えており、毎年議論を重ねながらサマーインターンの内容をブラッシュアップしています。 本記事では、FORCIA Summer Internship 2022 の開催内容と、開催にあたっての工夫についてご紹介します。 課題も、課題以外も充実 フォルシアのサマーインターンでは、 フォルシアの業務を体験していただく フォルシアに対する理解を深めていただく という２つの目的を両立させるために、課題の時間以外にも様々なプログラムを用意しています。 一部例を挙げますと、以下のようなものがあります。 キックオフ MTG インターン生とメンター、企画チームメンバーが互いに自己紹介をしたり、５日間のスケジュールを説明する会です。最初にサマーインターンの全体像をお見せすることで、安心して課題に取り掛かっていただけるようにしています。 中間発表会 課題の途中経過を共有し、最終的な目標から方向性がずれていないかを確認したり、課題に関連する業務に携わるエンジニアからコメントを受けたりします。 最終発表会 最終的な成果を社員や他のインターン生に発表し、５日間の集大成とします。 座談会 インターン生１～２名と社員２名の少人数で、仕事のことや就活のこと、余暇の過ごし方など様々なトピックについてざっくばらんに話します。エンジニアだけではなく、ITコンサルタントやバックオフィス担当の社員とも交流の機会があります。 実りある５日間にするための発表会 最終発表会の様子 サマーインターンでは、期間中２回の発表会（中間発表会・最終発表会）を設けています。 ５日間で２回というとやや多く感じられる方もいらっしゃるかと思いますが、それぞれ異なる目的があります。 中間発表会 まず、中間発表会の目的は課題で取り組んでいることについてコメントを受けたり、技術的なディスカッションをすることです。参加者は課題に関連する業務に携わるエンジニアが中心で、最終発表会と比べて小規模です。サマーインターン自体は社屋で開催されますが、この中間発表会は Web ミーティングとして実施し、インターン生も自席から参加します。資料を準備する必要はなく、書いたプログラムや実験結果を画面共有しながら発表することになります。 中間発表会は昨年まで対面での実施で、インターン生、メンターと他１～２名の社員でのみ行っていたものでした。中間発表の目的（技術的なディスカッション）や在宅勤務中心の社員の参加しやすさなどを鑑みて実施方法を Web ミーティングに変更しましたが、実際に次のようなメリットがありました。 参加者数が増え、質問がより活発になる。 他のインターン生の取り組みに興味を持ったインターン生も気軽に中間発表を聴きに行くことができる。 手元での作業内容を画面共有できるので、質問に応じて別のソースコードを見せるなどの柔軟な対応が可能になる。 チャット機能を使うことができる。「Aの手法よりBの手法を選んだのはなぜですか？」などの発表内容についての詳しい議論は互いの意図を確かめながら話せる口頭で、「この機能は便利そう」「目の付け所が良い」など取り組みについての感想は後からも確認できるチャットで、というようなコメント方法の使い分けが可能になる。 最終発表会 一方、金曜日の夕方に行われる最終発表会の目的は、５日間の成果をフォルシア社員や他のインターン生に知ってもらうことです。 インターン生の皆さんには発表資料やデモなどをご準備いただき、期間中の取り組みを整理して発表していただきます。以前は１つの会議室にインターン生とメンター、聴衆が一堂に介して盛り上がっていた最終発表会ですが、感染症対策が必須の情勢となってからはオンラインとオフラインを併用しています。オフラインでも聴講や質問ができるようにすることで、『密』を避けつつもより多くの社員が参加できるようにしています。 オンライン・オフライン併用の最終発表会の様子は 去年 ・ 一昨年 の記事にも掲載していますので、併せてご覧ください。 異なる目的の2つの報告会を設けることで、メリハリの利いた、技術的にも就活的にも実りある5日間を過ごしていただけるようにしています。 情勢に合わせた交流の機会 サマーインターンシップで技術課題や課題のサポート体制と同じくらいに重要なのが、インターン生と社員の間の交流を通して互いへの理解を深めること。しかし新型コロナウィルス感染症の流行により、従来と同じ形での交流は難しくなっています。 そこで、フォルシアのサマーインターンシップでは下記のような対応を実施しました。 社員とインターン生が外のお店でご飯を食べながら話すランチの時間を、お弁当を食べる時間と社員との座談会の時間に分割 飲食ありの懇親会を実施しない代わりに、マスクや消毒等の対策を実施した上でアナログゲームを通して交流する『交流会』を実施（任意参加） 特に座談会については、会議室の予約や参加メンバーの募集はもちろんのこと、その日の参加メンバーや注意事項を共有する bot の運用、話題に迷うとき用のトークテーマの用意など、企画側と参加側双方の心理的負荷が低くなるようにしました。 座談会のメンバーや注意事項をお知らせする Slack bot を運用 来年度以降も、交流の機会は情勢に合わせて柔軟に検討していこうと考えています。 若手メンバー主体で企画・運営 サマーインターンシップも５年目ということで、企画・運営メンバーは１年目のころと比較するとほぼ総入れ替え状態。１～３年目あたりまでは良くも悪くも情熱ある一部の社員に属人化していたサマーインターン関連のタスクも、今は企画・運営メンバーで議論・分担しながらやっていく体制ができつつあります。 特に今年は新卒入社１年目のメンバーが目覚ましい活躍をしていました。 ここまでに紹介したWebミーティングによる中間発表、座談会 bot 運用やトークテーマの用意といった工夫は新卒１年目のメンバーが主体的に考え、実行したものです。このようにフォルシアでは、若手が主体となって社内外の企画を進めていく文化があります。 もちろんベテランメンバーからのサポートも強力です。 今回のサマーインターンシップでも、開発環境の準備やスケジューリングといった開催に必須のタスクが漏れないよう、第１回からサマーインターンシップに関わっている先輩エンジニアが他部署と綿密に連携を取ってくれました。サマーインターンシップに限らず、若手メンバーや情熱を持ったメンバーから始まった企画が、他の社員の協力を得て全社に影響を及ぼすようになる光景はよく見られます。 おわりに 本記事では、例年のサマーインターンシップ報告記事とは少し趣向を変え、企画側としてサマーインターンの舞台裏を紹介させていただきました。 最後になってしまいましたが、サマーインターンシップに参加してくださった皆さん、本当にありがとうございました。 皆さんのサマーインターンシップの期間が終わった後も「５日間と言わずずっといてほしかった」「あのコースの人がやっていた方法は他の案件に生かせるのでは？」などの声が社内から聞こえてきていました。 フォルシアでの経験が、今後の皆さんの研究や就職活用などに少しでも活きれば幸いです。 この記事を読んでくださった学生の方で「フォルシアのサマーインターン、面白そう！」と思ってくださった方は、ぜひ来年度以降のサマーインターンにご応募ください。そしてフォルシアの業務のやりがいや社風などを体感していただければと思います。 サマーインターン参加者の方が書いてくださった参加記も参考になります。 FORCIA社 の Summer Internship 2022 に参加しました フォルシア サマーインターン 自然言語処理コースに参加しました また、エンジニアとして裁量を持って働きたいと思う方、主体的に業務を回していけるエンジニアを目指す方は、ぜひフォルシアの新卒採用・キャリア採用への応募をご検討ください。 今回のサマーインターンに参加された方もそうでない方も、ご興味をお持ちでしたら 採用情報ページ   をご覧の上、採用応募フォームまたは採用お問い合わせフォームからお問い合わせください。 将来、同僚として皆さんと働ける日を楽しみにしています。

はじめに こんにちは。フォルシア株式会社エンジニアの谷井です。 フォルシアでは、ソースコード管理にGitLabを使用してチーム開発を行っていますが、その中で「あるブランチに入る変更を、自動で別のブランチに取り込みたい」という状況が時折発生します。 例えば、 「大型新機能開発のためのブランチを切って開発を行うが、その間も本流のmasterブランチには通常開発の変更が入る」 「検証環境反映用のブランチにだけ入れておきたい機能があるが、それ以外は本番環境用のブランチと同じ状態にしておきたい」 というようなケースです。 あとでまとめて取り込もうとすると大量のコンフリクトと格闘することにな

Prettier の代替として Rome 触ってみた はじめに こんにちは、旅行 PF 部エンジニアの奥田です。 この記事では、Prettier の 10 倍速いと言われるRomeを触っていきます。 ここまで圧倒的な速度を喧伝されては気になるのは人の性…さっそく触っていきます！ Rome とは フロントエンド開発のツールチェインを 1 つに統一することを目指しているプロジェクトです。 Babel,ESLint,webpack,Prettier,Jest などのツールを置き換えることを目的にしています。 速度もそうですが、昔 ESLint や webpack・Prettier

はじめに こんにちは。入社2年目DXPF部エンジニアの竹下です。 いまエンジニアと名乗りましたが、私は2021年4月に総合職としてフォルシアに新卒入社し、つい4か月ほど前までは営業担当として業務を行っていました。 フォルシアでも前例のない営業からエンジニアへの転向を経験した私が、入社してからエンジニアへ転向するまでの経緯をお話しさせていただきます。 就職活動で職種の選択に迷っている方や、エンジニアに興味のある方にとって何か参考になる部分があれば幸いです。 総合職志望で進めた就職活動 大学時代、サークルの先輩が作成したサークルのHPを見たことをきっかけにプログラミングに興味を持ち、

はじめに こんにちは。 フォルシア株式会社エンジニアの籏野です。 この度新規アプリを構築するにあたって、認証を通してからアプリにアクセスできるようにする必要が出てきました。 認証アプリにはKeycloakを利用し、Kubernetes(EKS)上にアプリをデプロイしています。 Kubernetes上にKeycloakアプリをデプロイするにあたり対応した内容を紹介したいと思います。 前準備 データベースの用意 Keycloakを利用するには、ユーザー情報等を保持しておくためのDBを用意する必要があります。 今回はAWSのマネージドサービスを利用できるため、CloudFormat

こんにちは。広報の見原です。今回の記事は、フォルシアが大切にしている「脱・人月」という考え方についてのお話です。 人月って何？ 「人月」という言葉。建築系・IT系のお仕事に関わられていればご存じの方も多いかと思いますが、それ以外の業界や職種に就かれている方、学生の方には馴染みの薄い言葉だと思います。 人月とは、業務の工数を測る際に使う作業量（工数）を表す単位です。たとえば、5人で6ヵ月かかる仕事であれば、「5×6＝30」で「30人月」ということになります。 また、「Aさんは一か月あたり100万円」というように労働者の商売単価を時間で測ったものが人月単価となり、人月とかけて費用を見積もったり、請求したりします。古くから、土木・建築業界で利用される一方、比較的新しいとされるIT業界でも多く活用されている尺度です。 フォルシアの価値は人月では測れない？ IT業界に身を置いているフォルシアも例外ではなく、お客様のWebサイトの開発を行う際の費用算定に人月を使うことが多々あります。 しかし、フォルシアの開発スタイルは完全な受託ではありません。汎用的な技術基盤があり、それを活用してお客様からの要望に適った開発を行います。そのため、「Aさんが一人で3か月かけて開発したから300万円」というような単純計算がしづらいのです。 創業者の一人であるCOOの屋代（以下、COO）は自身もエンジニアであったことから、この人月の考え方はフォルシアのビジネスにはマッチしにくいと考えました。開発スタイルの問題だけではありません。 人月ではエンジニアが生み出したものに対する適正な価値がわかりにくいため、エンジニアに自身の価値を認めながら生き生きと働いてほしいと願うCOOにとってはもどかしさを感じる指標でした。 「フォルシアのエンジニアが提供する価値を正確に測れるようにするにはどうしたら良いのか」。 創業時からずっと「脱・人月」の思いと向き合い続けているCOOに話を聞きました。 COO屋代哲郎インタビュー 「脱・人月」の構想は前職外資系金融時代の経験が元 ー 日本のIT業界では長年費用算定に人月を使うことが一般的とされており、フォルシアでも使用しています。COOが「脱・人月」の考えをもつきっかけとなった出来事を教えてください。 21年前にフォルシアを起業してIT系の仕事を始めて、ITの世界では「人月」という尺度が一般的に使われているということを知り、驚くと同時に違和感を覚えました。前職での評価軸とはまったく異なっていたからです。外資系金融時代は成果主義が考え方の中心で、問われるのはあくまでも「成果」としての「稼いだ収益」。「時間」が尺度になることはありませんでした。なぜかというと、「成果」を「収益」として定量化しやすい指標として測ることができたから。なので、成果をあげている＝たくさん稼いでいる社員は、極端な話、始業時間にオフィスにいなくとも、はたまた終業時間前にオフィスからいなくなっていようとも、それを咎める様な考え方はありませんでした。 ー 「成果」が評価される世界にいたら、「時間」が尺度になるのは「違う」と感じると思います。特に違和感を覚えたポイントはどこですか？ お客様から「何日でいくらですか？」と初めて人月での見積もりを求められたときには戸惑いました。本来的に問われるべきなのは、「かけた時間」ではなく、「製作したソフトウェアの品質」ではないのかと考えていたからです。ソフトウェアのような「無形商材」を作る場合において、「かけた時間」というのはどのような意味をもつのか。「〇時間作業しました」と言っても、それがどれくらいの成果につながったのかの尺度として正しいのかは疑問が残ります。 ー COOの前職である金融もITも成果物が「無形商材」という点は同じですね。一方で、ITの世界で製作したソフトウェアやプログラムの出来を見て、客観的に品質の価値を測ることも難しいように感じます。開発する側はどのような点を意識すべきでしょうか？ 納品時にお客様の要求仕様を同じように満たしたプログラムでも、保守性・耐障害性・拡張性などの観点での大きな差異が発生することがあります。ただそれは、表面的にはわからないことが多いのも事実です。特に、ソフトウェアの世界においては「将来起こりうることをあらかじめ予見したコードを書くことができる」かどうかが非常に重要です。たとえば今は一見無駄だと思われるようなコードでも、それが将来役に立つときが来ることを予見して書かれたのであれば非常に価値は高い。そういった価値の創出が積み重なってお客様との信頼関係は構築されていきます。 エンジニアにおける「属人性」は必ずしも悪ではない ー 「無形商材」だからこそ、表面的にはわからない価値を生み出すことは他社との差別化につながりますね。ただ、そういった価値を創出できるかどうかは、個々のエンジニアの経験や力量による部分が大きいかと思いますが、開発の上で属人性が発生することは問題ないのでしょうか？ 教科書的には「属人性」は排除されるべきであるということが言われますが、それはあくまでも「顧客」もしくは「経営者」「管理者」の立場から言えること。長く第一線のエンジニアとして仕事をしてきた身からすると、「やりがい」は「属人性」から派生することが多いということも感じています。上述したような「将来的な拡張性のことまで考えて一見無駄だと思われるコードをあえて書く」行為、あるいは「このコードは自分にしか書けない」と思える瞬間は、エンジニアにとって一番面白く、快感や達成感があるものなのです。 私自身のエンジニアとしてのキャリアにおいても、「自分にしかできない」コードを書くことこそが仕事の原動力となり、エネルギーとなってきたと言うことが出来ます。一方で属人的なコードを書いてしまうと、将来的な保守性や拡張性の制約となってしまうことも事実です。単純な二元論に陥ることなく、バランスを取ることがソフトウエアの世界でビジネスを進めるうえで大切なことだと考えています。 ー エンジニアのやりがいを感じる瞬間は必ずしも第三者からの評価と直結しているわけではないのですね。現時点では、IT業界における最も優れた指標は人月なのでしょうか？ 顧客や株主等、いわば「社外の第三者」に対して、その「成果の客観的な尺度」を示す必要があるという意味では、人月を使うことには妥当性があります。あるいは、現時点において人月以上に「一般的に公正妥当と認められる」尺度は存在していないと言っても過言ではありません。世の中のビジネスの仕組みは人月でまわっているので、やむなくそれをせざるをえないことは現実問題としてあります。しかし、それは必ずしも「最善」というわけではありません。私はフォルシアのポリシーとして「脱・人月」を持っていますし、それを堅持していく姿勢こそが大事だと思っています。 「脱・人月」の考えは社内評価にも ー COOが考える「脱・人月」の思いは社員に十分浸透していると思いますか？ 折に触れて、伝えてはいます。さりとて、社員もそれぞれ様々な思いをもって、仕事をして社会生活を営んでいるはずですので、私の考えを一律で強制するつもりはありません。ただ、社員の重要な評価指標として用いている「3Cレビュー（以下、3C）」の考え方は「脱・人月」の思いを具現化したものであると考えています（参考： フォルシア評価制度 ）。 ー フォルシア独自の評価制度3Cでは、一般的な360度評価では補いきれない、全社員（全方向）からの評価を総合的に判断して最終的な評価を行います。定量的な面だけでなく、定性的な面も見ることができるという点は、COOの理想の評価指標と言えるのでしょうか？ そうですね。「客観性」や「妥当性」は大切ではあるものの、定量的な指標に過度に依存してしまうと、本来は成果を公正に測る為の指標であるべきなのに、「その指標を効率良く改善する為にどうするか」という本末転倒な方法論に陥ってしまう危険性があります。実際、3Cを導入したときに、定量的な指標を入れた方が良いという意見があり、試してみたことがあります。 しかし、エンジニアの定量的な指標としてはコミットの数とか書いたプログラムの行数くらいしか思いつきませんでした。ならば、売上金額であれば成り立つのでは？と思いますが、そうでもない。たとえば、たまたま売上金額としてはそこまで大きくない案件にアサインされたけれども、本人はすごい仕事をしていたり、その逆のことが起こったりして･･･。結局納得のいく結果は出ませんでしたね。長時間働けば良いわけでも、たくさん売り上げをあげれば良いわけでもなく、では何をしたら評価されるのか、という点を追求していくことが目的に近いところにあります。その点で、3Cは「定性指標」と「定量指標」を適度にバランスさせることによって上手く成り立っていると言えます。 フォルシア独自の評価制度3C 「〇〇が言うならそうだよね」と相手を納得させるビジネスセンス ー 定量的な指標はわかりやすいと思うのですが、定性的な指標という点で言うと、評価される側はどのように価値を創出したら良いですか？ これは社内の評価制度である3Cにおいても、対外的なビジネスにおいても同様だと思うのですが、「フォルシア（or 社員名）が言うならたしかにそうだよね」と顧客や相手が納得してくれる状態が理想です。 会社自体や本人自身に説得力が付帯する魅力がないと、「なぜこの値段なの？」と聞かれたときに「これ作るの大変だったんですよ」という説明になってしまい、結局人月で価値を測るしかありません。3Cの考え方であれば、普段のその人の働きや振る舞いを相対的に見ることができるので、「〇〇が言うならそうだよね」が通用しやすい。3Cがワークしているのは、社内評価というドメスティックな環境での方法だからであって、「対外的な尺度」として取り扱う事には無理があります。対外的にも、理由を言わずとも「フォルシアが言っているのであればこれだけの価値がある」と納得してもらえるような状態を目指すために試行錯誤していきたいですね。 ー お客様にとっては成果がすべてですからね。お客様に「フォルシアが言うならそうだよね」と思ってもらえるために、具体的に私たちが今できることは何ですか？ 「ビジネスセンスを磨く」の一言に尽きます。お客様が何に価値を感じるかを提供する側が知っているということが非常に大事です。お客様に言われたことを「はい、仰るとおりです」と言いながら作るのでは大きな価値を生み出すことはできません。ビジネスセンスがある人は「これを作ったらきっとお客様のビジネスに役立つし、喜んでくれる」という 肝 をわかっている。それを実際にお客様へ提供したときに喜んでもらえることが嬉しいし、仕事をしていて楽しい瞬間でもあります。 関係者みんなが幸せな状態を実現するために ー お客様が何に価値を感じるのかを理屈ではなく感覚でわかるようになるということですね。ビジネスセンスが研ぎ澄まされた社員が増えていったら最強な会社になりそうです！COOは、今後フォルシアをどのような会社にしていきたいですか？ どのような会社にしたいかという具体的な姿はまだ見えていません。ただ、働いている人たちみんなが楽しく仕事をして、お客様や株主も喜んで･･･という形を実現するためにどうするかというのを考えるべきだとは常々思っています。そのバランスが崩れてしまうことは良くありません。バランスを保つ手段として人月という評価指標やそうでない指標を活用して試行錯誤しているところなのです。ここには簡単な解決策はない、という前提で関係者みんなで模索し続けていくことが大切なことだと思っています。 全社会議の様子 以上、20年以上「脱・人月」と向き合い続けてきたCOO屋代の思いをご紹介しました。 ここからは、COOの「脱・人月」の考えをもとに現場で働くエンジニア社員Kさんに話を聞きます。Kさんは前職の大手SIerで「THE 人月ビジネス」を経験してきました。エンジニアの立場から見て、働く上での違いはあるのでしょうか？ フォルシア エンジニア社員Kさんの声 市場から求められるようなサービスを自分の裁量で作り出せる ー 前職では人月ビジネスを経験されましたか？ 前の会社は大手SIerで、請負契約の仕事、準委任契約の仕事どちらもありました。人月型というのかはわかりませんが、どちらの場合も人月が見積もりの際の大きな根拠となっていたことは確かです。 私はずっと準委任契約のプロジェクトに属していたので、一人当たり1か月〇〇円での労働力提供というような人月ビジネスそのものを経験しました。 ー 仕事のやりがいはどのような部分で感じられていましたか？ お客様が実現したい機能がたくさんあり、それらに対してスピード感をもって開発を進めていくことを常に意識していました。その結果、お客様に喜んでいただけたので、充実感がありました。また、数十人規模でチームを組んでいて売上額も大きかったので、部の稼ぎ頭チームとしてのやりがいもありました。 ー フォルシアは「脱・人月」をポリシーとしていることを知った上で入社されたのでしょうか？ 入社前には大きく意識していませんでした。ただ、前職の仕事では作成するシステムはソースコード含め納品して顧客の所有物ということになるのが一般的でしたが、フォルシアの技術基盤であるSpookはソースコード自体はあくまでフォルシアが資産として所有していて、その利用料としてライセンス料をいただくというビジネスモデルなので、その点に魅力は感じました。そういったビジネスモデルの紹介から、フォルシアが「エンジニアの時間を売る」のではなく、成果物のバリューで勝負できていることは潜在的に感じていたように思います。 ー フォルシアでの「脱・人月」の考え方において、良いと感じる点や難しく感じる点はどこですか？ 人月はサービスや製品の価格の根拠として、見積もりを提示されるお客さんとしても納得しやすい便利なツールではあると思っています。「脱・人月」となるとそれは根拠として提示できないため、説得力のある魅力的な製品・サービスを作り続ける必要があり、その部分は難しいと思います。 一方、 市場から求められるような素晴らしいサービスを自分の裁量で作り出せる舞台であるともいえるので、エンジニアとしての達成感ややりがいは十分にある環境だと日々実感しています。 さいごに 今回は、フォルシアで「脱・人月」の思いと向き合い続けるCOOと、その思いを受けてビジネスを推進しているエンジニア社員Kさんの声を紹介しました。 人月は長年ITの世界で使われている指標なので理にかなっていると言えます。すなわち、現在のIT業界においては、人月でないと開発したサービスの価値を測るのは難しい。 それでもフォルシアは、エンジニアに自身の価値を見出してより仕事のやりがいを実感してもらうために、そしてそれをより良いサービス・プロダクトを創り出す活力とするために、何をどうしたら良いのかを追求し、挑戦し続けます。 もっと詳しく話を聞いてみたいという方、フォルシアではカジュアル面談を随時受け付けています。ぜひお気軽に下記のリンクからエントリーをお願いします！

こんにちは。経営企画室の伊藤です。 昨日の 「フォルシアエンジニアの魅力編」 に引き続き、2019年に新卒で入社し、エンジニアのユニットリーダーとしてはもちろん、広報活動や経営者とともに会社課題を検討するチームでも活躍する webエンジニアの谷井 嶺太（たにい・りょうた）さんのインタビューをご紹介します。 （※所属、業務内容は取材時点の内容となります。） 本日は後編「４年目エンジニアの価値観編」です。それではさっそく伺っていきます！ ３年目、大規模な開発案件で開発リーダーに！ 谷井さんは昨年、年間MVP ※１ も受賞されたとのことでしたが... これまでの仕事の中で一番やりがいのあった仕事はどのようなものでしょうか？ 昨年度（2021年度）に行ったJRダイナミックパッケージ販売機能の開発です。 複雑なドメイン知識を要求されるJRの空席照会・予約システムとの結合がある開発で、顧客（旅行会社様）ごとに地域など扱う商品特性に差があり、汎用的な設計を要求されました。約一年間という実装期間、さらには、webコネクトでも初となる大型機能の３社同時リリースという社内では比較的大きな規模の開発案件でした。 ３社同時とのことでしたが、同じ機能を３社に提供したわけではなかったのですか？ フォルシアが新機能を開発していくときの多くのパターンとして、クライアントドリブンでお客様へのヒアリングをもとに進めていきます。このJRダイナミックパッケージ販売機能を開発するにあたってもニーズを紐解きながらの作業になるのですが、１つの小機能を開発するのに３社分の要望が出てきます。JR様と初期開発時の顧客である３社の旅行会社様との間の契約もぞれぞれまったく異なっており、どこまで開発すれば汎用的な機能として成り立たせられるのかという点が未知数でした。 当時はわからないことだらけだったので、お客様から必要と言われれば全部作るしかないような状態だったり、対面にいるお客様も必ずしもシステムの専門家というわけではないので、お互いが理解している範囲に差があり、なかなか要望の全体像を一発で引き出せずに、五月雨に要望をキャッチアップしていくことになってしまうという――そういう難しさが３社同時並行で発生していました。 フォルシアの開発スタイルはウォーターフォールではなくいわゆるアジャイル開発のため、設計→実装→ヒアリングを相当数繰り返し、次々に出てくるチャレンジングな仕様に対して試行錯誤しながら乗り越えていく過程は、タフで難しくもあり、おもしろかったです。 この案件では、コーディングや要件整理だけでなく、開発リーダーとしてチームメンバーのオンボーディングやタスク管理・アサインなど、より幅広い業務にあたることになったのも印象的でした。業務を分解し、なるべく完結していて切り出しやすいタスクにしてメンバーに渡したり、こまめにドメイン知識の補足を入れたり、どういう状態になっていることが望ましいかの完了条件を言語化することも工夫しながら進めていきました。 ※１　「MVP」 社内表彰制度における、年度内最も活躍した社員としての表彰 MVPへの推薦コメントを拝見しても、やはりこの案件での目覚ましい活躍が伺えました。続いては開発業務以外の面について聞いていきます。 幅広い知見をキャッチアップできる社内の横串組織 谷井さんはエンジニアとしての幅広い活躍だけでなく、社内の横串組織（部門横断型のワーキンググループ）にも積極的に参加されていると聞きましたが... 開発業務以外では、３つの横串組織に参加しています。 まず、３つの中で一番長く携わっているのが「技術広報チーム」※２ です。フォルシアのエンジニアとして大切な「訴求力のある伝え方」に興味があり、約三年前に発足したチームに立ち上げ当初から参加しています。２つ目は、「postgresタスクフォース」。タスクフォースは、エンジニア有志が参加し、特定の技術領域に関する活動を行うものなのですが、これまでの業務で相対的に訓練する機会が少なかったpostgresの知識を身に着けるため参加しました。そして３つ目は異色な活動なのですが、今年度から始まった「sense５」※３ という経営者と会社課題について考えていくチームにお声がけいただいて、社長やCOOと直接議論できる貴重な機会だと感じて参加しています。 ※２　「技術広報」の活動についてはこちらの記事もご覧ください　＜ こちら ＞ ※３　「sense５」の発足のきっかけなどはこちらの記事もご覧ください　＜ こちら ＞ 先ほどの、技術もビジネスもどちらも関わっていきたいということと同じで、なるべく幅広い視野をもっていたいという想いがあります。フォルシアのエンジニアは通常の業務においても広い領域に携わっていますが、均等に習熟できるわけではありませんし、プロジェクトやチームの状況などによっても異なります。横串組織に参加することで、関われる領域を主体的に選んで、幅広いキャッチアップができるように色々やってみたいと思っています。 思い返すと大学１年生の最初の頃は、サークルに３つくらい入っていたんです。それも、色々やってみて本当におもしろいと思ったものを続けようと思って、そういった身の置き方をしていましたね。 これらの横串組織の活動全部が開発業務に直接的に還元されているかといったら、そうでないことも多いですが、目の前の業務に活きることだけをやっていても幅は広がっていかないので、あえて飛び石になっているような部分にも参加して、それらが業務に繋がれば儲けものだし、繋がらなかったとしてもそれはそれで良いかな、くらいに捉えています。 例えば、いま参加しているものの中で「sense５」は開発業務とは離れたものではありますが、活動のコンセプトは自分がやってみたいと思っていたことのひとつでもあります。元々大学４年の時に部活の主将をやっていたのですが、組織を良くするためにどうしたらよいかというのを色々な観点から考えて実行していくプロセスにおもしろさを感じていて、就職活動の際にもコンサルティング業界に興味を持っていました。「sense５」の活動を通じてもっとこうしたら組織として良くなるのではないかということは引き続きやっていきたいと思います。 就職活動のお話も出ましたので、当時のことを深堀させてください。 大切にしたのは「納得感」、「誠実さ」 就職活動ではどのような会社を見られていたのですか？ 戦略/ITコンサル、総合商社、金融系、ITベンチャーなど幅広く見ていました。エンジニアとして働くかどうかも含め、仕事内容そのものにはあまりこだわりがなく、働き方や価値観が合う場所を探していました。フォルシアに応募した時もエンジニアか営業か、職種は決めずに応募しました。とにかく納得感を持って仕事に臨みたいという想いが強かったです。 私の価値判断の基準の原体験はだいたい大学の部活なんですが、「これだ！」って思って決めて、自分の中で考えに考え抜いて納得したことに関してはとても馬力が出て頑張れるんです。ただ、人に言われただけとか、納得いっていないこと、筋が通っていないことはなかなかできない。 あとは、「誠実さ」という点も重視していました。自分が部活で主将をやっていたとき、「熱意」と「誠意」というのをキーワードにしていて、自分自身が熱を持って取り組むということと、そうやって熱を持って取り組んでいる仲間や自分自身に対して、きちんと誠意を持って向き合う、ずるいことをしないで向き合うということを大切にしていました。就職先においても、ずるしてお金だけ儲けられればいいや、自分が成長できればいいやという考え方ではなく、誠実な人がいる場所、誠実な働き方ができる場所で働きたいと思っていました。 フォルシアは谷井さん基準の「納得感」・「誠実さ」に合致したということですね。 フォルシアのことは、ベンチャー企業を中心に紹介してくださるエージェント経由で知りました。社長やCOOが語られている内容は自分の中ですごく誠実だと思えたし、その考え方に対して頑張ることができそうだなと感じました。また、一概に納得いかないことはやりたくないという訳では決してなく、正しくないと感じたときに相談・議論できるような土壌があることが大事だと思っていて、自分が就職活動で見た中ではフォルシアが一番そこが担保されているように感じたということも大きかったです。 就職活動の選考過程で、（わがままを言って）たくさんの社員の方と面談させていただいたのですが、落ち着いていて理知的で魅力のある方ばかりで、それぞれ自分の言葉でフォルシアの仕事のおもしろさを語ってくださったことは印象的でした。 最後までどこに行くか迷って内定承諾期間を延ばしてほしいと依頼した自分に対して、人事部長の外山さんが「谷井さんの納得がいくまでお付き合いしますよ」と言ってくださったこともよく覚えています。 自分自身に誠実に向き合い、納得感を大切に進む谷井さんに、これからの姿についても聞いてみました。 webコネクトをSaaSプロダクトとして確立する 今後取り組んでいきたいこととは？ webコネクトをSaaSプロダクトとして確立することです。 従来フォルシアは受託開発でのビジネスが主流でしたので、SaaSプロダクトとしての開発フローのノウハウがまだ確立していません。実装面でも、チーム運営の面でも、仕様調整・お客様とのコミュニケーションの面でも改善の余地がまだまだたくさんあると感じています。 これまでは、webコネクトの機能もクライアントドリブンで開発が進み、お客様と一緒に機能をつくってきましたが、そのスタイルはプロダクトが大きくなればなるほど難しくなっていきます。受託開発では、ある意味シンプルにお客様の要望にきっちり寄り添っていけば、いつしか信頼に繋がっていくと思うのですが、SaaSプロダクトの場合はお客様からの要望に対して線引きをせざるを得ないケースも出てきます。そういう状況下でもお客様とフェアネスを築き、信頼を勝ち得ていくことがこれから必要になってくると感じています。 お客様に「SaaSプロダクトとしてのwebコネクトを使っていて良かった」と感じてもらえるように、SaaSプロダクトであることの利点をもっと還元できるようにしていきたいと思っています 。   エンジニア × α で価値を発揮させる 谷井さん個人としての目指したい姿とは？ 正直な話すごく悩んでいます。自分は生粋のエンジニアではないと思っていて、単純に手を早く動かして素早くつくるとか、綺麗にわかりやすくつくるという点においては、自分じゃ一生敵わないだろうなと感じる方が社内にもたくさんいます。そこで、何かもっと掛け合わせで、コーディングだけじゃなくこれもできます――というところで価値を発揮していきたいと思っています。ただ、その「何か」が果たして何なのか...それもある意味何でもいいと思っていて、結果的に自分が最大のパフォーマンスを発揮できることが大切なので、「これだったら誰にも負けないぜ」というような領域を見つけていきたいと思っています。 最後に、未来の仲間へメッセージをお願いします！ フォルシアに入って４年目になりますが、何をどう作るかの意思決定に携われる環境、幅広い技術領域に自ら関われる横串組織、手厚い福利厚生や柔軟な働き方、社員の自律性を尊重した制度、気軽に質問できるフラットな文化など、エンジニアとして働くにあたってここを超える環境はそうそうないと感じています。 経験の有無を問わず、新しいことに主体的に取り組める方にはもってこいの会社だと思います。一緒に働けることを楽しみにしています。 プロフィール webエンジニア 谷井 嶺太（たにい・りょうた） 入社年度： 2019年新卒入社 所属部署： 旅行プラットフォーム事業部 旅行第5グループ オフの過ごし方： 睡眠・ゲーム・躰道 自分を漢字一文字で表すと...「 整 」 ゼロから何かを創り出すよりも、既にあるものを整える方が得意です。 フォルシアを漢字一文字で表すと...「 信 」 社員一人一人にプロとしての誇りを持つことを求めつつ、信頼して尊重している会社だと思います。   インタビュー後記 フォルシアのエンジニアらしさが詰まった前編の「フォルシアエンジニアの魅力編」、そして谷井さん自身の想いが詰まった今回の後編「４年目エンジニアの価値観編」、いかがでしたでしょうか？ フォルシアのwebエンジニアの仕事内容や、谷井さん自身の人柄が伝われば幸いです。 フォルシアでは社員とのカジュアル面談を行っています。少しでも興味を持っていただけましたら、ぜひ下記のリンクからエントリーをお願いします♪

こんにちは。経営企画室の伊藤です。 フォルシアでは通年、積極的にキャリア採用を行っており、大手マスメディアや旅行会社、金融業界の出身者など様々なバックグラウンドをもった社員が活躍しています。 今回は2019年に新卒で入社し、エンジニアのユニットリーダーとしてはもちろん、広報活動や経営者とともに会社課題を検討するチームでも活躍する webエンジニアの谷井 嶺太（たにい・りょうた）さんのインタビューを前後編でご紹介します。 （※所属、業務内容は取材時点の内容となります。） まずは前編「フォルシアエンジニアの魅力編」です。 技術力 × お客様とのコミュニケーション で価値を発揮 谷井さんの現在のお仕事内容を教えてください。 フォルシアのSaaSプロダクトである 「旅行・観光業界向け商品販売プラットフォームサービス『webコネクト』」 の開発に携わっています。 webコネクトの社内の開発体制は、大きく分けて２つのコンセプトでチームが編成されています。１つは、中長期的にプロダクトラインナップを拡充していくチームで、もう１つは、既にwebコネクトを導入いただいたお客様からの要望をもとに、その実装可否を検討し、お客様とコミュニケーションをとりながら開発を進めていくチームです。もちろん綺麗に二分されているわけではなく、都度ケースによって対応するチームを検討する場合もありますが、大きく分けるとこの２つのチームがあり、私は後者のお客様とコミュニケーションをとりながら開発を進めるチームのユニットリーダーをしています。 もちろん前者後者どちらのチームであっても業務のなかで開発業務が占める割合は多いのですが、後者のチームの働き方の特徴として、お客様とコミュニケーションをとる機会が多いのはもちろん、SaaSプロダクトのwebコネクトに実装すべき機能の範囲をしっかりと検討し、見極め、お客様の要望に対してどういった回答を出していくのかをビジネスサイドとともに考えていくというものがあります。 フォルシアにとってSaaSプロダクトをつくっていくのは初めての試みで、プロダクトのつくり方が確立されていないところもあります。 お客様（旅行会社様）から出る要望の多くは技術的には対応可能ですし、言われたことを言われたままに作ることはある意味簡単ではありますが、エンジニアのリソースも有限な中で、SaaSプロダクトとして本当に価値のあるものを作るためには優先される機能を見極める必要があります。お客様のビジネスにどれくらいプラスのインパクトを与えられるのか、開発にどれくらいのコストがかかるかなどを総合的に考え、実装可否の判断やお客様への回答の仕方をITコンサルとともに考え、実際に対応するとなればその開発まで携わります。 エンジニアとは言え、非常にビジネスサイドまで踏み込んだ業務なんですね。ITコンサルとの役割分担はどうなっているのでしょうか。 やはり技術的な観点に関してはエンジニアから意見を出していく必要はあります。 例えば、「この機能は各社ごとのカスタマイズができるレイヤー内で実装が可能かどうか」「この機能を実装することで今後の開発時に考慮すべきコーナーケースが発生しないか」といった観点はエンジニアだからこその部分です。 いわゆる"技術負債"を残さないような設計にするため、実現される機能の価値とは別にシステム全体の美しさを保つための判断もエンジニアが行うべきことです。 また、お客様とのコミュニケーションといった意味では、いわゆる運用保守のような業務もあります。不具合の修正や、設定変更、メンテナンスについてなど...こういった内容はエンジニアが直接お客様と会話して進めていったりもします。 業務の難しさ、おもしろさとは？ 幅広く対応されている中での難しさやおもしろさはどういったところでしょうか？ 難しさも楽しさも色々な場面で感じていますが、わかりやすい例としては実装が綺麗に横展開できた時でしょうか。webコネクトでは原則的に、機能を追加すると複数のお客様で使えるようになります。それを見越して、B社からある機能要望があった際に、「この要望を叶えるだけであればここまでの開発で良いが、似た要望はほかの会社でもありそうだから、横展開のために汎用的に開発しておこう」というような"読み"が上手くはまって追加コストを抑えた横展開ができると、パズルが解けたときのような気持ちの良さがあります。 また、私自身の志向性として、言われたものをただつくるのではなく、自分がつくるものに納得感を持って開発していきたいという想いがありますし、器用貧乏なので一点集中型のエンジニアというタイプでもありません。そこで、コーディングと、ほかにも自分にできることを掛け合わせることで価値を出していきたいと考えています。 いまの働き方は、エンジニアとして技術のこともわかりますし、お客様と直接コミュニケーションをとることもできるので、伝える・つくるといった両面に携われます。技術についての理解・知見からわかりやすく伝えていくことができ、お客様の声を直接聞いていることで要望の意図を汲み取った実装をしていける――そういう両面から価値を発揮できる環境はおもしろいです。 webコネクト とは？ ダイナミックパッケージ型商品におけるリアルタイムな料金計算と高速な一覧表示を実現する旅行・観光業界向けのSaaSプロダクトです。商品のオンライン販売に求められる素材登録（造成）、検索、予約、電子クーポン、外部接続ゲートウェイといった機能群をモジュール化し、顧客ニーズに応じてカスタマイズして必要な範囲で提供することができます。 「webコネクト」を活用することで旅行会社、鉄道会社をはじめとする旅行・観光商品を販売する事業者や素材提供会社は、例えば目的地までの交通手段の予約と、現地での宿泊・レンタカー・アクティビティ等の手配とが一括で済むような仕組みをスムーズかつローコストで導入することができます。 とある日の谷井さんの１日のスケジュール システム全体を俯瞰してつくるためにはチームでの密なコミュニケーションが大切 「チームで開発する」とは？ フォルシアでは「チームで開発する」という表現をよく聞きますが、チームで開発とはどういうことでしょうか？ いろいろな要素があるのですが、一番は実装方針の相談をしあうという側面が大きいですね。一つの機能を実装するにあたって、そのコードの書き方は何通りもの方法があり、やりようによってはいくらでも"読みづらい"書き方や"見通しの悪い"設計もできてしまいます。そんな中で、どういった書き方にすると他の人にとっても編集しやすいかたちになって、システム全体として綺麗なつくりになるかという部分はチームで相談しながら進めていきます。 例を挙げますね。 webコネクトでは「マイクロサービスアーキテクチャ」という戦略をとっていて、システム全体として１個の大きいアプリというわけではなく、いくつものアプリをつくって、それぞれに役割分担をさせて成り立っています。これによって、それぞれのシステム同士はお互いに絡み合わないようにして、機能に関わる修正範囲をなるべく限定的にできるというメリットがあります。 具体的には、宿泊施設、航空素材、列車素材といった商材ごとのアプリと、画面描画や料金計算などの商材を跨いだ機能ごとのアプリで構成されています。 従って、新しい機能や処理を追加する場合には、どのアプリで処理を行うべきかを判断する必要があります。 こういった判断は様々な粒度で必要になり、多くは絶対的な正解がありません。システム全体でのメンテナビリティやパフォーマンスを総合的に考えながら、チームでコンセンサスを取って進めなければいけません。 「これ、こうやろうと思うんだけどどうかな？」「それだったらこっちの方がいいんじゃないですか？」というような相談をするというのが一番コミュニケーション回数としても多いと思いますね。 チーム内では「宿泊施設のアプリはAさん、列車素材のアプリはBさん」といったような役割分担がされているんですか？ いえ、そこは原則チームみんなで全部のアプリを見る形を取っています。 そうはいっても、初期開発時にはアプリごとにある程度特定の人がまとめて開発していったほうが効率的なので、そうなると属人化というか、開発した人が一番詳しくなるものなので、個々人ごとにどの領域に知見があるかという色は出てきます。それが一定以上偏ってしまうと、その人が抜けてしまった時にチームが回らなくなってしまう恐れがあり不健全なので、ある程度、詳しいものとそうでないもののグラデーションはありつつも、なるべく分散させてチームとして健全な形になるよう気を付けています。 属人化させないための工夫とは？ お客様の業界のドメイン知識のようなものはなるべくesa（社内の情報共有ツール）に書き出して残すようにしています。あとはチーム内でのアプリング（社内用語）で知識の偏りを減らす取り組みをしています。 アプリングは「アプリについて輪になって話す(app + ring)」という意味の社内造語です（COOが命名されたそうです）。チームによってやり方は異なりますが、webコネクトでは週１,２回行っていて、特定の機能に詳しい人が持ち回りで「ここはこういう形になっていて、元々こういう要望があって、こういう実装になっていて～～」というような説明を30分～１時間程度の枠の中で紹介する形式を取っています。全員で理解を深めることで、元々の開発に携わっていない人も、実装の修正や対応をできるようにするという目的があります。また、説明する側にとっても、人に説明することで構造化されて改めて理解が深まるというメリットもあります。 やはりドキュメントを残すというのは結構大変な作業なので、開発業務で忙しい中だとドキュメントを残す暇があったら自分で修正してしまおうというマインドにもなりがちです。そこで、アプリングの場ではあえてあまり資料は作り込まないようにしてもらっていて、その場で参加者みんなでesaをオンライン編集していくようにしています。講師役の社員の説明を聞いて書き残しておいた方が良いと感じたことを参加者が書き記して全員の共有財産にしていって、負担をかけずにその人の持っている知識を周りに伝播させていくようにしています。 プロフィール webエンジニア 谷井 嶺太（たにい・りょうた） 入社年度： 2019年新卒入社 所属部署： 旅行プラットフォーム事業部 旅行第5グループ オフの過ごし方： なにもしないことが一番のリラックス方法なので好きなだけ寝ています。また、大学時代から始めた躰道（たいどう）という武道の道場で週1回稽古しています。 自分を漢字一文字で表すと...「整」 ゼロから何かを創り出すよりも、既にあるものを整える方が得意です。 フォルシアを漢字一文字で表すと...「信」 社員一人一人にプロとしての誇りを持つことを求めつつ、信頼して尊重している会社だと思います。 前編 フォルシアエンジニアの魅力編 前編「フォルシアエンジニアの魅力編」はいかがでしたでしょうか。フォルシアのエンジニアだからこその仕事の幅や、チームで働くという働き方、谷井さんの想いが伝わりましたら幸いです。明日は後編「４年目エンジニアの価値観編」をお届けします。お楽しみに！

こんにちは！新人エンジニアの宮本です。 みなさんはアルゴリズムを使ってプログラムを高速化していますか？ アルゴリズムを工夫するだけでこれまで長時間かかっていた処理が一瞬で終わると感動しますよね。 PostgreSQLでは、与えられたクエリに対してプランナが実行計画を立てますが、ここでもアルゴリズムを使った高速化が行われています。 この記事では、その1つである 移動集約モード について紹介します。 移動集約モードとは？ 移動集約モードは、集約関数を含むある種のクエリを高速化する機能です。 対象となるクエリ key カラムと value カラムをもつ10行のテーブル test を用意

こんにちは、経営企画室 広報の伊藤です。 「そもそもSpookとはいったい何なのか？」 、 「Spookの強みとは何なのか？」 に続く第三弾、本企画のラストは「どんな企業で導入されているのか？」、「今後どんな未来を見据えているのか？」について社員の生の声で解説していきます！ 今回もこちらのお二人に伺いました。 Spookについて教えてくれた先輩社員プロフィール （右）ITコンサル：DXプラットフォーム部　営業部長　諏訪 （左）エンジニア：旅行プラットフォーム部　グループ長　西山 ITコンサルタント職 DXプラットフォーム部　営業部長　諏訪 俊（すわ・しゅん） ／写真右 2017年　キャリア入社 旅行会社での海外渡航手配や法人営業を経て、2017年にフォルシアへ入社 前職での経験を活かし、旅行・観光業向け営業活動に５年間携わり、今年からはDXプラットフォーム部で非旅行業界向け営業・コンサル活動に従事 エンジニア職 旅行プラットフォーム部　グループ長　西山 諒平（にしやま・りょうへい） ／写真左 2015年　新卒入社 新卒での入社後 、 大手旅行サイト開発を経て、現在は 旅行・観光業界向け商品販売プラットフォームサービス「webコネクト」 のプロダクト開発に従事 ※所属は2022年７月現在のものとなります それではさっそく聞いていきます！ Spookの導入先とは... 検索対象となるデータが膨大であり、検索条件が複雑。そんなデータを取り扱う業界でSpookは本領発揮 Spookは旅行・航空業界での導入が多いですが、それはなぜでしょうか？ 諏訪 ／旅行・航空業界で導入されているSpookを用いて開発されたシステムは、「宿泊商品販売」や「ツアー商品販売」における検索システムです。いずれも「宿泊」を伴う商品となりますが、宿泊プランというのは同じホテル、部屋であっても季節、空室状況、オプション条件などにより様々な料金設定がされます。 宿の検索画面イメージ このように同じ商品に対して多様な料金パターンが存在すると、検索対象となるデータが膨大・複雑になるため、データの圧縮が得意というSpookの特長が最大限に活かされるというわけです。 さきほど話にあがった通り、特定の宿ではなく希望条件に当てはまる宿を探したいとき、「知らなくても希望にあったものが見つけられる」検索が業界のニーズに当てはまったことがSpookが広く導入されることに繋がっていると思います。 では、旅行・航空業界以外ではどのような業界で導入されているのでしょうか？ 一つの仕組み、一つの部品の検索から、一つのものを作るために必要な部品を複数検索するというステージへ 諏訪 ／大量の商品数を扱われる商社やECサイトを運営する企業で導入いただいています。最近では工作機械を扱う企業や医科理化学機器を扱う企業様からも引き合いをいただいています。 開発の内容も、複数素材の組み合わせによる見積パターンを条件指定型で実現するという新しいSpookの活用方法にて採用いただいているケースもあります。簡単にいうと、部品と部品の組み合わせによる見積の算出・表示のシステムです。部品Aを使うとなったら、その部品Aに合う部品はこれですといったもので、非常に複雑な検索の制御などが発生してきます。こういった複雑さはまさにSpookの強みが活きるところです。 これまで、一つの仕組み、一つの部品の検索が求められていましたが、いまは、"一つのものを作るために必要な部品を複数検索する"という新しいステージに来ているように感じます。 膨大な商品数があり、商品に対する絞り込みの条件（スペック）が多く存在し、商品によって絞り込む対象スペックが異なるような場合、それを全て活かして検索画面上で表現することは難しく、パッケージで限定的な対応に留めるか、フルスクラッチで自社内製部隊を構えて必要な機能を作り上げていくか、難しい選択が迫られます。 だからこそ、パッケージと自社内製の良いところを併せ持ったサービスを提供できるSpookが高い評価を頂き、導入に繋がっていると考えています。 今後も、旅行業界のように業界全体で導入が進むようなパターンは考えられますか？ 諏訪 ／旅行・航空業界のように業界全体で広く導入が進むというのは特殊なパターンで、旅行・航空業界の取り扱うデータの膨大さ、組み合わせの複雑さゆえのものです。検索から提案が始まった旅行・航空業界のシステムにおいても、まだまだフォルシアが携わっている領域は部分的でしかありません。これからも深くペネトレイトしていきたいところです。 そのためにも、今後の営業展開として固定の業界をターゲットとしていくということはなく、業界問わずSpookの特長がはまる新しいお客様を探して行ければと思っていますし、今後もSpookへのニーズは新たに出てくるのではないかと考えています。 Spookの今後とは... 価値の源泉であり競争力となる「速さ」を突き詰める Spookは今後どのように発展していくのでしょうか？ 西山 ／今後のSpookの発展において、エンジニアとして３点注力させていきたいと思っています。 検索本体のさらなる高速化 クラウドを利用して、柔軟なシステム構成（k8s, aws） SaaSとして提供（webコネクトもSpookを用いて開発されています） それぞれ解説しますと、１点目については、検索処理速度・表示速度が速いということが価値の源泉であり、競争力だと思っているのでそこは突き詰めていきたいです。現状のSpookはお客さんのデータをバッチで取り込んで表示しているため若干のラグがあるのですが、速さを突き詰めた「リアルタイム化」は今後のSpookの発展の余地として残っています。 ２点目については、昔に比べてインフラの柔軟性が高まり、システム負荷の面でのお客さんのニーズに応えやすくなっているので、より一層、Spookとクラウドのサービスを組み合わせて柔軟なSpookを作っていきたいと考えています。 最後の３点目は、 webコネクト （自社SaaSプロダクト）とありますが、Spookを用いた開発を通して見えた検索に求められる共通点や課題をSaaSのプロダクトの中に組み込んでいき、より多くの顧客・ユーザーに検索サービスを使っていただきたいと思っています。 新しいものを作る機会を増やし、新しい機能が提供できる土壌を整える 営業サイドからはいかがですか？ 諏訪 ／Spookはフォルシアのこれまでの継続的な挑戦がノウハウとして集積された独自の検索エンジンです。先ほどもお話した通り、Spookに「完成形」としてのゴールはなく、フォルシアが日々お客様へサービスを提供するなかで、常に新しい知見を取り入れて成長していきます。 中核となっている「膨大・複雑なデータに対する検索の強み」は変わることはありませんが、その活用方法や求められる機能に応じて自由に発展を続けることができる仕組みだと思っています。 営業観点ではとにかくSpookを使って新しいものを作る機会を増やしていきたいです。そうすることで、さらにSpookのカスタマイズ（＝進化）が進んで、新しい機能の提供ができる土壌が整い、良い循環が生まれていくと思っています。 だからこそ、Spookに興味をもってフォルシアに入社する方が増えてほしいです。 目新しいSaaSサービスを作るということはフォルシアでなく別の会社でもできることです。フォルシアも今では自社のSaaSサービスを展開していますが、それはSpookという軸があってこそ生まれてきたもの。フォルシアにはSpookという軸があり、Spookを用いたサービスを柔軟に自由に考えて作っていけるということを一緒に楽しんでいってほしいと思っています。   インタビュー後記「Spookとは...」 ITコンサル、エンジニアという職種の異なる２人の先輩社員からのSpook解説三部作はいかがでしたでしょうか。私としても、営業の現場ではこういった言い回しで紹介しているのか...！だったり、エンジニア用語をよりかみ砕いて説明いただくことで理解が進んだりと非常に学びの多い時間となりました。 今回、採用時に多く質問いただくSpookについて紹介させていただきましたが、文字で読むのと実際に社員と会話するのではきっと感じ方や得られるものは異なると思います。フォルシアでは通年カジュアル面談を行っていますので、少しでも興味を持っていただけましたら、是非下部のフォーム（水色ボタン）よりご連絡いただければと思います！ フォルシアの継続的な挑戦の証であり、さらなるビジネス展開のための源泉であるSpookについて興味を持ち、より良いSpookを一緒につくり、広めていきたいという新しい仲間に出会えることを楽しみにしています。

こんにちは、経営企画室 広報の伊藤です。 先日の 「そもそもSpookとはいったい何なのか？」 に続き、今回は第二弾「Spookの強みとは何なのか？」について社員の生の声で解説していきます！ Spookについて教えてくれた先輩社員プロフィール （右）ITコンサル：DXプラットフォーム部　営業部長　諏訪 （左）エンジニア：旅行プラットフォーム部　グループ長　西山 ITコンサルタント職 DXプラットフォーム部　営業部長　諏訪 俊（すわ・しゅん） ／写真右 2017年　キャリア入社 旅行会社での海外渡航手配や法人営業を経て、2017年にフォルシアへ入社 前職での経験を活かし、旅行・観光業向け営業活動に５年間携わり、今年からはDXプラットフォーム部で非旅行業界向け営業・コンサル活動に従事 エンジニア職 旅行プラットフォーム部　グループ長　西山 諒平（にしやま・りょうへい） ／写真左 2015年　新卒入社 新卒での入社後 、 大手旅行サイト開発を経て、現在は 旅行・観光業界向け商品販売プラットフォームサービス「webコネクト」 のプロダクト開発に従事 ※所属は2022年７月現在のものとなります それではさっそく聞いていきます！ Spookの強みとは... パッケージでも自社内製でもない優位性のあるポジション 他社にはないSpookならではの強みとは何でしょうか？ 諏訪 ／Spookはお客様にとって、パッケージでも自社内製でもないところが強みだと考えています。パッケージだとどうしても機能の拡張性や自由度に限界があり、自社内製とするには多くのエンジニアを抱えたりサービス維持のために必要なコストが大きすぎるというジレンマがあります。 Spookは、これまでフォルシアが開発してきた検索システムの知見をベースとして新しい機能を検討して行くことができるので、ゼロベースでの開発ではない検討ができます。また、エンジニアを多く抱えたりサービス維持のノウハウがなくても、フォルシアのエンジニアがそれを直接サポートするため自社内製に近いかたちで自由な機能改修、機能拡張を実現できます。 先ほど西山さんからも「レシピ本と包丁とフライパンのセット」というお話がありましたが、Spook、パッケージ、自社内製をそれぞれ"カレーライス"に例えたら... パッケージ　＝レトルトカレー 自社内製　　＝自宅に料理人を抱えて作ってもらったカレー Spook　　 　＝？？？？？ 西山 ／自社内製もSpookもどちらも料理人が作るカレーなのですが、自社内製は料理人が「鍋はどこにありますか？」「どんなカレーが（ビーフ？チキン？シーフード？）良いですか？」「このスパイスないと作れないですよ？」といった風にたくさんの会話が必要で、多くのやり取り・多くの時間がかかってしまうイメージです。さらに、料理人たちは分業していて、自分の担当している部分以外のことになると都度確認が発生してしまう。 一方、Spookを用いて作られるカレーは、自分のことをすごく理解してくれている料理人が、だいたい必要となる下ごしらえを済ませた状態で、「（常連さんのこれまでのオーダーから察するに）この味付けが好きだと思うのでこんな感じに作ってみましたがどうですか？」「下ごしらえはできているので追加の注文伺いますよ」といった感じで作られるカレーのイメージです。 Spookというお作法・ノウハウ、これまでに作ってきた機能があるからこそ、一番良いものを、気持ちの良いコミュニケーション量で作ることができます。 諏訪 ／パッケージで事足りるのであれば、パッケージのほうが安くて容易に導入できるので良いと思います。ただ、パッケージでは事足りず、かと言って自分たちで何でもやる（＝自社内製）となると費用も手間もまかなえないという場合はSpookがぴったりだと思います。 営業線上、パッケージと勝負することもあるし、SIer（自社内製）と勝負することもあります。その際にパッケージでも自社内製でもない中間のポジションであるということを強みとして押し出しています。 ポジションに優位性があるということですね。 ほかにもSpookのすごさを語る上で「速さ」は欠かせないと思うのですが、Spookは何で速いのでしょうか？ Spookといえば、高速検索。高速検索の秘訣はデータの圧縮技術 西山 ／一言でいうと、データベースの圧縮が得意だからです。 例えば旅行会社のもつツアーの料金データは、ツアーごとに１日の料金が設定されていて、平日と祝日でも金額は異なるし、大人と子どもでも異なる。そうなると一つのツアーだけでも数レコードの料金データとなり、大手の旅行会社さんだと取り扱うツアーの数も何千何万とあるので、料金データは非常に膨大なものになります。このデータを検索する際に全部上からなめていくと、あまりのデータの多さに検索ボタンを押した後、画面がかたまって処理中の画面がずっと出続けてしまいます。 ただ、Spookの技術においては裏側でその膨大なデータを圧縮して保持しているので、検索ボタンが押された後すぐに検索結果を表示させることができます。 諏訪 ／フォルシアはデータ保持の仕方に関する特許をもっていて、その特許技術を使った圧縮方法でデータサイズを小さくすることによって高速検索が実現できています。 西山 ／これがSpookの高速検索の速さの要因です。 他にも他社の検索機能との違いという点では、Spookは絞り込まなくても検索ができるという強みがあります。他社の検索の場合、例えばそのコンピューター上で処理できる情報の数が100だとしたら、100にするために日付を決めて、出発地を決めて、参加人数を決めてという風にデータの全量が100になるように条件で絞り込んで行く必要があります。一方Spookであれば、データを圧縮して保持しているため、日付未指定であっても、出発地が決まっていなくても、料金の上限下限のレンジを設定していなくても検索することが可能です。 諏訪 ／これは私のイメージなのですが... 少ししか情報を書けない一筆箋が１万枚ぐらい詰まった箱から１枚の紙を取り出すのと、一筆箋100枚分の情報が書かれているカードが100枚入っている箱から１つの情報を取り出すのとどっちが速く取り出せるかっていう話かなと思っています。 Spookは、一筆箋１枚１枚を１データとして捉えるのではなく、データの圧縮技術によって100個のデータが固まっているものを１データとして捉えているようなイメージなので、１万枚から探すのではなく、100枚の中から探せば良い。要は探す対象となるカードの枚数を減らせるから、たどり着きたい情報を速く探し出すことができるんです。 諏訪 ／速さというパフォーマンスに一番直接的に影響するのはレコード数（データの量）なので、いかに対象とするレコード数を抑えるかというのがフォルシアの着眼点であり、技術の真髄です。 なるほど！速さの秘訣が少し解明された気がします。 他社との違いといえば、検索というと真っ先に浮かぶのはキーワード検索かと思うのですが、Spookの検索とキーワード検索との違いについて教えてください。 コンセプトは、「キーワード検索で探せないものを検索する」 諏訪 ／そもそもSpookは「キーワード検索では探せないものを検索する」っていうコンセプトで生まれています。キーワード検索だと、そのキーワードを知っていれば検索できるけれど、そうでなかったら検索できません。特に旅行先の宿を探したいとなったとき、知っている宿しか検索できなかったら選択肢の幅がすごく狭いわけです。ユーザーとしては、"その宿"に泊まりたいのではなくて、"その条件を満たしている宿"に泊まりたいわけで、条件にさえ合致するならば絶対にそこでないといけないということはないものです。 だからこそ、複数の条件からそれに合致する施設が全国にどれくらいあるのかを検索できるという点がSpookの良さとして旅行・観光業界に採用されています。 Google 検索でミラコスタに泊まりたい人がミラコスタを検索することができても、ミラコスタに似ている他のホテルを見つけることは難しい。なので、そういうものを検索できるようにするというのがSpookのコンセプトなんです。 諏訪 ／さらに言うと、お客様はどのように検索させたいかという意図を持って情報を管理しています。Spookはその工夫された情報管理のもと、条件検索で最適解に導こうとしていますが、キーワードだけでの検索においてはそのキーワードをどこの情報として当てるかも判然としないので 、当てたくない情報を引っ張ってきてしまい希望のものへたどり着けないといったこともあります。 Spookの強みとは何なのか？ 独自技術により高速検索に長け、パッケージでも自社内製でもない優位性のあるポジションを確立していることが強みであるSpook。第三弾ではSpookを採用いただいている業界・企業についてや、今後の展望について伺います。お楽しみに！