富士山マガジンサービスは、雑誌のECサイトの運営のみならず、様々なライフスタイルをカバーする趣味・嗜好のプラットフォーマーとして事業を展開しています。
実は、主力事業である雑誌の定期購読では、販売するための様々なルールがあります。
その中でも「定価でしか販売してはいけない」というルールがあり、資本力や規模メリットを活かした薄利多売は行えないのです。
値段で勝負がつかないならどこで戦うのか？
それは、サービスのユーザー体験に他なりません。お客様に良い体験をしていただく事が何より大事です。 そのため、私たちはこのECサイトを含む様々なプラットフォームを運営するにあたってのフロントエンドやバックエンド、注文から配送、カスタマーサポート、デジタル雑誌に関しては記事の作成まで、ほぼ全てのシステムを内製しています。
技術者の腕が会社の利益に直結する、そんな仕事なのです。 システム責任者からの
メッセージ↓
企画立案、業務プロセス設計、実際の開発から運用まで、全てのフェーズに関わっていただきます。
もちろん最初はできるフェーズをメインに、チームメンバーのサポートのもと、段々と関わるフェーズを増やしていきます。
富士山マガジンサービスではエンジニアのキャリアパスとしてマネージャー/エキスパートの2種類があるため、個人の目指すエンジニア像に近づくように業務を遂行することが可能です。
システムは、ほぼ全てが内製となっています。
雑誌販売事業の利益を上げていくために必要なすべての企画をシステムの立場から具現化していきます。
ECサイト「Fujisan.co.jp」を含め、様々なファンビジネスを展開するプラットフォームの多くのフェーズに関わることができます。 業務の影響する範囲が広く、調査や調整に割く時間は多い傾向にあります。
ですが、より早く効果を出せるよう機能を細かく分け、なるべく短い単位でのリリースを心がけています。
開発手法としては、アジャイル開発手法の一つであるスクラムを採用しています。
基本のプロジェクトツールとしてRedmineを採用しており、Redmine上のかんばんを見ながら毎朝デイリースクラムを行っています。 また、チャットツールとしてSlackを採用しており、プロジェクト毎にチャンネルを作ってコミュニケーションをとっています。
言語として、現在はJavaもしくはKotlinがメインです。過去にはGroovyを選択していた時期もありましたが、10年ほど使ったうえで現在の組織の状態とはそぐわないと判断し、社内デファクトスタンダードから外しています。
Groovyは言語の表現力に期待して採用しましたが、現在ではバージョンアップによってJavaの表現力もかなり上がっているため、エンジニアの母数が遥かに大きいJavaに回帰しています。
ただし、これらの言語しか使えないというわけではなく、常に新しいものを提案できる環境です。もちろん、提案には根拠と責任が伴いますが、Groovyの採用もエンジニアの提案から生まれたものであり、採用からすでに10年が経っています。
オープンソースの採用に積極的な空気があり、いわゆる自社内でしか通用しないフレームワークというものは存在しません。まだ今は不十分ですが、オープンソースへの貢献も心がけています。
CIツールとしてJenkinsを採用し、Webistranoと連携させてDeployを行っています。 必ずテストを書くことをルールとしており、Jenkins上でテストの網羅率や成功率を常に確認できるようになっています。 自動テストを重視している理由としてはプロジェクトの性質にもよりますが、初期コストよりも運用コストを重視していることが挙げられます。
また、現在インフラをAWSに変更中で、AWSを使った場合のCI/CD環境も構築中です。
富士山マガジンサービスは開発担当者が運用保守も担当するため、運用コストが高ければ新規プロジェクトにかける時間が削られてしまいます。 そのため、運用中に開発者が対応しなければいけない問題を減らした状態でリリースすることを心がけています。 サービスを運用していく中で、移り変わるビジネス要因に応じて常にサービスを改修し続けるため、改修を容易にしデグレードがないことを担保する手段として、自動テスト & CIを取り入れています。
監視システムとしてNagiosを採用しており、サービス一覧画面を見るだけで、自社サービスのどこに問題が起こっているかをすぐに把握できるようにしています。 ログの集約化に関してはまだあまり手を付けられておらず、これからの課題です。
自社サービスですので、自分たちが作ったシステムは自分たちで運用しています。 急な障害等にも対応しなければいけないので、100%純粋に開発だけに集中できるわけではありませんが、いかに障害が発生しないようにするか、また発生しても簡単に復旧できるように設計するかが腕の見せ所でもあります。
様々な企画が並行して動くことが当たり前の環境なので、バージョン管理システムにはGitを使い、並行開発性を高めています。 外部開発パートナー会社との共同開発ではGithubを使い、PullRequestベースでの開発とコードレビューを行うことによって、品質を担保する試みを行っています。
誰でも突発的なワーキンググループを主催することができ、他チームにも広めていきたい手法やツール等の共有が可能です。
また、別に社内チャットとしてSlackを採用しており、開発者用チャンネルではワーキンググループを開催するほどではない技術的な小ネタや雑談が行われています。
富士山マガジンサービスでは、社内で統一された機器はなく、得意分野や主に携わる開発フェーズ、業務環境に合わせて多種多様な開発機器を用意しています。 入社時に18万円（税込）以内で好きなPCをリクエスト可能で、ご自身で機器を選択できます。
今までに富士山マガジンサービスで手がけてきた案件事例についてご紹介します。
雑誌の定期購読サービスを利用する際の支払方法として「一括払い（先払い）」に加え、新たに「月額払い」を導入。
読みたい雑誌を登録すると発売日が来るたびに自動的に配送され、配送された分だけの金額を翌月に後払いで支払う形にすることで、まだ定期購読サービスを利用していないお客様にも手軽に利用してもらえるように設定した。
今までは大手運送会社による割安な運送サービスを利用して雑誌を配送していたが、お客様の手元に届くまで少し時間がかかっていた。
そこで当社は某新聞社と独占契約を締結し、新聞社の配送網を雑誌の配送に利用できるシステムを開発。その結果、廉価で且つ出庫日の翌日に朝刊と同じタイミングで届くという迅速なサービスを提供できるようになった。
2018年6月、割賦販売法の改正に伴い、クレジットカードを取り扱うECサイトの事業者は、今まで保持していたクレジットカード情報を保持できなくなった。またデータベースにカード情報を保存するだけでなく、サーバーのメモリ上へ展開することやネットワーク上を情報が通過することも「保持」とみなされるため、当社ではお客様のブラウザ上からJavaScriptで直接決済代行会社に情報を送信し、返されたトークンのみをサーバー側に送って管理を行うシステムに変更した。
サイト経由での申し込みや問い合わせなど、コンバージョンレートの向上を目的に、「Fujisan.co.jp」のトップページや商品カタログページのデザインを一新。同時にPDCAを細かく回しながら、お客様が利用しやすいようにサービス購入時のフローも改修した結果、予算の達成に成功した。
配送会社の倉庫から雑誌の出庫作業を行うため、発売日から逆算して出庫作業を担う作業者のシフトを組んでいたが、空振りが多く人件費が嵩んでいた。そこで出版社に対し、倉庫へ搬入する雑誌の予定冊数および搬入予定日・時間帯を毎号ごとに入力してもらうインターフェースを実装。結果を倉庫へ常に連携することで容易に作業者を確保できたほか、人件費の削減に成功した。
CS職が顧客対応時に使用する、顧客情報や注文情報、配送情報を確認するためのツールを開発。電話対応では3秒の沈黙は許されず、スムーズにCS職に情報を提供する必要があるため、一度に網羅的な情報を出すのではなく、非同期にその瞬間の会話に必要な情報のみを順次表示することで、顧客対応の品質向上に貢献した。
富士山マガジンサービスのソフトウェアエンジニアからのメッセージです。
当社のエンジニアとして活躍するためには、今まで培ってきた技術を活かすのはもちろん、当社のビジネスに興味を持って取り組み、成果を出すことが求められますが、
エンジニア一人ひとりのパフォーマンスを発揮できるような環境づくりにも取り組んでいます。
当社ではECサイト「Fujisan.co.jp」を含む様々なファンビジネスを展開するプラットフォームのスクラム開発を内製で行っています。
そのため一般的なSIerで見られる「上流」や「下流」という概念はなく、企画立案から業務プロセス設計、開発から運用まで全てのフェーズに関わります。
このことを聞いてハードルを高く感じるかもしれませんが、言い換えてみればエンジニア一人ひとりの裁量が大きいのが特徴と言えるでしょう。
例えば、あるシステム開発案件で自分で使いたい技術やフレームワークがある場合、エンジニアリングマネージャに対して、そのプロジェクトで採用すべき理由をきちんと説明することが出来れば、取り入れられるチャンスがあります。
もちろん、「自分がやりたいから」ではなく、「その技術を取り入れた結果ビジネスにどういう影響を与えることが出来るのか」を説明する必要があります。
具体例を挙げると、「この企画はリリースした後の結果を見ながら細かく機能を変えていく必要があるから、変更容易性の高いこのフレームワークを選択すべきである」や「この企画はこのあと様々なエンジニアが流動的に関わっていくことが想定されるから、堅牢性の高いこの言語を選択すべきである」などです。
我々エンジニアには、「技術」の軸と「問題解決」の軸があると思っています。
もちろん「技術」を使って「問題解決」を行うのがエンジニアの仕事ですが、どちらにどのくらい軸足をおくかは人によって結構差があると感じています。
私も技術が好きなのでどうしても見失いがちにはなるんですが、あくまで技術は問題解決のための手段です。そして我々はプロのエンジニアとして、問題解決のための手段を複数常に持っておき、そのときそのときの状況に合わせて最適な技術的解決手段を提示し、実行できる必要があります。
例えば、ブルーオーシャンの市場に対してアプローチするプロジェクトであれば、「先行者利益を得るために運用コストが高くついても初期コストを少なくすることを重要視した技術選定や設計」が必要ですし、法律や国際規格に対応するためのプロジェクトであれば「初期コストがかかってもきっちりとそれに対応させる」ことが必要です。
若手エンジニアの中にはどうしても「自分の思う最強の設計」一択でやりたくなってしまう人もいますが、あくまでそれは選択肢の一つです。時間や予算といった各種リソースが無尽蔵に使えるのであればその選択肢は正解ですが、なかなかそんな恵まれた条件のプロジェクトはありません。その時その時で、なにがどうなっていることが「最適」なのかをビジネス的見地と技術的見地の両方から考えて選択する必要があります。
このトレードオフの選択をプロのエンジニアとして楽しめるか、それとも妥協したと捉えてしまうのか。前者の考え方・捉え方が出来る方を求めています。
もちろん、そういった経験が浅い方に対しても私がメンターとしてしっかり話を聞き、そのプロジェクトの条件は何なのか、技術的に何がどう最適と思っているのかを一緒にまとめていきます。
大抵の場合、若手エンジニアの「技術的にこうあるべき」という直感はあっており、ただそれをビジネス的な観点でうまく説明できないだけだったりします。
そういう部分を非エンジニアにもわかりやすく説明するサポートもおこなっています。
この技術を導入することで、この設計を選ぶことで、ビジネス的な数値の何がどう変わるのかを説明できるエンジニアを目指して欲しいと思っています。
すべての領域とまではいかないかもしれませんが、当社のビジネスに深く関わることが出来ます。
技術を磨きつつ、自分の磨いた技術を使ってビジネス的な成果を生み出すのが楽しいと思えるエンジニアの方と一緒に、ビジネスをより大きくしていきたいですね。