ventus-incのブログ

全てのファンが、自分の「好き」に誇りを持てる世界をつくる。

2年間止まってた要望を1週間で実現させた一言から得られた学び

こんにちは、開発組織の支援などの活動をしている冬鏡です。 この記事ではこの間遭遇した社内ツールの開発に関して得られた気づきについて書いていこうと思います。

要約

  • 社内ツールが構築されていたが、リソース不足から次第に開発スピードが低下
  • CLIでもいいよ」という一言で一気に実用化にこぎつけた
  • 小さく試す方法の大切さ、身の回りにある気づきなどの学びが得られた

背景:社内ツール開発スピードの低下

弊社では約3年前(2021年春)に有志のエンジニアと運用・企画担当がほとんどその場のノリで作ったmiscと呼ばれる社内ツールがありました。ユーザーからの問い合わせに対応するための操作ができるツールです。

当初は1つのReactコンポーネントがサーバーにリクエストするだけの非常にシンプルな構成で、1日で作り上げられたツールでしたが、非常に利便性が高かったため、利用者、開発者ともに増加していきました。 それと比例してコードベースと技術スタックは複雑になっていき、2023年初めには、miscは3つのバックエンドと20以上のページを持つNextjsアプリケーションに成長していました。 利用者も当初の1人から10人程度へと増加し、さまざまなニーズが社内ツールの担当に寄せられるようになっていきました。 しかし、会社ではエンジニアリングリソースがプロダクト開発に優先して割り当てられており、社内ツール開発は主に業務委託に依存している状況でした。つまり、慢性的にニーズに開発が追いついていないという状況に陥っていたのです。

これに対して、ミーティングを重ねて実装プロセスを透明化し、要望に優先順位をつけたものの、新たな要望の実現までのリードタイムは縮まりませんでした。 また、技術スタックが複雑になった結果、要望を実現するための工数が肥大化していくというのも悩みの種でした。

この時点での課題は以下の通りでした。 - リソース不足から、要望を実現するまでに時間がかかる - コードベース、技術スタックが複雑になり、要望を実現するまでの工数が肥大化

次は、この2つの課題をどのように克服して要望を実現したのかについて書いていきます。

一言から始まった打開策

2023年の11月に開かれた要望を整理するミーティングの議題は「データベースへのデータ投入の効率化」でした。本番データの更新は既製品のツールを使っていますが、大規模なデータ投入では時間がかかる、切り戻しなどが難しいといった問題を抱えていたため、社内ツールで対応をしたいというものでした。 これを実装するには、データベースにデータを投入するジョブを管理するバックエンド、データをアップロードしてジョブを可視化するフロントエンドが必要で、現在のリソースでは数ヵ月が見込まれる大工事になるため、かなり時間がかかります。結局、いつも通り優先順位をつけてキューにタスクを積み、ゆるゆるとやっていこうという話になりつつありましたが、そのとき運用担当の方がボソッとおっしゃった一言がとても印象的でした。

「おれはWeb UIじゃなくてCLIツールでもいいけどね」

改めて状況を見直すと、CLIツールとして試作品を実装するというアイデアは非常に魅力的でした。社内ツールが作られた当初のヒアリングでは、誰でも簡単に操作ができるWeb UIツールとして実装することはほぼ必須の要件でした。しかし、運用フローの改善の中で、データの更新を行っているのは4,5人に集約されており、今回の発言をしたのはその統括の方でした。 つまり、ツールが登場した初期と現在では「どのくらい試験運用のためにUIを作りこむ必要があるのか」が大幅に変化していたのです。 しかも、CLIツールにより、ジョブシステムのバックエンドとフロントエンドを開発する工数を大幅に省略したうえで、要望の実現とその検証が可能となります。

CLIツールを作ると決心してからの展開は非常に速いものでした。 要望を実現するために必要なDenoのリポジトリが作成されてから最初のプロトタイプができるまで2時間、試作品が最初に使われるまで2日、そこからさらに実際に本番データ更新の時間が高速化されるまで1週間とかかりませんでした。 この1週間でCLIツールは10回以上バージョンを重ね、ニーズの技術検証としては非常に成功したといっていい状況になりました。

振り返り:どんな学びがあったか?

小さく試すことの重要性

アジャイルなど様々な方法論で示されているように、小さく試すということには非常な利点がありました。社内ツールとして完全な方法を提供するのに先立って小さく試すことで、少ないリソースで以下の事項が達成されました。

  • 実装に必要な技術要素の比較的詳細な洗い出し
  • 当事者からの要望機能フィードバック
  • 実現されたときのインパクトの詳細な見積もり

これらはWeb UIとして対象のツールを提供するときにも必要な事柄ですが、小さく試すことによって、Web UIを実装する際の計画や見積もり、優先度などの判断の精度を大幅に上げることができます。

身の回りにある細かな気づきの重要性

今回の成功につながった本質的なきっかけは、「かけるべき必要があると思われたコストを実はかけなくても検証できるという気づき」でした。この気づきをもたらしたのが何気ない一言だったのは大変センセーショナルでしたが、このような細かな気づきがときには重要な解決策をもたらしうるという教訓は、さまざまな場面で活かせるでしょう。 また、小さく試すことととかかわりがありますが、このような細かな気づきを普段から共有できる仕組みなどもあるといいのかもしれません。

