最近なんかクラウドソーシングの発注の質が落ちてきてる気がする

yusukeiwaki.hatenablog.com

この中で、

個人的にはクラウドソーシングを「大企業ではたらく人が、気軽にスキルアップできる＆感謝されて幸せになる手段」として布教したかったんだけど、営業利益のほとんどはおそらくフリーランスとプロいライターによって支えられていて、施策もそっちに寄りがちだった。

こんなことを書いてたんだけど、CW社を離れて１ヶ月、客観的にクラウドソーシングというものを見れるようになってくると、やっぱり発注される仕事の質の底上げ必要だよねって思ってきている。

気軽に副業できる案件ってどんなもの？

「仕事」というものには責任がつきまとう。とはいえ、いつまでも責任を負わされるものは気軽ではないし、なるべくリピートしたくない。ようは、一回ポッキリの仕事がとてもクラウドソーシングに相性がいいと思っている。

それって具体的にどういう仕事？というと、自分がいままでやったことあるものでいうと

  • 特許の実施例に書いている内容を実際にAndroidで実装してほしい
  • IoT機器の、音声認識部分（Androidで実装）の施策をしてほしい
  • 特定のサイトだけを閲覧できる、専用端末向けのブラウザを作って欲しい

などだ。

裏を返すと、

  • ○○を手伝ってくれるエンジニアさんを募集します！
  • 新規にSNSを立ち上げてほしい（Web/iOS/Android）
  • Railsでわからないところがあります。家庭教師してください

みたいなのは自分のなかでは地雷案件とおもっている。

仕事の質の低下は、発注者の質の低下のせいだ

質が良くない発注をする人は昔からずっと居たには居たんだけど、最近はその割合が増えてる気がする。（良い発注者が減ってるだけかもしれない）

あらかじめ１つだけ書いておくと、世間で騒がれている「安すぎるだろ！」みたいなのは個人的には質が低い発注とは思っていない。

「どういう発注者はダメなのか？」を2019/08/05現在のクラウドワークスの「仕事を探す」の検索結果ベースで解説していく。

無料求人広告媒体としてクラウドソーシングを使っている

crowdworks.jp

こういうやつ。極端に言えば、仕事に対する募集はしていない。ただエンジニアを募集しているだけ。

まるなげくん

crowdworks.jp

crowdworks.jp

こういうやつ。

「まるなげくん」っていうと発注してるひとが気分を害するかもしれないので、一応ことわっておくと、「もっと細分化して発注してくれたら気軽に仕事受けられるのに！！もったいない！！」というもの。

「iPhoneとAndroid両方お願いします♪」っていうのは非常にありがちなんだけど、世の中的にiOSとAndroid両方できる人ってまずそんなにいない。

  • iOS版アプリだけ、Androidアプリだけって発注してくれたらいいのに！
  • 「まずは試作だけ」「試作は有るので、プロダクションレベルにブラッシュアップする開発をしてほしい」ってフェーズ分けてくれたらいいのに！

と思うわけです。

ちなみに最近、割合として最も多いのがこのパターンだと思います。あくまで感覚値ですが。

検収能力のない発注者

これは具体例さすがに挙げれないｗ

けど、今までで"間違って"受注してしまって苦労をしたのが全てこのパターンだ。

冒頭で「安い報酬はそこまで問題じゃない」みたいなことを書いたのはこれが全てで、契約時に安い報酬を要求されたら単純に断ればいいだけだからだ。問題なのは、契約して、モノを作ったあとで「私にはこれが正しいかどうかわかりません」と言ってくる発注者たちだ。

時間かけてモノをつくったのに報われず、精神的にかなりつらい思いをする。

雑感

「まるなげくん」と「検収能力のない発注者」って実はけっこう共通項で、

やっぱり今の日本は多重下請け構造があるし（先日話題になったセブンペイとかまさにそう）、そういう延長線上でクラウドソーシングを利用している人だとどうしても検収能力がないまるなげ発注をしてしまうと思う。

クラウドソーシングのサービスは、会社存続のためには高額の発注をしてもらわないといけないので、やっぱり大きな企業の人に対して「クラウドソーシングで発注してね♪」みたいな営業をすることになるのは致し方ないと思う。ただ、そこでまるなげくんをそのまま許容してほしくはない。

  • 発注者に対して、フェーズやスコープを絞って発注したほうが、お互いに得をするよ！っていうことは教育してほしい
  • フェーズやスコープを絞って、発注者自身が検収できるようにタスクを分割しないと、お互い損するよ！！！っていうことは教育してほしい

