CO-NECTテックブログ

CO-NECT株式会社開発部門のブログです。テック関連の情報を発信していきます。

個人的にリモートワークが最高だった理由

f:id:co-nect-tech:20200828173249j:plain


CO-NECT株式会社の二階堂です。
昨年の1月より業務委託のエンジニアとして参画させていただいています。

 

新型コロナの影響により、今年の3月ごろからリモートでの業務対応となりました。
その中で感じたメリット・デメリットをお伝えしたいと思います。

 

  

リモートのメリット

  • 通勤時間がなくなったことにより、1日5時間くらい自由な時間が増えた

私は都心から離れたところに住んでいるため、通勤時間は出社の準備時間を入れると往復5時間ほどかかっていました。
自分としては通勤時間がなくなったことはかなり大きいメリットで、以前は平日は出社して帰宅後は寝るだけの生活でしたが、リモートになってからは、時間をかけて夕食を作ったり、趣味の時間が持てるようになりました。

 

  • 昼休みの時間が充分リフレッシュできる時間になった

以前は、昼食のためオフィスを出て戻ってくると休憩時間が終わっていました。
また、弁当持参のときでも30分程は昼食以外に休憩が取れますが、オフィスなので自宅ほどはリラックスできませんでした。
リモートになってからは、昼食後に仮眠を取ったり軽い運動が容易にできるようになったため、午後の作業パフォーマンスが以前より上がったと感じています。

 

  • 開発業務に集中できた

以前はオフィスで作業していたため、複雑なロジックを考えているときに話しかけられたり、他の方の話し声が気になったりということがあって集中力が途切れることが度々ありました。
リモートなってからは、自宅の静かな場所で考えることができるので集中力が途切れないようになりました。その結果、開発スピードが以前より上がったと個人的には感じています。

 

  • 情報連携が明確になった

以前は、他のメンバーが今どんな作業をしていて、どのくらいの進捗状況なのかがリアルタイムにはっきりと分かっていませんでした。
その理由は、気になったときはオフィスにいるため、いつでも気軽に聞ける状態だったからだと思います。
リモートになってからは、気軽に聞ける状態ではなくなったため、以下の取り組みを行っています。


・リモート出社時にその日の予定をSlackに投稿する
・夕方ごろ開発メンバー全員でMTGを行い、進捗状況の共有や作業で困っていることを相談する
・退社時に朝投稿した予定に対しての進捗をSlackに投稿する


この取り組みを行った結果、情報連携が明確でスムーズになり、以前より業務的に改善されていると思います。

 

リモートのデメリット

  • 仕事とプライベートな時間の区切りがつけづらくなった

以前は、退社後に帰宅してからは仕事をすることはほとんどありませんでしたが、リモートになってからは、進捗が悪いときは仕事が気になってしまい退社後も作業してしまうことがありました。
翌日通勤がないことをいいことに、気がつくと深夜になっていたこともしばしばあります。

 

  • 社内の方とのコミュニケーションが少なくなった

以前は、一緒にランチへ行ったり、飲みに行ったりというところで他部署の方ともコミュニケーションを取っていましたが、リモート後はそのような機会が激減してしまいました。
当社では、以前から月に一度飲み会が開かれており、その習慣は今でもリモート飲み会として続いているのですが、やはり実際に対面で会話するのとは違うので少し寂しい気もしています。

 

まとめ

ここまで、リモート業務において感じたメリット・デメリットを挙げさせていただきましたが、私個人としてはメリットの方が断然大きいと考えています。
将来、リモートワークが当たり前の時代となり、会社に通っていた時代を懐かしむ日が来るのではと期待しています。

 

おわりに

当社では、サービスを一緒に作ってくれる仲間を募集中です。興味のある方はお気軽にお問い合わせください。

 

conct.co.jp

BtoB SaaSのスタートアップはフルリモート化でどう変わったのか

f:id:co-nect-tech:20200730182328p:plain

 

CO-NECT株式会社の川崎です。7月20日(月)にマイクロソフトさんのオンラインイベント「これが私のおすすめリモート開発事例」に登壇させていただき、「BtoB SaaSのスタートアップはフルリモート化でどう変わったのか」というタイトルでお話しさせていただきました。

msdevjp.connpass.com

 

