« 2022年12月 | トップページ

セックスロボットは「悪」なのか

白いシャツと眼鏡だけの、女性の人形がある。

肌の質感は生きている人そのもので、温かい。シャツを脱がすと、透き通るような白い肌(色は選べる)と、豊満な胸があらわれる(大きさは選べる)。

瞳を見つめると、視線を合わせてくる(オプション)。話しかけると反応し、見事なクイーンズ・イングリッシュで返事をする(オプション)。20種類の基本人格を元に、利用者との会話を記憶し、学習して応答するAIが組み込まれている(オプション)。

ボディに埋め込まれたセンサーにより、自身の体勢や利用者との位置関係、動きを把握する。把握した内容により、体温を上げたり、適切なタイミングで声を上げることができる。重要なパーツはボディから取り外し可能で、水洗いができる。

ロボット工学と人工知能を集大成した特注品で、5万ドル(650万円)になる。

 

セックスロボットと人造肉

『セックスロボットと人造肉』の著者ジェニー・クリーマンは、開発元の ABYSS(リンク先アダルト注意) を訪れ、インタビューする。もとはセックス・トイ(大人のおもちゃ)を製造販売していた業者だったが、顧客の様々な声に応えるため、私財を投入して研究所を作り上げたという。

ロボットは女性型・男性型と両方ある。人形はオーダーメイドであり、体形、顔、肌・瞳・唇・髪の色などの他項目にわたって選択可能で、ひとつずつ手作りされる。医療用シリコン素材を用いており、現役のストリップ・ダンサーの全身を型取りして作られている。

著者は、実際に型取りする現場を取材し、ダンサーに質問を投げかける。

Q:あなたの体で作られた人形がどう使われるのか、ご存じですか? あなたはいまここで、まさにセックスの道具にされようとしているんですよ。

A:別にかまわない。ストリップじゃ、男たちが私の体を見て楽しむでしょ。ロボットを買った人が何をしようと、私がそこにいるわけじゃない。誰かの愛情行為のお手伝いをするんだと思っている。

著者が問題とする焦点が、ダンサーと噛み合っていないのが興味深い。

著者は強い問題意識を持っている。

テクノロジーの進展により、ラブドールはセックスロボットになった。相手は人間ではなく、ロボットなのだから、男性は完全な支配権を持つことができる。自主性のない奴隷を手に入れた男性は、自分の欲望を好きなだけ、一方的に発散することができる。

愛情を深め合うコミュニケーション手段としてのセックスが蔑ろにされ、人間感情を深めることができなくなる。その結果、人間の女性とのパートナーシップが損なわれ、女性蔑視や暴力へつながる―――そういう問題意識だ。

一方でダンサーは、別の方向を見ている。ストリップに出演するよりギャラがいいというのもあるけれど、この流行は、きっと大人気になる。触れ合ったり、話をしたりできるロボットがある未来が、もう実現している。「未来の一部になれるなんて、悪くない」という締めが印象的なり。

セックスロボットがもたらす未来

人工的なパートナーの歴史は古い。

ピュグマリオンが彫ったガラテアを始め、SF映画の原点にして頂点と名高い『メトロポリス』に登場するマリア、スティーブン・スピルバーグ『Aー1』、『ブレードランナー』のレプリカント、ドラマなら『ウェストワールド』、ゲームなら『デトロイト』など、未来SF作品の傑作が並ぶ。

しかし、これはSFではなく現実だ。

人間の欲望は、昔も今も変わらない。ただ、欲望を満たし、思いのままに実現する方法、すなわちテクノロジーが発展してきたのが現在になる。テクノロジーの進展スピードがあまりにも速いため、時代の常識や人の認識を追い越し、予想外の問題をもたらしている。セックスロボットはその焦点といっていい。

セックスロボットがもたらす影響は小さくない。

人間そっくりとはいえ、モノなのだから何をしてもいい。公言できない願望を叶えてくれる人形に慣れてしまうことで、人間とのパートナー関係が疎かになり、相手のことを思いやる気持ちが失われるかもしれない。『セックスロボットと人造肉』は、この「問題」に焦点を当て、自らの欲望の赴くままテクノロジーに身をゆだねることで、「自分自身の一部を失ってしまう」と警鐘を鳴らす。

