for Startups Tech blog

for Starupsのテックブログです

「STARTUP DB」に込められた想いとは?

f:id:forStartups:20211108190136j:plain

こんにちは、フォースタートアップスで運営している成長産業に特化した情報プラットフォーム「STARTUP DB」のプロダクトオーナーの寺田@yuyateradaです。

今回は「STARTUP DB」とはそもそもどのようなプロダクトか、直近リリースしたENTERPRISE機能、今後の戦略についてご紹介します。

 

「STARTUP DB」が目指すGOAL

f:id:forStartups:20211108185630j:plain

STARTUP DB」は国内13,000社以上のベンチャー・スタートアップ企業の情報、起業家・投資家、エコシステムビルダーの方々累計150名以上のインタビュー記事が閲覧できる情報プラットフォームです。エコシステムビルダーは国内スタートアップエコシステムに関わるVCやCVC、大手事業会社、海外企業、金融機関、政府自治体、教育機関などあらゆるステークホルダーの方々を対象にしています。

プロダクトのゴールは「国内スタートアップエコシステムのキャッシュフローを増やすこと」です。そのプロダクトゴールに向け、「国内スタートアップとエコシステムビルダーの方々がそれぞれ信頼のできるパートナーと出会いをつくっていくこと」を目指し、運営をしています。「STARTUP DB」があることで、スタートアップエコシステムがブーストされ、インフラとなるような存在を目指しています。

STARTUP DB」はデータベース販売しているとイメージされることもあるのですが、あくまでも企業データベースはスタートアップエコシステム内での良い出会いをつくっていく手段として考えています。

また、プロダクトポリシーとして、会社のバリューでもある「Startups First(注1)」を1番の重きにおいています。プロダクトポリシーである「Startups First」を大事にしている事例として、よく色々な企業よりデータベースを営業リストとして販売してほしいという問い合わせを頂くのですが、提供をお断りすることがあります。スタートアップは限られたリソースの中で事業運営をしているため、営業の問い合わせ数が増えてしまうことで事業運営におけるノイズになってしまうことがあるためです。もちろんプロダクトしてマネタイズは大事でありますが、信頼のできるパートナーとの出会いをつくる場として価値提供していくこと、軸をぶらさないよう大事にしています。

現在、メインの企業データベース以外の機能では、スタートアップ向けの無料会員機能「CLUB」、スタートアップとの事業創造をサポートする機能「ENTERPRISE」(次の章で紹介)を提供しています。

その他「STARTUP DB」が保有するスタートアップのデータは、テレビや新聞、雑誌などの様々なメディアへのデータ協力や、金融機関や大学研究機関、政府自治体といった公共機関のリサーチにもデータが活用されています。

f:id:forStartups:20211108185700p:plain

注1:全ては日本の成長のために。スタートアップスのために。スタートアップス=『進化の中心』にいることを選択する挑戦者達。

 

スタートアップとの事業創造をサポートする機能「ENTERPRISE」

スタートアップとの事業創造をサポートする機能として「ENTERPRISE」を21年7月に正式版をリリースしました。主に大手事業会社や投資家を中心としたエコシステムビルダーの皆様と国内スタートアップ、それぞれが信頼のできるパートナーとのアライアンス機会をつくるための機能になります。

現状スタートアップとの事業創造における課題として、「Googleなどの検索サービスを利用しても、網羅的に効率よく調べることができていないこと」や「比較検討の際に、類似企業の抽出などのリサーチや情報整理に時間がかかってしまっている」などが生じています。ENTERPRISEを導入頂くことにより導入企業社の業務工数の削減、業務クオリティの向上に繋げていきたく、以下のような機能を提供しています。

①スタートアップに詳しい専門チームのサポートにより精度の高いソーシングに対応

f:id:forStartups:20211108185727p:plain

②無制限でエクセルデータのダウンロードが利用可能

f:id:forStartups:20211108185753p:plain

検索したスタートアップ企業の一覧で、表示順上位100社を一覧データとしてダウンロードできます。企業紹介、合計資金調達額など分析に必要なデータを全て提供しています。また、個別の企業ページからファイナンス情報などの詳細データをダウンロードすることも可能です。これらのデータダウンロードが回数無制限で可能です。

 

③すべての検索機能が利用でき、すべての検索結果から比較検討が可能

f:id:forStartups:20211108185805p:plain

ソート機能や全検索結果の閲覧、類似企業情報が可能になります。一般ユーザー様は検索や検索結果の表示数などの機能に一部制限がかかります。

それ以外にも、現在新機能を仕込んでいますので、乞うご期待ください。

 

絶賛仲間募集中です!

今後は現状機能としてある「CLUB」と「ENTERPRISE」を基盤としながら、スタートアップエコシステム内でのより良い出会いをサポートする機能を色濃くしていく予定です。スタートアップ×エコシステムビルダーやスタートアップ同士、エコシステムビルダー同士などの様々なパートナーとの出会いが同時多発的に創出されるようにするために、まだまだ仲間が必要です。

少しでもご興味頂けそうな際は、是非カジュアルにお話をしましょう!

 

▼Meety特集ページ
https://meety.net/articles/t2--lbkb5t1gd9

Wantedly
https://www.wantedly.com/companies/forstartups/projects

ブラウザで本番データの分析をするためにRedashとGoogleColabを組み合わせてみた話

f:id:forStartups:20211020185235j:plain

こんにちは。エンジニアの藤井(@yutafujii)です。

社内向けのプロダクト「タレントエージェンシー支援システム(SFA/CRM)」のエンジニアをしています。

当社ではデータ分析を専門に行う人がまだいないので、私たちエンジニアがごく簡単なデータ分析を行う場面があるのですが、それを行うためにPythonでの分析環境を手軽に構築しました。

具体的には、複数のRDBやログデータを対象に、RedashでSQLを書いてデータレイク的状態(あるいはデータウェアハウス的状態)を形成し、Google Colaboratory(以下Colab)を用いてその出力をPythonで分析するという流れを説明します。