もともと弊社はマイクロソフトさんのスタートアップ向けプログラムである「Microsoft for Startups」に今年の2月から採択されており、その一環でお声がけいただきました。なお、Microsoft for Startups は、参加特典が充実しており、Azureを使ってシステム開発などをされている会社さんにとってはメリットの大きいプログラムとなっています。その他にも様々な良いことがあるので、興味のある方はエントリーしてみることをおすすめします。

startups.microsoft.com

 

さて、本題です。以前の記事でもお伝えした通りですが、弊社では新型コロナの影響で原則リモートワークを継続しています。まさかここまでリモートワークが継続するとは思ってもいませんでしたが、実際に運用してみると様々なメリットと課題が浮き彫りになってきました。全員出社が原則だったコロナ以前と、リモートが原則になったコロナ以後でのチームはどのように変化したのか。それをまとめた表が以下となります。

 

f:id:co-nect-tech:20200730135914p:plain

 コロナ以前の項目については、まあよくある話なので割愛しますが、コロナ以後の運用になってどのあたりが良かったのか、課題が残るのかを書いていこうと思います。以下は弊社エンジニアの声をベースにまとめています。

 

 

原則的に全員リモート出社

良かったこと
- 通勤時間がなくなったことで体力的に楽になった
- 自宅とオフィスが遠い人ほど時間の節約ができる
- 家の方が開発に集中できる
- 気分転換に運動にでかけたりするのが容易になった

 

課題
- 家庭環境によっては集中できないこともある
- 本番作業時のストレスは増えた
- 気軽にお酒を飲みに行けない

 通勤時間がなくなったことで体力的な負担がなくなったという声がありました。これはたしかにごもっともかと思っていて、リモート前提の生活の中でたまに出社すると、なんで移動にこんな時間をかけているんだと不思議な気持ちになります。

もともとの大前提として出社が当たり前の世界から、突然在宅が基本の世界になったというのはかなりドラスティックな出来事です。また在宅での働きやすさは個人差があると思いますので、独立した仕事環境が確保できる人にとってはオフィスより快適かと思います。

ただ私のようなお酒好きにとっては、仕事後に飲みに行けなくなったのはちょっと寂しいですが、これはリモートワークが原因というよりもコロナが原因ではあるので、諸々収束したらそんなに気にしなくてもよいはずですね。

 

プロジェクトごとのMTGは原則廃止し、日次のオンラインMTGを厚めに実施

良かったこと
 -話す時間が確保されたことで、気軽になんでも話せる環境になった
- 相談事項や進捗報告の習慣化がなされた
- 画面共有で仕様の認識合わせが容易になった

課題
- 気が向いたタイミングで雑談、というのが難しい

 これはリモート化をきっかけに弊社内でのコミュニケーションのスキームが変化したというのが大きいです。もともと顔を合わせて仕事をしていたので、雑談をしたり、ちょっとした相談事項を話していたりしたのですが、リモート化でそれがなかなか難しくなってしまいました。

もちろん、Slackで常時接続されているので会話をしようと思えば可能です。ただ空気感というかその場の勢いみたいものを感じることは難しく、雑なコミュニケーションは取りにくい状態になりました。ですので、仕組みとして毎日30分から60分程度、決まった時間に開発チームで集まる時間を決めて、そこでいろいろ話す、みたいな運用を始めた感じです。これが意外とよくて、良い意味で状況共有の習慣化につながりよりオープンなコミュニケーションができるようになったと感じています。

 

週次のMTGはオンライン化で継続

良かったこと
- 日々の進捗確認は日次MTGに集約されたので、勉強会的なことや、ディスカッションの時間として活用できている
- 1週間の総括として、頭の整理に役立っている
- 中長期的な開発計画の認識あわせに役立っている

課題
- 日次MTGとの内容がかぶることがある

 いままで週次で行っていたチームMTGのあり方の再定義につながりました。毎日の定例MTGで細かい調整やら進捗やらは共有されるようになったので、週次のMTGではより中長期の開発計画やディスカッションに使うことができ、情報の整理に役立っています。

 

基本的にはテキストコミュニケーションベース

良かったこと
- テキスト情報は最初から要点が整理されているので理解が早まった
- 他チームメンバーからの口頭での仕様相談などがなくなったので、開発業務に集中できるようになった
- オープンなコミュニケーションが前提となったため、全員の進捗がクリアになった

