  |
はてなキーワード: 発注者とは
-
日本でプログラムを作ってもらおうとするとめちゃめちゃお金がかかる。
-
[まず中抜きされている分高くなる]
まず中抜きが多すぎるんじゃないっていうのはよく言われているけど、それはそのとおりだと思う。
少し話はずれるけど、一次請け辺りにいる人達はそもそも優秀な人が多いんじゃないかとは思う。
だけど下請けに仕事を発注することを何十年もやっていれば、それは無能集団にならざるを得ないよね。かわいそうだけど。
そういう人達にお金を一番払っているのだから、無駄にソフトウエアが高くなるのは当然。
客はこの役立たずたちの生活のために、多めに料金を払っている。
元請は調整役なんだから必要だよって思う人もいるかもしれないけど、実際にはそれすらも下請けにやらせているところがたくさんあるし元請の役割って、仕事を受注するためのブランドだったり看板でしかないこともある。
-
[くそみたいなプログラマーが時間をかけて作るからもっと高くなる]
それでもって、不当な扱いを受けている下請けのプログラマーがかわいそうって話になるけど、本当にかわいそうなのはお客だ。
まず日本では適正のないものを大量に雇っている。ベテランとか言われている中にもまともにプログラミングできないやつらはたくさんいる。
そもそも勉強する気がないのが大半なので、経験則でくそみたいなプログラムを書く人間が80%くらい。
そういう人間ばかりのプロジェクトは、1ヶ月くらいで終わりそうなものを何年もかけてつくることすらある。
そういうやつは居てもいなくても良いんだけど、っていうか居ないほうがいいんだけど、会社的は居たほうがメリットがある。
なぜかというと、プログラマーを売るときはスキルに関係なくある程度の値段で時間貸しできるから。
できるやつ1人にできないやつ5人くらいをつけて、客先に送りつけても6人分の料金をふんだくることができる。これは普通に行われている。
-
つまりはお客は、
プライドだけ高い元エリートくそじじい(今は役立たず)にたくさん中抜きされるお金を支払わされて
さらにまったく必要とされていないたくさんのプログラマー分の給料までも支払わされているってことになる。
^
わたしはSI下請けプログラマーなので、自分が一番かわいそうな立場なんだといつも思っていたけど、よく考えてみればこんな業界に発注せざるをえないお客さんたちも結構かわいそうだよなあと思う。
ただもういらすとやで全部賄えるし
AI使えばいらすとやのイラストベースに無限にイラストを自動生成することも可能になるので
そうなるともう受注してまで欲しいイラストなんてなくなると思う
タダでいくらでも湯水のように手に入るものを欲しいと思う人間は居ないし
むしろ発表する場、宣伝する場を与えてやるんだからイラストレーターは発注者にお金を払うべきだ！
って考えも出始めてる
コンテンツの主体はそれを発表する場であり、それを売って利益を出す仕組みのほうで
乞食になりたくなければ自分1人で作ったものを自分で売るようにしないとならない
マネジメント力が無いクリエイターは死んでかなきゃならないのは仕方ないんじゃない？
それを衰退と言うのは甘えだ
「私」の謙譲語で「小職」とか「小生」というものがある。社会人ならこれらの一人称を使ったメールを受け取ったことは一度や二度ではないのではないだろうか。もしかしたら自ら使っている人もいるかもしれない。しかし、これらはよくよく考えて使う必要がある謙譲語である。
三省堂 大辞林によると、「小職」については「官職についている人が自分をへりくだっていう語」、「小生」については「手紙文などで，男子が自分をへりくだっていう語」とある（weblio辞書）。また、デジタル大辞泉では「小生」について「[補説]ふつう、自分と同等か、目下の人に対して使うものとされる」ともある（goo辞書）。「小職」についてはこのような記述は見当たらなかったが、このような言葉が成立した頃は官職というのは民間からすれば圧倒的な存在であったので、いずれにしても社会的な位が極めて高い人が使う言葉である。
つまるところ、これらは「自分の職位がとても高いのだけど、（だからこそ）へりくだってやる」または「自分は大変な人格者なのだけど、（だからこそ）へりくだってやる」という意味が含まれている。
これを踏まえると、たとえば、組織や部署の長が「小職の意見は○○ですが、皆さん（部下）の意見も聞かせてください」というような使い方は適切である。一方、部下が上司に「小職の意見を申し上げます」とか、審査を受ける側が審査をする側に対して「書類に不備がありましたら小職にご連絡ください」などというのは不適切である。同様に、社長が社内報で「小生の生い立ちから現在までを綴る」のは適切だが、受注者が発注者に対して「小生含め二名でお伺いします」というのは不適切である。
この手の一人称を学生時代から使っている人は滅多にいないだろうから、大体偉い人から回ってきたメールとかで使われているのを真似して使い出すようになるのだろうが、よく知らないで使っている人はよくよく考えて使った方が良い。
まぁでも、若くして偉い人の言い回しを真似るようなタイプの人っていうのはそれでもって偉くなった気になりたいような人が多いので、心情を込めるという敬語表現の存在意義からすれば、あながち誤用とも言い切れないのかもしれない。
（自らの悲哀に満ちた立場をネタにしたTwitterアカウントを運営している官僚がおそらく正しい意味合いを知りながら意図的に使っている例が散見されるが、これについては非常にウイットに富んだ使い方といえよう。）
SESやってるとあまりにもこの組み合わせが多くて、実は間違ってるのはこっちなんじゃないかって思うほど多いから、改めて記す。
大前提として「請負と準委任契約」は、発注側から請負作業者への直接指示をしてはいけない。（直接指示が許されるのは、特定派遣か一般派遣の場合のみ）
発注側から指示がある場合は、必ず「請負側の管理責任者」に対して行われなければいけない。
つまり、「請負と準委任契約」は、最低2名からなるチームを持つ会社でないと請け負うことはできない。
現場に請負側の管理責任者と作業者がいて、管理責任者が何か作業する場合、これは「管理と作業の兼任」になるが、作業をしながらも作業者の管理や発注側との交渉を行う権限を行使できるのであれば、兼任でも問題はない。
ただし、これは「管理責任者と作業者」という最低2名が現場にいる場合に限っての話だ。
そもそも現場に1人しかいない場合、その作業者に発注側が作業指示しても、それは「管理責任者に対する指示」にはならない。
厚生労働省から出ている 労働者派遣・請負を適正に行うためのガイド から引用する。
請負事業主の管理責任者が作業者を兼任する場合、管理責任者が不在になる場合も発生しますが、請負業務として問題がありますか。
A
請負事業主の管理責任者は、請負事業主に代わって、請負作業場での作業の遂行に関する指示、請負労働者の管理、発注者との注文に関する交渉等の権限を有しているものですが、仮に作業者を兼任して通常は作業をしていたとしても、これらの責任も果たせるのであれば、特に問題はありません。
（中略）
さらに、請負作業場に、作業者が1人しかいない場合で当該作業者が管理責任者を兼任している場合、実態的には発注者から管理責任者への注文が、発注者から請負労働者への指揮命令となることから、偽装請負と判断されることになります。
これらの取り決めは、適正な労働環境を維持するため・労働者を守るためのルールである。
1年目の新人が、いきなり1人で客先常駐になり、会社名の違う人間から無理難題を押し付けられる。新人には発注側との交渉を行う権限もなければ、自分の作業分量を管理する権限もない。けれど、これが当たり前なのだと思って無理な作業を受け入れ、やがて潰れる。
これは新人に限った話ではない。なんの裁量もなくただ作業を押し付けられるだけの作業者は、いつか潰れるのだ。
現状には外注というシステムがあって、第三者であるライターが文章を書く仕事がある。第三者のライターとAIの関係は似たような構造。だからこれがAIが発達してそのAIに文句を言っても今さら感が拭えない。いや、今だってAIじゃないにしろ他人に仕事振ってるじゃんという。要はAIが台頭したらそれをコントロールする側じゃなきゃどうしようないことを知っているから騒ぐのだろうけどな。結局、外注して第三者にやらせるという意味では、それはAIがやろうが構造的には同じ意味だ。だから発注者と書き手、どちらの生き残る確率が高いかという話になったら前者だろうなぁ。もしくは如何にユニークなAIを開発して魅力的な文章を提供できるかとか。
自分より優れたるものを自分の周りに置きし者ここに眠る。カーネギー
できる人ばかり辞めていく会社が研修費用を出すようになったら、さらに退職が加速したというお話「人事に聞かせたい」 - Togetterまとめ
「従業員にトレーニングをして、よそへ行ってしまったらどうするのか」という疑問に対するStanger氏の答えは、「従業員にトレーニングをしないで、彼らが会社にとどまってしまったらどうするのか」ということになる。
従業員の才能を爆発させるには「会社に人を長く留める」戦略を捨てる必要がある
ttps://b.hatena.ne.jp/entry/s/gigazine.net/news/20171005-superboss/
「弱いつながり」理論でいうと、SNSでつながる友だちは、それこそFacebookの友だちが3,000人規模で、国内のスタートアップの経営者なら、たいていの人に直接または1hopでつながることができる。
ttps://s.nikkei.com/2vJsvYx
優れたマネージャーは自分より高い給与をもらう可能性のあるポテンシャルの高い部下を喜んで雇う
ttp://b.hatena.ne.jp/entry/www.masafumiotsuka.com/2015/11/the_peter_principle.html
人材は会社の資産として残らないが仕組みは会社の資産として永遠に残る
ttps://www.amazon.co.jp/dp/B010JM64M6/
ttps://employment.en-japan.com/engineerhub/entry/2019/11/07/103000
ttps://www.slideshare.net/yattom/ss-79372905
ttps://tinyurl.com/y8tkhuhz
ttps://bit.ly/2MylBjs
"競争優位につながるような戦略的なソフトを開発しようとするなら内製しかない。"
ttps://www.amazon.co.jp/dp/4822273784
ttps://medium.com/@kuranuki/aac6062adfb2
どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるか
（中略）
ソフトウェア開発とは、経営的意思決定の集積なのだから、経営的意思決定を外部の会社に委託するというのは、「経営を外部の会社にやってもらうようなもの」だからだ。
もっと言うなら、自分の会社の今後のビジネス的ポジションを、他社に決めてもらうようなものだからだ。
外注を出された会社は、そのソフトウェアが未来に実現するであろうビジネス的価値を犠牲にして、できるだけ少ないコストで作ろうとする。
ttp://fromdusktildawn.hatenadiary.jp/entry/20061003/1159869683
ttps://bit.ly/2JzCggZ
「ソフトウェア業界（特に受託開発業界）は、基本的に正直者が馬鹿を見る世界である。顧客が、保守性というソフトウェアの最も重要な品質を正しく評価できないという、情報の非対称性が存在するからだ」/分かるなぁ
「モダンな開発環境×技術顧問×内製化」Sansan×日経電子版 アプリ開発の最前線を語る夜
ボタンを1つ追加するだけで2週間。内製化によるスピードアップは必須だった。
「アプリ内にボタンを1つ追加するだけで、2週間の開発期間と、数十万円のコストが発生していました。それでは急な仕様変更に対応できないし、技術ノウハウも貯まらない。」
ネットサービスの肝は、開発にかける額の多寡というよりは、内製化するかどうかにあると思っています。
ローンチした後、そこからの追加・改善はものすごいスピードでやらなくちゃいけない。これは、内製体制でないと絶対に不可能です。
2017年1月、ネット証券大手のマネックス証券は証券基幹システムを刷新した。
お客様へ提供するサービスの開発スピード向上と、ノウハウの社内蓄積、開発コストの適正化を目的に、
（中略）
サービスの改善や新サービスの開発時に、ASPサービスの提供会社との会議に費やしていた時間を削減し開発のスピードアップを図ることで、競合他社への競争力を強化したいと考えました。
ttp://b.hatena.ne.jp/entry/s/quality-start.in/it-strategy/467
ttps://twitter.com/kanayang2009/status/129677947572465666
ttps://amzn.to/2ncDXrO
だから育てるんだ。
ABテスト デザイン OR ボタン OR 文言 - Twitter検索
外注でもA/Bテストでユーザの反応を計測してトライ・アンド・エラーでシステム開発ってできるもんなんだろうか。
できるとして、それって内製化した方がずっとクオリティ高くなるんじゃないの？
ttps://twitter.com/fromdusktildawn/status/874796380522336256
「外部委託すると細かい継続的な機能の改善が遅くなるので、自社採用でかなり優秀な人材をケチらずに採るべきだね。なかなか見つからなくても妥協せずに」ホリエモン
ttps://bit.ly/2QWMsoJ
外注はPDCAを回せないという致命的な欠点がある。ITスタートアップの感覚だと外注と内製には天と地ほどの差がある
ttps://bit.ly/2J5UCWQ
銀の弾丸ではないがリーンな開発は競争力の源泉。そのためにはPMFをコントロールできる開発チームが必須でそれは内製でしか達成困難。
ttps://bit.ly/2vkDd8E
正解に当たるまで回し続ける！3ヶ月で200回のA/Bテストから得た「意外な結果」とは
弊社のイベント一覧のページなのですが、単なるテキストの羅列のパターンと、リッチなレイアウトのものでテストすると、いつも必ずテキストの方が勝ちます。
海外テック情報局：eBayではダサいデザインのほうがコンバージョン率が高かった｜gihyo.jp … 技術評論社
デザイナと口論したいのではなく，見たいのは数字とお客さんの利用例。
そして何がうまくいっているのか突き止めたい。
選択の科学 ２４種類のジャムを売り場に並べたときと、６種類のジャムを売り場に並べたときでは、前者は、後者の売り上げの１０分の1しかなかったのです。
ttps://amzn.to/2I2V1O4
エンジニアでないファウンダーは最大一人まででお願いします | On Off and Beyond
理由１：変更につぐ変更を重ねられるようにする
最近 lean startup なる考え方がはやってますが、これはどういうことかというと、
東大合格者ランキングは正しいのか？――常に分母は何かを考えよ
何事にも閾値はある。そこに至らなければ、意味がないという数字だ。
「頭のいい人が成功しない理由」という本に、閾値の話があった。
だれもが中途半端にやめてしまう。それでは足りない。閾値を越えない。
ttps://ameblo.jp/chimu841/entry-10036171360.html
ttps://amzn.to/2Odv25b
①内製
②外注
フラクタルなレモン市場問題｜建築不動産クラスタ交流会の件その１
ttp://realtor-readyabooks.hatenablog.com/entry/20100515/1273919457
ttp://ledsun.hatenablog.com/entry/2016/02/28/014851
ttps://ja.wikipedia.org/wiki/情報の非対称性
ttps://ja.wikipedia.org/wiki/逆選抜
ttps://ja.wikipedia.org/wiki/取引コスト
「探索コスト」
時給制（時間を売る）が生産効率低いのって自明だよなぁ・・相当ボランティア精神ないと時給制で効率よくやろうって気持ちにならないよね
でも拘束時間で金額を決めてしまっては効率化を目指さなくなるんじゃないか
ttp://b.hatena.ne.jp/entry/b.hatena.ne.jp/entry/194800390/comment/redhornet96
ttp://b.hatena.ne.jp/entry/twitter.com/etomiho/status/872820182883762176
ttp://b.hatena.ne.jp/entry/twitter.com/etomiho/status/872822997106565120
ttp://getlife.hateblo.jp/entry/2013/09/10/015011
見積もりが人日で工数を計算していると、実際にはそれよりも短期間で実装できても見積もり日数になるまで納品を待ったりすることはある。
納期よりもかなり早い段階で実際には完成しているにも関わらず、
エージェントが利益相反行動をしていないかどうか監視するためのコスト。
自身の行動がプリンシバルの利益追求にかなっていることを証明するために
ttps://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1212240292
ttps://twitter.com/search?q=rails%E3%80%80%E9%A1%A7%E5%95%8F
「顧問プログラマ」再考 - Rails 雑感 - Ruby on Rails with OIAX
ttps://www.oiax.jp/rails/zakkan/rethinking_of_adviser_programmer.html
ITエンジニア採用に欠かせない原則とは (1/5)：IT人材ラボ
ttp://b.hatena.ne.jp/entry/s/itjinzai-lab.jp/article/detail/856
ttps://www.slideshare.net/fukumura1/fukuokarubykaigi-medpeer-ver1
【256人がリモートワークで回る仕組みを考える】後編
ttps://www.remotework-labo.jp/2015/10/interview_10/
「既存のプログラムに対して、機能Aを入れたいんだけど何人日？」みたいな質問あるじゃん？
機能を入れるのは良いよ
たぶんすぐ終わるよ
でもね、その前任者が作ったクソコードに機能を入れるのは、かなりきつい作業なんだよ
機能を入れようとしたら、どこか修正点が出たり、バグが発見されるんだよ
バグを直そうと思ったら、他の何かも作り変えなきゃいけないんだよ
作り変えるってなったら、そもそも正しい仕様が分からなきゃいけないし、テスト範囲も広範になるんだよ
わかる？
そもそも前任者はどこへ行ったの？ え、居ない？ 何で辞めたの？ 何か嫌だったんじゃないの？ それを俺にもするの？
ていうか何でそんなクソコード書くやつ入れたの？ おまけに逃してるし
じゃあ仕様は？ 何が正しいかは誰がわかってる？ それぜんぶ俺が聞き出さなきゃいけないの？
わかったよ、やるよ
いつ終わるかって？ しらねーよ神にでも聞け
機能Aなら直ぐ終わる
俺もそう思うよ、何でだろうね
クラウドワークス上に掲載されてる仕事案件、悪質なの多すぎだろ。
記事制作なんか、物理的に1時間位かかる作業でも1記事10円とか。酷いと1円だぜ?普通に1時間労働する最低賃金は都内だと932円だ。
1時間必要とする業務内容の対価が1円やら10円やらって、依頼主はカスかよ。
そんでもって「コピペ禁止」だの「記事書き直せ」だの言ってくるんだぜ。
んで、そういう依頼が多発してるにも関わらず、クラウドワークスは放置してやがるんだぜ。
これさー、依頼内容もクラウドワークスの体制も厚労省か労基署に報告して強制家宅捜査とかすべきレベルなんだけど。
政府って基本メディアに大きく取り上げられないか、人が死なない限り仕事してくれないから厄介だけどさ、たった数十円の小銭をチラつかせて個人情報を差し出させる案件も多すぎるんだわ。「外部コンテンツにユーザー登録したら100円あげるよー」な依頼も多い多い。
大手口コミサイトが数十円チラつかせてユーザー登録と口コミ投稿を募集してるのもいっぱいだー。
そしてクラウドワークス上で違反としている依頼内容も見る限り6〜7割はあるのだが、クラウドワークス様は放置してるがな。
『発注者と受注者の直接取引禁止』というルールを全面に出してるくせに、キュレーションサイト問題の時は『発注者と受注者が直接取引をしている為、私達はそんな実態知りませーん』ときた。
同じサイズだから管理しやすかったり、配送時に積み上げやすかったりという理由ももちろんなんだけど、一番はサイズを同じにすることで内容物に対して思考停止させることが目的らしい。
中身によってサイズを変えてたら逆にサイズから中身を想像できてしまうだろ？
最初の頃は高そうなものが盗難に遭いやかったり、安そうなものは乱雑に扱われたりという事故が多かったらしい。
さらに宅配先に届ける荷物の傾向で、住人の収入や職業、趣味嗜好が特定されやすくなってしまい、ストーキングや空き巣に対して大きなヒントになってしまっていたそうだ。
ところが箱のサイズを一律にしたことで、重さの情報だけでは価格帯はもちろんどんなものが入っているかが全くわからなくなったそうだ。
それによってどんな荷物も扱いが一律になって、盗難も物損も激減。
発注者のプライバシーも守られることで応対コストも下がって、多少の過剰包装になっていたとしても、トータルでみるとかなりのコストカットにつながっているらしい。
わざわざ死んだじいちゃんが夢に出てきてまで教えてくれたんだから間違いない。
welqの一件以降、クラウドソーシングに対する風当たりが強くなっている。
筆者は過去、主にクラウドワークスで200記事ほどライティングを請け負ったことがある。だが、やがて「クラウドソーシングはライターをダメにする」と思い、それ以降は使用していない。ただ、世話になったことを差し引いても、たとえば主婦（夫）の方が新たな可能性を掴む土壌となったなど、素晴らしい点もあるサービスだと思う。
ただ、だからこそ、書いておきたいことがある。
それは、クラウドソーシングがライターをダメにするサービスと化している、ということだ。
◇
筆者がクラウドワークスを使っていたのは、2013年の夏から2014年の冬にかけて、およそ半年ほどだ。以下の話は当時の経験をベースにしている。ただ、発注者としてクラウドソーシングを利用している知人数人に話を聴いたところ、おそらく状況はいまでも似たようなものだと思う。
クラウドソーシングが、なぜライターをダメにすると感じたのか。
それは「褒め殺しが横行している」からだ。お世辞と言い換えてもいい。
クラウドソーシングの発注者は、なぜかやたらに褒めてくれる。いつどんな仕事を納品しても、
「いつもありがとうございます！」
「いつも素晴らしい仕事、ありがとうございます！」
こんな具合だ。
筆者もクラウドワークスで20案件ほど発注いただいたが、オール5だった。
なにかおかしいと思った。
◇
発注者が期待する以上のものを返そうと努力してきた自負は、もちろんある。だから最初は高い評価がついても、単純に「ありがとうございます」と感謝を覚えるだけだった。
ただ、この違和感を覚えた直後、筆者は過去に書いた記事をすべて見直した。
すると、文章のつながりがおかしいと感じるところがあったり、恥ずかしながら誤字脱字も数か所あったりするのを確認した。
前者については、経験を積むうちに自分のスキルと感性が磨かれ、それまでなら気にならなかった点に違和感を覚えるようになった可能性はある。だが、後者の誤字脱字はそれ以前の問題だ。
もし、発注者がきちんと記事内容を確認しているなら「誤字脱字があります」と連絡するはずだろう。
だが、そうした連絡は一度もなかった。
では、なぜ連絡がなかったのか。考えられるケースはいろいろある。
たとえば、
1：このくらいならこちらで直してしまおうと、スルーしているケース。
2：面倒だからこのまま掲載してしまおうと、スルーしているケース。
こんなところだろうか。
そもそも記事内容を確認しないのが問題なのは、すぐ分かるだろう。著作権法に違反していても、その記事がそのまま掲載されてしまう。今回のwelqのケースだ。二番目も同様である。
では、冒頭の「こちらで直そう」はどうだろうか。
実はこれもかなり問題だ。
なぜ問題なのか？
◇
上述した通り、クラウドソーシング上では、基本的に褒められることしかない。よほどひどい仕事や対応でもしない限り、大抵の場合は受注者に対してポジティブな評価やコメントが並ぶ。
だが、それは言い換えれば「欠点を指摘されることがない」ということだ。
欠点を指摘されなければ、その改善はできない。PDCAが回せない。最悪、称賛を浴びすぎて「俺すごい」「私すごい」と勘違いする可能性もあるだろう（意識的であれ無意識的であれ）。その勘違いは、自分を省みる機会を奪い、スキルや知識を磨こうというライターとして当たり前の使命感と向上心を削ぎ落とす。
しかし、駆け出しのころは、そうしたセルフマネジメントもなかなか上手くいかない。「良い記事とはどんな記事か」「守るべきルールはなにか」を見極める知識や感性がないため、自分の記事の不足を自分で見抜けないのだ。
もちろん発注者にフィードバックする義務はない。長期的にその受注者と付き合う気がなければ、褒め殺し・お世辞を駆使して一時的に良好な関係を維持し、円満に「さようなら」するだろう。
そうした「誉め殺し」の蔓延が、クラウドソーシングに登録しているライター全体の平均値を下げている可能性は十二分にある（というか確実にあるだろう）
それによって、クラウドソーシングから生まれるライティングの平均値が下がる。
それによって、粗製乱造が進む。
誰も幸せになれないのだ。
◇
もっとも、このあたりはライターの自己責任だろうという意見もありそうだ。一理も二理もあると思う。
受注を受ける以上はプロとして仕事をしなければならない。クラウドワークスやランサーズにワーカーとしてアカウントを持っている以上、プロとしての自覚を持たなければならない。
そしてプロである以上、教えてください・指摘してくださいなどという受け身の姿勢ではいけない。
実際、クラウドソーシングで仕事を依頼すると、できないことに対して「できません」と返信してくるライターが多いように感じる。だが、できないことを「できない」と言いつづけていては、成長できない。
また、この手のスキルと意識に不足が目立つライターは、クラウドソーシング以外で仕事をとることが難しい。そのため仕事はすべてクラウドソーシングから受けるしかない。よって、フィードバックがもらえない仕事を延々と受け続ける。
つまり、成長しないのだ。
一方、実力がある人は、どんどん自分で仕事をとっていくので、クラウドソーシングからは離れていく。安い仕事をつづける理由などないからだ。
よくサイトを運営している知人から「クラウドソーシングにはロクなライターがいない」という声を聴く。その実態の裏には、あるいはこうした背景があるのではないだろうか。
だから、安値の依頼でも、普通に受注される。1文字0.5円でも受ける人がいる。
なぜか。
いまのクラウドソーシングは、この二者のみが跋扈するプラットフォームへとなりつつあるような気がしている。
◇
では、なぜ「褒め殺し」が横行するのか。
もしかしたら、発注者側がライター側に気を遣っているのかもしれない。
あるいは、自分の体面を気にしているのかもしれない。
クラウドソーシング上では、発注者がどんな評価をつけたかは誰の目にも明らかだ。よって、自身の体面を気にして★5つしかつけない可能性はある。上述した「褒め殺し」に等しい受注者とのやりとりも、彼・彼女から低評価をもらわないためかもしれない（もちろん、なかには素直なコメントもあるだろうが）
だが、クラウドソーシングで取り交わされる仕事は、当たり前だが「ビジネス」だ。
ビジネスで遠慮などいらない。褒めるべきは褒め、言うべきことは言うべきだ。
◇
閑話休題。
ある知人のライターが、こんなことを言っていた。
曰く「ありがとうございます！ これで大丈夫です！ と言っていたのに、掲載時に手直しが入っているのを知って、気分を害した」とのこと。
「修正点があるなら、その場で言ってくれ」と思ったそうだ。
◇
welq問題を皮切りに、クラウドソーシング全般が「悪」のような風潮が蔓延しないか、筆者は危惧する。決してクラウドソーシングというサービス自体が「悪」ではないと思うからだ。
もちろんクラウドソーシングの運営会社には、上述した受発注時の悪癖や、ほかに要因があるのであればなんとかして欲しいとは思う。ねとらぼの記事のように、運営会社の営業が今回の問題に率先して加担していた事実があるのなら、即刻やめてもらいたい。
＊ねとらぼ｜「クラウドソーシングサイトも共犯だ」 キュレーションメディア炎上騒動についてWELQ記事寄稿ライターが怒りの告発
http://nlab.itmedia.co.jp/nl/articles/1612/13/news140.html
このままでは、せっかくの素晴らしいプラットフォームが、ライターを安く買い叩いてやろうという悪徳業者によって汚される一方だからだ。
クラウドソーシングによって新たなチャンスを得られるかもしれない人々から、そのチャンスを奪うことになるからだ。
べつにその営業がクビになろうが、どうでもいい。
◇
今回のwelqのような記事を書いていて「これまずくないか？」という倫理観が欠如しているというのは、極めて問題だ。
ねとらぼの記事では、告発したライターが「クラウドソーシングも同罪」と言っている。
以下の記事だ。
＊ねとらぼ｜「クラウドソーシングサイトも共犯だ」 キュレーションメディア炎上騒動についてWELQ記事寄稿ライターが怒りの告発
http://nlab.itmedia.co.jp/nl/articles/1612/13/news140.html
◇
クラウドソーシングが新たな就業スタイルやキャリアの可能性を切り拓いたのは、紛れもない事実だ。
筆者も、ライティング経験がゼロからクラウドワークスでライター業をスタートし、個人ブログ経由で出版社から編集やライティングのご依頼をいただいたり、上場企業の編集長を委託していただいたり、貴重な機会を手にすることができた。
クラウドソーシングがあったからこそ、手にできたチャンスだった。
がんばれ、クラウドソーシング。
http://business.nikkeibp.co.jp/atcl/report/15/110879/092300445/
この件については電通に同情する余地はなく、徹底的に膿を洗い出して欲しいと思う。
ただし「広告代理店は不正を働くものだからもっとノルマや監視を厳しくしてコストを下げてやれ」という方向に流れがいくことが個人的には一番怖い。この件は電通の組織的な問題だけではなく、広告業界全体の問題、ひいては企業の広報担当者やメディア関係者含む、広告に携わる全ての組織と人間が関係する問題だと思うから。
知らない人多いと思うけど、電通は日本のデジタル広告を扱う代理店の中では最も先進的な取り組みをやっていて規模も大きく、ここ最近M&A含めかなり強引にデジタル化を進めて、テレビ一辺倒の収益体制からの脱却を図ろうとしていた。
誓っていうけどおれは別に電通の回し者でもなんでもないし、つい先日まで広告代理店でデジタル広告をやっていた。もう辞めたけど。後で書くけどデジタル広告業界は漆黒なほどブラックな業界だ。これを業界全体が改善するきっかけになったらいいと思ってるけど、さらに悪い方向に進む可能性もあると危機感を持っている。こうやってる今も死にそうな顔で仕事をしてるかつての同僚がいるに違いないし。
まず今回の問題を乱暴に一言で言ってしまうと「日本の広告業界のデジタル広告の未成熟さ」に尽きると思う。
何が未成熟かというと色々あるが、中本副社長も言っている通り「組織の管理体制」「恒常的な人不足」がまず大きい。元も子もない話だけど、「発注する側も受注する側も、デジタル広告についてあまり分かってない」ので。
広告代理店は「代理店」なので、発注者が面倒臭い、できればやりたくないことを代理でやることでお金を頂戴している。広告戦略の策定・具体プランの提案・運用・レポート・反省点と次に生かすべきポイントを報告、などなど。会社にもよるし人にもよるからこれが全部じゃないけど、基本的に企業の広報担当は代理店からの提案を受けて、確認をし、問題があれば改善指示を出し、よければ社内決裁を通すだけの場合が多い。この社内決裁がまた面倒だし、最近は定時もうるさいので発注者側はデジタル広告について勉強しない。そもそもあまり興味がある人もいないかもしれない。それでもデジタル広告は国産/海外産含め新しいテクノロジーや広告メニューが毎日のように発表されるし、それを活用した新たな事例や手法がどんどん登場する。代理店の担当者はこれらを常にチェックして、発注者のためになるプランとメニューを作り、適切に受けた発注の運用を行なっていかなくていけない。
ただしこれができる代理店の人間は、もう本当にほんとーーに少ない。代理店の人間の大部分は、細かい数字ばっか追っていくような仕事をそもそもやりたがらない。でもニーズはめちゃくちゃある。だから発注を受けたら子会社やグループ会社の人間に丸投げすることになる。
そして子会社やグループ会社の人間は、残念ながら優秀な人間は少なく、大きな戦略を作ったりすることはおろか、与えられた目の前のタスクもボロボロこぼしていく有様だったりする。そりゃそうだ、給料低いんだもん。経験の少ない若者か、経験はあっても能力の低い人しか雇えない。
代理店はその中でも比較的マシな人間を代理店に出向させて名刺をもたせて権限を与えてデジタル広告担当として業務を押し付ける。そこで成長してバリバリこなす人もいるけど、たいていは津波のように押し寄せる業務に呆然となってしまう。日付の確認ミス・金額の記入間違い・指示を勘違いして間違った発注をする、間違ったバナーを掲出する等々、細かいミスやケアレスが多発していく。呆然となりながら業務をしているとミスをしたことすら気づかず、次々とやってくる業務をちぎっては投げ、ちぎっては投げを繰り返す。受注を取ってくる営業がそんな細かい運用の話をわかるはずもなく、売り上げのことだけを考えて、ミスが含まれたレポートや請求書を、分からないまま得意先に報告することになってしまう。
デジタル広告の運用結果は数字に表れるから、得意先は代理店から報告された数字を見ながら、提案されたプランの中で、予算に合っているメニューを選んでいくんだけど、その数字には「どれだけの人間が稼働して作ったものか」が一切現れない。デジタル広告担当は毎日朝帰り、休日出勤当たり前が恒常化している。体を壊して休職する者も多い。
広告代理店は発注者の「これやりたい！」を何とかして叶えてやることで食っている商売だから、それは組織としてやりたいを叶える体制を作らないといけないんだけど、管理職のオヤジどもはデジタル広告の現場で何が行われているかわからず、かつて自分達がテレビコマーシャルの受注を取ってきたようにイケイケドンドンで売り上げを伸ばそうとして無茶なノルマを現場に課すことになる。
現在広報部長や宣伝部長を務める人も同様で、何となくデジタルが重要だということは知ってるけど、具体的にどういうことなのか全く分かっておらず、面倒臭いことは嫌だから細かい数字の話は避けて、「とにかく最先端でかっこいいことをやって目立って話題にしてほしい」と言う。そもそも得意先の言う「やりたい！」がどう考えても達成出来ない無茶苦茶な要求である場合も多いのだ。
これは広告業界に蔓延する悪癖のようなもので、特に電通は「いまの広告の最先端はこれですよ！？え、あなたの会社はまだですか？遅れてる！」といって発注主も代理店も煽って焚きつけて商売にしようとしてる。電通報とかその権化のようなサイトだ。
そもそもデジタル広告をまともにできる人間が全然育ってないのに、業界全体で「デジタルだデジタルだ」と掛け声だけは威勢が良く、組織的なサポートもほとんどなく小会社やグループ会社、下請けに丸ぶりし、一部の責任感の強い担当者が過労で疲弊する中でミスが起こり、ミスに気づかず間違いのまま発注主に報告や請求が行く。
広告のデジタル化は避けては通れず、今後も需要は高まっていくのは間違いなく、今は完全に個人が人力で回しているのをいかにして組織的に回していけるようにするかが課題だ。
一番の問題は発注者側も、代理店側も、「デジタルはやらないといけないのは分かってるけど、面倒臭いことはやりたくない」というマインドであることだ。
電通の不正を追及するのは最もだけど、本質はそこではなく、業界に携わる人間全員が腹をくくってデジタル広告を正面から取り組むこと、そしてそのための組織的なサポート体制を作ることだと思う。
正社員にしろ派遣にしろ、Web系、SI系にかかわらず、開発するのに最低限の環境さえ用意できない会社が淘汰されない社会が問題。だいたい、何が問題なのかもわかってないんじゃないのか。ここで書かれてる質問に全部論外になる会社なんて腐るほどあるけど、そういう会社に仕事を回す発注者がいる限り改善など無理。
ただ、会社にとっては、細かい環境にこだわる人は後で文句ばかり言いそうだから扱いにくいって感じるだろう。面談の場では仕事の遂行能力だけじゃなく人柄も見ているだろうから。本当にこんな質問をしていると、どこも雇ってもらえないんじゃないか。
http://simplearchitect.hatenablog.com/entry/2016/06/20/080807
から始まった何年ぶり何度目かのウォーターフォール (vs アジャイル) 論争だが，この記事もその反論記事・支援記事も含めて，「ウォーターフォールを採用する（せざるを得ない）理由」について書いてあるものはあっても，「ウォーターフォールのメリット」について書かれた記事が見当たらないのには驚く。
http://simplearchitect.hatenablog.com/entry/2016/06/20/080807
まずこの記事。「メリットはない」って言ってるんだから，書いてないのは当然なのかもしれないが，アジャイルのメリット＝なぜアジャイルがいいのか，についても書かれていない。これではFUDといわれてもしかたない。
http://ledsun.hatenablog.com/entry/2016/06/21/102501
「日本でアジャイルが流行らない理由」≒日本でウォーターフォールが採用される（消極的な）理由は書いてあるが，ウォーターフォールのメリットについては書かれていない。
http://ledsun.hatenablog.com/entry/2016/06/21/102501
タイトルから期待して読んだが，「ウォーターフォールの課題と言われてるものは，実は解決されてるよ」という記述が大半を占める。
最後の一節は「アジャイルの問題」として，「変化に人間がついていけない」点が挙げられていて，その裏返しでウォーターフォールがいいよ，ってことを言いたいのかもしれない。しかし，アジャイルは「変化に機敏に対処する」ことが眼目であって，何でもかんでも変化させなければいけない，というものではないので，指摘自体が的外れに見える。
http://arclamp.hatenablog.com/entry/2016/06/23/172941
冒頭，
とあって，メリットを語ってくれるかな，と期待させるが，結局「スコープが確定しているならウォーターフォールでいい」，という消極的な採用理由が述べられるだけで，メリット＝積極的な採用理由は述べられていないように見える。
それを語る前に，まずウォーターフォールを定義しておく。現在日本でウォーターフォールとして認識されているプロセスは，国防総省式の「戻りの線」なしのものである。即ち，確定した要件なり仕様なり（以下まとめて「スコープ」と呼ぶ）は変更しない。「ウォーターフォール」という名前自体が，この一方向性に由来している。従って，ウォーターフォールの定義としては，「（フェーズゲートを超える際に）確定したスコープは変更しないプロセス」で良いだろう。
この定義に沿わないプロセスは，「偽ウォーターフォール」であり，以下に述べるウォーターフォールのメリットを受けることはできない。メリットを享受できないだけでなく，この種の「偽ウォーターフォール」は（「偽アジャイル」同様）大きな害悪を撒き散らす。
さて，「確定した要件・仕様は変更しない」ことのメリットは何か。パッと思いつくのは「手戻りがない」ということである。確かにこれはメリットと言えるかもしれないが，手戻りがなくてうれしいのは主に作業者である。これでは弱い。もう一歩踏み込んで「手戻りがない」と発注者／受注者含め何がうれしいのか。
答は
である。
すごく当たり前のことなのだが，これが書かれている記事が見当たらない。
そしてウォーターフォールのメリットはこれだけで，それ以外にはメリットと言えるものはおそらく存在しない。
ここで，前節で登場した三つの要素「スコープ」「コスト」「納期」に注目してみる。
よく見るとこれらは，いわゆる「QCD」に対応している。ちなみにここでいう Quality (品質) は「バグがない」等の「問題の不在」だけを指すのではなく，本来の意味での「品質」，即ち利用者の役に立つか，使いやすいか，ということまで含むものである。スクラム（アジャイル）を知る人であれば，「トレードオフ・スライダー」の「品質」に相当するものだと理解してもらえればよい。
そうすると，前節のウォーターフォールのメリットは，以下のように言い換えることが可能である。
「ウォーターフォールのメリットは＜品質を固定することで＞コストと納期がぶれるリスクを小さくできる点にある」
これで問題が明らかになった。要するにウォーターフォールは，コストと納期のために品質を二の次にするプロセスなのである。
その結果，これまでどんなことが起きてきたか。
開発の途中で，要件や仕様に問題が見つかったとしても，あくまでウォーターフォールの定義に殉じると，出来上がるのは「使いにくい」「使われない」システムである。
「事業会社をIT会社に転生させることが、これからのSIerのミッション」 ( http://gothedistance.hatenadiary.jp/entry/2016/06/20/153941 ) に，その実例らしきものがでてくる。
これを行った瞬間から，ウォーターフォールはその（ほぼ）唯一のメリットを失い，混沌が始まる。
最も多いパターンは，発注者側が（もはやスコープ＝品質を固定するという前提が失われているにも関わらず）納期とコストの確定というメリットの享受を譲らず，プロジェクトがデスマーチ化する，というものであろう。あるいは，コストは譲るが納期は譲らない，というパターンの方が多いかもしれないが，いずれにせよデスマーチ化につながりやすいことは間違いない。
そしてこの副作用として何が起きたかというと，受注者側がそれを見越して納期とコストにバッファを積むようになった。当然それは見積もりの不透明感につながり，発注者側に受注者が「ボッて」いるのではないかという不信感を植えつけることになった。要するにお互い不幸になったのだ。
スコープの変更の必要が生じたら，どちらに転んでもいい結果は得られない。となると，ウォーターフォールがうまくいくのは，「スコープが明白で，変更の可能性が全くない」開発案件に限られる。統計をとったわけではないので，そのような案件がどの程度あるかはわからないが，直感的には「ほとんどない」のではないかと思う。なぜなら，そこまでスコープが明白であれば，今はパッケージやSaaSのようなレディメイドのものを導入する方が安いし早いしリスクも小さいからだ。
もう一つの可能性としては，スコープが変更不要になるまで，とにかく事前の準備と調査を徹底的に行う，というパターンもありうる。しかし，これは「準備と調査」の過程で事実上いろいろ試作することになる（そうしないと変更のリスクが消せない）ので，もはや作業プロセスの大半が実はウォーターフォールではない，ということになるだろう。
ではアジャイルのプロセスを導入すれば，これらの問題はすべて解決するか，というとそういう話ではない。ウォーターフォールにメリットが（ほとんど）ないことと，アジャイルが有効であることとは，独立な議論である。
そもそも「アジャイル」というのは考え方であってプロセスではない。だから，考え方を理解せずにプロセスだけ導入すると「偽アジャイル」になって，害悪を撒き散らすことが多い。
アジャイルの考え方は，主に以下の2点でウォーターフォールと大きく異なる。
1. スコープの変化がありうることを前提としている
2. スコープ＝品質＝役に立つこと（＝使えないものを作らないこと）が最優先であり，そのためにコストや納期が変化を（ある程度）受け入れる
この考え方こそアジャイルの本質であって，CI/CDやDevOpsなどは，変化にすばやく対応するための道具にすぎない。もっといい道具があればそれを使えば良いし，CI/CDがなくても変化に迅速に対応できるのなら使わなくてもいい。
また「スコープに変化がありうること」は必ずしも「スコープをできるだけ確定する」こととは矛盾しない。リスクを下げるために，スコープはできるだけ確定する努力をする，というのはアジャイルでも変わらない。変えるべき時は変える，という点が違うだけだ。なんでも後で決めればいい／変えてもいい，というのは「偽アジャイル」であって，害悪でしかない。
もちろんこれがあれば何もかもが解決する，という類のものでもない。上述の2点があるだけで（少なくとも今のたいていの開発案件において）ウォーターフォールよりマシになりうるとは思われるが，別の問題（例：納期やコストの変化をどう扱うかという問題）も，同時に導入されてしまう。特に日本では請負契約によるソフトウェア開発が一般的であり，これが「納期やコストの変化」と絶望的に相性が悪い。
もっとも，今の「ウォーターフォール」によるソフトウェア開発が，請負契約の成立条件である「契約時にスコープを確定（し，変更しない）」を厳密に守っているわけでもない以上，これだけを理由にアジャイルを否定するのはどうかとも思う。
契約については，IPA等でも取り組みがあるようだが，いずれにせよ契約を行うのは発注者と受注者であり，受注者側だけでどうこうできる問題でもないので，発注者側の意識の変化を期待するしかないかもしれない。
ついさっき田舎者の災難にあったところ。
映像は経費が発生するそれなりの仕事だったが、地元の小学校に寄贈するというので公益性を考慮し格安（15000円）で納品した。
女は2年前に納品した映像を小学校に寄贈せず店に放置していたという。
その映像を、こんど新築した土産物屋でタダで流させろ、さらに名前と目的は明かせないがダビングさせろ、音声データをよこせ、プレゼンにつかわせろと言ってきた。
早急に小学校に寄贈すること、営利施設での無料使用はみとめられない、使用するならあらたな契約が必要、意図が不明なダビングは許可できない、音声データは渡さない、内部プレゼンで資料として１回程度上映するのかかまわない、と伝えた。
ほんとにもう、田舎は低脳で非常識で恥知らずの寄生虫みたいなのばかりだ。
痴呆創生。
今日も日本の何処かで、基幹システムのリプレースが行われている。
基幹システム…そう、古くは汎用機にCOBOLという、枯れるを通り越してまさに朽ち果てんとしているアレだ。
そもそも朽ちて土に還る前に建て直すためのリプレースだ。
てか朽ちないんだったら、もう半永久的に触るべきじゃないと思うんだけど、形あるものは必ず滅びるのだ、作り直すしかない。勘弁してくれーという感じだ。
じゃあ何を用いて作り直すか？またCOBOLが一番手っ取り早そう(ソースいじらず移植という意味で)だが、それは許されないのだそうだ。ふざけんな。
今だったら大体どこでもJavaで作り直しだ。どういうわけか今のトレンド()だ。
てかそれ、オブジェクト指向とWebアプリに夢見過ぎじゃね？別にそれ銀の弾丸でもないしエクスカリバーでもなければ伝家の宝刀でもない、ただの道具なんですけど。
その証拠に、色々共通化されて保守性も拡張性も格段に上がったとか言ってる割に、その実態は、数える気にもならないほどインターフェースをimplementしまくった、複雑怪奇なクラスファイルの乱立ですよ。
もちろんドキュメントも上から下のレイヤーまで、そのクラスの分だけ揃ってる。というか山のようにある。いやそれ分量的に読めねーから。
ちなみに、今時の銀行や大企業は、基幹システム一つだけなんて事は無いケースが多い。基幹システムは複数あって相互に通信する巨大システム群の中の一つに過ぎなかったり。
そこで基幹システムだけ今風に作り直した所で、コスト増大の根本原因である複雑さの解消に、微塵も貢献しているとは思えないのだが、その質問はダメらしい。
もうさ、ぶっちゃけちゃうと、そもそも人間という柔軟な脳を持つ生き物がこなしている業務を、人間より正確かもしれないけど全く融通が効かないコンピュータに代替することが限界なんじゃね？と思うんだわ。
基幹システムを見ていると、そんな暗澹たる気分になる。
そりゃCOBOLと汎用機しか選択肢のなかった時代から比べて、今は色んなソリューションやソフトウェアがある。どれもシンプルに造るため、分かりやすく造るためにある。
しかしこの国の基幹システムは、それでもなお複雑さを解消していない。
あるいは、そういう大きなシステムを抱えている日本の組織性の問題なんですかね？
爆発しなくてもいいから、Google辺りに生息している本物のプログラマが、そういう複雑さを一気に解決するような、黒船もびっくりなソリューションで、今のITゼネコンありきのSIの世界に風穴を開けてくれることを切に願う。
