sitateru tech blog: SCS

sitateru tech blog

シタテルの技術やエンジニアの取り組みを紹介するテックブログです。

ラベル SCS の投稿を表示しています。 すべての投稿を表示
ラベル SCS の投稿を表示しています。 すべての投稿を表示

2018年12月26日水曜日

プロジェクトの振り返りをやってみた

12月 26, 2018

kaizen
こんにちは、シタテルの藤本です。
主にSCS(Sitateru-Control-System)という生産管理システムのバックエンド(Rails)を担当しています。

シタテルに入って小さい機能の追加、改修を行ってきたのですが
最近要件定義からリリースまでが3ヶ月程度のプロジェクトが終了しました。
そのプロジェクトに対して振り返りを行ってみたので内容について書いてみたいと思います。

やり方

シタテルの開発では2週間のタイムボックスで動いており、最終日にKPTにて振り返りを行っています。
今回のプロジェクトの振り返りでは繰り返し性がないことから
KPTの拡張版でやってみました。参考にさせていただいたのは以下です

プロジェクトの振り返り(KPTの様な何か)

各種情報

参加人数:4人
場所:熊本(2拠点)、東京
テレビ電話:Zoom
ボード:Google スプレッドシート

KPTから追加されている項目

KPTとの違いとして以下の項目が追加しております

  • Good
    よかったことをあげる、続けたいものをKeepにする
  • Issue
    Problemから導き出された課題
  • Risk
    今回具体的には発生していないが危ないと考えられること、将来起こりそうな問題
  • Solution
    IssueとRiskに対しての解決策を考える
  • Task(今回は対象外の項目とした)
    Solutionから導かれる具体的なアクション

進行順序

  1. Good、Problem、Riskを考えて、付箋に記載
  2. 各々の内容を確認してグルーピング
  3. GoodをKeepにするものを選択
  4. Problem(Risk)をIssueにするものを選択
  5. 4.で選択したものからIssueを考える
  6. Issueを共有する
  7. Solutionを話し合いながら出し合う
  8. 次に対応するSolutionを決める

付箋を張っていったボードは以下のような形です
board

やってみて

アウトプット

Good:14
Keep:4(Goodからグルーピングしている)
Problem:21
Risk:5
Issue:22

対象としたProblemとRiskは共に1つで
Solutionを合わせて6つ出し合った

よかったこと

  • みんなが考えていたことが共有できる
    自分の考えだけだと狭い範囲になりますがみんなの考えていること出してもらい共有することで
    各々の考えが掛け算になりより良いSolutionを出すことができた
  • 単発ものの振り返りの形式としては良い
    KPTだと繰り返すことで仕分けを流れになっていますが今回の形式では
    「続けたいこと」と「原因となったこと」を明確にして解決策を導くことができた
  • Solutionを話し合いながら考えることができて前向きになる
    みんなが思っていた問題はたくさん出たけど最後にSolutionについて議論をしていると
    前向きに次はもっと良くしよう、良くできると思うことができた

反省点

  • 予定した時間が甘すぎた
    1時間は流石に少なすぎました、大幅にオーバーしてしまい倍の2時間かかってしまいました
    (参加した方には申し訳なかったです、かつ快く続行していただき、ありがとうございました!)
    単発での実施かつ対象とする期間が大きいので最初から時間を長めに取っておくべきでした
  • 各項目の意味がパッとわからない
    ProblemとRiskってどう違うということが出たりしました、事前にちょっと時間をとり
    認識を合わせておいたほうがスムーズに入ることができたかなと思いました
  • 思い出す時間がなかった
    Good、Problem、Riskについて事前にちょっと考えておくとかのアナウンスをしていなかったので
    思い出す時間がちょっと少なすぎかなと思いました

まとめ

プロジェクトを振り返ることでよかったこと、問題となったことを再認識しその解決策まで
出すことができたことはとてもよかったと思います。
ただし出してよかったで終わると何も変わっていかないので次やる時に
今回上がったことを見直して実際の行動に移して、少しでも良いプロジェクトにしていきたいと思います。

2018年12月25日火曜日

[第一回]SansanとHubSpotの連携

12月 25, 2018

こんにちは、シタテルエンジニアの工です!
今回は、SansanとHubSpotの連携の仕方について書いていきます 🚀

はじめに

シタテルでは、衣服生産をSCS、マーケティング・営業の部分をHubSpotを使って管理しています。