課題
- 日常的に接点が少ない人とはより一層絡みがなくなった
- 会話の間を読むのが難しく、ドライな書き方になると怒られているのかな?と感じることがある(話すと怒ってなかったりする)

 フルリモート化の醍醐味はここにあると思っています。リアルに顔を合わせないことでラフなコミュニケーションは取りにくくなった一方で、ほぼ全ての情報がテキストに集約されるのでインプットが楽になりました。

今までは俗人的になりがちだった仕様の話も、しっかりとテキストでコミュニケーションが取れれば情報として残りますし、複数人に展開するのも容易です。もちろんテキストだけでカバーできないこともありますので、その際はビデオMTGも交えてコミュニケーションをとりつつ、議事録を作ることも大切です。

とはいえ、基本は相手の顔を見ずして会話をするわけで、人によっては「なんでこの人怒っているんだろう?」とか実際に怒っていなくてもミスリードするリスクはありますので、より丁寧な会話が求められる状況にはなってくるはずです。

 

*当日の資料です。

www.slideshare.net

まとめ

フルリモート化は弊社ではたまたまフィットしている感がありますが、業種業態や、会社の規模などによっても向き不向きがあるのかなとも思います。特にテキストで情報をまとめるのが苦手な人は、自分の言いたいことをうまく伝えられず、相手にも分かってもらえず、しかも温度感も分からずちょっとずつ、ずれていってしまうとかありそうなので、自社の体制に最適なコミュニケーション手段を模索していくのが大切なのかなとも思います。

 まだまだコロナ収束の目が見えない中、いかに社員のコロナ感染リスクを抑えつつ業務のパフォーマンスを上げていくのかというのは日本全体の課題であるとは思っているので、部分的にでもリモートワークを導入する企業は増えていくはずです。

 弊社で開発している受発注システムCO-NECTは従来の受発注業務をデジタルシフトさせるためのツールですので、コロナ禍において一定の効果を見込んでいます。業務のデジタル化による生産性向上は重要課題でもあるので、必要な人に届いて欲しいと思っています。

conct.jp

そんな当社では、サービスを一緒に作ってくれる仲間も募集中です。一緒にDXを推進しましょう!ご連絡お待ちしています。

conct.co.jp

受発注SaaSのインフラ整備について

CO-NECT株式会社の太田です。

2020年2月にWEBエンジニアとして入社しました。

受発注ツールCO-NECTの機能開発も行っていますが、今は弊社で運用しているサービス全体のインフラの運用をメインに行なっています。

本日は私の日々の業務内容を簡単に紹介したいと思います

業務の紹介 

業務内容としては主に3種類あります。(1)快適に利用していただくための施策立案と実行、(2)安心して利用していただくための施策立案と実行、(3)IT統制の整備です。

 

(1)快適に利用していただくための施策立案と実行
受発注ツールCO-NECTは利用者の増加と取り扱うデータ量の急増により、常にパフォーマンスの改善と戦っています。
そのために、パフォーマンスを可視化するためのダッシュボードの整備、サーバーの負荷が高まった際の通知、必要に応じてサーバーの増強やスケールアップなどを実施しています。
また、ミドルウェアのチューニングによりコンテンツの圧縮やキャッシュ等の改善も行っています。

 

(2)安心して利用していただくための施策立案と実行
弊社で運用している受発注ツールCO-NECT・受発注ラボ・コーポレートサイトはAWSとAzure(パブリッククラウド)上で稼働しています。(本テックブログははてなブログにてホスティングしています)
パブリッククラウドを利用する上で重要なのが責任共有モデルであり、責任共有モデルに基づき、弊社にてOSの更新やセキュリティパッチ等を適切なタイミングで適用し、併せてファイアウォール設定などを実施しています。
また、データの保全という観点で、定期的に作成している複数世代のバックアップデータを一定期間保存するようにしています。さらに利用者のコンプライアンス要件に応えるために、サービス上で作成された各種伝票は国内データセンターの他に、海外のデータセンターにも安全に転送し保存するようにしています。(これはAWSのクロスリージョンレプリケーションで実現しています)
その他、適宜セキュリティポリシーを見直しており、最近ではTLS1.0/1.1を無効化しています。

 

(3)IT統制の整備
私が注力して整備しているのがログ管理です。
弊社ではサービスの利用者のアクセスログの他、ファイアウォールにより遮断した通信のログ、弊社のエンジニアのだれが・いつ・どのサーバーにアクセスしたか、VPNをいつ利用したか等の情報、クラウドサービスの操作ログ等を保存しています。(AWSの操作ログはCloudTrailを利用して保存しています)
今後、さらにログ管理の対象を広げていく予定です。

 