一方、これを読んでいる私は、むしろダンサーの方が近い。小説や映画で想像上だったものが、現実に製品として存在することを知ってぞくぞくする。モノであるのだから、向こうからは何もしてこないし、感染症の心配もない。人に向けると引かれるくらいの愛情であっても、受けとめてくれる。TENGAのおかげで救われた男性がいるように、ドールのおかげで救われる人も増えていくに違いない。

もちろん、本書が指摘する社会的・倫理的な問題にも取り組む必要がある。だが、セックスロボットを拒絶すべき「悪」と見なすのは早計だと考える。

セックスロボットに限らず、テクノロジーが問題をもたらすのはいつものことだ。そして、人はその度に解決を導くために努力してきた。さらに技術革新をして乗り越えたり、法や制度を更新して対応したり、認識や常識をアップデートしてきた。

テクノロジーは未来を増やす

本書では、他にもヴィーガンミート(人造肉)、子宮を再現したバイオバッグ、完全にコントロールされた安楽死装置など、様々な問題の焦点となる「モノ」をテーマに、生命倫理と資本主義、フェミニズムとウェルビーイングといった論点から斬り込んでゆく。

テクノロジーに頼りきりになるのではなく、問題を解決するための社会変革を起こせという主張になるほどと思いつつ、テクノロジーがもたらす未来を心待ちにしている自分がいる。

人に欲望がある限り、テクノロジーが後押しするのは避けられない。では、本書が示す暗い運命は避けられないかというと、それは違う。

テクノロジーの良い点は、選択肢が増えることだ。よくない選択肢は、たいていSF作品になっており、私たちは物語の形で履修済みだ(バイオバックは『マトリックス』、安楽死装置は『ブラックジャック』にあった)。未来を知ったうえで、選択肢を吟味しよう。

なお、冒頭で紹介した5万ドルのドールは、プロトタイプの特注品のお値段だ。技術革新により、スタンダードタイプだと6千ドル(90万円)になる。

| | コメント (1)

プロジェクトを炎上させない言葉と習慣

Photo_20230117121301

納期・予算・品質のいずれか(または全て)が制御不能になって炎上した問題プロジェクトを鎮火させる技術は、[ITエンジニアが修羅場を生き抜く3冊] に書いた。

一方、そもそもプロジェクトを炎上させない技術もある。

いま「プロジェクトを炎上させない技術」と呼んだが、要するに言葉と習慣だ。

プロジェクトである限り、必ず、何らかの火種をはらんでいる。要件は膨らむものだし、見積もりはズレが生じるもの。予想外の問題は常に起きるし、重要な問題ほど後から見つかるものだ。

こうした火元を察知して、手を打つ。あるいはそもそも火種にさせない。

そのために、何か特別なセンスが必要というわけではなく、トレーニングで身につけることができる。具体的には、ある言葉や習慣をくり返し実践し、チームに浸透させることで自然に備わるスキルだ。

  1. ご要望は承りました、要件に落とす検討をします
  2. ノー、それは我々の優先順位に合致していません
  3. あとどれだけ?(何日?/何時間?)
  4. いま、取り組むべき問題は何だろう?

これらは、経験者からすると「常識ですね」と片づけられるが、知らない人からすると初見殺しになる。いちど自分が痛い目に遭うか、そんな先輩や上司を見ていれば覚えるけれど、初見だと間違いなくハマる。

これらの言葉が、なぜプロジェクト初見殺しなのか、そしてどのように実践に適用していけばよいかを、[プロジェクトを炎上させない4冊] にまとめた。同時に、このスキルのエッセンスが学べる書籍も併せて紹介する。

ぜひ参考にしてほしい。

| | コメント (0)

たった一冊で「生活の質」を底上げする『TEST the BEST』

どんな包丁を使ってる?

私は amazon で見つけたステンレスのやつ。「三徳包丁」で検索したら大量に出てきたので、上の方にあった値段が手ごろなやつを買った。10年以上も前の話だ。