HubSpotを導入する際に、Sansanの情報をHubSpotに同期したいという要望があったので、SansanのAPIとHubSpotのAPIを組み合わせて同期処理を実装しました。

AWSLambdaを使って、定期的に同期処理を実行しています。

HubSpot公式にもSansanとハブスポットの連携の仕方という記事も公開されていますので参考にしてみてください。

Sansanの名刺情報をHubSpotにインポートする

使うもの

余談ですが実装したときAWSLambdaにはRubyの選択肢がなかったのですが、今は使用できるみたいですね。
普段はRubyを使うことが多いので、次にLambdaを使うときはRubyで実装してみたいです。

Sansanの情報を取得

公式ドキュメント Sansan Open API

handler.js

const axios = require('axios')
const moment = require('moment')
axios.defaults.headers.common['X-Sansan-Api-Key'] = process.env.SANSAN_API_KEY
axios.defaults.headers.get['Content-Type'] = 'application/json'

module.exports.importSansanData= async (event, context, callback) => {
  var updatedFrom = moment().subtract(2, 'hours').format("YYYY-MM-DDTHH:mm:ss")+"Z"
  var updatedTo = moment().format("YYYY-MM-DDTHH:mm:ss")+"Z"

  await axios.get(`https://api.sansan.com/v2.0/bizCards?updatedFrom=${updatedFrom}&updatedTo=${updatedTo}&range=all`)
      .then(function (response) {
        importHubspot(response)
        callback(null, response.data)
      })
      .catch(function (error) {
        callback(error)
      });
};

詳しくはこのあたりを参考にしてください。
AWSLambdaとServerlessを使ってみる[第1回]
AWSLambdaとServerlessを使ってみる[第2回]

日時取得のところがとてもブサイクです... 😢
なぜかタイムゾーンZにしないとうまくいかなっかった 🤔
本当は+09:00に設定したい。

var updatedFrom = moment().subtract(2, 'hours').format("YYYY-MM-DDTHH:mm:ss")+"Z"
var updatedTo = moment().format("YYYY-MM-DDTHH:mm:ss")+"Z"

HubSpotにインポート

取得したSansanデータをインポート。
propertyは数が多いのでほとんど割愛して記載します。

公式ドキュメント HubSpot Developers

handler.js

function importHubspot (response) {
  response.data.data.forEach(createContact)
}

function createContact (value, index) {
  var properties = [
      {
        property: 'email',
        value: value.email
      },
      {
        property: 'firstname',
        value: value.firstName
      },
      {
        property: 'lastname',
        value: value.lastName
      }
    ]

  axios.post(`https://api.hubapi.com/contacts/v1/contact?hapikey=${process.env.HUBSPOT_API_KEY}`, {
    properties: properties,
  })
  .then(function (response) {
    console.log(response.data)
  })
  .catch(function (error) {
    console.error(error.response.data)
  });
}

上の例はひとつひとつPOSTしていますが、こちらのAPI使えば1回のPOSTでまとめてCreateできます。
Create or update a group of contacts | Contacts API

CloudWatchでスケジュールを設定

serverless.ymlにスケジュールを設定します。
2時間おきにインポート 🚀

serverless.yml

functions:
  importSansanData:
    handler: handler.importSansanData
    events:
      - schedule: cron(0 */2 * * ? *)

これで2時間おきに、Sansanの名刺情報がHubSpotのコンタクトに同期されます!👏

最後に、deploy 🚀

serverless deploy -v

まとめ

今回はSansanとHubSpotのAPIを使って、Sansanの名刺情報をHubSpotのコンタクトにインポートする方法について書きました。

SCSと外部サービスとの連携は今後もどんどん加速していくと思います!
マーケティング・営業 -> 衣服生産 -> 請求この流れがシステムでシームレスに実現できるように開発中です 💻

2018年11月10日土曜日

オンライン衣服生産システム[第2回] Sitateru Control System(SCS)

11月 10, 2018

コンシェルジュ向けシステム - Sitateru Control System(SCS)

こんにちは!
シタテル株式会社CTOの和泉です。

シタテルのシステムを紹介する記事第2回。今回はコンシェルジュ向けのシステム「Sitateru Control System(SCS)」をご紹介します。
SCSはユーザーとシタテル、サプライヤーの間のストック情報(決まったことやデータ)やフロー情報(チャットなどでやり取りされるコミュニケーション)の橋渡しをしているシステムで、シタテルのいわば基幹システムです。

SCSの構成

