sitateru tech blog: やってみた

sitateru tech blog

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

ラベル やってみた の投稿を表示しています。 すべての投稿を表示
ラベル やってみた の投稿を表示しています。 すべての投稿を表示

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月19日水曜日

circleciでビルドしたあとにnetlifyへデプロイしてみた

12月 19, 2018

こんにちは!

シタテルでエンジニアをしている建山です。

主に工場向けのマイオペというシステムの開発を行っています。

マイオペでは、インフラとして本番、ステージング、開発、feature環境を用意して開発していますが、新機能をテストする環境としてfeature環境を使用しています。
そして、feature環境にnetlifyというサービスを使用しています。

netlifyとは

Netlifyは静的なサイトをすばやく提供できるWebサービスです。フロントエンドのビルド、デプロイ、ホスティングのすべてを行ってくれます。

今回の概要

デプロイの流れとしては、github -> circleci ➔ netlify
となっています。netlifyにはビルドする機能が備わっているので、github -> netlify
が可能なのですが、マイオペでは、ビルドの際にjavaを使用していて、netlifyのビルドで対応されていないので、circleciでビルドを行ったあと、netlifyにデプロイすることにしました。

今回の前提

  • ビルドはcircleciでおこなう
  • ビルドが終わったものをnetlifyにデプロイする
  • 指定のサイトURLにデプロイする

「それ、netlifyじゃなくてAWS S3でよくない?」っていうツッコミはあるとおもいますが、まずは使ってみたということでご容赦ください。

方法

事前にnetlifyにサイトを作成してください。(画面やcliを使って作成できます)

netlify cliをインストールします。今回は、プロジェクトに
npm install --save netlify-cliでいれました。circleciのconfig.ymlのstepsにnpm install -g netlify-cliでインストールしてもいいと思います。

次に、circleciのconfig.ymlでデプロイの設定をします。
こんな感じで、インストールされたnetlify cliを使って、デプロイします。

<<他省略>>
# run deploy
- run:
    name: deploy
    command: |
    if [[ "$CIRCLE_BRANCH" =~ ^.*-netlify.* ]]; then
        node_modules/netlify-cli/bin/cli.js deploy --site-id $NETLIFY_SITE_ID -p ${SC_DIR}/ --access-token $NETLIFY_ACCESS_TOKEN
    fi

${SC_DIR} にはデプロイしたいディレクトリをいれてください。
$NETLIFY_SITE_ID$NETLIFY_ACCESS_TOKEN
はcircleciの環境変数にセットしてお使い頂いたほうがいいかと思います。

上の例だと、ブランチ名に"-netlify"が含まれているとnetlifyにデプロイされるようにしています。
実際には、利用状況にあわせてカスタマイズしてください。

たとえば、"abcd-netlify"というブランチでgithubにpushすると、

デプロイされます!

今回は同じURLにデプロイしていますが、デプロイのたびに違うサイトURLを発行してデプロイもできるようです。
netlifyの中で、ビルドもいろいろできるようになっているので、今回のように限定的な使い方ではなく、もっと活用できると思います。

とりあえず使ってみましたということで、またいい感じのCI/CDを実現できたら紹介します!

詳しくは公式ドキュメントをご覧ください。https://www.netlify.com/docs/

2018年12月14日金曜日

いま話題の0円タクシーに乗ってみた!

12月 14, 2018

こんにちは!
シタテル株式会社UI/UXデザイナーの堤です。

先日ずっと気になっていた0円タクシーを利用したのでレポートします。

0円タクシーとは

DeNAさんが運営する次世代タクシー配車アプリ「MOV(モブ)」と日清のどん兵衛とのコラボレーションと なっており、2018年12月5日から31日までで都内の対象エリアでのみ運行されています。

利用方法

  1. MOV(モブ)アプリをダウンロード
    https://m-o-v.jp/campaign/donbei/
  2. アカウント情報を登録
  3. 乗る場所と行き先を指定
  4. タクシー会社の 中から「0円タクシーby日清のどん兵衛」を選択
  5. 「タクシーを呼ぶ」であとは待つだけ

タクシー会社選択画面。



目的地選択画面。
目的地を入力したりピンを移動すると瞬時に距離やかかる時間が表示されます! すごい!!



いま呼べるタクシーが地図に プロットされてる画面。
このときは 10 〜15分ぐらい に 1、2台呼べる状態 となっていました。



手配中の画面。
一度だけこの状態からキャンセルとなってしまったので 競争率も激しそうです。



手配完了の画面。
地図上で普通のタクシーとの差別化がうまくできていて、なにより不安を与えず待ち時間も楽しめる画面になっているので素晴らしいです。



外装だけかと思いきや内装も凝ってました!MOVのロゴもかわいい。



移動中は終始CMが 流れていました。



乗車中の画面。
添えられてるメッセージも良い!