まるなげくんに営業したあとに、↑みたいな教育なりコンサルなりも一緒にやると、もっともっと仕事の質あがるんじゃないかなーって思う。

まとめ

最近、副業したくても微妙な仕事しかクラウドソーシングになくて不満を書いた記事でした。

西新プラリバのオープンでいろいろ思ったこと

家の最寄り駅に、プラリバっていう小規模なショッピングモールがオープンした。

praliva.jp

そこまで期待はしてなかったんだけど、とりあえず行ってみた感じ、悪くはなさそうだなと思った。

オープニング

7/26 10:00オープンだが、内装は実は7/24の朝から見えていた。

f:id:YusukeIwaki:20190726232533p:plain

なんて小綺麗な。リバレインモールみたいに閑散としている様子が似合う感じ？と思ってしまうくらい、なんか上品だ。

ところが、今朝の様子が

f:id:YusukeIwaki:20190726232445p:plain

うわ、なんだこれ！

関東に住んでいたときに経験した武蔵小杉のごちゃごちゃショッピングモールを彷彿させる、ありえん人の多さだった。藤原紀香を見たくて並んでた人も多いんだろうけど。

なんというか、こんなに人があふれるのって西新地区では見たことがない風景なので、結構衝撃的でした。というか、通勤するときにめちゃくちゃ通行の妨げになっていて邪魔でしたｗｗ　広い地下があるのに、なんで狭い狭い1階をオープニングの待ちに選んだんだろ...謎。たぶん「地下は市の持ち物だから・・・」とかそういう系の理由なんだろうけども、正直とても迷惑だったので猛烈に反省して欲しいと思う。

"地下直結！"なのになぜか地下から入れない

これは確実に設計ミスじゃないかって思った。

地下直結！と言っているのに地下から入れない。暑いなか、階段で地下2階から地上1階まで上がり、そこから階段で地下2階へどうぞ、という謎のナビゲーション。（あとから分かったんだけど、このプラリバ、地下2階のフードウェイっていうスーパーの構造にかなりの難がある。）

お年寄りの方が、地下1階から入ろうとして警備員に止められている（地上まで上がって地下に降りて、という説明を受けて非常に困惑している）のを見て、なんかそれはちょっと違うんじゃないかって思わずにいられなかった。

迷路のようなスーパーマーケット

フードウェイという、福岡では比較的イケイケなスーパーが地下2階フロアの大半を占める形で入っている。

私の勝手なスーパーの王道ルートは f:id:YusukeIwaki:20190726235600p:plain

こんなかんじなんだけど、フードウェイ西新店は（うろ覚えだけど）

f:id:YusukeIwaki:20190727000925p:plain たしかこんな構造をしていた気がする。なので、慣れている買い物の仕方をしようとすると

f:id:YusukeIwaki:20190727001237p:plain

ああ悲惨・・・。

慣れなんだろうな。

お惣菜が入り口にあるっていうのは、たぶん成城石井あたりを真似したんじゃないかなっておもう。なんだけど、それにしては中途半端で、お惣菜のクオリティが低くノイズが多いかなと思った。

近所の西鉄レガネットストアよりも営業時間が長く、珍しいものも売ってそうなので、今後に期待かな。

待望の本屋さん

西新は修猷館高校もあることだし、勉強のためには本屋が必要だ。なんだけど、今まで中規模以上の本屋は無かった。

プラリバに新たにくまざわ書店っていうのができていて、小さいながら割といろいろな本がバランス良く置かれている印象。

いままで、六本松か天神まで出ないと本屋が無かったので、これは便利に使わせてもらうことになりそう。

あとのお店は・・・

天神VIOROで飲んでファンになったハニー珈琲をはじめ、多くの店にはまだ行けていない。

全体的に人が多すぎて、「また今度かな」ってなってしまったのが正直なところ。

ホークスタウンにあるマークイズ福岡に比べると、便利だし、リピート率が高そう。でも早く落ち着いてほしいなー。

自分用Cloud9をSSL化して、oauth2_proxyで自分だけの認証を追加した

この記事では、SSH使うから認証は後回しで、って書いてたんだけど、それじゃあChromebookで気軽にお遊びができないことに気づいたので、結局SSL化と認証を追加した。

ドメイン取得＆SSL化

