船舶ツアー開発の裏側に迫る！船舶ツアー誕生ヒストリー～ベテランエンジニア編～

関東地方では長い梅雨が続いておりますが、全国のみなさまいかがお過ごしでしょうか。
沖縄ではもう梅雨明けとのことで、とうとう日本にも待ちに待った夏がやってくるのかな？というワクワクした気持ちが溢れております、営業企画部の岡地です。

さて今回は、今月商用リリースをむかえたwebコネクト船舶ツアー販売機能(以下船舶ツアー)について、プロジェクトメンバーにインタビューを行いました！（船舶ツアープレスリリースはこちら）

前編ではベテランエンジニアへ、後編では新卒２年目コンビ！ITコンサル＆エンジニアへインタビューしており、全二部作でお届けいたします。
まずはベテランエンジニア編として、船舶ツアーの開発エンジニア、長峰さんにお話を伺いました！

ベテランエンジニアの歴史

――長峰さん、本日はよろしくお願いします。（岡地）

なんか緊張しますね。よろしくお願いします。（長峰）

長峰さんは今までフォルシアでどんなお仕事をされていましたか？

入社してから３年間ほど、大手航空系の会社の検索システムの開発・運用保守を担当していました。ここ数年は、担当の運用保守に加え、大手の旅行会社さんの検索システムの開発であったり、機械学習を用いたダイナミックプライシングなど、他のチームのヘルプに入り開発に携わることが多かったです。
チームを転々とする中で、webコネクト開発にもヘルプに入ることになって、気づいたら正式なメンバーになっていました。

――長峰さんは今や、傍から見てもwebコネクトチームに欠かせない主力エンジニアとしてご活躍されていますが、振り返ってみると、ヘルプ時代からすでにwebコネクト海外ツアー（海外ツアーに特化した検索機能「ツアーサーチ」、プレスリリースはこちら）を開発されていませんでしたか？

そうですね、実はwebコネクトツアーサーチ（海外）の開発も担当していました。思い返せば、これがwebコネクトヘルプの始まりでしたね。

――長峰さんの開発ヒストリーを改めて知ることが出来ましたが、やはり凄いの一言に尽きます。

webコネクト船舶ツアーとは

今月、船舶ツアーが商用リリースされましたが、どんな機能なのでしょうか

表向きに見える機能を説明すると、「ツアーの交通手段として使えるものが１つ増えた」と言えるかと思います。具体的には、いままではwebコネクトツアー型での交通手段は飛行機や列車（新幹線や特急列車）だけでしたが、移動手段に船舶を組み込んだツアーが販売できるようになりました。

システム面にフォーカスした説明をすると、「どんな移動手段にでも対応できる最強の交通機能」ですかね。たまたまお客さんが船舶を導入するという話があったので船舶がフォーカスされていますが、私たちは最初から船舶を含め色々な交通手段を売るためにはどうすべきか？ということを議論していました。どういったデータ登録をしてもらえれば必要十分なのか考えたり、どの交通手段にも矛盾しないようなデータ構造について熟考しながら開発していきました。

結果として今回は船舶のデータを登録していただいたので、船舶ツアーが画面に出て販売されています。しかし、実は船舶だけではなくて、バスやヘリコプター、鉄道などもツアーとして紐づけられ、汎用的に交通手段を選べる仕組み(以下汎用交通)で売ることができるようになったというのがシステム面での機能説明になります。

実際に船舶ではない交通素材を使ってのツアーに興味があると言って下さっているお客さんもいます。船舶が汎用交通の１つであるということをお客さんが理解してくださり、可能性を感じてくださっているのかもしれません。

――いい意味でとんでもない機能ということが分かり、改めて驚きです。お客さんも、またフォルシアとしても可能性を感じられるのはとてもポジティブな流れが生まれているようですね。

大変だった開発の軌跡

船舶ツアーの開発の中で大変だったことがあれば教えてください

船舶ツアーの開発がはじまる１か月前くらいに正式にwebコネクトチームにjoinしたのですが、既存のwebコネクトを理解するためのキャッチアップが大変でした。かなり大きなアプリだし、アプリがどういう構造になっていて、それぞれの機能がどう動くのか、どういう思想で作られているのかが分からない状態で作り始めなくてはならなかったし、今から作りたいシステム、そもそも今作られているシステムが分からない状況だったので、かなり四苦八苦しました。

基本的には航空素材のツアー検索機能を参考にして開発を進めたものの、手戻りも多かったですね。航空には必要だが、船舶には必要ない機能やデータ構造があり、とりあえず開発するために航空ツアーを参考にぼーんと箱だけ作っておくが、「結局使わなかったね」みたいなことがあったり、「逆にこれだと足りないね」みたいなこともありました。

具体的な事象を教えていただけたりしますか？

往路と復路で人員区分が違うケースがあることですかね。たとえば航空だったら年齢が決まると行きも帰りも「子供」「大人」と判断されるけれど、船舶をはじめとする汎用交通は自由に登録できるように設計されているところがあり、行きは「子供」運賃で行けるが、帰りは違う基準が設定された便でデータが帰ってくるので、「大人」運賃になってしまうことがありました。