毎日使っているのだが、研ぎ方が悪かったのか、切れ味がイマイチに感じられる。新調しようと amazon を覗いて、フと気づいた。

  1. 「三徳包丁」だけでも500種類ある
  2. 新しい包丁は、毎日使うし、ずっと使っていく
  3. 良いものが欲しいけど、お金はそんなに出せない

「価格」「刃渡り」「素材」などで、検索結果を絞り込むことはできる。絞り込んでも100種類ぐらいになる。買うのは一つだけで、買ったらそれを10年くらい毎日使っていくのだから、良いのがいい。

もちろん、それなりにお金をかければ、品質的には十分なものが手に入るだろう。だが日用品にべらぼうなお金は出せない。いつもと同じぐらいの値段で、その価格帯で最も私に合ったものを選びたい。

本当は、お試しを実際に触って切ってみて、使い勝手を確かめたいのだが、そういうわけにもゆかぬ。

同じ値段で、良いのがほしい。私の代わりにチェックして比較してくれたらなぁ……

なんて思っていたら、『TEST the BEST』を見つけた。実際に買って試して評価した結果をまとめた本である。

包丁の場合、評価基準はこうだ。

  • 価格:5000円以下であること。ダイソーから貝印まで15種類をテスト
  • 切れ味:トマト、かぼちゃ、鶏肉、トーストを実際に切って切れ味を確認する(プロ料理人が実施)
  • 持続性:まな板に3000回切りつけ摩耗させ、水に浸して放置し(拭かない)劣化品にする。新品と劣化品で上の4種の食材の切れ味の差を確認する(プロ料理人が実施)
  • 使いやすさ:実際に家庭で利用してもらい、持ちやすさ、洗いやすさ、メンテナンスしやすさを検証する(主婦モニターが実施)

そして、総合評価をランキング形式で示してくれている。

これはありがたい。なぜなら、それぞれの特徴が比較できるから。例えば、私が重視するのは「切れ味」と「持続性」だ。主婦モニターが「大きくて使いにくい」と低評価でも、私には関係ないから。

結果、総合評価第2位の「藤次郎 A-1」に決めた。「切れ味」と「持続性」がダントツだそうな。面白いことに、amazon で「包丁」だけで検索しても類似品しかヒットせず、その類似品も下位になっている。10年使い倒してから感想を述べてみる。

ちなみに、いま使っている包丁の総合評価は5位だった。可もなく不可もなし、ただしトマトの切れ味は悪いとのこと(それ、私が常々思っていたことだ)。

こんな感じで、マスク、シャンプー、焼肉のタレ、味噌、コーヒーなど、日用品のレビューをしてくれている。評価の低いものは、どの点が良くないのか、どんな人にとって向いていないのかを解説してくれる。

我が家で使っているものと比べると、面白い。同じ価格帯でもっといいモノがあることに気づいたり、我が家で評判の商品が同じく高評価だったり、宝探しみたいで楽しい。

本書で高評価なものをいくつか並べて見た。あなたが普段使いしているものと比べてみると、楽しいかも。

焼肉のタレ(塩・レモン系)ダントツ1位。

我が家でも高評価で、焼いた肉にこれかけるだけで、みんなモリモリ食べてくれる。エバラなら大丈夫だろうと思っていたら、本書によると「エバラは当たり外れが大きい」とのこと。知らなかった……

洗剤は激戦だった。上位層はほぼ僅差だった。

よく見かけるのでこれを使っているが、「泡立ち」「泡もち」「手肌への優しさ」総合1位だった。面白いのは、評価ランキングと洗剤の値段が比例していないこと。高くてもダメなものはダメ、という姿勢がシビアなり。

味噌は評価が分かれていた。良いものは極めて良いし、ダメなものは酷い点がついていた。

ボトルタイプの味噌だと、これが高い評価を得ていた。コクと旨みと糀の自然な甘みにあふれていて、コクを出す調味料としても使えるらしい。一方で、我が家で常用している味噌は、ボロカスに評価されていた。マジか……今度、西友で探してみよう。消耗品の場合、「手に入れやすさ」も重要だな。