本日は短くまとめてしまいましたが、次回はより詳細について紹介していきたいと思います。

 

おわりに

私たちと一緒にサービスのパフォーマンスや信頼性、セキュリティ強化などを取り組みたい仲間を募集しています。
取り組むべき課題も多く、やりがいがあると思います。興味のある方はお気軽にお問い合わせください。

 

参考リンク

責任共有モデル
https://aws.amazon.com/jp/compliance/shared-responsibility-model/

クラウドにおける共同責任
https://docs.microsoft.com/ja-jp/azure/security/fundamentals/shared-responsibility

レプリケーション
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/replication.html

受発注ツール CO-NECT(コネクト)
https://conct.jp/

受発注ラボ
https://media.conct.jp/

コーポレートサイト
https://conct.co.jp/

「企業における情報システムのログ管理に関する実態調査」報告書について
https://www.ipa.go.jp/security/fy28/reports/log_kanri/index.html

求人
https://conct.co.jp/recruit/

CO-NECT株式会社でチャレンジしていること!

CO-NECT株式会社の木村です。

約10年程勤めた楽天を退職して2020年1月からCO-NECT株式会社のエンジニアとして働いて来て4ヶ月経ちました!

自分の感覚では1年以上働いている感じがします(あとなぜか古参感も出してるみたいです)

f:id:co-nect-tech:20200507104725p:plain

CO-NECT株式会社でチャレンジしていること

入社当初からチャレンジしている事の一つとして

今後、急激に利用アカウント数と大企業クライアントが増えるこを想定した

システムのパフォーマンス改善を実施しています。

パフォーマンスが与える影響について

なぜパフォーマンス改善対応が必要かと言いますと、

パフォーマンスがサービスの使いやすさに影響を与える。

これは当たり前のことですが。

 

パフォーマンスが最終的にサービスが成功するか失敗するかを決める大きな要因の一つになっているからです。

パフォーマンスを制するものはサービス成功を制するといっても過言ではないでしょう!

(NO Performance NO Success Of Service)

と私は思っています。

パフォーマンスがオンライン ベンチャーの成功に及ぼす影響は非常に大きくなっています。

パフォーマンスの低いサイトと比較してパフォーマンスの高いサイトがどのようにユーザーの注意を引き、ユーザーを引きつけておくことができるかを示すいくつかの事例があります。

 ・Pinterest では、ユーザーが体感している待ち時間を 40% 削減した結果、検索エンジンのトラフィックとサインアップ数が 15% 増加しました

 ・COOK では平均ページ読み込み時間を 850 ミリ秒短縮したところ、コンバージョン数が 7% 増加し、直帰率が 7% 減少し、セッション当たりの閲覧ページ数が 10% 増加しました

パフォーマンスが悪かったことが原因で、ビジネス目標に悪い影響が及んだいくつかの事例があります。

 ・自社サイトの読み込みにかかる時間が 1 秒増えるごとに BBC はユーザーが 10% ずつ減少することを発見しました。

 ・ページの読み込みにかかる時間が 3 秒を超えると、DoubleClick by Google は 53% のユーザーがモバイルサイトの訪問をあきらめることを発見しました。

developers.google.com

DBのパフォーマンスチューニング

今回はパフォーマンス対応の中でもDBチューニングによるパフォーマンス対応を紹介したいと思います。

知ってる人には当たり前!と思う内容で恐縮ですが、

DBチューニングは知っていれば簡単に対応ができて、すぐ有効になるパフォーマンス対応の一つです。

DBパフォーマンスチューニングの進め方

弊社では下記のステップでDBパフォーマンスを対応しています。 

 

Step1. 【各ログの出力】SQLクエリの実行ログやプロファイリングによるログを出力

Step2.【調査】フロントエンド・ネットワーク・API・DBなどの切り分けを実施し、

         DBの場合は下記の”DBのチェックポイント”で原因を調査

Step3.【改善】原因にあわせた対応を実施(”改善方法”を確認)

Step4. 【リリース】問題がなくなったらリリース

DBのチェックポイント

DBのパフォーマンスへ影響をあたえるのは以下の項目になります。

No

項目

理由

システムへの影響

1

大量のSQLクエリを発行しているか

  • フロント側の実装も問題になることがありますが、フロント側では全てのSQLクエリ実行が完了するまで待つことになります。
    そのため一つ一つのSQLクエリが早い場合でも大量のSQLクエリを実行してしまう処理だとパフォーマンスが遅くなってしまいます。

  • レスポンス遅延
  • CPU高負荷

