※ここで言う「レビュー」とは、リリース判断の可否を決める機能のことではなく、デザインをブラッシュアップさせるための、批評とフィードバックそのものを指しています。

開発チームの一員としてのデザイナー

開発チームでのレビューのいいところ

悩ましいところ

デザインチームでレビューを始めた

レビューをしてみる

3週間やってみて

こんにちは！
シタテル株式会社エンジニアのいしづかです。

これまで、ぼくは社内外いろいろなセミナーに参加してきました。

新卒で勤めていた会社では出社初日からビジネスマナー研修がありましたし、本業に関わるプログラミング言語やフレームワークなどの技術的なものは今でも機会があれば参加しますし、はたまた「女性部下との接し方」みたいなやつも参加したことがありますし、そういえば速読のセミナーなんかにも行ったことがあります（身についてはいないけど・・・）。

多かれ少なかれ、ご経験があることだと思います。


これらは基本的に講師が登壇して内容を解説し、ワークを通じて体験するといった流れでセミナーが進行していきました。


もちろんコレ自体が悪いというわけではありません。
しかし、悩みとして一般論としては理解できたけれど、そこから具体に落とせず、結局セミナー前後であまり変化がないというものがありました。


それはセミナーに望むぼく自身の姿勢に大いに問題があるのは承知の上です。目的意識を持って参加してないからだ、と。
しかしながら、なかなかそこから抜け出しきれない状態にありました。


そういうご経験、ありません？（同意を求めてみる）


先日「フィードバック法」に関するセミナーを受けたのですが、その内容はもちろんですが、セミナーのやり方自体がぼくの中でかなり新鮮で、いい気づきがありました。

今回はぼくの気付きについてレポートしたいと思います。

【講師＝参加者全員】伝え合う形式のセミナー

ぼくが受けたのは「効果的なフィードバック」という名目のセミナーでした。オンライン開催で、参加者は講師含めて15名です。

資料は事前に配布されており、参加者は事前に目を通しておくことになっていました。


「フィードバック」というのは自分が見知ったことについて感じたことや考えたことを相手に伝えることです。
そこにはIメッセージだのYouメッセージだのという様々なテクニックがあるのですが、今回は内容については割愛します。


このセミナーでは1名の講師がいて全体を進行していたのですが、全体を通して講師の方がしゃべっている時間はほとんど無かったというのが最大の特徴だったように思います。


具体的なシチュエーションを設定して参加者同士でワークをすることはありますが、それについて「自分はどのように感じたか」や「自分だったらどうするか」といったことをシェアし合うという形で進んでいきました。


ぼくにとってこのやり方で進んでいくセミナーはとても新鮮でした。
今まで参加したセミナーでは「なんでも当てはまる一般論」を取り扱うことが多かったですが、今回のフィードバックセミナーではすごく個別具体的なシチュエーションに対して意見を出し合うという形でした。


その中でも同じシチュエーションについて話しているのに人によって感じ方や対策が異なっているのが見えるというのがとても印象的だったのを覚えています。

「過去このような経験があったので、自分としてはこの点を重視しています」といったお話を各参加者がなさるのですが、ぼく自身が経験したことのないことを具体的に聞けるというはとてもリアリティがあって、良い追体験の機会になりました。

シェア型セミナーがおもしろいなと思った点

今回のセミナーは実際にやってみて自分たちがどのように感じたのかといった生々しい部分がしっかり活用できている点がとても良かったと感じました。


一般論的な知識については、資料を読めば大体のところは理解できます。
ぼくもセミナーでしゃべる側になることもあるのですごく反省しているのですが、書いてあることをそれらしく読むだけでセミナーやった（受けた）気になってしまうという罠にハマり続けていた部分があります。


大事なのは具体的な気づきや発見を自分の中に発生させて、それを自分で認識できたのか、という点のハズです。

今回のように、とあるシチュエーションについて自分はどう感じてどう行動しようと思うのかを考え発表しつつ他の人の話も聞くことで、単なる一般論だった知識が「経験」まで昇華されていくプロセスを体験することができたように思いました。


このやり方の一番の特徴は参加者によって得られるものが変わるという点でしょうか。
これまでの経歴によって1つのケースを見たときの感じ方も当然変わってきます。そうするとセミナー中にシェアされることも変わります。


これはメリットでもありデメリットでもありますが、現場の生の声が聞けるというのはかけがえのないものだと思うので、個人的にはそこそこ肯定派です。

自分の困りごとについて様々な意見がもらえたというのは、通常のセミナーではあまりないことだったので、とても有用でした。

まとめ

セミナーの形式にはいろいろなものがありますが、シェア会形式というのもなんかオトナな勉強の仕方みたいで、ぼくはいいなぁ〜と思いました。


特に社内セミナーとかだと、主催する人が一番やりたいと思ってる人だったりするので、一方的にしゃべって終わりってケースも少なくはない気がします。

シェア会形式だと、講師の人は進行役に徹するので、参加者が主役となってみんなで作り上げる会みたいな感じにしやすいです。


組織づくりやコミュニケーションなど、明確な答えが存在しないような話について扱うときはシェア会形式を取ってみるのもおもしろいと思います。

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

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

やり方

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

プロジェクトの振り返り（KPTの様な何か）

各種情報

参加人数：４人
場所：熊本（２拠点）、東京
テレビ電話：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を決める

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

やってみて

アウトプット

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について事前にちょっと考えておくとかのアナウンスをしていなかったので
  思い出す時間がちょっと少なすぎかなと思いました

まとめ

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

こんにちは！

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

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

マイオペでは、インフラとして本番、ステージング、開発、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/

こんにちは！
シタテル株式会社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月下旬に乗車すると、実際にどん兵衛をいただけるようなのでまた利用したいと思います！

こんにちは！
シタテル株式会社CTOの和泉です。
Follow @shinobu_shiva
今回は研究開発的に、「縫製工場の類似度算出を深層学習のモデルでやってみた」について書きます。
まず初めに結果から。

['loss', 'acc']
[273999.25, 0.695652186870575]

69.6% 成功？
なにが？って話ですよね。
結果的には全然精度出ませんでした。まぁ、のべ１週間ぐらいでやってみた感じですし、サーベイも全然できてないので結果出るわけないのですが。
せっかくやってみたのでブログに恥を晒しておきます。
その道の専門の方にはお目汚しかと思いますがご容赦ください。

やりたかったこと

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

希望的仮定

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

結果

教師データに対しては98.8%の正答率に達したが、テストデータについては69.6%にとどまった。残念ながら実用に足るような結果は得られなかった。

図１：教師データに対する推論結果のプロット（青が教師データ、点線先のオレンジが対応する推測結果）

図２：テストデータに対する推論結果のプロット（青が教師データ、点線先のオレンジが対応する推測結果）

図３：学習の経過

何をやったのか

データベースに保有する123の縫製工場を２次元平面上で類似しているものを近くに配置するように、弊社コンシェルジュに依頼して教師データを作成。（図１の青い点が各工場を表す）この際、「類似している=あるアイテムを相談するときに変わりに相談できる工場であるか」とした。作成された教師データが含む縫製工場データは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'])

_________________________________________________________________
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)

考察

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

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

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

工場を検索して絞り込み

（工場名や取引先は非公開のため消してあります）

いくつかの工場を並べて比較
弊社コンシェルジュはこれらのデータを使ってご相談いただいたアイテムごとに最適な工場に問い合わせを行います。