SCSは主にトピック画面とアイテム画面で構成されています。
  • トピック画面 - コンシェルジュがユーザーとサプライヤー、それぞれとやりとりしているメッセージをトピックごとに管理している画面(フロー情報の管理)
  • アイテム画面 - 製作アイテムについて、アイテムごとに情報を管理している画面(ストック情報の管理)
コンシェルジュは基本的にトピックでユーザーやサプライヤーとコミュニケーションし、トピックで決まった内容をアイテムの情報に入力してます。前回の記事でご紹介した「マイアトリエ」からユーザーが送信するメッセージがトピック画面に反映されます。
SCSの役割

トピック画面

コンシェルジュがユーザーやサプライヤーとメッセージのやりとりを行う画面がです。トピックはクライアント(この画面ではユーザーのことをそう呼びます)とサプライヤーに分かれていて、下の画面はクライアントを絞り込んで表示した状態です。やりとりをしているクライアントごとのトピックが並んでいます。
トピック一覧
ここからトピックの個別画面を開いてメッセージの確認、送信ができます。また、個別画面ではそのトピックの参加者、話しているアイテムなどの情報も表示されます。ここからユーザーやアイテムの情報ページに飛んで確認することもできます。
トピック
メッセージはこの個別ページに時系列順に全て表示されています。チャットのようにこのページでメッセージを書いて投稿するという形になっています。もちろんファイルも添付できます。
メッセージ送信

アイテム画面

トピックでやりとりをして決まったアイテムの具体的な内容は、コンシェルジュがアイテム画面に入力し ます。アイテム画面には「概要」と「相談〜概算見積もり」「サンプル作成」「本生産」の3つの工程のボックスがあります。工程のボックスは任意に増やすことができます。(セカンドサンプルや 量産リピートなど)

概要

概要
概要にはアイテムの基本的な情報を入力します。トピックでのやりとりを通じて工程が進むと 対応するボックスを作成します。
ボックス作成

「相談〜概算見積もり」ボックス

ユーザーからの相談を受けると「相談〜概算見積もり」ボックスを作成します。アイテムについての相談内容を、具体的な情報に落としていきます。
相談ボックス
アイテム画面では関連するトピックを同時に確認できるようになっています。フロー情報とストック情報を1画面で確認できるようにすることで 正確で効率の良いコミュニケーションを実現しています。

「サンプル作成」ボックス

具体的なアイテムの内容が決まったら、次は「サンプル作成」ボックスです。サンプル作成に必要な情報を入力します。この情報はサプライヤー向けのシステムであるマイオペレーターを通じてリアルタイムに共有されます。
サンプルボックス1
上記ボックスに 1stサンプル作成とナンバリングされているように、「サンプル作成」ボックスは複数作れます。ユーザーの満足いくサンプル品が完成するまで、何個でもボックスは作成できますし、実際にサンプル品を作成することも出来ます。もちろん、その分のお代は発生しますが、、、
サンプルボックス2
サンプルボックス3

「本生産」ボックス

サンプルが完成したら次は本生産です。
「本生産 」ボックスも「サンプル作成」ボックスと同じように何個でも作れます。再発注が行われる度に、ここで「本生産」ボックスが作成され、サプライヤーへと情報が送信されます。
「本生産」ボックスで発注された内容に基づいてサプライヤーが生産し、完成品をユーザーに納品することでアイテム作成の1サイクルが完了します。
本生産ボックス

まとめ

今回はSCSをトピック画面とアイテム画面に分けてご紹介しました。
SCS (特にアイテム画面のボックス)を通じて、シタテルのアイテム作成の具体的な流れがご理解頂けたかと思います。ユーザーと相談 → サンプル作成 → 本生産が基本的な流れです。
実は、他にも原価計算や裁断報告など ご紹介できていない機能もたくさんあります。また毎週のようにどんどん機能追加されています。 随時このブログで紹介していきます!
次回は、衣服の相談を行うユーザー向けのシステムである「マイアトリエ」についてです。
お楽しみに!

2018年11月6日火曜日

DXF TIIPビューワ

11月 06, 2018

こんにちは!
シタテル株式会社CTOの和泉です。

シタテルではユーザー様からの相談を相談をお受けして、衣服の生産管理を行っています。

その際、衣服のパターンデータをいただきますが、このパターンデータはDXFという形式のファイルで送られてきます。

正確にはDXFを拡張したアパレルCADデータ互換のTIIP規約としてフォーマットが規定されています。

アパレルCADデータ互換のTIIP規約

このファイルは通常、専用のソフトウェアを使って編集、閲覧するのですが、