2

スロークエリが発生していないか

  • スロークエリは応答に時間がかかるだけでなくDBのCPU高負荷の原因にもなります。

  • レスポンス遅延
  • CPU高負荷

3

参照系はリードレプリカを利用しているか
(書き込み処理・読み込み処理を管理する)

  • 読み込み処理を分散することでDBの負荷を軽減します。

  • マスターに負荷をかけずに処理したいときに有効になります。

  • マスター(更新処理)が遅延する
  • レスポンス遅延
  • CPU高負荷

4

適切なトランザクションが設定されているか

  • 特に更新系で大量のSQLクエリを実行するときに1レコード毎にDBとのトランザクション管理している場合は処理が遅くなります。

  • マスター(更新処理)が遅延する
  • レスポンス遅延
  • CPU高負荷

改善方法

1. 大量のSQLクエリを発行している場合

  • データを更新する処理の場合(更新系)

    • bulk updateで纏めて更新処理を実行する。

    • MySQLではLOAD DATA INFILEを利用する。

  • データを取得する処理の場合(参照系)

    • テーブルを結合することで必要な情報を一度のSQLクエリで取得するようにする。

    • 参照用のテーブルもしくはKVSから取得するようにする。結果として、1回の処理で完了するようにする。

2. スロークエリが発生している場合

  • インデックスの追加

    • WHERE文で利用するカラムにはインデックスを追加する。

    • テーブル結合で利用するカラムにはインデックスを追加する。

  • 複合インデックスの追加

    • WHERE文で複数の条件が設定されている場合は複合インデックスを追加する。

  • 型を統一

    • テーブルを結合するときにカラムの型が同じでないとインデックスが効かないので
      結合するカラムは同じ型を設定する。

  • サブクエリを利用しない

    • サブクエリの場合はインデックスが効かないので、サブクエリを利用しない。

3. 参照系の処理について

  • (参照系)読み込み処理はリードレプリカを利用する。

4. トランザクションの処理について

  • 更新系で大量のSQLクエリを実行するときは1レコード毎にDBとのトランザクションを設定しないで、全体の開始と終了のみに設定する。

 

次回も取り組んでいる事や開発したプロダクトの紹介などを書いていきたいと思います。

最後に、CO-NECT株式会社に入ってよかったこと

  • なんといってもメンバーが最高です!

  • サービスが魅力的です!

  • やりがいが沢山あります!

人生色々チャレンジしたい!とい思ってたところ

前職時代の飲み友達との縁でCO-NECT株式会社に入りましたが、毎日楽しく日々をおくっております。

正直、もっと早くチャレンジしても良かったと思っています。

 

そんな当社では、サービスを一緒に作ってくれる仲間も募集中です。興味のある方はお気軽にお問い合わせください!

conct.co.jp

 



ガイアックスさん主催のイベントにオンライン登壇しました

CO-NECT株式会社の川崎です。先日ガイアックスさんのイベントに登壇させていただきました。本来ならNagatacho GRiD で開催される予定でしたが、昨今のコロナの情勢を鑑み、スピーカーのみ来場し、オーディエンスはオンラインでの参加という形になりました。

gaiax.connpass.com

 

 

イベント当日の様子

当日はパネルディスカッションベースで他のスピーカーの方とざっくばらんにお話しつつ、「DXを推進するBtoB SaaSを支える開発チーム構成と必要スキル」というテーマで少し話してきました。プレシードからプレシリーズAあたりのエンジニアチームではどんなスキルセットが要求されるのか、というお話でしたので、こちらはまた改めて記事にできればと思っています。 

半分オンラインイベント

今回、スピーカーのみ来場するといういわば半分オンラインのイベントだったわけですが、近くに人がいる状態で、オーディエンスは目の前にいない、というのは初めての経験でした。なかなか不思議な感覚です。本来、目の前に聞き手がいる場合、話したことにリアクションがなかったり、無関心な雰囲気を感じると若干滑った感が出て心が痛むものですが、今回の場合聴衆のリアクションがまったくわからないので、ある意味無敵状態で話しやすかったです。対面イベントと完全オンラインイベントのいいとこ取りな感があります。

f:id:co-nect-tech:20200417142808j:plain

会場の様子。運営スタッフの方々の手際がよかった

 