certbot(Let's encrypt)を使うには、TXTレコードやCNAMEレコードをイジる必要があるので、しぶしぶ c9work.net というドメインを購入。（胡散臭いキャンペーンとか嫌いなので、AWS経由で購入した）

証明書の取得は

letsencrypt.org

にあるように、certbotで行う。

  • Cloud9 IDEを表示するURL（hogehoge.ide.c9work.net）
  • 成果物を誰かに見せる用のURL（hogehoge.preview.c9work.net）
  • 認証用その他もろもろのページのURL（auth.c9work.net, page.c9work.net, ...）

の3つを想定していたので、雑にワイルドカード証明書を3つ。

sudo certbot certonly --manual --manual-public-ip-logging-ok -d *.preview.c9work.net -m ore_ore@yahoo.co.jp
sudo certbot certonly --manual --manual-public-ip-logging-ok -d *.ide.c9work.net -m ore_ore@yahoo.co.jp
sudo certbot certonly --manual --manual-public-ip-logging-ok -d *.c9work.net -m ore_ore@yahoo.co.jp

みたいな感じで。

都度、TXTレコードに確認用文字列を入れる、みたいなことはやる必要があったけど、そこはRoute53なりAzure DNSなりで管理してたらなんの問題もなくいける。

前段にGitHub認証を入れる

これが結構つまった。（ひとえに、nginxのAuth Requestを知らなかったからなんだけどｗ）

SSL化をした時点で、

f:id:YusukeIwaki:20190722171647p:plain

なんとなくこんな感じに、nginx二段構えにしていた。なので、認証はとりあえずSSLオフロードをやってる前段のnginxに何かしらやればいいんだろうなーと。Cloud9 SDK自身も、なんとなく認証っぽい仕組みは内部で持っていそう（ core/auth.js at master · c9/core · GitHub ）だったんだけど、SSLオフロードした先に認証機構があるのはちょっと筋が悪い気がした、なのでnginxかその前段に持たせようかなと。

んで、CW社の偉大なる同期が昔書いていた記事も参考に、

qiita.com

これはとりあえずoauth2_proxyをAuth Requestと組み合わせて使えばラクかなと。

認証エンドポイントと認証した先に戻るURLでドメインが違うのをなんとかする

手っ取り早くウェブアプリケーションにOAuth2認証を導入する - その手の平は尻もつかめるさ あたりを参考にするとわかりやすいんだけど、oauth2_proxyは /oauth2/start?rd=/return_back_to/this/address のようにパスを渡すと、認証完了後に /return_back_to/this/address に帰ってきてくれる。

今回の場合は、

と想像していた。が、現実はそうはいかず。 https://auth.c9work.net/ にリダイレクトされてしまった。

oauth2_proxyのソースをみたら、「あーー」ってなんたんだけど

https://github.com/pusher/oauth2_proxy/blob/863539154366f456d8ba57142b3a66b4544fda82/oauthproxy.go#L477-L483

redirect = req.Form.Get("rd")
if !p.IsValidRedirect(redirect) {
    redirect = req.URL.Path
    if strings.HasPrefix(redirect, p.ProxyPrefix) {
        redirect = "/"
    }
}

をチェックして、NGだったら強制的に / に書き換えられてしまっているではありませんかー！

OAUTH2_PROXY_EMAIL_DOMAINS に .ide.c9work.net を設定すると解決。

GitHubユーザをYusukeIwakiに限定する

これも結構ハマった。

本当は前段の認証側でどうにかしたかったんだけど、nginx.confの記述方法わからなすぎたので、

  • 前段の認証ではGitHubユーザだったらとりあえず通すようにする
    • バックのnginxにリクエストを渡すときに X-Remote-Username というカスタムヘッダにGitHubユーザ名を渡す
  • バックに居るコンテナ振り分けをやるnginxのほうで、GitHubユーザ名が YusukeIwaki じゃなかったら強制的に403を返すようにする

という雑な方法で実現。

        location / {
            auth_request /oauth2/auth;
            error_page 401 = /oauth2/start?rd=https:///$host$request_url;

            proxy_set_header X-Forwarded-Scheme $http_x_forwarded_proto;
            proxy_set_header Host $host;
            auth_request_set $user $upstream_http_x_auth_request_user;  # ←認証完了時に、oauth_proxy2 がX-Auth-Request-UserヘッダにGitHubユーザ名をセットしてくれるのを拾う。
            proxy_set_header X-Remote-Username $user;  # ←nginx_backにリクエストをプロキシするときに、 X-Remote-Usernameというカスタムヘッダを付ける
            proxy_pass http://nginx_back:8888;
        }
    server {
        listen             8888;
          (中略)

        if ($http_x_remote_username != 'YusukeIwaki') {
            return 403;
        }

たぶんもっといいやり方はあるんだろうなぁ...。

そんなわけで

Chromebookでも開発をできるようになった。

うぇいうぇい