「ブラウザ上でユーザー様とメッセージのやり取りをしている中でいちいちダウンロードして確認してというのは効率が良くないから、ブラウザで見たい!」

という現場からの要望がありました。

ということで、DXF TIIPのファイルをブラウザ上で閲覧できる簡易ビューワーを作りました!(1年ぐらい前に)
突貫工事で作ったのであまりできはよくないですが、ザックリとファイルの中身を 見られるので重宝していただいてます。

DXF TIIP Viewer - Github

DXF TIIP Viewer

シタテルの SCSやマイオペレーター、マイアトリエにも組み込まれています。スマホでも見られるので外出先でちょっと確認したいときにも便利です。

フォーマットが見つからなかった、、、

実装するときにファイルフォーマットをダウンロードしよう思ったのですが、ちょっと探しただけでは見つけられず。

いや、きっと私の探し方が悪かっただけだと思うんですが、、、

結果、バイナリエディタとにらめっこしながらなんとなくで作りました。

TIIPはDXFのコメントエントリ(用語適当です、ごめんなさい)の部分を拡張してあるフォーマットだったので、なんとなくで読み取ることができました。

DXFの読み取り

DXF自体の読み込みには three-dxf を利用しました。
そのままだと読み取りできない部分があったのでもとのリポジトリをフォークして少し編集しています。

Three DXF - Github

おわりに

今回のDXFの話はちょっとした部分を便利にしただけですが、 シタテルではこのように現場の声を毎日聞きながらエンジニアが開発を行うことで、現場にフィットした機能を作り、効率性を高めることで多くの相談をすばやく処理して、ユーザー様の衣服づくりをサポートしています。

2018年11月3日土曜日

オンライン衣服生産システム[第1回]

11月 03, 2018

はじめに

こんにちは!
シタテル株式会社CTOの和泉です。

今年の4月にそれまで努めていた大学を離れてシタテルに正式にジョインしました。半年近くが過ぎ、いくつかのプロダクトリリースを行う中でお客様とお会いする機会も多くあったのですが、私達が内製でシステムを開発していることや、それを使ってどのように業務を行っているかというのは知られてない事に気が付きました。

ということで、4回の連載で「シタテルのシステム」についてご紹介します!

シタテルが開発しているシステムについて、コンセプトや構成、どのように使われているのかをお伝えします。ベールに包まれたシタテルの内側に興味を持っていただけたら嬉しいです。(そして衣服生産のご相談をいただけたら、、、← 欲)

シタテルとは

シタテルはオンラインで衣服の生産を行うためのプラットフォームサービスです。衣服を作りたいというユーザーの皆さんに対して様々なお手伝いをさせていただいています。また、そのために必要な縫製工場や生地会社、2次加工工場、パタンナー、デザイナーなど様々なサプライヤーと連携しています。

こう言うとシンプルなマッチングサービス(出会いの場を提供してあとはお任せする)のように捉えられることも多いのですが違います!

シタテル社内には上記サプライヤーとユーザーの間をつなぐコンシェルジュがいて、アパレルのプロの方が煩雑だと感じる部分ををお手伝いしたり、はじめて衣服生産に関わる方でも衣服生産の複雑な部分で挫折しないようにサポートしています。なので、マネージド(管理された)な衣服生産プラットフォームと言えるかもしれません。

ログイン

これはシタテルウェブページのトップ画面です。この画面を見ればもう「ここから登録してログインして、オンラインでシタテルとやりとりして衣服を作るんだ」という流れがばっちり想像出来ると思います。

いや、全然わからないですね。すみません。でも、この連載を読み終わる頃にはバッチリわかるはずですので、、、がんばります。

第1回目の本記事では、ログイン後の画面やそのさらに裏側で実際にどのようなシステムが動いているのか。シタテルの「オンラインで衣服生産」とはどこまでを本当にオンラインで行っているのか。その全体像をざっくりとご紹介します。第2回ではシタテル内部でコンシェルジュが扱うSCS(sitateru control system)、第3回ではユーザーがシタテルとのやり取りに使うマイアトリエを紹介します。最後の第4回では連携工場が使っているマイオペレーターについて紹介します。

シタテルで衣服生産する流れ

シタテルで衣服を生産する場面では、大きく分けて3人のキャラクターが登場します。

  • これから衣服を作りたいと思っているユーザー
  • ユーザーの要望をヒアリングして生産を管理するシタテルのコンシェルジュ
  • 実際の衣服製作に関わるサプライヤー(生地や資材を提供する会社も含みます)