航空の時以上に、「往路のこの便」「復路のこの便」みたく、もっと細分化してデータを保持しておく必要があったので、そういう点は仕様を深く議論していかないと分からないところだったなというエピソードがありますね。

――そんな苦労が...。長峰さんは何でもできてしまうエンジニアさんだという印象が元々あって、でもそんな長峰さんでも悩むことがあったんだというのは、個人的に新しい発見です。

いやいや、そういうのばっかりでしたね。

開発者が最初自分１人しかいなかったというのも大変ではありました。人員区分が想像以上に複雑で、難しいから誰かと議論したい！となっても議論ができなかったので。難しいことを考えるときは人と話して自分の考えをアウトプットしないと矛盾点を把握しづらいので、誰かと議論できない状態というのはかなり辛かったです。

――今までは議論ができるプロジェクトがスタンダードだったのが、今回の場合は１人で読み解いて、更にコードに落とし込むというところまでやらなければならない。とても大変だったと思います。

そうですね、純粋に難易度の高いことをやらなくてはいけなかったので。

――長峰さんがいう「難易度が高い」がどれたけ難易度が高いことかを世間に伝えるのにはどうしたらよいのか、悩んでしまいます（笑）

よろしくお願いします（笑）

ITコンサルタント側とのコミュニケーションについて

ITコンサルとやり取りをする際、意識したことはありますか？

詳しく話すことですかね。実際にお客さんのフロントに立つのはITコンサルなので、ITコンサルがきちんと仕様調整とか理解する必要がある。一方で社内では、きちんと内容を聞いていてもエンジニアでさえほとんど理解できないような複雑な話をしている。もはや「担当ITコンサルだからこれくらい知っているよね」という前提も、ほとんど使えないような状態にありました。その状況で私がITコンサルへの説明を端折ってしまうと絶対に認識齟齬が出ると感じていたので、このデータはこういう性質を持っていますという前提を、こんなに話さなくてもいいよというくらい、繰り返し話したというのはありますね。

――私も船舶をはじめとする汎用交通の複雑さを理解するのは難しいなと感じていて、それでもお客さんとの会議で新卒２年目のITコンサルの江川さん（後編記事でご紹介します！）が凄くわかりやすくお客さんに説明しているのが印象的でした。その裏で長峰さんの配慮やコミュニケーションがあったんですね。

私からのインプットもあると思いますし、ITコンサルの奥田さん(奥田さんの活躍はこちら)からのインプットもかなりあると思います。江川さんが主体性をもって、船舶の状況を常に把握するべくエンジニアに色々聞いてくれるようになってから、チーミングが上手く出来てきたのではないかと思います。私は基本的に「お客さんにこの内容を伝えてください」というのをお願いしていました。

――名操縦士とでもいうのでしょうか、長峰さんの活躍を垣間見ることができました。

一緒に開発を行った後輩エンジニアについて

非常に頼りがいがあると思います。力石さん（後編記事でご紹介します！）とかすごく反応が速いし、バリバリ積極的に開発をやってくれたんですよね。結構私自身、「本当にこれでいいのか」というのを最後までずっと追いかけて考え込んで、いつまでも終わらないタイプのエンジニアなのですが、後輩エンジニアたちは臆することなく手を動かして「できました」といって、MR（マージリクエスト）を投げてくれるので、とても助かりました。実際システムを作ってみて、出来た後に皆の目で「これは大丈夫か」と確認する方が効率が良いので。

また、リリース間際になるにつれてwebコネクトエンジニアが船舶ツアープロジェクトに集まり、それぞれの得意分野を活かしてラストスパートをかけて開発を進めてくれたのも印象的でした。

――アベンジャーズみたいな感じでしょうか。これは映画館でみんな号泣するタイプの話ですね、胸に刻ませてください。

仕事をする上で大切にしていること

仕事をする上で大切にしていることは「重箱の隅をつつくこと」。
私自身の得意とするところでもあるのですが、本当にこれでいいのかを何度も反芻して、何か見落としはないかとか、考え切れていないパターンはないかとか、そういうところに重きを置いて考えるようにしています。

でも多分、もっと大切なことは他にいっぱいあるはずなんです。何かに対応する or 対応しないの線引きを決めるとか、お客さんのニーズに正面から答えていくとか。もちろんそれらが大事なことであるとは理解していますが、残念ながら自分はその分野が得意ではない。でもありがたいことに、周囲には前述した事柄が得意な人たちがたくさんいる。だからこそ、私は私の得意なところで周りの皆をサポートしようと思ったし、実際に実行することができています。自分は手を動かすのは早くはないが、手を動かすのが早い人の書いたコードを見て、深く考える。そして、色々と見落としがないかを見ていく方に特化しようかなと考えています。

――確かにお話を聞いていて、深く反芻したり、考えて見落としを見破ったりすることは長峰さんらしいなと思いました。改めまして、本日はありがとうございました。