データ分析を本格化する前のサービス運用をしているPdM・エンジニア・マーケターや、片手間にPythonで分析したいという人を想定読者とさせていただきます。

モチベーション

一言でいえば「データ分析基盤もないし分析者もいないけどちょっとデータ分析したい」というのがこれを思いついたきっかけです。

私は本業がプロダクト開発でデータ分析をする稼働もあまり割けないという事情もあり、いきなりがっつり構築して運用コストがかかるのは避けたいところでした。というわけでざっと満たすべき制約や要件を挙げると次のようなものになりました。

要件

  • Pythonで分析できる
  • 分析が属人化しないこと
  • 当たり前ですがセキュリティリスクが低いこと
  • 運用コスト(労働コスト・費用)が低いこと

なお私が入社したときには既にBIツールとしてRedashを利用している状態でした。

Pythonで分析するだけであればBIツールのSQL結果を自分のPCにダウンロードして、ローカルで立ち上げたJupyter Notebook上で分析するということで良いのですが(もちろんこれもやりました)、分析方法や結果の共有をするために

  • GitHubを通して分析コードを共有する
  • 共有者のローカルでjupyterを立ち上げる
  • データをローカルにダウンロードしてもらい分析する

という複雑なステップを踏む必要があります。また、本番データがローカルPCに蓄積することのセキュリティリスクも気になります。

共有のしやすさという観点からブラウザ上で分析したいなと思いつつ、Jupyter NotebookコンテナをAWSのサーバーで起動させることも考えましたが、そこまで使わないのにメンテナンスも認証もセキュリティ対策も全部自分でやるのは面倒だなと思い、Colabを思いつきました。

初めて知る方のためにも、RedashとColabについて簡単に説明しておきます。

Redashとは

f:id:forStartups:20211019215332p:plain
f:id:forStartups:20211019215401p:plain
出所)LP