同じ価格帯で、より良いものを選ぶことで、生活の質を上げることができる。

次の買いものが楽しくなる一冊。

| | コメント (5)

しなくていい失敗を回避する『プロジェクトマネジメントの基本が全部わかる本』

プロジェクトマネジメント(PM)の重要性は、あまり認知されていないように見える。

うまく回っているときは「あたりまえ」扱いでスルーされ、いざ暗礁に乗り上げたときに「どうなってるんだ!?」と糾弾の的となる。

プロジェクトをうまく回していくコツというか勘所は確かにあり、相応のトレーニングが必要だ。にもかかわらず、なぜか蔑ろにされている。ろくに訓練もしないまま、「見て学べ」「やって覚えよ」と実践に放り込み、メンタルをやられず生き延びた者が幹部になる。

これは悪手だ。

よく、「失敗から学ぶほうがより身につく」などと唱える輩がいるが、しなくていい失敗は避けたほうがいいに決まってる。そして、この「しなくていい失敗」のほとんどは、基本を押さえるだけで回避できる。

この、PMの基本を押さえているのが本書だ。

『プロジェクトマネジメントの基本が全部わかる本』には、プロジェクトを回していくために「あたりまえ」のことが丁寧&具体的に説明されている。経験者が読めば、「なぜこんな当然のことを書くのだろう?」と疑問に思うかもしれない。だが、その「あたりまえ」をやらなかったために、数々の失敗があったのだ。

ここでは、本書で紹介されている「しなくていい失敗」と「それを回避する技」を合わせて紹介していく。これらが「あたりまえ」と見えるなら本書は不要だろうが、もっと知りたいのであれば、ぜひ手に取ってほしい。

要件が膨らみすぎて爆発する

要件定義を詰めていくとき、発注者の「アレがしたい」「この機能を入れたい」という言い分を丸のみして、身動きが取れなくなる。

もちろん発注者の要求なので尊重するべきだが、それを受け入れることで、品質・コスト・納期(QCD)に影響が出てくる。どれくらいの影響が出るかも含めて検討し、優先順位を付ける必要がある。どうすればよいか。

本書では、「要求と要件を分けよ」と説く。

つまりこうだ。発注者が言ってくることは、いったん「要求」として受け止める。そして、検討を進めることで「要件」に落としていく。具体的には、Excelなどで「要求」と「要件」のカラムを分けて、関係者に共有しながら検討を進めると、自然と切り分けが明確になっていく。

例えば、サイトをリニューアルするプロジェクトで、「パソコンやスマホでもスムースに見られるようにしたい」という要求は、要件として「レスポンシブデザインにする」となる。ポイントは、要求は「〇〇したい」という表現にして、要件は「〇〇する」という書き方にする。

重要なのは、発注者の言い分を、いったん「要求」として受け止める点にある。「要求」を持ち帰り、「この要求を要件に落とし込むのであれば……」という観点からプロジェクトメンバーと検討する。発注者は言い分を受け止めてもらったという印象を持つだろうし、メンバーは「要求は必ずしも要件ならず」と冷静に分析できる。

発注者の要求は、要件を決めるためのインプットであり、要件そのものではない。あたりまえのことなのに、両者をごっちゃにしている人は、結構いるように見える。

機能追加やスケジュール短縮のプレッシャーに負ける

思いつきレベルで機能追加が要求されたり、合意したはずの納期が短縮できないか圧力をかけてくる。発注者だけでなく、営業チームの連中や上司も思いつきでモノを言う。

もちろん一筋縄ではゆかぬ。適当にあしらうことが出来ればよいのだが、思いつきで言う連中に限って役職が上だったりするから一応は聞かねばならぬ。しかも、進捗会議の場で「アレ言ったよね」とプレッシャーをかけてくる。

その思いつきを受け入れるために、QCDのどこかに影響が出てくる。結果、プロジェクト全体で調整が必要となると、他ならぬ言い出しっぺが「それは聞いていない」と騒ぎ出す。非常によくある話だ。どう対処すればよいか。