これからやるべきこと

今回のCLIツールはすでにほぼ完成したような状況ですが、社内ツールに対するニーズにはまだ検証もされていないものがいくつもあります。これらの学びを他のものについて適用できないか模索しつつ、リソース不足の解消への取り組みを行っていきます。

1年かけて「マイクロサービスパターン」を勉強会で読みきった話

f:id:ventus-inc:20220402160742p:plain

こんにちは、Tech Leadの冬鏡です。

この記事はタイトルの通り、社内の非公式な勉強会を主催して、「マイクロサービスパターン」を1年間かけて読み切ったことの経緯やまとめ、反省です。(この記事では本の内容そのものには触れないのでご注意ください。)

背景

勉強会・LT会の系譜

そもそもventusでは会社の外に対して勉強会を開いていました。以前の記事でも話した「サステイナブル・フロントエンド」です。もともと採用につながるといいねという話でこれをやっていましたが、正直なところあまり効果がなかったので2019年秋に終わってしまいました。

そのあと、採用とか抜きにして2020年夏から秋にかけて社内で持ち回りLT会がありました。これはかなり良い試みで、社内のエンジニアが持ち回りでLTをしていくというものでした。とはいえ、これも10月くらいで終わってしまいました。これは、順番が一周するのが比較的速い(1ヶ月)ためにメンバーがネタ切れに陥ってしまったのと、多忙のためでした。

adminプロジェクトの破綻

ここでかなり話が変わります。ventusでは現在oricalというプロダクトを開発、運用しています。

lions.orical.jp

sumo.orical.jp

marines.orical.jp

swallows.orical.jp

これの運用のための社内ツールを作ることがプロダクトローンチ以来の課題でした。ゆくゆくは様々な社内で使っているツールを統合するシステムに成長することを見据えて、マイクロサービスアーキテクチャ「風」な構成にして2021年の2月くらいまで作っていました。

さて、マイクロサービスアーキテクチャ「風」と言ったのは理由があります。これは、担当者だった僕のマイクロサービスアーキテクチャへの理解度が低く、社内にも知見がないままそれっぽいものを作ったためです。その結果「マイクロサービスとモノリスの両方の悪いところ」を合わせたようなタールの沼が出現してしまいました。(いわゆる分散モノリスです)

マイクロサービスに関する経験と知識の不足により沼ってしまったことは明白でした。そのため、adminのアーキテクチャをどうにかして改善するため、そして、改善の方向性を明確にし、ちゃんと議論するために上記の本を読むことになりました。

f:id:ventus-inc:20220226165856p:plain

経過

良かった点や反省点はあとで書くとして、ここでは経過を書いて行きます。

上のメッセージにある通り週1で1時間ずつというペースで進めようとしましたが、基本的にかなりルーズでした。また、基本的に僕も含めて読むメンバーは全員学生なので、年度初めや夏休み明けは予定調整で月1回だけ、みたいな月もありました。あと、リマインドを忘れて全員遅刻して延期、なんて回もあったりしました。(リマインドは大事ですね...)

なので進捗はかなりむらがあって、記録にある限りだと以下のように進んでいました。

  • 3/23 3章
  • 6/5 4章
  • 7/3 5章
  • 7/17 6章
  • 8/25 7章
  • 10/9 8章
  • 11/27 9,10章
  • 12/5 11章
  • 1/15 12章
  • 2/12 13章

見ての通り、1章あたりにかかる時間が短いときは2週間、長いときは3ヶ月(!)もかかっていることがわかります。

最初のメンバーは6人でしたが、途中で予定が合わなくなったり忙しくなったことで最終的には3,4人でやっていました。

批評

当初の目的であった「adminプロジェクトでの実践」は、adminプロジェクトがその後モノリシックな小規模プロジェクトとして再スタートしたことで実践できなくなってしまいました。とはいえ、現在の本体のモノリシックなプロダクトが肥大化し、複数のサブシステムが外付けされてチーム人数も増えていくという流れの中で、「最低限の網羅的な議論ができるようになった」だけでも無駄ではなかったのではないかと考えたいです。少なくとも、adminプロジェクトのような「分散モノリス」といった失敗は回避できるようになるでしょう。

勉強会の運営に関して言うと、「ルーズでもどんなにゆっくりでも進める」というのは悪くなかったのではないかと思います。(1章に3ヶ月かかるようなのは流石にもうしたくないですが)とはいえ、これは今回選んだ本がたまたま各章ごとの独立性が高かったというのにも助けられていたと考えられます。

反省点もあります。経過のところで6人から3,4人になったという話をしましたが、せっかく重要なテーマを扱っているだけに、シリーズもので途中離脱したり途中参加をしたときのサポートを真面目に考えたほうが良かったな、と考えています。

次に向けて

adminプロジェクトとは独立してしまいましたが、一つの題材について深堀りするタイプの勉強会は、現在行われている各人持ち回りのLT会とは並列で進めたほうがよいと考えています。勉強会の最終回では、「次のシリーズ」をどの本で行うかで投票が行われ、「Googleのソフトウェア・エンジニアリング」の第3部 プロセスを読むことになりました。今回の反省も活かしつつ、将来的な変化を創出できるような勉強会にしていけるとよいなと考えています。