アフターコロナにはイベントのあり方が変わりそう

今はコロナの関係でこういうハイブリッドのイベントは開催しにくいものの、終息後はもっとライトにこういう感じのイベントが行われていくものと思います。登壇者だけリモートで、参加者はどこかの会場に集まるとかもありそうですよね。また完全オンラインでのイベントもこの逆境の中でフィットする方法が確立されていくはずで、何かしらかの答えが出ると思います。オンライン飲み会を始め、今は皆試行錯誤の中で良いやり方を探している段階なので、こういうイベントのあり方もアフターコロナの世界では変容していくでしょう。

リモートワークはハマっている

当社でももうひと月以上リモートワークが行われています。元々決まった時間に会社に出勤し、同じ空間で仕事を行うという「常識」の中で働いてきたものの、今回の件でそれがいかに食わず嫌いだったかが明らかになってきています。もちろんリモート化したことで顕在化した問題点もありますが、それ以上にバリューも出ています。大きな波の中で、変化に順応できた組織が生き残ると思いますので、引き続き良いバランスを模索していこうと思います。

 

そんな当社では、サービスを一緒に作ってくれる仲間も募集中です。興味のある方はお気軽にお問い合わせください!

conct.co.jp

 

 

 

 

 

CO-NECTテックブログを開設しました

CO-NECT株式会社の川崎です。「やさしいテクノロジーで社会をアップデートする」をミッションとする当社は、従来のアナログ受発注業務を劇的に効率化するために日々プロダクトの開発を進めています。

f:id:co-nect-tech:20200305113823j:plain

 

私たちのミッション

f:id:co-nect-tech:20200305110903p:plain

私たちが解決すべき課題

日本の飲食小売業界を含む多くの事業者では未だ日常的にFAXを使った発注が行われ、通常業務が終わった深夜に店舗でFAX発注を行うなど、時間的空間的制約の中で行われています。それに加え、手書きで発注する際は発注ミスも起こりがちですし、誰がいつ何を発注したかという本来共有されるべき情報も漏れてしまうなど、アナログ発注だからこそ起こる問題もあります。

当然発注側がFAXを使えば、商品を販売する側の卸もFAXから出力された紙を元に取引をすることになりますし、販売管理を行うためにPCにデータを打ち直す必要もでてくるのです。

このように取引にFAXが使われると、発注する側、受注する側関係なくアナログ取引を強いられることになり、双方の生産性が悪くなるという構造的な問題をはらんでいます。

テクノロジーの力で解決を目指す

そこで私たちは、このような問題を解決するために「受発注ツールCO-NECT」をリリースしました。以下に特徴を記載します。

受発注ツール CO-NECT(コネクト)

発注CO-NECTの特徴

発注CO-NECT

  • 直感的なUIで、誰でも簡単に使えるWebサービス
  • 取引相手が受注CO-NECTを使っていなくても、Web上でFAXへの発注やメールへの発注に対応
  • 取引相手が受注CO-NECTを使っていればクローズドなECサイト(発注フォーム)から簡単に発注可能
  • 取引相手が受注CO-NECTを使っていれば受付中、出荷済みなどのステータスをリアルタイムに確認可能
  • 複数人で使えば、発注履歴の共有が可能
  • 発注レポートで発注額の確認も容易

受注CO-NECTの特徴

受注CO-NECT

  • 商品管理、顧客管理、受注、出荷、請求まで一気通貫で対応可能
  • 受注レポート機能で売り上げ分析など様々な分析が可能
  • 発注CO-NECTからFAX、メール発注があった場合、注文情報をWebで管理することが可能
  • 複数人で使えば、商品管理、受注管理など職務で分担することが可能
  • 顧客ごとに販売する価格を変更することに対応
  • グラム、キログラムの量り売りに対応
  • 納品書、請求書などの帳票をPDFで出力可能

おわりに

私たちはユーザ様からのフィードバックを元に日々プロダクトのアップデートを行なっています。使っていただくユーザ様の想像を超えていくために、リリースサイクルは短めに設定し、高速で改善を進めています。

何か気になる点、使いにくい点がございましたら弊社カスタマーサクセス担当までお気軽にご相談ください。

今後こちらのテックブログではプロダクト開発に関わる情報を配信していきます。

 

私たちのサービスを一緒に作ってくれる仲間も募集中ですので、興味のある方はお気軽にお問い合わせください。

conct.co.jp