RedashはオープンソースのBIツールです。弊社ではEC2に載せてRedashサーバーを起動することでブラウザから利用しています(これらの構築手順もHPに載っています:https://redash.io/help/open-source/setup)。

Redashにはざっと以下のような機能があります。

1.認証・認可

Google OAuthの設定が容易にできる。また権限設定も簡単

2.複数のデータソースと接続

RDBMS、各種NoSQL、Google Analyticsスプレッドシートなど

3.クエリ結果の保存

→Redashが保有する固有のデータベース(SQLite3)に格納される

4.クエリ結果へアクセスするAPIの発行

CSVJSON形式でそれぞれ固有のURLが発行される

5.複数ソースからデータの結合

→クエリ結果を保存するRedashのデータベースに対してSQLを発行することで実現

これらの機能を活用することで、データレイクや、データウェアハウスを形成することができます。クエリを書かずに集計ができないため非エンジニアが使いにくいとか、クエリの説明を付ける場所が小さすぎて出力数字の定義を把握しづらいとか、承認フローなどがないのでSQLが一方的に増えがちなどの課題もありますが、それでもクエリを一元的に発行出来る場所があることは非常に助かっています。

Colabとは

f:id:forStartups:20211019215446p:plain

Colabの愛称で利用されているColaboratoryはGoogleが提供しているサービスで、ブラウザでのPython実行環境を提供しています。その特徴は

  • 構築作業がゼロ
  • GPUへのフリーアクセス
  • シェアの容易さ

というもので、今回の要件にどストライクなサービスです。pipにもanacondaにも触れることなくいきなり

import numpy as np
import pandas as pd
import seaborn as sns

from sklearn.linear_model import LinearRegression
from sklearn.model_selection import train_test_split

といったコードを書き始めることができます。

Google Driveと同様のアクセス権限・共有設定が可能なので、認証と認可も実装することなく使えます。ソースコードや演算はGoogleクラウド上で行われますが、利用規約を読む限りそれらがGoogleに利用されるということはなさそうです。もちろんGoogle側の脆弱性があった場合に自分たちのデータもリスクに晒されるわけですが、一旦このリスクは許容しています。

f:id:forStartups:20211019221815p:plain
Colabの利用イメージ

構成

というわけでRedashとColabを組み合わせてできる分析構成は以下の通りになります。

f:id:forStartups:20211019221914p:plain
全体の構成

まず、Colabで分析したいデータをRedashで構築しておきます。

Colab側で利用するSQLを作成し

f:id:forStartups:20211019221959p:plain

右上の3点リーダーから「Show API Key」を選択

f:id:forStartups:20211019222023p:plain

クエリ結果へのアクセスリンクが表示されるのでJSONフォーマットのURLをコピー

f:id:forStartups:20211019222047p:plain

Colabを開いて、あとはコピーしたURLにアクセスするだけです

f:id:forStartups:20211019222104p:plain

Colabサンプルコード

import numpy as np
import pandas as pd
import requests
import json

# Redash query resultにリクエスト
URL = 'https://YOUR_REDASH_DOMAIN/api/queries/QUERY_ID/results.json?api_key=XXXXXXXXXXXXXXXXX'
raw_html = requests.get(URL).content
x = json.loads(raw_html)

# Create Dataframe
d = x['query_result']['data']['rows']
df = pd.DataFrame(d)
df

以上です、構築は非常に簡単ですし、エンジニアでなくてもできるのではと思います。

実際に作られたColab上での分析です。快適ですね。SQLでは面倒な集計、細かい設定の可視化や線形回帰などを実際に書いています。

f:id:forStartups:20211019222130p:plain
実際に分析したグラフ

おわりに

冒頭の「モチベーション」で記載した「データ分析基盤もないし分析者もいないけどちょっとデータ分析したい」という目的と制約要件は、Redash + Colabで問題なく充足することができました。

要件

Pythonで分析できる

 →ColabでPythonを利用できる

分析が属人化しないこと

 →ColabはURLシェアだけで他の人とシェア可能

当たり前ですがセキュリティリスクが低いこと

 →認証、サーバー構築を自作せずGoogleにリスクを転嫁

運用コスト(労働コスト・費用)が低いこと

 →Colabはフリーで利用可能

構築の手間を考えると非常に便利だと思いつつ、今後はしっかりデータパイプラインを構築してデータレイク・データウェアハウスをきちんと整えていきたいところです。現状ではまだ乱立したローデータと、データレイクとデータウェアハウスが混在したようなRedashクエリ結果しかないため、このあたりを改善してくれる人がいたらぜひお話しさせてください。

【フォースタ テックブログ】デザイナーがコーポレートサイトをノーコードツールのWebflowを使ってリニューアルした話

 

フォースタートアップスは2021年7月にコーポレートサイトの大幅なリニューアルを行いました。

www.forstartups.com

今回、このリニューアルに関わったデザイナー2名(甲斐・長峰)より、ノーコードでWebサイト制作ができるWebflowを利用するに至った背景や、グラフィックについてのこだわり、制作で苦労した点などについてご紹介します。

www.wantedly.com

www.wantedly.com

TechLab.でノーコードツールを使うという選択

甲斐:
エンジニアリングチームであるTechLab.には複数名のエンジニアが所属しています。SREをはじめ、バックエンド・フロント、もちろんデザイナーも在籍しています。Webサイトを制作するスキルを十分に保持したチームですので、今回ノーコードツールを選択した理由は技術や実装面の問題ではありませんでした。多くの企業が同じ課題を抱えていると思いますがコーポレートサイトという特性上、多くの時間と予算を使って作成するというものでもありません。テックラボも日々ビジネスを加速するためのタスクに追われています。今回フォースタがコーポレートサイトのリニューアルの実行に舵を切れたのは、チームが常に新しい事にチャレンジしようとする文化があったからだと思います。結果として、ノーコードツールを使用した知見は今後の開発にも大きく役にたつものになりましたし、PRやブランディング、そしてHRの観点からもメリットが大きかったと思っています。

Webflowにした理由や背景

甲斐:
「ノーコード」という言葉を耳にする機会が増えた方も多いと思います。実際フォースタでもノーコードを使ったWebページを作成した事はありました。ノーコードツールの印象としては「お手軽にWebページが作れる」といった感じです。しかし既にフォースタのコーポレートサイトをご覧頂いた方はお分かり頂けたと思いますが、決してお手軽にスピード重視で作成されたサイトではありません。今回のコーポレートサイトはフォースタのブランドを大切に、コンセプトメイキングからはじまり、ペルソナ・ユーザーストーリーなどをしっかり設計、ブランドを生かしたグラフィックとアニメーションにも挑戦しました。プロジェクトは約半年をかけたものです。

私たちが重視しこだわったのは、更新のしやすさとフォースタのブランドの再現でした。更新のしやすさでいうと、CMSやノーコードツールが挙げられると思います。フォースタでもWordPressといったCMSを利用してはいましたが、テンプレート部分などはエンジニアへの修正依頼が必要であったりして、時期に寄ってはなかなか修正の工数が割けないといった状況も発生しました。実際にフォースタのコーポレートサイトは2019年4月にリニューアルして以降、追加で開発することはあまりできませんでした。上場時にIRページを追加した以外は細かい変更を行うのみでした。しかし、フォースタという会社も事業拡大しており、その拡大しているフォースタと共に進化していくコーポレートサイトを作るということが課題でした。そこを解決してくれそうだと考えたのがWebflowです。Webflowであれば、デザイナーとコンテンツエディターが直接Webサイトを更新できます。デザイナーが直接サイトを更新出来るというのは、先に挙げたフォースタのブランドをデザイナーが直接表現できるということでもありました。

デザイナーのみで作り上げるWebサイト

甲斐:
一般的なWeb開発の場合、デザイナーが作ったカンプを元にバックエンドエンジニアとフロントエンドエンジニアが実装するというイメージが多いかと思います。しかし今回私たちは、最初に練り上げたコンセプトやユーザーストーリーを元に、UXデザイナーが作ったワイヤーから直接WebflowでWebデザインを行うという工程に移りました。

今回のコーポレートサイトに携わったデザイナーはグラフィックデザイナー(長峰)とUXデザイナー(甲斐)の2名です。10数年に渡るグラフィックデザイン歴のある長峰にとって、Web制作は大きなチャレンジでもありました。これまで担当してきたパッケージなどのクリエイティブとWebデザインでは画面内での表現やレイアウトの考え方に違いがあったからです。それにプラスして動きといったモーションデザインもとてもチャレンジングな作業となりました。さらに今回は会社のミッションのアップデートも重なり、それにともなった新しいグラフィックもうみだされました。

これまでのフォースタのブランドを引き継ぎ、次なる進化を表現したトップ画面

 

サイトのキーグラフィックを「挑戦者の広がり」をテーマに制作し、トップ画像などに展開

 

各サービスのビジュアルを開発し、それぞれの特色を出しながら全体のトーンを合わせた。

 

トップページのサービスメニュー

 

デザイナーが直接デザインを行っていけるWebflowはとてもパワフルなツールです。HTML/CSSの基礎知識があるデザイナーであれば十分に使いこなせますし、フロントエンジニアであれば問題無く実装に利用出来ると思います。私自身Webサイトのコーディングをこれまでいくつも行ってきましたが、コーディングを行う頭の使い方でGUIを使って実装していけるのがとても便利だと感じました。これまでの方法ですと、コードを考えて、書いて、書き出して、確認する…といういくつかのステップが必要でしたが、ブラウザ上で直接GUIを使って操作できるので、そうしたステップが大いに短縮できました。必要なパーツは共通コンポーネントとして使えたりもするので、メニューやフッターなどに変更があった場合でも1回の更新ですべてに適用することができます。必要なのはブラウザだけなのです。

グラフィックデザイナーがWebデザインに挑戦

長峰
私は前職のデザイン制作会社でグラフィックデザインに13年以上、アートディレクター・デザイナーとしてロゴデザイン・パッケージデザイン・広告・ポスター等の制作、商品撮影・モデル撮影等のディレクション・デザインに従事してきました。半年前よりプロジェクトメンバーとしてキックオフから参加し、グラフィックデザイン、WEBデザイン、実装と広く関わりました。Webflowを使って実装したのですが、過去に使用したことのあるノーコードツールのSTUDIOとは全然違いました。Webflowはコーディングと同じ仕組みで作られたアプリケーションで、クラスの設定やコードの埋め込みなど、最初ははっきり言って訳がわかりませんでした。しかし、公式の豊富なレクチャー動画や公開されているデザインデータを研究することで一つ一つ理解していきました。

コーポレートサイトのWEBデザインへの挑戦は非常にチャレンジングな仕事で幾多の壁がありましたが、心強い仲間と力を合わせることで乗り越え、リリースすることができました。

グラフィックデザイナーが苦労したポイント

長峰
私が苦労したポイントが大きく3つあります。
1つ目は、グラフィックデザイナーならではの壁だと思いますが、WEBのデザイン・実装の経験が少ないため、何ができて何ができないか、できる場合どれぐらいの工数がかかるかがわからないことです。想像がつかないのでデザインも進めにくいという事態になりました。しかし、WebflowのいいところはGUIで実装しながらデザインできるところで、想像つかないところはまず実装してみることで感覚を掴みました。

2つ目はHTML 、CSSCMSなど専門的な知識がないと理解しづらい部分があるということです。幸い、私はフォースタートアップスでTechLab.に所属していて優秀なエンジニア・デザイナーがいるので相談したり力を借りたりすることで乗り越えました。また公式が運営しているWebflow Universityというサイトがあり、豊富なレクチャー情報があります。英語なので最初はとっつきにくいかもしれませんが、Google翻訳などを駆使して読み解くことで解決できました。他にもWebflow Forumというサイトは様々な質問に対してみんなで答えるサイトがあり、大抵の困りごとはそこで見つけることができます。

3つ目はインタラクティブの部分です。アニメーション表現やユーザーのスクロールやカーソルに対しての表現はフォースタの進化を伝えるためにどうしてもチャレンジしたいものでした。しかし、本来そこはCSSやjsなどのコードによって実装するものでかなりハードルが高いものです。しかしWebflowであればインタラクティブに関しても多くの機能がありGUIでプレビューしながら進めることができ、表現したいイメージに近づくことができました。

WordPressからWebflowへ

甲斐:
コンポーネントやテンプレートといった考え方はWordPressでもなじみのあるものだと思います。世界で最も導入されているCMSであるWordPressは多くのコーポレートサイトでも使用されていると思います。しかし今回フォースタで利用したWebflowは今WordPressに置き換わろうとしています。多くの人がWordPress程できることの多いCMSは他にないだろうと考えていると思います。私もその1人でした。しかし今回私が半年をかけて担当したWeb開発で、WordPressに著しく劣っていると感じた部分はありません。むしろPHPJavaScriptの知識が無くても実装できる点で優位と言えるのではないかとさえ思います。確かに細かい点でPHPが使えれば便利(実装が早そう)だなと思う点はありましたが、結果として実現したいことでWebflowの機能で実現出来なかったことはありませんでした。

今回の開発では使用していませんが、ECの機能も付いています。コーポレートサイトだけでなく用途は大きく広がると思います。さらに作業を自動化できるZapierなどの外部ツールとの連携も可能です。例えば、お問い合わせフォームからの投稿があった場合には社内のSlackにリアルタイムに通知を送ったり、自動でスプレッドシートにお問い合わせ内容を格納したりと言うことが可能です。コーポレートサイトを入り口として発生するお客様対応などを一部自動化することで、1人に集中しがちな作業の負担を減らし、分担もしやすくなりました。

インターフェースが英語なので不安に思っている方もいるかもしれませんが、これまでWeb制作を行ってきた方にはなじみのある用語ばかりですので問題無いと思います。

おわりに

今回のコーポレートサイトのリニューアルは、デザイナー自身がWebflowというノーコードツールを使って実装しただけではなく、会社のミッションのアップデートに伴った新たなグラフィックを生み出したり、ブランディングや設計を、PRや時には経営陣と共にしっかり練り上げてゴールまでたどり着いたプロジェクトです。作業を行うだけではなく、デザインやエンジニアリングの力をフルに生かしてアイディアを形にする職場に魅力を感じるデザイナー・エンジニアの皆様の参画をお待ちしております!

【フォースタ テックブログ】技術書典への初めての出版物を書籍にしていただきました!

テックラボグループが有志を募り、2020年12月に技術書典に応募。その後2021年5月にインプレス社経由で出版を果たした。今回の記事では出版に至った経緯とその裏側に迫る。

▽▽▽今回出版に至ったVol.1▽▽▽

https://www.amazon.co.jp/dp/B097D6B8QY

 

-この度は初の技術書典での出展および本の出版、おめでとうございます!
 そもそも技術書典に応募しようと思ったきっかけや走り出しはどんなものだったのですか?

井原:
軽い気持ちで「技術書典に出してみたいね」と提案したところ話が盛り上がり、自然と集まったメンバーで書くことになりました。10月から執筆作業に取り掛かり約2ヶ月間で仕上げていったのですが、話し合いで決めたのは「10ページを目安に書き上げること」程度で、テーマに関しては特に戦略を立てて決めることなく各々の興味関心が高い分野で好きに書き始めました。

井原

 

-技術書典への応募・本の出版にあたり大変だった点や苦労した点を教えてください。

藤井:
内容の質の高さを出すのに初めはプレッシャーを感じました。執筆自体初めてのことですし、個人ブログではなく会社として発信するものだったため、読者に何かしらの発見を与え、読んで良かったと思ってもらうにどうするべきかと随分苦悩しました。後々自身で振り返って「このテーマは他の人に負けないくらい考えた」と思えるくらい考え抜こうと自問自答を繰り返しながら書きました。

藤井

 

村林:
通常業務に加え、テックブログの執筆や勉強会、ウェビナーの登壇も控えていた中、応募時と出版時で記事のフォーマットが異なっていたことが発覚しそのディレクションや編集作業に思いの外手間取りました。具体的にはRe:VIEW StarterからRe:VIEWに変える作業だったのですが、フォーマット変更に伴い表示にズレが生じてしまってないかを一つ一つ確認する必要があったのです。結果かなり出版ギリギリの提出にはなりましたが、なんとか間に合いホッとしたのを覚えています。

-今回記事を書いたことで良かった点や学んだことなど簡単な感想を教えてください。

村林:
自身のやっていることの言語化に繋がった気がします。全体像を気にせずバラバラ書いていったからか普段自分が感じている点や思っていること等が文章として顕著に落とし込まれていく感覚はありました。

村林

 

戸村:
フォースタでの自身の歴史を棚卸ししていくような内容だったので、これまでの振り返りができました。ヒューマンキャピタリストとして人材紹介事業に携わっていた頃から、エンジニアとしてテックラボに参画し現在のCTOを任されるまでの軌跡とともに「組織」について触れられたのは自身にとってもとてもいい経験だったと思います。

藤井:
メンバーの新たな“強み”を知れました。例えば村林さんは大学時代新聞部だったこともあり、キャッチーなタイトルをつけるのが上手でした。本文を書き出したはいいものの、読みたいと思わせられるタイトルをつけるのは文字数が少ない分想像以上に難しかったので、それをサラッと出していた村林さんはシンプルに凄いなと。

「何よりも実際に書籍として手元に届いた時は本当に嬉しかった」と話す皆さん

 

-技術書典に出した後の反響等はありましたか?

戸村:
知人からの買いました連絡を何件かいただきました。当時、Twitterで技術書典の購入ツイートを購買者がつぶやく度Slackに流れるよう連携しており、その通知が届く度に皆で盛り上がっていました。中にはその後に個人的に挙げた振り返り記事を見て購入したとツイートしてくれた人も。
執筆当初に想像していたよりも多くの方に閲覧いただけたようです。

-書籍の話が来てから本が出るまではどんな流れだったのですか?

戸村:
技術書典を出してからすぐにインプレス社からDMが届きました。あまりに掲載直後のDMだったので思わず一瞬半信半疑になってしまった程です(笑)

ですがせっかくいただいた話ですし、Amazonや書店で並んだ方がより成果を形に残せると思い、出版することにしました。契約締結後はSlackでのやりとりに移行し、村林さんに出版準備全般のディレクションをお任せしました。

村林:
インプレス社から出版話を持ちかけられた2020年12月がちょうどサービスのリリースのタイミングだったため、準備期間は多少長めにいただきました。フォーマットの修正やAmazonでの書籍紹介文の作成、表紙をご担当いただく絵師決め、ラフ画すり合わせ等で都度やりとりしながら、無事2021年5月25日に出版することができました。

また、2021年7月に今回新たなメンバーで書き上げたVol.2を技術書典11に出しました。Vol.1とはまた違ったテーマを取り上げた渾身の一冊となっております!(急な宣伝)

techbookfest.org

-最後に、今回の総括をお願いします。

戸村:
フォースタートアップスのバリューの一つである “Be a Talent”は、「自らの生き様を社会に発信せよ」というメッセージが込められており、なかなかエンジニアとして体現が難しい中、テックブログや勉強会等で積み重ねてきたものを公に出せたのは良かったです。引き続き、技術書典も含め、よりいろんな挑戦を発信していけるチームにしていきたいと思っております。

CTO 戸村

Slackを最高に使いこなすためにフォースタがやっていること

f:id:forStartups:20210817154912j:plain

どうも、フォースタートアップスでエンジニアをやっています村林です。

皆さん「Slack」使っていますか?Slack最高ですよね。
弊社もSlackバリバリ使っていて、Slack無いと仕事できないくらいには依存しているのですが、組織が拡大する中で様々な問題が出てきました。

チャンネルが多すぎてよくわからない

弊社は誰でもチャンネルを作成できます。そのためどんどんチャンネルが作成されていき、その結果大量のチャンネルが存在しています。それだけなら良いのですが「チャンネル名のルールがない」「チャンネルの説明がない」などの理由から目的のチャンネルが探しづらい状況になってしまっていました。

これはいかんということでSlackの活用ガイドラインを一部の有志で考えました。

Slack活用ガイドライン、チャンネル命名のルール

原則: 部署名_チーム名_目的で作る
特に接頭句に関しては以下のものから使ってもらっています。

  • 部署内に閉じる場合

ac_ :アクセラレーション本部
cp_ :コーポレート本部
hr_ :人事
oi_ :オープンイノベーション
ta_ :タレントエージェンシー本部
tl_ :テックラボ

  • 部署をまたがる場合

all_ :全員いるチャンネル
pjt_ :部署がまたがる(2ヶ月以上)
tmp_ :一時的な集団(2ヶ月未満)

  • その他の用途

guest_ :他社の方との連携チャンネル
info_ :情報共有系
notify_ :システムからの通知
club_ :趣味系

以上がチャンネル名のルールです。

具体的な例としては

pjt_startupbdb
弊社が展開しているSTARTUP DBに関して話し合うチャンネル

all_branding_pr
社外向けの情報周知がされるチャンネル

club_ラーメン
ラーメンの画像を貼るチャンネル。「今日のラーメン」と書けばラーメンじゃない画像を載せても許される風潮がある。

そこまで堅苦しいものにすると、実運用されないなと考えたことから接頭句のみ縛りを加え、それ以外は比較的に自由に設定できるようになっています。このルールが作られてから半年くらいですが、最初は守られていないケースも多々ありましたが、最近は殆どこのルールに従って作成されています。

ちょっとした命名規則ですが、あるとないとでは検索性、視認性が段違いなのでSlackのチャンネル多すぎてお困りでしたら皆さんもぜひやってみてはいかがでしょうか。

DMが多い

これもあるあるですよね。
「みんなの注意を向けられるほどの内容でもない」「変なことを聞いて恥をかきたくない(恥をかく対象範囲を最小限にしたい)」などの色んな理由から人はpublicなチャンネルではなく、DMを使います。
気持ちはわかりますが、DMは完全に秘匿された状態なので、そこで交わされた内容は誰の目にも触れることがありません。知識が社員の間で偏在し、横展開されることもなくなります。

Slackの素晴らしいところのひとつに検索性の高さがあると思っています。
Slackは検索能力が素晴らしいので「なんでこうなってるんだろ?」「これ今どうなってるのだろう」ってなったときに検索すれば大体経緯が出てきます。これは対面、電話、Zoomのいずれのコミュニケーション手段も達成していない価値なので是非活用しましょう。

でもたまにDMで感謝を伝えたり、伝えられたりは好きだったりします。なんかいいですよね(個人の見解)

ということで、この状況を打破するために以下の指針を出しました。

DMはやめて個人チャンネルでやり取りする

個人チャンネルは「分報」「times」などとも呼ばれていますが、特定個人のためのチャンネルです。個人チャンネルはpublicで作られているため、誰がどこのチャンネルに入ろうが勝手ですし、検索にも出てきます。また個人チャンネルという特性上、その人に関する話題なら何を振っても良い(良さそう)なため、publicなチャンネルでありつつも投稿をする心理的ハードルを下げるという効果を狙っています。

 

ということで、slackの困りごととそれに対応した話でした。
Slackのガイドライン策定などは色んな人の思いを汲んでやらなければいけないため、正直とても面倒くさいし、別に誰からも喜ばれない行為ではあります。
ただ、ちょっとした指針があるだけでみんなハッピーになりますし、Slackをみんなが使いこなす様を見ていると嬉しいので引き続き改善していければ良いですね。

We are hiring !

フォースタートアップスはエンジニア・デザイナーを積極採用中です😃

もしこの記事を読んでフォースタートアップスに少しでもご興味をお持ち頂けましたら、下記の「話を聞きに行きたい」ボタンより気軽にエントリーしてください。

事業やチームについての説明から技術スタックの解説まで、CTOやチームメンバーからさせていただきます。

【フォースタ テックブログ】RepositoryFactoryパターンをVueのAPIリクエストに導入する

こんにちは。エンジニアの藤井(@yutafujii)です。
社内向けのプロダクト「タレントエージェンシー支援システム(SFA/CRM)」のエンジニアをしています。

プロダクトはフロントエンドをNuxt/TypeScript・サーバーサイドをRailsで実装しているのですが、今回はフロントエンドのAPIリクエスト処理にRepositoryFactoryパターンを導入した話をさせていただきます。

RepositoryFactoryパターンとは

RepositoryFactoryとはAPIを呼び出す設計のデザインパターンとして、JorgeというVueエヴァンジェリストによって2018年に紹介されました。

(原文)Vue API calls in a smart way
https://medium.com/canariasjs/vue-api-calls-in-a-smart-way-8d521812c322

(日本語訳)【Vue.js】Web API通信のデザインパターン (個人的ベストプラクティス)
https://qiita.com/07JP27/items/0923cbe3b6435c19d761

Jorge氏のブログでは以下のような問いかけがされます。

How many times have you seen examples with an instance of axios in each component?
(各コンポーネントにaxiosインスタンスが書かれてるような実装をどれくらい見たことがありますか?)

そしてそのように実装されているコードに対してJorge氏は問題提起しています。

What happens if the endpoint changes?
(エンドポイント変更したらどうする?)
How I can handle mocks or different endpoints to test it?
(動作確認のためにエンドポイントをモックしたくなったらどうする?)
What happens if you need to reuse a call?
(再利用したくなったらどうする?)
What happens if you need to refactor some call or move it to a Vuex actions?
(Vuexに処理を移植するとかリファクタするとなったら?)

後述しますが、最後の”リファクタリングしたくなった”のがまさに私たちの陥った状況でした。
この問題に対処するために考えられたのがRepositoryFactoryパターンのようです。

これは名前の通りRepositoryパターンとFactoryパターンを組み合わせた設計ということになります。Repositoryパターンはドメイン駆動設計(Domain-Driven Design, DDD)で提唱された考え方、Factoryパターンはオブジェクト指向言語のCreational Design Patternsの一つです。

Repositoryパターンは、ドメインモデルのまとまり(Aggregateと呼ばれます)ごとにデータアクセスを1箇所に集約するRepositoryを作成し、データレイヤのロジックとドメイン疎結合にするというもの、Factoryパターンとはインスタンスの生成ロジックを一元管理するFactoryを作成し、インスタンスを必要とするクライアントから生成ロジックを分離するものです。

雑な言い方をすれば、両者を組み合わせることで以下のようなメリットを享受できるということになります。

  • コードのメンテナンス性が向上(DRYに記述できる)
  • 拡張性が向上(横展開するときに短時間で実装ができる)

導入背景

さて、弊社では2019年ころからモノリシックなRailsアプリケーションをフロントエンドとバックエンドに分離してきています。フロントエンドはVue/Nuxt/TypeScriptを採用していますが、詳細は下記ブログに記載しています。

tech.forstartups.com


ゼロから作ってきたばかりということもあり、APIへのリクエストは各コンポーネント中からaxiosを利用していました。

しかし、実装量が増大するにつれてAPIへのリクエストで共通の修正を行う場合に該当箇所や対象ファイルも増大し、メンテナンスが難しくなりました。そして、あるタイミングで実際にaxiosの処理をrescueしたいという話になりました。

「axiosを書いた各コンポーネント全部の箇所に修正を入れていく方法は避けた方がよいので別の方法を考えましょう」と一緒に働くメンバーの方が色々調査してくれて、RepositoryFactoryパターンを採用することにしました。

実装する

まずRepositoryパターンを導入していきます。

ドメインごとにデータへアクセスする処理をそれぞれ1枚のRepositoryに集約し、axiosによるAPIリクエストはこのファイルから(このRepositoryを通して)のみ行われるようにします。

次にFactoryパターンを導入します。

今回のFactoryパターンにおける具体的な生成物はRepositoryです。
Factoryを記述するファイルを作成し、どのRepositoryを生成するかを(呼び出し元のクライアントではなく)Factoryが決定できるようにします。

最後にaxiosを直利用していたコンポーネントを修正します。

データに対するCRUDアクションを行うときは必ずRepositoryを通すのがRepositoryパターンです。従ってaxiosを直で利用せずにRepositoryを指定するということになりますが、直接Repositoryインスタンスを生成せずにFactoryに”生成依頼”するのがFactoryパターンなので、最終的にはコンポーネントはFactoryに対してRepositoryインスタンス生成の依頼を行うよう修正します。これが下の図の .$repository(‘user’) です。

これによって得られたRepositoryは共通のInterfaceが備わっているので、あとは取得したRepositoryへのメソッド呼び出しを行うよう書き換えます。

 

なお、実際にはFactoryを呼び出すにあたって事前にpluginでFactoryをNuxtAppにインジェクトしておきます(repositoryという名称をつけました)。こうすることで context.root.$repository でFactoryを呼ぶことができます。

import { Inject, NuxtApp } from '@nuxt/types/app'
import {
 ApiRepositoryFactory,
 RepositoriesType,
} from '@/factories/api-repository-factory'
 
export default ({ app }: { app: NuxtApp }, inject: Inject) => {
 const repositories = (name: string) => {
   return ApiRepositoryFactory.get(name)(app.$axios)
 }
 inject('repositories', repositories)
}
 
declare module 'vue/types/vue' {
 interface Vue {
   $repositories: RepositoriesType
 }
}

また、コンポーネントにおけるRepositoryを通したCRUDアクションはcomposition APIを利用してcompositionとして切り出し、コンポーネントでは当該compositionをimportして使っています。

pages/index.vue

import useUsers from '~/composables/useUsers'
 
export default defineComponent({
 components: { },
 setup(_, context: SetupContext) {
   const {
     get,
     post,
     // ...
   } = useUsers(context)

composables/useUsers.ts

import { computed, reactive, toRefs } from '@vue/composition-api'
 
export default (context: any) => {
 const state = reactive<{
   user: UserType
   loading: boolean
 }>({
   user: {},
   loading: true,
 })
 
 const get = async (userHash: string) => {
   const response = await context.root
     .$repositories('user')
     .get()
   // ...
 },
 
 return {
   ...toRefs(state),
   get,
   post,
   // ...
 }
}

実装の概要は以上ですが、RepositoryFactoryパターンをAPIリクエストに導入した全体像を記載しておきます。

実装してみて

実装を終えて数ヶ月が経ちますが、当初の目的であったAPIクライアントに関するエラーハンドリングを1箇所に集約して管理することができるようになり(そしてそれは再利用が可能)、設計を一度理解すればコード管理が行いやすくなりました。

フロントエンドにとってはBackend For Frontend(BFF)サーバー以降のAPIサーバー・各種データソースをデータレイヤと見做すことができますが、その意味でドメインモデルとデータレイヤの中間にドメインごとに(正確にはAggregateごとに)1種のRepositoryレイヤを設けたことのメンテナンス性の高さをチーム一同実感しています。

副次的な効果として、以前の実装では設計から落ちておりスクリプトエラーとして拾っていたAPIのエラーを全てリクエスト段階で捉えて監視ツールにロギングできたことで、バグ発見までの時間を短縮できたことがありました。

Factoryパターンに厳密に従っているわけではないものの、それでもDRYに書けた部分が多く、今後もこのパターンに沿ってAPIクライアント側の機能開発は拡張していきたいと思います。

参考文献

以下のブログは実装の際に参考にさせていただきました

Vue API calls in a smart way
https://medium.com/canariasjs/vue-api-calls-in-a-smart-way-8d521812c322

【Vue.js】Web API通信のデザインパターン (個人的ベストプラクティス)
https://qiita.com/07JP27/items/0923cbe3b6435c19d761

Repositoryパターン
https://medium.com/canariasjs/vue-api-calls-in-a-smart-way-8d521812c322

Factoryパターン
https://www.oodesign.com/factory-pattern.html

【フォースタ テックブログ】Tryを決めるだけでは意味がない。チームに成果を還元するための取り組み。

お疲れ様です。エンジニアのHur Junhaengです。
フォースタートアップス(以下、フォースタ)に今年の2月に入社しました。

今回は、スクラム開発を行っているチームが振り返りで決定するTryをどう管理するべきか個人的な見解を込めて、フォースタでどのように対応しているかについてご紹介していきたいと思います。

スクラムにおいての振り返り

そもそもの話になりますが、振り返りは何故必要なのでしょうか。

振り返りを行う目的は、組織ごと違いはあるものの「過去にあった出来事から学び、チームをよりよい方向に変化させる」という大枠は同じかと思います。なので、振り返りの結論としてはチームをよい方向に変化させるための次のアクションを決めることが必須不可欠になります。

スクラム開発を採用している組織において、振り返りそのものは珍しいことではありません。振り返りのフレームワークは数え切れないほど多く存在していますが、Keep・Problem・Try方式(以下、KPT方式)を使ったことがない組織は少ないでしょう。表現は少し変わってしまいますが、この方式の場合でも「続けるべきこと(Keep)」と「抱えている問題(Problem)」を洗い出して、最終的には「次のアクション(Try)」を決定するために振り返りをしていることが分かります。

どの方式が組織に適切なフレームワークかはさておき、他の振り返り方式を採用している組織においても、新しいTryを決定することは重要ではないでしょうか。ただ、Tryを決定するだけで終わってしまうと個人によって取り組みがズレてしまったり、継続的な管理ができないことが多いです。よって、一度決定されたTryはチームとして「Tryに対する評価」をすることで、その成果をチームに還元する必要があります。

チームが抱えている課題

私が働いているチームではKPT方式を含め、色んな振り返りフレームワークを実施しています。フレームワークごとに手法は異なりますが、最終的なアウトプットとしては複数のTryが決定されています。ただ、決定されたTryは体系的に管理されておらず、チームやメンバーの状況によって左右されるという問題が発生していました。

  • Tryによっては共通認識にズレがあり、メンバーごとの解釈が異なる
  • 目の前のタスクが優先され、新しい取り組みを忘れてしまう
  • 効果があっても、チーム全体の行動改善に繋がりにくい

明確なTryの評価フローがなかったので、Working Agreement(以下、WA)は存在しているが、良いTryだと評価されていても適切なタイミングでWAに反映されておらず、そのままフェードアウトしていくようなケースもありました。

振り返りを通じて、チームで議論して決定された方針が、知らない内に忘れられてしまうことは望ましくありません。チームとして、もう少しTryの扱いを改善する必要があると認識しました。

Try一覧とステータスを可視化

チームの問題を解決するために最初に取り入れたのは、決定されたTryを別ドキュメントにまとめることでした。今までは振り返りの時に作成した議事録の中で各Tryを記載していたので、Tryを確認するたびに作成された日の議事録を閲覧していました。スプリントを跨いでも一目で状況が分かるような仕組みを作り、Tryを取り組む際のフットワークをなるべく軽くする必要がありました。

専用の一覧ページには振り返りで決定されたTryを記載し、それぞれの進捗状況をステータスとして表示させます。 そのステータスは毎スプリントごとに再評価を行い、最終的にはチーム全体の行動を変化させるためにWAやチームのCultureとして還元することを目的にします。

In progress
: 最初にtryが決定されている時の状態
Keep
: Tryを継続し、今後も効果を図りつつ継続したい
Done
: 実施済み、または意識しなくても既にに達成されている
Close
: 実施できない、または実施する必要がなくなっている
WA
: Tryの結果、チームとして守るべき行動規約として決定されたもの
Culture
: Tryの結果、特に意識しなくてもチームに浸透している状態

Try一覧を作成してステータスを管理することは、常に最新状態であり、信頼できる情報元を1画面で提供することに意味があります。例えばメトリックス監視など、情報の可視化のためにダッシュボードにリソースの情報を集約させることを考えてみましょう。情報を集約し、現在のステータスを可視化することは継続的な管理手法の第一歩と言っても良いでしょう。

Tryのライフサイクル

先ほどご説明しましたが、Tryを評価することはTryを決定することと同じくらい重要です。リスト化されたTry一覧を管理することができれば、次は定期的な評価を行う必要があります。現在のチームでは2週間を1スプリントとして進めているので、スプリントの振り返りを行う際にTryを再評価を実施しております。

振り返りの実施結果としてTryが作られたら`In progress`として設定させ、1スプリントの実施時間を経て評価を行います。実行すること自体が目的であるタスクレベルのTryはこの時点でDoneに移行するケースが多いが、その他の場合はチームでそのTryを継続して取り組むべきかを検討する必要があります。

  • スプリントの中で、メンバーはそのTryを遵守して行動していたか。
  • 実施してみて、本来想定していた効果は得られたのか。
  • Tryの効果よりも、継続するためのコストが高くないか。

この中でTryをチームが継続して取り込む価値がないと判断されたらステータス`Close`に設定し、継続を中止します。また、1スプリントで評価できなかったTryに関しては次のスプントまで効果検証を継続します。数は多くないかもしれませんが、1スプリントで充分に効果検証を完了しており、チーム全体で今後も取り組みたいと判断する場合は`WA`や`Culture`に反映することもよいでしょう。

次のスプリントではこの`Keep`ステータスのTryを同じ方式で評価して行いますが、`Keep`状態として残り続けることは警戒する必要があります。評価のタイミングを先送りにし実施されないTryが残り続けることは、効果の判断ができないTryをチームとして意識し続けなければならいことを意味します。

私が働いているチーム場合、`Keep`ステータスから`Keep`ステータスに変化することは、最初Tryが決定から2スプリント(4週間)が経過していることを意味します。2スプリントが経過したにもかかわらずTryが残り続ける状況の場合、評価を阻害する要因が存在しているか確認する必要があります。その場合、阻害要因を無くすためにチームとして取り組むべきことを先に実施した方が良いでしょう。

最後にTryの結果をWAやCultureに反映することに決まった場合は、それぞれを専用のドキュメントとしてまとめ、常に最新の状態になるように管理しなければなりません。これはTry一覧を作成する際と同じく、継続的な管理を行うためです。チームが取り組んでいることを言語化することによって、メンバーの共通認識を促すことと同時に、新しいメンバーが参加する場合にもチームの働き方をスムーズに吸収することができます。

チームの今

全てのTryは一覧で管理されており、スプリントごとにその効果を検証しているので、どんなTryでもしっかり評価されるようになりました。また、Try一覧を作成してから3ヶ月間、22件のTryが作られましたが、`Keep`ステータスのTryは2件のみでその他は何からの形でチームに還元されています。

特にTryの結果、WAとCultureに4件の行動規約が追加されており、Tryのステータスが変更されたタイミングでWAとCultureを更新するので、常に最新の情報が反映されています。WAにはチームとして遵守すべき内容のみ記載することになってので、Tryの管理仕組みを取り入れる前と比べれば非常にコンパクトになっています。WAに収まらない項目はCultureに記載することによって、遵守すべきものとチームの文化を区別することができました。

WAの例 :
エラー対応を完了する際には、その根拠をコメントに記載する
Cultureの例 :
githubは1function - 1commitを原則とし、日本語でコミット内容の説明文を記載する

現在はTry一覧を朝会などでチームと確認する時間を作って、スクラムの一部として取り扱っています。今後チーム内で確認する時間を作らなくても、メンバーがTryを意識して働くような文化が染み付くようになったら、別途時間を作る事なくTryを継続していくことができるでしょう。