これに対して本書は、「発注者は、自分の要求がプロジェクト全体にどのような影響を与えるかという視点を持っていない」と説く。これ、あたりまえのことなのだけど、見過ごされやすい。

要件定義をした後に機能追加を要求してきたり、たとえ一部でも前倒しの要望を出してきたとき、コストやスケジュール全体に影響が出る可能性を言っておく必要がある。

すると、どの程度のコスト増なのか、スケジュールへのインパクトがどれほどなのかといった質問が二の矢で来るだろう。だが、それを調べるためにも、それなりの時間がかかる。即答できないからといって、微々たるものである理由にはならない。

発注者の口頭ベースのプレッシャーに対し、エビデンスを残す。要求に対するプロジェクトへの影響を整理し、ファクトベースで資料化する。落としどころを予め想定し、事前に社内で通しておく―――その上で、発注者と交渉する。

プロジェクトでは、変更のプレッシャーが来るのは当たり前だ。だが、プレッシャーを受け止めた上で、「要求を言うのは自由だが、それを要件として呑むとどうなるのか」これをハッキリ告げるのは、PMしかいない。

あたりまえのことなのだが、これをやらないと、「言った/言わない」の不毛な空中戦になる。土壇場でちゃぶ台をひっくり返されたり、社内の後ろから撃たれることになる。お客から罵倒されるのに慣れても、背中から撃たれるのは痛いぞ。

「請負契約しか通せない」と言われたとき

契約締結プロセスでよくある話。発注者が「社内の稟議、請負なら通せるんですけど、準委任は厳しいですね」と言ってくるやつ。あるあるすぎて草も生えぬ。

補足すると、「請負」とは請負契約のこと。期日までに完成品を納めることが契約となる(つまり、納期と仕様が決められた契約)。「準委任」とは準委任契約のことで、一定の期間に労務を提供する契約となる。

そして、請負契約には罠がある。

納期は「〇年〇月〇日」と誰が見ても明確であるにもかかわらず、仕様は「〇〇機能を実装する」みたいなふわっとした書き方となっている。仕様は、変更/追加/読替えリスクが常について回る一方、納期は動かない。

プロジェクトあるあるとして、ふわふわした仕様を確定させようとする一方、動かない納期までの残り時間がどんどん食いつぶされるパターンがある。あるいは、できあがったものを、「これは欲しかったものではない」と難癖つけられるパターンだ。

現実はもう少し巧妙で、「早く製造に着手したいだろ?仕様を確定させたくばこの機能を入れろ」とか「難癖つけて瑕疵扱いされたくないだろ?なら無償でこの機能を入れろ」と捻じ込んでくる発注者がいる。そいつの不幸を心から希うのはこの瞬間である。

そうならないために、本書では有用なポイントを挙げている。

まず、「成果物の定義」だ。納品するものを定義する。成果物として何を書くかによって、プロジェクト全体への負担が変わってくる。ふわふわ変わる要件や仕様をドキュメント化していたら、そこへの負担が大きくなる。

必要なのはサービスやプロダクトなのだからと割り切って、成果物としてソースコードのみを納品物として提出する形とする。仕様書や設計書は、あくまで合意を得るための「共有資料」として扱うのだ。

次に、「検収の定義」だ。できあがった成果物を、発注者が受け入れる検収というプロセスがある。結合テストが問題なく行われたかを確認したり、第三者機関による脆弱性テストを確認するといった「検収の条件」を決めておく。

契約書に詳細化されなくても、すくなくともプロジェクト計画書に取り込んで文書化しておく必要がある。これ超重要なんだけれど、痛い目に遭わないと思い知らない人が多すぎる。

まだまだあるが、残りはご自身で確かめて欲しい。

この紹介で「あるあるwww」と笑える人には、本書は不要だろう。おそらく、ご自身が痛い目に遭ったか、そんな上司や先輩を見てきたかのいずれかだろう(というか、わたしがそうだった)。

わたし自身が酷い目に遭ってきたからこそ、なおさらこの本を薦めたい。ハマらなくていい罠は、予め回避できるのだから。

プロジェクトで転ばぬ先の一冊。

| | コメント (0)

« 2022年12月 | トップページ