乗車完了後の画面。
0円!!!



乗るときも 降りるときもドライバーさんに写真撮っていいですか?と聞くと快くOKと 言っていただいたので10枚ほど写真を撮り、移動中は「どんな人が利用してますか?」や「ドライバーさん自身は損しない仕組みなんですか?」などの質問にも笑顔で答えていただき 、どん兵衛もタクシーも より好きになりました。

12月下旬に乗車すると、実際にどん兵衛をいただけるようなのでまた利用したいと思います!

2018年12月10日月曜日

縫製工場の類似度算出を深層学習のモデルでやってみた

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

今回は研究開発的に、「縫製工場の類似度算出を深層学習のモデルでやってみた」について書きます。
まず初めに結果から。
['loss', 'acc']
[273999.25, 0.695652186870575]
69.6% 成功?
なにが?って話ですよね。
結果的には全然精度出ませんでした。まぁ、のべ1週間ぐらいでやってみた感じですし、サーベイも全然できてないので結果出るわけないのですが。
せっかくやってみたのでブログに恥を晒しておきます。
その道の専門の方にはお目汚しかと思いますがご容赦ください。

やりたかったこと

弊社コンシェルジュが手動で類似分類(グループ化)した縫製工場 のデータを教師データとして学習し、同様の類似分類を行える学習済みモデルを作成する。
類似分類ができれば、これまでのアイテム作成履歴から代替となる工場の提案ができる。かも。

希望的仮定

類似度の判定に用いられる特徴はある程度絞られているのではないかと想定し、学習によって効果の高い特徴が反映されるモデルが作成されれば、人の判断に近づけるのではないか。

結果

教師データに対しては98.8%の正答率に達したが、テストデータについては69.6%にとどまった。残念ながら実用に足るような結果は得られなかった。
images/image-3.png
図1:教師データに対する推論結果のプロット(青が教師データ、点線先のオレンジが対応する推測結果)
images/image-4.png
図2:テストデータに対する推論結果のプロット(青が教師データ、点線先のオレンジが対応する推測結果)
images/image-5.png
図3:学習の経過

何をやったのか

データベースに保有する123の縫製工場を2次元平面上で類似しているものを近くに配置するように、弊社コンシェルジュに依頼して教師データを作成。(図1の青い点が各工場を表す)この際、「類似している=あるアイテムを相談するときに変わりに相談できる工場であるか」とした。作成された教師データが含む縫製工場データは114件。9件は情報不足により配置できなかった。
作成した教師データは各工場ごとに位置ベクトルが与えられた状態になっている。この位置ベクトルを各工場がもつ特徴ベクトル(全313次元のうち、名前などヒューリスティックに取り除けるものを除いて、108次元)から求めるモデルを学習により獲得した。

DNNモデルや条件などのメモ

model = Sequential()
model.add(Dense(DIM, activation='relu', input_dim=DIM))
model.add(Dropout(0.25))
model.add(Dense(DIM*2, activation='relu'))
model.add(Dense(2))

model.compile(optimizer='adam',
              loss='mean_squared_error',
              metrics=['accuracy'])
images/image-6.png
_________________________________________________________________
Layer (type)                 Output Shape              Param #   
=================================================================
dense_1 (Dense)              (None, 108)               11772     
_________________________________________________________________
dropout_1 (Dropout)          (None, 108)               0         
_________________________________________________________________
dense_2 (Dense)              (None, 216)               23544     
_________________________________________________________________
dense_3 (Dense)              (None, 2)                 434       
=================================================================
Total params: 35,750
Trainable params: 35,750
Non-trainable params: 0
_________________________________________________________________
history = model.fit(X_train, Y_train,
            batch_size=50,
            epochs=5000,
            validation_split=0.1, 
            verbose=1)

考察

代替工場を考える際には、アイテムによって代替として扱うものが変わることが想定されるため、全体を2次元平面上に次元縮退してプロットすることが難しいであろうことは当初予定していたとおりであった。
今回は、比較的手軽に作成できる教師データを用いて試してみたが、十分な結果は得られなかった。
統計によるリコメンドではデータの量が問題になるが、良質で量のあるデータが十分にないのが現状。シタテルの取扱量が増えることによりある程度のデータは蓄積されていくが、滝行との連携も含めて扱えるデータ量を増やしていくことが必要である。

工場データベースについて

シタテルは500を超える縫製工場やサプライヤーと連携して衣服づくりサービスを提供しています。
それぞれの縫製工場に対して、設備や人員、アイテムごとの金額感、繁閑の目安など300を超える情報をデータベースに格納しています。
images/image-1.png
工場を検索して絞り込み

(工場名や取引先は非公開のため消してあります)
images/image-2.png
いくつかの工場を並べて比較
弊社コンシェルジュはこれらのデータを使ってご相談いただいたアイテムごとに最適な工場に問い合わせを行います。