「クローラーとamazon出品管理システム」（mkh6811）

１．目的 
①「大量のデータを収集する最適クローラーの仕組みとその収集した情報を活用したAmazon出品管理システムの構築を目的にしたプログラムの製作請負契約」 
②テスト設計(単体テスト-結合テスト-総合テスト-受入テスト）＊リグレッションテストも含む 
③「即使用可能な環境構築(サーバーの選定やプログラムの稼動検証等)とマニュアルの作成」 
 
２．契約条件  
①納期：約６か月 
＊製作納期の遅延・製作の断念がない様に製作納期の回答は要検討願います。 
②予算：１５０万～２５０万 
③支払条件：契約締結後(仮入金後)、全額の納品検収完了時支払いで応じていただける方を優先致します。 
 ＊手付金支払後に一方的に契約内容を変更され、手付金を詐取されたため
 
④常に「電話」で連絡が取れる担当者を置く事。メールは１週間以内に返事をいただける事。 
⑤こちらが製作状況を常に把握できるような共有ツールを用いること。 
⑥類似プログラムの製作実績がある方及び規模が大きい為、複数の作業者を擁する提案者が望ましいです。 
⑦今回の依頼は「完成品の稼動状態での引渡し」を目的とする請負契約でございます。  
重箱の隅を突くようなことで未完成とはしませんが、技術的な問題や製作元の都合によるキャンセル等、製作途中で頓挫した場合はお支払いできません。 
 
３．発注先決定までの流れ 
広く「ウェブサイトへ最少の負担で情報を収集・利用する仕組み」を作るためすべての仕組みを募集致します。  
「一次審査」 
・アクセス拒否に対してどういった仕組み(簡単な概念図等での）を考えられてるかのご説明や 
製作実績をアピール願います 
・最後まで仕事をやり遂げる熱意をアピール願います。当たり前のことですが、一旦出来ると引き受けた仕事を、壁にぶつかると軽い損得感情で簡単に投げ出さす方にはお願いできません。【最後までやり遂げる責任感のある方】【個人等関係なく、契約の重みと仕事をやり遂げることへの意識を十分に持たれている方】を募集しております。 
 
「二次審査」 
必要機能の詳細を提示致しますので「見積」をご提出いただき、併せて月間の保守費用・その範囲についても概算金額提示願います。 
＊注文仕様書に記載の機能を全て製作いただく前提で発注致しますので、こちらが要望する全ての仕様をまず最初にご確認いただき、解らないままにして引き受けないでください。 
 
＜４．今回の主な依頼内容の概要＞ 
・十分な処理能力をもったクローラー(プログラム)をつかって情報収集したい。 
・在庫情報の収集対象となるウェブサイトは現時点で約34サイト 
・商品情報の収集対象となるウェブサイトは現時点で約5サイト(全てapi)で収集に必要な分類コード等の一覧はこちらで用意します。 
(国立国会図書館、amaozn japan,amazon usa,等) 
・商品情報の管理はクラウドでの管理を前提としますが、容量次第ではハードでの管理も検討します。 
・ウェブ API も情報の収集対象としたい 
・収集対象となるウェブサイトは継続的に増加していく予定。(＊その都度費用支払い) 
・収集対象となる情報は数千万のオーダーになる。 
⇒在庫元によっては商品情報を10～100件同時表示可能なため、一旦全件取り込んでプールしてデータベースと照らし合わせればアクセス数の大幅な削減が可能 
・情報の収集は継続的に繰り返したい。商品ごと情報収集先サイトごとに最適な更新頻度で行う。 
・複数台のクローラーを並行して動かしたい 
・任意のクローラーがアクセス禁止を食らってしまったら、そのクローラーはしばらくの間そのサイトを訪れないようにして別のクローラーに自動で切り替わるようにする。 
・ランニングコストはできるだけ下げたい。取扱い件数に応じた段階ごとの費用積算を希望。 
・どのクローラーがどのウェブサイトのどの情報を収集しているのかなどのモニタリングも出来るようにしたい。 
・収集したデータを閲覧するための管理画面がほしい 
・クローラーの数や収集頻度などは管理画面上で設定したい。 
 
＜５．再募集にあたって＞ 
過去に当方の募集を拝見いただいた方も多いと思いますので今回再募集に至った経緯についてご説明致します。 
この点が今回の依頼の難点でもあると言えますので、この点要ご検討の上ご提案願います。 
＜理由＞ 
①想定していたプログラムの能力不足 
「取扱商品数」は提示しておりましたが「情報の更新頻度」や「１回のアクセスごとの情報量」の想定が甘く、考えていたプログラムのスペックでは捌ききらないとのことでした。 
＜対策＞ 
事前に「取扱商品数」「情報の更新頻度」「１回のアクセスごとの情報量」を予測想定値を予め提供致します。事前に議論を重ねてトラブルがないようにする方針です。 
②ランニング費用の膨張 
取扱商品数を契約サーバーの能力に合わせて段階的に調整することで解決できると思います。サーバー切り替えタイミングを何段階に分けるかを協議する必要があります。 
③「AWS lamdba」の採用断念  
以前サーバーレスの利用を検討し「AWS lamdba」ベースで検証したところ アクセスが拒否される事象が起きました。無論サーバーレスであっても問題なく情報収集できるのであれば可です。