ユーザーは、シタテルのコンシェルジュと、作りたい衣服についてやりとりを行います。具体的なイメージが固まると、コンシェルジュがサプライヤーと連携して生産を進めます。
基本的にユーザーとサプライヤーが直接コンタクトとることはなく、コンシェルジュが間に入って両者をサポートします。

登場人物

シタテルではこの3人のキャラクターにそれぞれ専用のシステムを用意しています。

  • ユーザー向けシステム「マイアトリエ」
  • コンシェルジュ向けシステム「SCS(sitateru control system)」
  • サプライヤー向けシステム「マイオペレーター」

この3システムを使って、ユーザーとの相談からサプライヤーへの発注・生産までをオンラインで行っています。それぞれのシステムについて第2回目から個別に紹介しますが、ここでもざっくりと説明します。

ユーザー向けシステム「マイアトリエ」

マイアトリエ

マイアトリエはユーザーが作りたいアイテムについてコンシェルジュと相談するためのシステムです。コンシェルジュとメッセージのやりとりを行いながら、製作状況の確認も行うことが出来ます。アパレルのプロであるブランドから、初めて衣服生産をする方まで全てのユーザーが利用します。

コンシェルジュ向けシステム「SCS(sitateru control system)」

SCS

SCSはコンシェルジュが行う製作進行の全てをサポートしています。ユーザーとのメッセージやファイルによるやり取り、その中でで決まった事項を社内、社外と共有するために整理して入力するための機能が備わっています。サプライヤーへの発注依頼もこのシステムの情報を用いて行います。

サプライヤー向けシステム「マイオペレータ」

マイオペレーター

マイオペレーターは主に縫製工場が使う生産管理システムです。衣服生産に必要な指示書やスケジュールについて一元管理し、発注から納品までサポートします。データはSCSと同期しています。今年の6月から400以上ある提携工場に順次導入し、7割程度の工場に使っていただいています。エクセルなどで管理をされていた工場も多くある中、使いやすく、他社の案件もこれで管理したいなどの声をいただいています。

シタテルのシステム設計思想

上に紹介した3システムは、それぞれが別々に開発されていますが、SCSを中心としてAPIで接続されています。入社してからシステムの設計思想を言語化していく中で私達が作るシステムは他のアパレルITベンダーと何が違うべきであるかを考えました。

生産の管理につかうシステムと言うと、たくさんの複雑な入力項目があって、コンピューターにあれこれ急かされて、というものを想像するシステム開発関係者の方も多いのではないでしょうか?下手をするとめちゃくちゃ横に長いエクセルシートのさらに使い勝手が悪くなったようなシステムになる場合も、、、(大学時代に使っていたものがまさしくそうでした)

シタテルでは「コミュニケーションを促進するためのデータ共有」「入力よりも出力」を重視してシステムの設計、開発を行っています。

世の中にはシステムがなくても電話と帳簿でビジネスができている場面は多くあります。コミュニケーションをとることがビジネスにおいて最重要であり、データをオンラインでやり取りすることは副次的であると、私は考えています。(コミュニケーションが最も大事で普遍的だからこそ、SlackやLINEのようなツールがビジネスの場で重宝されているのだと思います)

そのため、シタテルが開発するシステムでは、メッセージでのやりとりを重要視しています。コンシェルジュは基本的に、メッセージを用いてユーザーや工場とやりとりを行います。生産工程をパターンやテンプレートに当てはめて最適化するのでは無く、それぞれの案件に合わせてコミュニケーションによって解決する。そのコミュニケーションで伝えづらいものをデータという形でシステムが出力して共有する。それに最小限必要な入力項目を作成する。この順序でシステムの設計、開発を進めています。

シタテルは多くのユーザーやサプライヤーをつなぐビジネスを行っています。このようなビジネス形態はアパレルの業界では珍しいようです。そのため、1つの会社のオペレーションを極限まで効率化するためのシステムではなく、多くのプレイヤーが一緒に働きながらビジネスを進めていくシステムが必要であり、それを自らの手で作り上げています。

まとめ

シタテルがユーザーとの相談依頼からサプライヤーへの生産発注まで独自のオンラインシステムで行なっていることを紹介させていただきました。嘘偽りのない「オンラインでの衣服生産」だと思っていただけましたか?

次回からはもっと具体的に、マイアトリエ、SCS、マイオペレータを、それぞれのシステムごとに紹介します。

お楽しみに!