株式会社ventusでは、延長線上にない未来にも共に踏み出せるエンジニアを探しています。

ventus-inc.com

持続可能なフロントエンドについて

f:id:ventus-inc:20211211172607p:plain

はじめに

はじめまして、株式会社ventus Tech Leadの冬鏡と申します。現在は東大で修士をしていて、学年だと23卒という年代にあたります(大学だと量子計算の研究をしています)。この会社ではいろんなことをしてきましたが、主にフロントエンドの領域をやってきました。

今までこの会社でやってきたことを述べると、以下のようになります。

  • whooop!(前プロダクト)のフロントエンドの設計とコーディング
  • ORICALのwebフロントエンドやモバイルアプリケーションフロントエンドの設計とコーディング

会社に来る前は東京大学駒場祭委員会や五月祭委員会で情報部門の統括みたいなことをしていました。(Wantedlyの個人ページを見ていただけるとその時の情報がちょっとだけ載っています。)現在やっていることは、ORICALの運用を効率化するための社内ツールの開発ですが、全体的にフロントエンドの設計や新規技術の導入みたいなことをやる傾向があります。

 

今回のブログでは、僕がずっと問題意識をもっていて、かつての会社の勉強会のタイトルにもした「持続可能なフロントエンド」について少しだけ書いてみようと思います(残念ながら勉強会そのものはコロナ禍の前に打ち切りになってしまいましたが…)。

 

フロントエンドの難しさ

フロントエンド、という分野を僕が最初に総体として認識し、活動をはじめたのは僕が大学2年生の頃、2017年の前半でした。そのときから5年が経過しようとしており、フロントエンドと呼ばれる領域は大きく変化しました。

 

その変化は進化と呼べるものであった一方、(『人月の神話』*1にもあるように)「本質的な難しさ」はほとんどそのまま保存されており、今でも多くの人が頭を悩ませていると思います。むしろ、当時よりもツールチェインやライブラリ、フレームワークなどのエコシステムが発達した分、その難しさは顕在化しているとみていいでしょう。つい最近JSConf JPが開催されましたが、そこでもいくつか「本質的な難しさ」に関わるような講演が採択されていました。

 

jsconf.jp

 

ではフロントエンドにおいて「本質的な難しさ」(そして、普遍的でもある難しさ)とはなんでしょうか。それは、設計であったり、人材の育成、開発手法、組織体系であったりといったソフトウェア開発プロジェクトであれば誰もが避けては通れないものから、「エコシステムの変化への追従」といったフロントエンドで特に起こりやすいものなど、多岐にわたります。

 

この会社で最初に携わったプロダクトであるwhooop!の開発では、設計の大切さを感じる出来事が多く、whooop!をリニューアルしたときには開発手法が、ORICALのwebフロントエンドを開発したときにはエコシステムの変化への適応、モバイルアプリフロントエンドを開発したときには人材がそれぞれ重要なテーマでした。そして、現在ventusでは組織体系を刷新し、より「スケーラブル」な組織を目指そうとしています。

 

では、スケーラブルな組織にとって、開発組織がフロントエンド領域でできることとはなんでしょうか?その答えの一つは、「持続可能である」ことだと僕は考えています。

 

「持続可能」とは何か

ある程度の経験年数(フロントエンドだと多分1,2年?)のある方は「技術的負債」なる概念を(自分の言葉で明確に言語化できなくとも体感している方が多いと思います。技術的負債を素朴に言語化を行うとすれば、「開発しているうちに、段々と新規機能の追加などが難しくなっていき、時間がかかるようになっていく現象」のことでしょう。この会社でも、この会社に来る前の大学の学園祭の情報部門でも、様々なプロジェクトが「負債」にゆっくりと変貌していく様子を僕は目の当たりにし、それがコンウェイの法則*2よろしく、対応する組織をゆっくりと「老化」させていくのを見ていました。(この話はそれ自体がケーススタディとして面白いという指摘をされたことがあるので、また別の機会に書くかもしれません)

 

幾度かのプロジェクトを経て、この「技術的負債」は、それ自体がより普遍的なケースの「開発プロジェクト版」なのではないかと思うようになりました。それは、「環境の変化に対する不適応」です。僕はかつて学園祭の組織で仕事をしていたとき、「コードを読むだけで書いた人を当てる」という特技を持っていました。これはかなり特殊なケースだと思いますが、開発されたソフトウェアを注意深く観察し、メタデータなども含めてひもといていくと、「コードが書かれた環境」をまるで地層のように紐解くことが可能でしょう。そして、「コードが書かれた環境」と「現在のコードを取り巻く環境」が食い違い、「不適応」が引き起こされるとき、それが技術的負債の発端になるのではないかと考えるようになりました。というのも、コード自体には問題はなくとも、時間が経過するだけだったり、極端なときには「書いた人が賢くなる」という完全な外部要因で技術的負債になるケースを観察したためです。

 

「不適応」は(開発に限らず)問題を引き起こします。そして、「式年遷宮」と揶揄されるような(とても痛みを伴う)リプレースの引き金になったりします。式年遷宮はまだマシで、同一性をたもっていないような変更もたくさんあるでしょう。そういった状態に陥らないということ、「常に適応し続ける」ことを僕は「持続可能である」と考えています。

 

「持続可能」のために

正直なところ、この部分は書きかけといいです。といっても僕自身「持続可能にする」ために何ができるのかをまだ模索している途中だからです。とはいえ、やっていることはいくつかあります。

 

例えば、社内で有志をあつめて(あえて)業務とは直接関係なさそうだけど有用な知識に関する輪講を開いたりしています。これは、適用するためには基本的に今までやってきた延長線上とはやや異なる方向性の知識が必要になることがあるためです。現在はマイクロサービスについての本をそろそろ読み終えようとしており、次の題材を探し中です。

 

また、現在携わっているプロジェクトでも、長期的に開発者体験をブーストするような「experimental」なサブプロジェクトに対して少しリソースを投下する、みたいなことをしています。(https://github.com/facebookexperimental のパクリです)プロダクトのリファクタリングやテストの充実だけでなく、プロジェクト管理方法を変えたり、周辺ツールの開発や、新たな開発手法の提案とそれに移行するためのロードマップなど、いろいろなことを試みています。

 

おわりに

というわけで「持続可能」の説明とそのための試みでした。これらがうまくいくかはわかりませんが、それも経過が分かり次第書けたらよいなと思います。

最後に、弊社ではエンジニアに限らず様々な採用を行っており、また社内にも様々なメンバーがいます。よければですが、他の方の記事も見ると興味深いかもしれません。興味のある方はぜひお気軽に採用フォームや各種媒体から応募してください。ありがとうございました。

*1:人月の神話【新装版】 | Jr FrederickP.Brooks, Brooks,Jr.,Frederick P., 徹, 滝沢, 祐子, 牧野, 昇, 富澤 |本 | 通販 | Amazon

*2:「システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう」

ventusにおける「目指すべきエンジニア像」を再定義した話

f:id:ventus-inc:20211211172427p:plain

はじめに

こんにちは、株式会社ventus VPoEの野間です。

VPoEとしては採用、組織作り、勉強会の運営などを担当しています。

 

また元々の職種はフロントエンドエンジニアです。ざっくりエンジニアとしてこれまでやってきたことをまとめると:

などです!最近は社員の成長もあり(←素晴らしい!!)実際に手を動かすことは日々少なくなってきていますが、週100~200行くらいのペースで細々と書いています。

 

f:id:ventus-inc:20211208002834p:plain

一応ちゃんと書いてますよというアピールです

f:id:ventus-inc:20211208002827j:plain

これは最近自宅に導入したデカいディスプレイです。デカいディスプレイはいいぞ。(記事とは無関係です)

 

ventusの現状のエンジニア像

このたび採用などを進める中で、「ventusにおける『理想のエンジニア像』って何なんだろう?」という議論になりました。

 

まず、今のエンジニア組織は現状の業務量を回すのには非常に良くできていて、以下の点ではある程度成功しているのではないかという結論になりました:

  • ユーザにとって致命的なバグは発生していない
  • スケジュールに致命的な遅れは出ていない
  • メンバー間で不和が起きていない

そこでまずは、今いるエンジニア達の良いところをブレインストーミングでたくさん列挙してみました。

 

主だったものを挙げると:

  • 責任感がある
  • 職人気質
  • 細かいところにも気付く
  • 勉強熱心
  • 正しいことは正しいと認められる
  • 趣味や業務外の活動に熱心な人も多い

などが挙げられました。

 

ventusでは、以下のValueを定めています。

f:id:ventus-inc:20211211170753p:plain

ventusのValue

Valueは、社員が目指すべき姿そのものです。今回は個々のエンジニアが日々の業務において、このValueを体現していくためにはどういう行動をすれば良いのか?ということを考えました。その時に考慮したのは以下の3つです:

  1. エンジニア組織が今よりも大きくなった時のことを考える
  2. 現状のエンジニア組織の「良いところ」を残す
  3. Valueに沿った内容にする

理想のエンジニア像

f:id:ventus-inc:20211211170933p:plain

1つ目のValue「Fan/Fun First」では、ファンにワクワクしてもらえるサービスを提供するために、現在のventusの開発組織の特徴である「職人気質」なところが重要になると考えました。例としてUI/UXや応答速度、開発者体験の向上などを挙げましたが、こういった何気ない日々の業務で「細かいこと」を気にすることがひいてはユーザの喜びに繋がることを説いています。

 

また「全社でユーザの立場に立って考える」ことは、(会社がまだ小さい現状ではできていても)日々の業務に忙殺されたり役割分担が細分化していったりすると失われがちです。ユーザ目線のサービスを作っていくためには、ビジネスチームだけでなく開発者の視点も必要不可欠です。この「全員を巻き込む」文化は会社が大きくなっても残すべきだと考えました。

 

f:id:ventus-inc:20211211170937p:plain

2つ目のValue「Be the First」で推奨される「新しいことをやる」ことは、エンジニアにとっては「新しい概念」「新しい技術」に対して貪欲であることだと定義しました。ここでは、エンジニア個人にとって新しいことへの挑戦を全力でサポートし、それを誰もがためらわないようなフラットな組織を守ることを各個人に求めています。

 

さらに、得た知見を独り占めするのではなく、みんなで共有することでさらに新たな知見が生まれる好循環が生まれるのが理想だと考え、知識の共有も重要だと説いています。実際に現在ventusでは隔週土曜日でメンバーが持ち回りで発表するLT会が開かれたり、また特定のテーマの勉強会も散発的に開かれたりするなど、知見の共有は積極的に行われています。今後ともこのような共有を活発化させていきたいという願いを込めました。

 

f:id:ventus-inc:20211211170942p:plain

3つ目のValue「Be Freakin’ Geekでは、メンバーが個性を大事にしながら、会社におけるそれぞれの役割を最大限発揮できる環境であり続けたいという思いを込めました。今後組織が大きくなっても、各個人が自分だけのこだわりを持ってエネルギッシュに行動し、自分の個性を生かしながら輝いてほしい―そんな会社としての理想像を定義しました。

 

おわりに

今回の「目指すべきエンジニア像」は、エンジニア各個人が守るべき指針をまとめるとともに、会社がエンジニア組織に対してどうあるべきかを定めたものでもあります。今後、ventusではこの理想像を体現できる人を育てるとともに、各個人がこの理想像を体現しやすくなる組織をより一層整えていきます。


また、これは採用候補者の方に選んでいただける会社であるために策定したものでもあります。現在ventusでは積極的に採用を行っています。もし少しでもventusのことが気になった方、また「我こそは『目指すべきエンジニア像』にドンピシャだ」という方は、ぜひ採用ページからお問い合わせください!

 

ventus-inc.com

 

 

ORICALを支えるインフラ

f:id:ventus-inc:20211211172735p:plain

はじめに

こんにちは、ventus CTOの宮澤です。

 

CTOとしてはエンジニア採用や組織運営の仕事をしています。また、実際にバックエンド開発で手を動かしたり、実質この会社で1人しかいないインフラ担当として色々なサーバたちの面倒を見たりしています。

 

これまでにこの会社でエンジニアとしてやってきたことを簡単にまとめると、

  • Ruby on Rails を用いたAPIサーバ開発
  • バックエンド開発のPdM兼PM的な役回り
    • 開発方針の決定(これはみんなで)
    • 開発計画の策定
    • 技術選定
    • 仕様ぎめ、Issue立て
    • レビュー
    • その他定常タスク
  • 弊社で使っている全サーバの管理、運用
  • オペレーション周り
    • CS対応
    • データ作成

こうして書いてみるとなんでもやる人みたいになってますね笑 小さい会社あるあるな気もしますが...

 

f:id:ventus-inc:20211208002830p:plain

鯖缶のイメージ(実際はアラートが飛ぶのでこれとにらめっこすることは殆どありませんが...笑)

ORICALの現状

ventusでは、電子トレカ®︎コレクションサービスのORICALというプロダクトを運用しています。

現状では3つのパートナーさん(弊社では提携先企業さんのことをパートナーと呼んでいます)と一緒にやらせていただいており、それぞれの登録ユーザー数は以下の通りです(2021/11末現在)。

一日あたりのAU(アクティブユーザー)数は登録ユーザー数の半分弱なので、3サービスで1日約20,000人のAUがあるサービスを運用している計算になります。さらに、野球の試合が終わった直後などには「観戦限定トレカ」の受け取りのためアクセスが集中し、その際には大量のトラフィックをさばかなければなりません。

 

f:id:ventus-inc:20211208003349p:plain

野球の試合が終わった直後にはアクセスが集中します

このようにアクセスが集中した時にもユーザーがアクセスに時間がかかりすぎることなく快適に利用できるようにする必要があります。このためには、インフラ構成を適切に設計し運用しなければなりません。

 

ORICALを支えるインフラ

ventusでは、アクセスが集中した時やクラウドサービスプロバイダ側で障害が発生した時にも、サービス全体に影響を与えることなく対応できるようなインフラ構成を(紆余曲折を経ながらも)確立しています。

 

f:id:ventus-inc:20211208003445j:plain

ORICALの現在のインフラ構成

 

弊社では多くのスタートアップと同様に、クラウドサービスプロバイダとして主にAWSを用いてインフラを構築しています。

上のように図にしてみるとなにやら色々なサービスを使っているように見えますが、基本的にはフロントエンド(Webサーバ)、バックエンド(APIサーバ)、DBの三層構造です。

 

フロントエンドとバックエンドには AWS Elastic Beanstalk と呼ばれる PaaS を用いており、それぞれ Node.js と Ruby のプラットフォームを使っています。

PaaS を用いることでデプロイ管理や環境変数などの様々な設定項目を AWS 側に委譲することができるので、インフラ担当が実質1人しかいない状況では大変重宝しています。

また、Elastic Beanstalk は基本的に(デプロイ管理以外は)他の AWS サービスの寄せ集めなので、裏でなにがどのように動いているのか簡単に把握することができるのもメリットです。実際、Elastic Beanstalk は裏で CloudFormation を使って各種リソースを制御しているので、俺は自分で全部やる!という強者は EB を使わずとも CloudFormation を使えば同じようなことを実現することができます。

 

フロントエンドとバックエンドのサーバーはオートスケーリングを用いて、一定の負荷がかかると自動でスケールアウトするような仕組みになっています。

とはいえ、負荷ベースのオートスケールは発火してから実際に使えるようになるまで数分間のラグがあるので、事前に予測できる負荷増大に対しては時間トリガーのオートスケールも組み合わせて使っています。

 

また、低負荷時でも最低2AZにまたがるような構成にしているので、単一のデータセンターに障害が発生してもサービスが使えない...ということには極力ならないようになっています。

 

ちなみに、上の図にある他のサービスに関しては以下のようになっています。

  • AWS周り
    • Aurora (MySQL): メインDBサーバ
    • ElastiCache
      • Redis: APIサーバで使うログイン情報、決済情報その他の一時キャッシュ
      • memcached: APIサーバで使うアクセス情報の一時キャッシュ
    • ElasticSearch: サービス内のユーザー検索機能の提供
    • Lambda: サービス内 Twitter シェア機能の OGP 生成
    • S3: サービス内で提供する画像、動画の保存
      • CloudFront: S3と組み合わせてユーザーに静的ファイルを高速に提供
    • Route 53: 弊社の権威DNSサーバとして使用
  • 外部決済: 決済サービスは外部のものを使用
  • GCP周り
    • BigQuery: データ分析
    • Firebase Auth: ユーザー認証

 

おわりに

今回はORICALのインフラ構成を簡単に説明しました。

 

ventusではエンジニアに限らず、様々な職種で採用を積極的に行っています。他の記事も読んでいただき、ventusに興味を持っていただけたらぜひ採用フォームからお気軽にご応募ください!

ventus-inc.com

 

 

デザイナー目線!制作が捗るデザイン依頼書の4つのコツ

f:id:ventus-inc:20211211172845p:plain

はじめに

こんにちは。株式会社ventus クリエイティブディクレターの藤原奏人です。

ventusではクリエイティブ全般の制作・依頼・品質管理、採用や組織作りなどを担当しています。

個人としては、ロゴ、バナーや紙面などのグラフィックから、テレビCMなどの動画、Webデザインまで幅広く制作してきました。

ポートフォリオ

https://www.resume.id/nekohitosan/works

 

弊社のメインの事業である電子トレカコレクションサービスでは、1コンテンツ*1につき年間約2000種類のトレカが販売・配布されており、社内での制作はもちろん、そのうちの3分の1ほどを制作会社に外注する形をとっています。

 

トレカのサンプルは以下からご覧いただけます(各動画内に登場する4枚がここで指しているトレカです)

 

内製であれ外注であれ、デザインの依頼主は、いかにデザイナーが制作を進めやすい依頼書を渡せるかが成功の鍵となってきます。もしあなたが依頼主ではなくデザイナーであっても、これから紹介する内容を応用して依頼を理解することで、スムーズに制作を進められるでしょう。

今回は、デザイナーでありながら多くの制作依頼もしてきた私が、制作しやすい依頼書のコツをデザイナー目線でご紹介します!

最後に依頼書のサンプルも載せていますので、ぜひご一読ください。

 

 

制作が捗る依頼書のコツ① 目的と用途・仕様・納期が明記されている

「動画を依頼されたが、何秒に収めればいいのかわからない……」

「チラシのつもりが実はポスターで、文字が小さくて読めなかった……」

「初稿のつもりで出したら、最終締め切り日だった……」

デザイナーにとって、目的・用途・仕様・納期の4つは最も重要な事項です。不要なやりとりや、完成後に間違いが判明することがないように、依頼の段階でできる限り把握しておきましょう。

 

目的とは、その制作物がどのような人をターゲットにしていて、その人に何を伝えたいか、どのように行動してほしいかを指します。

用途は、その制作物の使い道(例:会場で手渡しする/Twitterに広告出稿する など)を指します。

この2項目が明らかにされていることで、デザイナーはより良いアイデアを考えることができます。

 

仕様とは、サイズやカラーモード、納品データの形式などを指します。

仕様に未確定の内容がある場合は、その旨を伝えてもらえれば、デザイナーは対処を考えながら制作を進行することができます(例:動画が15秒か30秒かまだ決まっていない→パートごとに分割して制作し、時間を調整できるように制作する)。

 

簡単に、代表的なメディアで必要な事項を列挙します。内容によってはこの限りではないので、参考程度にご覧ください。

 

印刷物

印刷物の場合は、仕様と印刷会社が決定していれば、その会社の入稿フォーマットを渡すことが一番手っ取り早いです。

 

  • 用紙サイズ:A4 など
  • 色数:片面1色/両面4色 など
  • カラーモード:印刷物の場合は基本的にCMYK
  • 加工の有無:折り加工 など
  • 解像度(画像が入る場合):300ppi以上 など
Webバナー
  • サイズ:970px × 90px など
  • カラーモード:Webバナーの場合は基本的にRGB

 

動画
  • サイズ:1920px x 1080px など
  • デュレーション:15秒 など
  • 音声の有無
  • その他にも動画では、フレームレート、ビットレート、前後の捨て素材の有無など詳細な項目が多数あります。

 

納期とは、制作物が依頼主の検収を経て完成とされるまでのスケジュールのことです。一般には修正作業などがあるため、最低でも初稿提出・修正稿提出・最終稿提出(納品)の3つの日程を決めておくと良いでしょう。また、依頼主が提出物を確認するための時間なども加味しましょう。

 

上述の事項に加えて、納品や請求の流れ、契約周りなども事前に打ち合わせておくと、デザイナーは制作そのものに専念することができます。

 

制作が捗る依頼書のコツ② 多角的なムードボードが用意されている

ムードボードとは、アイデアを伝えるために、成果物に印象の近い資料素材をコラージュしたもののことです。イラストや写真、文章にカラーパレット、音楽など、あらゆる角度から参考事例を用意し、まだ見ぬ成果物の輪郭をはっきりさせていきます。

 

ここを疎かにしてしまうと、依頼側の思い描いていたものと成果物にズレが生じてしまうため、できるだけ丁寧に用意しましょう。

 

例えば、クリスマスのポスターを1つ作るとしましょう。クリスマスと一口に言っても、様々な表現があります。

「可愛い?かっこいい?」「赤?白?緑?」「リアル?イラスト?」などなど、これ以外にも言葉では説明できないことが多くありますが、ムードボードを作成することでそのイメージをお互いにすり合わせることができます。

サンプルとして、ムードボードを1つ制作してみました。

ムービーボードの例

掲載する文字情報などは割愛していますが、これだけでもおおよその方針が掴めるのではないでしょうか?

このムードボードについては、依頼側が用意するのではなく、デザイナーに作成を依頼してみてもいいでしょう。デザイナーは様々な資料を探す中で、新しいアイデアに出会えるかもしれません。

また、多くのジャンルの参考資料を掲載することで、1つの印象に引っ張られすぎずに、盗用につながる恐れを減らす事ができます。

 

制作が捗る依頼書のコツ③ NG例が載っている

②では、イメージに近いものを掲載したムードボードを作成しましたが、それと合わせてNG例も載せておくと、より作るべきものが見えてくるでしょう。

NG例

 

制作が捗る依頼書のコツ④ 想像の余地が残されている

ここまでは、イメージを明確にするためのムードボード作りについて紹介してきました。

ここからは更に踏み込んで、テキストの配置や大きさ、フォント、使用する素材などを全て指定していきましょう。

 

……となってくると、ものを創りたいデザイナーからすると、決して良い依頼書とは言えないかもしれません。作るものの全てが指定されている依頼では、その指示以上のものが成果物として完成することはないでしょう。もちろん、依頼主が確固たるイメージや構成を持っていて、それを具現化する手段としてデザイナーを起用するのであれば話は別です。

 

デザインの依頼で大切なことは、デザイナーがものを考え、創造力を発揮する余地が残されていることです。その制作物の目的や用途、ここだけは外せないというイメージの希望を依頼書としてまとめたら、あとは作る本人を「表現のプロ」として信頼して任せることが、最も良い成果物に繋がると私は考えています。

依頼の中に残された余地から、デザイナーは表現者として想像を膨らませ、依頼主をあっと言わせるようなアイデアを捻り出します。目的やイメージを明らかにした依頼であればあるほど、この余地から生まれるアイデアは、成果物を一段と素晴らしいものに化けさせることでしょう。ventusでは、制作者の皆様が自身のクリエイティビティを遺憾なく発揮できるような制作環境の整備に努めています

 

▼今回作成したムードボードのサンプルはこちら

https://app.milanote.com/1MSZey1Cr9tr5I?p=BgSrpDQWbp2

弊社では参考事例を探す際は、主にhttps://www.pinterest.jp/を使用しています。また、ムードボードを組み込んだ依頼書の作成にはhttps://milanote.com/を活用しています。

 

一緒にトレカを作る仲間を大募集!

デザイナー目線から、制作が捗る依頼書のコツについてご紹介しました。デザインに従事していない方が依頼を書く際はもちろん、デザイナーの方もこの依頼の流れを自身の制作に応用することができると思います。

 

ventusのクリエイティブチームでは、デザイナーの皆さまが生き生きと制作に励めるように、今回紹介したデザイナー目線の依頼をはじめとして、さまざまな取り組みをしています。

私たちは年間約6000枚ものトレカを中心に様々なものを制作しています。そのどれもが日本を代表するコンテンツとの協業で、制作のしがいは満点。ありがたいことに、事業規模も日々拡大しています。

そんなコンテンツを更に盛り上げるために、ventusでは制作に心血を注げる仲間を大募集中! 気になった方は、ぜひお気軽に採用ページや各種採用媒体からご応募くださいませ。

ventus-inc.com

*1:現在、プロ野球埼玉西武ライオンズ千葉ロッテマリーンズ日本相撲協会という3つのスポーツコンテンツと協業しており、クリエイティブチームの行うトレカの制作数は実に年間約6000枚にも及びます。加えて、UI/UXや広報物などさまざまな制作を行っています。

全てはファンのために。次世代のファンビジネスをつくるventusの挑戦について

f:id:ventus-inc:20211211172946p:plain

はじめに

株式会社ventus 代表取締役CEOの梅澤優太です。

会社を創業して4年、ついに会社の公式ブログができました🎉

 

この4年間、様々な挫折や紆余曲折、コロナ禍などの大きな変化を乗り越えながら、まずはここまでくることができました。

 

荒波の中で事業の内容や戦略は少しずつ変化しながら進んできましたが、創業以来掲げたミッション、「全てのファンが、自分の『好き』に誇りを持てる世界をつくる」は、全くブレずに貫いてきました。

社員や関わってくれているメンバーにこの理念が浸透しているからこそ、同じ方向を向いてここまで進むことが出来たのだなと感じています。

 

ここをスタートラインとして、会社を次のフェーズへ前進させていくために、改めての自己紹介も兼ねて、ventusのこれまでとこれからを紹介したいと思います。

 

他のメンバーの記事も合わせて、ぜひご覧ください!

 

ventusがやっている事業について

私たち株式会社ventusは、スポーツ・エンタメ領域でファンのためのプロダクトを作り続けるスタートアップ企業です。

 

メインの事業として、電子トレカ®︎コレクションサービスのORICALというプロダクトを運用しています。

2021年11月現在、ORICALではプロ野球埼玉西武ライオンズ千葉ロッテマリーンズ日本相撲協会という3つのスポーツコンテンツとご一緒しながら、それぞれの公式電子トレカサービスを作っています。

 

lions.orical.jp

marines.orical.jp

sumo.orical.jp

 

「デジタルでのカードコレクション」だからこその仕組みや仕掛けに加えて、球場にいらっしゃった方だけがゲットできる限定トレカなど、リアルな応援と連動する仕組みを備えています。

動くカードのデザインやリアルタイム販売、試合と連動した機能など、ただのカードアプリにとどまらない、ファンの皆様にきっと楽しんでいただけるような取り組みも多数行っています!(そして様々な新機能を開発中です・・・!)

 

特にこの2年弱、球場や会場に行けない、思うようにエンタメが楽しめない、という皆様に向けて、デジタル上で新しい楽しみ方をお届けしようと尽力してきました。

少しずつですが、新しいデジタルコンテンツの一つとして、ファンの皆様に浸透しつつあるのかなと思っています。

引き続き、電子トレカを通して新しいデジタルコンテンツの形を追求し続けていきます。

 

コロナ禍とこれからのスポーツエンタメ界について

このコロナ禍では、言うまでもなくスポーツ・エンタメ界は大きな影響を受けました。

ライブや興行が無観客ないし観客数の制限下で行われる中で、入場料収入は激減し、「これまで通り」の興行・イベントが行えないという前代未聞の事態となりました。

 

この短期的な影響は、社会が正常化していく中で少しずつ回復していくものと思われますが(2021年11月現在、Bリーグ等が100%有観客での試合実施を目指すことを発表しています)、より深い問題として顕在化したのは、「既存のファンシステムが画一的で、来場前提のシステムになっていること」です。

 

これまで当たり前のように提供されてきたファンシステムの典型例は、「来場するとポイントが貯まって、特典でチケットがもらえる」「ファンクラブ加入の最大のメリットはチケットの先行抽選に参加できること」など、「来場」「チケット」がキーワードになっていました。結果として、このコロナ禍でいくつかのファンクラブでは大きな影響が出ています。

 

加えて、ファンクラブ等におけるいわゆる「コース」も、ファン一人一人の好みに応じたものではなく、画一的なシステムにとどまっているのが現状です。

ファンコミュニケーションがSNSなどのデジタル上での形式がメインとなり、本来であればマスマーケティングからファンの個別化に転換すべきなのに、理想とは離れた状態となっています

 

ファンビジネス企業として、ventusが目指す場所

これからのventusは、ファンの皆様に楽しんでいただける「コンテンツ」を作り続ける企業でありながら、この業界に新たなファンシステムの形をお届けできるよう「仕組み」もアップデートしていく企業として、事業を拡大していきます。

 

「コンテンツ」と「仕組み」は決して別々のものではなく、不可分な、表裏一体のものとして、私たちはセットで新たなサービスを作り続けていきます。

 

先ほど述べたように、このスポーツ・エンタメという業界にも様々なテクノロジーの波が押し寄せ、新たな楽しみ方や提供価値が多数生まれていくでしょう。

しかしながらその中では、常に「ファンの皆様が楽しめるものか?」が最も重要です。

ventusはテクノロジーの力を最大限活用したスタートアップとして事業を進めていきますが、ファンの皆様に寄り添った企画を徹底して泥臭く出していく姿勢は変わりません。

 

電子トレカに代表される新たなデジタルコンテンツの開発・運用に加えて、ファンの個別化を目指した新たなファンシステムの構築まで一気通貫のファンビジネス企業として、事業推進をしていきます。

 

おわりに

電子トレカを中心に事業推進してきた「これまで」と、この業界の課題、ventusの「ここから」の展開について、まとめて書いてきました。

 

熱量の高いデジタルコンテンツから全く新しいファンシステムまで、私たちの描く次世代のファンビジネスを作り出すには、アツく、優秀な仲間が必要です・・・!

きっと次のファン文化を作り出せるような、そんなとてもやりがいのある仕事なのではないかと思っています。

ぜひお気軽に、採用ページや各種採用媒体からのエントリー、もしくは梅澤のSNSまで、「我こそは!」という方のご連絡をお待ちしております。

 

一緒に、新しいファンのためのコンテンツ、システムを作っていきましょう。

全てはファンのために。

 

これからも、株式会社ventusをどうぞよろしくお願いします!

ventus-inc.com